Security in queue manager clusters on z/OS

Security considerations for clusters are the same for queue managers and channels that are not clustered. The channel initiator needs access to some additional system queues, and some additional commands need appropriate security set.

We can use the MCA user ID, channel authentication records, TLS, and security exits to authenticate cluster channels (as with conventional channels). The channel authentication records or security exit relating to the cluster-receiver channel must check that the remote queue manager is permitted access to the server queue manager's cluster queues. We can start to use IBM MQ cluster support without changing your existing queue access security. We must, however, allow other queue managers in the cluster to write to the SYSTEM.CLUSTER.COMMAND.QUEUE if they are to join the cluster.

IBM MQ cluster support does not provide a mechanism to limit a member of a cluster to the client role only. As a result, we must be sure that you trust any queue managers that you allow into the cluster. If any queue manager in the cluster creates a queue with a particular name, it can receive messages for that queue, regardless of whether the application putting messages to that queue intended this or not.

To restrict the membership of a cluster, take the same action that you would take to prevent queue managers connecting to receiver channels. You restrict the membership of a cluster by using channel authentication records or by writing a security exit program on the receiver channel. You can also write an exit program to prevent unauthorized queue managers from writing to the SYSTEM.CLUSTER.COMMAND.QUEUE.

Note: It is not advisable to permit applications to open the SYSTEM.CLUSTER.TRANSMIT.QUEUE directly. It is also not advisable to permit an application to open any other transmission queue directly. If we are using resource security, consider the following points in addition to the considerations contained in Security considerations for the channel initiator on z/OS:

    System queues
    The channel initiator needs RACF ALTER access to the following system queues:

    • SYSTEM.CLUSTER.COMMAND QUEUE
    • SYSTEM.CLUSTER.TRANSMIT.QUEUE.

    and UPDATE access to SYSTEM.CLUSTER.REPOSITORY.QUEUE

    It also needs READ access to any namelists used for clustering.

    Commands
    Set appropriate command security (as described in Table 1 ) for the cluster support commands (REFRESH and RESET CLUSTER, SUSPEND, and RESUME QMGR.

Parent topic: Set up security on z/OS