IBM MQ Advanced Message Security (AMS) has been available for several years now. AMS allows you to protect messages at rest, in-transit and in memory, while dataset encryption allows you to protect messages at rest, and TLS enabled channels allow you to protect messages in transit.
Originally, AMS provided Privacy (sign and encrypt) and Integrity (sign only) levels of protection. However, more recently, Confidentiality (encrypt only) has been provided as a more performant level of protection. For specific details about the performance of each type of protection, please refer to the MQ Performance reports available at: https://github.com/ibm-messaging/mqperf .
It is also worth noting that while AMS has to be enabled at the Queue Manager level, AMS protection can be enabled, without the need to make any application changes, by defining policies on a per-queue basis. This means that AMS protection can be limited to those queues that hold critical or high value data, rather than enabling it for all queues in your MQ environment.
Prior to IBM MQ V9.1.3, when sending messages to AMS protected queues across queue managers, the requirement has been that Queue Managers should be enabled for AMS and that AMS protection should be enabled for both the source and target queues. Consider the following example of a Clearing House that requires that messages in its MQ network are protected:
This means that for the Clearing House to exchange messages with a bank for example, policies need to be defined for the remote and target local queues:
However, it is highly likely that some banks or business partners do not support AMS:
So, it would be unreasonable for the Clearing House to send protected messages to them because they would not be able to understand them. Similarly, as the Clearing House requires that all messages in their MQ network are protected, it needs to ensure that any messages it receives from banks or business partners that do not support AMS, are somehow protected.
MQ for z/OS V9.1.3 introduced support for AMS interception on server to server message channels. This feature adds the SPLPROT (Security Policy Protection) attribute on Sender and Receiver type server to server channels to control whether message protection should be added or removed:
The following example shows that by setting SPLPROT(REMOVE) on the sender channel, the Clearing House can unprotect messages before sending to a bank that does not support AMS. Similarly, by setting SPLPROT(ASPOLICY) on the receiver channel, the Clearing House can ensure that any inbound unprotected messages are protected on receive:
Of course, additional policies would be required to achieve this as shown in the following examples:
In the above example, the policy defined for the remote queue is used to protect messages at rest in the Clearing House, and the policy defined for the transmission queue is used to remove protection from the message before sending to the bank which does not support AMS.
In the above example, the policy defined for the target local queue in the Clearing House is used to protected unprotected inbound messages from the bank and to unprotect messages when an application gets the messages.
Of course, suitable certificates also need to be defined for the above examples. The IBM MQ Knowledge Center documents additional AMS examples for IBM MQ for z/OS which list the RACF commands required to define suitable certificates. Refer to the folloing section for further details: https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q119340_.htm
For details of the performance impact of using IBM MQ for z/OS V9.1.3 AMS interception on server to server message channels, refer to: https://developer.ibm.com/messaging/2019/08/07/ibm-mq-for-z-os-v9-1-3-advanced-message-security-interception-on-server-to-server-message-channels/ .
Support for the SPLPROT attribute on distributed MQ platforms will be considered in the future.