A GDPR-friendly role setup
Who Watches the Watchmen?
Or Quis custodiet ipsos custodes? as the Romans would say. When you grant someone the right to use force against crime, or look at private data to detect crime, how do you ensure they don’t abuse their privilege to commit crime? You assign someone else to oversee them. But how do you ensure those people stay in line? Recursion quickly becomes a problem, and at some level you have to trust people, whether they deserve it or not. There just aren’t enough watchmen for all of us.
Honor doesn’t work here. When you give people access to one of the world’s biggest databases of would-be private data and communications, some of them will abuse their access to spy on spouses, exes, or other love interests, for example. This happened often enough at the US security agency NSA that they gave it a code name: LOVEINT. Colleagues, relatives, and celebrities may also be targets. Similar abuses have been documented to happen elsewhere. Those tasked with overseeing people in such jobs have to take this sad aspect of human nature into account, and actively look for breaches and ways to prevent them. This raises the question of the ethics of collecting the data in the first place, of course.
Trust, But Verify
Do you trust your employees/ colleagues? This is the wrong question. The right question is, how much do you trust them? Do you trust them to never, ever make mistakes? Unlikely, because errare humanum est. This is why we have handrails and seatbelts. Do you trust them not to sell your customer database to the highest bidder on the dark web? Hopefully, but that doesn’t mean you shouldn’t be careful about who you trust with what data, and how you follow them up. Доверя́й, но проверя́й or Trust, but verify, as the Russian proverb goes.
The EU’s General Data Protection Regulation (GDPR) describes the role of the Data Protection Officer - someone who is responsible for data protection in an organization. If you’re dealing with or in the EU/ EEA, you will likely need to have one of those. In any case, one can learn a lot from reading up on the GDPR: It’s wise to minimize data collection, because what isn’t collected cannot be leaked. It’s also good to minimize the number of people who have access to the data, since that reduces the chance of one of them being a bad egg, or of making a fatal mistake despite good intentions. How can we do this in eZ Platform?
Data Protection in eZ Platform
Out of the box, eZ Platform comes with four roles: Anonymous (those who have not logged in), Member (registered users), Editor, and Administrator. Editors can publish content, and Administrators can do whatever they please. If you find that your editors lack some permission they need, it can be tempting to simply give them Administrator access, and be done with it. But with great power comes great responsibility, and it’s best to grant this power to as few people as possible. It’s safer to diversify the roles.
Thankfully the permission system in eZ Platform is very flexible. We can make as many roles as we need. We can assign roles to users or user groups, and we can assign conditionally based on the content in question. We can even do permission inheritance using nested user groups. I’d like to sketch up a privacy-friendly role setup that’s a bit more differentiated than the default, based on the need-to-know principle and common use-cases.
Goals
- Do not share passwords, including that of the original Administrator User. Maintain separate, named user accounts. Assign roles to user groups, and place users in groups to give them access. This way it's easy to review and revoke access, and audit user actions.
- Administrators should be very few, and carefully vetted. Consider the bus factor, but note that if administrator access is lost, it can be regained using scripts like this.
- Developers may need higher access levels during initial development than after going live. Make sure you revoke unneeded rights before going live. Consider also who has direct access to the shell and/ or database, and revoke when possible.
- Do not ask for data that you don't need. What isn't stored cannot be leaked. If you think you'll maybe need more data later, ask for it then, not now. If you don't need it anymore, delete it. Keep the user informed about what you store and why.
- Do not give access to external user data to those who don't need it. Developers don't need it, they can use dummy user accounts for testing. Editors certainly don't need it. The Data Protection Officer may need it, and so may user support agents.
- Maintain separation between internal and external users. Human Resources should be responsible for internal users, as the Data Protection Officer is for external users.
As an extreme case, consider having no Administrators. Administrators by design have access to everything, including user data. But it's perfectly possible to run a site without such full admins, if you design sub-administrator roles for the required admin tasks. Note that the original Administrator User is required by the system, and should not be removed or disabled. However, you could give it a complex password that you lock up in the company safe, or simply do not save anywhere (if you need to regain access, see goal 2).
Note that out of the box, the Editor role grants no access to User data, despite having access to the backend and a content/* policy. This is because it is assigned to the Editor group with subtree limitation on the eZ Platform and Media roots, not the User root. That’s a good thing, and I suggest you keep it that way.
Example user group/ role structure
The user groups are in italic, and the roles in bold.
- Administrators/ Administrator - Full access. Could be empty except the original Administrator User, see above. But if you do use it, use separate accounts per administrator.
- Sub-administrators/ Sub-administrator - Have access to specific administrative functions, but not to any other users.
- Human Resources/ Human Resources - Have access to all user groups except Administrators and External users. Can e.g. grant access to new employees, and revoke for ex-employees. (This could be integrated in the Sub-administrator role instead, to minimize group complexity.)
- Editors/ Editor - For example, can create content, but not publish it.
- Chief Editors/ Chief Editor - Inherit the Editor role. For example, can approve and publish content.
- Developers/ Developer - Have access to Dummy users but not External users. For example, could also have Editor & Chief Editor roles, and administrative rights as needed. Revoke unneeded permissions/ assignments before going live. (Could be integrated in the Sub-administrator role instead, to minimize group complexity.)
- Data Protection Officer/ Data Protection Officer - Has full access to External users.
- External users/ External user - Invisible to anyone but the Data Protection Officer.
- Premium users/ Premium user - Have extra privileges, e.g. paying subscribers. Inherit the basic External user role.
- Dummy users/ External user - Same permissions as External users.
- Premium users/ Premium user - Same permissions as external Premium users.
- Anonymous users/ Anonymous - Contains only the Anonymous user, which is used when not logged in.
See the documentation on roles and policies for how to design the setup you need. Do you have questions or feedback? Please let me know in the comments section. Thanks!
Other means of data protection
The GDPR suggests various means of ensuring data protection, but does not mandate any of them specifically. One way is pseudonymization: when personally identifiable information is replaced by fake data, such as replacing a name by John Doe, but in such a way that the original information can be recovered by those holding the right key. Another way is encryption, which I have written briefly about before. I'd like to look at these topics in future blog posts, in the context of eZ Platform and GDPR.
In the meantime, please remember our guidelines for safely reporting security issues in eZ Systems products, and do the same for other vendors. Until next time, stay safe!
