I'm not here to define a perfect infrastructure for securing NoSQL databases and Riak and go into implementation details... It's not my intention because I simply don't have time to dedicate to this big project and it's impossible to come up with a perfect solution right away. Either way asking customers to be security experts is asking for trouble... And I base this statement on the actual real world experience in security, which I have quite a bit. I'll leave it on this note :-) And let's talk in 10 or 15 years :-)
A quick advice to the Riak team... If you want to go beyond startups as your customers you'll need to have a good story around security and an integrated solution people can use. Good luck! On Fri, Sep 30, 2011 at 2:23 PM, Aphyr <[email protected]> wrote: > On 09/30/2011 01:28 PM, Kyle Quest wrote: >> >> Having separate nodes for reads and writes provides an opportunity for >> better isolation and control even when the requests are forwarded to >> different vnodes... > > I humbly suggest this is a bad idea. Varying behavior between nodes > > a.) is a headache to configure and maintain > b.) creates fault-tolerance problems > c.) creates unbalanced loads > > It's at odds with the symmetric layout of a dynamo system. Best case, you'll > fail more often. In addition, splitting reads and writes will require you to > work harder to handle client IDs. If you aren't careful, you'll lose data. > >> 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. > > What was the last datastore you *didn't* have to wrap in your own security > layer? I've built... I dunno, twenty or thirty of them for various > applications. Because trust is complicated, sufficiently general security > systems require almost as much configuration and integration glue as the > code you'd write to do it from existing primitives. > > That said, if you have a proposal for a security model I'd like to see it. > There is a dearth of pluggable access control layers for datastores. I > suspect there's a good reason for that. > >> Either way saying, "you customer go take care of our database >> product security" is not the answer :-) > > It is an entirely reasonable answer; access control is almost totally > orthogonal to robust data storage. You're asking Ikea to control who puts > things in your cabinets. > > I'm guessing the reason your posts appear so confused is because you don't > have a clear idea about what properties a "database security" system would > have. It might be worth writing down your specific requirements, and asking > "What percentage of use cases will this satisfy efficiently?" > > --Kyle Kingsbury > _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
