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.

RACF provides definitions for the IBM MQ security classes in its supplied static Class Descriptor Table (CDT). As you work through the checklist, we can determine which of these classes your setup requires. We must ensure that they are activated as described in RACF security classes.

Refer to other sections for details, in particular Profiles used to control access to IBM MQ resources.

If you require security checking, follow this checklist to implement it:

Activate the RACF MQADMIN (uppercase profiles) or MXADMIN (mixed case profiles) class.
- Do we want security at queue sharing group level, queue manager level, or a combination of both?
  See, Profiles to control queue sharing group or queue manager level security.
Do we need connection security?
- Yes: Activate the MQCONN class. Define appropriate connection profiles at either queue manager level or queue sharing group level in the MQCONN class. Then permit the appropriate users or groups access to these profiles. Note: Only users of the MQCONN API request or CICS or IMS address space user IDs need to have access to the corresponding connection profile.
- No: Define an hlq.NO.CONNECT.CHECKS profile at either queue manager level or queue sharing group level in the MQADMIN or MXADMIN class.
Do we need security checking on commands?
- Yes: Activate the MQCMDS class. Define appropriate command profiles at either queue manager level or queue sharing group level in the MQCMDS class. Then permit the appropriate users or groups access to these profiles.
  If we are using a queue sharing group, you might need to include the user IDs used by the queue manager itself and the channel initiator. See Set up IBM MQ for z/OS resource security.
- No: Define an hlq.NO.CMD.CHECKS profile for the required queue manager or queue sharing group in the MQADMIN or MXADMIN class.
Do we need security on the resources used in commands?
- Yes: Ensure the MQADMIN or MXADMIN class is active. Define appropriate profiles for protecting resources on commands at either queue manager level or queue sharing group level in the MQADMIN or MXADMIN class. Then permit the appropriate users or groups access to these profiles. Set the CMDUSER parameter in CSQ6SYSP to the default user ID to be used for command security checks.
  If we are using a queue sharing group, you might need to include the user IDs used by the queue manager itself and the channel initiator. See Set up IBM MQ for z/OS resource security.
- No: Define an hlq.NO.CMD.RESC.CHECKS profile for the required queue manager or queue sharing group in the MQADMIN or MXADMIN class.
Do we need queue security?
- Yes: Activate the MQQUEUE or MXQUEUE class. Define appropriate queue profiles for the required queue manager or queue sharing group in the MQQUEUE or MXQUEUEclass. Then permit the appropriate users or groups access to these profiles.
- No: Define an hlq.NO.QUEUE.CHECKS profile for the required queue manager or queue sharing group in the MQADMIN or MXADMIN class.
Do we need process security?
- Yes: Activate the MQPROC or MXPROC class. Define appropriate process profiles at either queue manager or queue sharing group level and permit the appropriate users or groups access to these profiles.
- No: Define an hlq.NO.PROCESS.CHECKS profile for the appropriate queue manager or queue sharing group in the MQADMIN or MXADMIN class.
Do we need namelist security?
- Yes: Activate the MQNLIST or MXNLISTclass. Define appropriate namelist profiles at either queue manager level or queue sharing group level in the MQNLIST or MXNLIST class. Then permit the appropriate users or groups access to these profiles.
- No: Define an hlq.NO.NLIST.CHECKS profile for the required queue manager or queue sharing group in the MQADMIN or MXADMIN class.
Do we need topic security?
- Yes: Activate the MXTOPIC class. Define appropriate topic profiles at either queue manager level or queue sharing group level in the MXTOPIC class. Then permit the appropriate users or groups access to these profiles.
- No: Define an hlq.NO.TOPIC.CHECKS profile for the required queue manager or queue sharing group in the MQADMIN or MXADMIN class.
Do any users need to protect the use of the MQOPEN or MQPUT1 options relating to the use of context?
- Yes: Ensure the MQADMIN or MXADMIN class is active. Define hlq.CONTEXT.queuename profiles at the queue, queue manager, or queue sharing group level in the MQADMIN or MXADMIN class. Then permit the appropriate users or groups access to these profiles.
- No: Define an hlq.NO.CONTEXT.CHECKS profile for the required queue manager or queue sharing group in the MQADMIN or MXADMIN class.
Do we need to protect the use of alternative user IDs?
- Yes: Ensure the MQADMIN or MXADMIN class is active. Define the appropriate hlq.ALTERNATE.USER. alternateuserid profiles for the required queue manager or queue sharing group and permit the required users or groups access to these profiles.
- No: Define the profile hlq.NO.ALTERNATE.USER.CHECKS for the required queue manager or queue sharing group in the MQADMIN or MXADMIN class.
Do we need to tailor which user IDs are to be used for resource security checks through RESLEVEL?
- Yes: Ensure the MQADMIN or MXADMIN class is active. Define an hlq.RESLEVEL profile at either queue manager level or queue sharing group level in the MQADMIN or MXADMIN class. Then permit the required users or groups access to the profile.
- No: Ensure that no generic profiles exist in the MQADMIN or MXADMIN class that can apply to hlq.RESLEVEL. Define an hlq.RESLEVEL profile for the required queue manager or queue sharing group and ensure that no users or groups have access to it.
Do we need to 'timeout' unused user IDs from IBM MQ ?
- Yes: Determine what timeout values you would like to use and issue the MQSC ALTER SECURITY command to change the TIMEOUT and INTERVAL parameters.
- No: Issue the MQSC ALTER SECURITY command to set the INTERVAL value to zero.
Note: Update the CSQINP1 initialization input data set used by your subsystem so that the MQSC ALTER SECURITY command is issued automatically when the queue manager is started.
Do we use distributed queuing?
- Yes: Use channel authentication records. For more information, see Channel authentication records.
- We can also determine the appropriate MCAUSER attribute value for each channel, or provide suitable channel security exits.
Do we want to use Transport Layer Security (TLS)?
- Yes: To specify that any user presenting an TLS personal certificate containing a specified DN is to use a specific MCAUSER, set a channel authentication record of type SSLPEERMAP. We can specify a single distinguished name or a pattern including wildcards.
- Plan the TLS infrastructure. Install the System SSL feature of z/OS . In RACF, set up your certificate name filters (CNFs), if we are using them, and your digital certificates. Set up your SSL key ring. Ensure that the SSLKEYR queue manager attribute is nonblank and points to your SSL key ring. Also ensure that the value of SSLTASKS is at least 2.
- No: Ensure that SSLKEYR is blank, and SSLTASKS is zero.
For further details about TLS, see TLS security protocols in IBM MQ.
Do we use clients?
- Yes: Use channel authentication records.
- We can also determine the appropriate MCAUSER attribute value for each server-connection channel, or provide suitable channel security exits if required.
Check your switch settings.
IBM MQ issues messages when the queue manager is started that display your security settings. Use these messages to determine whether your switches are set correctly.
Do you send passwords from client applications?
- Yes: Ensure that the z/OS feature is installed and Integrated Cryptographic Service Facility (ICSF) is started for the best protection.
- No: We can ignore the error message reporting that ICSF has not started.
For further information about ICSF see Use the Integrated Cryptographic Service Facility (ICSF)

Parent topic: Plan for the security requirements