Re: Database Encryption (now required by law in Italy)
От | Radu-Adrian Popescu |
---|---|
Тема | Re: Database Encryption (now required by law in Italy) |
Дата | |
Msg-id | 404864DD.6000207@aldratech.com обсуждение исходный текст |
Ответ на | Re: Database Encryption (now required by law in Italy) ("Matt Clark" <matt@ymogen.net>) |
Ответы |
Re: Database Encryption (now required by law in Italy)
|
Список | pgsql-admin |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Clark wrote: |>What's wrong with using a LoopAES filesystem? It protects against |>someone walking off with the server, or at least the hard disk, and |>being able to see the data. | | |Yes, but only if the password has to entered manually [1] at boot time. |And it gives zero protection against someone who gains root access to the |server. | |So you _also_ have to encrypt the sensitive data before giving it to the |DB, using a key that is not stored on the DB server. | |Of course that means your app servers have to have _those_ passwords/ |keys entered manually at boot time, or else someone who roots them can |read your sensitive data quite trivially. | |And to do any better than that you need one of those very snazzy cards |from nCipher or whoever, that allow you to process encrypted data in a |hardware sandbox so even your application doesn't see it, or at least |only allow signed code to manipulate the data. | | |Matt | |[1] There are ways of avoiding having to enter the info manually, but | they're very tricky to implement securely. | | |---------------------------(end of broadcast)--------------------------- |TIP 2: you can get off all lists at once with the unregister command | (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) | | We're basically doing it this way: generate a pair of private/public keys and save these. Then we get sensitive data in from some outside source, use it in the processing part, then we encrypt it using the public key (obviously) and store it in the database. They public key lives itself inside the database, because it presents no security risk if exposed. The private key lives on a separate machine in another physical location. So no-one can decrypt the data even if gaining access to the server machines. Obviously this assumes that we do not decrypt the data after using it... Which is something rather hard to enforce, depending on the application. If we do need to decrypt the data, we take the encrypted data to a safe location, get the private key securely and then decrypt and use the data. - -- Radu-Adrian Popescu CSA, DBA, Developer Aldratech Ltd. +40213212243 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFASGTdVZmwYru5w6ERAtCkAJ47bkhYffP3CeehdOKZThhCSoOoJgCfQGU3 9ZQkJc6yiuK5WwpmHtvRQ0E= =jkE+ -----END PGP SIGNATURE-----
В списке pgsql-admin по дате отправления: