| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Audit of changes to mq objects |
« View previous topic :: View next topic » |
| Author |
Message
|
| exerk |
 Posted: Wed Dec 23, 2009 1:43 am Post subject: |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| exerk wrote: |
| Michael Dag wrote: |
...yes but as mqm you can turn these events off and later on or remove the messages from the config event queue without anyone knowing...
so the question is how can you make changes without being mqm or having mqm (group) authority so you can't alter the config event notification or remove the messages from the queue...
IMHO this is a painted lock on the door... but please proof me wrong... |
I would expect that the sudden 'loss' of events from a particular queue manager, as noted by the monitoring software being used, would be an indication. That or centralise the queue somewhere else, i.e. redefine as a QR to a collector queue manager somewhere. |
There may be no loss of event messages. Turn off config events, make your bad boy changes, turn config events back on. No config event for your naughty change.
BUT, I think turning config events on and off generates config messages.
BUT, you could intercept those and delete them. 
I guess there's a way around everything if you have super user access, just like if you have root access you can get around stuff. There is a certain level of trust that comes with having mqm (or mqm level access) or root. |
I'm a great believer in only using the mqm account as a service account, i.e. no user should be able to su to it, and I should never need root either. I prefer additional accounts, each assigned to an admin and disabled depending on the level of site paranoia, which the admin has to log in and su to.
It still never ceases to amaze me that security departments will sanction giving out god-level log-in's and application userid's in the mqm group, but jealously guard the password for the one account I need most to do my job.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Wed Dec 23, 2009 2:08 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| PeterPotkay wrote: |
| exerk wrote: |
| Michael Dag wrote: |
...yes but as mqm you can turn these events off and later on or remove the messages from the config event queue without anyone knowing...
so the question is how can you make changes without being mqm or having mqm (group) authority so you can't alter the config event notification or remove the messages from the queue...
IMHO this is a painted lock on the door... but please proof me wrong... |
I would expect that the sudden 'loss' of events from a particular queue manager, as noted by the monitoring software being used, would be an indication. That or centralise the queue somewhere else, i.e. redefine as a QR to a collector queue manager somewhere. |
There may be no loss of event messages. Turn off config events, make your bad boy changes, turn config events back on. No config event for your naughty change.
BUT, I think turning config events on and off generates config messages.
BUT, you could intercept those and delete them.
I guess there's a way around everything if you have super user access, just like if you have root access you can get around stuff. There is a certain level of trust that comes with having mqm (or mqm level access) or root. |
I agree there should be a level of trust and yes as mqm you should be allowed to do your work, BUT
I still feel in this day and age changes should be auditable in a proper way, so there is no doubt about whether the mqm user/group was misused.
sending the messages off to somewhere else is one option to make it more difficult but what if you don't have 'another' place to send them to?
adding a sequence number to the messages would be another (so you can detect missing messages from the queue),
the best option that IMHO has always been around and still is is the MQ logs themselves, the logs can not be tampered with and a a 'simple' dmpmqcfglog could spit out configuration changes and security changes...
the security changes themselves are not part of the configuration events either...
I am playing devil's advocate here so don't get me wrong on my intentions 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Dec 23, 2009 2:15 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Pebble in the pond time...what would be really nice would be for config and security events to be on by default. It would be handy if an internal mechanism (tunable preferably) collated the messages and dumped them out to a log. Maybe one for the wish-list?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
