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

From: sanjay sharma <sanksh(at)hotmail(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Submission of Feature Request : RFC- for Implementing Transparent Data Encryption in P
Date: 2008-03-31 18:21:06
Message-ID: BAY116-W46B71284B03E38FD575564C3FA0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Heikki,

Although the solution could be implemented using views and functions and I am implementing a reference application using this approach but TDE can greatly reduce the design and maintenance complexcity. It would also take care of data protection in backups and archives.
You are correct to identify that TDE may not provide complete data security required for data like credit crad details but TDE seems to be ideally suited to take care of data privacy issues. Major chunk of the private data is of no interest to hackers and criminals but needs protection only from casual observers. To implement a full data security infrastucture to protect only privacy issues seems to be overkill. Compliance requirement for storing private data arises from each organizations own declared privacy policies and statutory bodies like privacy commissioners and other privacy watchdogs. These standards are not as strict as PCI, HIPPA or Sarnabes-Oxley

Compliance with HIPPA regulation requires not only maintaining all records of who created and updated the record but also who accessed and viewed records, when and in what context.

Cheers

Sanjay Sharma


> Date: Mon, 31 Mar 2008 09:48:46 +0100> From: heikki(at)enterprisedb(dot)com> To: sanksh(at)hotmail(dot)com> CC: jonah(dot)harris(at)gmail(dot)com; pgsql-hackers(at)postgresql(dot)org> Subject: Re: [HACKERS] Submission of Feature Request : RFC- for Implementing Transparent Data Encryption in P> > sanjay sharma wrote:> > However there are certain fetures which are becoming key for putting postgres in areas where strong regulatory compliance is required.TDE is very helpful in storing data where there is strict privacy compliance requirement for example e.Government and e.Health. All columns of personal profile/health data do not need same level of security for all users and applications. Selective data encryption is very handy in an architecture where different applications are pulling data from a central data repository for processing and presenting to their users or where different users are changing different part of data set in central repository. These departmental applications may contain keys for decrypting and looking at only those columns needed by their users. Encrypting just needed column takes care of compliance requirement down the line in backups and archives.> > You could implement that using views and contrib/pgcrypto. Create a view > on the underlying table that encrypts/decrypts the data on access.> > I'm not sure who the encryption is supposed to protect from in this > scenario. From the superuser of the database server? It isn't really > suitable for that: the way you describe it, the encryption/decryption is > done in the server, so a malicious superuser that has full access to the > server can still capture the data before it's encrypted, and can also > recover the key from the running server, by crawling through system > memory or installing hacked software to print it out.> > It's better than nothing, as it does protect from a casual non-malicious > observer, and it does protect the backups, but what I'd rather see is a > system where the database server never sees the data in plaintext. You > could do the encryption/decryption in the client, perhaps in the driver > so that it's transparent to the application.> > I'm not familiar with the compliance requirements you refer to. What > exactly is required?> > > Another area where I 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 very nice standard feature. Currently this needs code/trigger to be duplicated at each table which is a big grunt. At furthur higher level a way to audit data access/view for regulatory complinace like HIPPA is also needed.This should not be copy of Oracle FGA which has its own limitations. > > This could be implemented fairly easily as an external tool that queries > the system catalogs, and adds the required columns and triggers.> > -- > Heikki Linnakangas> EnterpriseDB http://www.enterprisedb.com
_________________________________________________________________
Technology : Catch up on updates on the latest Gadgets, Reviews, Gaming and Tips to use technology etc.
http://computing.in.msn.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2008-03-31 18:34:25 Re: [HACKERS] ANALYZE getting dead tuple count hopelessly wrong
Previous Message Tom Lane 2008-03-31 18:10:35 Re: Can Postgres 8.x start if some disks containing tablespaces are not mounted?