Re: Database Encryption (now required by law in Italy)

Matt Davies wrote:

> And how does one account for key information? If one encrypts any information
> deemed worthy to be a key then you have to decrypt the entire database to find
> particular information.
>
>
> Of course, you could keep keys unencrypted for use, but then again, why encrypt
> it at all?

My question is much more basic than that:  Why encrypt anything beyond
passwords?  If you secure the accounts on the machine, and encrypt all
network traffic to the machine (ssh, scp, ssl) then what additional
security can you add?

I have servers in remote facilities all over the world.  It is just not
possible for me to fly to each datacenter to be there at boot time when
I upgrade the kernel. I'd love the travel, but it is not feasible.

Second, hard-disk encryption will only come into play if someone stole
the hardware, right?  And even then, as long as the thing boots, then
they would have access!  That is, unless we went back to the
human-required-at-boot scenario.

As a former CSO for an 18000-person company, I'm a horribly paranoid
person when it comes to security; but security that is easily bypassed
(or dificult-to-impossible to enforce) is just added effort, isn't it?

Here is an idea to beat up on:  how about having the end user of the
application supply the key that is used to decrypt their data, and only
their data?  Take your basic, garden variety PHP website, for example.

When the user is given an account, they are also given a password.  This
password is also used as the key for the (blowfish, via mcrypt maybe?)
encryption of the data that gets stored for that person.  If you do not
have that key, then you cannot decrypt their data.  To boot, their key
is useless for everyone else's data as they used their own...

Excellent discussion, maybe we could all come up with a sort of best
practices for PostgreSQL and security :)

-- Mitch