Skip to content

Latest commit

 

History

History
127 lines (79 loc) · 6.71 KB

plan-implement-tenant-key.md

File metadata and controls

127 lines (79 loc) · 6.71 KB
Raw
title description author ms.author manager ms.date ms.topic ms.collection ms.service ms.assetid ms.subservice ms.reviewer ms.suite ms.custom
Your Azure Information Protection tenant key
Instead of Microsoft managing the root key for Azure Information Protection, you might want to create and manage this key (known as "bring your own key" or BYOK) for your tenant, to comply with specific regulations.
batamig
bagol
rkarlin
02/14/2021
conceptual
M365-security-compliance
information-protection
f0d33c5f-a6a6-44a1-bdec-5be1bc8e1e14
kms
esaggese
ems
admin

Planning and implementing your Azure Information Protection tenant key

Applies to: Azure Information Protection

Relevant for: AIP unified labeling client and classic client

[!INCLUDE AIP classic client is deprecated]

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

In addition to your tenant root key, your organization may require on-premises security for specific documents. On-premises key protection is typically required only for a small amount of content, and therefore is configured together with a tenant root key.

Azure Information Protection key types

Your tenant root key can either be:

If you have highly sensitive content that requires additional, on-premises protection, we recommend using Double Key Encryption (DKE).

Tip

If you are using the classic client, and need additional, on-premises protection, use Hold Your Own Key (HYOK) instead.

Tenant root keys generated by Microsoft

The default key, automatically generated by Microsoft, is the default key used exclusively for Azure Information Protection to manage most aspects of your tenant key life cycle.

Continue using the default Microsoft key when you want to deploy Azure Information Protection quickly and without special hardware, software, or an Azure subscription. Examples include testing environments or organizations without regulatory requirements for key management.

For the default key, no further steps are required, and you can go directly to Getting started with your tenant root key.

Note

The default key generated by Microsoft is the simplest option with the lowest administrative overheads.

In most cases, you may not even know that you have a tenant key, as you can sign up for Azure Information Protection and the rest of the key management process is handled by Microsoft.

Bring Your Own Key (BYOK) protection

BYOK-protection uses keys that are created by customers, either in the Azure Key Vault or on-premises in the customer organization. These keys are then transferred to Azure Key Vault for further management.

Use BYOK when your organization has compliance regulations for key generation, including control over all life-cycle operations. For example, when your key must be protected by a hardware security module.

For more information, see Configure BYOK protection.

Once configured, continue to Getting started with your tenant root key for more information about using and managing your key.

Double Key Encryption (DKE)

Relevant for: AIP unified labeling client only

DKE protection provides additional security for your content by using two keys: one created and held by Microsoft in Azure, and another created and held on-premises by the customer.

DKE requires both keys to access protected content, ensuring that Microsoft and other third parties never have access to protected data on their own.

DKE can be deployed either in the cloud or on-premises, providing full flexibility for storage locations.

Use DKE when your organization:

  • Wants to ensure that only they can ever decrypt protected content, under all circumstances.
  • Don't want Microsoft to have access to protected data on its own.
  • Has regulatory requirements to hold keys within a geographical boundary. With DKE, customer-held keys are maintained within the customer data center.

Note

DKE is similar to a safety deposit box that requires both a bank key and a customer key to gain access. DKE-protection requires both the Microsoft-held key and the customer-held key to decrypt protected content.

For more information, see Double key encryption in the Microsoft 365 documentation.

Hold Your Own Key (HYOK)

Relevant for: AIP classic client only

HYOK-protection uses a key that is created and held by customers, in a location isolated from the cloud. Since HYOK-protection only enables access to data for on-premises applications and services, customers that use HYOK also have a cloud-based key for cloud documents.

Use HYOK for documents that are:

  • Restricted to just a few people
  • Not shared outside the organization
  • Are consumed only on the internal network.

These documents typically have the highest classification in your organization, as "Top Secret".

Content can be encrypted using HYOK protection only if you have the classic client. However, if you have HYOK-protected content, it can be viewed in both the classic and unified labeling client.

For more information, see Hold Your Own Key (HYOK) details.

Next steps

See any of the following articles for more details about specific types of keys:

If you are migrating across tenants, such as after a company merger, we recommend that you read our blog post on mergers and spinoffs for more information.