Azure RMS が動作する しくみ

  • [アーティクル]

Azure RMS の動作方法について理解しておく必要がある重要な点は、Azure Information Protection のこのデータ保護サービスでは、保護プロセスの一環としてユーザーのデータが見られたり保存されたりしないということです。 ユーザーが保護した情報は、ユーザーが Azure に明示的に保存したり、Azure に情報を保存する別のクラウド サービスを使用しない限り、Azure に送信されたり保存されたりすることはありません。 Azure RMS は単に、ドキュメント内のデータを、承認されたユーザーとサービスしか読み取ることができないようにするだけです。

  • データは、アプリケーション レベルで暗号化されており、そのドキュメントの承認された使用を定義するポリシーを含みます。

  • 保護されたドキュメントが正当なユーザーによって使われたり、承認されたサービスによって処理されたりすると、ドキュメント内のデータの暗号化が解除され、ポリシーで定義されている権利が適用されます。

次の図は、このプロセスの概要を示したものです。 秘密の調合を含むドキュメントが保護されており、承認されたユーザーまたはサービスによって正常に開かれます。 ドキュメントは、コンテンツ キー (この図では緑の鍵) によって保護されています。 コンテンツ キーはドキュメントごとに固有であり、Azure Information Protection のテナント ルート キー (図では赤の鍵) によって保護されてファイル ヘッダーに配置されています。 Microsoft がテナント キーを生成して管理することも、ユーザーが独自のテナント キーを生成して管理することもできます。

Azure RMS が暗号化と暗号化解除、承認、制限の適用を行う保護プロセス全体を通じて、秘密の調合が Azure に送信されることはありません。

How Azure RMS protects a file

処理については、この記事の「Azure RMS の動作のチュートリアル: 初めての使用、コンテンツ保護、コンテンツ消費」を参照してください。

Azure RMS が使うアルゴリズムとキー長に関する技術的な詳細は、次のセクションをご覧ください。

Azure RMS で使用される暗号化制御: アルゴリズムとキーの長さ

この技術のしくみを詳しく知る必要がない場合であっても、この技術で使われている暗号化制御について質問されることがあるかもしれません。 たとえば、セキュリティ保護が業界標準であることを確認する場合などです。

暗号化制御 Azure RMS での用途
アルゴリズム: AES

キーの長さ: 128 ビットと 256 ビット [1]		 コンテンツの保護
アルゴリズム: RSA

キーの長さ: 2048 ビット [2]		 キーへの保護
SHA-256 証明書の署名
脚注 1

次のシナリオでは、Azure Information Protection クライアントに256 ビットが使用されます。

  • Pfile: 一般的な保護

  • ドキュメントが PDF 暗号化の ISO 標準で保護されているか、結果として保護されたドキュメントに .ppdf ファイル名拡張子が付いている場合、PDF ドキュメントをネイティブ保護します。

  • テキストまたは画像ファイル (.ptxt や .pjpg など) のネイティブ保護。

脚注 2

Azure Rights Management サービスがアクティブになっているときのキーの長さは、2048 ビットです。 以下のオプション シナリオでは、1024 ビットがサポートされます。

  • オンプレミスからの移行中に、AD RMS クラスターが暗号化モード 1 で実行している場合。

  • 移行前にオンプレミスで作成されてアーカイブされたキーの場合、以前に AD RMS によって保護されていたコンテンツを、移行後も引き続き Azure Rights Management サービスで開くことができるようにする場合。

Azure RMS 暗号化キーの格納方法と保護方法

Azure RMS によって保護されるドキュメントまたはメールごとに、Azure RMS は 1 つの AES キー ("コンテンツ キー") を作成します。そのキーは、ドキュメントに埋め込まれ、ドキュメントの各エディションを通じて保持されます。

コンテンツ キーはドキュメントのポリシーの一部として組織の RSA キー ("Azure Information Protection テナント キー") で保護され、ポリシーもドキュメントの作成者によって署名されます。 このテナント キーは組織の Azure Rights Management サービスによって保護されるすべてのドキュメントとメールに共通であり、組織が顧客によって管理されるテナント キー ("Bring Your Own Key" (BYOK) と呼ばれます) を使っている場合、このキーを変更できるのは Azure Information Protection 管理者だけです。

このテナント キーは、Microsoft のオンライン サービスにより、高度に制御された環境と厳しい監視の下で保護されます。 顧客が管理するテナント キー (BYOK) を使う場合は、どのような状況でもキーを抽出、エクスポート、または共有する機能を持たない、Azure リージョンごとのハイエンド ハードウェア セキュリティ モジュール (HSM) のアレイを使うことで、このセキュリティが強化されます。 テナント キーと BYOK については、「Azure Information Protection テナント キーを計画して実装する」を参照してください。

Windows デバイスに送信されるライセンスと証明書は、クライアントのデバイス秘密キーで保護されます。このキーは、デバイスのユーザーが Azure RMS を初めて使ったときに作成されます。 この秘密キーはさらに、クライアント上の DPAPI で保護されます。DPAPI は、ユーザーのパスワードから作成されたキーを使って、これらのシークレットを保護します。 モバイル デバイスでは、キーは 1 回しか使われず、クライアントに格納されないので、デバイスでこれらのキーを保護する必要はありません。

Azure RMS の動作のチュートリアル: 初めての使用、コンテンツ保護、コンテンツ消費

Azure RMS の動作方法をさらに詳しく理解するため、Azure Rights Management サービスがアクティブ化された後、ユーザーが初めて Windows コンピューターで Rights Management サービスを使用し (ユーザー環境の初期化とも呼ばれます)、コンテンツ (ドキュメントまたは電子メール) を保護し、他のユーザーによって保護されているコンテンツを消費する (開いて使用する) ときの、一般的なフローを説明します。

ユーザー環境が初期化された後、そのユーザーはそのコンピューターでドキュメントを保護したり、保護されているドキュメントを消費したりできます。

Note

このユーザーが別の Windows コンピューターを使う場合、または別のユーザーがこの同じ Windows コンピューターを使う場合は、初期化プロセスが繰り返されます。

ユーザー環境の初期化

ユーザーが Windows コンピューターでコンテンツを保護する場合、または保護されたコンテンツを消費する場合は、その前に、デバイスでユーザー環境を準備する必要があります。 これは 1 回限りのプロセスであり、ユーザーがコンテンツを保護したり保護されたコンテンツを消費したりしようとすると、ユーザーの介入なしに自動的に行われます。

RMS Client activation flow - step 1, authenticating the client

ステップ 1 で行われること: コンピューター上の RMS クライアントは、最初に、Azure Rights Management サービスに接続し、Azure Active Directory アカウントを使っているユーザーを認証します。

ユーザーのアカウントが Azure Active Directory にフェデレーションされていると、この認証は自動的に行われ、ユーザーが資格情報の入力を求められることはありません。

RMS Client activation - step 2, certificates are downloaded to the client

ステップ 2 で行われること: ユーザーが認証された後、接続は組織の Azure Information Protection テナントに自動的にリダイレクトされます。テナントは、ユーザーが保護されたコンテンツを消費したり、オフラインでコンテンツを保護したりするために、Azure Rights Management サービスへの認証を実行できる証明書を発行します。

これらの証明書の 1 つは権限アカウント証明書です。多くの場合、RAC と省略されます。 この証明書は、Microsoft Entra ID にユーザーを認証し、31 日間有効です。 証明書は RMS クライアントによって自動的に更新されます。ユーザー アカウントがまだ Microsoft Entra ID にあり、アカウントが有効になっている場合。 この証明書は、管理者によって構成できません。

ユーザーの証明書のコピーが Azure に格納されるので、ユーザーが別のデバイスに移動した場合、同じキーを使って証明書が作成されます。

コンテンツの保護

ユーザーがドキュメントを保護すると、RMS クライアントは保護されていないドキュメントに対して次の操作を実行します。

RMS document protection - step 1, document is encrypted

ステップ 1 で行われること: RMS クライアントは、ランダムなキー (コンテンツ キー) を作成し、このキーと AES 対称暗号化アルゴリズムを使って、ドキュメントを暗号化します。

RMS document protection - step 2, policy is created

ステップ 2 で行われること: RMS クライアントは、ドキュメントに対するポリシーを含む証明書を作成します。ポリシーには、ユーザーまたはグループに対する使用権限と、有効期限などの他の制限事項が含まれます。 これらの設定は、それ以前に管理者が構成するテンプレートで定義することも、またはコンテンツを保護するときに指定することも ("アドホック ポリシー" とも呼ばれます) できます。

選択されたユーザーやグループの識別に使われるメインの Microsoft Entra 属性は、Microsoft Entra ProxyAddresses 属性であり、この属性にはユーザーまたはグループのすべてのメール アドレスが格納されます。 ただし、ユーザー アカウントの AD ProxyAddresses 属性に値が何も含まれない場合は、ユーザーの UserPrincipalName の値が代わりに使われます。

その後、RMS クライアントは、ユーザー環境の初期化時に取得された組織のキーを使って、ポリシーと対称コンテンツ キーを暗号化します。 また、RMS クライアントは、ユーザー環境の初期化時に取得されたユーザーの証明書でポリシーに署名します。

RMS document protection - step 3, policy is embedded in the document

手順 3 の処理: 最後に、RMS クライアントは前に暗号化したドキュメントの本文と共にポリシーをファイルに埋め込みます。これらすべてが、保護されたドキュメントを構成します。

このドキュメントは、任意の方法を使って、任意の場所に格納したり共有したりでき、ポリシーは暗号化されたドキュメントと共に常に存在します。

コンテンツの消費

ユーザーが保護されたドキュメントの消費を望むと、RMS クライアントは最初に Azure Rights Management サービスへのアクセスを要求します。

RMS document consumption - step 1, user is authenticated and gets the list of rights

ステップ 1 で行われること: 認証されたユーザーは、ドキュメントのポリシーとユーザーの証明書を Azure Rights Management サービスに送信します。 サービスはポリシーの暗号化を解除して評価し、ユーザーがドキュメントに対して持っている権限の一覧を作成します (ある場合)。 ユーザーを識別するには、Microsoft Entra ProxyAddresses 属性が、ユーザーのアカウントとユーザーがメンバーであるグループに対して使われます。 パフォーマンス上の理由から、グループ メンバーシップはキャッシュされます。 ユーザー アカウントの Microsoft Entra ProxyAddresses 属性に値がない場合は、Microsoft Entra UserPrincipalName の値が代わりに使われます。

RMS document consumption - step 2, use license is returned to the client

ステップ 2 で行われること: その後、サービスは暗号化解除されたポリシーから AES コンテンツ キーを抽出します。 このキーは、要求で取得されたユーザーの公開 RSA キーで暗号化されます。

再暗号化されたコンテンツ キーは、暗号化された使用ライセンスとユーザー権限の一覧に埋め込まれて、RMS クライアントに返されます。

RMS document consumption - step 3, document is decrypted and rights are enforced

ステップ 3 で行われること: 最後に、RMS クライアントは暗号化された使用ライセンスを取得し、独自のユーザー秘密キーで暗号化を解除します。 これにより、RMS クライアントは必要に応じてドキュメント本文の暗号化を解除し、画面にレンダリングできます。

また、クライアントは、権限一覧の暗号化を解除してアプリケーションに渡し、アプリケーションのユーザー インターフェイスにそれらの権限を適用します。

Note

組織の外部のユーザーが組織で保護されているコンテンツを消費するときのフローも同じです。 このシナリオで異なる点は、ユーザーを認証する方法です。 詳細については、「保護されたドキュメントを社外のユーザーと共有する場合、そのユーザーはどのようにして認証されますか」を参照してください。

バリエーション

これまでに示した流れは標準的なシナリオのものですが、いくつかのバリエーションがあります。

  • 電子メール保護: 新しい機能を備えた Exchange Online と Office 365 Message Encryption を使用して電子メール メッセージを保護する場合、使用のための認証では、ソーシャル ID プロバイダーとのフェデレーションまたはワンタイム パスコードを使用することもできます。 その後、送信メールの一時的にキャッシュされたコピーを介して Web ブラウザー セッションでサービス側でコンテンツの従量課金が発生する点を除いて、プロセス フローは非常に似ています。

  • モバイル デバイス: モバイル デバイスが Azure Rights Management サービスでファイルを保護または消費するときのプロセス フローはとても簡単です。 モバイル デバイスでは、(コンテンツを保護または消費するための) 各トランザクションが独立しているため、最初にユーザー初期化プロセスを行う必要はありません。 Windows コンピューターと同様に、モバイル デバイスは Azure Rights Management サービスに接続して認証を行います。 コンテンツを保護するには、モバイル デバイスはポリシーを送信し、Azure Rights Management サービスはドキュメントを保護するための発行ライセンスと対称キーを送信します。 コンテンツを消費するには、モバイル デバイスは、Azure Rights Management サービスに接続して認証を行うときに、Azure Rights Management サービスにドキュメント ポリシーを送信し、ドキュメントを消費するための使用ライセンスを要求します。 応答で、Azure Rights Management サービスはモバイル デバイスに必要なキーと制限を送信します。 どちらのプロセスも、TLS を使って、キーの交換およびその他の通信を保護します。

  • RMS コネクタ: Azure Rights Management サービスが RMS コネクタで使われるときも、プロセス フローは変わりません。 唯一の違いは、コネクタがオンプレミスのサービス (Exchange Server や SharePoint Server など) と Azure Rights Management サービスの間のリレーとして機能することです。 コネクタ自体は、ユーザー環境の初期化、暗号化、暗号化解除など、いかなる操作も実行しません。 コネクタは、通常は AD RMS サーバーに送られる通信をリレーし、それぞれの側で使われているプロトコル間の変換を処理するだけです。 このシナリオでは、オンプレミスのサービスで Azure Rights Management サービスを使うことができます。

  • 一般的な保護 (.pfile): Azure Rights Management サービスが一般的にファイルを保護しているときは、RMS クライアントがすべての権限を許可するポリシーを作成する点を除き、フローは基本的にコンテンツ保護の場合と同じです。 ファイルが消費されるときは、ターゲット アプリケーションに渡される前にファイルが暗号化解除されます。 このシナリオでは、ファイルが RMS をネイティブにサポートしない場合でも、すべてのファイルを保護できます。

  • Microsoft アカウント: Azure Information Protection は、Microsoft アカウントで認証されるときに、使用する電子メール アドレスに従量課金を承認できます。 ただし、Microsoft アカウントが認証に使用されている場合、すべてのアプリケーションは保護されたコンテンツを開けるわけではありません。 詳細については、こちらを参照してください。

次のステップ

Azure Rights Management サービスについては、「理解と調査」セクションの「アプリケーションによる Azure Rights Management サービスのサポート」などの他の記事で、既存のアプリケーションを Azure Rights Management と統合して情報保護ソリューションを提供する方法を学習してください。

「Azure Information Protection の用語」で、Azure Rights Management サービスを構成および使用するときに目にする用語をよく理解してください。また、展開を始める前に、「Azure Information Protection の要件」も確認してください。 すぐに試してみたい場合は、クイックスタートとチュートリアルをご利用ください。

データ保護を組織にデプロイする準備ができたら、「分類、ラベル付け、保護のための AIP デプロイ ロードマップ」で、デプロイの手順と具体的な操作手順へのリンクを参照してください。

ヒント

追加情報やヘルプについては、「Azure Information Protection の情報とサポート」のリソースとリンクをご覧ください。