←back to thread

PostgreSQL Anonymizer

(postgresql-anonymizer.readthedocs.io)
250 points chynkm | 1 comments | | HN request time: 0.201s | source
Show context
riskable ◴[] No.42739402[source]
One of the best ways to handle this sort of thing is to put things like PII in a separate database entirely and replace it with a token in the "main" database. When something like PII actually needs to be retrieved you first retrieve the token and then search the other database for said token to get the real data.

It certainly complicates things but it provides an additional security layer of separation between the PII and it's related data. You can provide your end users access to a database without having to worry about them getting access to the "dangerous" data. If they do indeed need access to the data pointed to via the token they can request access to that related database.

This method also provides more performance since you don't need to encrypt the entire database (which is often required when storing PII) and also don't need to add extra security context function calls to every database request.

replies(5): >>42739945 #>>42740069 #>>42740081 #>>42744848 #>>42745753 #
1. 10000truths ◴[] No.42745753[source]
What's the difference between this and a user ID that's not publicly exposed?