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
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. |