แก้ไข

แชร์ผ่าน

Planning and implementing your Azure Information Protection tenant key

  • บทความ

Note

Are you looking for Microsoft Purview Information Protection, formerly Microsoft Information Protection (MIP)?

The Azure Information Protection add-in is retired and replaced with labels that are built in to your Microsoft 365 apps and services. Learn more about the support status of other Azure Information Protection components.

The Microsoft Purview Information Protection client (without the add-in) is generally available.

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).

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)

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.

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.