Keeping clusters secure

Authorize or prevent queue managers joining clusters or putting messages on cluster queues. Force a queue manager to leave a cluster. Take account of some additional considerations when configuring TLS for clusters.

• Stopping unauthorized queue managers sending messages
  Prevent unauthorized queue managers sending messages to your queue manager using a channel security exit.
• Stopping unauthorized queue managers putting messages on your queues
  Use the channel put authority attribute on the cluster-receiver channel to stop unauthorized queue managers putting messages on your queues. Authorize a remote queue manager by checking the user ID in the message using RACF on z/OS, or the OAM on other platforms.
• Authorizing putting messages on remote cluster queues
  On z/OS set up authorization to put to a cluster queue using RACF. On other platforms, authorize access to connect to the queue managers, and to put to the queues on those queue managers.
• Preventing queue managers joining a cluster
  If a rogue queue manager joins a cluster it is difficult to prevent it receiving messages we do not want it to receive.
• Forcing unwanted queue managers to leave a cluster
  Force an unwanted queue manager to leave a cluster by issuing the RESET CLUSTER command at a full repository queue manager.
• Preventing queue managers receiving messages
  We can prevent a cluster queue manager from receiving messages it is unauthorized to receive by using exit programs.
• SSL/TLS and clusters
  When configuring TLS for clusters, be aware a CLUSRCVR channel definition is propagated to other queue managers as an auto-defined CLUSSDR channel. If a CLUSRCVR channel uses TLS, we must configure TLS on all queue managers that communicate using the channel.

Parent topic: Securing IBM MQ