| Author |
Message
|
| bloomy |
 Posted: Thu Dec 15, 2011 1:24 pm Post subject: Security in WMB V7 |
 |
|
Acolyte
Joined: 11 Feb 2009
Posts: 61
Location: Bloomington, IL USA
|
Wanted to post this to get some insight on the security settings and my issues/concerns with the new security setup and share my thoughts so that I will be corrected if my understanding is wrong.
As most of you know WMB V7 does not have configmgr and there are no ACL entries needed for administrative security for broker. The security in WMB V7 is setup by granting access to the SYSTEM.BROKER.AUTH.QUEUES and there are alias queues autodefined by broker for each execution group(good thing is that we can go down to EG level for security, which was not possible until V6), my concern/question lies here.
In V6 we were able to define groups for different users and define access to them based on their role, like developers would be given deploy access only in test and view access in test and production and this can be done in V7 also by giving the access to the SYSTEM queues but my concern is, every user who is in mqm will have all access on all the attributes in the queue manager and there is no way to remove access to mqm or restrict access to mqm.
Issue is:
let us say we need users to be part of mqm but not give them deploy access in production for broker. As broker uses the qmgr where the users are added to mqm group, even if i grant limited access to the group they are in the mqm access will override the other group access.
And with the size of the infrastructure we have we define the groups including mqm and add the same groups on all servers with mq and mb combination, mq only servers and WAS and mq combination servers.
Solution would be:
1. dont use MQ explorer or toolkit and develop customized tools with which we can grant access to specific users
2. create the broker qmgrs with ID other than mqm so that we can restrict mqm users with access on brokers
Bottom line is, why would IBM change the ACL's to add the queue based security? Do you think we could have a simple solution in this case. |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Thu Dec 15, 2011 1:41 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
First off, you should never run WMB under the mqm Id. Broker should have its own security service Id whose primary group membership is mqbrkrs and secondary group membership is mqm.
The reason you should never run under the mqm service Id is because mqm's primary group membership is mqm group not mqbrkrs group.
That being said, developers never should access WMB runtimes on anything but sandbox systems. DevInt systems should prevent anyone who cannot sudo into the mqbrkrs service Id from doing any commands against broker.
That THAT being said, no command should ever be run against a broker runtime unless that user is sudo'd into the Broker's service Id.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| bloomy |
| Posted: Fri Dec 16, 2011 10:55 am Post subject: |
|
|
Acolyte
Joined: 11 Feb 2009
Posts: 61
Location: Bloomington, IL USA
|
Thanks for the response lancelotlinc.
May be I was not clear here, my issue is not with runtime and as you said we have a seperate ID for broker and broker does not run under mqm. The issue I have is with access from toolkit to broker, how do I restrict people who are in mqm on performing administrative tasks on broker from toolkit.
For our runtime, only people who can sudo to the broker service ID can perform admin tasks on them and we can easily restrict that.
It is not like we have something down with this but I am not comfortable with users having additional access than they are supposed to have. I might take up the step of cleaning the mqm group and remove people who are not supposed to have access on broker and may be create a seperate ID's file for broker and non broker servers so that if a user has to be in mqm on non broker ID will not be automatically added to broker server.
Just wanted to know how people are handling such situation elsewhere if anyone is in such situation. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Dec 16, 2011 11:44 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Dec 16, 2011 12:12 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| You change the default port and don't tell them what the new port is. |
Well, that'll last for a short period of time.
Setting up SSL and denying access to any svrconns is a more long term solution.... But it doesn't discriminate between MQExplorer and Toolkit/MBExplorer. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 16, 2011 12:12 pm Post subject: Re: Security in WMB V7 |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bloomy wrote: |
| let us say we need users to be part of mqm but not give them deploy access in production for broker. |
Users don't need to be part of mqm unless they're administrators.
| bloomy wrote: |
| 1. dont use MQ explorer or toolkit and develop customized tools with which we can grant access to specific users |
Or secure WMQ properly with SSL so that only relevant personal can connect to the relevant environment.
| bloomy wrote: |
| 2. create the broker qmgrs with ID other than mqm so that we can restrict mqm users with access on brokers |
You should be doing that anyway.
| bloomy wrote: |
| Do you think we could have a simple solution in this case. |
There is - SSL. It's easy enough to set up your own CA and an internal CA is enough for this kind of connection.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 16, 2011 12:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| But it doesn't discriminate between MQExplorer and Toolkit/MBExplorer. |
This is an issue my end where that lack of discrimination is worrying the team which supports WMQ & a) doesn't want me in the queue managers b) doesn't want to come within a mile of a broker.
I sigh, and move forwards.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Dec 16, 2011 12:59 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| mqjeff wrote: |
| But it doesn't discriminate between MQExplorer and Toolkit/MBExplorer. |
This is an issue my end where that lack of discrimination is worrying the team which supports WMQ & a) doesn't want me in the queue managers b) doesn't want to come within a mile of a broker.
I sigh, and move forwards. |
I think its so funny that IT doesn't want WMB people near their WMB .
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 16, 2011 1:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| I think its so funny that IT doesn't want WMB people near their WMB . |
Oh the WMB people (effectively me) can go to any WMB I want. It's the WMQ people who don't want any truck with this transformational technology.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 16, 2011 9:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
Setting up SSL and denying access to any svrconns is a more long term solution.... But it doesn't discriminate between MQExplorer and Toolkit/MBExplorer. |
It well can if you set up your access rights correctly and set up your SSL PEER correctly on the channel to discriminate.
On the other hand I would tend to agree that if you want to connect to the qmgr and the broker using the same chl... there will be no difference but for the actions you may be authorized to do...
(add the broker's service account to mqm group but not the broker's admin account).... but then I have not explored such a scenario much. We do not distinguish between mq admin and broker admin...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Dec 16, 2011 11:28 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
| It's the WMQ people who don't want any truck with this transformational technology. |
Pehaps they feel a little threratened by you due to the fact that you may well know more about WMQ than they do?
Where I am currently employed (3 weeks left) even the person responsible(me) for the use of WMQ and Broker in thre company does not have any access to PreProd or Production systems. I have to get the Admins to do it all.
Actually, that suits me fine. If they mess up then they can't point the finger at anyone but themselves. So far they have not messed up.(yet)
_________________
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: Sat Dec 17, 2011 5:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| Vitor wrote: |
| It's the WMQ people who don't want any truck with this transformational technology. |
Pehaps they feel a little threratened by you due to the fact that you may well know more about WMQ than they do? |
It's likely, but it's more corporate circling of the wagons. Because they're responsible for the WMQ estate they don't like anyone else having authority. This speaks volumes to the quality of the audit control and monitoring.
As these are the people who have 27 queue managers in a hub and spoke because "you can monitor the health by checking if the transmission queues are backing up. You can't monitor a cluster".
| fjb_saper wrote: |
| We do not distinguish between mq admin and broker admin... |
That's a common model in my experience. The wrinkle in my case is that WMB is owned, licensed and maintained by same area that runs WAS, WESB and so forth because it contains code. WMQ is in a different business area with the network, databases and OS because it's an infrastructure component.
Political abstraction what can you do but keep calm & carry on?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Dec 17, 2011 3:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
| lancelotlinc wrote: |
| I think its so funny that IT doesn't want WMB people near their WMB . |
Oh the WMB people (effectively me) can go to any WMB I want. It's the WMQ people who don't want any truck with this transformational technology. |
I admit I have not actually set up a WMB 7 Broker yet, but from what I read a while ago on the topic.....Can they not give you a secure channel to the Broker's QM that is tagged with an MCAUSER that gives you all the access you need to the Broker but no access to the WMQ Administration layer on that QM?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Dec 17, 2011 5:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| I admit I have not actually set up a WMB 7 Broker yet, but from what I read a while ago on the topic.....Can they not give you a secure channel to the Broker's QM that is tagged with an MCAUSER that gives you all the access you need to the Broker but no access to the WMQ Administration layer on that QM? |
Well the first problem there is they don't use SSL "because the cost is prohibitive". I've checked, and they do mean the cost of Versign (or similar) certificates. Why they don't have an internal CA who authorises entirely internal systems is a question I'm still waiting for an answer on.
If you have a link to something that describes this kind of set up I'd welcome it as weight to the discussion.
Currently they don't use WMQExplorer because "it can't be secured and you can download it from the Internet". They instead use a 3rd party tool which requires you to log onto it and has internal ACL rules "because it allows them to control access & functions". The devil on my shoulder wants to point out this tool uses a SVRCONN channel with no SSL (see above), no security exits and an MCAUser that's a member of the mqm group...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Dec 18, 2011 1:01 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
If you have a link to something that describes this kind of set up I'd welcome it as weight to the discussion.
|
Talk to Jenny Chow @ ibm and ask for an advanced copy of the lecture I gave at nynjmq.org that just describes such a setup.
By the way if you need SSL FIPS you'll have to open a PMR to get the fix (toolkit 7.0.0.2 and 7.0.0.3).
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
