Microsoft Purview Information Protection
Microsoft Purview Information Protection
DKE の暗号化と復号の基盤を理解する
基盤: MPIP / Azure RMS
DKE は MPIP/Azure RMS を基盤として構築されているため、DKE の詳細に入る前に、標準的な MPIP/Azure RMS のワークフローを理解しておくことが不可欠です。
中核となる機能
MPIP は基本的にクライアント側の暗号化技術であり、エンドユーザー向けにキー管理を自動化することで、従来の PKI と比較して保護を簡素化します。認可を制御するために、ユーザー ID（メールアドレスまたはユーザープリンシパル名を使用）について Microsoft Entra ID に大きく依存します。
暗号化に加えて、作成者や中央ポリシー（例: 秘密度ラベル）によって定義される使用制限（権利）を適用します。たとえば、印刷の防止、編集の制限、有効期限の設定などです。
重要な概念: これらの権利は暗号化されたファイルとともに移動します。
主要な概念とコンポーネント
| コンポーネント | 説明 |
|---|---|
| Microsoft Entra ID | ID サービスとテナント分離を提供します。ユーザー／グループの ID が認可を制御します。 |
| Purview Information Protection Service | 秘密度ラベルと保護設定を管理するためのクラウドサービス |
| Azure Rights Management (Azure RMS) | テナントの暗号化キーを保持し、リクエストを処理する中核のクラウドサービス |
| クライアント | 保護されたコンテンツとやり取りする、ユーザーデバイス上のアプリケーションまたは認可されたクラウドサービスインスタンス |
| DKE Web Service | Double Key Encryption 向けの顧客が管理するコンポーネント（別途説明） |
標準的な暗号化プロセス (MPIP/Azure RMS)
これは、Microsoft が管理するキーのみを使用し、DKE を用いずにコンテンツを保護する方法を説明します。
ラベルの適用
ユーザーが RMS 対応アプリケーション（例: Word）で暗号化用に構成された秘密度ラベルを適用します。
コンテンツキーの生成
アプリケーションは、この特定のドキュメント（その documentID に紐づく）のために、一意の対称 AES キー（コンテンツキー）をメモリ内に生成します。
ファイルの暗号化
アプリケーションは、この一意のコンテンツキーを使用してドキュメントのコンテンツストリームを暗号化します。
発行ライセンス (PL) の作成
アプリケーションは発行ライセンス (Publishing License, PL) を作成します。この XML 構造には、コンテンツキー、ラベルまたは作成者によって定義された使用権利／権限、その他のメタデータが含まれます。
PL の暗号化と埋め込み
アプリケーションは、PL の機密部分（最も重要なのはコンテンツキー）を Azure RMS テナントの公開鍵（Azure RMS サービスから取得・キャッシュ）を使用して暗号化します。次に、暗号化された PL がドキュメントファイル構造内に埋め込まれます。
ステップ 2 ～ 4 は、アプリケーションのメモリ内でローカルに行われます。
テナントの Azure RMS サービスの URL など、PL 内の一部のメタデータは、クライアントが正しいサービスを見つけられるように暗号化されないままになります。
標準的な復号プロセス (MPIP/Azure RMS)
これは、認可されたユーザーまたはサービスが DKE を用いずに保護されたコンテンツにアクセスする方法を説明します。
オープンの試行とサービスの検出
ユーザーが RMS 対応アプリケーションで保護されたドキュメントを開きます。アプリケーションは PL の暗号化されていない部分から Azure RMS サービスの URL を読み取ります。
認証と GIC
ユーザーは Microsoft Entra ID を介して Azure RMS サービスに認証します。ユーザーが RMS を初めて操作する場合、サービスはユーザー固有の RSA キーペア（Global Identity Certificate (GIC)）をプロビジョニングします。GIC の秘密鍵はユーザーのローカルプロファイルに安全に保存され、公開鍵は RMS に認識されます。
ライセンスリクエスト
アプリケーションは、暗号化された PL（ファイル全体ではない）とユーザーの ID の証明（GIC 公開鍵を含む）を、ステップ 1 で特定した Azure RMS サービスに送信します。
認可チェック
Azure RMS は、PL で定義された権限に対してユーザーの ID を検証し、必要に応じて Microsoft Entra ID のグループメンバーシップやその他の属性を確認します。この特定のドキュメントに対するユーザーの実効的な権利を判定します（複数のグループを通じて付与される場合、権限は加算されます）。
使用ライセンス (UL/EUL) の発行
認可された場合、Azure RMS はテナントの秘密鍵を使用して PL からコンテンツキーを復号します。次に、使用ライセンスとも呼ばれるエンドユーザーライセンス (EUL) を作成します。EUL には、復号されたコンテンツキーとユーザー固有の実効的な権限が含まれます。この EUL は、ユーザーの GIC 公開鍵を使用して暗号化されます。
コンテンツの復号と適用
アプリケーションは暗号化された EUL を受け取ります。ユーザーの GIC 秘密鍵（ローカルに保存）を使用して EUL を復号し、それによってコンテンツキーを取得します。次に、アプリケーションはコンテンツキーを使用して実際のドキュメントコンテンツを復号し、同時に EUL で指定された権限を適用します（例: 表示は許可するが印刷やコピーは無効にする）。
サービスアクセスに関する注記
認可されたクラウドサービス
この RMS フローはエンドユーザーアプリケーションに限定されません。認可されたクラウドサービスも RMS クライアントとして動作できます。
Exchange Online
トランスポートルール
DLP サービス
データ損失防止
eDiscovery
Microsoft Purview
Microsoft Copilot
AI サービス
これらは Azure RMS に認証し、許可されれば使用ライセンスを取得し、コンテンツを復号して平文データに対して機能を実行します。
重要 — これは DKE で保護されたコンテンツには適用されません。 DKE は顧客が保持する 2 つ目のキーを必要とするため、Microsoft のクラウドサービス（Copilot、コンテンツ検索、eDiscovery、Office web apps を含む）は DKE で保護されたコンテンツを復号したりアクセスしたりすることができません。上記の動作は、標準の Azure RMS ／秘密度ラベルのコンテンツにのみ適用されます。