From: | Bill Moran <wmoran(at)potentialtech(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Looking for advice on database encryption |
Date: | 2009-04-16 19:40:12 |
Message-ID: | 20090416154012.59a9f17a.wmoran@potentialtech.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
What are folks doing to protect sensitive data in their databases?
We're running on the assumption that the _really_ sensitive data
is too sensitive for us to just trust the front-end programs that
connect to it.
The decision coming down from on-high is that we need to encrypt
certain fields. That's fine, looked at pgcrypto, but found
the requirement to use pgp on the command line for key management
to be a problem.
So we're trying to implement the encryption in the front-end, but
the problem we're having is searching on the encrypted fields. Since
we have to decrypt each field to search on it, queries that previously
took seconds now take minutes (or worse).
We've tested a number of cryptographic accelerator products. In
case nobody else has tried this, let me give away the ending: none
that we've found are any faster than a typical server CPU.
So, it's a pretty open-ended question, since we're still pretty open
to different approaches, but how are others approaching this problem?
The goal here is that if we're going to encrypt the data, it should
be encrypted in such a way that if an attacker gets ahold of a dump
of the database, they still can't access the data without the
passphrases of the individuals who entered the data.
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2009-04-16 20:00:03 | Re: Looking for advice on database encryption |
Previous Message | Grzegorz Jaskiewicz | 2009-04-16 18:45:47 | Re: [GENERAL] Performance of full outer join in 8.3 |