cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Coe, Robin" <robin....@bluecoat.com>
Subject RE: bandwidth limiting Cassandra's replication and access control
Date Thu, 12 Nov 2009 02:17:54 GMT
I completely agree with Ian but would also like to add a point about the 
proposed service.  As was presented, the authentication is to be performed 
at the Thrift API layer, not the CLI layer.  In a relational database
environment, this would be equivalent to connections opened over a 
network.  In this environment, all connections share the same user account,
which is not per-user authentication.

I would still like to understand why there is the need to impose a keyspace
binding, from a security standpoint.  What is the risk associated with 
Cassandra's Thrift interface and how does a keyspace binding in Cassandra
mitigate this risk?  Beyond that, how will tokens be shared amongst all
the nodes in a cluster, such that a user returning to a different node 
maintains the keyspace binding and do so without affecting performance?

I ask these questions because I am evaluating Cassandra for a new service
and I need to ensure that my data are secure from unauthorized access.  I
know how I would go about implementing this using a relational backend but 
maybe Cassandra has security holes that can't be protected by securing the 
network environment alone?

Thanks,
Robin.

-----Original Message-----
From: Ian Holsman [mailto:ian@holsman.net]
Sent: Wed 11/11/2009 17:40
To: cassandra-user@incubator.apache.org
Subject: Re: bandwidth limiting Cassandra's replication and access control
 
just on point on 5.
most places i've seen don't use DB auth anywhere. there is a common  
login, stored in a property file, sometimes stored in a internally- 
world-readable SVN repo.
they usually use network ACLs to restrict access to good hosts. (jump  
hosts). network ACLs have been tested for decades and they work.  
implementing your own auth is just asking for problems. It's too hard  
to do properly, and will probably never work well with the enterprises  
existing auth systems.

If you have sensitive data being stored, ENCRYPT it, or use a 1-way  
hash instead of storing it.
Ideally with a user-supplied key which is not stored anywhere on disk.

sadly DBA's are people too, and it is pathetically easy for them to  
get all the data from a DB-dump.

On Nov 12, 2009, at 11:53 AM, Jonathan Mischo wrote:

> Let me put this in a slightly different (and probably fairly  
> tactless) context here, for those of us without an infosec background.
>
> 1) Per-keyspace authentication allows for accountability and access  
> control, at least at a rudimentary level.  Without this, there are  
> several types of applications that it would be impossible to use  
> Cassandra for, due to data security restrictions.  Not just  
> impractical, but probably illegal in some cases.
>
> 2) If you have an intrusion into your network or a malicious user  
> internally (yes, this happens), you're completely unprotected  
> without per-keyspace authentication.
>
> 3) Per-keyspace authentication is done once-per-session; if you use  
> connection pooling or persistent connections of any sort in your  
> application, this has virtually zero overhead.
>
> 4) It's REALLY bad infosec practice to have your data accessible by  
> anyone, anytime, with no restrictions, which is how Cassandra  
> currently operates.  While good network and application security can  
> minimize the risks, at present, a typo or missed change in a cut and  
> paste can potentially damage your data, especially if you have CFs/ 
> SCFs that have the same name in two keyspaces.
>
> 5) This is common practice, pretty much everywhere.  Every SQL  
> database, and almost every NOSQL database employs some form of AAA  
> (Authentication, Authorization, and Accountability) functionality.   
> It's pretty much an expected feature, though the granularity varies  
> depending on the implementation.  AAA isn't expensive, but it sure  
> can save your butt later (and/or help you prosecute that Evil Nasty  
> Person).  It can also provide you with nifty "Unauthorized"  
> exceptions that let you know you forgot to change the keyspace in  
> your configuration and almost did a Really Bad Thing.
>
> 6) Your bosses will like it (and you) a lot better if they don't  
> have to ask you where your organization's data went.
>
> Hope this helps drive the point home that authentication and  
> authorization (as proposed) has near-zero overhead and is actually  
> pretty bad (read: slightly horrifying to auditors and security  
> people, but really exciting for evil people and typo gremlins) to  
> not have.
>
> -Jon
>
> On Nov 11, 2009, at 4:18 PM, Coe, Robin wrote:
>
>> Do you mean that users interacting with Cassandra through the CLI  
>> should be restricted based on a security service?  I agree.   
>> However, I believe the more common case is to front the Cassandra  
>> service with an application layer, as you would expose a relational  
>> backend.  For that kind of service, the application should control  
>> the security.
>>
>> Basically, a user request to Cassandra is not stateful; any request  
>> should be able to perform a transaction against any node in the  
>> cluster, using an appropriate consistency model for the request.   
>> Requiring something like real time token synchronization across all  
>> nodes in a cluster seems outside of Cassandra's  eventual  
>> consistency model.
>>
>> Securing the data is intrinsically application-specific.  While I  
>> could see adding a plugin that makes the CLI access point secured,  
>> I would still want that to be made in a pluggable fashion, so it  
>> could be swapped out with a custom implementation.
>>
>> Of course, this is just my point of view, but I make it after  
>> having written several security layers on J2EE apps over the years  
>> and none of them have been the same.  Besides that, I want the data  
>> layer to be highly efficient and in my opinion, it isn't the work  
>> of the data service to impose security.
>>
>> Robin.
>>
>> From: Brandon Williams [mailto:driftx@gmail.com]
>> Sent: November 11, 2009 4:44 PM
>> To: cassandra-user@incubator.apache.org
>> Subject: Re: Re: bandwidth limiting Cassandra's replication and  
>> access control
>>
>> On Wed, Nov 11, 2009 at 9:40 AM, Coe, Robin  
>> <robin.coe@bluecoat.com> wrote:
>> IMO, auth services should be left to the application layer that  
>> interfaces to Cassandra and not built into Cassandra.  In the  
>> tutorial snippet included below, the access being granted is at the  
>> codebase level, not the transaction level.  Since users of  
>> Cassandra will generally be fronted by a service layer, the java  
>> security manager isn't going to suffice.  What this snippet could  
>> do, though, and may be the rationale for the request, is to ensure  
>> that unauthorized users cannot instantiate a new Cassandra server.   
>> However, if a user has physical access to the machine on which  
>> Cassandra is installed, they could easily bypass that layer of  
>> security.
>>
>> What if Cassandra IS the application you're exposing?  Imagine a  
>> large company that creates one large internal Cassandra deployment,  
>> and has multiple departments it wants  to create separate keyspaces  
>> for.  You can do that now, but there's nothing except a gentlemen's  
>> agreement to prevent one department from trashing another  
>> department's keyspace, and accidents do happen. You can front the  
>> service with some kind of application layer, but then you have  
>> another API to maintain, and you'll lose some performance this way.
>>
>> -Brandon
>

--
Ian Holsman
Ian@Holsman.net





Mime
View raw message