カスタマー キーを使用すると、organizationの暗号化キーを制御し、これらのキーを使用して Microsoft のデータセンターの保存データを暗号化するように Microsoft 365 を構成できます。 つまり、所有および管理する暗号化レイヤーを追加できます。
Customer Key を使用する前に、必要なAzure リソースを設定する必要があります。 この記事では、これらのリソースを作成および構成する手順と、Customer Key を有効にする手順について説明します。 Azure リソースを設定したら、適用するポリシーと、organization内の Microsoft 365 ワークロード全体でデータを暗号化するキーを選択します。
一般的な概要と詳細については、「 顧客キーの概要」を参照してください。
重要
TIP、IMPORTANT、NOTE とマークされたこの記事のベスト プラクティスに従ってください。 カスタマー キーを使用すると、organization全体に影響を与える可能性があるルート暗号化キーを制御できます。 これらのキーを誤って使用すると、サービスが中断されたり、永続的なデータが失われたりする可能性があります。
重要
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 Purview スイート (旧称Microsoft 365 E5 Compliance)
- Microsoft 365 E5 Information Protection & ガバナンス SKU
- FLW の Microsoft 365 セキュリティとコンプライアンス
既存のOffice 365 Advanced Compliance ライセンスは引き続きサポートされています。
この記事の概念と手順を理解するには、Microsoft Azure Key Vault ドキュメントを参照してください。 また、テナントなどの主要なAzure用語についても理解Microsoft Entra必要があります。
ドキュメント以外のヘルプが必要な場合は、Microsoft サポートにお問い合わせください。 カスタマー キーまたはこのドキュメントに関するフィードバックや提案を共有するには、 Microsoft 365 コミュニティにアクセスしてください。
カスタマー キーを設定する手順の概要
Customer Key を設定するには、次のタスクを順番に完了します。 この記事の残りの部分では、各タスクの詳細な手順を説明します。または、プロセス内の各ステップの詳細にリンクします。
Azure PowerShellを使用して、次の前提条件を満たします。 (v4.4.0 以上をお勧めします):
重要
セットアップ プロセスは、Azure Key Vaultまたはマネージド HSM のどちらを使用しているかによって異なります。 共有の前提条件が最初に表示され、次に構成固有の手順が表示されます。
すべての構成の前提条件
構成固有のセットアップ
最後の手順
- カスタマー キー オンボード サービスを使用してオンボードする
- レガシ メソッドを使用して Customer Key にオンボードする
- SharePoint と OneDrive のカスタマー キーへのオンボード
- 特別なクラウド環境のカスタマー キーへのオンボード
2 つの新しいAzure サブスクリプションを作成する
カスタマー キーには、2 つのAzure サブスクリプションが必要です。 ベスト プラクティスとして、Microsoft では、特にカスタマー キーで使用するために新しい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
構成固有のセットアップ手順
重要
次の手順は、Azure Key Vaultとマネージド HSM のどちらを使用しているかによって異なります。 以下のタブを使用して、構成を選択します。
各サブスクリプションに Premium Azure Key Vaultを作成する
キー コンテナーを作成する前に、「Azure Key Vaultを使用してはじめにする」の手順を実行します。 これらの手順では、Azure PowerShellのインストールと起動、サブスクリプションへの接続について説明します。 次に、リソース グループとキー コンテナーを作成します。
重要
キー コンテナーを作成するときは、コンテナーの初期作成プロセス中に論理的な削除と消去の両方の保護を有効にする必要があります。 Customer Key では、すべてのコンテナーで、保持期間が 90 日間で両方の機能が有効になっている必要があります。 これらの設定は一度有効にすると無効にできないため、最初から正しく構成することが重要です。
キー コンテナーを作成するときは、SKU (Standard または Premium) を選択する必要があります。 Standard SKU では、ハードウェア セキュリティ モジュール (HSM) なしでソフトウェアで保護されたキーが使用されますが、Premium SKU では HSM を使用してキーを保護できます。 カスタマー キーでは、2 つの SKU のいずれかを持つキー コンテナーがサポートされていますが、Microsoft では Premium SKU の使用を強くお勧めします。 操作のコストは両方とも同じです。そのため、唯一の価格の違いは、HSM で保護された各キーの毎月のコストです。 価格の詳細については、「Key Vault価格」を参照してください。
重要
運用データには、Premium SKU キー コンテナーと HSM で保護されたキーを使用します。 STANDARD SKU キー コンテナーとキーは、テストと検証にのみ使用します。
論理的な削除と消去の保護を有効にする
キーをすばやく回復できる場合は、偶発的または悪意のある削除による延長されたサービス停止が発生する可能性が低くなります。 この回復機能は、論理的な削除と呼ばれます。 これにより、バックアップから復元する必要なく、削除されたキーまたはコンテナーを 90 日以内に回復できます。 Customer Key では、すべてのコンテナーで論理的な削除が 有効になっており 、保持期間が 90 日である必要があります。 論理的な削除は、新しいAzure Key Vault に対して自動的に有効になります。 有効になっていない既存のコンテナーを使用する場合は、手動で有効にすることができます。
消去保護がオンの場合、コンテナーまたは削除された状態のオブジェクトは、保持期間が経過するまで消去できません。 論理的に削除されたコンテナーとオブジェクトは引き続き復旧でき、アイテム保持ポリシーに従っていることを確認できます。
Azure Key Vaultで論理的な削除と消去の保護を有効にするには、「論理的な削除と消去保護を使用した回復管理のAzure Key Vault」を参照してください。
Customer Key を使用する Microsoft 365 ワークロードごとに、前に設定した 2 つのAzure サブスクリプションのそれぞれにキー コンテナーを作成します。
Key Vault構成
たとえば、複数のワークロード、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 Key Vaultにアクセス許可を割り当てる
Azure portal Azureロールベースのアクセス制御 (Azure RBAC) を使用して、必要なアクセス許可を各キー コンテナーに割り当てます。 このセクションでは、RBAC を使用して正しいアクセス許可を適用する方法について説明します。
RBAC メソッドを使用したアクセス許可の割り当て
Azure Key Vaultで (wrapKey、unwrapKey、およびget) を割り当てるには、Key Vault Crypto Service Encryption User ロールを適切な Microsoft 365 アプリに割り当てます。 「AZURE RBAC を使用してAzure Key Vaultにアクセスするためのアクセス許可をアプリケーションに付与する」を参照してください。
ロールを割り当てるときに、テナントで次のアプリ名を検索します。
複数のワークロード:
M365DataAtRestEncryptionExchange:
Office 365 Exchange OnlineSharePoint と OneDrive:
Office 365 SharePoint Online
探しているアプリが表示されない場合は、 テナントにアプリを登録してください。
ロールとアクセス許可の割り当ての詳細については、「ロールベースのアクセス制御を使用して、Azure サブスクリプション リソースへのアクセスを管理する」を参照してください。
ユーザー ロールの割り当て
カスタマー キーでは、Key Vault管理者とKey Vault共同作成者の両方が、暗号化キーへのアクセスを管理および保護する必要があります。
Key Vault管理者は、バックアップ、作成、取得、インポート、一覧表示、復元などの毎日の管理タスクを処理します。 設計上、キーを削除する権限がありません。 この設計は、永続的なデータ損失を防ぐのに役立ちます。 共同作成者ロールを使用して、削除アクセス許可を一時的かつ慎重に付与するだけです。
Key Vault共同作成者は、アクセス許可を管理し、Key Vaultでロールを割り当てることができます。 このロールを使用して、チーム メンバーが参加または退出するタイミングのアクセスを制御します。
Azure RBAC を使用してこれらのロールを割り当てる詳細な手順については、「Key Vault データ プレーン操作の組み込みロールのAzure」を参照してください。
キーを作成またはインポートして、各Key Vaultにキーを追加する
Azure Key Vaultにキーを追加するには、コンテナーに直接キーを作成するか、既存のキーをインポートする 2 つの方法があります。 Azureでキーを作成する方が簡単ですが、キーをインポートすると、キーの生成方法を完全に制御できます。 RSA キーを使用します。 カスタマー キーは、最大 4,096 ビットの RSA キー長をサポートします。 Azure Key Vaultでは、楕円曲線 (EC) キーを使用したラップとラップ解除はサポートされていません。
各コンテナーにキーを追加するには、「 Add-AzKeyVaultKey」を参照してください。
オンプレミスでキーを生成し、Azureにインポートする場合は、「Azure Key Vaultの HSM で保護されたキーを生成して転送する方法」の手順を実行します。 Azure手順を使用して、各Key Vaultにキーを追加します。
キーの有効期限を確認する
キーに有効期限がないことをチェックするには、Get-AzKeyVaultKey コマンドレットを実行します。
Azure Key Vaultの場合:
Get-AzKeyVaultKey -VaultName <vault name>
カスタマー キーでは、期限切れのキーを使用できません。 キーの有効期限が切れている場合は、キーを使用する操作が失敗し、サービスが停止する可能性があります。 カスタマー キーで使用されるキーには有効期限がないことを強くお勧めします。
設定した有効期限は削除できませんが、変更することはできます。 有効期限が設定されたキーを使用する必要がある場合は、キーを 12/31/9999 に更新し、従来のオンボード方法を使用します。 その他の有効期限の値は、カスタマー キーのオンボード検証に失敗します。
注:
カスタマー キー オンボード サービスは、有効期限のないキーのみを受け入れます。
有効期限を 12/31/9999 に変更するには、 Update-AzKeyVaultKey コマンドレットを使用します。
Update-AzKeyVaultKey -VaultName <vault name> -Name <key name> -Expires (Get-Date -Date "12/31/9999")
注意
カスタマー キーで使用される暗号化キーに有効期限を設定しないでください。
Azure Key Vault キーをバックアップする
キーを作成または変更した後は、すぐにバックアップしてください。 バックアップ コピーをオンラインとオフラインの両方の場所に保存して、データの損失を防ぎます。
Azure Key Vaultでキーをバックアップするには、Backup-AzKeyVaultKey コマンドレットを使用します。
重要
バックアップなしでキーが削除された場合、回復できません。 キーの変更または作成後は、常にバックアップを作成します。
各Azure Key Vault キーの URI を取得する
Key Vault を設定し、キーを追加したら、次のコマンドを実行して、各キーの URI を取得します。 DEP を作成して割り当てるときに、これらの URI が必要です。そのため、安全な場所に保存してください。
Azure PowerShellで次のコマンドを実行します。Key Vaultごとに 1 回実行します。
(Get-AzKeyVaultKey -VaultName <vault name>).Id
カスタマー キー オンボード サービスを使用してオンボードする
Microsoft 365 カスタマー キー オンボード サービスを使用すると、テナントでカスタマー キーを有効にすることができます。 このサービスは、必要なカスタマー キー リソースを自動的に検証します。 必要に応じて、有効化を続行する前に、リソースを個別に検証できます。
重要
このサービスは現在、次のシナリオでは使用できません。
- 特殊なクラウド テナント: 特殊なクラウド環境のカスタマー キーへのオンボードに関するページを参照してください。
- SharePoint と OneDrive: 「SharePoint と OneDrive のカスタマー キーへのオンボード」を参照してください。
オンボードに使用するアカウントには、次のアクセス許可が 必要です 。
- サービス プリンシパルの登録アクセス許可: 必要なサービス プリンシパルを登録します。
- 閲覧者ロール: オンボード コマンドレットで使用される各Azure Key Vault。
M365CustomerKeyOnboarding PowerShell モジュールをインストールする
Azure PowerShellを使用してAzure サブスクリプションにサインインします。 ガイダンスについては、「Azure PowerShellでサインインする」を参照してください。
PowerShell ギャラリーから最新バージョンの
M365CustomerKeyOnboardingモジュールをインストールします。
- 最新バージョンを使用していることを確認するには、モジュール ページの下部にある [バージョン履歴] タブをチェックします。
- install コマンドをコピーしてセッションに貼り付けて実行します。
- メッセージが表示されたら、[ はい] を [すべて] に 選択して続行します。
2 つの異なるオンボード モードの使用
カスタマー キー オンボード サービスを使用する場合は、 検証と 有効化という 2 つの異なるオンボード モードを使用できます。 各モードは、オンボード プロセスで異なる目的を果たします。
コマンドレットを実行する場合 (「 オンボード要求の作成」のガイドに基づく)、 -OnboardingMode パラメーターを使用してモードを指定します。
検証
Validate モードを使用して、Customer Key リソース構成が正しいことを確認します。 このモードでは、環境に変更は加えられません。
重要
このモードは、特に構成を変更した後に、必要な回数だけ実行できます。
有効にする
テナントをカスタマー キーにオンボードする準備ができたら、 Enable モードを使用します。 このモードでは、 -Scenario パラメーターを使用して指定したワークロードの Customer Key が有効になります。
複数のワークロードと Exchange の両方でカスタマー キーを有効にする場合は、各ワークロードに対してコマンドレットを 2 回 1 回実行します。
有効モードで実行する前に、検証結果に [ValidationResult の下に渡されました] と表示されていることを確認します。
重要
オンボーディング プロセスが有効モードで成功するには、リソースが Validate モードですべてのチェックに合格する必要があります。
オンボード要求の作成
オンボード プロセスの最初の手順は、新しい要求を作成することです。 PowerShell では、 $ 記号の後に変数名を使用して、コマンドレットの結果を変数に格納できます。
この例では、オンボード要求は $request という名前の変数に格納されます。
$request = New-CustomerKeyOnboardingRequest -Organization <tenantID> -Scenario <Scenario> -Subscription1 <subscriptionID1> -KeyIdentifier1 <KeyURI1> -Subscription2 <subscriptionID2> -KeyIdentifier2 <KeyURI2> -OnboardingMode <OnboardingMode>
| パラメーター | 説明 | 例 |
|---|---|---|
-Organization |
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx形式のテナント ID。 |
abcd1234-abcd-efgh-hijk-abcdef123456 |
-Scenario |
オンボードするワークロード。 オプション: MDEP – 複数のワークロードのカスタマー キー、 EXO – Exchange のカスタマー キー |
MDEP または EXO |
-Subscription1 |
Azure最初のサブスクリプションのサブスクリプション ID。 | p12ld534-1234-5678-9876-g3def67j9k12 |
-KeyIdentifier1 |
Customer Key 用に構成された最初の AKV または HSM キーのキー URI。 | https://exampleVault1.vault.azure.net/keys/customerKey1 |
-Subscription2 |
2 つ目のサブスクリプションのサブスクリプション ID をAzureします。 | 21k9j76f-ed3g-6789-8765-43215dl21pbd |
-KeyIdentifier2 |
Customer Key 用に構成された 2 つ目の AKV または HSM キーのキー URI。 | https://exampleVault2.vault.azure.net/keys/customerKey2 |
-OnboardingMode |
実行するオンボード アクション。 オプション: Validate – 変更を加えずに構成を検証します。 オンボード前の検証に役立ちます。
Enable – 検証に合格した場合、テナントで Customer Key を検証して有効にします。 |
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: 環境内で検出された内容。
- スコープ: どのサブスクリプション (およびその関連するKey Vault) に問題があるかを特定するのに役立つサブスクリプション ID の最初の 5 文字。
- 詳細: 根本原因について説明し、問題を解決するためのガイダンスを提供します。
次の表は、一般的な検証規則とエラーを解決する方法をまとめたものです。
| RuleName | 説明 | 解決方法 |
|---|---|---|
OrganizationHasRequiredServicePlan |
organizationに必要なライセンスがあるかどうかを確認します。 | 「 テナントに必要なライセンスがあることを確認する」を参照してください。 |
KeyNeverExpires |
キーに有効期限がないことを確認します。 | 「構成固有のセットアップ」のキーの有効期限確認手順を参照してください |
KeyOperationsSupported |
キーがワークロードに必要な操作をサポートしているかどうかを確認します。 | 「構成固有のセットアップ」のアクセス許可の割り当て手順を参照してください |
RecoveryLevel |
キー回復レベルが Recoverableされているかどうかを確認します。 |
論理的な削除と消去の両方の保護が有効になっていることを確認します。 「Azure Key Vaultの論理的な削除と消去保護の有効化」または「リソース グループ プロビジョニングを作成する」を参照し、Managed HSM のマネージド HSM をアクティブ化します。 |
SubscriptionInRequestOrganization |
Azure サブスクリプションがorganizationに属していることを確認します。 | 指定したテナント内にサブスクリプションが作成されていることを確認します。 |
SubscriptionsCountPerScenario |
2 つのサブスクリプションが提供されたことを確認します。 | オンボード要求に 2 つの サブスクリプションが含まれていることを確認します。 |
SubscriptionUniquePerScenario |
シナリオごとに 2 つの一意のサブスクリプションを使用していることを確認します。 | 両方のサブスクリプション ID が異なっていることをダブルチェックします。 |
VaultExistsinSubscription |
AKV/Managed HSM が指定されたサブスクリプションの一部であることを確認します。 | Key Vault/HSM が正しいサブスクリプションで作成されたかどうかを確認します。 |
渡された検証の確認
オンボード プロセス中に成功した検証を表示するには、次の手順を実行します。
- 特定のオンボード要求を変数 '$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 (中国) が運営する Microsoft 365 のお客様の場合は、21Vianet ポータルが運営するAzureを使用してカスタマー キー リソースを構成します。 次に、Microsoft サポートに問い合わせ、テナントのオンボードを要求します。
SharePoint と OneDrive のカスタマー キーへのオンボード
SharePoint と OneDrive の Customer Key にオンボードするには、Azure Key Vault が次の前提条件を満たしている必要があります。
コンテナーの初期作成プロセス中に、論理的な削除と消去の両方の保護を有効にします。 「Azure Key Vaultの論理的な削除と消去保護の有効化」を参照してください。
保持期間は 90 日間維持します。
すべての前提条件が満たされている場合は、「 SharePoint と OneDrive で使用する DEP を作成する」の手順を実行します。
次の手順
この記事のセットアップ手順を完了すると、DEP を作成して割り当てる準備が整います。 詳細な手順については、「 カスタマー キーの管理」を参照してください。