| Author |
Message
|
| erkusch |
 Posted: Fri Mar 16, 2007 8:56 am Post subject: Which precautions against application adminstrators abuses? |
 |
|
Newbie
Joined: 16 Mar 2007
Posts: 2
|
Hi,
I know it's not strictly related to MQ, but in my case I have an application which submits data to an MQ queue with a "tecnhical userID".
I wonder if someone here has experience in minimizing risks that the application administrator uses this userID to submit fake messages/data.
Thanks a lot and sorry if I'm off topic.
Bye
g.ame |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Fri Mar 16, 2007 9:04 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Mon Mar 19, 2007 12:07 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| RogerLacroix wrote: |
Hi,
You need to beef up the MQ Security use are using.
If you want proper security for MQ then you have 4 choices:
1. Capitalware's MQ Standard Security Exit
2. Capitalware's MQ Authenticate User Security Exit (heavy-duty security)
3. IBM's WebSphere MQ Extended Security Edition V6
4. Primeur's Data Secure for WebSphere MQ
Regards,
Roger Lacroix
Capitalware Inc. |
And additionally:
- SSH (on Unix)
- SSL (to restrict access to the channels and / or system)
- OAM to restrict a (e. g. via SSL authenticated user) access to queues.
If a user is allowed, to login to your technical user ID (because she/he knows the password) any security tool will be quite useless  .
_________________
Regards
Hubert |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Mar 19, 2007 3:12 am Post subject: Re: Which precautions against application adminstrators abus |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| erkusch wrote: |
Hi,
I know it's not strictly related to MQ, but in my case I have an application which submits data to an MQ queue with a "tecnhical userID".
I wonder if someone here has experience in minimizing risks that the application administrator uses this userID to submit fake messages/data.
Thanks a lot and sorry if I'm off topic.
Bye
g.ame |
If you don't trust your admins to do the right thing I believe you have little to no recourse. The essence of admin is to have the rights you try to deny.... There is no foolproof way.... and especially no guard against malicious intent from an admin... but to revoke all his admin priviledges...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 19, 2007 3:24 am Post subject: Re: Which precautions against application adminstrators abus |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| erkusch wrote: |
| I know it's not strictly related to MQ, but in my case I have an application which submits data to an MQ queue with a "tecnhical userID". |
There is of course no reason why a "technical userID" has to have adminstrative rights, just the rights needed to perform it's function.
The problem with securing administrators is that typically they're responsible for administering the security. It's a bit like stopping the security guards in a building performing unauthorised activities. You can rapidly spiral into a "who watches the watchers" situation.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Mar 19, 2007 2:35 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| HubertKleinmanns wrote: |
| - OAM to restrict a (e. g. via SSL authenticated user) access to queues. |
SSL is a node to node security mechanism and to my knowledge cannot authenticate a user. Therefore, you may use SSL between 2 nodes for security but there is no guarantee that the UserId that the user is asserting is actually their UserId (or a UserId that they are allowed to be using).
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Mar 19, 2007 2:42 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
SSL on channels (in conjunction with OAM) provides role-based security , and not user-based security.
OAM on Unix doesn't provide user-based security, either - everything is done by group.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Mon Mar 19, 2007 11:33 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| RogerLacroix wrote: |
| HubertKleinmanns wrote: |
| - OAM to restrict a (e. g. via SSL authenticated user) access to queues. |
SSL is a node to node security mechanism and to my knowledge cannot authenticate a user. Therefore, you may use SSL between 2 nodes for security but there is no guarantee that the UserId that the user is asserting is actually their UserId (or a UserId that they are allowed to be using).
Regards,
Roger Lacroix |
Roger,
you may use SSH, which is SSL based, to authenticate a user on a system.
Another situation, where SSL may be used, to authenticate a user, are MQI channels (e. g. together with MQ Visual Edit or MQMON). Then the username should be part of the SSL certificate and checked via the SSLPEER attribute.
But you are right, these mechanism is as secure as the key store itself (and password authentication is as secure as the password itself  ). To be more secure, you should combine SSL with an exit - which for examples asks for a password (and possibly with biometric mechanisms like finger prints etc.  ).
Some days ago I read a message, that the only secure system has no connections, is put somewhere on the bottom of the ocean and the only person, who knows the location, died  .
_________________
Regards
Hubert |
|
| Back to top |
|
|
| erkusch |
| Posted: Wed Mar 21, 2007 2:34 am Post subject: |
|
|
Newbie
Joined: 16 Mar 2007
Posts: 2
|
Thanks a lot for your preciuos comments.
I agree that this is quite an impossible task, but all your inputs are really interesting.
If I'll come up with some smart solution, I'll let you know.
Bye. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 21, 2007 6:03 am Post subject: |
|
|
Guest
|
Back to the original post... have you added the 'technical user' to the MQM group to run the application? Is that what you mean?
If so, take him/her out of MQM; then use setmqaut (see System Admin Guide) to permit only the access that the user really needs. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 21, 2007 6:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
Back to the original post... have you added the 'technical user' to the MQM group to run the application? Is that what you mean?
If so, take him/her out of MQM; then use setmqaut (see System Admin Guide) to permit only the access that the user really needs. |
Sort of what I was getting at...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
