We've been over this several times on riak-users, which suggests to me a
blog post might help. I'll try to draft something.
On 09/30/2011 11:00 AM, Kyle Quest wrote:
This is a pretty common situation with the NoSQL databases. They have
no security and the standard answer is that it's your job to do with
firewalls and proxies. This is a good indication that the NoSQL world
is still in its infancy. Security features will get there eventually
and Accumulo is an example of progress in terms of security
capabilities, but it's going to take a while... a long while :-)
If you have a sensible, flexible, comprehensive proposal for access
control in an eventually consistent distributed key-value store, I would
love to hear about it. Thus far, every attempt I've encountered rapidly
approaches the proverbial "blatant layering violation", or is a subset
of {inconsistent, inadequate, overly specific, complex, slow}.
Accumulo (IIUC, docs are scarce) tags data with authorizations;
restricting access is up to the client. You can do that in Riak. You can
front Riak with a layer which allows puts/gets (globally, to buckets, to
keys, at various times, etc.) on the basis of HTTP auth, sessions, IP,
certificate, etc. You can also implement access control by writing valid
state transitions on an object to a statebox and invalidating concurrent
modifications that introduce policy conflicts. Authentication provided
by cryptographic hashes on transitions, or by a layer above. You could
introduce a lock service and use it to enforce certain classes of
sequential access, simplifying consistency.
Hopefully this suggests why it's not as simple as "adding security to
the database". There are a wide variety of security semantics, and many
can be layered on top of Riak (or any other datastore) without changing
the database itself.
Now in this case you can do something :-) One option is to use a web
proxy that would expose two different ports for GET and PUT requests
and then have the appropriate HTTP method filters for each of those
ports.
Writes require reads beforehand, but this will do the trick.
However, this doesn't really do much for security because these
GET and PUT requests will still be sent to the same Riak node.
...
A better solution is to have separate Riak nodes for reads and writes.
Riak forwards requests to the appropriate vnode for a key. Doing this
would have no effect on operational semantics.
--Kyle
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
