RE: Column encryption use-case

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: "'Priit Piipuu'" <priit.piipuu@xxxxxxxxx>, <loknath.73@xxxxxxxxx>
  • Date: Thu, 21 Sep 2023 08:00:32 -0400

Excellent points.

 

In this case I believe Lok P was suggesting that the sensitive data would no 
longer be allowed to appear in this string, not that it would not be 
unencrypted there.

 

Tim Gorman’s approach might allow the sensitive data to appear here only (the 
JSON string), which seems plausible since JSON can be parsed. But removing 
sensitive data altogether is the most effective possible “encryption,” similar 
to not executing a  sql you don’t need to execute to accomplish your goal. 
Presumably that trades some user inconvenience for performance in this 
particular case.

 

That does NOT diminish the value of your reminder that in some cases we are 
talking about legal requirements with possible criminal penalties for being 
careless.

 

Consider printed (even virtually “printed” to a PDF image). If reports contain 
legally controlled data in clear test, now they become subject to lock and key 
as well. IS the system administrator able to view all areas on disk based 
report repositories? How about operators at remote third party back-up sites?

 

You are correct, this is a serious issue.

 

mwf

 

mwf

 

From: Priit Piipuu [mailto:priit.piipuu@xxxxxxxxx] ;
Sent: Thursday, September 21, 2023 7:36 AM
To: loknath.73@xxxxxxxxx
Cc: Mark W. Farnham; Lucas Pimentel Lellis; rjgoulet@xxxxxxxxxxx; Oracle L
Subject: Re: Column encryption use-case

 

 

 

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: