Re: Column encryption use-case
- From: Priit Piipuu <priit.piipuu@xxxxxxxxx>
- To: loknath.73@xxxxxxxxx
- Date: Thu, 21 Sep 2023 13:35:33 +0200
On Tue, 19 Sept 2023 at 23:03, Lok P <loknath.73@xxxxxxxxx> wrote:
But I understand the column encryption/decryption comes with its own
performance overhead. So it seems, dbms_encrypt is the only solution we can
go with and then perhaps we have to move the only sensitive field out of
the JSON string so that we would be able to avoid the burden of
encrypting/decrypting the whole clob column.
Please note: if the legal requirement is that sensitive data must be
encrypted, then it must be encrypted no matter what the overhead is. For
example, in certain jurisdictions tipping off the money launderer is a
jailable offence, so you will have a tradeoff between encrypting the
AML-related data and a few years in jail.
Oh, and if sensitive data must be encrypted, then it must be encrypted
everywhere, including networks and applications. For example, if the app
processes sensitive data unencrypted, then core dumps will become sensitive
data as well, etc.
Other related posts:
