RBAC

RBAC is associated with the idea of least privilege, where each user or process is only allowed minimal access to the information, data and resources needed to carry out their role, nothing more.

When calling on role-based access controls, organizations must first determine what a particular user needs to do to carry out their job – and then create or assign the right role (access policies) that only permit them to perform the specific tasks related to their position. If at any point in the future they need more or additional permissions, only then are their permissions expanded. The opposite should be avoided in creating overly-broad permission and restricting them later.

Why is RBAC important?

RBAC controls that implement least privilege reduce data security risks and enhance data privacy so only those who must be given access to sensitive data are actually granted access. What is more, organizations implement RBAC controls to meet the regulatory requirements for security and privacy since there is tight control over how data is accessed. Additionally, with RBAC in place, organizations can implement separation of duties with respect to access to and use of applications.

Roles, Permissions and Scopes

Let’s look at some of the relevant terms tied to RBAC.

The first is the idea of a role. Roles are created related to a user’s job, so a user will be assigned a role for specific levels of access, i.e., what they can or cannot do, defined by permissions.

Roles can range from admin or superuser, to user, editor, viewer, reader, etc. and each consists of a handful of permissions.

Once a role is created, permissions are then assigned to define what that particular role is allowed to do. Permissions can span from full privileges to edit and delete to partial permissions to draft a policy, for example, without being able to approve and provision it, to only being able to view resources. Least privilege is very relevant here in order to assign the least amount of access necessary for an employee to get their job done.

To further enhance the impact of least privilege we can add scopes to define or limit what resources access (via the right role with permissions) will be granted to.

Benefits of RBAC

There are a number of benefits of role-based access control, including:

• Rather than one-off, ad-hoc granting of permissions, the roles in RBAC make access management well-defined and repeatable.
• Letting organizations fulfill compliance obligations with respect to data privacy.
• Taking the mystery out of figuring out what users have what access permissions and privileges.
• Allows for clear separation of duties in enterprises.

An RBAC example with micro-segmentation

Let’s look at an RBAC example for the creation and provisioning of micro-segmentation policy for an ERP application. The application owner knows the application best, so we’d like for them to create the policy, but we want administrators to review the policy and provision it.

For starters, the app owner is assigned a Limited Ruleset Manager role. That role has permissions of adding, editing, and deleting all segmentation rulesets. However, the scope of where they are able to operate is limited to the ERP application, wherever it may be in the development cycle and wherever the ERP app workloads may reside. In other words, they can only see and create policies for the ERP app.

Once the ERP owner has created the appropriate segmentation policies, a role with greater, “global” permissions will then review and provision (push live) the policy created by the application owner.

As you can see, RBAC allows for strong separation of duties between app owners and IT admins and organizations know precisely what someone assigned the role of ruleset manager can and cannot do.