Re: Submission of Feature Request : RFC- for Implementing Transparent Data Encryption in P

Hello <span id="PresenceContainer">Heikki,</span><br /><span></span> <br /><span>Although the solution could be
implementedusing views and functions and I am implementing a reference application using this approach but TDE
can greatlyreduce the design and maintenance complexcity. It would also take care of data protection in backups and
archives.</span><br/><span>You are correct to identify that TDE may not provide complete data security required for
data likecredit crad details but TDE seems to be ideally suited to take care of data privacy issues. Major chunk of the
privatedata is of no interest to hackers and criminals but needs protection only from casual observers. To implement a
fulldata security infrastucture to protect only privacy issues seems to be overkill. Compliance requirement for storing
privatedata arises from each organizations own declared privacy policies and statutory bodies like privacy
commissionersand other privacy watchdogs. These standards are not as strict as PCI, HIPPA or Sarnabes-Oxley</span><br
/><span></span> <br/><span>Compliance with HIPPA regulation requires not only maintaining all records of who created
andupdated the record but also who accessed and viewed records, when and in what context.</span><br /><span></span> <br
/><span>Cheers</span><br/><span></span> <br /><span>Sanjay Sharma </span><br /><span> </span><br
/><span><strong></strong></span> <br/><br /><br />> Date: Mon, 31 Mar 2008 09:48:46 +0100<br />> From:
heikki@enterprisedb.com<br/>> To: sanksh@hotmail.com<br />> CC: jonah.harris@gmail.com;
pgsql-hackers@postgresql.org<br/>> Subject: Re: [HACKERS] Submission of Feature Request : RFC- for Implementing
TransparentData Encryption in P<br />> <br />> sanjay sharma wrote:<br />> > However there are certain
fetureswhich are becoming key for putting postgres in areas where strong regulatory compliance is required.TDE is very
helpfulin storing data where there is strict privacy compliance requirement for example e.Government and e.Health. All
columnsof personal profile/health data do not need same level of security for all users and applications. Selective
dataencryption is very handy in an architecture where different applications are pulling data from a central data
repositoryfor processing and presenting to their users or where different users are changing different part of data set
incentral repository. These departmental applications may contain keys for decrypting and looking at only those columns
neededby their users. Encrypting just needed column takes care of compliance requirement down the line in backups and
archives.<br/>> <br />> You could implement that using views and contrib/pgcrypto. Create a view <br />> on
theunderlying table that encrypts/decrypts the data on access.<br />> <br />> I'm not sure who the encryption is
supposedto protect from in this <br />> scenario. From the superuser of the database server? It isn't really <br
/>>suitable for that: the way you describe it, the encryption/decryption is <br />> done in the server, so a
malicioussuperuser that has full access to the <br />> server can still capture the data before it's encrypted, and
canalso <br />> recover the key from the running server, by crawling through system <br />> memory or installing
hackedsoftware to print it out.<br />> <br />> It's better than nothing, as it does protect from a casual
non-malicious<br />> observer, and it does protect the backups, but what I'd rather see is a <br />> system where
thedatabase server never sees the data in plaintext. You <br />> could do the encryption/decryption in the client,
perhapsin the driver <br />> so that it's transparent to the application.<br />> <br />> I'm not familiar with
thecompliance requirements you refer to. What <br />> exactly is required?<br />> <br />> > Another area
whereI would like to put a RFC is Auditing. A flag at the database level (conf file) or in DDL which puts audit columns
(created_by, creation_date, last_updated_by, last_update_date) on tables and automatically populates them would be a
verynice standard feature. Currently this needs code/trigger to be duplicated at each table which is a big grunt. At
furthurhigher level a way to audit data access/view for regulatory complinace like HIPPA is also needed.This should not
becopy of Oracle FGA which has its own limitations. <br />> <br />> This could be implemented fairly easily as an
externaltool that queries <br />> the system catalogs, and adds the required columns and triggers.<br />> <br
/>>-- <br />> Heikki Linnakangas<br />> EnterpriseDB http://www.enterprisedb.com<br /><br /><br /><hr
/>ExclusiveMarriage Proposals! Find UR life partner at Shaadi.com <a href="http://ss1.richmedia.in/recurl.asp?pid=430"
target="_new">Tryit!</a>