Re: Column Redaction

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Column Redaction
Date: 2014-10-10 09:38:54
Message-ID: CA+U5nMJZqu=rwYmw4xjwWQewAs7ojmCNEDuDv3j-rj__ASiVVQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10 October 2014 10:29, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:
> On 10/10/2014 11:57 AM, Simon Riggs wrote:
>>
>> Postgres currently supports column level SELECT privileges.
>>
>> 1. If we want to confirm a credit card number, we can issue SELECT 1
>> FROM customer WHERE stored_card_number = '1234 5678 5344 7733'
>>
>> 2. If we want to look for card fraud, we need to be able to use the
>> full card number to join to transaction data and look up blocked card
>> lists etc..
>>
>> 3. We want to block the direct retrieval of card numbers for
>> additional security.
>> In some cases, we might want to return an answer like '**** ***** ****
>> 7733'
>>
>> We can't do all of the above with current facilities inside the database.
>
>
> Deny access to the underlying tables. Write SQL functions to do 1. and 2.,
> and grant privileges to the functions, instead. For 3. create views that do
> the redaction.

If everything were easy to lock down the approach you suggest is of
course the best way.

The problem there is that the SQL for (2) changes frequently, so we
want to give people SQL access.

Just not the ability to retrieve data in a usable form.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2014-10-10 09:45:06 Re: Column Redaction
Previous Message Fujii Masao 2014-10-10 09:37:31 Re: alter user set local_preload_libraries.