Re: Column encryption use-case

On Tue, 19 Sept 2023 at 23:03, Lok P <loknath.73_at_gmail.com> 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.

--
http://www.freelists.org/webpage/oracle-l