On Fri, 2006-01-20 at 14:47, David Blewett wrote:
> Quoting Scott Marlowe <smarlowe@g2switchworks.com>:
>
> >> Having the table containing the index, or the database object,
> >> encrypted would protect against system admins,
> >
> > IF they've got root, and the unencrypted data or the password / key is
> > on the machine or in memory on it, you've lost. It may make it harder
> > for them to get it, but they can.
>
>
> The password shouldn't be saved anywhere, it should be entered manually
> when the application starts. Or, only store it on secure removable
> media.
But it will be in memory, and root can get anything out of memory that
they want to.
The only way to keep root on this box from getting it is to put the key
on another box that the administrator doesn't have access to. I.e. on
the client side of postgresql. If you want to keep root out of your
data on your server, you encrypt it before you give it to the server.
Then, you can set up a different box with the keys on it that encrypts /
decrypts the data there.
Now, if you can trust root, then you can do the encryption / decryption
on the same box as postgresql.
Now, having to enter a password by hand onto that box will keep the data
secure should the box itself be stolen.
I'd suggest defining the threat model well first, then defining the
encryption you'll need based on that.
> But it would be better than the options that exist today.
There is secure, and there are levels of insecure. Changing which level
of insecure you have doesn't give you secure.
> You're
> right; there is no perfect security, especially when the box has been
> rooted. They would have to get root while the machine is powered on,
> the database engine is running, and the user was authenticated and
> logged in.
True. If you trust the REAL sysadmins, but are afraid of the box being
stolen, then your methodology is secure. Because you can trust the real
admins.
If you don't trust your real sysadmins on that box, then you need to do
your encryption elsewhere.