Security requirements vary from application to application.  WebSphere MQ is no different.  For instance, if you ignore security considerations for WebSphere MQ on i5/OS, UNIX and Windows systems, you simply won't be able to implement WebSphere MQ.  Ignoring these on WebSphere MQ for z/OS means any user will be able to access and change your MQ resources.

There are many variations of security implementation for WebSphere MQ.  With so many articles, technotes and books available on the subject, it's understandable how security can get confusing and sometimes complex.  This blog post is intended to provide you with some overall security basics as well as supply you with links to more detailed information to help secure your WebSphere MQ product.  It's based on what you should do first, along with what you could do if you decided to pursue all levels of protection.

So for starters, basic security should begin with your WebSphere MQ administrators.  The WebSphere MQ administrators should have the authority to:

• issue commands to administer WebSphere MQ (including the commands to grant WebSphere MQ authorities for other users)
• use the WebSphere MQ Explorer
• use the operations and control panels on z/OS
• use the WebSphere MQ utility program, CSQUTIL, on z/OS
• access the queue manager data sets on z/OS

WebSphere MQ objects also need authority.  Applications can access MQ objects by issuing MQI calls, but these objects are protected by WebSphere MQ and the User IDs associated with the applications need authority to access them. For more information, refer to: Authority to work with WebSphere MQ objects.

Another important aspect of access control is channel security.  In order to access WebSphere MQ resources, you'll need to grant authority to the User IDs associated with the channel agents.  User IDs associated with message channel agents (MCAs) also need authority to access those resources. Go to Channel security for complete information.

These additional considerations would only apply if you're using these specific WebSphere MQ functions.

Security for queue manager clusters - Queue manager clusters are queue managers associated with one another.  If you're using clusters, you'll need to consider allowing:

• selected queue managers to send messages to your queue manager.
• selected users of a remote queue manager to send messages to a queue on your queue manager.
• applications connected to your queue manager to send messages only to selected remote queues.

WebSphere MQ Publish/Subscribe would also need a certain level of security, such as granting authority for:

• publisher access
• subscribers access

WebSphere MQ internet pass-thru (available in SupportPac MS81) lets two queue managers exchange messages and can simplify communication through a firewall,  but it still has security implications.  Check out Security for WebSphere MQ internet pass-thru for more information.

Lastly, you'll need to look at Link level security and application level security.  Link level security is described as "security services that are invoked, directly or indirectly, by an MCA, the communications subsystem, or a combination of the two working together". Application level security is described as "those security services that are invoked at the interface between an application and a queue manager to which it is connected".

Here's a final snippet of security best practices (as referenced in The top 15 WebSphere MQ best practices developerWorks article):
"On distributed systems, the mqm group provides administrative access to all MQ resources on a system. Therefore, limit membership in the mqm group.

Security in MQ can be divided into two broad categories: MQ consumers and MQ administrators.  Consumers normally take the form of the IDs used to execute applications that connect to MQ.  Administrators are users who need to interactively query or alter MQ configurations through the included tooling (such as runmqsc). In some environments, the application-account IDs (consumers) are sometimes placed in the mqm group for simplicity. In these situations, these IDs should be locked down so that they cannot be used for interactive login, since any user who gains access to these IDs will have full administrative control over MQ.  An alternative is to use the WMQ OAM setmqaut facility to specify detailed API-level permissions for each resource or MQ object (such as queues).  This technique gives much more granular control and is preferred when feasible."

WebSphere MQ security resources

• Setting up security on z/OS
• Setting up security on UNIX systems and Windows
• Setting up security on i5/OS
• Getting started with WebSphere MQ for z/OS security
• WebSphere MQ for z/OS security
• Comparing WebSphere MQ security on distributed platforms and z/OS
• Implementing WebSphere MQ security

Marcações:  security websphere mq wmq