How to configure advanced role based access control

Ops Center Protector User Guide
Version
7.7.x
Audience
anonymous
Part Number
MK-99PRT002-08
ft:lastEdition
2023-10-26
You will need to have:
  • A Protector account with Default Administrator authority. You will already have an <Username>@master login with this authority if you installed Protector on the Master node. If you do not have an account with this authority then you will need to request one from your Protector administrator.
  • A good understanding of your organization's computing resources and the way they are managed and grouped into departments.
  • Knowledge of where computing resource will be backed up to (i.e. the storage devices to be used).
  • Knowledge of users and user groups who require access to Protector and their data protection roles and responsibilities.
  • The details of any authentication services that you intend to use to authenticate Protector users (e.g. Active Directory, LDAP, RADIUS etc.)

Refer to Access Control Concepts and Access Control UI Reference for further information.

Protector implements Role Based Access Control (RBAC) to ensure that only those users with sufficient privileges can view or modify resources. The RBAC implementation is extremely flexible and can be configured to be as open or restrictive as an organization demands.

If you require only a basic RBAC implementation then refer to How to configure basic role based access control

Alternatively, custom roles and resource groups can be created that precisely control the nodes that are visible and the operations that can be performed on them. This topic explains how to plan and implement a custom RBAC policy:

  1. Identify the computing resources within your organisation, based on geographical, divisional, departmental, functional and project groupings.
    These resources may be managed locally and/or centrally and this will also dictate how they are grouped together, for the purposes of access control when:
    • Designing data protection policies and data flows
    • Monitoring and reporting Protector performance
    • Allocating and monitoring backup storage resources
    • Auditing for compliance
    • Administrating security and access controls
    • Repurposing data for test and development
    • Executing restore and disaster recovery procedures

    For example, you might need to create the following resource groups in addition to the built-in default group:

    (The names in this example are designed only to help illustrate how the RBAC objects are assembled into hierarchies).
    • groupAccountsGlobal
    • groupLegalGlobal
    • groupHumanResourcesUS
    • groupHumanResourcesUK
    • groupDevelopmentUK
    • groupProductionPrimaryUS
    • groupProductionSecondaryUS

    For guidance, refer to How to create a resource group.

  2. Identify the generic roles (not the individuals) required within your organisation for administering computing resources and the associated data protection processes.
    For example, you might need to create the following roles based on, or in addition to, the built-in roles:
    • roleBackupAdmin
    • roleComplianceAuditor
    • roleSecurityAdmin
    • roleDevelopmentLead
    • roleProtectorUser
  3. Define precisely what activities each role should and should not be able to perform.
    Protector defines numerous Activity Groups that are cohesive collections of Activities. Normally a role would be assigned all activities in a group, however individual activities can be assigned if fine grain control is required. For example, the Logs Activity Group contains the following Activities which can be granted to a role en-mass or individually:
    • View Logs
    • Manage Logs
    • Purge Audit Logs
    • Verify Audit Logs

    For guidance on configuring Roles and their associated Activities, refer to How to create a role.

  4. Create Access Control Profiles based on the Resource Groups and Roles identified above. These ACPs combine a Role with one or more Resource Groups.
    For example, it might be necessary to create the following ACPs, in addition to the built-in Default Administrator ACP:
    • acpAccountsBackupAdmin

      - to allow roleBackupAdmin access to groupAccountsGlobal

    • acpLegalBackupAdmin

      - to allow roleBackupAdmin access to groupLegalGlobal

    • acpDevelopmentBackupAdmin

      - to allow roleBackupAdmin access to groupDevelopmentUK

    • acpProductionBackupAdmin

      - to allow roleBackupAdmin access to groupProductionPrimaryUS and groupProductionSecondaryUS

    • acpDevelopmentUser

      - to allow roleProtectorUser access to groupDevelopmentUK

    For guidance on associating Roles with Resource Groups, refer to How to create an access control profile.

  5. Identify how users will be authenticated by Protector.
    Protector supports a number of authentication protocols. If your organization has an established AD, LDAP or RADIUS authentication service or uses local accounts, then these can be used.
    For example, it might be necessary to create the following user and group accounts:
    • Donald McPhee has a UID (User ID) of donald.mcphee in the Active Directory authentication service global.widgetdev.com.

      An Authentication Space is created named widgetdev that refers to that AD service. He logs into Protector with the UPN (User Principal Name) donald.mcphee@widgetdev.

    • Pete Traynor has a UID of traynorp in the local OS Account on the Protector node WIN7-PCEA45.

      An Authentication Space is created named WIN7-PCEA45 that refers to that node. He logs in with the UPN traynorp@WIN7-PCEA45.

    • Sarah Dean has a UID of svpdean in the RADIUS service uk.widgetdev.com.

      An Authentication Space is created named uk.widgetdev that refers to that RADIUS service. She logs into Protector with the UPN svpdean@uk.widgetdev.

    • The contract development team members are in a user group that has a UID of devteam in the LDAP authentication service datadevs.biz.

      An Authentication Space is created named datadevs that refers to that LDAP service. They log in using the UPN devteam@datadevs

    For guidance, refer to How to create an Authentication Space.

  6. Associate authenticated users and user groups with Access Control Profiles (i.e. Roles and Resource Groups) so that those users are able to log on to Protector, access the resources they need and carry out the activities their roles allow.
    An individual user can be associated with more than one ACP, and an ACP can be assumed by more than one user.
    For example the following ACP Associations are required:
    • donald.mcphee@widgetdev and svpdean@uk.widgetdev are authorized to perform the activities defined by acpDevelopmentBackupAdmin on its associated resources.
    • svpdean@uk.widgetdev is, in addition, authorized to perform the activities defined by acpProductionBackupAdmin on its associated resources.
    • The entire database development team devteam@datadevs are authorized to perform the activities defined by acpDevelopmentUser on its associated resources.
    • traynorp@WIN7-PCEA45 is authorized to perform the activities defined by acpAccountsBackupAdmin and acpLegalBackupAdmin on its associated resources.

    For guidance on authorizing users with their respective Roles and Resource Groups, refer to How to create an Access Control Profile Association.

  7. It is recommended that the default ACP Association <username>@master is replaced with your own ACP associations, using dedicated usernames created in your organization's domain.
    CAUTION:
    • The default ACP Association is generated automatically when Protector is installed, to enable initial configuration of access control features. This is based on the local Windows account specified during installation. Best practice states that local accounts should be disabled on the Master to reduce security vulnerabilities.
    • The default <Username>@Master ACP association should be assigned to a user with the specific responsibility as primary Protector administrator, to ensure security is not compromised.
    • Access to the Master node should be strictly controlled to prevent malicious access to the Protector executables and associated configuration data.