Setting up an Azure target

R‑Cloud supports using an Azure target to store data in the highly available, scalable, and secure Azure cloud storage.

Prerequisites

  • To allow the HYCU Managed Service Principal (HMSP) to perform all operations on the target, you must add an Azure resource group to R‑Cloud as a source. For instructions, see Adding an Azure resource group as a source.

  • Only if you plan to select a custom Azure service principal for performing all operations on the target. The service principal must be added to R‑Cloud. You can add it as part of setting up your Azure target or by following the procedure described in Adding an Azure service principal.

  • Only if you plan to store data on an Azure target for which immutability (WORM) is enabled. You must set the enable version-level immutability support option at the storage account level. For details, see Azure documentation.

  • Only if the target is accessible exclusively from a private network. The data movers that are created during data protection operations must have access to the endpoint used by the target. Assign the data mover configuration that uses the appropriate networking parameters to the entity whose data you plan to store on the target. For details, see Creating a data mover configuration.

  • Only if you plan to enable the customer-managed target encryption without a key management service. The length of your AES-256 key must be 32 bytes.

  • Only if you plan to enable the customer-managed target encryption with a key management service. The cloud account that you want R‑Cloud to use to access the encryption key must have the required permissions assigned. The cloud account that you want R‑Cloud to use to access the encryption key must have the required permissions assigned:

    Cloud account Required permissions
    AWS IAM role

    A custom managed or inline policy with the kms:Encrypt and kms:Decrypt permissions.

    Example   

    {
      Version": "2012-10-17",
      "Statement": [
       {
        "Effect": "Allow",
        "Action": [
         "kms:Encrypt",
         "kms:Decrypt"
        ],
        "Resource": "arn:aws:kms:<Region>:
        <AccountID>:key/<KeyID>"
       }
      ]
    }
    Azure service principal (including the HMSP) The Key Vault Crypto User role assigned at the Key Vault Key level.
    Google Cloud service account (including the HMSA) The Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) assigned at the KMS crypto key level.

Limitations

  • Storing data to a publicly available target is not supported. Therefore, make sure that the Allow Blob anonymous access setting is disabled in Azure.

  • Storing data to a target for which a lifecycle management policy is configured is not supported and may result in data loss.

  • Only StorageV2 (general-purpose v2) storage accounts can be set up as a target.

  • Only if you plan to enable target encryption. The following limitations apply:

    • Target encryption is supported for SaaS applications.

    • R‑Cloud cannot encrypt data of the SaaS applications that use only snapshots for storing the data. For details, see the relevant topics for your SaaS application in Protecting SaaS applications.

    • For customer-managed target encryption with a key management service: The following keys are supported:

      • For AWS Key Management Service (KMS): Symmetric encryption KMS keys

      • For Azure Key Vault: RSA keys

      • For Google Cloud Key Management Service (KMS): Symmetric encryption keys

Considerations

  • You can set up the same target in multiple protection sets.

  • Only if you plan to store data to an Azure target for which immutability (WORM) is enabled. When backing up data, R‑Cloud sets the retention period of the immutable blob data to the retention period defined in the R‑Cloud policy.

    • Only if you plan to enable target encryption. Consider the following:

    • The R‑Cloud encryption is applied on top of the native cloud platform data encryption to provide an additional layer of security.

    • After you enable target encryption, the previously stored backup data remains unencrypted.

    • If you decide to disable target encryption, the backup data that was stored on the target while the target encryption was enabled remains encrypted.

    • The SaaS applications metadata is not encrypted.

  • Only if you plan to enable the customer-managed target encryption with a key management service. Consider the following:

    • If you disable your encryption key in cloud or unassign the required permissions from the cloud account, you will not be able to restore the data that is stored on the target or store new data on the target until you re-enable the encryption key or reassign the permissions.

    • If you delete your encryption key from cloud, you will not be able to restore the data that is stored on the target. To store new data on the target, you must reconfigure the target encryption and perform a manual full backup.

  • Only if the target is accessible exclusively from a private network. When adding such a target, R‑Cloud will not check if the target exists and if the selected cloud account has the necessary permissions to perform all operations on the target. As a result, until the first backup is performed, the target will be in the Pending state.

To access the Targets panel, in the navigation pane, click Targets Targets. Alternatively, in the Dashboard panel, click the Targets widget title.

Procedure

  1. In the Targets panel, click Add Add.

  2. Select Azure, and then click Next.

  3. In the Storage Account Name field, enter the name of the Azure storage account that will store backup data.

  4. In the Size Quota field, specify the amount of storage space that should be used for storing data (in MiB, GiB, or TiB).

    Important  The specified amount represents a soft limit, therefore actual usage may exceed it.

  5. Use the Enforce quota switch to stop running backups if this target reaches its size quota. The backups will start running again after you increase the size quota of this target or assign a different policy to the entities. Such a policy must use a target with the sufficient size quota.

  6. Only if the target is accessible exclusively from a private network. Enable the Private target switch.

  7. Only if you want to use a custom Azure service principal for performing all operations on the target.

    1. From the Cloud Account drop-down menu, select the preferred Azure service principal.

      By clicking Add Add New, you are automatically redirected to the dialog box that enables you to add the preferred cloud account to R‑Cloud, if not already added.

    2. Click Grant Consent to create a custom role that includes the necessary permissions for accessing the Azure target and to assign the role to the selected Azure service principal.

      Note  The name of the custom role is HYCU Storage Account Role.

    3. In the Azure portal, do the following:

      1. Specify the subscription and the resource group that include the target.

      2. Depending on whether you want to assign your custom role to the service principal at the subscription or resource group scope, select subscription or resource group.

      3. Click Review + create to view the summary, and then click Create.

    4. Return to the R‑Cloud web user interface.

  8. Only if you want the SaaS application data that is stored on this target to be encrypted. Under Encryption Settings, enable the Target encryption switch, and then do the following:

    1. From the Key Management Type drop-down menu, select one of the following options:

      • Select HYCU managed if you want the encryption key to be provided and managed by HYCU.

      • Select Customer managed if you want to provide and manage the encryption key by yourself.

    2. Only if you selected the Customer managed option. From the Customer Key Provider drop-down menu, select your encryption key provider:

      Encryption key provider Instructions
      AWS Key Management Service

      Select this option, and then do the following:

      1. From the Encryption Cloud Account drop-down menu, select the cloud account that you want R‑Cloud to use to access the encryption key.

        By clicking Add Add New, you are automatically redirected to the dialog box that enables you to add the preferred cloud account to R‑Cloud, if not already added.

      2. In the Key ARN field, enter the AWS KMS Amazon Resource Name (ARN) of the encryption key in the following format:

        arn:aws:kms:<Region>:<AccountID>:key/<KeyID>

      Azure Key Vault

      Select this option, and then do the following:

      1. From the Encryption Cloud Account drop-down menu, select the cloud account that you want R‑Cloud to use to access the encryption key.

        By clicking Add Add New, you are automatically redirected to the dialog box that enables you to add the preferred cloud account to R‑Cloud, if not already added.

      2. In the Key Identifier field, enter the Azure Key Vault key identifier in the following format:

        https://<VaultName>.vault.azure.net/keys/<KeyName>

      Google Cloud Key Management Service

      Select this option, and then do the following:

      1. From the Encryption Cloud Account drop-down menu, select the cloud account that you want R‑Cloud to use to access the encryption key.

        By clicking Add Add New, you are automatically redirected to the dialog box that enables you to add the preferred cloud account to R‑Cloud, if not already added.

      2. In the Crypto Key Resource Name field, enter the resource name of the Google Cloud KMS cryptographic key in the following format:

        projects/<ProjectID>/locations/<LocationName>
        /keyRings/<KeyRingName>/cryptoKeys/<CryptoKeyName>

      Custom key file

      Select this option, and then, in the AES-256 Encryption Key field, browse for and select your AES-256 binary key.

  9. Click Save.

The target is added to the list of targets in the Targets panel. For details on managing targets, see Managing targets.