The Rubrik Andes 5.2 release, now Generally Available, introduced a variety of capabilities to advance enterprise security, compliance, and resilience. One of our most significant enhancements is with our Role-Based Access Control (RBAC) capability, which is designed to help maximize operational efficiency, safeguard against unauthorized access, reduce admin and IT support work, and make it easier to meet audit requirements. Least privilege—the practice of assigning each user the precise amount of privileges to perform their jobs and nothing more—is one of the most fundamental security principles. With our new RBAC capabilities, you can now enforce least privilege and separation of duties policies and achieve all of the above benefits.
What is new for RBAC?
Andes 5.2 introduces the following three RBAC roles:
Each organization has different requirements and operational processes. Oftentimes, the pre-defined build-in roles won’t be specific enough. They either grant too few or too many privileges that each user needs to undertake. To resolve this problem, Andes 5.2 allows you to create custom roles that grant the precise privileges based on your users’ responsibilities at a more fine-grained level.
Infrastructure Administrator Role
This role is designed for IT personas who are responsible for setting up the environment for CDM but should not have any access to data sources or operate any backup and recovery operations.
The Read-Only Administrator role is a predefined default role with read-only access privilege. The role is designed for an auditor persona who should have privileges to view all the information on CDM but should not execute any operations.
How does CDM RBAC work?
Essentially, a role is a collection of permission and operation actions that you can apply to users. Using roles makes it easier to add, remove, and adjust permissions rather than assigning permissions to users or user groups. As your user base increases in scale and complexity, roles become particularly useful.
Predefined Default Roles
Our solution supports two predefined default roles: AdministratorRole and ReadOnlyAdminRole. They are the most commonly used roles in most of the organizations. The permissions of these roles have been predefined and can be directly assigned to individual users or user groups. AdministratorRole will have all the privileges and permissions for the entire system. ReadOnlyAdminRole, as described above, will have read privilege for the whole CDM.
With Custom Role, administrators can grant precise privileges based on each persona’s responsibilities. Custom Roles consist of protectable objects, resources, and privileges. Role creation is very simple to set up, and our UI wizard guides you through the entire process:
Protectable objects are the data sources that the persona can backup and recover. The protectable object structure is consistent with the inventory page and allows administrators to assign objects at any granular-levels. Moreover, with the enhancement in Andes 5.2, administrators can assign the entire protectable object type, and all the future objects will be automatically be assigned without further users intervention. This can future reduce the operation burden off the administrator’s shoulder.
Resources, such as SLA Domains and Reports, are necessary for some personas to carry on their daily operation responsibilities. Administrators can assign specific resources to custom roles.
Privileges can be broken down into three sections: Protection, Recovery, and Data Source Management. Rubrik supports a granular level of privileges.
One of the main goals of RBAC is to only grant employees the access they need to do their jobs and prevent them from having irrelevant access. A well-designed RBAC system also simplifies and streamlines the administration of access. Here are some best practices when implementing role-based access controls:
Enforce least privilege
Define roles strictly based on persona’s duties and responsibilities. Setting up roles for the least privilege is a best practice for reducing security risk, both from malicious intent and user errors.
Multiple role assignment
Our RBAC is designed to be an additive model, so if users have overlapping role assignments, users’ effective permissions are the union of the role assignments. Consider overlapping role assignment only if the user is indeed delegated to a different set of duties.
End-User role consolidation
End-User role prior to 5.2 was designed to assign permissions to each individual user or user group. Now, End-User roles will be replaced by the Custom Role, and all the End-User roles will be migrated to Custom Roles automatically. The recommendation is to consolidate these individual End-User roles into few custom roles, which can help reduce the operation burden and the potential attack surface.
Make roles reusable
One of the benefits of the RBAC is to reduce administrative work. Make sure the roles you defined are applicable to groups of individual users; otherwise, your RBAC model will be unwieldy and minimize efficiency and simplification. We also recommend consolidating automatically migrated End-User roles so you can take full advantage of our enhanced RBAC model.
The RBAC configuration will need to be constantly adjusted based on your organization changes. It’s common that the first iteration of RBAC will require some tweaking overtime. Take good advantage of our User summary page and Role summary page directly from our UI to evaluate your RBAC configuration setting and make change accordingly.
Data is the crown jewels of most of the organization. A core business function of any organization is protecting data. An RBAC system can ensure the company’s information meets privacy and confidentiality regulations. We are here to help you achieve these goals.