Re: Column Redaction

Thom Brown <thom(at)linux(dot)com> wrote:
> On 10 October 2014 15:56, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> Thom Brown (thom(at)linux(dot)com) wrote:
>>> Data such as plain credit card numbers stored in a
>>> column, even with all its data masked, would be easy to determine.
>>
>> I'm not as convinced of that as you are.. Though I'll point out that in
>> the use-cases which I've been talking to users about, it isn't credit
>> cards under discussion.
>
> I think credit card numbers are a good example.

I'm not so sure. Aren't credit card numbers generally required by
law to be stored in an encrypted form?

> If we're talking
> about format functions here, there has to be something in addition to
> that which determines permitted comparison operations. If not, and we
> were going to remove all but = operations, we'd effectively cripple
> the functionality of anything that's been formatted that wasn't
> intended as a security measure. It almost sounds like an extension to
> domains rather than column-level functionality.

I have to say that my first thought was that format functions
associated with types with domain override would be a very nice
capability. But I don't see where that has much to do with
security. I have seen many places where redaction is necessary
(and in fact done), but I don't see how that could be addressed by
what Simon is proposing. Perhaps I'm missing something; if so, a
more concrete exposition of a use case might allow things to
"click".

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company