Azure Rights Management サービスのしくみを詳しく理解する場合は、次の情報を使用します。 データを保護するために暗号化設定を構成または適用するために、このレベルの情報を知る必要はありません。
注:
Azure Rights Management サービスがMicrosoft Purview Information Protectionの一部ではなくスタンドアロン製品として利用できた場合、多くの場合、Azure RMS と省略されていました。 この省略形は、この記事の画像に表示されます。
Azure Rights Management サービスについて理解すべき重要な概念は、このサービスが暗号化プロセスの一部としてデータを表示または格納しないということです。 暗号化した情報は、Azure に明示的に格納したり、Azure に保存する別のクラウド サービスを使用したりしない限り、Azure に送信されたり、Azure に格納されたりすることはありません。 Azure Rights Management サービスでは、承認されたユーザーやサービス以外のユーザーがアイテム内のデータを読み取れなくなるだけです。
データはアプリケーション レベルで暗号化され、そのアイテムの承認された使用を定義するポリシーが含まれています。
暗号化されたアイテムが正当なユーザーによって使用されるか、承認されたサービスによって処理される場合、アイテム内のデータは暗号化解除され、ポリシーで定義されている権限が適用されます。
大まかに言うと、このプロセスのしくみを次の図で確認できます。 シークレット数式を含むドキュメントが暗号化され、承認されたユーザーまたはサービスによって正常に開かれます。 ドキュメントは、コンテンツ キー (この図の緑色のキー) によって暗号化されます。 コンテンツ キーはドキュメントごとに一意であり、Azure Rights Management テナントのルート キー (この図の赤いキー) によって暗号化されるファイル ヘッダーに配置されます。 テナント キーは、Microsoft によって生成および管理することも、独自のテナント キーを生成および管理することもできます。
Azure Rights Management サービスが制限の暗号化と暗号化解除、承認、適用を行っているときの暗号化されたプロセス全体を通じて、シークレット数式は Azure に送信されません。
何が起こっているのかの詳細については、この記事 の「サービスのしくみのチュートリアル: 最初の使用、コンテンツ暗号化、コンテンツの使用 」セクションを参照してください。
サービスが使用するアルゴリズムとキーの長さの詳細については、次のセクションを参照してください。
暗号化制御: アルゴリズムとキーの長さ
このテクノロジのしくみを詳しく知る必要がない場合でも、使用する暗号化制御について質問される場合があります。 たとえば、暗号化が業界標準であることを確認します。
| 暗号化コントロール | Azure Rights Management サービスでの使用 |
|---|---|
| アルゴリズム: AES キー長: 128 ビットと 256 ビット [1] |
コンテンツ暗号化 |
| アルゴリズム: RSA キーの長さ: 2048 ビット [2] |
キーの暗号化 |
| SHA-256 | 証明書の署名 |
脚注 1
次のシナリオでは、Microsoft Purview Information Protection クライアントで 256 ビットが使用されます。
汎用暗号化 (.pfile)。
ドキュメントが PDF 暗号化の ISO 標準で暗号化されている場合、または結果として暗号化されたドキュメントに .ppdf ファイル名拡張子がある場合の PDF ドキュメントのネイティブ暗号化。
テキストまたはイメージ ファイル (.ptxt や .pjpg など) のネイティブ暗号化。
脚注 2
2048 ビットは、Azure Rights Management サービスがアクティブ化されたときのキー長です。 次の省略可能なシナリオでは、1024 ビットがサポートされています。
AD RMS クラスターが暗号化モード 1 で実行されている場合、オンプレミスからの移行中。
移行前にオンプレミスで作成されたアーカイブ済みキーの場合、AD RMS によって以前に暗号化されていたコンテンツを、移行後も Azure Rights Management サービスによって開き続けることができます。
暗号化キーの格納方法とセキュリティ保護方法
Azure Rights Management サービスによって保護されているドキュメントまたは電子メールごとに、サービスによって 1 つの AES キー ("コンテンツ キー") が作成され、そのキーがドキュメントに埋め込まれており、ドキュメントのエディションを通じて保持されます。
コンテンツ キーは、ドキュメント内のポリシーの一部としてorganizationの RSA キー ("Azure Rights Management テナント キー") で暗号化され、ポリシーもドキュメントの作成者によって署名されます。 このテナント キーは、organizationの Azure Rights Management サービスによって保護されているすべてのドキュメントと電子メールに共通しており、このキーは、organizationがカスタマー マネージドのテナント キー ("Bring your own key"、または BYOK) を使用している場合にのみ、サービスの管理者が変更できます。
このテナント キーは、Microsoft のオンライン サービス、高度に制御された環境、および密接な監視下で保護されています。 カスタマー マネージド テナント キー (BYOK) を使用する場合、このセキュリティは、どのような状況でもキーを抽出、エクスポート、共有することなく、各 Azure リージョンでハイエンド ハードウェア セキュリティ モジュール (HSM) の配列を使用することで強化されます。 テナント キーと BYOK の詳細については、「 Azure Rights Management サービスのルート キーの管理」を参照してください。
Windows デバイスに送信されるライセンスと証明書は、クライアントのデバイス秘密キーで暗号化されます。 この秘密キーは、デバイス上のユーザーが初めて Azure Rights Management サービスを使用する場合に作成されます。 この秘密キーは、クライアント上の DPAPI で暗号化され、ユーザーのパスワードから派生したキーを使用してこれらのシークレットを保護します。 モバイル デバイスでは、キーは 1 回だけ使用されるため、クライアントに保存されていないため、デバイスでこれらのキーを暗号化する必要はありません。
サービスのしくみのチュートリアル: 最初の使用、コンテンツ暗号化、コンテンツの使用
Azure Rights Management サービスのしくみを詳しく理解するために、 Azure Rights Management サービスがアクティブ化された 後、ユーザーが最初に Windows コンピューターから Rights Management サービスを使用する場合 (ユーザー 環境の初期化 やブートストラップと呼ばれるプロセス)、コンテンツ (ドキュメントまたは電子メール) を 暗号化 した後の一般的なフローについて説明します。 その後 、他の ユーザーによって暗号化されたコンテンツを使用 (開いて使用) します。
ユーザー環境が初期化されると、そのユーザーはドキュメントを暗号化したり、そのコンピューターで暗号化されたドキュメントを使用したりできます。
注:
このユーザーが別の Windows コンピューターに移動した場合、または別のユーザーがこの同じ Windows コンピューターを使用している場合、初期化プロセスが繰り返されます。
ユーザー環境の初期化
ユーザーが Windows コンピューターでコンテンツを暗号化したり、暗号化されたコンテンツを使用したりする前に、デバイスでユーザー環境を準備する必要があります。 これは 1 回限りのプロセスであり、ユーザーが暗号化されたコンテンツを暗号化または使用しようとすると、ユーザーの介入なしに自動的に発生します。
手順 1: コンピューター上で実行される Azure Rights Management サービスのクライアントが最初にサービスに接続し、サービスがユーザーのMicrosoft Entra アカウントを使用してユーザーを認証します。
ユーザーのアカウントがMicrosoft Entra IDとフェデレーションされている場合、この認証は自動的に行われ、ユーザーは資格情報の入力を求められません。
手順 2: ユーザーが認証されると、接続は自動的にorganizationのテナントにリダイレクトされます。これにより、暗号化されたコンテンツを使用し、コンテンツをオフラインで暗号化するために、ユーザーが Azure Rights Management サービスに対して認証を行う証明書が発行されます。
これらの証明書の 1 つは権限アカウント証明書で、多くの場合、RAC と省略されます。 この証明書は、ユーザーを認証してMicrosoft Entra IDし、31 日間有効です。 証明書はクライアントによって自動的に更新されます。ユーザー アカウントがまだMicrosoft Entra IDにあり、アカウントが有効になっている場合。 この証明書は管理者によって構成できません。
この証明書のコピーは Azure に格納されるため、ユーザーが別のデバイスに移動すると、同じキーを使用して証明書が作成されます。
コンテンツ暗号化
ユーザーがドキュメントを暗号化すると、Azure Rights Management サービスのクライアントは、暗号化されていないドキュメントに対して次のアクションを実行します。
手順 1: クライアントはランダム キー (コンテンツ キー) を作成し、AES 対称暗号化アルゴリズムを使用してこのキーを使用してドキュメントを暗号化します。
手順 2: クライアントは、ユーザーまたはグループの 使用権限 や有効期限などのその他の制限を含むドキュメントのポリシーを含む証明書を作成します。 これらの設定は、管理者が以前に構成した秘密度ラベル暗号化設定で定義することも、コンテンツが暗号化された時点で指定することもできます ("ユーザー定義のアクセス許可" または "アドホック ポリシー" とも呼ばれます)。
選択したユーザーとグループを識別するために使用される主なMicrosoft Entra属性は、ユーザーまたはグループのすべての電子メール アドレスを格納するMicrosoft Entra ProxyAddresses 属性です。 ただし、ユーザー アカウントに AD ProxyAddresses 属性に値がない場合は、代わりに ユーザーの UserPrincipalName 値が使用されます。
次に、クライアントは、ユーザー環境が初期化されたときに取得されたorganizationのキーを使用し、このキーを使用してポリシーと対称コンテンツ キーを暗号化します。 また、クライアントは、ユーザー環境の初期化時に取得されたユーザーの証明書を使用してポリシーに署名します。
手順 3: 最後に、クライアントは、以前に暗号化されたドキュメントの本文を含むファイルにポリシーを埋め込みます。これは、暗号化されたドキュメントを構成します。
このドキュメントは、任意のメソッドを使用して任意の場所に保存したり共有したりすることができ、ポリシーは常に暗号化されたドキュメントにとどまります。
コンテンツの使用
ユーザーが暗号化されたドキュメントを使用する場合、クライアントはまず Azure Rights Management サービスへのアクセスを要求します。
手順 1: 認証されたユーザーは、ドキュメント ポリシーとユーザーの証明書を Azure Rights Management サービスに送信します。 サービスはポリシーの暗号化を解除して評価し、ユーザーがドキュメントに対して持っている権限の一覧 (存在する場合) を作成します。 ユーザーを識別するために、ユーザーのアカウントとユーザーがメンバーであるグループに対して、Microsoft Entra ProxyAddresses 属性が使用されます。 パフォーマンス上の理由から、グループ メンバーシップは キャッシュされます。 ユーザー アカウントに Microsoft Entra ProxyAddresses 属性の値がない場合は、代わりに Microsoft Entra UserPrincipalName の値が使用されます。
手順 2: サービスは、復号化されたポリシーから AES コンテンツ キーを抽出します。 その後、このキーは、要求で取得されたユーザーの公開 RSA キーで暗号化されます。
再暗号化されたコンテンツ キーは、ユーザー権限の一覧を含む暗号化された使用ライセンスに埋め込まれます。その後、クライアントに返されます。
手順 3: 最後に、クライアントは暗号化された使用ライセンスを取得し、独自のユーザー秘密キーで暗号化解除します。 これにより、クライアントは必要に応じてドキュメントの本文を復号化し、画面上にレンダリングできます。
また、クライアントは権限リストを復号化してアプリケーションに渡します。これにより、アプリケーションのユーザー インターフェイスでこれらの権限が適用されます。
注:
organization外部のユーザーが暗号化したコンテンツを使用する場合、従量課金フローは同じです。 このシナリオの変更点は、ユーザーの認証方法です。 詳細については、「暗号化されたドキュメントを社外のユーザーと共有する場合、そのユーザーはどのように認証されますか?」を参照してください。
バリエーション
前のチュートリアルでは、標準的なシナリオについて説明しますが、いくつかのバリエーションがあります。
Email暗号化: Exchange OnlineとMicrosoft Purview Message Encryptionを使用して電子メール メッセージを暗号化する場合、使用する認証では、ソーシャル ID プロバイダーとのフェデレーションまたはワンタイム パスコードを使用することもできます。 その後、プロセス フローは非常に似ていますが、コンテンツの消費量は、送信メールの一時的にキャッシュされたコピーを介して Web ブラウザー セッションでサービス側で発生する点が異なります。
モバイル デバイス: モバイル デバイスが Azure Rights Management サービスでファイルを暗号化または使用する場合、プロセス フローが簡単になります。 モバイル デバイスはまずユーザー初期化プロセスを通過しません。代わりに、各トランザクション (コンテンツを暗号化または使用する) は独立しているためです。 Windows コンピューターと同様に、モバイル デバイスは Azure Rights Management サービスに接続して認証します。 コンテンツを暗号化するために、モバイル デバイスはポリシーを送信し、Azure Rights Management サービスから発行ライセンスと対称キーが送信され、ドキュメントを暗号化します。 暗号化されたコンテンツを使用するには、モバイル デバイスが Azure Rights Management サービスに接続して認証するときに、ドキュメント ポリシーを Azure Rights Management サービスに送信し、ドキュメントを使用するための使用ライセンスを要求します。 これに対して、Azure Rights Management サービスは、必要なキーと制限をモバイル デバイスに送信します。 どちらのプロセスも TLS を使用して、キー交換やその他の通信を保護します。
Rights Management コネクタ: Rights Management コネクタで Azure Rights Management サービスを使用する場合、プロセス フローは変わりません。 唯一の違いは、コネクタがオンプレミス サービス (Exchange Serverや SharePoint Server など) と Azure Rights Management サービスの間のリレーとして機能することです。 コネクタ自体は、ユーザー環境の初期化や暗号化または暗号化解除などの操作を実行しません。 通常は AD RMS サーバーに送信される通信を中継するだけで、各側で使用されるプロトコル間の変換を処理します。 このシナリオでは、オンプレミス サービスで Azure Rights Management サービスを使用できます。
汎用暗号化 (.pfile): Azure Rights Management サービスがファイルを一般的に暗号化する場合、フローは、クライアントがすべての権限を付与するポリシーを作成する点を除き、コンテンツ暗号化のフローは基本的に同じです。 ファイルが使用されると、ターゲット アプリケーションに渡される前に暗号化が解除されます。 このシナリオでは、Azure Rights Management サービスをネイティブにサポートしていない場合でも、すべてのファイルを暗号化できます。
Microsoft アカウント: Azure Rights Management サービスは、Microsoft アカウントで認証されるときに、電子メール アドレスの使用を承認できます。 ただし、Microsoft アカウントが認証に使用されている場合、すべてのアプリケーションで暗号化されたコンテンツを開くことができるわけではありません。 詳細については、以下を参照してください。
次の手順
Azure Rights Management サービスの技術的な概要については、「 Azure Rights Management サービスの詳細」を参照してください。
データを保護するための暗号化を含むデプロイ推奨手順の準備ができたら、「 Microsoft Purview を使用した情報保護ソリューションのデプロイ」を参照してください。