A long time ago I wrote the following statement on my LinkedIn profile: "RBAC is EOL". And in my not so youthful overconfidence I mentioned this during an intake with a potential customer, who asked me how they could introduce Role Based Access Control (RBAC) as conveniently as possible. That talk never materialized into an assignment…
GDPR and access control
Nixu Blog
March 19, 2018 at 13:22
It is an exciting time, we are approaching the deadline to be GDPR compliant and it does not seem that all organizations are ready for it.
An important question is how ready you should be? Or how ready can you be? There is so much to take into account that it is difficult to set the right priorities. And that is essential to get something done on time. In this contribution a few tips for using Role Based Access Control (RBAC) to become GDPR compliant.
The GDPR oversees the processing of personal data by organizations. This immediately means a pragmatic limitation of the scope: no personal data, then no concern for the GDPR. Conversely: where no personal data is processed, there is in fact no risk of, for example, a data breach. Now there are actually no organizations that do not process personal data, but by excluding access to personal data for people who do not have to process such data, the risk of data leaks, for example, is considerably reduced.
This mechanism can be activated if you apply Role Based Access Control within an Identity & Access Management (IAM) solution. With RBAC people gain access to systems, processes and data on the basis of the role they play in an organization. People get a role within an organization and automatically get all authorizations that are linked to that role.
This means from the perspective of GDPR two analyzes and follow-up actions:
- Analyze which authorizations for personal data are in a role.
As far as the current GDPR projects are concerned, it is already known which personal data are processed in which registrations. The business functions and processes with which this data is processed must be found in the authorization matrices, with which authorizations within the RBAC model are linked to the roles. So we can know which roles give access to personal data.
Follow-up action: analyze why these authorizations are in the individual roles and determine who approved these authorizations in the role. Have the authorizations in the role re-established within the GDPR process, or remove the authorizations (with access to personal data) from the role if there is no justification.
- Analyze which people are members of roles with authorizations for personal data.
If someone is a member of a role in which personal data can be processed, then that person also has access to personal data. Logical, but is that right? In many cases, the role assignments within organizations have grown historically and there has never been a reassessment.
Follow-up action: analyze whether people are rightly still a member of these roles. Have the membership of roles re-established within the GDPR process, or remove someone from the role if there is no justification.
Adjusting authorizations (in this case often withdrawing them) often hurts the employees who were used to working with those authorizations and who therefore CAN access personal data. But with the GDPR it becomes clear that CAN and MAY can be different things.
RBAC disclaimers..
In our experience, the roles in an RBAC environment are often developed too one-dimensionally. As a result, not all stakeholders are taken into account in the decision to place an authorization in a role or to assign a role to a person. A balanced structure of RBAC requires a more extensive analysis of business processes, systems, organization and data (flows). By means of smart role engineering solutions these both indicate that analyzes can be carried out relatively quickly and in an integrated manner and embedded in the regular IAM cycle. We are happy to help!