From: | Sam Halliday <sam(dot)halliday(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | RFE: Transparent encryption on all fields |
Date: | 2009-04-23 11:43:30 |
Message-ID: | 2F0C4178-0867-4F0E-B070-520EBDF17B1E@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dear pgsql hackers,
The encryption options
http://www.postgresql.org/docs/8.3/static/encryption-options.html
fall short for my thread case. Consider the case where all users of a
machine are trusted and the machine automatically locks itself down on
a period of inactivity, and only local psql connections are allowed.
If the machine is stolen, the only current protection is to use an
encrypted drive. This is impractical because it requires a manual
start of the psql server and essentially means each user has to use a
separate instance and copy of the databases, each storing their data
in their own encrypted drives. (e.g. consider Apple OS X FileVault,
Windows TrueCrypt, or Linux/BSD equivalents)
If it were feasible, a transparent crypto on all fields for a given
database would be just the trick! Connections to such databases could
require a key as well as the user login. Queries could then continue
as if it was a normal connection and all fields would be unencrypted
on the fly. This particular approach might be a little too naive, but
it is a threat case I would urge you to consider. All security comes
with a cost, the cost here should be only minimal performance hit and
no changes to queries.
--
Sam
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2009-04-23 12:15:25 | Re: New trigger option of pg_standby |
Previous Message | Jasen Betts | 2009-04-23 10:38:21 | Re: Workaround for bug #4608? |