Plan for the security requirements
This collection of topics explains what we need to consider when planning security in an IBM MQ environment.
We can use IBM MQ for a wide variety of applications on a range of platforms. The security requirements are likely to be different for each application. For some, security will be a critical consideration.
IBM MQ provides a range of link-level security services, including support for Transport Layer Security (TLS).
We must consider certain aspects of security when planning to install IBM MQ:- On Multiplatforms, if you ignore these aspects and do nothing, we cannot use IBM MQ.
- On z/OS, the effect of ignoring these aspects is that the IBM MQ resources are unprotected. That is, all users can access and change all IBM MQ resources.
Authority to administer IBM MQ
IBM MQ administrators need authority to:- Issue commands to administer IBM MQ
- Use the IBM MQ Explorer
- Use IBM i administrative panels and commands.
- Use the operations and control panels on z/OS
- Use the IBM MQ utility program, CSQUTIL, on z/OS
- Access the queue manager data sets on z/OS
For more information, see:
- Authority to administer IBM MQ on UNIX, Linux, and Windows
- Authority to administer IBM MQ on IBM i
- Authority to administer IBM MQ on z/OS
Authority to work with IBM MQ objects
Applications can access the following IBM MQ objects by issuing MQI calls:- Queue managers
- Queues
- Processes
- Namelists
- Topics
Applications can also use Programmable Command Format (PCF) commands to access these IBM MQ objects, and to access channels and authentication information objects as well. These objects can be protected by IBM MQ so that the user IDs associated with the applications need authority to access them.
For more information, see Authorization for applications to use IBM MQ.
Channel security
The user IDs associated with message channel agents (MCAs) need authority to access various IBM MQ resources. For example, an MCA must be able to connect to a queue manager. If it is a sending MCA, it must be able to open the transmission queue for the channel. If it is a receiving MCA, it must be able to open destination queues. The user IDs associated with applications which need to administer channels, channel initiators, and listeners need authority to use the relevant PCF commands. However, most applications do not need such access.
For more information, see Channel authorization.
Additional considerations
We need to consider the following aspects of security only if we are using certain IBM MQ function or base product extensions:- Security for queue manager clusters
- Security for IBM MQ Publish/Subscribe
- Security for IBM MQ Internet Pass-Thru
- Plan identification and authentication
Decide what user IDs to use, and how and at what levels we want to apply authentication controls. - Plan authorization
Plan the users who will have administrative authority and plan how to authorize users of applications to appropriately use IBM MQ objects, including those connecting from an IBM MQ MQI client. - Plan confidentiality
Plan how to keep your data confidential. - Plan data integrity
Plan how to preserve the integrity of our data. - Plan auditing
Decide what data we need to audit, and how we will capture and process audit information. Consider how to check that the system is correctly configured. - Plan security by topology
This section covers security in specific situations, namely for channels, queue manager clusters, publish/subscribe and multicast applications, and when using a firewall. - Firewalls and Internet pass-thru
You would normally use a firewall to prevent access from hostile IP addresses, for example in a Denial of Service attack. However, you might need to temporarily block IP addresses within IBM MQ, perhaps while you wait for a security administrator to update the firewall rules. - IBM MQ for z/OS security implementation checklist
This topic gives a step-by-step procedure we can use to work out and define the security implementation for each of the IBM MQ queue managers.
Parent topic: Securing IBM MQ