| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Different Service IDs for multiple Brokers on Windows |
« View previous topic :: View next topic » |
| Author |
Message
|
| JanB_193 |
 Posted: Wed Oct 15, 2014 2:59 am Post subject: Different Service IDs for multiple Brokers on Windows |
 |
|
Novice
Joined: 22 Aug 2014
Posts: 15
|
Hi all
I'm currently implementing a new WMQ/IIB Setup where we have three Brokers running on the same VMWare Image and WMQ Infrastructure. Each Broker represents a customer and I want to make sure that customer specific data is not (accidentically) processed by the wrong Broker - meaning a given Broker may only access the directories oh "his" customer.
By using different Service IDs (one for WMQ and one each for every Broker) I hope to separate the access rights to the customer data specific to each instance.
In my first try the Broker Service ID was only in the mqbrks group (and not in mqm) but this caused problems when it tried to access the WMQ-Queues.
Since we have a very volatile environment manually setting the access rights for every queue a Broker will need would soon become unmanageable. I "solved" the issue by adding the Broker Service ID into the mqm Group, but this seems like a solution where I basically circumvent the security?
Any suggestions on how I could do this in a better/smarter way would be greatly appreciated.
We use:
IIB v9.0.0.2
WMQ v8.0.0.0
Windows Server 2012 R2
Thanks a lot in advance
Jan |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Oct 15, 2014 5:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There are instructions, or at least there used to be, in the KC for how to configure a broker to not need mqm membership.
Unless I'm remembering wrong.
The important thing to remember about your setup, though, is that each broker at v9 and earlier *has to have* a dedicated queue manager.
So you merely need to route the right messages to the right queue manager to ensure that each broker only processes the right customer data. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 15, 2014 5:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Its also 100% possible to remain secure by using one QM and one Broker if the data is coming in and out via MQ. You have that level of granularity in MQ layer for queues and channels.
If you are worried about cross memory leakage of data (not sure its a legitimate concern), then you should be using separate virtual servers for each Broker / QM.
Jan, maybe you can provide a scenario where you feel 2 separate Brokers are required? Perhaps we can demonstrate how it can be solved with a single Broker / QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 15, 2014 5:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Jan talked about file system access. That's tough to secure without using different service ids.
Although I forget, maybe you can run different EGs under different IDs these days? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 15, 2014 5:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| There are instructions, or at least there used to be, in the KC for how to configure a broker to not need mqm membership. |
There are indeed such instructions, which cover what objects IIB needs access to just to work. But:
| JanB_193 wrote: |
| Since we have a very volatile environment manually setting the access rights for every queue a Broker will need would soon become unmanageable |
Like any other MQ application, IIB needs the correct access rights to the MQ objects it's using. So you will either need to set up access rights for each queue or give IIB access to all queues via mqm membership. Pick your poison.
| mqjeff wrote: |
The important thing to remember about your setup, though, is that each broker at v9 and earlier *has to have* a dedicated queue manager.
So you merely need to route the right messages to the right queue manager to ensure that each broker only processes the right customer data. |
The OP is talking about directories, which may be a kink in this otherwise correct statement. All of the MQ & broker materials will be isolated in the correct queue manager structure with the usual lack of access and the OP doesn't really have a problem. But if the broker flows are inputting or outputting files then, at first flush, all the brokers can write to any of the customer's directories because they all have the same ids.
On this site we have 1 broker (logically - it's scaled to be many brokers) servicing many customers with a lot of file based traffic. We handle this by giving the broker's id access to all the of directories and secondary access (group) to a specific customer's group. So the customers can only access their data but broker can write to them all. Data is kept separate by means of running the right data through the right flows, in the same way you're planning to run the right data through the right brokers.
My 2 cents, YMMV.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 15, 2014 6:09 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
Jan talked about file system access. That's tough to secure without using different service ids.
Although I forget, maybe you can run different EGs under different IDs these days? |
Also tough to do on Windows! Although he says he is going with 2012, perhaps that is more robust in this area.
Vitor's point is well taken...if you control what the flows are coded to do, and control who can invoke what flow, then there is no problem.
Yeah, I thought I remember something about have EGs run under distinct service accounts....was that a new actual feature, or just a Request For Enhancement we are remembering?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
