Re: Column Redaction

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Damian Wolgast <damian(dot)wolgast(at)si-co(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Column Redaction
Date: 2014-10-10 10:49:24
Message-ID: 20141010104924.GA28859@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Heikki Linnakangas (hlinnakangas(at)vmware(dot)com) wrote:
> On 10/10/2014 01:21 PM, Simon Riggs wrote:
> >Redaction is now a feature available in other databases. I guess its
> >possible its all smoke and mirrors, but thats why we discuss stuff
> >before we build it.
>
> I googled for Oracle Data redaction, and found "General Usage guidelines":
>
> >General Usage Guidelines
> >
> >* Oracle Data Redaction is not intended to protect against attacks by
> >privileged database users who run ad hoc queries directly against the
> >database.
> >
> >* Oracle Data Redaction is not intended to protect against users who
> >run exhaustive SQL queries that attempt to determine the actual
> >values by inference.
>
> So it's not actually suitable for the example you gave. I don't
> think we want this feature...

Or, we need to consider how Oracle addresses these risks and consider if
we can provide a similar capability. Those capabilities may include
specific configuration and could be a prerequisite for this feature, but
I don't think it's sensible to say we don't want this feature simply
because it can't stand alone as a perfect answer to these risks.

As has been discussed before, we are likely in a better position to
identify the concerns and problem areas, come up with recommendations
for configuration and/or develop new capabilities to mitigate those
risks, than the every-day user or DBA. If we provide it and address
these issues in a central location which is generally available, then
fixes and problems can be addressed and fixed rather than every
database implementation faced with these concerns having to address
them independently with, most likely, poorer quality solutions.

While we don't want every feature of every database, this deserves more
consideration.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-10-10 11:00:54 Re: Column Redaction
Previous Message Andres Freund 2014-10-10 10:49:01 Re: Wait free LW_SHARED acquisition - v0.2