カスタマー キーを使用すると、organizationの暗号化キーを制御し、これらのキーを使用して Microsoft のデータセンターの保存データを暗号化するように Microsoft 365 を構成できます。 つまり、所有および管理する暗号化レイヤーを追加できます。
Customer Key を使用する前に、必要な Azure リソースを設定する必要があります。 この記事では、これらのリソースを作成および構成する手順と、Customer Key を有効にする手順について説明します。 Azure リソースを設定したら、適用されるポリシーと、organization内の Microsoft 365 ワークロード全体のデータを暗号化するキーを選択します。
一般的な概要と詳細については、「 顧客キーの概要」を参照してください。
重要
TIP、IMPORTANT、NOTE とマークされたこの記事のベスト プラクティスに従ってください。 カスタマー キーを使用すると、organization全体に影響を与える可能性があるルート暗号化キーを制御できます。 これらのキーを誤って使用すると、サービスが中断されたり、永続的なデータが失われたりする可能性があります。
ヒント
E5 のお客様でない場合は、90 日間の Microsoft Purview ソリューション試用版を使用して、Purview の追加機能が組織のデータ セキュリティとコンプライアンスのニーズの管理にどのように役立つかを確認してください。 Microsoft Purview トライアル ハブ で今すぐ開始してください。 サインアップと試用期間の詳細については、こちらをご覧ください。
重要
Microsoft では、アクセス許可が可能な限りで少ないロールを使用することをお勧めします。 グローバル管理者ロールを持つユーザーの数を最小限に抑えることで、organizationのセキュリティを向上させることができます。 Microsoft Purview のロールとアクセス許可の詳細については、こちらをご覧ください。
顧客キーを設定する前に
開始する前に、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 ドキュメントを参照してください。 また、Microsoft Entra テナントなどの主要な Azure 用語についても理解している必要があります。
ドキュメント以外のヘルプが必要な場合は、Microsoft サポートにお問い合わせください。 カスタマー キーまたはこのドキュメントに関するフィードバックや提案を共有するには、 Microsoft 365 コミュニティにアクセスしてください。
カスタマー キーを設定する手順の概要
Customer Key を設定するには、次のタスクを順番に完了します。 この記事の残りの部分では、各タスクの詳細な手順を説明します。または、プロセス内の各ステップの詳細にリンクします。
Azure では、次の手順を実行します。
Azure PowerShellを使用して、次の前提条件を満たします。 (v4.4.0 以上をお勧めします):
セットアップが完了したら、テナントを有効にします。
Azure Key Vault for Customer Key でタスクを完了する
Azure Key Vaultで次のタスクを完了します。 この手順は、複数のワークロードのカスタマー キー、Exchange、SharePoint、OneDrive など、使用する予定のカスタマー キー ワークロードごとに 1 回だけ実行する必要があります。
2 つの新しい Azure サブスクリプションを作成する
カスタマー キーには、2 つの Azure サブスクリプションが必要です。 ベスト プラクティスとして、Microsoft では、特に Customer Key で使用するために新しい Azure サブスクリプションを作成することをお勧めします。
Azure Key Vault キーは、同じMicrosoft Entra テナント内のアプリケーションに対してのみ承認できます。 データ暗号化ポリシー (DEP) を割り当てるには、organizationで使用されているのと同じMicrosoft Entra テナントの下に両方のサブスクリプションを作成してください。 たとえば、organizationで適切な管理者権限を持つ職場または学校アカウントを使用します。 詳細なガイダンスについては、「organizationとして Azure にサインアップする」を参照してください。
重要
カスタマー キーには、DEP ごとに 2 つのキーが必要です。 この要件をサポートするには、2 つの個別の Azure サブスクリプションを作成する必要があります。 ベスト プラクティスとして、organizationのさまざまなメンバーが各サブスクリプションで 1 つのキーを管理するようにします。 これらのサブスクリプションは、Microsoft 365 の暗号化キーの管理にのみ使用する必要があります。 この構成は、ユーザーが制御するキーを誤って削除したり、意図的に削除したり、悪意を持って管理したりした場合に備え、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のインストールと起動、サブスクリプションへの接続について説明します。 次に、リソース グループとキー コンテナーを作成します。
キー コンテナーを作成するときは、SKU (Standard または Premium) を選択する必要があります。 Standard SKU では、ハードウェア セキュリティ モジュール (HSM) なしでソフトウェアで保護されたキーが使用されますが、Premium SKU では HSM を使用してキーを保護できます。 カスタマー キーでは、2 つの SKU のいずれかを持つキー コンテナーがサポートされていますが、Microsoft では Premium SKU の使用を強くお勧めします。 操作のコストは両方とも同じです。そのため、唯一の価格の違いは、HSM で保護された各キーの毎月のコストです。 価格の詳細については、「Key Vault価格」を参照してください。
Azure Key Vaultではなく Azure マネージド HSM を使用する予定の場合は、「マネージド HSM を使用したカスタマー キー」を参照してください。
重要
運用データには、Premium SKU キー コンテナーと HSM で保護されたキーを使用します。 STANDARD SKU キー コンテナーとキーは、テストと検証にのみ使用します。
Customer Key を使用する Microsoft 365 ワークロードごとに、前に設定した 2 つの Azure サブスクリプションのそれぞれにキー コンテナーを作成します。
たとえば、複数のワークロード、Exchange、SharePoint のシナリオで Customer Key を使用している場合は、合計 6 個のキー コンテナーのペアが 3 組必要です。 コンテナーを関連付ける DEP の使用目的を反映した明確な名前付け規則を使用します。 次の表は、各 Azure Key Vaultを各ワークロードにマップする方法を示しています。
| Key Vault名 | 複数の Microsoft 365 ワークロードのアクセス許可 (M365DataAtRestEncryption) | Exchange のアクセス許可 | SharePoint と OneDrive のアクセス許可 |
|---|---|---|---|
| ContosoM365AKV01 | はい | いいえ | 不要 |
| ContosoM365AKV02 | はい | いいえ | 不要 |
| ContosoEXOAKV01 | 不要 | はい | いいえ |
| ContosoEXOAKV02 | 不要 | はい | いいえ |
| ContosoSPOAKV01 | 不要 | 不要 | はい |
| ContosoSPOAKV02 | 不要 | 不要 | はい |
キー コンテナーを作成するには、Azure リソース グループを設定する必要もあります。 キー コンテナーには少量のストレージが必要であり、ログ記録 (有効な場合) にもデータが格納されます。 ベスト プラクティスとして、Microsoft では、各リソース グループを管理するために異なる管理者を割り当てることをお勧めします。 これらのロールは、関連するカスタマー キー リソースの管理を担当する管理者と連携する必要があります。
Exchange の場合、DEP のスコープはメールボックス レベルです。 各メールボックスにはポリシーを 1 つだけ割り当てることができ、最大 50 個のポリシーを作成できます。 SharePoint ポリシーは、organizationの地理的な場所 (または地域) 内のすべてのデータを対象としますが、マルチワークロード ポリシーでは、organization内のすべてのユーザーでサポートされているワークロードがカバーされます。
重要
複数のワークロード、Exchange、および SharePoint と OneDrive のカスタマー キーを使用している場合は、ワークロードごとに 2 つの Azure Key Vault を作成してください。 つまり、合計 6 つのキー コンテナーが必要です。
各キー コンテナーにアクセス許可を割り当てる
Azure portalで Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、必要なアクセス許可を各キー コンテナーに割り当てます。 このセクションでは、RBAC を使用して正しいアクセス許可を適用する方法について説明します。
RBAC メソッドを使用したアクセス許可の割り当て
Azure Key Vaultで (wrapKey、unwrapkey、get) を割り当てるには、Key Vault Crypto Service Encryption User ロールを適切な Microsoft 365 アプリに割り当てます。 「 Azure RBAC を使用して Azure キー コンテナーにアクセスするためのアクセス許可をアプリケーションに付与する」を参照してください。
ロールを割り当てるときに、テナントで次のアプリ名を検索します。
複数のワークロード:
M365DataAtRestEncryptionExchange:
Office 365 Exchange OnlineSharePoint と OneDrive:
Office 365 SharePoint Online
探しているアプリが表示されない場合は、 テナントにアプリを登録してください。
ロールとアクセス許可の割り当ての詳細については、「 ロールベースのアクセス制御を使用して Azure サブスクリプション リソースへのアクセスを管理する」を参照してください。
ユーザー ロールの割り当て
カスタマー キーでは、Key Vault管理者とKey Vault共同作成者の両方が、暗号化キーへのアクセスを管理および保護する必要があります。
Key Vault管理者は、バックアップ、作成、取得、インポート、一覧表示、復元などの毎日の管理タスクを処理します。 設計上、キーを削除する権限がありません。 この設計は、永続的なデータ損失を防ぐのに役立ちます。 共同作成者ロールを使用して、削除アクセス許可を一時的かつ慎重に付与するだけです。
Key Vault共同作成者は、アクセス許可を管理し、キー コンテナー内のロールを割り当てることができます。 このロールを使用して、チーム メンバーが参加または退出するタイミングのアクセスを制御します。
Azure RBAC を使用してこれらのロールを割り当てる詳細な手順については、「Key Vault データ プレーン操作用の Azure 組み込みロール」を参照してください。
キーを作成またはインポートして、各キー コンテナーにキーを追加する
Azure Key Vaultにキーを追加するには、コンテナーに直接キーを作成するか、既存のキーをインポートする 2 つの方法があります。 Azure でキーを作成する方が簡単ですが、キーをインポートすると、キーの生成方法を完全に制御できます。 RSA キーを使用します。 カスタマー キーは、最大 4,096 ビットの RSA キー長をサポートします。 Azure Key Vault では、楕円曲線 (EC) キーを使用したラップとラップ解除はサポートされていません。
各コンテナーにキーを追加するには、「 Add-AzKeyVaultKey」を参照してください。
オンプレミスでキーを生成してから Azure にインポートする場合は、「Azure Key Vaultの HSM で保護されたキーを生成して転送する方法」の手順を実行します。 Azure の手順を使用して、各キー コンテナーにキーを追加します。
キーの有効期限を確認する
キーに有効期限がないことをチェックするには、Get-AzKeyVaultKey コマンドレットを実行します。
Azure Key Vaultの場合:
Get-AzKeyVaultKey -VaultName <vault name>
カスタマー キーでは、期限切れのキーを使用できません。 キーの有効期限が切れている場合は、キーを使用する操作が失敗し、サービスが停止する可能性があります。 カスタマー キーで使用されるキーには有効期限がないことを強くお勧めします。
設定した有効期限は削除できませんが、変更することはできます。 有効期限が設定されたキーを使用する必要がある場合は、キーを 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")
注意
カスタマー キーで使用される暗号化キーに有効期限を設定しないでください。
キー コンテナーで論理的な削除が有効になっていることを確認する
キーをすばやく回復できる場合は、偶発的または悪意のある削除による延長されたサービス停止が発生する可能性が低くなります。 この回復機能は、論理的な削除と呼ばれます。 これにより、バックアップから復元する必要なく、削除されたキーまたはコンテナーを 90 日以内に回復できます。
論理的な削除は、新しい Azure Key Vault に対して自動的に有効になります。 有効になっていない既存のコンテナーを使用する場合は、手動で有効にすることができます。
キー コンテナーで論理的な削除を有効にするには、次の手順を実行します。
Azure PowerShellを使用して Azure サブスクリプションにサインインします。 詳細については、「Azure PowerShellでサインインする」を参照してください。
Get-AzKeyVault コマンドレットを実行します。
<vault name>をキー コンテナーの名前に置き換えます。$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.Properties次を実行して、論理的な削除が有効になっていることを確認します。
Get-AzKeyVault -VaultName <vault name> | fl
[論理的な削除が有効] が [ True] に設定され、[論理的な削除の保持期間 (日数)] が [ 90] に設定されていることを確認します。
Azure Key Vault キーをバックアップする
キーを作成または変更した後は、すぐにバックアップしてください。 バックアップ コピーをオンラインとオフラインの両方の場所に保存して、データの損失を防ぎます。
Azure Key Vaultでキーをバックアップするには、Backup-AzKeyVaultKey コマンドレットを使用します。
重要
バックアップなしでキーが削除された場合、回復できません。 キーの変更または作成後は、常にバックアップを作成します。
各 Azure Key Vault キーの URI を取得する
キー コンテナーを設定し、キーを追加したら、次のコマンドを実行して、各キーの URI を取得します。 DEP を作成して割り当てるときに、これらの URI が必要です。そのため、安全な場所に保存してください。
キー コンテナーごとに 1 回、Azure PowerShellで次のコマンドを実行します。
(Get-AzKeyVaultKey -VaultName <vault name>).Id
カスタマー キー オンボード サービスを使用してオンボードする
Microsoft 365 カスタマー キー オンボード サービスを使用すると、テナントでカスタマー キーを有効にすることができます。 このサービスは、必要なカスタマー キー リソースを自動的に検証します。 必要に応じて、有効化を続行する前に、リソースを個別に検証できます。
重要
このサービスは現在、次のシナリオでは使用できません。
- 特殊なクラウド テナント: 特別なクラウドのカスタマー キーへのオンボードに関するページを参照してください。
- SharePoint と OneDrive: 「SharePoint と OneDrive のカスタマー キーへのオンボード」を参照してください。
- マネージド HSM を使用するテナント: レガシ メソッドを使用したカスタマー キーへのオンボードに関するページを参照してください。
オンボードに使用するアカウントには、次のアクセス許可が 必要です 。
- サービス プリンシパルの登録アクセス許可: 必要なサービス プリンシパルを登録します。
- 閲覧者ロール: オンボード コマンドレットで使用される各 Azure Key Vault。
M365CustomerKeyOnboarding PowerShell モジュールをインストールする
Azure PowerShellを使用して Azure サブスクリプションにサインインします。 ガイダンスについては、「Azure PowerShellでサインインする」を参照してください。
PowerShell ギャラリーから最新バージョンの
M365CustomerKeyOnboardingモジュールをインストールします。
- 最新バージョンを使用していることを確認するには、モジュール ページの下部にある [バージョン履歴] タブをチェックします。
- install コマンドをコピーしてセッションに貼り付けて実行します。
- メッセージが表示されたら、[ はい] を [すべて] に 選択して続行します。
3 つの異なるオンボード モードの使用
カスタマー キー オンボード サービスを使用する場合は、 検証、 準備、 有効化という 3 つの異なるオンボード モードがあります。 各モードは、オンボード プロセスで異なる目的を果たします。
コマンドレットを実行する場合 (「 オンボード要求の作成」のガイドに基づく)、 -OnboardingMode パラメーターを使用してモードを指定します。
検証
Validate モードを使用して、Customer Key リソース構成が正しいことを確認します。 このモードでは、環境に変更は加えられません。
重要
このモードは、特に構成を変更した後に、必要な回数だけ実行できます。
準備
Prepare モードでは、必須保有期間のコマンドレットで指定された 2 つの Azure サブスクリプションが登録されます。 この設定は、暗号化キーの誤った削除または即時削除を防ぐための保護手段であり、永続的なデータ損失やサービスの中断につながる可能性があります。
このモードでコマンドレットを実行した後、サブスクリプションが変更を反映するまでに最大で 1 時間かかる場合があります。 完了したら、Validate モードをもう一度使用して状態をチェックします。
重要
必須の保持期間を登録する必要があります。 環境ごとに 1 回だけ Prepare を実行する必要があるのは、コマンドレットから再度実行するように求められる場合を除きます。
有効にする
テナントをカスタマー キーにオンボードする準備ができたら、 Enable モードを使用します。 このモードでは、 -Scenario パラメーターを使用して指定したワークロードの Customer Key が有効になります。
複数のワークロードと Exchange の両方でカスタマー キーを有効にする場合は、各ワークロードに対してコマンドレットを 2 回 1 回実行します。
有効モードで実行する前に、検証結果に [ValidationResult の下に渡されました] と表示されていることを確認します。
重要
オンボーディング プロセスが有効モードで成功するには、リソースが Validate モードですべてのチェックに合格する必要があります。
オンボード要求の作成
オンボード プロセスの最初の手順は、新しい要求を作成することです。 PowerShell では、 $ 記号の後に変数名を使用して、コマンドレットの結果を変数に格納できます。
この例では、オンボード要求は $request という名前の変数に格納されます。
$request = New-CustomerKeyOnboardingRequest -Organization <tenantID> -Scenario <Scenario> -Subscription1 <subscriptionID1> -VaultName1 <AKVVaultName1> -KeyName1 <KeyName1> -Subscription2 <subscriptionID2> -VaultName2 <AKVVaultName2> -KeyName2 <KeyName2> -OnboardingMode <OnboardingMode>
| パラメーター | 説明 | 例 |
|---|---|---|
-Organization |
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx形式のテナント ID。 |
abcd1234-abcd-efgh-hijk-abcdef123456 |
-Scenario |
オンボードするワークロード。 オプション:
|
MDEP または EXO |
-Subscription1 |
必須保有期間に登録された最初のサブスクリプションの Azure サブスクリプション ID。 | p12ld534-1234-5678-9876-g3def67j9k12 |
-VaultName1 |
Customer Key 用に構成された最初の Azure Key Vaultの名前。 | EXOVault1 |
-KeyName1 |
最初の Azure Key Vaultの最初のキーの名前。 | EXOKey1 |
-Subscription2 |
必須保有期間に登録されている 2 つ目のサブスクリプションの Azure サブスクリプション ID。 | 21k9j76f-ed3g-6789-8765-43215dl21pbd |
-VaultName2 |
Customer Key 用に構成された 2 つ目の Azure Key Vaultの名前。 | EXOVault2 |
-KeyName2 |
2 つ目の Azure Key Vaultの 2 番目のキーの名前。 | EXOKey2 |
-OnboardingMode |
実行するオンボード アクション。 オプション:
|
Prepare、Validate、または Enable |
テナント管理者の資格情報を使用してログインする
プロンプトが表示されたら、ブラウザー ウィンドウが開きます。 オンボードを完了するために必要な特権を持つテナント管理者アカウントを使用してサインインします。
検証と有効化の詳細を表示する
正常にサインインしたら、PowerShell ウィンドウに戻ります。 オンボード要求を作成するときに使用した変数を実行して、その出力を表示します。
$request
ID、CreatedDate、ValidationResult、EnablementResultを含む出力を受け取ります。
| 出力 | 説明 |
|---|---|
ID |
作成されたオンボード要求に関連付けられている ID。 |
CreatedDate |
要求が作成された日付。 |
ValidationResult |
検証の成功/失敗を示すインジケーター。 |
EnablementResult |
成功/失敗の有効化のインジケーター。 |
顧客キーを使用する準備ができているテナントには、次のスクリーンショットに示すように、ValidationResultとEnablementResultの両方で成功が表示されます。
両方の値に [成功] と表示されている場合は、[ 次の手順] に進みます。
失敗した検証の詳細のトラブルシューティング
オンボード中に検証が失敗した場合は、次の手順を実行して原因を調査します。 このプロセスは、正しく構成されていないカスタマー キー リソースを特定するのに役立ちます。
- 調査するテナントの
RequestIDを見つけるために、テナントのすべてのオンボード要求を一覧表示します。
Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID>
- 特定のオンボード要求を変数に格納します。
$request = Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID> -RequestID <RequestID>
- 失敗した検証の詳細を表示します。
$request.FailedValidations
各検証規則には、次のフィールドが含まれます。
- ExpectedValue: リソース構成の内容。
- ActualValue: 環境内で検出された内容。
- スコープ: 問題があるサブスクリプション (およびその関連するキー コンテナー) を識別するのに役立つサブスクリプション ID の最初の 5 文字。
- 詳細: 根本原因について説明し、問題を解決するためのガイダンスを提供します。
次の表は、一般的な検証規則とエラーを解決する方法をまとめたものです。
| RuleName | 説明 | 解決方法 |
|---|---|---|
MandatoryRetentionPeriodState |
必須のRetentionPeriod の状態を返します。 |
Prepare モードを実行したことを確認します。 問題が解決しない場合は、「 必須の保持期間の状態が正しくない」を参照してください。 |
SubscriptionInRequestOrganization |
Azure サブスクリプションがorganizationに属していることを確認します。 | 指定したテナント内にサブスクリプションが作成されていることを確認します。 |
VaultExistsinSubscription |
Azure Key Vaultが指定されたサブスクリプションの一部であることを確認します。 | キー コンテナーが正しいサブスクリプションで作成されたかどうかを確認します。 |
SubscriptionUniquePerScenario |
シナリオごとに 2 つの一意のサブスクリプションを使用していることを確認します。 | 両方のサブスクリプション ID が異なっていることをダブルチェックします。 |
SubscriptionsCountPerScenario |
2 つのサブスクリプションが提供されたことを確認します。 | オンボード要求に 2 つの サブスクリプションが含まれていることを確認します。 |
RecoveryLevel |
キー コンテナーの回復レベルが Recoverable+ProtectedSubscriptionされているかどうかを確認します。 |
「正しくない必須の保持期間の状態」を参照してください。 |
KeyOperationsSupported |
キーがワークロードに必要な操作をサポートしているかどうかを確認します。 | 「AKV キーに適切なアクセス許可を割り当てる」を参照してください。 |
KeyNeverExpires |
キーに有効期限がないことを確認します。 | 「 キーの有効期限を確認する」を参照してください。 |
KeyAccessPermissions |
キーに適切なアクセス許可があることを確認します。 | 「AKV キーに適切なアクセス許可を割り当てる」を参照してください。 |
OrganizationHasRequiredServicePlan |
organizationに必要なライセンスがあるかどうかを確認します。 | 「 テナントに必要なライセンスがあることを確認する」を参照してください。 |
必須の保持期間の状態が正しくありません
オンボード コマンドレットを Prepare モードで実行した後、MandatoryRetentionPeriodStateが Recoverable または Recoverable+Purgeable 1 時間以上に設定されたままで、Azure Key Vault で論理的な削除が既に有効になっている場合は、次の手順に従って問題のトラブルシューティングと解決を行います。
-
機能登録の状態を確認する
Azure PowerShellで次のコマンドを実行して、両方の Azure サブスクリプションにRegisteredの状態が表示されることを確認します。
Set-AzContext -SubscriptionId <Subscription ID>
Get-AzProviderFeature -FeatureName mandatoryRetentionPeriodEnabled -ProviderNamespace Microsoft.Resources
必要なリソース プロバイダーを再登録する
各サブスクリプションのMicrosoft.ResourcesとMicrosoft.KeyVaultリソース プロバイダーの両方を再登録します。 このアクションは、Azure PowerShell、Azure CLI、またはAzure portalを使用して実行できます。Azure PowerShell:
Register-AzResourceProvider -ProviderNamespace Microsoft.Resources Register-AzResourceProvider -ProviderNamespace Microsoft.KeyvaultAzure CLI:
az provider register --namespace Microsoft.Resources az provider register --namespace Microsoft.KeyvaultAzure portal:
キーの回復レベルを確認する
キーの回復レベルが正しいことを確認するには、Azure PowerShellで次のコマンドを実行します。(Get-AzKeyVaultKey -VaultName <vault name> -Name <key name>).Attributes出力で
RecoveryLevelプロパティを探します。 に設定する必要があります。Recoverable+ProtectedSubscription
渡された検証の確認
オンボード プロセス中に成功した検証を表示するには、次の手順を実行します。
- 特定のオンボード要求を変数 '$request' に格納します
$request = Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID> -RequestID <RequestID>
- 次のコマンドを実行して、渡されたすべての検証を表示します。
$request.PassedValidations
このコマンドは、選択したオンボード要求に対して正常に渡されたすべての検証の一覧を返します。
レガシ メソッドを使用して Customer Key にオンボードする
このメソッドは、カスタマー キー オンボード サービスがテナントのシナリオをサポートしていない場合にのみ使用します。
Azure Key Vault とサブスクリプションを設定するために必要なすべての手順を完了したら、Microsoft サポートに問い合わせ、カスタマー キーのオンボードに関するサポートを要求します。
特別なクラウドのカスタマー キーへのオンボード
テナントが 21Vianet によって運営されているGCC-H、DoD、または M365 にある場合は、最初に必要なすべてのカスタマー キーのセットアップ手順を完了します。
GCC-H テナントと DoD テナントの場合は、Microsoft サポートに問い合わせて、政府機関テナントのオンボードを要求します。
21Vianet (中国) が運営する M365 のお客様の場合は、 Azure China ポータルを使用してカスタマー キー リソースを構成します。 次に、Microsoft サポートに問い合わせ、テナントのオンボードを要求します。
SharePoint と OneDrive のカスタマー キーへのオンボード
SharePoint と OneDrive のカスタマー キーにオンボードするには、テナントが次の前提条件を満たしている必要があります。
- テナントは、 複数のワークロード または Exchange のカスタマー キーに既にオンボードされています。
- どちらの Azure サブスクリプションも、 必須の保持期間に登録されます。
両方の前提条件が満たされている場合は、「 SharePoint と OneDrive で使用する DEP を作成する」の手順を実行します。
次の手順
この記事のセットアップ手順を完了すると、DEP を作成して割り当てる準備が整います。 詳細な手順については、「 カスタマー キーの管理」を参照してください。