Role Based Access Control model (RBAC)
The Role Based Access Control model, or RBAC, is the model which will grant or revoke permissions and rights to semi-privileged users. This is effectively another way to call the Delegation Model. Any "Access Control" model relies on a set of tasks. These tasks are grouped together. Then this group gets populated to provide controlled access to the resources.
In this model, we will define roles, which are a collection of permissions. These roles will be assigned to users or groups, allowing them to perform specific tasks without having full control over the server or the database.
RBAC is based on the principle of least privilege, which means that users should only have the minimum level of access necessary to perform their job functions.
This model is widely used in various systems and applications, including operating systems, databases, and cloud services. It provides a flexible and scalable way to manage user permissions and access rights.
An RBAC consist of several components, depending on the role itself:
- A resource (or several) to protect
- Access Control List associated to the resource
- A Group which is reference on the ACL
- A Group for the security principals which need access to the resource
- Security Principals (users)
In this model, the resource is protected by an Access Control List (ACL), which defines the permissions for different users or groups. The ACL is associated with a group, which is then populated with security principals (users) who need access to the resource.
The security principals are assigned to a group, which is then granted permissions on the resource through the ACL. This way, users can be easily added or removed from the group, and their access to the resource can be managed centrally through the ACL.
The key factors when designing this model are Least Privileged Access and Segregation of Duties. This is why most of our resources do not provide enough security, or at least flexibility. Having a single role (like Administrator or root) will jeopardize the security. Yes, we have all that we need. Even worst, way more of what we need. Other point to consider; security principal directly defined into an ACL, no way. So we need extra groups and nesting strategy. But how many groups? Enough to abstract the resource/ACL from the security principal, but the least to maintain control and security. The use of RBAC to manage user privileges (computer permissions) within a single system or application is widely accepted as a best practice.
SQL database example
Lets imagine I need access to a SQL database. Of course the Administrator has “Full Control” over the db, but not limited to it. It also has the same control over the server hosting the DB. This example is the opposite of Least Privileged Access. In this example we can consider 6 roles, just as an example.
These roles are:
- Server Administrator. Full admin access to the server hosting SQL
- db_owner. Perform all configuration and maintenance activities on the database, and can also drop the database in SQL Server
- db_securityadmin. Modify role membership for custom roles only and manage permissions
- db_backupoperator. Back up the database
- db_datawriter. Add, delete, or change data in all user tables
- db_datareader. Read all data from all user tables
In this example, we can have 6 different roles, each one with a specific set of permissions. The “Server Administrator” role is the most powerful one, as it has full control over the server hosting the SQL database. The other roles have more limited permissions, allowing users to perform specific tasks without having full control over the server or the database.
From the 6 role above mentioned, 5 are specific SQL resources. 1 is server default administrator. In this example, we can create the 5 SQL resources as server local groups, and then populate those with Active Directory groups. Now we can have our "Data-Generation-Department" group nested in each of the db_datawriters groups of SQL servers. This group will have evenly granted rights across all SQL servers.
In this example, we can see how RBAC provides a flexible and scalable way to manage user permissions and access rights. By defining roles and associating them with users or groups, we can ensure that access is granted based on the principle of least privilege.