Re: Column Redaction

On 14 October 2014 17:43, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Oct 11, 2014 at 3:40 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> As soon as you issue the above query, you have clearly indicated your
>> intention to steal. Receiving information is no longer accidental, it
>> is an explicit act that is logged in the auditing system against your
>> name. This is sufficient to bury you in court and it is now a real
>> deterrent. Redaction has worked.
>
> To me, this feels thin. It's true that this might be good enough for
> some users, but I wouldn't bet on it being good enough for very many
> users, and I really hope there's a better option. We have an existing
> method of doing data redaction via security barrier views.

I agree with "thin". There is a leak in the design, so let me coin the
phrase "imprecise security". Of course, the leaks reduce the value of
such a feature; they just don't reduce it all the way to zero.

Security barrier views or views of any kind don't do the required job.

We are not able to easily classify people as Trusted or Untrusted.

We're seeking to differentiate between the right to use a column for
queries and the right to see the value itself. Or put another way, you
can read the book, you just can't photocopy it and take the copy home.
Or, you can try on the new clothes to see if they fit, but you can't
take them home for free. Both of those examples have imprecise
security measures in place to control and reduce negative behaviours
and in every other industry this is known as "security".

In IT terms, we're looking at controlling and reducing improper access
to data by an otherwise Trusted person. The only problem is that some
actions on data items are allowed, others are not.

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