Related

PostgreSQL RULES for pseudonymisation

Pseudonymisation; a use case

Data has value and, as stated in
GDPR Unplugged, can be quite risky
to handle.

Keeping it safe by itself is not a problem, but for data to be
valuable, it needs to be accessed. The process of accessing it
introduces the risk: data may leak. Leaking riskful data is bad for
continuity in many ways.

One solution to make riskful data harmless, is
pseudonymisation. This word is invented by the EU and mentioned in
the GDPR document.

What they mean by this is a 1-to-1 function (a bijection in
mathematical terms) where going one way is easy, but going back is
terribly hard.1 The terribly then
is documented by the EU to need
additional information for attributing the personal data to a
specific data subject which is to be kept separately (see pretext
item (29)).

So going back needs some extra information only authorised people
have access to.

In
Anonymise and tag simultaneously
I describe how this could work. In this title I will show exactly
how. The performance impact and the way to get back from a scrambled
field will be dealt with in subsequent titles.

Riskful data displayed in a harmless way

The riskfulness in employee data are names, date-of-births,
acountnames, e-mailaddresses and roles. Let's assume that the name
of someone's department is not a risk.

Making the employees table harmless, I need
to provide for a RULE which pseudonymises these columns based on
the access-level of the current user.

To make things simple, I assume that for personnel data, HR and no
others have full access to the riskful data
(except the director of the board of course).

Before being able to present a new table for employees, I need to
move the old one out of the way. It is called employeesold for
now.

This is only part of the work, for INSERT and UPDATE, rules
must be created as well. This is to avoid pseudonymised data ends up
being inserted in the database. These rules are pretty
straightforward, ignoring all riskful columns.

As this is a lot of work and error-prone, my proposal is to change
column-level security to cater for this in a single statement.