Role-Based Access Control


Role-based access control (RBAC) is the security model by which Metallic defines which users or user groups can perform which actions on which entities. Use of RBAC can help ensure that individuals are only given the permissions necessary to perform their jobs.

There are three components of role-based access control:

  • User or User Group: A user or collection of users who have been given access to the Metallic Hub as part of a tenant

  • Role: A collection of permissions that defines the level of access granted to a user or a user group. Permissions allow users to perform tasks such as performing backup, restore, and administrative operations (for example, license administration) on entities.

  • Entity: A logical or physical component that a user can access, based on their role. Examples of entities are a client, a storage policy, or a plan.

Definitions of Important Terms

  • Client: A client is any entity for which an agent is deployed. An agent is used for operations such as data protection and archiving. Examples of clients are NAS devices, Microsoft 365 applications, and databases.

  • Company: Each organization which has subscribed to Metallic is assigned as a tenant within Metallic. Metallic manages and protects the organization’s data. In the context of Metallic, a company is the same as a tenant.

Creating a Security Association

A security association is a three-way mapping of users, a role, and entities. A user must have administrator rights to create users, roles, and associations with entities.

Before creating a security association, the necessary users/user groups and roles must first be defined:

  • For more information about creating users and user groups, see Users and User Groups.

  • For roles, you can start with the roles listed in the "Preconfigured Roles" section listed below, and then later modify the permissions associated with those roles, or you can configure new, custom roles.

To create a security association, the entity is selected, a user or user group is selected, and then a role is assigned to the selected user or user group. For examples of the steps used to create security associations, see Creating Security Associations for Role-Based Access Control.

Preconfigured Roles

Metallic has some preconfigured roles that are designed to address the most common use cases. By using preconfigured roles, the administrator avoids the need to construct custom roles from a collection of permissions.




Alert Owner

Add/delete/edit notifications, add/remove recipients of alerts, change security settings

Company level

Browse and Restore

Ability to browse and restore the data of all or selected clients, such as file servers, NAS devices, and Microsoft 365 applications

Company, client, subclient

Office 365 Self Service

Ability to browse and restore all or selected Microsoft 365 application data

Company, Microsoft 365 applications

Tenant Admin

Superuser who can manage all the operations within Metallic

Company level

Custom Roles

To create custom roles, see Managing Roles.

Role Conflicts

When creating RBAC security associations, it is possible to have conflicting roles at different levels of the organization, such as at the company and client levels. In these cases, it is important to understand which role takes precedence.

For example, let's say a user has been assigned the Browse and Restore role at the company level, but only the Browse role at a specific client level, for example, the File Server client. In this case, the user can restore data at the client level, even though their access level at the client level only includes Browse privileges.

Conversely, if a user has been assigned the Browse role at the company level, but the Browse and Restore role at a specific client level, the user is only able to restore data for that specific client. For all other clients, the user can only browse data and not restore data.

Role conflicts can occur if, for any given level, there are two or more roles that have been assigned to the same user or user group. This happens because of the inheritance of roles. For example, if role A is assigned to a user at a company level, role A is inherited down to all the client levels in that company and the user has the same role A for all the clients under that company. If role B is assigned to the same user for a particular client there is a role conflict, so the system takes the union of permissions across the different roles. The system does not prioritize one role over another.

If you provide a role with more powerful permissions at a higher level (for example, a company level), you cannot restrict that role at a lower level (for example, a client level) by assigning it a different role. Instead, assign a less powerful role at the higher level and then add more powerful roles for specific objects at lower levels.