RBAC (or role-based access control) is a network access control method that aligns users’ privileges with their role in an organization. Unlike other security controls, RBAC is a flexible way to limit unnecessary access to data regardless of how an organization is structured internally. For example, an organization may wish to grant access to financial resources — that other departments do not require — only to accounting users. This is done to reduce the risk of unauthorized access to sensitive information. Access can also be granted with different privileges, such as granting junior roles in an organization only access to read resources but not update, delete or add new data.
In light of the increased number of targeted data breaches, RBAC is becoming even more crucial as organizations struggle to keep their data secure. Not only do data breaches hurt a company's credibility, they can be highly costly as well. According to research
by the Ponemon Institute, the average cost borne by an organization when responding to a data breach was $4.24 million in 2021.
It is vital to limit internal and external access to resources and information to secure data. One of the main components of data governance
is providing the least privilege access to data. This means that it should only be possible for users to access the resources they need to do their jobs and nothing more. One of the main principles of data governance is providing employees least privilege access to data.
How does role-based access control work?
RBAC allows organizations to apply granular controls to users to control what functions employees can perform. By assigning users to “roles,” we associate them with groups of people who share specific characteristics. For example, roles are usually defined based on location, department, seniority level, or job requirements. The more detailed the roles, the more precise the controls applied to specific users.
Following the definition of roles, administrators can begin to define their permissions. Here are a few items to think about :
- Access – What data and applications can the user see and access?
- Operations – What is the user allowed to read, write, update, and delete?
- Sessions – How long is the user allowed to stay logged into the system?
Once these desired permissions have been defined for each type of role, we can further refine tune even more with four subtypes of RBAC that can be applied to create even more flexibility.
- Flat (Level 1) – Employees are associated with roles that define the permissions applied to that user.
Hierarchical (Level 2) – Senior employees have expanded permissions and inherit access to levels granted to junior levels of their assigned role.
Constrained (Level 3) – This type of RBAC incorporates all the elements of Hierarchical RBAC and adds separation of duties in role permissions.
Symmetrical (Level 4) – This level includes all the elements of constrained RBAC and adds a periodic review of role permissions.
RBAC offers several benefits due to its flexibility and mechanics. RBAC simplifies assigning roles to users, allowing organizations to maximize their operational efficiency. New users can be onboarded quickly since they only need to be assigned a role and granted access based on predetermined criteria. As users move up the ranks or change departments, they can also gain new permissions or have their access changed without creating a new account. There is also a reduced risk of granting users more permissions than needed since roles and access levels are predetermined.
Due to the coarse-grained access control, RBAC is also an effective solution for permissioning in compliance-related contexts. This can be especially useful when organizations need to meet local regulations promptly. For example, it can be beneficial to adopt a data-centric approach leveraging permissions such as location or role if an administrator is building a system around regulatory compliance as in GDPR or HIPAA.
Examples of role-based access control
Role-based access control can streamline security permissions across many different areas. For instance, an organization, which manages a web application, can create multiple roles for users within their organization.
Software Engineers – Granted access to resources such as GitHub and AWS. GitHub permissions and access within the codebase are limited to junior developers, while senior engineers are granted broader privileges.
Marketing – They have access to Google Analytics, Facebook Ads, and Google Ads. Update and write access are limited to the senior marketing manager for channel use, while other users are restricted with view access only.
Finance – Granted access to Xero and ADP. Permissions within finance are then restricted based on how the user serves the organization; payroll administrators have access to employees’ financial information, while accounts payable is limited to the organization’s financial data and applications.
Human Resources – Granted Administrator access to BambooHR and employee data as required for their job.
However, the complexity of these controls can cause security teams to encounter several pain points. In particular, RBAC’s coarse level of access control can make it difficult to manage systems. Even so, we see that granularity is still required for restricting how users within departments access resources, such as limiting access to junior employees or blocking access to payroll information by employees within the same department.
Complexity can cause "role explosions.” When organizations want more granularity, new roles in the system are created. As applications and access requirements change, this can result in hundreds or thousands of new roles that need to be managed.
RBAC also requires data teams to define access policies in advance. This requires organizations to retrofit existing policies if new ones are introduced or changed. If, for instance, an American company does business in the EU, the GDPR data locality compliance requirements are strictly defined in terms of where data may be stored and processed. As a result, the organization must redefine its existing policies to ensure the GDPR compliance of all RBAC roles.
Best practices for your data governance policy
In situations where role-based access control might be too broad for the application of security controls, attribute-based access control, or ABAC, can offer a viable alternative, granting access to resources or information based on user, environment, or resource attributes. Usually, RBAC controls define broad access for all in an organization, while ABAC takes a more granular approach. Administrators often combine RBAC and ABAC methods to comprehensively meet stringent data governance requirements to get the best of both worlds.
To define your organization's data governance policy, you should begin by mapping out the software, hardware, and applications that require security controls, as well as the roles and characteristics of users who need access to them. This blueprint allows administrators to define, document, and socialize policies that govern access to these resources and their related data and map out how they will be applied.
As your organization and resources grow, don’t forget to test, validate regularly, and optimize your data governance policies.
Out-of-the-box ABAC with Fauna
Fauna is a transactional and serverless database delivered as a secure cloud API with native GraphQL
support. Fauna offers attribute-based access control
for fine-grained access and permissioning for users in an organization. It’s free to try and takes minutes to spin up a new database.
Sign-up for free
Quick start guide