Azure Information Protection テナント キーを計画して実装するPlanning and implementing your Azure Information Protection tenant key

*適用対象:Azure Information Protection**Applies to: Azure Information Protection*

*関連する内容:AIP の統合ラベル付けクライアントとクラシック クライアント**Relevant for: AIP unified labeling client and classic client*

注意

統一された効率的なカスタマー エクスペリエンスを提供するため、Azure portal の Azure Information Protection のクラシック クライアントラベル管理 は、2021 年 3 月 31 日 をもって 非推奨 になります。To provide a unified and streamlined customer experience, Azure Information Protection classic client and Label Management in the Azure Portal are being deprecated as of March 31, 2021. このタイムフレームにより、現在のすべての Azure Information Protection のお客様は、Microsoft Information Protection 統合ラベル付けプラットフォームを使用する統一されたラベル付けソリューションに移行できます。This time-frame allows all current Azure Information Protection customers to transition to our unified labeling solution using the Microsoft Information Protection Unified Labeling platform. 詳細については、公式な非推奨の通知をご覧ください。Learn more in the official deprecation notice.

Azure Information Protection テナント キーは組織のルート キーです。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. Azure Information Protection が組織でこれらのキーを使用するたびに、暗号化された Azure Information Protection ルートテナントキーにチェーンされます。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 キーの種類Azure Information Protection key types

テナントのルートキーは次のいずれかになります。Your tenant root key can either be:

オンプレミスの追加の保護を必要とする非常に機密性の高いコンテンツがある場合は、 二重キー暗号化 (DKE)を使用することをお勧めします。If you have highly sensitive content that requires additional, on-premises protection, we recommend using Double Key Encryption (DKE).

ヒント

従来のクライアントを使用していて、追加のオンプレミス保護が必要な場合は、代わりに 独自のキー (HYOK) を使用してください。If you are using the classic client, and need additional, on-premises protection, use Hold Your Own Key (HYOK) instead.

Microsoft によって生成されたテナントルートキーTenant root keys generated by Microsoft

Microsoft によって自動的に生成された既定のキーは、テナントキーのライフサイクルのほとんどの側面を管理するために Azure Information Protection 専用に使用される既定のキーです。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.

特別なハードウェア、ソフトウェア、または Azure サブスクリプションを使用せずに Azure Information Protection をすばやくデプロイする場合は、既定の Microsoft キーを使い続けます。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.

注意

Microsoft によって生成される既定のキーは、管理オーバーヘッドが最も少ない、最も簡単なオプションです。The default key generated by Microsoft is the simplest option with the lowest administrative overheads.

多くの場合、テナントキーがあることはわかりません。 Azure Information Protection にサインアップすることができ、残りのキー管理プロセスは Microsoft によって処理されます。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) 保護Bring Your Own Key (BYOK) protection

BYOK-保護では、顧客組織の Azure Key Vault またはオンプレミスのいずれかで、顧客によって作成されたキーが使用されます。BYOK-protection uses keys that are created by customers, either in the Azure Key Vault or on-premises in the customer organization. これらのキーは、さらに管理するために Azure Key Vault に転送されます。These keys are then transferred to Azure Key Vault for further management.

すべてのライフサイクル操作の制御など、キーの生成に関するコンプライアンスの規制が組織にある場合は、BYOK を使用します。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.

詳細については、「 BYOK 保護の構成」を参照してください。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.

二重キー暗号化 (DKE)Double Key Encryption (DKE)

関連: AIP 統合ラベルクライアントのみRelevant for: AIP unified labeling client only

DKE 保護では、2つのキーを使用してコンテンツのセキュリティを強化します。1つは Azure で作成して保持するキーで、もう1つは顧客がオンプレミスで作成して保持するキーです。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 では、保護されたコンテンツにアクセスするために両方のキーが必要です。これにより、マイクロソフトとその他のサードパーティが自分で保護されたデータにアクセスできなくなります。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 はクラウドとオンプレミスのどちらにでもデプロイできるため、ストレージの場所を最大限に柔軟に実現できます。DKE can be deployed either in the cloud or on-premises, providing full flexibility for storage locations.

組織で DKE を使用する: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. DKE では、顧客保持キーは顧客データセンター内に保持されます。With DKE, customer-held keys are maintained within the customer data center.

注意

DKE は、アクセス権を取得するために銀行キーと顧客キーの両方を必要とする安全預金箱に似ています。DKE is similar to a safety deposit box that requires both a bank key and a customer key to gain access. 保護されたコンテンツの暗号化を解除するには、Microsoft によって保持されているキーと、ユーザーが保持するキーの両方が必要です。DKE-protection requires both the Microsoft-held key and the customer-held key to decrypt protected content.

詳細については、Microsoft 365 ドキュメントの「 Double キー encryption 」を参照してください。For more information, see Double key encryption in the Microsoft 365 documentation.

独自のキーを保持する (HYOK)Hold Your Own Key (HYOK)

関連: AIP classic client のみRelevant for: AIP classic client only

HYOK は、クラウドから分離された場所で、顧客によって作成および保持されるキーを使用します。HYOK-protection uses a key that is created and held by customers, in a location isolated from the cloud. HYOK 保護ではオンプレミスのアプリケーションとサービスのデータへのアクセスのみが可能であるため、HYOK を使用するお客様はクラウドドキュメント用のクラウドベースのキーも持っています。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.

次のようなドキュメントには、HYOK を使用します。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".

コンテンツは、クラシッククライアントを使用している場合にのみ、HYOK protection を使用して暗号化できます。Content can be encrypted using HYOK protection only if you have the classic client. ただし、HYOK で保護されたコンテンツがある場合は、クラシックラベルクライアントと統合ラベルクライアントの両方で表示できます。However, if you have HYOK-protected content, it can be viewed in both the classic and unified labeling client.

詳細については、「 独自のキーの保持 (HYOK) の詳細」を参照してください。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:

企業合併の後など、テナント間で移行する場合、詳細については、 spinoffs のブログ記事 をお読みになることをお勧めします。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.