Having separate nodes for reads and writes provides an opportunity for
better isolation and control even when the requests are forwarded to
different vnodes...
Just like with anything else you can always build something on top...
The difference in maturity is determined by what you have to build
yourself vs what's already available and integrated into a unified
solution. Yes, there are different and unique aspects to how NoSQL
databases operate, but it's no excuse for not having any integrated
security. It's going to take time for integrated solutions to emerge,
but this is exactly what I was saying about the maturity stage the
NoSQL databases are in.
There won't be a perfect security solution right away. And it's not
just one thing... there are many aspects to security and it'll take
time to develop and go through various stages of evolution. And by
definition, it will make things slower :-) I did not give Accumulo as
an example of a NoSQL database that figured out this whole "security"
thing. Either way saying, "you customer go take care of our database
product security" is not the answer :-)
On Fri, Sep 30, 2011 at 12:00 PM, Aphyr <ap...@aphyr.com> wrote:
> 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
