>what are the drawbacks of just making one big cluster (external and >internal queue managers in the same cluster) as opposed to having a >"gateway" queue manager in overlapping clusters (which is recommended from >one document that I've read).
Your firewall administration can get unwieldy. Rather than setting up a couple rules on the firewall, you now have to allow for the possibility of however many external QMgrs connecting to some number of internal QMgrs. So if you have three internal QMgrs talking to two external QMgrs you will need 6 sets of rules. You will also need to set up the firewall with no address translation among all the related hosts. When you set up a CLUSRCVR channel, both the external hosts and the internal hosts (the repositories at the very least) need to access it using the same IP address. >Aside from issues with server connection channels, what other security >issues should we be concerned with, and how would those issues be addressed? An MQ cluster is basically a Pub/Sub engine feeding a modified Command Server. When you advertise a queue or join a cluster, the configuration change is published to the repositories and propagated to anyone subscribed to those changes. When the published changes arrive at a repository or subscribing QMgr they are acted on by the modified Command Server which then builds channels or updates the local repository (whether full or partial). >From a security standpoint, you should be aware that any member of the cluster can publish these messages and your QMgrs will automatically respond. That means any QMgr which can join the cluster can become a full repository and/or alter the cluster's configuration. Also, any QMgr which can join the cluster can send messages anywhere throughout the cluster, whether the target queues are advertised to the cluster or not. So if your QMgrA is in the cluster I can send PCF messages to [EMAIL PROTECTED] and because they arrive over your CLUSRCVR channel, chances are they have full mqm admin privileges. Since the attacker can be a repository, they generally know enough about your cluster to go at least one hop beyond the cluster further into your MQ network. The gateway is meant to restrict that one-hop access to just the QMgrs the other side needs to know about. Remove the gateway and the one-hop now extends considerably further in. -- T.Rob Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
