purview-customer-key

Microsoft Purview Customer Key と Double Key Encryption

Microsoft は、保存中の M365 データを Microsoft 管理のキーで既に暗号化しています。これらの追加制御により、規制対象またはデータ主権に配慮が必要なお客様は、キーを自ら保持できます。

• Customer Key — お客様が提供するルートキー（Azure Key Vault HSM 内）で、Exchange、SharePoint、OneDrive、Teams（チャット／ファイル）、Purview のサービスデータ暗号化キーをラップします。キーを失効させると、Microsoft は復号できなくなり、サービスデータの経路は暗号学的に消去されます。
• Double Key Encryption（DKE） — 機密ラベルに基づくクライアント側暗号化で、キーの一方をセルフホスト型のキーリリースサービスでお客様が保持します。Microsoft はそのキーを一切認識しないため、サービス側の機能（検索、eDiscovery、Copilot）でコンテンツを読み取ることはできません。

このスキルでは、両方を取り上げます。どちらを使うか、アーキテクチャ、運用上の実態を説明します。

使用する場面

• 暗号化キーの保持を求める規制上の義務がある場合（金融セクターのデータ主権、防衛、一部の EU 公共部門など）。
• 暗号学的消去の要件がある場合（キーの失効によって破棄を証明する）。
• Microsoft やサービス側のプロセスから、一時的にも読み取れないようにする必要がある最高機密の文書。

このスキルは Azure リソースの暗号化（azure-key-vault）、一般的な機密ラベルの展開（purview-information-governance）、GRC フレームワーク（compliance-manager）には使用しないでください。

Customer Key と DKE — 慎重に選択する

機能	Customer Key	DKE
対象範囲	選択した M365 サービス内のすべてのデータ	文書単位、ラベルに基づく
暗号化のタイミング	サービス側、透過的	クライアント側、アップロード前
サービス機能で Microsoft が読み取れるか	はい（キーが失効されるまで）	いいえ
eDiscovery、検索、Copilot、DLP はコンテンツに対して動作するか	はい	いいえ
キーの保管場所	Azure Key Vault HSM（お客様のサブスクリプション）	お客様がホストするキーリリースサービス（オンプレミスまたはお客様のクラウド）
失効による暗号学的消去が可能か	はい（サービス全体）	文書ごとにキーを破棄
用途	データ主権、規制当局による包括的な要求	最重要文書のみ

経験則： テナント全体のデータ主権には Customer Key を使用します。内部のクロステナント機能に対しても内容を不透明なまま保つ必要がある文書（取締役会議事録、M&A 草案、兵器の設計図など、文書全体の 0.1%）には DKE を使用します。

アプローチ

Customer Key

1. Azure Key Vault を、別々の 2 つの Azure サブスクリプション／リージョンにプロビジョニングします（ペア構成）。 必須の設定：

   • HSM で保護されたキー（RSA 2048 以上）。
   • ソフト削除を有効にし、消去保護を有効にします（そうでない場合、Customer Key のオンボーディングは拒否されます）。
   • 回復レベル：Recoverable+ProtectedSubscription。
   • 診断ログを、専用の長期保持 Log Analytics ワークスペースに送信します。

2. サービスごとに 2 つのルートキーを作成します。リージョンごとに 1 つです。M365 でラップ／ラップ解除を行うには、両方を使用できる状態にしておく必要があります。片方を失っても回復できますが、両方を失うと回復不能な暗号学的消去になります。

3. サービス（Exchange／SharePoint など）ごとにデータ暗号化ポリシー（DEP）を作成し、2 つのルートキーを指定します。DEP はテナント全体またはメールボックス／サイトごとに割り当てます（Exchange はメールボックス単位に対応し、SharePoint はその geo 内でテナント全体に適用されます）。

4. キーを毎年（またはポリシーに従って）ローテーションし、新しいキーのバージョンを追加します。Microsoft が自動的に再ラップします。使用中の可能性がある間は、古いバージョンを決して削除しないでください。

5. 失効手順書（これが肝心です）。 誰が承認するか、どのコマンドを実行するか、誰に通知するか、お客様にどのような影響があるかを正確に文書化します。非本番テナントで失効を練習してください。暗号学的消去を実現できるのは、実際にキーを失効させることだけです。確実なガバナンスを整えてください。

6. 監視します。 Key Vault のアクセス ポリシー、キーのアクセス許可、M365 サービス プリンシパルの割り当てに変更があれば、アラートを発生させます。

Double Key Encryption

1. ドキュメントの対象範囲を決めます。 DKE は対象ドキュメントの検索、DLP、Copilot、eDiscovery を利用できなくします。対象を小規模で明確に定義された範囲に限定してください。

2. DKE サービスを立ち上げます。

   • コンテナー化された .NET サービス（Microsoft 公開イメージ）。
   • お客様の環境（オンプレミス、AWS、GCP、または M365 テナント外の Azure）でホストします。
   • エンドユーザーのクライアントから HTTPS 経由で接続できるようにし、認可にはクライアント証明書または IdP への OAuth を使用します。
   • 高可用性：少なくとも 2 つのリージョン／AZ に配置します。停止すると、ユーザーは DKE で保護されたドキュメントを開けなくなります。

3. キーを生成して読み込みます。 各 DKE ラベルは、サービス内のキーを参照します。ドキュメントごとではなく、分類ごとにキーを用意する計画を立ててください（運用負荷が増えるためです）。

4. Purview で、DKE 暗号化オプションとサービスエンドポイント URL を指定して DKE 秘密度ラベルを作成します。

5. 対象のユーザーグループ（法務、M&A、取締役会など）にラベルを公開します。 ユーザーには Office に新しいラベルの選択肢が表示され、それを適用すると DKE サービスによるクライアント側の暗号化が実行されます。

6. ユーザーにトレードオフを文書で伝えます。 検索結果、Copilot による要約、サードパーティによるスキャン、DKE ラベル付きドキュメントの自動文字起こしは利用できません。

7. 厳格な管理体制のもとで DKE キーをバックアップします。 DKE キーを失うと、そのキーで保護されたすべてのドキュメントが永久に失われます。

ガードレール

• Customer Key で両方のルートキーを失うと、データが失われます。 Microsoft は復旧できません。HSM のルートキーと同等の管理体制でキーを取り扱ってください。
• 論理的な削除と消去保護は必須であり、取り消しできません。 Key Vault のガバナンスをあらかじめ計画してください。
• DKE は設計上、サービス側の機能を利用できなくします。 DKE コンテンツで eDiscovery や Copilot を利用できると約束しないでください。
• DKE サービスは可用性に不可欠な依存先です。 停止するとドキュメントにアクセスできなくなります。高可用性、監視、オンコール体制を整えてください。
• Customer Key は、Microsoft のネットワーク上でのデータ暗号化を変えるものではありません。転送には引き続き TLS が使用されます。Customer Key はラッピングキーの管理機能であり、転送時の暗号化を変更するものではありません。
• Customer Key の取り消しによる暗号学的消去は、DEP の対象範囲全体に影響します。 これは強力な手段です。マルチテナントの場合は、法務部門および顧客と調整してください。
• どちらの制御もプレミアムライセンスが必要です。 対象範囲を決める前に SKU とアドオンを確認してください。
• HYOK（Hold Your Own Key、AD RMS ベース） は DKE の旧来の前身です。Microsoft は今後の方針として DKE を推奨しています。新たに HYOK を設計しないでください。

よくあるアンチパターン

• 「1 つのリージョンに Key Vault を 1 つだけ置いて Customer Key を使う」 — 単一障害でサービス停止につながります。必ず 2 つのリージョンを使用してください。
• 「本番環境でテストするために Customer Key を取り消す」 — テナント全体のサービスデータ停止を引き起こしました。復旧には Microsoft の対応が必要です。テストテナントでのみ実施してください。
• 「すべての役員のメールボックスに DKE を適用する」 — 対象集団全体で eDiscovery の要求に対応できなくなります。適用は必要最小限にしてください。
• 「DKE サービスを単一の VM で運用する」 — 停止すると、ユーザーは最も機密性の高いドキュメントを開けなくなります。
• 「Customer Key を社内で『追加の暗号化』として宣伝する」 — これはより強力な暗号方式ではなく、キー管理の制御です。取り消しや主権に関する実際の価値を伝えてください。
• 「DKE キーを管理者の OneDrive にバックアップする」 — モデル全体の目的を損ないます。
• 「Customer Key と Customer Lockbox を混同する」 — 別の製品です。Customer Lockbox は Microsoft のエンジニアによるアクセスの承認、Customer Key はキー管理のためのものです。

プロンプト例

• Plan Customer Key rollout for Exchange Online and SharePoint across a multi-geo tenant — Key Vault topology and DEP design.
• Document the Customer Key revocation runbook with authorization steps and customer impact.
• Design DKE for board meeting minutes used by 12 directors — service architecture, HA, and user comms.
• Compare Customer Key vs DKE for a sovereignty requirement from a financial regulator.
• Key rotation plan for Customer Key with audit evidence for ISO 27001.
• Author the DKE label and pilot with 5 users in legal; identify broken workflows.
• Cost and operational impact estimate for adopting DKE on 1% of SharePoint content.

Microsoft Learn

• Customer Key overview: https://learn.microsoft.com/purview/customer-key-overview
• Customer Key setup: https://learn.microsoft.com/purview/customer-key-set-up
• Data encryption policies: https://learn.microsoft.com/purview/customer-key-manage
• Roll/rotate Customer Key: https://learn.microsoft.com/purview/customer-key-availability-key-roll
• Revoke Customer Key: https://learn.microsoft.com/purview/customer-key-overview
• DKE overview: https://learn.microsoft.com/purview/double-key-encryption
• DKE deploy service: https://learn.microsoft.com/purview/double-key-encryption-setup
• Customer Lockbox (distinct): https://learn.microsoft.com/purview/customer-lockbox-requests
• Service encryption (Microsoft-managed baseline): https://learn.microsoft.com/purview/office-365-service-encryption