Protecting Message Data by Implementing MQ AMS End to End Message Security Introduction: Key Concepts MQ AMS augments IBM MQ security by providing data protection of messages. Three “Qualities of Protection” (QOP) are provided: Integrity (signed) IBM MQ messages are signed when put on a queue and the signature embedded into the message is verified when the message is retrieved. The signature identifies the sender of the message and ensures that the content of the message has not been changed. MQ AMS uses PKCS #7 data-envelope to envelop a message in a digital signature. Privacy (sealed) IBM MQ messages are signed as above but the content of the message is also encrypted. The key used to encrypt messages is itself encrypted for each potential recipient so that the messages can be retrieved by one or more recipients. MQ AMS uses PKCS #7 data-envelope to envelop a message in a digital signature. Confidentiality (encrypted only) IBM MQ messages are encrypted end-to-end using a symmetric key and are not digitally signed. This reduces the amount of asymmetric key operations by half and improves performance. Optionally the encryption keys can be reused for multiple messages going to the same recipient. The second and subsequent messages incur no asymmetric key operations which keeps performance similar to plaintext/unprotected message throughput. Data protection is provided by various interceptors relying on configuration files, PKI keystores and certificates. This is in addition to the standard protection available for IBM MQ objects using the IBM MQ Object Authority Manager (OAM) or SAF (via a product such as IBM’s RACF) on z/OS. The diagram below depicts the overall architecture: Interceptors MQ AMS implements security by intercepting IBM MQ API calls. The following APIs are supported: • Message Queue Interface (MQI) • Java Message Service (JMS) • IBM MQ Java Service (JMS) • IBM MQ Java Classes Three interceptors are provided: • IBM MQ server interceptor To protect messages put or get by applications using the mqm library and using the interprocess communication (IPC), also called bindings mode. This interceptor will also protect messages for Java applications (either using the MQ Java API or JMS) connecting in MQ bindings mode. • IBM MQ C client interceptor To protect messages put or get by applications using the mqm client library and therefore connecting using a (non-Java) MQ client connection. • IBM MQ Java interceptor (JMS and MQ Java) To protect messages put or get by Java applications (MQ Java API or JMS) using either client connections or bindings mode. Note that if you use this interceptor for applications using Java bindings mode, you should consider disabling the server interceptor to avoid signing/encrypting messages twice. Public Key Infrastructure (PKI) and Certificates MQ AMS uses Public Key Infrastructure (PKI) identities to represent users or applications. The identities are used to sign and encrypt messages. An identity is represented by the distinguished name (DN) of a personal X.509 (v2/v3) certificate associated with the signed and/or encrypted message. To authenticate this authority, the user or application must have access to a keystore containing a public certificate and an associated private key. A mechanism is provided to map the OS identity of the user or application to the specific keystore file. Object Authority Manager (OAM) MQ AMS provides message security. It does not provide authorization services for IBM MQ objects. The task to authorize access to IBM MQ resources (queue manager, queues and other objects) remains the responsibility of the IBM MQ Object Authority Manager (OAM) or RACF (or other SAF) on z/OS. When an interceptor intercepts the MQ API calls from an application, it delegates the authorization request to the IBM MQ authority service. Error Handling MQ AMS defines an error handling queue (SYSTEM.PROTECTION.ERROR.QUEUE) to manage messages that contain errors or messages that cannot be decrypted. If a received message does not meet the security requirements for the queue it is on, then the message is moved to the error handling queue. The following is a non-exclusive list of possible reasons why a message might be sent to the error handling queue: • Quality of protection mismatch • Decryption error • PDMQ header error • Size mismatch • Encryption algorithm strength mismatch • Unknown error The system error handling queue can optionally be defined as an alias queue pointing to another queue. The Objective of this lab is to demonstrate the simultaneous implementation of IBM® MQ Security features like OAM, SSL, AMS & CHLAUTH in an Integrated Test Case Scenario which can be taken as a template for Large Scale Implementation at Enterprise Level. The specific configuration of Advanced Message Security (AMS) feature is required to meet the regulatory requirement of PCI DSS (Payment Card Industry Data Security Standard) which mandates business critial information like Credit / Debit Cards & other important Bank transactions to be secured & encrypted. The above diagram depicts our Test Case Scenario at High Level As per the above diagram, Application user Alice puts a messages through SSL/TLS enabled Client Connection Channel into an AMS enabled Cluster Queue Alias (AMS_A) defined under TEST1 Qmgr. This Q Alias points to AMS enabled Cluster Local Queue (AMS_E) defined under TEST2 Qmgr through a secure Cluster Channel. Once the business critical message(s) reaches Q Local (AMS_E), it will be encrypted using pre- defined AMS rules set at the Queue Level. Only authorized Application user Bob should be able to retrieve the the data from the Queue (AMS_E). Going by this configuration, even ‘mqm’ or ‘root’ user does Not have the default authority to read / browse the message from Queue (AMS_E) without setting explicit AMS security rules! Hence, highly sensitive Customer data like Credit / Debit Card information is secured from the point it originates from Application user Alice till it is consumed by Application user Bob from the other end of the secure MQ network. From Implementation Perspective, we have created & configured the following components: 1. Created a MQ Cluster called ‘POC’ having 3 Qmgrs TEST(1,2,3) where TEST(1,2) are Full Repository (FR) Qmgrs & TEST3 is the Partial Repository(PR) Qmgr. 2. Created an Internal Certificate Authority (CA) for signing Certificate Requests for MQ Clients & Cluster Qmgrs. 3. Configured SSL/TLS at Cluster Channels using in-house Certificate Authority (CA) 4. Created a dedicated Queue Manager CCDT for Administration & Maintenance of Client Connection Channel file (CCDT) called AMQCLCHL.TAB. 5. Configured MQ Clients (Alice & Bob) connectivity with Qmgrs using CCDT. 6. Configured Channel Authentication (CHLAUTH) rules to Allow / Block incoming requests from MQ Client users Alice & Bob. 7. Created & Configured have 2 AMS enabled Cluster Queues AMS_A (QA) defined under TEST1 & AMS_E (QL) define under TEST2 Qmgrs respectively. 8. AMS Keystores are created using Self-Signed Certificates of Alice & Bob. With these Security Configurations in place, this Test Case demonstrate a comprehensive security solution by making use of most of the built-in IBM MQ Security features like OAM, SSL/TLS, CHLAUTH & AMS to achieve End to End Message Security Solution which includes Authentication, Authorization, Encryption & Digital Signature. Thus, MQ messages are secured while in transit through SSL/TLS enabled MQ Channels as well as while sitting in the AMS enabled Local Queue before being processed by receiving Application. Step-by-step 1. MQ Configuration Items This entire article on IBM MQ Security Solution can be broken down into 4 Major parts: 1. Creation & Configuration of MQ Cluster with SSL/TLS Enabled Channels. 2. Configuration of SSL/TLS enabled MQ Client Connectivity with Cluster Queue Managers using CCDT file AMQCLCHL.TAB. 3. Setting up the CHLAUTH rules at Channel Level for enhanced Security. 4. Implementation of AMS Security Rules at Queue Level. #################################### Internal Certificate Authority (CA): /home/mqm/CA TEST1 Qmgr’s SSL Keystore: /var/mqm/qmgrs/TEST1/ssl TEST2 Qmgr’s SSL Keystore: /var/mqm/qmgrs/TEST2/ssl TEST3 Qmgr’s SSL Keystore: /var/mqm/qmgrs/TEST3/ssl Alice’s home directory: /home/alice/ Alice’s SSL Keystore: /home/alice/keystore Bob’s home directory: /home/bob Bob’s SSL Keystore: /home/bob/keystore CCDT File: /home/CCDT/AMQCLCHL.TAB ==> Centralized Location to be used by both Alice & Bob CCDT File Administration: /var/mqm/qmgrs/CCDT/@ipcc/AMQCLCHL.TAB ##################################################### 2. Define Queue Managers This is the first part of the exercise wherein we are going to create 3 Qmgrs & define the Listener Process for each. Create TEST1 Qmgr ################# crtmqm TEST1 Strmqm TEST1 Runmqsc TEST1 DEFINE LISTENER(TEST1.LISTENER) TRPTYPE(TCP) PORT(1417) CONTROL(QMGR) end Create TEST2 Qmgr ################# crtmqm TEST2 DEFINE LISTENER(TEST2.LISTENER) TRPTYPE(TCP) PORT(1415) CONTROL(QMGR) Create TEST3 Qmgr ################# crtmqm TEST3 DEFINE LISTENER(TEST3.LISTENER) TRPTYPE(TCP) PORT(1416) CONTROL(QMGR) Checkpoint Test: You can Stop / Start the Queue Managers and listeners via the commands or through the MQ Explorer; verify if the Listener Programs are running using the command: ps -ef | grep runmqlsr Observation: 3. Create a MQ Cluster In this Section, we are going to create a Cluster called POC & make 3 Qmgrs part of the Cluster. Configured TEST1 & TEST2 as the Full Repository (FR) & TEST3 as the Partial