| Author |
Message
|
| meaton78 |
 Posted: Mon Sep 27, 2010 5:55 pm Post subject: Alter access to allow only one user to put clustered queue |
 |
|
Centurion
Joined: 16 Oct 2008
Posts: 100
|
I have looked around here and in the manual and haven't found a real great explanation on this topic. We have some brokers that host multiple cluster queues for cluster A. Application B resides on a remote server/qmgr and puts to the clustered queues. We would like to restrict access to one of the clustered queues so that only user C can put to that queue (I'll call it QD).
On the brokers that host the queue, we have ssl and a mcauser set on the clusrcvr channel, so the mcauser obviously has to access to the queue on that end. On the remote end where the application resides, I tried something from the InfoCenter, where I created QA(QD) TARGQ(QD). I then tried to do setmqaut -m QMGR -g TEST -n 'QD' -t queue -all + none but I was still able to put to the queues. I'm guessing that I was bypassing the local QA and hitting the clustered queues directly.
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzah.doc/qc11430_.htm
Is there some eloquent way that I am missing that I could use to do this? I was thinking I might somehow be able to use an mcauser on the cluster sender channel, but I have never done that before and am not sure how the authorization works that way. Thanks for any help or pointers. This one is driving me mad.
We are running MQ 6.0.2.8 on AIX if that matters. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Sep 27, 2010 7:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You need an mcauser that has no priviledges to the SystemClusterTransmitQueue (SCTQ). Then you need an authorized queue remote, defined locally, that will resolve to the cluster queue (difference with queue alias is that you can do a put when the destination is not available, the message will go to the DLQ).
Have fun. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 28, 2010 1:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So the MCAUSER on the CLUSRCVR is only active once the message passes down the cluster channel.
As FJ says, you need to stop the application from being able to write directly to SCTQ.
But you need to make sure you know what user is in effect for the connection to the local qmgr.... That's *not* the MCAUSER on the clusrcvr. It's whatever MCUASER is set on your clntconn/svrconn or whatever local user is running your code on a bindings connection (with caveats, alas). |
|
| Back to top |
|
|
| meaton78 |
| Posted: Tue Sep 28, 2010 7:25 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 100
|
If I created a QR named QD pointing to the cluster queue, would all local traffic on the application box be forced to use that queue and not the cluster queue of the same name?
The piece I am having trouble with is this. Say we have 10 clustered queues. I want mqm to be able to put to 9 of them for testing purposes since they are inquiry only. The 10th queue is for transactions that we are not able to test since they make actual system changes. I also want the application, which puts messages as user 'app' to also be able to put to all 10 of the clustered queues. Then, in theory, with the proper monitoring, I should be able to say that there has been a breach if someone not authorized logged on as app and put a message to the secured queue. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Sep 28, 2010 7:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
So, you are testing in production??
_________________
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 |
|
|
| meaton78 |
| Posted: Tue Sep 28, 2010 7:37 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 100
|
| bruce2359 wrote: |
| So, you are testing in production?? |
Absolutely. Once I have done an MQ or WAS upgrade I'd prefer to know that it is working properly. We probably have more testing regions than most, but that doesn't mean that I can guarantee an upgrade in Prod has worked simply because it did in dev... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Sep 28, 2010 7:47 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Uh....
So, you have no QA environment for doing pre-production testing?
_________________
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 |
|
|
| meaton78 |
| Posted: Tue Sep 28, 2010 7:50 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 100
|
| Of course we do. Do you not validate your upgrades after you have completed them in Prod? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Sep 28, 2010 8:00 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Do you not validate your upgrades after you have completed them in Prod? |
End-users validate first in QA - often with real production data; then end-users do production work in prod.
I guess I'm wondering how testing in prod passes any audit...
_________________
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 |
|
|
| Vitor |
| Posted: Tue Sep 28, 2010 8:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| I guess I'm wondering how testing in prod passes any audit... |
With proper controls to ensure that either no data escapes during the testing window or it's captured by other systems which are using the same window to test their production environments, with a restore back to a known point after you're done.
It's not just this sort of thing, but also security & connectivity testing typically has to be done in situ. Takes months of meeting to plan & organize but it's not uncommon.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Sep 28, 2010 8:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
| bruce2359 wrote: |
| I guess I'm wondering how testing in prod passes any audit... |
With proper controls to ensure that either no data escapes during the testing window or it's captured by other systems which are using the same window to test their production environments, with a restore back to a known point after you're done.
It's not just this sort of thing, but also security & connectivity testing typically has to be done in situ. Takes months of meeting to plan & organize but it's not uncommon. |
Sure but wouldn't you have tested this out in Qual first, to make sure that the concept and the authorizations work, and then tested in prod once installed according to the configuration that worked in Qual, modified as needed for prod?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Sep 28, 2010 8:18 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I'd guess that there is little/no demarcation between QA and PROD; and that QA procedures are lack sufficient rigor to validate what is headed for PROD; and that the procedures for percolating QA to PROD are lacking.
I doubt this would pass internal audit or Soxley...
_________________
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 |
|
|
| Vitor |
| Posted: Wed Sep 29, 2010 4:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| Sure but wouldn't you have tested this out in Qual first, to make sure that the concept and the authorizations work, and then tested in prod once installed according to the configuration that worked in Qual, modified as needed for prod? |
Sometimes and under ideal conditions but sometimes for operational reasons QA & PROD differ. Often they don't have the same security & network set up just because of how they're used or where they're hosted.
Strange yet true.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 29, 2010 4:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| I'd guess that there is little/no demarcation between QA and PROD; |
Nope
| bruce2359 wrote: |
| and that QA procedures are lack sufficient rigor to validate what is headed for PROD; |
Nope
| bruce2359 wrote: |
| and that the procedures for percolating QA to PROD are lacking. |
Nope.
(I have a couple of specific clients in mind with those nopes).
| bruce2359 wrote: |
| I doubt this would pass internal audit or Soxley... |
It does. My knowledge of Soxley is about the same as my knowledge of the surface of the Moon (I can recognise it & talk in general terms) but auditors never seem to mind as long as the agreed procedures I mention above are followed and that the following of the procedures can be proved.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 29, 2010 6:23 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I've seen a few shops where the lines between TEST, QA and PROD, were blurred; and where there were different apps, different security, different whatever.
When I've had the opportunity, I've required that QA be pre-PROD, not a test-PROD. QA, when certified prod-ready by end-users and auditors, is cloned into PROD.
I shall consider myself fortunate that I've worked mostly in shops with clear delineation between TEST, QA, and PROD.
Maybe an ALMOST-PROD is necessary to do any last minute testing.
_________________
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 |
|
|
|
|
