Planning and implementing your Azure Information Protection tenant key

Applies to: Azure Information Protection, Office 365

Use the information in this article to help you plan for and manage your Azure Information Protection tenant key. For example, instead of Microsoft managing your tenant key (the default), you might want to manage your own tenant key to comply with specific regulations that apply to your organization. Managing your own tenant key is also referred to as bring your own key, or BYOK.

What is the Azure Information Protection tenant key?

  • The Azure Information Protection tenant key is a root key for your organization. Other keys can be derived from this root key, such as user keys, computer keys, and document encryption keys. Whenever Azure Information Protection uses these keys for your organization, they cryptographically chain to your Azure Information Protection tenant key.

  • The Azure Information Protection tenant key is the online equivalent of the Server Licensor Certificate (SLC) key from Active Directory Rights Management Services (AD RMS).

At a glance: Use the following table as a quick guide to your recommended tenant key topology. Then, use the additional documentation for more information.

Business requirement Recommended tenant key topology
Deploy Azure Information Protection quickly and without special hardware, additional software, or an Azure subscription.

For example: Testing environments and when your organization does not have regulatory requirements for key management.
Managed by Microsoft
Compliance regulations, additional security, and control over all life cycle operations.

For example: Your key must be protected by a hardware security module (HSM).
BYOK [1]

If required, you can change your tenant key topology after deployment, by using the Set-AadrmKeyProperties cmdlet.

Choose your tenant key topology: Managed by Microsoft (the default) or managed by you (BYOK)

Decide which tenant key topology is best for your organization. By default, Azure Information Protection generates your tenant key and manages most aspects of the tenant key lifecycle. This is the simplest option with the lowest administrative overheads. In most cases, you do not even need to know that you have a tenant key. You just sign up for Azure Information Protection and the rest of the key management process is handled by Microsoft.

Decide which tenant key topology is best for your organization:

  • Managed by Microsoft: Azure Information Protection automatically generates a tenant key for your organization. By default, Microsoft uses this key for your tenant and manages most aspects of your tenant key life cycle.

    This is the simplest option with the lowest administrative overheads. In most cases, you do not even need to know that you have a tenant key. You just sign up for Azure Information Protection and the rest of the key management process is handled by Microsoft.

  • Managed by you (BYOK): For complete control over your tenant key, use Azure Key Vault with Azure Information Protection. For this tenant key topology, you create the key, either directly in Key Vault, or create it on-premises. If you create it on-premises, you next transfer or import this key into Key Vault. You then configure Azure Information Protection to use this key, and you manage it in Azure Key Vault.

More information about BYOK

To create your own key, you have the following options:

  • A key that you create on-premises and transfer or import to Key Vault:

    • An HSM-protected key that you create on-premises and transfer to Key Vault as an HSM-protected key.

    • A software-protected key that you create on-premises, convert, and then transfer to Key Vault as an HSM-protected key. This option is supported only when you migrate from Active Directory Rights Management Services (AD RMS).

    • A software-protected key that you create on-premises and import to Key Vault as a software-protected key. This option requires a .PFX certificate file.

  • A key that you create in Key Vault:

    • An HSM-protected key that you create in Key Vault.

    • A software-protected key that you create in Key Vault.

Of these BYOK options, the most typical is an HSM-protected key that you create on-premises and transfer to Key Vault as an HSM-protected key. Although this option has the greatest administrative overheads, it might be required for your organization to comply with specific regulations. The HSMs that are used by Azure Key Vault are FIPS 140-2 Level 2 validated.

With this option, the following happens:

  1. You generate your tenant key on your premises, in line with your IT policies and security policies. This key is the master copy. It remains on-premises and you are responsible for backing it up.

  2. You create a copy of this key, and securely transfer this copy from your HSM to Azure Key Vault. Throughout this process, the master copy of this key never leaves the hardware protection boundary.

  3. The copy of the key is protected by Azure Key Vault.

Note

As an additional protection measure, Azure Key Vault uses separate security domains for its data centers in regions such as North America, EMEA (Europe, Middle East and Africa), and Asia. Azure Key Vault also uses different instances of Azure, such as Microsoft Azure Germany, and Azure Government.

Although it’s optional, you will also probably want to use the near real-time usage logs from Azure Information Protection to see exactly how and when your tenant key is being used.

When you have decided your tenant key topology

If you decide to let Microsoft manage your tenant key:

  • Unless you are migrating from AD RMS, no further action is required for you to generate the key for your tenant and you can go straight to Next steps.

  • If you currently have AD RMS and want to migrate to Azure Information Protection, use the migration instructions: Migrating from AD RMS to Azure Information Protection.

If you decide to manage your tenant key yourself, read the following sections for more information.

Implementing BYOK for your Azure Information Protection tenant key

Use the information and procedures in this section if you have decided to generate and manage your tenant key; the bring your own key (BYOK) scenario:

Note

If you have started to use Azure Information Protection with a tenant key that is managed by Microsoft and you now want to manage your tenant key (move to BYOK), your previously protected documents and emails will remain accessible by using an archived key.

Prerequisites for BYOK

See the following table for a list of prerequisites for bring your own key (BYOK).

Requirement More information
Your Azure Information Protection tenant must have an Azure subscription. If you do not have one, you can sign up for a free account.

To use an HSM-protected key, you must have the Azure Key Vault Premium service tier.
The free Azure subscription that provides access to configure Azure Active Directory and configuration of Azure Rights Management custom templates (Access to Azure Active Directory) is not sufficient to use Azure Key Vault. To confirm that you have an Azure subscription that you can use for BYOK, use the Azure Resource Manager PowerShell cmdlets:

1. Start an Azure PowerShell session with the Run as administrator option, and sign in as a global admin for your Azure Information Protection tenant with the following command: Login-AzureRmAccount

2. Type the following and confirm that you see values displayed for your subscription name and ID, your Azure Information Protection tenant ID, and that the state is enabled: Get-AzureRmSubscription

If no values are displayed and you are simply returned to the prompt, you do not have an Azure subscription that can be used for BYOK.

Note: In addition to the BYOK prerequisites, if you are migrating from AD RMS to Azure Information Protection by using software key to hardware key, you must have a minimum version of 11.62 for the Thales firmware.
To use an HSM-protected key that you create on-premises: All the prerequisites listed for Key Vault BYOK. See Prerequisites for BYOK from the Azure Key Vault documentation.

Note: In addition to the BYOK prerequisites, if you are migrating from AD RMS to Azure Information Protection by using software key to hardware key, you must have a minimum version of 11.62 for the Thales firmware.
The Azure Rights Management administration module for Windows PowerShell. For installation instructions, see Installing Windows PowerShell for Azure Rights Management.

If you have previously installed this Windows PowerShell module, run the following command to check that your version number is at least 2.9.0.0: (Get-Module aadrm -ListAvailable).Version

For more information about Thales HSMs and how they are used with Azure Key Vault, see the Thales website.

Choosing your key vault location

When you create a key vault to contain the key to be used as your tenant key for Azure Information, you must specify a location. This location is an Azure region, or Azure instance.

Make your choice first for compliance, and then to minimize network latency:

  • If you have chosen the BYOK key topology for compliance reasons, those compliance requirements might mandate the Azure region or Azure instance that stores your Azure Information Protection tenant key.

  • Because all cryptographic calls for protection chain to your Azure Information Protection tenant key, you want to minimize the network latency that these calls incur. To do that, create your key vault in the same Azure region or instance as your Azure Information Protection tenant.

To identify the location of your Azure Information Protection tenant, use the Get-AadrmConfiguration​ PowerShell cmdlet and identify the region from the URLs. For example:

LicensingIntranetDistributionPointUrl : https://5c6bb73b-1038-4eec-863d-49bded473437.rms.na.aadrm.com/_wmcs/licensing

The region is identifiable from rms.na.aadrm.com, and for this example, it is in North America.

Use the following table to identify which Azure region or instance is recommended to minimize network latency.

Azure region or instance Recommended location for your key vault
rms.na.aadrm.com North Central US or East US
rms.eu.aadrm.com North Europe or West Europe
rms.ap.aadrm.com​ East Asia or Southeast Asia
rms.sa.aadrm.com West US or East US
rms.govus.aadrm.com​ Central US or East US 2

Instructions for BYOK

Use the Azure Key Vault documentation to create a key vault and the key that you want to use for Azure Information Protection. For example, see Get started with Azure Key Vault.

Make sure that the key length is 2048 bits (recommended) or 1024 bits. Other key lengths are not supported by Azure Information Protection.

To create an HSM-protected key on-premises and transfer it to your key vault as an HSM-protected key, follow the procedures in How to generate and transfer HSM-protected keys for Azure Key Vault.

A key that is stored in Key Vault has a key ID. This key ID is a URL that contains the name of the key vault, the keys container, the name of the key, and the key version. For example: https://contosorms-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333. You must configure Azure Information Protection to use this key, by specifying its Key Vault URL.

Before Azure Information Protection can use the key, the Azure Rights Management service must be authorized to use the key in your organization's key vault. To do this, the Azure Key Vault administrator uses the Key Vault PowerShell cmdlet, Set-AzureRmKeyVaultAccessPolicy and grants permissions to the Azure Rights Management service principal, by using the GUID 00000012-0000-0000-c000-000000000000. For example:

Set-AzureRmKeyVaultAccessPolicy -VaultName 'ContosoRMS-kv' -ResourceGroupName 'ContosoRMS-byok-rg' -ServicePrincipalName 00000012-0000-0000-c000-000000000000 -PermissionsToKeys decrypt,sign,get

You're now ready to configure Azure Information Protection to use this key as your organization's Azure Information Protection tenant key. Using Azure RMS cmdlets, first connect to the Azure Rights Management service and sign in:

Connect-AadrmService

Then run the Use-AadrmKeyVaultKey cmdlet, specifying the key URL. For example:

Use-AadrmKeyVaultKey -KeyVaultKeyUrl "https://contosorms-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333"

Important

In this example, "aaaabbbbcccc111122223333" is the version of the key to use. If you do not specify the version, the current version of the key is used without warning and the command appears to work. However, if your key in Key Vault is later updated (renewed), the Azure Rights Management service will stop working for your tenant, even if you run the Use-AadrmKeyVaultKey command again.

Make sure that you specify the key version, in addition to the key name when you run this command. You can use the Azure Key Vault cmd, Get-AzureKeyVaultKey, to get the version number of the current key. For example: Get-AzureKeyVaultKey -VaultName 'contosorms-kv' -KeyName 'contosorms-byok'

If you need to confirm that the key URL is set correctly for Azure Information Protection: In Azure Key Vault, run Get-AzureKeyVaultKey to see the key URL.

Finally, if the Azure Rights Management service is already activated, run Set-AadrmKeyProperties to tell Azure Information Protection to use this key as the active tenant key for the Azure Rights Management service. If you do not do this step, Azure Information Protection will continue to use the default Microsoft-managed key, that was automatically created for your tenant.

Next steps

Now that you've planned for and if necessary, created and configured your tenant key, do the following:

  1. Start to use your tenant key:

    • If you haven’t already done so, you must now activate the Rights Management service so that your organization can start to use Azure Information Protection. Users immediately start to use your tenant key (managed by Microsoft, or managed by you in Azure Key Vault).

      For more information about activation, see Activating Azure Rights Management.

    • If you had already activated the Rights Management service and then decided to manage your own tenant key, users gradually transition from the old tenant key to the new tenant key, and this staggered transition can take a few weeks to complete. Documents and files that were protected with the old tenant key remains accessible to authorized users.

  2. Consider using usage logging, which logs every transaction that the Azure Rights Management service performs.

    If you decided to manage your own tenant key, logging includes information about using your tenant key. See the following snippet from a log file displayed in Excel where the KeyVaultDecryptRequest and KeyVaultSignRequest request types show that the tenant key is being used.

    log file in Excel where tenant key is being used

    For more information about usage logging, see Logging and analyzing usage of the Azure Rights Management service.

  3. Manage your tenant key.

    For more information about the life cycle operations for your tenant key, see Operations for your Azure Information Protection tenant key.

Comments

Before commenting, we ask that you review our House rules.