Re: Looking for advice on database encryption

Поиск
Список
Период
Сортировка
От Steve Atkins
Тема Re: Looking for advice on database encryption
Дата
Msg-id 8E4EA5D2-6589-47E5-A2EE-FBA2D0BE7631@blighty.com
обсуждение исходный текст
Ответ на Looking for advice on database encryption  (Bill Moran <wmoran@potentialtech.com>)
Ответы Re: Looking for advice on database encryption  (Bill Moran <wmoran@potentialtech.com>)
Список pgsql-general
On Apr 16, 2009, at 12:40 PM, Bill Moran wrote:

(This is the traditional "you're asking the wrong question" response).

>
> What are folks doing to protect sensitive data in their databases?

I don't think that's a useful way to look at it. Protecting sensitive
data in the entire system, where the database is just one
part of that system is likely to lead to a much better answer.

>
> 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.

If that's the mandate, then that's what you have to do. It's unlikely to
make the system overall much more secure, and likely no more secure
than some much less intrusive approaches, though.

> 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.

If the concern is database dumps, then encrypting the output of
pg_dump will pretty much solve the problem. But if the attack
vector is the common one of compromising the front end, then
encrypting data in the database, but allowing the front end to
decrypt it is likely useless. If the concern is "what if an attacker
got access to the server?" then physical security is likely to have
much better ROI than some random encryption regime.

Can you go back and ask your management what their actual
security or compliance needs are?

If it's a real business need you probably want to find a decent
security guy and have him draft the questions that management
need to answer and start from there, rather than trying to clean
up after someone has already made 95% of the decisions, in
an uninformed way, for you.

Cheers,
   Steve


В списке pgsql-general по дате отправления:

Предыдущее
От: Kenneth Tilton
Дата:
Сообщение: string filtering in postgres?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Performance of full outer join in 8.3