1

In my company we want to implement pseudonymization to fulfill some GDPR requirements. From what I understand, the purpose of pseudonymization is to prohibit easy access to all information about one person. You give this person a pseudonym, then store his/her data divided in different places. This way, someone using system A, doesn't have easy access to data stored in system B. But what about system administrators who can access databases of all the systems and easily connect the partitioned data?

  • Is it OK for system administrators to have such option?

  • How to protect the data from access by system administrators?

  • Is it possible to have pseudonymized data when there are people with access to all the databases?

  • You would need multiple sysadmins for that, and also isolated building for each partition of data to avoid that. Doing client-side encryption is not solution to most problems. – Aria Sep 13 '17 at 18:26
1

Just because a system administrator have access to the database doesn't necessarily mean that the administrator need to have access to all the data. You can encrypt the data to prevent the system administrator from having access to the data. If the encryption happens at the client side and only the users have access to the encryption keys, then you can design it so the system administrator would not be able to decrypt the data. Using public key cryptography, you can allow data entered by one user to be read by a different user, without the first user having to share their own encryption key to the second user.

Of course most real applications need the server to do some work with parts of the data, usually to allow searching the database, you'll need to rethink these aspects of the application. Perhaps, you can store a second hashed_name field so you can search based on the user's name without disclosing the actual name. Perhaps you can store a general location of addresses in plain text and have the full address encrypted.

You'll also need to consider if there are any data that can be correlated with other data to leak information even after encryption/hashing. For example, you may hash a disease's name so you can use the field for searching patients with that disease, but by correlating the frequency of occurrence of the hashed names can be correlated with publicly available data about prevalence of diseases to reduce the number of possibilities that each hashed names can be. You may want to consider whether such advanced attack scenarios would be in scope or to accept tree risk and limit the pseudonymization only to opportunistic attackers.

You can also enforce physical partitioning so that system A and B are managed independently by separate teams, running on separate hardware and resources (share nothing). This way, you ensure that no single system holds all the data and data leak will require at least two person from different teams to collude.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.