Apples and Oranges: Security

Every messaging systems offers a different approach and trade offs for security, authentication and permissions.

This is the last of six articles in the series comparing stormmq and Amazon SQS.

Every messaging systems offers a different approach and trade offs for security, authentication and permissions.

Ultimately, the choice of what’s needed dictates what’s right.

Security covers three main areas:‐

Amazon SQS and stormmq both use TLS to securely authenticate connections and transport message data encrypted to and fro. Importantly, stormmq is secure by default; you can not disable TLS, whereas, with some versions of Amazon SQS, you can use HTTP for a faster response. With stormmq, that’s not needed – we can deliver more than 10,000 messages a second, with TLS. However, the initial stages of TLS are plain, and reveal information about the client that might be best kept secret. For the very security conscious, we offer IPSec VPNs to those clients that request them – or we can even run our endpoints inside your data centre (a hybrid cloud model). However, to maintain the privacy of your messages, we go much further

At stormmq, we take the view that the less trust we have to place in things, the better. Consequently, we run IPSec VPNs between all our internal servers, so that no ‘traffic knowledge’ leaks out. Aggressive firewall policies (during testing we even once locked ourselves out of our own servers) prevent non‐VPN traffic entering a box. And any messages needing to be temporarily stored on disk are encrypted – with AES 256 bit keys and appropriate cipher block modes. We’ve internally banned use of MD5 and SHA1 – hash algorithms still used in Amazon SQS for successful message enqueues.

All these security arrangements at Amazon SQS and stormmq are not worth a fig leaf, though, without proper user permissions. Like Amazon, we strongly authenticate API calls and server connections, and allow sharing of queues. However, we go much further; we allow different users fine grained read, write and create permissions, with a flexible means of defining which queues (and other important things) they get them on. With Amazon, to set up a secure solutions with different senders and receivers requires separate user accounts and the complexities of more billing and account management. With stormmq, one configuration manager can define who gets what. Additionally, our command line tools let server or desktop administrators prevent user access to passwords and credentials. With stormmq’s concept of environments, developers can not accidentally use production or vice versa – thereby saving your bacon on a SAS 70 Type II audit.


  Raphael ‘Raph’ Cohn

Raphael ‘Raph’ Cohn
Title
Chief Architect
Co‑Founder
Company
stormmq
Phone
+44 (0) 7590 675 756
Email
raphael.cohn@stormmq.com

I’ve designed, developed and burnt the midnight oil on the graveyard support shift from large systems for banks to troubleshooting telcos to pricing electricity in Singapore. The one thing that was always missing was ‘ready to use’ Message Queuing. Message Queues you could set up and tear down yourself without bureaucracy or crazy costs. Message queues that worked with anything. Then it dawned. Message Queuing should be a cloud based service.