カスタマー キーを設定する
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 コンサルティング サービス (MCS)、Premier Field Engineering (PFE)、または Microsoft パートナーにお問い合わせください。 ドキュメントを含むカスタマー キーに関するフィードバックを提供するには、アイデア、提案、およびパースペクティブを に customerkeyfeedback@microsoft.com送信します。
カスタマー キーを設定する手順の概要
顧客キーを設定するには、これらのタスクを一覧表示された順序で完了します。 この記事の残りの部分では、各タスクの詳細な手順を説明します。または、プロセス内の各ステップの詳細にリンクします。
Azure では、次の手順を実行します。
Azure PowerShellにリモートで接続して、次の前提条件を完了します。 最適な結果を得るには、バージョン 4.4.0 以降のAzure PowerShellを使用します。
前のタスクを完了した後のテナントの有効化:
手動の方法を使用してカスタマー キーにオンボードする (Government テナントのみ)
顧客キーの Azure Key VaultとMicrosoft FastTrackでタスクを完了する
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価格」を参照してください。
重要
運用データには Premium SKU キー コンテナーと HSM で保護されたキーを使用し、テストと検証の目的で Standard SKU キー コンテナーとキーのみを使用します。
Customer Key を使用する Microsoft 365 サービスごとに、作成した 2 つの Azure サブスクリプションのそれぞれにキー コンテナーを作成します。
たとえば、顧客キーが Exchange Online、SharePoint、マルチワークロードのシナリオで DEP を使用できるようにするには、3 つのペアのキー コンテナーを作成し、合計で 6 つのコンテナーを作成します。 コンテナーを関連付ける DEP の使用目的を反映したキー コンテナーの名前付け規則を使用します。 次の表は、各 Azure Key Vault (AKV) を各ワークロードにマップする方法を示しています。
| Key Vault名 | 複数の Microsoft 365 ワークロードのアクセス許可 (M365DataAtRestEncryption) | アクセス許可Exchange Online | SharePoint と OneDrive のアクセス許可 |
|---|---|---|---|
| ContosoM365AKV01 | はい | いいえ | いいえ |
| ContosoM365AKV02 | はい | いいえ | いいえ |
| ContosoEXOAKV01 | いいえ | はい | いいえ |
| ContosoEXOAKV02 | いいえ | はい | いいえ |
| ContosoSPOAKV01 | いいえ | いいえ | ○ |
| ContosoSPOAKV02 | いいえ | いいえ | ○ |
キー コンテナーの作成には、Azure リソース グループの作成も必要です。これは、キー コンテナーにはストレージ容量 (小さいものの) が必要であり、ログ記録Key Vault (有効な場合) にも格納されたデータが生成されるためです。 ベスト プラクティスとして、Microsoft では、関連するすべてのカスタマー キー リソースを管理する一連の管理者に合わせた管理を使用して、個別の管理者を使用して各リソース グループを管理することをお勧めします。
Exchange Onlineでは、メールボックスにポリシーを割り当てるときに、データ暗号化ポリシーのスコープが選択されます。 メールボックスにはポリシーを 1 つだけ割り当てることができ、最大 50 個のポリシーを作成できます。 SharePoint ポリシーのスコープには、地理的な場所または地理的なorganization内のすべてのデータが含まれます。 マルチワークロード ポリシーのスコープには、すべてのユーザーに対してサポートされているワークロード全体のすべてのデータが含まれます。
重要
複数の Microsoft 365 ワークロード、Exchange Online、および SharePoint の両方にカスタマー キーを使用する場合は、ワークロードごとに 2 つの Azure Key Vault を作成してください。 合計 6 つのコンテナーを作成する必要があります。
各キー コンテナーにアクセス許可を割り当てる
Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、各キー コンテナーに必要なアクセス許可を定義します。 Azure Key Vault構成アクションは、Azure portalを使用して実行されます。 このセクションでは、RBAC を使用して適切なアクセス許可を適用する方法について説明します。
RBAC メソッドを使用したアクセス許可の割り当て
Azure Key Vaultに対して、およびアクセス許可を割り当てるにはwrapKey、対応する Microsoft 365 アプリに "Key Vault Crypto Service Encryption User" ロールを割り当てる必要があります。getunwrapkey 「 Azure RBAC を使用して Azure キー コンテナーにアクセスするためのアクセス許可をアプリケーションに付与する」を参照してください。 |Microsoft Learn。
Azure Key Vaultにロールを追加するときに、Microsoft 365 アプリごとに次の名前をSearchします。
Exchange Onlineの場合:
Office 365 Exchange OnlineSharePoint、OneDrive、および Teams ファイルの場合:
Office 365 SharePoint Onlineマルチワークロード ポリシー (Exchange、Teams、Microsoft Purview 情報保護):
M365DataAtRestEncryption
対応する Microsoft 365 アプリが表示されない場合は、 テナントにアプリが登録されていることを確認します。
ロールとアクセス許可の割り当ての詳細については、「 ロールベースのアクセス制御を使用して Azure サブスクリプション リソースへのアクセスを管理する」を参照してください。
ユーザー ロールの割り当て
organizationのキー コンテナーの日常的な管理を行うキー コンテナー管理者。 これらのタスクには 、バックアップ、作成、取得、インポート、一覧表示、 復元が含 まれます。
重要
キー コンテナー管理者に割り当てられた一連のアクセス許可には、キーを削除するためのアクセス許可は含まれません。 これは意図的であり、重要なプラクティスです。 暗号化キーの削除は通常は行われません。これは、データを完全に破棄するためです。 ベスト プラクティスとして、暗号化キーを削除するアクセス許可を既定でキー コンテナー管理者に付与しないでください。 代わりに、キー コンテナーの共同作成者に対してこのアクセス許可を予約し、結果の明確な理解が得られれば、短期的にのみ管理者に割り当てます。
- RBAC を使用してorganizationのユーザーにこれらのアクセス許可を割り当てるには、「Azure portalを使用して Azure ロールを割り当てる」を参照し、Key Vault管理者ロールを割り当てます。
Azure Key Vault自体に対するアクセス許可を変更できる Key Vault 共同作成者。 従業員がチームを離れたり、チームに参加したりすると、これらのアクセス許可を変更できます。 キー コンテナー管理者がキーを削除または復元するためのアクセス許可を正当に必要とするまれな状況では、アクセス許可も変更する必要があります。 このキー コンテナー共同作成者のセットには、キー コンテナーの 共同作成者 ロールが付与されている必要があります。 このロールは、RBAC を使用して割り当てることができます。 サブスクリプションを作成する管理者は、このアクセス権を暗黙的に持ち、他の管理者を共同作成者ロールに割り当てることができます。
キーを作成またはインポートして、各キー コンテナーにキーを追加する
Azure Key Vaultにキーを追加するには、2 つの方法があります。Key Vaultで直接キーを作成することも、キーをインポートすることもできます。 Key Vaultで直接キーを作成することはあまり複雑ではありませんが、キーをインポートすると、キーの生成方法を完全に制御できます。 RSA キーを使用します。 カスタマー キーでは、最大 4096 の RSA キーの長さがサポートされます。 Azure Key Vaultでは、楕円曲線キーを使用したラップとラップ解除はサポートされていません。
各コンテナーにキーを追加する手順については、「 Add-AzKeyVaultKey」を参照してください。
オンプレミスでキーを作成し、キー コンテナーにインポートする詳細な手順については、「Azure Key Vaultの HSM で保護されたキーを生成して転送する方法」を参照してください。 Azure の手順を使用して、各キー コンテナーにキーを作成します。
キーの有効期限を確認する
キーに有効期限が設定されていないことを確認するには、 次のように Get-AzKeyVaultKey コマンドレットを実行します。
Get-AzKeyVaultKey -VaultName <vault name>
Customer Key では、期限切れのキーを使用できません。 キーの有効期限が切れた操作が失敗し、サービスが停止する可能性があります。 カスタマー キーで使用されるキーには有効期限がないことを強くお勧めします。 設定した有効期限は削除できませんが、別の日付に変更できます。 有効期限が設定されているキーを使用する必要がある場合は、有効期限の値を 12/31/9999 に変更します。 有効期限が 12/31/9999 以外の日付に設定されているキーは、Microsoft 365 の検証に失敗します。
12/31/9999 以外の値に設定されている有効期限を変更するには、 次のように Update-AzKeyVaultKey コマンドレットを実行します。
Update-AzKeyVaultKey -VaultName <vault name> -Name <key name> -Expires (Get-Date -Date "12/31/9999")
注意
カスタマー キーで使用する暗号化キーに有効期限を設定しないでください。
キーの回復レベルを確認する
Microsoft 365 では、Azure Key Vault サブスクリプションが [キャンセル不可] に設定されていること、およびカスタマー キーで使用されるキーで論理的な削除が有効になっている必要があります。 キーの回復レベルを確認することで、サブスクリプションの設定を確認できます。
キーの回復レベルをチェックするには、Azure PowerShellで次のように Get-AzKeyVaultKey コマンドレットを実行します。
(Get-AzKeyVaultKey -VaultName <vault name> -Name <key name>).Attributes
キー コンテナーで論理的な削除が有効になっていることを確認する
キーをすばやく回復できる場合、誤ってまたは悪意を持ってキーが削除されたために、延長されたサービスの停止が発生する可能性は低くなります。 カスタマー キーでキーを使用する前に、この構成 (論理的な削除と呼ばれる) を有効にします。 論理的な削除を有効にすると、バックアップから復元することなく、削除から 90 日以内にキーまたはコンテナーを回復できます。
キー コンテナーで論理的な削除を有効にするには、次の手順を実行します。
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 キーのバックアップを作成するには、Backup-AzKeyVaultKey コマンドレットを実行します。
各 Azure Key Vault キーの URI を取得する
キー コンテナーを設定し、キーを追加したら、次のコマンドを実行して、各キー コンテナー内のキーの URI を取得します。 これらの URI は、後で各 DEP を作成して割り当てるときに使用するため、この情報を安全な場所に保存します。 このコマンドは、キー コンテナーごとに 1 回実行します。
Azure PowerShell:
(Get-AzKeyVaultKey -VaultName <vault name>).Id
カスタマー キー オンボード サービスを使用したオンボード (プレビュー)
Microsoft 365 Customer Key Onboarding Service (お客様のテナント内でカスタマー キーを有効にできるサービス) をご紹介します。 この機能は、必要なカスタマー キー リソースを自動的に検証します。 必要に応じて、テナント内でカスタマー キーの有効化に進む前に、リソースを個別に検証できます。 この合理化されたアプローチにより、オンボードの全体的な期間が大幅に短縮され、便利でセルフダイレクトなプロセスが提供されます。
重要
このプレビューは、 政府機関のテナント や SharePoint と OneDrive のカスタマー キーでは使用できません。 政府機関テナントがある場合、または SharePoint と One Drive のカスタマー キーを有効にする場合は、このセクションをスキップし、「手動方法を使用してカスタマー キーにオンボードする」に進みます。
オンボードに使用するアカウントには、最小限のアクセス許可を満たす次のロールが 必要です 。
'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 時間かかる場合があります。 必須のRetentionPeriod 登録の状態をチェックするには、準備モードでコマンドレットを実行した後、検証モードに進みます。
重要
Azure サブスクリプションの必須のRetentionPeriod の登録は 必須です。 コマンドレットによってもう一度実行するように求められる場合を除き、このモードは 1 回だけ実行する必要があります。
有効にする
カスタマー キーにオンボードする準備ができたら、このモードを使用します。 "Enable" では、 -Scenario パラメーターによって示されるワークロードの Customer Key に対してのみテナントが有効になります。 Exchange と M365DataAtRestEncryption の両方で Customer Key を有効にする場合は、オンボード コマンドレットをワークロードごとに 1 回、合計 2 回実行します。 "enable" モードでコマンドレットを実行する前に、リソースが正しく構成されていることを確認します。"ValidationResult" の下に "Passed" で示されます。
重要
Enable は、リソースが検証モードのチェックを満たしている場合にのみ、テナントをカスタマー キーに正常にオンボードします。
オンボード要求の作成
この自動化プロセスの最初の手順は、新しい要求を作成することです。 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 Onlineのカスタマー キー |
MDEP or エキソ |
| -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 を使用するための正しいサービス プランがあります。 | テナントに必要なライセンスがあることを確認する |
渡された検証の確認
チェックして渡された検証を確認するには、次のコマンドを実行します。
- 特定のオンボード要求を変数 '$request' に格納します
$request = Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID> -RequestID <RequestID>
- 次のコマンドを実行します。
$request.PassedValidations
レガシ メソッドを使用して顧客キーにオンボードする
政府機関のテナントがある場合、または SharePoint と OneDrive のカスタマー キーを有効にする場合は、Azure Key Vault とサブスクリプションを設定するためのすべての手順を完了した後、対応する Microsoft Alias に問い合わせて手動でオンボードします。 カスタマー キー オンボード サービスを使用し 、[ 次の手順] に移動した場合は、このセクションを無視してください。
必須の保持期間を使用するように Azure サブスクリプションを登録する
重要
Microsoft 365 チームに連絡する前に、カスタマー キーで使用する Azure サブスクリプション ごとに 次の手順を実行する必要があります。 開始する前に、Azure PowerShell Az モジュールがインストールされていることを確認します。
Azure PowerShellでサインインします。 手順については、「Azure PowerShellでサインインする」を参照してください。
Register-AzProviderFeature コマンドレットを実行して、必須の保持期間を使用するようにサブスクリプションを登録します。 サブスクリプションごとにこのアクションを完了します。
Set-AzContext -SubscriptionId <SubscriptionId> Register-AzProviderFeature -FeatureName mandatoryRetentionPeriodEnabled -ProviderNamespace Microsoft.Resources
対応する Microsoft Alias に連絡する
複数の Microsoft 365 ワークロードのExchange Onlineまたはカスタマー キーのカスタマー キーを有効にするには、 にお問い合わせくださいm365-ck@service.microsoft.com。
すべてのテナント ユーザーの SharePoint および OneDrive コンテンツ (Teams ファイルを含む) を暗号化するために DEP を割り当てるためにカスタマー キーを有効にするには、 にお問い合わせください spock@microsoft.com。
メールに次の情報を含めます。
件名：テナントの<完全修飾ドメイン名のカスタマー キー>
体： オンボードする各カスタマー キー サービスの FastTrack 要求 ID とサブスクリプション ID を含めます。 これらのサブスクリプション ID は、必須の保持期間と、各サブスクリプションの Get-AzProviderFeature の出力を完了する必要がある ID です。
このプロセスを完了するためのサービス レベル アグリーメント (SLA) は、必須の保持期間を使用するためにサブスクリプションを登録したことを Microsoft に通知 (および確認) した後、5 営業日です。
次の手順
この記事の手順を完了すると、DEP を作成して割り当てる準備が整います。 手順については、「 カスタマー キーの管理」を参照してください。
関連記事
フィードバック
近日公開予定: 2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub イシューを段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、以下を参照してください: https://aka.ms/ContentUserFeedback。
フィードバックの送信と表示