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.
The on-premises equivalent of the Azure Information Protection tenant key is known as the Server Licensor Certificate (SLC) key. Azure Information Protection maintains one or more keys for each organization that has a subscription for Azure Information Protection. Whenever keys are used for Azure Information Protection within an organization (such as user keys, computer keys, document encryption keys), they cryptographically chain to your Azure Information Protection tenant key.
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.
If you deploy Azure Information Protection by using a tenant key that is managed by Microsoft, you can change to BYOK later. However, you cannot currently change your Azure Information Protection tenant key from BYOK to managed by Microsoft.
|Business requirement||Recommended tenant key topology|
|Deploy Azure Information Protection quickly and without requiring special hardware||Managed by Microsoft|
|Need full IRM functionality in Exchange Online with the Azure Rights Management service||Managed by Microsoft|
|Your keys are created by you and protected in a hardware security module (HSM)||BYOK
Currently, this configuration will result in reduced IRM functionality in Exchange Online. For more information, see BYOK pricing and restrictions.
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.
Alternatively, you might want complete control over your tenant key, by using Azure Key Vault. This scenario involves creating your tenant key and keeping the master copy on your premises. This scenario is often referred to as bring your own key (BYOK). With this option, the following happens:
You generate your tenant key on your premises, in line with your IT policies and security policies.
You securely transfer the tenant key from a hardware security module (HSM) in your possession to HSMs that are owned and managed by Microsoft, using Azure Key Vault. Throughout this process, your tenant key never leaves the hardware protection boundary.
When you transfer your tenant key to Microsoft, it stays protected by Azure Key Vault.
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.
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. And for different instances of Azure, such as Microsoft Azure Germany, and Azure Government. When you manage your own tenant key, it is tied to the security domain of the region or instance in which your Azure Information Protection tenant is registered. For example, a tenant key from a European customer cannot be used in data centers in North America or Asia.
The tenant key lifecycle
If you decide that Microsoft should manage your tenant key, Microsoft handles most of the key lifecycle operations. However, if you decide to manage your tenant key, you are responsible for many of the key lifecycle operations and some additional procedures in Azure Key Vault.
The following diagrams show and compares these two options. The first diagram shows how little administrator overheads there are for you in the default configuration when Microsoft manages the tenant key.
The second diagram shows the additional steps required when you manage your own tenant key.
If you decide to let Microsoft manage your tenant key, no further action is required for you to generate the key and you can go straight to Next steps.
If you decide to manage your tenant key yourself, read the following sections for more information.
Implementing 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:
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. However, if you have users who run Office 2010, contact Microsoft Support before you run these procedures. These computers will need some additional configuration steps.
Also contact Microsoft Support if your organization has specific policies for handling keys.
Prerequisites for BYOK
See the following table for a list of prerequisites for bring your own key (BYOK).
|A subscription that supports Azure Information Protection.||For more information about the available subscriptions, see the Azure Information Protection Pricing page.|
|You do not use RMS for individuals or Exchange Online. Or, if you use Exchange Online, you understand and accept the limitations of using BYOK with this configuration.||For more information about the restrictions and current limitations for BYOK, see BYOK pricing and restrictions.
Important: Currently, BYOK is not compatible with Exchange Online.
|All the prerequisites listed for Key Vault BYOK.||See Prequisites for BYOK from the Azure Key Vault documentation.
Note: 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 18.104.22.168:
For more information about Thales HSMs and how they are used with Azure Key Vault, see the Thales website.
To generate and transfer your own tenant key to Azure Key Vault, follow the procedures in How to generate and transfer HSM-protected keys for Azure Key Vault from the Azure Key Vault documentation.
When the key is transferred to Key Vault, it is given a key ID in Key Vault, which is a URL that contains the name of the 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 will need to tell the Azure Rights Management service from Azure Information Protection to use this key, by specifying this URL.
But 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, Microsoft.Azure.RMS. For example:
Set-AzureRmKeyVaultAccessPolicy -VaultName 'ContosoRMS-kv' -ResourceGroupName 'ContosoRMS-byok-rg' -ServicePrincipalName Microsoft.Azure.RMS -PermissionsToKeys decrypt,encrypt,unwrapkey,wrapkey,verify,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:
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"
If you need to confirm that the key URL is set correctly in the Azure RMS service, in Azure Key Vault, you can run Get-AzureKeyVaultKey to see the key URL.
Now that you've planned for and if necessary, generated your tenant key, do the following:
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.
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.
For more information about usage logging, see Logging and analyzing Azure Rights Management usage.
Maintain your tenant key.
For more information, see Operations for your Azure Rights Management tenant key.