| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WMB security - EG userid for accessing resources |
« View previous topic :: View next topic » |
| Author |
Message
|
| hopsala |
 Posted: Fri Oct 23, 2009 12:40 pm Post subject: WMB security - EG userid for accessing resources |
 |
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Ho there,
Back when V6 came out, I was making a security review for a client. To my horror, I discovered that all Execution Groups use the broker userid for accessing external resources (files, queues) or one universal pre-set mqsetdbparms userid for accessing the database. In other words, there was no way to assign a userid for each EG or flow. Consequently, the "broker per application" concept was born.
The problem is that a programmer for a non-secure application could start reading messages from a confidential queue (maliciously or by mistake) by simply inserting a new MQInput node into his flow and asking the admin to deploy it; since the broker has to be authorized to access all the queues in his QM, every flow can access every queue. The same goes for databases.
So, my question is: has this has changed in V6.1 or in V7 ? I haven't been able to find any reference to it in 6.1 lit, and the 7.0 info center isn't up yet.
Much obliged!
H |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Oct 23, 2009 1:26 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You have clearly misunderstood what mqsisetdbparms allows.
mqsisetdbparms gives you a specific userid and password for each DSN.
You should therefore have, at a minimum, one DSN! per application.
There's absolutely no requirement that every DSN must point to a unique database.
There are not any controls over the userid that is used for MQInput, that is always the broker service user which must always be in mqm (at least until MB v7). However, your deployment review processes /change control processes should cover this (and you can't claim a secure environment if you don't have them!).
There is additional message level security available with SOAP messages, and of course you can use other kinds of message level security tools. Or if you really felt you had to, you could use JMSInput nodes instead of MQInput nodes and establish client connections over dedicated (and therefore secured) SVRCONNs. But clearly you would have to be convinced of the security value for the performance hit. |
|
| Back to top |
|
|
| mgk |
| Posted: Fri Oct 23, 2009 1:36 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1638
|
Some of this has changed, but by no means all. In V7 (in fact since 6.1.0.4) there is no requirement for the Broker userid to be a member of the mqm group. Additionally, in V7 on Windows there is no longer a requirement for the service userid to be an Administrator, only that they are a member of the mqbrkrs group.
There are also some changes to the admin security model for deployment, and I'm sure mqmatt will be along here soon to tell you what they are 
Also, please raise a requirement for the features you still think may be missing...
Kind Regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Oct 23, 2009 11:48 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| mqjeff wrote: |
You have clearly misunderstood what mqsisetdbparms allows.
mqsisetdbparms gives you a specific userid and password for each DSN.
You should therefore have, at a minimum, one DSN! per application.
There's absolutely no requirement that every DSN must point to a unique database. |
All this I know; I guess trying to save characters by saying "same goes for db" has come back to haunt me.. The problem here is not that its one DSN per db, but that there are is no way to secure access to a particular DSN. If I define one DSN with a secure user, and another with a non-secure user, I still can't prevent a non-secure message flow from accessing the secure DSN. The problem remains.
Same goes for what you said about JMS nodes, I can't prevent a non-authorized flow ("non-authorized flow" being a new concept I'm suggesting we need to have) from accessing an authorized jndi name. (can I?)
| mqjeff wrote: |
| There are not any controls over the userid that is used for MQInput, that is always the broker service user which must always be in mqm (at least until MB v7). However, your deployment review processes /change control processes should cover this (and you can't claim a secure environment if you don't have them!). |
Here I really disagree. You can't expect the prod env admins to have the time and the know-how to review each and every new deployments. And besides, this isn't just about intended break-ins, it's also about preventing simple human mistakes.
Unless I misread you, what you're saying amounts to proposing that any regular application (exe file) should run as admin on the machine, since it should be reviewed before deployment. If WMB offers increased granularity of sub-environments (MF under EG), it should also offer the same granularity for security measures. This is a WMB limitation, not a feature.
| mgk wrote: |
| Also, please raise a requirement for the features you still think may be missing... |
I did, over three years ago. At the time I was promised that each EG will have a different userid by V6. Sadly, I wasn't the one who opened the request (I was at a client's site), so I lost track of what went down since.
Let me be clear about this: this is a very, very serious problem. I know of two large sites (banks) who have been using one broker per application (or per a group of applications with similar confidentiality requirements), with all the increased admin and cost overheads. Thankfully, neither site has too many broker apps, but this is slowly changing as they continue to develop new flows.
I curious to know how other sites deal with this. There are, after all, regulations governing international banks which explicitly state you can't have two applications being able to read from the same queue. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Oct 24, 2009 9:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| hopsala wrote: |
| mqjeff wrote: |
| There are not any controls over the userid that is used for MQInput, that is always the broker service user which must always be in mqm (at least until MB v7). However, your deployment review processes /change control processes should cover this (and you can't claim a secure environment if you don't have them!). |
Here I really disagree. You can't expect the prod env admins to have the time and the know-how to review each and every new deployments. And besides, this isn't just about intended break-ins, it's also about preventing simple human mistakes. |
I repeat, in order for an environment to be considered secure, it must include code review processes and deployment review processes, regardless of what kind of code and deployment is involved. If you tell any halfway competant security auditor that "the production admins just deploy whatever they're given by the development team whenever the development team wants and there's been no review of anything at all", you'll fail right then and there.
This is doubly true of production deployments, in order TO prevent simple human mistakes as well as intended break-ins.
Even if Broker did everything you wanted, you would STILL require review processes before production deployments and security considerations should STILL be part of that.
And, no, I'm not saying that every application should run as root. I'm saying that every application should be reviewed as if it *did* run as root.
At least, this is my belief when I'm wearing my security hat. When I'm wearing my developer hat, it's a different viewpoint.
The message level security stuff that's available with SOAP nodes is an important direction that is being taken with Broker in this area. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Oct 24, 2009 11:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hopsala wrote: |
| Here I really disagree. You can't expect the prod env admins to have the time and the know-how to review each and every new deployments. And besides, this isn't just about intended break-ins, it's also about preventing simple human mistakes. |
I'm forced to partially refute you here. While the prod env admins (if by this you mean the people actually running the env) don't have time and know-how to perform this review, then yes. But this doesn't mean that new deployments are should not be reviewed. Whatever procedure you use to get new code into production should include a review step by relevant authorities. At the minimum it's a peer review, at the maximum it's a full all singing/all dancing test suite or whatever else your internal audit people demand.
All the prod env admins (in your scenario) should be doing is verifying the code supplied for delivery is the same as that signed off by whatever the review process is. It's not the previous version, the untested next version or the tested version with a few last-minute changes popped in for whatever reason.
| hopsala wrote: |
| If WMB offers increased granularity of sub-environments (MF under EG), it should also offer the same granularity for security measures. This is a WMB limitation, not a feature. |
I do see the value of this. I do wonder how many sites would go to the time and trouble of setting this up. I offer into evidence the number of large sites (who should know better) who add all the app user ids into the mqm group, or use mqm into MCAUser.
| hopsala wrote: |
| I curious to know how other sites deal with this. There are, after all, regulations governing international banks which explicitly state you can't have two applications being able to read from the same queue. |
I'd be obliged if you could post a link so I can scare some people. I've worked at a large number of banks & other financial institutions that don't seem aware of this, and indeed it's the first time I've heard it. Where I've experienced something similar it's been described as the segrigation of data according to application use; it's never been as explicit as what access is permitted on a given technical object. How does this translate into database access, where multiple applications access different columns? Presumably this regulation would require each application to use a specific view for access, and I've not seen that enforced either.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 24, 2009 12:23 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Sir Jeff:
In a perfect world, deployers are admins, competent programmers and security experts. In the real world - that is, in each and every client I've seen without exception - deployers have skills similar to most QA people. They can sit down with the programmer and review the code, but they can't really make out head or tail by themselves. Sure, there's a review, but it's very easy for a sufficiently clever programmer to sneak in a few extra obfuscated lines into a seemingly innocent java node.
If a flow ran under an EG with access only to its intended queues, files and databases, security would be a breeze, as potential damage will be reduced to a minimum. The only possible attack would be something like back doors and data manipulations. But only programmers who are authorized to work on restricted data would even have the chance to access it.
But all this doesn't really refute what you said. Sure, you need a review process. The point is that the product should supply security granular enough to secure the environment, just like WAS does, or any other product for that matter. You said it yourself, processes shouldn't run as root. And the broker user is tantamount to root, in an MQ world.
Another angle would be the simple fact that this has caused clients to use a broker-per-application scheme. So that question is, does IBM wish to continue making money out of these extra licenses and the increased headache of their clientelle, or be nice and give the clients what they so desperately need? 
Mr. Vitor:
Much of my answer to jeff is relevant to what you wrote. As for the universal "Oh heck, just give it admin auth and be done with it. We'll deal with it later" attitude, I am well acquainted with it. And you know what they say - later never comes..
Concerning the bank regulations: I am familiar with local regulations here in Israel concerning stock exchange transactions, prohibiting anyone from having access to the queues other than the protocol-management application. This translates into more than one broker on the DMZ server. I have also seen a number of cases in which an external provider, such as another bank, refused to connect to another bank's broker if it is not a dedicated one, due to the above reasons.
Anyway, I'll look into it and hopefully get back to ya with a few links or additional info. No promises though. |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 24, 2009 12:30 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
So, bottom line, the answer to my question is:
No, it's still broker userid for all flows in V7.
Right?
Are there any plans to change this in the near future? Who do I need to sleep with to get this implemented? Any female IBM managers out there with a yen for young, dashing SOA consultants? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Oct 24, 2009 2:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| hopsala wrote: |
| Another angle would be the simple fact that this has caused clients to use a broker-per-application scheme. So that question is, does IBM wish to continue making money out of these extra licenses and the increased headache of their clientelle, or be nice and give the clients what they so desperately need? |
It really depends on where you put the borders.
If you consider the broker as a black box and each flow separately, I am sure you can guarantee after deployment that the flow is only picking up messages from a particular queue. You have flow and code reviews so you know what the flow is doing. If the flow has queue output, I am sure you can secure that queue so that only the intended consumer application gets the messages.....
It's all about the point of view...
Yes you can go to extremes and have a distinct qmgr / broker for specific stuff... and it is no different with products from the competition.... AFAIK.
As jeff said, you could use a JMSnode instead of an MQInput node and not have the message transit through the broker's qmgr at all. But you will take into account the hit in performance...
In the most paranoiac sense you can have everything be hand processed.
But then how much do you trust the processing staff...
You can also bring the process to a complete stop...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Oct 24, 2009 2:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hopsala wrote: |
| In a perfect world, deployers are admins, competent programmers and security experts. |
You and I have very different definitions of perfect! In my perfect world, deployers are actually a blind, automated process than runs after the competent programmers, QA people, system testers and architects have all signed off on the code & the guy who owns the prod env has agreed the deployment time slot.
| hopsala wrote: |
| In the real world - that is, in each and every client I've seen without exception - deployers have skills similar to most QA people. They can sit down with the programmer and review the code, but they can't really make out head or tail by themselves. Sure, there's a review, but it's very easy for a sufficiently clever programmer to sneak in a few extra obfuscated lines into a seemingly innocent java node. |
In my real world (and resisting the oppertunity to take another dig at the use of Java in WMB - ESQL rules ok?) the deployer is not expected to review the code, & only reviews the documentation supporting the deployment request. This includes whatever the site has determined is a proper sign-off on review and testing by people who understand such things. Live example - my last site had code go through peer review, system test, user test, regession test and random external review (the frequency of the review was random, not the quality!) before being submitted to the prod team for deployment.
| hopsala wrote: |
| If a flow ran under an EG with access only to its intended queues, files and databases, security would be a breeze, as potential damage will be reduced to a minimum. The only possible attack would be something like back doors and data manipulations. But only programmers who are authorized to work on restricted data would even have the chance to access it. |
I repeat my comments on the average site going to this much trouble. Security tends to be a wall round prod, not a guard patrolling within it.
| hopsala wrote: |
| Concerning the bank regulations: I am familiar with local regulations here in Israel concerning stock exchange transactions, prohibiting anyone from having access to the queues other than the protocol-management application. This translates into more than one broker on the DMZ server. I have also seen a number of cases in which an external provider, such as another bank, refused to connect to another bank's broker if it is not a dedicated one, due to the above reasons. |
My experience is more European but I still find it odd that financial regulations would go down to a technical level like this. I've reviewed some docs my end and the technical stuff is concerned with SSL, encryption of data, that sort of thing rather than held where and encrypted how.
Interesting.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Oct 24, 2009 2:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| hopsala wrote: |
| This translates into more than one broker on the DMZ server |
This is an architectural decision.
I would question, why have any broker in the DMZ?
It's OK to have stuff like MQIPT or qmgrs in the DMZ but why would an enterprise like to put a Message broker, or even an MQ broker into the DMZ?
You usually have only entrypoints such as http servers, network devices and such in the DMZ. Application and DB stuff is usually at least 1 firewall removed from the DMZ. Credit card and other sensitive stuff is usually at least 2 firewalls removed from the DMZ...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Oct 24, 2009 2:56 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Whether many people would use it or not is kinda irrelevant. Without disagreeing with what anyone has said, I think its a valid need to be able to have an EG run under a unique admin assigned User Id.
This is very similar to SVRCONN channels (Execution Groups) and MQ Clients (Message Flows). Imagine if every channel ran as mqm! Sure, we could secure them by SSL and review the code that was being deployed that used those channels, but we all agree (right?) that it would be insane not to allow Channel A to run under a differnt ID when compared to Channel B.
_________________
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
|
|
|
|
