Role-based Access Control: Five steps to Effective Access Management

Defining and granting access rights is a constant challenge for IT departments. On the one hand, operational processes must not be disrupted by unnecessary restrictions, while on the other hand, it is essential to avoid overly broad rights and thus potential points of attack. The least privilege approach promises a balance between productivity and security. Its implementation in turn benefits sustainably from the implementation of role-based access control. If roles and associated authorisations are preconfigured, manual, error-prone system settings become obsolete.

What is Role-based Access Control (RBAC)?

Role-based access control is a procedure for managing and controlling access to files or services. Instead of giving users in the network direct access rights to various systems or making spontaneous decisions about who may access what and for how long, access is granted according to a role previously assigned to the user. In this way, RBAC supports the implementation and systematic enforcement of a least privilege strategy - even in large and geographically distributed companies, which is why the RBAC concept is often used in particular in companies with more than 500 employees. This ensures that employees always have the rights they need and that there are no business interruptions, while RBAC also eliminates overly broad rights and thus potential gateways for hackers and inside attackers.

Although the RBAC model has been in use for years, its consistent implementation is becoming increasingly difficult due to the complexity of modern use cases. The rapid increase in cloud services and third-party software makes a uniform approach to role-based access control indispensable, as this is the only way to effectively reduce risks and meet compliance requirements in the long term.

Five steps to RBAC

Effective implementation of role-based access control involves the following five steps:

• Inventory: The first step is to create a comprehensive list of all servers, databases, applications, external websites, etc. to which users need access. Optionally, physical security can also be included in this list, covering access to server rooms or other sensitive physical spaces and resources. An overview of who (or what) currently has access to these systems and resources must then be created.
• Define role permissions: The next step for the IT department is to define the roles that reflect the structure of the company - be it accounting, sales, customer care, etc. - and determine what resources they can access or what actions employees in that role must take to complete their work. Resource here means a programme, website, application or other tool, and actions include viewing, creating, modifying or deleting certain information. For example, an accountant needs access to certain financial resources and accounting software packages to perform her core tasks. All roles can be defined globally or specifically based on organisational needs. Changes and updates to a role's permissions can be made as needed and immediately communicated to all users.
• Document RBAC policies: Next, the defined and implemented RBAC policy should be well documented, even if an automated tool is used in the implementation. Many compliance policies require that access control policies are thoroughly documented and that this documentation is subject to a change control process to ensure that it is always up-to-date. With the move to cloud infrastructures, SaaS applications and the convenience of SSO, users and groups often inherit roles with excessive permissions and RBAC helps mitigate this risk.
• Assigning the users to the defined roles: Each individual user must be assigned to at least one role from the previously defined role library according to their function. The basis for this assignment should always be the least privilege approach.
• Conduct regular audits: To ensure that users are always assigned the correct roles and that each role has the appropriate permissions, regular audits should be conducted. Adjustments must always take place, especially in the event of internal position changes, project expiry, etc. Also, one-off changes or extensions of rights should never be made for an individual employee. Either the authorisations for the entire role must be updated or a new role must be created for the user.

In principle, IT departments should design role-based access control so flexibly that it is possible to define roles and their restrictions entirely according to individual requirements, wishes and prerequisites. This includes, in particular, limiting permissions based on a specific project, setting a time limit or expiry date, applying permissions based on geographical location or restricting permissions by time of day.

The challenge of overlapping role assignments

Many users are assigned more than one role, so the implications of overlapping role assignments must be considered and permissions defined for appropriate combinations. In cases where a user has multiple roles, an administrator must therefore configure how RBAC is applied so that potential conflicts between roles are addressed and the employee does not end up with more permissions than intended.

In doing so, RBAC essentially distinguishes between two types of separation of duty: static (Static Separation of Duty) and dynamic (Dynamic Separation of Duty). Mutually exclusive role restrictions are used to enforce static separation of duty policies, while dynamic separation is intended to restrict the permissions available to a user.

To further codify the assignment and inheritance of permissions, the National Institute of Standards and Technology (NIST) has established four levels that define groups: ?????????????????????

• Flat: Users gain permissions by being assigned roles, and then are given the permissions directly associated with their role. For example, there may be a single, broad role called "Admin" that is assigned to all users who need admin permissions.
• Hierarchical: Levels and relative role relationships can be used to define a permissions hierarchy, along with associated rules for how those permissions are inherited, e.g. for enterprise admins vs. domain admins.
• Restricted: To enforce segregation of duties, users can be restricted to perform only certain actions based on the roles they are assigned, depending on which systems or applications they use.
• Symmetric: This approach is used to maintain consistent standards. Available objects, roles and permissions must be exactly the same in all systems and applications, regardless of where they are used.

Conclusion

Role-based access control simplifies common IT administration tasks such as adding a new user, moving a person to another department or even deleting a user, thus reducing the burden on the IT department. When used systematically, RBAC reduces the risk of granting too much access to a user and thus promotes the implementation of a least-privilege strategy. With clearly defined roles, protocols are created specifying exactly which role is appropriate for which type of user, preventing inappropriate inheritance of permissions. In the event of a compromise, permissions can also be blocked extremely quickly and on a large scale, effectively preventing the spread of cyber attacks.