| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Enabling broker administration security |
« View previous topic :: View next topic » |
| Author |
Message
|
| rammer |
 Posted: Tue Apr 09, 2013 2:28 am Post subject: Enabling broker administration security |
 |
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
Morning All,
We are currently looking at building a new environment which will be on the following (currently we have 6.1MB and 6.xMQ)
AIX
MB 8.0.2
MQ 7.5
I have little (make that none) knowledge of Message Broker, another Team manage MB.
I was looking at the following document
http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.etools.msgbroker.helphome.doc%2Fhelp_home_msgbroker.htm
Within the document it states the following
"When you create or change a broker, your user ID must be a member of the WebSphere® MQ control group mqm."
I was hoping we would not have them in the mqm group as the message broker team will have full control then off mq.
It then mentions
"The broker creates the authorization queue SYSTEM.BROKER.AUTH. This queue is used to define which users are authorized to perform an action on the broker"
So if I did not add them to mqm I could create the above queue and give it relevant permissions.
It then goes on to read (in my mind) you do not need to add the broker id to mqm group
"Check that the user ID under which your broker is running is a member of the WebSphere MQ security group mqm. Without this authority, the broker cannot create or delete the authorization queues for execution groups at run time.
Because mqm authority grants full access control to all WebSphere MQ resources, you might not want your broker running with this level of authority. If you do not want the broker to run with mqm authority, you must work with your WebSphere MQ administrator to ensure that the required queues are created (and deleted) at the appropriate time."
So for example if I do not want to allow the Broker ID to be part of mqm group then basically I need to create the SYSTEM.BROKER.AUTH Queue and assign relevant permissions to it. After that there will be other queues that would need to be defined specifically by mq admin?
"The broker creates a queue for each defined execution group, with a name that conforms to the format SYSTEM.BROKER.AUTH.EG, where EG is the name of the execution group. It assigns default permissions of inquire, put, and set authority to the queue, which grants read, write, and execute access to the execution group and its properties, for the mqbrkrs group"
I would also define any other queues that they require in terms of local, alias, remotes which I already do on version 6.
I am querying this as on our old systems there is very little security at present
I guess the advice I am looking at is from people that are managing both MB and MQ and have carried out better security than we currently have.
Once I have tackled the security around installation I will expand the security further before the system is sued but I am currently wanting one step at a time.
THanks in advance |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Apr 09, 2013 9:35 am Post subject: Re: Enabling broker administration security |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rammer wrote: |
| So for example if I do not want to allow the Broker ID to be part of mqm group then basically I need to create the SYSTEM.BROKER.AUTH Queue and assign relevant permissions to it. After that there will be other queues that would need to be defined specifically by mq admin? |
Yes. If the broker's id does not have mqm authority then someone who does have that authority must do the work instead.
| rammer wrote: |
| "The broker creates a queue for each defined execution group, with a name that conforms to the format SYSTEM.BROKER.AUTH.EG, where EG is the name of the execution group. It assigns default permissions of inquire, put, and set authority to the queue, which grants read, write, and execute access to the execution group and its properties, for the mqbrkrs group" |
Well only if it has mqm authority, otherwise someone else will need to do it on behalf of the broker.
| rammer wrote: |
| I guess the advice I am looking at is from people that are managing both MB and MQ and have carried out better security than we currently have. |
My 2 cents:
It's better to have the broker's id in the mqm group so that the broker has the ability to create all the objects it needs. This does mean that anyone with administrative authority over the broker does have administrative authority over the queue manager, but in an ideal world one team has responsibility for both. Even in a less than ideal world, there can be sufficient controls put in place to a) disallow changes to WMQ without authority & b) detect such unauthorised changes. Both mqm and the broker service id should be non-terminal users only accessable via sudo and hence all use is logged.
Outside the administrative world there should be no access to or use of either the mqm or broker service id. Deploys can be individually authorised for developers via access to the alias queues as described.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rammer |
| Posted: Tue Apr 09, 2013 9:53 am Post subject: Re: Enabling broker administration security |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| Vitor wrote: |
My 2 cents:
It's better to have the broker's id in the mqm group so that the broker has the ability to create all the objects it needs. This does mean that anyone with administrative authority over the broker does have administrative authority over the queue manager, but in an ideal world one team has responsibility for both. Even in a less than ideal world, there can be sufficient controls put in place to a) disallow changes to WMQ without authority & b) detect such unauthorised changes. Both mqm and the broker service id should be non-terminal users only accessable via sudo and hence all use is logged.
Outside the administrative world there should be no access to or use of either the mqm or broker service id. Deploys can be individually authorised for developers via access to the alias queues as described. |
Hi Vitor thanks for the response. So far I have tried it without application account within mqm and currently getting failure.
BIP8134E: Unable to alter WebSphere MQ Queue Manager 'HUTPMB02'.
This command attempts to alter a WebSphere MQ Queue Manager, the Queue Manager could not be altered.
Locate and resolve the problem and retry the command.
I have created all the queues I believe it needs at start up time. as per document http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fbp43520_.htm
SYSTEM.BROKER.ADAPTER.FAILED
SYSTEM.BROKER.ADAPTER.INPROGRESS
SYSTEM.BROKER.ADAPTER.NEW
SYSTEM.BROKER.ADAPTER.PROCESSED
SYSTEM.BROKER.ADAPTER.UNKNOWN
SYSTEM.BROKER.ADMIN.QUEUE
SYSTEM.BROKER.ADMIN.REPLYTODM
SYSTEM.BROKER.AGGR.CONTROL
SYSTEM.BROKER.AGGR.REPLY
SYSTEM.BROKER.AGGR.REQUEST
SYSTEM.BROKER.AGGR.TIMEOUT
SYSTEM.BROKER.AGGR.UNKNOWN
SYSTEM.BROKER.AGGR.UNKNOWN
SYSTEM.BROKER.AUTH
SYSTEM.BROKER.DEPLOY.QUEUE
SYSTEM.BROKER.DEPLOY.REPLY
SYSTEM.BROKER.EDA.COLLECTIONS
SYSTEM.BROKER.EDA.EVENTS
SYSTEM.BROKER.EXECUTIONGROUP.QUEUE
SYSTEM.BROKER.EXECUTIONGROUP.REPLY
SYSTEM.BROKER.INTER.BROKER.COMMUNICATIONS
SYSTEM.BROKER.MODEL.QUEUE
SYSTEM.BROKER.TIMEOUT.QUEUE
SYSTEM.BROKER.WS.ACK
SYSTEM.BROKER.WS.INPUT
SYSTEM.BROKER.WS.REPLY
as well as SVRCONN it uses and gave the channel mcauser to the app account.
mq permissions given to queue manager and all the queues but we get the above error.
Just to test we had no issues with the install I popped the account back into the mqm group deleted the queue manager and let the broker create it which it did without any issues. I then stripped out what it had defined in terms of queues and channels and they did match what is above.
Ideal world yes MQ and MB would be done by the same people but I am afraid its not where I currently am and there is a very large spread around the world of people who have access to the MB Account, but not the mq account. But I do like your idea of having access to it only as sudo. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 09, 2013 10:03 am Post subject: Re: Enabling broker administration security |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rammer wrote: |
Hi Vitor thanks for the response. So far I have tried it without application account within mqm and currently getting failure.
BIP8134E: Unable to alter WebSphere MQ Queue Manager 'HUTPMB02'.
This command attempts to alter a WebSphere MQ Queue Manager, the Queue Manager could not be altered.
Locate and resolve the problem and retry the command. |
You will. The create broker command does more than create queue objects, it issues the setmqaut commmands needed to authorize the broker to use them. Without mqm authority these will fail.
| rammer wrote: |
| there is a very large spread around the world of people who have access to the MB Account |
Why? What do they use it for? Do they need access to the service account, need access to a few functions via the service account or need access because their project manager feels it makes his team more valuable?
| rammer wrote: |
| but not the mq account. |
Why does the justification to have access to the MB service account not justifiy access to the mqm account? What does that tell you about the strength of the justification?
| rammer wrote: |
| But I do like your idea of having access to it only as sudo. |
It's the only way to control this kind of anonomous account. Do not let anyone tell you it's unwieldy or will reduce productivity too much.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rammer |
| Posted: Tue Apr 09, 2013 10:17 am Post subject: Re: Enabling broker administration security |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| Vitor wrote: |
| rammer wrote: |
Hi Vitor thanks for the response. So far I have tried it without application account within mqm and currently getting failure.
BIP8134E: Unable to alter WebSphere MQ Queue Manager 'HUTPMB02'.
This command attempts to alter a WebSphere MQ Queue Manager, the Queue Manager could not be altered.
Locate and resolve the problem and retry the command. |
| Vitor wrote: |
| You will. The create broker command does more than create queue objects, it issues the setmqaut commmands needed to authorize the broker to use them. Without mqm authority these will fail. |
Yes I believe I added all the relevant permissions when I manually added all the queues that is adds at build time.
| rammer wrote: |
| there is a very large spread around the world of people who have access to the MB Account |
| Vitor wrote: |
| Why? What do they use it for? Do they need access to the service account, need access to a few functions via the service account or need access because their project manager feels it makes his team more valuable? |
The company I work for is world wide with support spread across the globe the support / dev teams are not all in one location. They dont need it directly but at the moment I am in no position to force people to use dedicated named accounts then sudo, yes I have pointed this out to customer etc but that is all I can do. I will raise it again. And they do understand it means that it makes audit a lot more of an issue.
| rammer wrote: |
| but not the mq account. |
| Vitor wrote: |
| Why does the justification to have access to the MB service account not justifiy access to the mqm account? What does that tell you about the strength of the justification? |
Ignore the above I was rushing when I typed that! yes one rule for all should be applied.
| rammer wrote: |
| But I do like your idea of having access to it only as sudo. |
It's the only way to control this kind of anonomous account. Do not let anyone tell you it's unwieldy or will reduce productivity too much. |
|
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 09, 2013 10:26 am Post subject: Re: Enabling broker administration security |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rammer wrote: |
| Yes I believe I added all the relevant permissions when I manually added all the queues that is adds at build time. |
I never said that you didn't. This won't stop the create broker command trying to issue them.
| rammer wrote: |
| The company I work for is world wide with support spread across the globe the support / dev teams are not all in one location. They dont need it directly but at the moment I am in no position to force people to use dedicated named accounts then sudo, yes I have pointed this out to customer etc but that is all I can do. I will raise it again. And they do understand it means that it makes audit a lot more of an issue. |
Nothing you've said here is a justification for unfettered access to the service id. You've at least raised the point, I understand your position and it all really hinges on how much they want more security & control.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Apr 09, 2013 11:30 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
One IT Manager I worked with got really fed up with the number of problems due to the MQ Team messing with the broker Qmgrs. (applying their 'hardening' etc)
In the end he told them in a broad liverpuddlian accent
"If you lot mess with the broker queue managers one more time each and every one of you will be singing as sopranos. Get it?"
We didn't have any more issues after that.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 10, 2013 4:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
In the end he told them in a broad liverpuddlian accent
"If you lot mess with the broker queue managers one more time each and every one of you will be singing as sopranos. Get it?" |
Not quite what I meant about controls preventing unauthorized changes but it does illustrate the point.
And in keeping with regional & cultural norms. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
