カスタマー キーを設定する
Customer Key を使用すると、organizationの暗号化キーを制御し、Microsoft 365 を使用して Microsoft のデータ センターの保存データを暗号化するように構成します。 つまり、Customer Key を使用すると、自分に属する暗号化レイヤーをキーと共に追加できます。
カスタマー キーを使用する前に Azure を設定します。 この記事では、必要な Azure リソースを作成して構成するために従う必要がある手順について説明し、Customer Key を設定する手順について説明します。 Azure を設定した後、organizationのさまざまな Microsoft 365 ワークロード間でデータを暗号化するために割り当てるポリシー、そのため、どのキーを決定します。 カスタマー キーの詳細、または一般的な概要については、「 顧客キーの概要」を参照してください。
重要
この記事のベスト プラクティスに従うことを強くお勧めします。 これらは TIP と 重要として呼び出されます。 Customer Key を使用すると、スコープがorganization全体と同じ大きさのルート暗号化キーを制御できます。 つまり、これらのキーで行われた間違いは広範な影響を与える可能性があり、サービスの中断やデータの取り消し不可能な損失につながる可能性があります。
ヒント
E5 のお客様でない場合は、90 日間の Microsoft Purview ソリューション試用版を使用して、Purview の追加機能が組織のデータ セキュリティとコンプライアンスのニーズの管理にどのように役立つかを確認してください。 Microsoft Purview 試用版ハブから開始します。 サインアップと試用期間の詳細については、こちらをご覧ください。
Microsoft Purview カスタマー キーのWindows 365サポートはパブリック プレビュー段階であり、変更される可能性があります。
顧客キーを設定する前に
作業を開始する前に、organizationに適切な Azure サブスクリプションと Microsoft 365、Office 365、Windows 365 ライセンスがあることを確認してください。 有料の Azure サブスクリプションを使用する必要があります。 [無料]、[試用版]、[スポンサー]、[MSDN サブスクリプション]、[レガシ サポート] のサブスクリプションを通じて取得したサブスクリプションは対象外です。
重要
Microsoft 365 カスタマー キーを提供する有効な Microsoft 365 ライセンスとOffice 365 ライセンス:
- Office 365 E5
- Microsoft 365 E5
- Microsoft 365 E5 Compliance
- Microsoft 365 E5 Information Protection & ガバナンス SKU
- FLW の Microsoft 365 セキュリティとコンプライアンス
既存のOffice 365 Advanced Compliance ライセンスは引き続きサポートされています。
この記事の概念と手順を理解するには、Azure Key Vault ドキュメントを参照してください。 また、テナントなど、Azure で使用される用語Microsoft Entra理解してください。
ドキュメント以外のサポートが必要な場合は、Microsoft サポートにお問い合わせください。 ドキュメントを含むカスタマー キーに関するフィードバックを提供するには、アイデア、提案、パースペクティブを Microsoft 365 コミュニティに送信します
カスタマー キーを設定する手順の概要
顧客キーを設定するには、これらのタスクを一覧表示された順序で完了します。 この記事の残りの部分では、各タスクの詳細な手順を説明します。または、プロセス内の各ステップの詳細にリンクします。
Azure では、次の手順を実行します。
Azure PowerShellにリモートで接続して、次の前提条件を完了します。 最適な結果を得るには、バージョン 4.4.0 以降のAzure PowerShellを使用します。
前のタスクを完了した後のテナントの有効化:
Azure Key Vault for Customer Key でタスクを完了する
Azure Key Vaultでこれらのタスクを完了します。 Customer Key で使用するすべての種類のデータ暗号化ポリシー (DEP) に対して、次の手順を実行する必要があります。
2 つの新しい Azure サブスクリプションを作成する
カスタマー キーには、2 つの Azure サブスクリプションが必要です。 ベスト プラクティスとして、Microsoft では、Customer Key で使用する新しい Azure サブスクリプションを作成することをお勧めします。 Azure Key Vault キーは、同じMicrosoft Entra テナント内のアプリケーションに対してのみ承認できます。 DEP が割り当てられているorganizationで使用されるのと同じMicrosoft Entra テナントを使用して、新しいサブスクリプションを作成する必要があります。 たとえば、organizationでグローバル管理者特権を持つ職場または学校アカウントを使用します。 詳細な手順については、「organizationとして Azure にサインアップする」を参照してください。
重要
カスタマー キーには、データ暗号化ポリシー (DEP) ごとに 2 つのキーが必要です。 これを実現するには、2 つの Azure サブスクリプションを作成する必要があります。 ベスト プラクティスとして、Microsoft では、サブスクリプションごとに 1 つのキーを構成organizationの個別のメンバーを用意することをお勧めします。 これらの Azure サブスクリプションを使用して、Microsoft 365 の暗号化キーを管理する必要があります。 これにより、オペレーターの 1 人が誤って、意図的に削除したり、悪意を持って責任を負うキーを誤って削除したり、誤って管理したりする場合に備え、organizationが保護されます。
organization用に作成できる Azure サブスクリプションの数に実質的な制限はありません。 これらのベスト プラクティスに従うことで、カスタマー キーで使用されるリソースの管理に役立つ一方で、人的エラーの影響を最小限に抑えることができます。
必要なサービス プリンシパルを登録する
カスタマー キーを使用するには、テナントに必要なサービス プリンシパルが登録されている必要があります。 以降のセクションでは、サービス プリンシパルが既にテナントに登録されている場合にチェックする手順を示します。 登録されていない場合は、次に示すように 、"New-AzADServicePrincipal" コマンドレットを実行します。
カスタマー キー オンボード アプリケーションのサービス プリンシパルを登録する
Customer Key Onboarding アプリケーションがテナントに既に登録されているかどうかをグローバル管理者特権でチェックするには、次のコマンドを実行します。
Get-AzADServicePrincipal -ServicePrincipalName 19f7f505-34aa-44a4-9dcc-6a768854d2ea
アプリケーションがテナントに登録されていない場合は、次のコマンドを実行します。
New-AzADServicePrincipal -ApplicationId 19f7f505-34aa-44a4-9dcc-6a768854d2ea
M365DataAtRestEncryption アプリケーションのサービス プリンシパルを登録する
M365DataAtRestEncryption アプリケーションがテナントに既に登録されているかどうかをグローバル管理者特権でチェックするには、次のコマンドを実行します。
Get-AzADServicePrincipal -ServicePrincipalName c066d759-24ae-40e7-a56f-027002b5d3e4
アプリケーションがテナントに登録されていない場合は、次のコマンドを実行します。
New-AzADServicePrincipal -ApplicationId c066d759-24ae-40e7-a56f-027002b5d3e4
Office 365 Exchange Online アプリケーションのサービス プリンシパルを登録する
Office 365 Exchange Online アプリケーションがテナントに既に登録されているかどうかをグローバル管理者特権でチェックするには、次のコマンドを実行します。
Get-AzADServicePrincipal -ServicePrincipalName 00000002-0000-0ff1-ce00-000000000000
アプリケーションがテナントに登録されていない場合は、次のコマンドを実行します。
New-AzADServicePrincipal -ApplicationId 00000002-0000-0ff1-ce00-000000000000
各サブスクリプションに Premium Azure Key Vaultを作成する
キー コンテナーを作成する手順については、「Azure Key Vault を使用したはじめに」を参照してください。 これらの手順では、Azure PowerShellのインストールと起動、Azure サブスクリプションへの接続、リソース グループの作成、そのリソース グループ内のキー コンテナーの作成について説明します。
キー コンテナーを作成するときは、SKU (Standard または Premium) を選択する必要があります。 Standard SKU を使用すると、Azure Key Vault キーをソフトウェアで保護できます。ハードウェア セキュリティ モジュール (HSM) キー保護はありません。Premium SKU では、Key Vault キーの保護に HSM を使用できます。 カスタマー キーは、いずれかの SKU を使用するキー コンテナーを受け入れますが、Microsoft では Premium SKU のみを使用することを強くお勧めします。 どちらの種類のキーを使用した操作のコストも同じであるため、コストの唯一の違いは、HSM で保護された各キーの 1 か月あたりのコストです。 詳細については、「Key Vault価格」を参照してください。
カスタマー キーは最近、FIPS 140-2 レベル 3 準拠ソリューションであるマネージド HSM に格納されている RSA キーのサポートを追加しました。 Azure Key Vault Managed HSM は、FIPS 140-2 レベル 3 の検証済み HSM を使用して、クラウド アプリケーションの暗号化キーを保護できるようにする、フル マネージドの高可用性シングルテナント標準準拠クラウド サービスです。 マネージド HSM の詳細については、 概要を確認してください。
重要
運用データには、Premium SKU キー コンテナーと HSM で保護されたキーを使用します。 STANDARD SKU キー コンテナーとキーは、テストと検証の目的でのみ使用します。
Customer Key を使用する Microsoft 365 サービスごとに、作成した 2 つの Azure サブスクリプションのそれぞれにキー コンテナーまたはマネージド HSM を作成します。
たとえば、Exchange、SharePoint、マルチワークロードのシナリオでカスタマー キーで DEP を使用できるようにするには、キー コンテナーまたはマネージド HSM の 3 つのペア を合計 6 個作成します。 コンテナーを関連付ける DEP の使用目的を反映した名前付け規則を使用します。 次の表は、各 Azure Key Vault (AKV) またはマネージド HSM を各ワークロードにマップする方法を示しています。
| Key Vault名 | 複数の Microsoft 365 ワークロードのアクセス許可 (M365DataAtRestEncryption) | Exchange のアクセス許可 | SharePoint と OneDrive のアクセス許可 |
|---|---|---|---|
| ContosoM365AKV01 | はい | いいえ | いいえ |
| ContosoM365AKV02 | はい | いいえ | いいえ |
| ContosoEXOAKV01 | いいえ | はい | いいえ |
| ContosoEXOAKV02 | いいえ | はい | いいえ |
| ContosoSPOAKV01 | いいえ | いいえ | はい |
| ContosoSPOAKV02 | いいえ | いいえ | ○ |
キー コンテナーの作成には、Azure リソース グループの作成も必要です。これは、キー コンテナーにはストレージ容量 (小さいものの) が必要であり、ログ記録Key Vault (有効な場合) にも格納されたデータが生成されるためです。 ベスト プラクティスとして、Microsoft では、関連するすべてのカスタマー キー リソースを管理する一連の管理者に合わせた管理を使用して、個別の管理者を使用して各リソース グループを管理することをお勧めします。
Exchange の場合、メールボックスにポリシーを割り当てると、データ暗号化ポリシーのスコープが選択されます。 メールボックスにはポリシーを 1 つだけ割り当てることができ、最大 50 個のポリシーを作成できます。 SharePoint ポリシーのスコープには、地理的な場所または地理的なorganization内のすべてのデータが含まれます。 マルチワークロード ポリシーのスコープには、すべてのユーザーに対してサポートされているワークロード全体のすべてのデータが含まれます。
重要
複数の Microsoft 365 ワークロード、Exchange、SharePoint & OneDrive にカスタマー キーを使用する場合は、ワークロードごとに 2 つの Azure Key Vault を作成してください。 合計 6 つのコンテナーを作成する必要があります。
各キー コンテナーにアクセス許可を割り当てる
Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、各キー コンテナーに必要なアクセス許可を定義します。 Azure Key Vault構成アクションは、Azure portalを使用して実行されます。 このセクションでは、RBAC を使用して適切なアクセス許可を適用する方法について説明します。
RBAC メソッドを使用したアクセス許可の割り当て
Azure Key VaultにwrapKey、unwrapkey、getのアクセス許可を割り当てるには、対応する Microsoft 365 アプリに "Key Vault Crypto Service Encryption User" ロールを割り当てる必要があります。 「 Azure RBAC を使用して Azure キー コンテナーにアクセスするためのアクセス許可をアプリケーションに付与する」を参照してください。 |Microsoft Learn。
マネージド HSM に wrapKey、 unwrapkey、 get アクセス許可を割り当てるには、対応する Microsoft 365 アプリに "Managed HSM Crypto Service Encryption User" ロールを割り当てる必要があります。
「マネージド HSM ロール管理 |Microsoft Learn。
Azure Key Vaultにロールを追加するときに、Microsoft 365 アプリごとに次の名前を検索します。
Exchange の場合:
Office 365 Exchange OnlineSharePoint と OneDrive の場合:
Office 365 SharePoint Onlineマルチワークロード ポリシー (Exchange、Teams、Microsoft Purview Information Protection):
M365DataAtRestEncryption
対応する Microsoft 365 アプリが表示されない場合は、 テナントにアプリが登録されていることを確認します。
ロールとアクセス許可の割り当ての詳細については、「 ロールベースのアクセス制御を使用して Azure サブスクリプション リソースへのアクセスを管理する」を参照してください。
ユーザー ロールの割り当て
organizationのキー コンテナーの日常的な管理を行うキー コンテナー管理者またはマネージド HSM 管理者。 これらのタスクには 、バックアップ、作成、取得、インポート、一覧表示、 復元が含 まれます。
重要
キー コンテナー管理者に割り当てられた一連のアクセス許可には、キーを削除するためのアクセス許可は含まれません。 これは意図的であり、重要なプラクティスです。 暗号化キーの削除は通常は行われません。これは、データを完全に破棄するためです。 ベスト プラクティスとして、暗号化キーを削除するアクセス許可を既定でキー コンテナー管理者に付与しないでください。 代わりに、キー コンテナーの共同作成者に対してこのアクセス許可を予約し、結果の明確な理解が得られれば、短期的にのみ管理者に割り当てます。
RBAC を使用してorganizationのユーザーにこれらのアクセス許可を割り当てるには、「Azure portalを使用して Azure ロールを割り当てる」を参照し、Key Vault管理者ロールを割り当てます。
Azure Key Vault自体に対するアクセス許可を変更できる共同作成者。 従業員がチームを離れたり、チームに参加したりすると、これらのアクセス許可を変更できます。 キー コンテナー管理者がキーを削除または復元するためのアクセス許可を正当に必要とするまれな状況では、アクセス許可も変更する必要があります。 このキー コンテナー共同作成者のセットには、キー コンテナーの 共同作成者 ロールが付与されている必要があります。 このロールは、RBAC を使用して割り当てることができます。 サブスクリプションを作成する管理者は、このアクセス権を暗黙的に持ち、他の管理者を共同作成者ロールに割り当てることができます。
キーを作成またはインポートして、各キー コンテナーにキーを追加する
Azure Key Vault またはマネージド HSM にキーを追加するには、2 つの方法があります。リソースに直接キーを作成することも、キーをインポートすることもできます。 Key Vaultで直接キーを作成することはあまり複雑ではありませんが、キーをインポートすると、キーの生成方法を完全に制御できます。 RSA キーを使用します。 カスタマー キーでは、最大 4096 の RSA キーの長さがサポートされます。 Azure Key Vaultでは、楕円曲線キーを使用したラップとラップ解除はサポートされていません。
マネージド HSM では、HSM で保護されたキーのみがサポートされます。 マネージド HSM のキーを作成するときは、別の種類ではなく RSA-HSM キーを作成する必要があります。
各コンテナーまたはマネージド HSM にキーを追加する手順については、「 Add-AzKeyVaultKey」を参照してください。
オンプレミスでキーを作成し、キー コンテナーにインポートする詳細な手順については、「Azure Key Vaultの HSM で保護されたキーを生成して転送する方法」を参照してください。 Azure の手順を使用して、各キー コンテナーにキーを作成します。
キーの有効期限を確認する
キーに有効期限が設定されていないことを確認するには、 Get-AzKeyVaultKey コマンドレットを実行します。
Azure Key Vaultの場合:
Get-AzKeyVaultKey -VaultName <vault name>
マネージド HSM の場合:
Get-AzKeyVaultKey -HsmName <HSM name>
Customer Key では、期限切れのキーを使用できません。 キーの有効期限が切れた操作が失敗し、サービスが停止する可能性があります。 カスタマー キーで使用されるキーには有効期限がないことを強くお勧めします。
設定した有効期限は削除できませんが、別の日付に変更できます。 有効期限のあるキーを使用する必要がある場合は、有効期限の値を 12/31/9999 に変更し、レガシ オンボード プロセスを使用します。 有効期限が 12/31/9999 以外の日付に設定されているキーは、Microsoft 365 の検証に失敗します。カスタマー キー オンボード サービスは、有効期限のないキーのみを受け入れます。
12/31/9999 以外の値に設定されている有効期限を変更するには、 Update-AzKeyVaultKey コマンドレットを実行します。
Azure Key Vaultの場合:
Update-AzKeyVaultKey -VaultName <vault name> -Name <key name> -Expires (Get-Date -Date "12/31/9999")
マネージド HSM の場合:
Update-AzKeyVaultKey -HsmName <HSM name> -Name <key name> -Expires (Get-Date -Date "12/31/9999")
注意
カスタマー キーで使用する暗号化キーに有効期限を設定しないでください。
キー コンテナーで論理的な削除が有効になっていることを確認する
キーをすばやく回復できる場合、誤ってまたは悪意を持ってキーが削除されたために、延長されたサービスの停止が発生する可能性は低くなります。 この構成は、論理的な削除と呼ばれます。 論理的な削除を有効にすると、バックアップから復元することなく、削除から 90 日以内にキーまたはコンテナーを回復できます。 この構成は、新しい Azure Key Vault の作成時に自動的に有効になります。 マネージド HSM リソースに対して論理的な削除をオフにすることはできません。 この設定が有効になっていない既存のコンテナーを使用している場合は、有効にすることができます。
キー コンテナーで論理的な削除を有効にするには、次の手順を実行します。
Azure PowerShellを使用して Azure サブスクリプションにサインインします。 手順については、「Azure PowerShellでサインインする」を参照してください。
Get-AzKeyVault コマンドレットを実行します。 この例では、 コンテナー名 は、論理的な削除を有効にするキー コンテナーの名前です。
$v = Get-AzKeyVault -VaultName <vault name> $r = Get-AzResource -ResourceId $v.ResourceId $r.Properties | Add-Member -MemberType NoteProperty -Name enableSoftDelete -Value 'True' Set-AzResource -ResourceId $r.ResourceId -Properties $r.PropertiesGet-AzKeyVault コマンドレットを実行して、キー コンテナーに対して論理的な削除が構成されていることを確認します。 キー コンテナーに対して論理的な削除が正しく構成されている場合、 Soft Delete Enabled プロパティは True の値を返します。
Get-AzKeyVault -VaultName <vault name> | fl
続行する前に、[論理的な削除が有効になっていますか?] を確認します。 が 'True' に設定され、'論理的な削除保持期間 (日) ' が '90' に設定されています。
Azure Key Vaultのバックアップ
キーの作成または変更の直後に、バックアップを実行し、バックアップのコピーをオンラインとオフラインの両方で保存します。 Azure Key Vaultまたはマネージド HSM キーのバックアップを作成するには、Backup-AzKeyVaultKey コマンドレットを実行します。
各 Azure Key Vault キーの URI を取得する
キー コンテナーを設定し、キーを追加したら、次のコマンドを実行して、各キー コンテナー内のキーの URI を取得します。 これらの URI は、後で各 DEP を作成して割り当てるときに使用するため、この情報を安全な場所に保存します。 このコマンドは、キー コンテナーごとに 1 回実行します。
Azure PowerShell:
(Get-AzKeyVaultKey -VaultName <vault name>).Id
マネージド HSM の場合:
(Get-AzKeyVaultKey -HsmName <HSM name>).Id
カスタマー キー オンボード サービスを使用してオンボードする
Microsoft 365 カスタマー キー オンボード サービスは、独自のテナント内でカスタマー キーを有効にできるサービスです。 この機能は、必要なカスタマー キー リソースを自動的に検証します。 必要に応じて、テナント内でカスタマー キーの有効化に進む前に、リソースを個別に検証できます。
重要
このサービスは、次のシナリオではまだ使用できません。
- Government テナント - 以下の「Government テナントのカスタマー キーへのオンボード」を参照してください。
- SharePoint と OneDrive - 以下の「SharePoint と OneDrive のカスタマー キーへのオンボード」を参照してください。
- マネージド HSM を使用するテナント - 以下の「レガシ メソッドを使用してカスタマー キーにオンボードする」を参照してください。
オンボードに使用するアカウントには、最小限のアクセス許可を満たす次のロールが 必要です 。
'M365CustomerKeyOnboarding' PowerShell モジュールをインストールする
Azure PowerShellを使用して Azure サブスクリプションにサインインします。 手順については、「Azure PowerShellでサインインする」を参照してください。
PowerShell ギャラリーから入手できる M365CustomerKeyOnboarding モジュールの最新バージョンをインストールします。 ページの下部にある [バージョン履歴] タブを表示して、最新バージョンをダウンロードしていることを確認します。 管理者として PowerShell セッションを開始します。 コマンドをコピーしてAzure PowerShellに貼り付け、それを実行してパッケージをインストールします。 プロンプトが表示されたら 、オプション "Yes to All" を 選択します。 インストールには少し時間がかかります。
3 つの異なるオンボード モードを使用する
オンボード プロセスでは、それぞれ異なる目的で使用される 3 つの異なるオンボード モードがあります。 これらの 3 つのモードは、"Validate"、"Prepare"、"Enable" です。 [オンボード要求の作成] でコマンドレットを実行する場合は、"-OnboardingMode" パラメーターを使用してモードを指定します。
検証
[検証] モードを使用して、Customer Key に使用するリソースの構成が正しいことを検証します。 このモードでは、どのリソースに対してもアクションは実行されません。
重要
リソースの構成を変更する場合は、このモードを何度でも実行できます。
準備
"準備" モード では、コマンドレットで示された 2 つの Azure サブスクリプションを登録して、MandatoryRetentionPeriod を使用することで、カスタマー キー リソースに対してアクションを実行します。 ルート暗号化キーの一時的または永続的な損失は、サービス操作に破壊的または致命的な影響を与える可能性があり、データの損失につながる可能性があります。 このため、Customer Key で使用されるリソースには強力な保護が必要です。 必須のリテンション期間により、Azure サブスクリプションの即時および取り消し不可能な取り消しが防止されます。 コマンドレットを実行した後、サブスクリプションが変更を反映するまでに最大 1 時間かかる場合があります。 MandatoryRetentionPeriod 登録の状態をチェックするには、準備モードでコマンドレットを実行した後、"検証" モードに進みます。
重要
Azure サブスクリプションの必須のRetentionPeriod の登録は 必須です。 コマンドレットによってもう一度実行するように求められる場合を除き、このモードは 1 回だけ実行する必要があります。
有効にする
カスタマー キーにオンボードする準備ができたら、このモードを使用します。 "Enable" では、 -Scenario パラメーターによって示されるワークロードの Customer Key に対してのみテナントが有効になります。 Exchange と M365DataAtRestEncryption の両方で Customer Key を有効にする場合は、オンボード コマンドレットをワークロードごとに 1 回、合計 2 回実行します。 "enable" モードでコマンドレットを実行する前に、リソースが正しく構成されていることを確認します。"ValidationResult" の下に "Passed" で示されます。
重要
Enable は、リソースが "検証" モードのチェックを満たしている場合にのみ、テナントを Customer Key に正常にオンボードします。
オンボード要求の作成
この自動化プロセスの最初の手順は、新しい要求を作成することです。 PowerShell を使用すると、コマンドレットの結果を変数に圧縮できます。 新しい要求を変数に圧縮します。 変数を作成するには、"$" 記号の後に変数名を付けます。
この例では、$requestはオンボード要求に割り当てることができる変数です。
$request = New-CustomerKeyOnboardingRequest -Organization <tenantID> -Scenario <Scenario> -Subscription1 <subscriptionID1> -VaultName1 <AKVVaultName1> -KeyName1 <KeyName1> -Subscription2 <subscriptionID2> -VaultName2 <AKVVaultName2> -KeyName2 <KeyName2> -OnboardingMode <OnboardingMode>
| パラメーター | 説明 | 例 |
|---|---|---|
| -組織 | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx の形式でテナント ID を入力します。 | abcd1234-abcd-efgh-hijk-abcdef123456 |
| -シナリオ | オンボードするワークロードを入力します。 入力するオプションは、"MDEP" – 複数のワークロードの顧客キーです。 'EXO' – Exchange のカスタマー キー |
MDEP or EXO |
| -Subscription1 | 必須保有期間に登録した最初のサブスクリプションの Azure サブスクリプション ID を入力します。 | p12ld534-1234-5678-9876-g3def67j9k12 |
| -VaultName1 | Customer Key 用に構成した最初の Azure Key Vaultのコンテナー名を入力します。 | EXOVault1 |
| -KeyName1 | Customer Key 用に構成した最初の Azure Key コンテナー内の最初の Azure Key Vault Key の名前を入力します。 | EXOKey1 |
| -Subscription2 | 必須保有期間に登録した 2 つ目のサブスクリプションの Azure サブスクリプション ID を入力します。 | 21k9j76f-ed3g-6789-8765-43215dl21pbd |
| -VaultName2 | Customer Key 用に構成した 2 つ目の Azure Key Vaultのコンテナー名を入力します。 | EXOVault2 |
| -KeyName2 | Customer Key 用に構成した 2 つ目の Azure Key コンテナー内の 2 つ目の Azure Key Vault Key の名前を入力します。 | EXOKey2 |
| -オンボード モード | "準備" - 必要な構成は、サブスクリプションに MandatoryRetentionPeriod を適用することで行われます。 適用されるまでに最大 で 1 時間 かかる場合があります。 "検証" – Azure Key Vaultと Azure サブスクリプション リソースのみを検証し、Customer Key にオンボードしないでください。 このモードは、すべてのリソースを確認するが、後で正式にオンボードすることを選択する場合に便利です。 "有効にする" – Azure Key Vault とサブスクリプション リソースの両方を検証し、検証が成功した場合にテナント内でカスタマー キーを有効にします。 |
準備 or 有効にする or 検証 |
テナント管理者の資格情報を使用してログインする
特権アカウントでログインするように求めるブラウザー ウィンドウが開きます。 適切な資格情報を使用してログインします。
検証と有効化の詳細を表示する
正常にログインしたら、PowerShell ウィンドウに戻ります。 オンボード コマンドレットを圧縮した変数を実行して、オンボード要求の出力を取得します。
$request
ID、CreatedDate、ValidationResult、EnablementResult の出力を受け取ります。
| 出力 | 説明 |
|---|---|
| ID | 作成されたオンボード要求に関連付けられている ID。 |
| CreatedDate | 要求が作成された日付。 |
| ValidationResult | 検証の成功/失敗を示すインジケーター。 |
| EnablementResult | 成功/失敗の有効化のインジケーター。 |
顧客キーを使用する準備ができているテナントには、次に示すように、'ValidationResult' と 'EnablementResult' の両方の下に "Success" があります。
テナントがカスタマー キーに正常にオンボードされている場合は、[ 次の手順] に進みます。
失敗した検証の詳細のトラブルシューティング
テナントの検証が失敗した場合、次の手順は、正しく構成されていないリソースの根本原因を調査するためのガイドです。 検証が失敗する原因となっているリソースが正しく構成されていないチェックするには、オンボード結果を変数に格納し、検証結果に移動します。
- 調査する要求の要求 ID を見つけるには、すべての要求を一覧表示します。
Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID>
- 特定のオンボード要求を変数 '$request' に格納します
$request = Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID> -RequestID <RequestID>
- 次のコマンドを実行します。
$request.FailedValidations
各ルールの期待値は "ExpectedValue" 列に表示され、実際の値は "ActualValue" 列に表示されます。 [スコープ] 列には、サブスクリプション ID の最初の 5 文字が表示され、問題が発生したサブスクリプションと基になるキー コンテナーを判断できます。 [詳細] セクションでは、エラーの根本原因とその処理方法について説明します。
| RuleName | 説明 | 解決方法 |
|---|---|---|
| MandatoryRetentionPeriodState | 必須のRetentionPeriod の状態を返します | "準備" モードが実行されたことを確認します。 問題が解決しない場合は、[ 無効な必須保有期間の状態] に移動します。 |
| SubscriptionInRequestOrganization | Azure サブスクリプションがorganization内にあります。 | 指定されたサブスクリプションが、指定されたテナント内に作成されたことを確認します |
| VaultExistsinSubscription | Azure Key Vaultは Azure サブスクリプション内にあります。 | 示されたサブスクリプション内に Azure Key Vaultが作成されたことを確認します |
| SubscriptionUniquePerScenario | サブスクリプションは Customer Key に対して一意です。 | 2 つの一意のサブスクリプション ID を使用していることを確認する |
| SubscriptionsCountPerScenario | シナリオごとに 2 つのサブスクリプションがあります。 | 要求で 2 つの サブスクリプションを使用していることを確認する |
| RecoveryLevel | AKV キーの回復レベルは Recoverable +ProtectedSubscription です。 | 必須の保持期間の状態が正しくありません |
| KeyOperationsSupported | キー コンテナーには、適切なワークロードに必要なアクセス許可があります。 | AKV キーに適切なアクセス許可を割り当てる |
| KeyNeverExpires | AKV キーに有効期限がありません。 | キーの有効期限を確認する |
| KeyAccessPermissions | AKV キーに必要なアクセス許可がある | AKV キーに適切なアクセス許可を割り当てる |
| OrganizationHasRequiredServicePlan | organizationには、Customer Key を使用するための正しいサービス プランがあります。 | テナントに必要なライセンスがあることを確認する |
必須の保持期間の状態が正しくありません
"準備" モードでオンボード コマンドレットを実行してから 1 時間後に MandatoryRetentionPeriodState が 'Recoverable' または 'Recoveryable+Purgeable' に設定され、Azure Key Vault で論理的な削除が有効になっている場合は、次の手順を実行します。
- 次のコマンドを実行して、両方の Azure サブスクリプションが 'Registered' の状態を返していることを確認します。
Set-AzContext -SubscriptionId <Subscription ID>
Get-AzProviderFeature -FeatureName mandatoryRetentionPeriodEnabled -ProviderNamespace Microsoft.Resources
両方のサブスクリプションに 'Microsoft.Resources' と 'Microsoft.KeyVault' リソース プロバイダーの 両方 を再登録します。
- 再登録は、Azure Portal、Azure CLI、Azure PowerShellの 3 つの方法を使用して実行できます。
- Azure PowerShell:
Register-AzResourceProvider -ProviderNamespace Microsoft.Resources Register-AzResourceProvider -ProviderNamespace Microsoft.Keyvault - Azure CLI:
az provider register --namespace Microsoft.Resources az provider register --namespace Microsoft.Keyvault - Azure Portal:
- Azure PowerShell:
- 再登録は、Azure Portal、Azure CLI、Azure PowerShellの 3 つの方法を使用して実行できます。
キーの回復レベルをチェックするには、Azure PowerShellで次のように Get-AzKeyVaultKey コマンドレットを実行します。
(Get-AzKeyVaultKey -VaultName <vault name> -Name <key name>).Attributes
渡された検証の確認
チェックして渡された検証を確認するには、次のコマンドを実行します。
- 特定のオンボード要求を変数 '$request' に格納します
$request = Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID> -RequestID <RequestID>
- 次のコマンドを実行します。
$request.PassedValidations
レガシ メソッドを使用して Customer Key にオンボードする
この方法は、カスタマー キー オンボード サービスでサポートされていないシナリオがテナントに適用される場合にのみ使用します。 従来の方法を使用してカスタマー キーにオンボードする場合は、Azure Key Vault とサブスクリプションを設定するためのすべての手順を完了した後、カスタマー キーのサポートを要求Microsoft サポートにお問い合わせください。
政府機関テナントのカスタマー キーへのオンボード
GCC-H または DoD にテナントがあり、カスタマー キーを有効にしたい場合は、Azure Key Vault とサブスクリプションを設定するすべての手順を完了した後、政府テナントのカスタマー キー サポートを要求するMicrosoft サポートにお問い合わせください。
SharePoint と OneDrive のカスタマー キーへのオンボード
SharePoint と OneDrive のカスタマー キーにオンボードするには、2 つの前提条件があります。
テナントは既に Exchange のカスタマー キーまたは複数のワークロードのカスタマー キーにオンボードされています。
両方のサブスクリプションは、必須の保持期間を使用するように登録されます。
テナントが両方の前提条件を満たす場合は、[SharePoint と OneDrive で使用する DEP を作成する] に移動します
次の手順
この記事の手順を完了すると、DEP を作成して割り当てる準備が整います。 手順については、「 カスタマー キーの管理」を参照してください。