Trouble with Securing Riak

Database systems like SQL Server and Oracle have long featured pervasive security.

You define the available logins, transports and encryption. You grant each login specific rights, then using ownership chaining to build a secure, only-what-is-absolutely-necessary data platform.

Security was never optional. It wasn’t bolted on later.

While originally intended for client-server applications, where each user is authenticated directly by the database with all of the authorization that entails, in most modern architectures only service accounts hit the database. Even in that sort of service oriented install, database authentication and authorization helps you restrict the subsystems to doing only the actions that their purpose demands.

The authentication service can only ever call the auth.PerformLogin stored procedure, for instance.

It’s a very good last defense. Security is maximized through layering.

The complete absence of security in many NoSQL solutions stands in stark contrast to those traditional solutions. Riak, for instance, simply has no security whatsoever. The security documentation is essentially just a placeholder.

The advice is that you should roll your own by layering security in other parts of the system. Install an Apache or Nginx reverse proxy in front of it, for instance. Build a node.js application just to apply permission restrictions. Layer some ipsec rules for added measure.

I’m not faulting Riak (quite the opposite — my cost to commercially use what is a very impressive product is $0): Every other NoSQL system I’ve looked at has at most rudimentary security. The single root user, for instance, that can do anything.

Many try to see the best in these deficiencies, reminding a bit of the early days of MySQL when every feature they had yet to get around to implementing was instead held as an advantage: When transactional integrity, stored procedures, robust storage systems, user types, etc, were purportedly an unwanted extra burden. Until they get implemented when their utility became obvious and of value to all.

This lack of security adds friction and complexity to the implementation. How, for instance, to maintain the incredible scalability of Riak (the reason I chose it as the key/value database of tewdew for a very unique need that it perfectly suits) while choosing one of these layered options. How to ensure absolute security under varying network conditions (e.g. spinning up a new instance or operating in another vendor’s virtual machine farm when I have minimal trust that the peers will always be controlled by me, yet need to dynamically facilitate adding and removing machines).

I’m considering these questions now, and continue to research options. If any reader has any thoughts on implementing credible security with Riak, I’d be very interested in hearing it. It’s a learning experience for me, though I feel quite certain that I’ll come up with a great solution that I’ll document here.

Leave a Reply

Your email address will not be published. Required fields are marked *