Subscription security is the operational and access-control discipline around DEFINE SUB objects, dynamic MQI and JMS subscriptions, and the destination queues that receive publication copies. Topic SUB authority decides who may register interest; subscription security goes further—which DEST names are allowed, whether durable subs survive credential rotation, who may DISPLAY or DELETE subscriptions, and how you detect a shadow subscription copying hr/salary/# to an unapproved queue. Incidents in mature estates often start with an old test subscription left on a production queue manager, not with broken TLS. This tutorial covers administrative versus application-created subs, DEST queue hardening, SUBUSER considerations, managed queue authority after auto-create, cluster SUBSCOPE exposure, audit runbooks, and pairing subscription reviews with topic ACL exports.
An identity with +sub on a broad pattern and +get on a queue they control receives every matching publication automatically—no need to hack the publisher. A developer who keeps DURSUB(YES) on a test TOPICSTR pointing at prod-like patterns after go-live continues receiving regulated data. Multiple applications sharing one DEST without coordination leak messages between teams. Cluster SUBSCOPE(ALL) multiplies interest across sites—attack surface grows with repository visibility.
| Control | Protects against | Implementation |
|---|---|---|
| Narrow +sub | Unauthorized interest registration | Topic ACL at entity branch not prod/# |
| Approved DEST list | Copy to rogue queue | Queue OAM only on named QLOCAL prefixes |
| Admin-only DEFINE SUB | MQSC subscription sprawl | Restrict crt on SUB objects if supported |
| DISPLAY SUB audits | Shadow and stale subs | Weekly automation compare to CMDB |
| Separate service IDs | Shared credential abuse | One MCAUSER per consumer app |
1234567* Approved pattern - operations pipeline only DEFINE SUB('FIN.REPORTING.SUB') TOPICSTR('prod/finance/report/#') + DESTQL('FIN.REPORTING.Q') DESTTYPE(UNMANAGED) DURSUB(YES) + SUBSCOPE(QMGR) DESCR('Approved reporting consumer') setmqaut -m QM1 -t topic -n 'prod/finance/report/#' -p MQ.REPORT +sub setmqaut -m QM1 -n FIN.REPORTING.Q -p MQ.REPORT +get +dsp * Developers lack +sub on prod/finance/report/#
Store DEFINE SUB in Git; peer review TOPICSTR and DESTQL like application code. DELETE SUB in decommission runbooks before removing applications. REPLACE on redeploy should not accidentally widen TOPICSTR to # without architecture approval.
Runtime-created subs inherit the connection identity. Lock down SVRCONN MCAUSER mapping so microservices cannot connect as a shared power user with wide SUB. JMS durable subscriber client ID and subscription name conventions help audits—document expected DISPLAY SUB rows per deploy. After penetration tests, scan for subs pointing to unexpected DESTQL names containing EXFIL, TEMP, or personal user IDs.
Durable subs persist after application disconnect—security exposure persists too. Offboard employees by removing SUB authority and DELETE SUB objects they owned, not only disabling LDAP login. Rotate MCAUSER passwords and certificates on schedule; verify old durable subs are not still bound to retired identities via SUBUSER attributes on your platform.
When DEST is auto-created, grant +get immediately after first DISPLAY SUB in deploy pipeline. Managed queue names are unpredictable—automate dspmqaut from captured DESTQL. Do not leave default deny while production traffic accumulates unprocessed on inaccessible queues.
Subscription security is controlling who may sign up (SUB), which address (DEST) deliveries are allowed to go to, and who may open that mailbox (+get)—not just whether the newspaper may be printed (PUB).
You check who is allowed to ask for dinosaur magazines and make sure the magazines only go to mailboxes you trust—not a stranger’s box across town.
Write audit steps using DISPLAY SUB after new microservice deploy.
Describe shadow subscription exfiltration and three defenses.
Why separate SUB and GET grants for consumers?
1. Shadow subscription risk needs:
2. Audit tool for subs is:
3. Consumer needs on DEST:
4. Restrict DEFINE SUB on prod by: