Re: Looking for advice on database encryption

In response to Sam Mason <sam@samason.me.uk>:
>
> > As far as the trust factor, you've blurred the lines a bit.  My job
> > is to ensure that the user doesn't know or care about the lines between
> > application and database, but trusts the system as a whole.  However,
> > I need to clearly define those lines and ensure that each part of
> > the whole has enough security measures to withstand a flaw in one
> > of the other parts.  Think of the design of postfix, where each
> > program (smtpd, qmgr, etc) doesn't trust the input of the other
> > programs and runs in its own sandbox.
>
> Sorry; my example of where to place trust was a bad one, lets try some
> other ones:
>
> The Postgres process; do you trust that the database engine is secure?
> This implies that the frontend program can send the user's secret to the
> database engine and the decryption will be done "inside" the database.
> I believe this to be the case, otherwise for the user to query on SSN,
> to pick an example you were using before, you would need to send *every*
> encrypted SSN to the client where they would decrypt it with their secret
> to find the one they wanted.
>
> Backups; you mentioned that if someone stole the backups they shouldn't
> be able to get any more information than if they were using the client
> interface.  If every sensitive field is encrypted then you're protected
> against some attacks, but you'd be better encrypting the backup.  Where
> is it OK to place the trust here?

Nowhere, really.  The goal is not to trust any one part of the system.
As a result, we can protect the data across multiple security failures.
For example, backups will actually be encrypted twice.  In order to
recover data from our backups, an attacker would have to physically
acquire a tape, then steal or brute-force 2 different encryption
keys before they could access the data.

In the end, the only person that should be trusted with the data are
the users who own the data.  That person will explicitly grant access
to their data to program administrators, the software will simply
facilitate the process.

We put as many layers as we can everywhere.  Usually this is limited
when we start hitting performance issues and have to remove a layer
to keep performance where it needs to be.  The goal is to have as
many layers as possible while keeping the system as performant as
the client expects.

We only get one shot at this.  If there's a data leak, a lot of
people are going to be very upset and we're going to be out of
business, so we're implementing the tightest security possible
at every layer.  This thread is only one part of the overall
process as it specifically relates to the database layer.

--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/