Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 21/06/18 21:43, Nico Williams wrote:
> On Fri, May 25, 2018 at 08:41:46PM +0900, Moon, Insung wrote:
>> Issues on data encryption of PostgreSQL
>> ==========
>> Currently, in PostgreSQL, data encryption can be using pgcrypto Tool.
>> However, it is inconvenient to use pgcrypto to encrypts data in some cases.
>>
>> There are two significant inconveniences.
>>
>> First, if we use pgcrypto to encrypt/decrypt data, we must call pgcrypto functions everywhere we encrypt/decrypt.
> Not so. VIEWs with INSTEAD OF triggers allow you to avoid this.
>
>> Second, we must modify application program code much if we want to do
>> database migration to PostgreSQL from other databases that is using
>> TDE.
> Not so. See above.
>
> However, I have at times been told that I should use SQL Server or
> whatever because it has column encryption. My answer is always that it
> doesn't help (see my other posts on this thread), but from a business
> perspective I understand the problem: the competition has a shiny (if
> useless) feature XYZ, therefore we must have it also.
>
> I'm not opposed to PG providing encryption features similar to the
> competition's provided the documentation makes their false-sense-of-
> security dangers clear.
>
> Incidentally, PG w/ pgcrypto and FDW does provide everything one needs
> to be able to implement client-side crypto:
>
> - use PG w/ FDW as a client-side proxy for the real DB
> - use pgcrypto in VIEWs with INSTEAD OF triggers in the proxy
> - access the DB via the proxy

    Sounds a bit hackish, but it could work. I doubt however the
acceptance of a solution like this, given the number of "moving parts"
and operational complexity associated with it.

>
> Presto: transparent client-side crypto that protects against DBAs. See
> other posts about properly binding ciphertext and plaintext.
>
> Protection against malicious DBAs is ultimately a very difficult thing
> to get right -- if you really have DBAs as a threat and take that threat
> seriously then you'll end up implementing a Merkle tree and performance
> will go out the window.
>
>> In these discussions, there were requirements necessary to support TDE in PostgreSQL.
>>
>> 1) The performance overhead of encryption and decryption database data must be minimized
>> 2) Need to support WAL encryption.
>> 3) Need to support Key Management Service.
> (2) and full database encryption could be done by the filesystem /
> device drivers. I think this is a much better answer than including
> encryption in the DB just because it means not adding all that
> complexity to PG, though it's not as portable as doing it in the DB (and
> this may well be a winning argument).
>
> What (3) looks like depends utterly on the threat model. We must
> discuss threat models first.
>
> The threat models will drive the design, and (1) will drive some
> trade-offs.
>
>> Therefore, I'd like to propose the new design of TDE that deals with
>> both above requirements. Since this feature will become very large,
>> I'd like to hear opinions from community before starting making the
>> patch.
> Any discussion of cryptographic applications should start with a
> discussion of threat models. This is not a big hurdle.

    You already mentioned that there are also "business criteria" to
consider here, and they are important. And there are even more to
consider. For instance, cases where (1) and even (2) under your proposed
threat model cannot be fixed by external (device/filesystem) encryption.
Consider for example the managed database services provided by the cloud
vendors. While (all?) of them provide transparent disk encryption, are
they trust-able? Do business want to rely on their encryption scheme,
key management, and how they respond from requests to hand off
encryption keys? I believe self-contained solutions are very worth, also
because of this.

    Álvaro

--

Alvaro Hernandez

-----------
OnGres