Access management in MQ environments to ensure data security

Ensuring data security through access control and management in MQ environments are the main reason why our partner Avada has developed the unique Trusted Spaces™ functionality in Infrared360®. Should administrators, engineers, developers, helpdesk agents, and managers all have the same visibility and type of access to the enterprisemessaging and integrationinfrastructure? According to Gartner, no, and we couldn’t agree more.

Let’s face it: there are situations where someone other than theMQ administrator needs to gain visibility oraccess to a queue, the Qmgr command, or even a message in a queue.

An application team manager claims that the support team has reported a problem with a production transaction for the application, but the message is not being processed.

Before they ask you to remove it or change it, they necessarily have to look at it, because only they know what the transaction content, format, character set, etc. should contain. They don’t want the situation to escalate into an SEV2 incident, so they ask you to drop everything you are doing and become a forensic investigator right away.

An application developer needs to test the new application to make sure that it takes messages from one queue, processes them, and the broker application correctly transforms them and places them in another outgoing queue. It is necessary to verify that the original message exits, is found in the application’s input queue, and then is displayed in a new way in the broker’s output queue. Also, once this is done, you will want to automate the sending of transactions in this stream.

Because these situations, and many others like them, not only exist but are quite common, identity and access management for MQ environments is critical.

That’s why Avada created Infrared360®: to make life easier for MQ administrators. The Trusted Spaces™ feature allows users to see and work only in their areas of expertise and promotes more secure collaboration between departments, teams, locations and partners. This powerful feature allows or restricts visibility of objects such as queues, topics, consumers, channels, applications, flows and other integration-type server resources based on user permissions or role.

Users can be assigned visibility only to objects in their middleware environments for which they have access. This can be extremely granular, down to individual message types on specific queues.