Compartmentalization and AMQP Infrastructures

In order to deploy a secure message-driven distributed system the components should have very specific, narrowly defined roles. This is a extension of security best practices like least privilege and single-purpose systems.

The purpose in a single-purpose system should be as narrow as is practical. The narrower it is, the less privileges required, and the much easier it becomes to define expected behavior.

The security impact of being able to narrowly define expected behavior is extremely significant. It makes the deployment of Host Intrusion Prevention Systems (HIPS) easier and their alerting more effective. By contrast, a very loosely defined, dynamic component would be difficult to secure even with behavioral intrusion analytics deployed. The reason is simple: if normal can't be defined then everything looks normal (no alerts, attacks go unnoticed) or everything looks anomalous (false alerts, SOC staff fatigued).

Defense in depth requires segmentation. An obvious interpretation of this is putting firewalls in place and having a DMZ separating external systems and internal systems. A much more advanced version of this is service-level RBAC assigning least privilege rights to each component. Somewhere in the middle is a partial implementation where certain aspects of a system use RBAC and others have fairly broad rights.

In practice I've seen the middle ground deployed. Firewalls and DMZs are used consistently. RBAC is used to limit privileges for external services. However, the rights of services to use other services within the internal system is either implicitly limited or not limited at all.

A specific scenario along these lines is access to AMQP exchanges, queues, and topics. AMQP is a protocol for brokered messaging that can form a useful component in distributed asynchronous systems similar to how HTTP fits that role for distributed synchronous systems. A server implementation of AMQP is RabbitMQ. It allows RBAC at the level of these AMQP concepts. In practice I have seen coarse grained roles assigned to components of a distributed system. These roles limit what a single component can consume or publish. However, the generality of the components leads to diffuse responsibility and challenges in assigning least privilege.

By leveraging the vhost, exchange, queue, and topic ACLs in RabbitMQ an effective RBAC regime can be extended to your messaging infrastructure. Doing this is worthwhile because it builds on existing effort expended to deploy RBAC at the Cloud API and OS levels to deliver a comprehensive least privilege system that lets people work while containing risk.