Apples and Oranges UK, Tuesday, 18th January 2011
This is the last of six articles in the series Apples and Oranges 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.
About the AuthorGot a question but don’t want to comment? Email me.
Other posts you might likeGuess-timated
Superficially, stormmq seems to be like Amazon’s SQS, but they have very different message properties.
Superficially, stormmq seems to be like Amazon’s SQS, but they have very different messaging idioms.
Superficially, stormmq seems to be like Amazon’s SQS, but they have very different models for acknowledgments and transactions.