Ian,
All valid points, though using a common login is considered poor
security. Usually you see a per-application login, which is generally
just fine, and then anyone who might directly access the database has
a named login for accountability reasons. Yes, some companies use a
single common login, but that's just laziness. And yes, DBAs are
people too, but if you limit who has access to your system, then you
make your pool of potential security violators a lot smaller, and make
investigations a lot faster (usually pointing to a connection from the
wrong application...let's face it, developers aren't infallible, as
much as some like to pretend otherwise).
-Jon
On Nov 11, 2009, at 7:40 PM, Ian Holsman wrote:
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:[email protected]]
Sent: November 11, 2009 4:44 PM
To: [email protected]
Subject: Re: Re: bandwidth limiting Cassandra's replication and
access control
On Wed, Nov 11, 2009 at 9:40 AM, Coe, Robin
<[email protected]> 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
[email protected]
