Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of
 gcdcu-cassandra-user@m.gmane.org designates 80.91.229.12 as permitted sender)
To: cassandra-user@incubator.apache.org
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: bandwidth limiting Cassandra's replication and access control
Date: Thu, 12 Nov 2009 08:58:44 -0600
Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @
 Cienfuegos
Lines: 44
Message-ID: <871vk3ssbf.fsf@lifelogs.com>
References: <87eio6p7pb.fsf@lifelogs.com>
	<e06563880911101153j60552e58h417fe8f896ca6ce@mail.gmail.com>
	<87ljienhjx.fsf@lifelogs.com>
	<e06563880911101509t7b457941q49394a000f6e639c@mail.gmail.com>
	<87hbt1nnur.fsf@lifelogs.com>
	<764B352CF55C514F816B4B14BD2450D803DBB97B@bcs-mail04.internal.cacheflow.com>
	<cdc5ad200911111344v38c44732h57a0305fa62d57cc@mail.gmail.com>
	<764B352CF55C514F816B4B14BD2450D803DBBF2C@bcs-mail04.internal.cacheflow.com>
	<BEDD8E0E-A3F7-41D1-8103-22C761D3E147@quagility.com>
	<97635523-9F34-4A3B-81AB-A2DDFA1E4BDC@Holsman.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux)
Cancel-Lock: sha1:56/gUe04ma3pBt+FlIVeFZ5LI4Q=
Sender: news <news@ger.gmane.org>

On Thu, 12 Nov 2009 12:40:05 +1100 Ian Holsman <ian@holsman.net> wrote: 

IH> most places i've seen don't use DB auth anywhere. there is a common
IH> login, stored in a property file, sometimes stored in a internally- 
IH> world-readable SVN repo.

In my current industry (financials) this is not acceptable.  It puts
money and jobs at risk to open access this way.

IH> they usually use network ACLs to restrict access to good hosts. (jump
IH> hosts). network ACLs have been tested for decades and they work.
IH> implementing your own auth is just asking for problems. It's too hard
IH> to do properly, and will probably never work well with the enterprises
IH> existing auth systems.

Layers of security are always a good idea (any firewall is just a part
of good security design, and by itself only increases complacency).  I
should mention I've been a sysadmin and network admin for many years
besides doing programming.

No one is suggesting to implement our own authentication.  We're going
to use existing mechanisms, namely what JAAS supports (LDAP, NIS,
etc.).  We're creating a specific authorization mechanism because it
makes sense for Cassandra, but we're again using JAAS to do that.

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

This is not feasible in many cases.  Encryption is slow and very hard to
implement properly.  One-way hashes lose the original content,
obviously.  User-supplied keys require interactivity at least at some
point, which is annoying and makes reliable operation harder to
achieve.  Fast access to the data is very important and my proposal
(initial login followed by an auth token passed around) is a decent
solution to these concerns.

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

Securing backups is, fortunately, much easier to address on the server
side because it deals with static data.

Ted