Author |
Message
|
jeevan |
Posted: Thu Aug 20, 2009 2:58 pm Post subject: MQ/MQ security Best Practice |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
|
Back to top |
|
 |
gbaddeley |
Posted: Thu Aug 20, 2009 4:12 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
The level of MQ security practice depends strongly on your business requirements for security, so its not really possible to come up with a comprehensive list of all the MQ security options that should be applied in all cases. YMMV. However, there are a few basic things that should always be done to mitigate the anonymous remote administration capability that exists for out-of-the-box MQ.
http://t-rob.net/ is good food for thought. _________________ Glenn |
|
Back to top |
|
 |
jeevan |
Posted: Tue Aug 25, 2009 10:42 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
gbaddeley wrote: |
The level of MQ security practice depends strongly on your business requirements for security, so its not really possible to come up with a comprehensive list of all the MQ security options that should be applied in all cases. YMMV. However, there are a few basic things that should always be done to mitigate the anonymous remote administration capability that exists for out-of-the-box MQ.
http://t-rob.net/ is good food for thought. |
I asked this question because recently, I discovered that one of our qmgrs was accepting an app without an user id and so connecting as an ANONYMOUS. Also, when I went ahead and do more research, I figured out that there is a provision in Windows whether to allow an ANONYMOUS connection.
Had we restricted that, it would have compelled us to have an user for connecting to the queue manager. Which is much more better than not to have an user id at all.
Thanks |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Aug 25, 2009 12:07 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Briefly, very briefly:
A general (not specifically MQ) best-practice is to have work performed under the userid that requested the work. This implies authentication (username/password) and authorization (domain rules).
For MQ, access to MQ applications should be authorized, access to the MQI calls should be authorized, access to MQ objects (by intent - get/put, alternate userid, for example) should be authorized.
This becomes an issue (challenge, opportunity), as you've discoverd, when a message leaves the security domain where the application that created the message executed. This applies to client apps, and messages that leave across a point-to-point channel. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
RogerLacroix |
Posted: Wed Aug 26, 2009 6:39 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
jeevan wrote: |
Had we restricted that, it would have compelled us to have an user for connecting to the queue manager. Which is much more better than not to have an user id at all. |
That's not securing your queue manager, its simply turning a blind eye to the problem. If you have not implemented either SSL or a security exit then your queue manager is wide-open for anyone to do anything they want to.
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
Sam Uppu |
Posted: Thu Aug 27, 2009 6:41 am Post subject: |
|
|
 Yatiri
Joined: 11 Nov 2008 Posts: 610
|
We are not using SSL for the clients though security is a big concern in our shop. Wanted to know which is the best and easy to secure the client channels either security exits or SSL?.
Do we have any free security exits available from IBM?. I didn't really search on this one yet.
Thanks. |
|
Back to top |
|
 |
jeevan |
Posted: Thu Aug 27, 2009 8:13 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
Sam Uppu wrote: |
We are not using SSL for the clients though security is a big concern in our shop. Wanted to know which is the best and easy to secure the client channels either security exits or SSL?.
Do we have any free security exits available from IBM?. I didn't really search on this one yet.
Thanks. |
Secure Sockets Layer (SSL) is a protocol designed to allow the transmission of secure data over an insecure network while exit are piece of code. SSL provides:
integrity
confidentiality
while exit work for encryption of data while transmissting data between two queue managers.
The channel security exits usually work in pairs.
I am sure more will come from experts. |
|
Back to top |
|
 |
crossland |
Posted: Fri Oct 02, 2009 2:37 am Post subject: |
|
|
Master
Joined: 26 Jun 2001 Posts: 248
|
Sam Uppu wrote: |
We are not using SSL for the clients though security is a big concern in our shop. Wanted to know which is the best and easy to secure the client channels either security exits or SSL?.
Do we have any free security exits available from IBM?. I didn't really search on this one yet.
Thanks. |
To do it properly, SSL is going to require a bit of work, with implementing certificate management etc. However, once this is done you are likely to end up with a solution that produces a good level of authentication and (if required) encryption, provided it is done properly.
Writing your own exit is not a trivial task, especially if you are going to try and have an equivalent level of security to that provided by SSL. And you will then have the ongoing support of this exit going forward. |
|
Back to top |
|
 |
|