Azure RMS が動作するHow does Azure RMS work? しくみUnder the hood

*適用対象: Azure Information ProtectionOffice 365**Applies to: Azure Information Protection, Office 365*

*関連する内容: AIP の統合ラベル付けクライアントとクラシック クライアント。**Relevant for: AIP unified labeling client and classic client.*

注意

統一された効率的なカスタマー エクスペリエンスを提供するため、Azure portal の Azure Information Protection のクラシック クライアントラベル管理 は、2021 年 3 月 31 日 をもって 非推奨 になります。To provide a unified and streamlined customer experience, the Azure Information Protection classic client and Label Management in the Azure Portal are deprecated as of March 31, 2021. クラシック クライアントは構成どおりに動作しますが、今後のサポートは提供されず、メンテナンス バージョンがクラシック クライアントにリリースされなくなります。While the classic client continues to work as configured, no further support is provided, and maintenance versions will no longer be released for the classic client.

統一されたラベル付けに移行し、統一されたラベル付けクライアントにアップグレードすることをお勧めします。We recommend that you migrate to unified labeling and upgrade to the unified labeling client. 詳細については、最新の非推奨に関するブログを参照してください。Learn more in our recent deprecation blog.

Azure RMS の動作方法について理解しておく必要がある重要な点は、Azure Information Protection のこのデータ保護サービスでは、保護プロセスの一環としてユーザーのデータが見られたり保存されたりしないということです。An important thing to understand about how Azure RMS works, is that this data protection service from Azure Information Protection, does not see or store your data as part of the protection process. ユーザーが保護した情報は、ユーザーが Azure に明示的に保存したり、Azure に情報を保存する別のクラウド サービスを使用しない限り、Azure に送信されたり保存されたりすることはありません。Information that you protect is never sent to or stored in Azure, unless you explicitly store it in Azure or use another cloud service that stores it in Azure. Azure RMS は単に、ドキュメント内のデータを、承認されたユーザーとサービスしか読み取ることができないようにするだけです。Azure RMS simply makes the data in a document unreadable to anyone other than authorized users and services:

  • データは、アプリケーション レベルで暗号化されており、そのドキュメントの承認された使用を定義するポリシーを含みます。The data is encrypted at the application level and includes a policy that defines the authorized use for that document.

  • 保護されたドキュメントが正当なユーザーによって使われたり、承認されたサービスによって処理されたりすると、ドキュメント内のデータの暗号化が解除され、ポリシーで定義されている権利が適用されます。When a protected document is used by a legitimate user or it is processed by an authorized service, the data in the document is decrypted and the rights that are defined in the policy are enforced.

次の図は、このプロセスの概要を示したものです。At a high level, you can see how this process works in the following picture. 秘密の調合を含むドキュメントが保護されており、承認されたユーザーまたはサービスによって正常に開かれます。A document containing the secret formula is protected, and then successfully opened by an authorized user or service. ドキュメントは、コンテンツ キー (この図では緑の鍵) によって保護されています。The document is protected by a content key (the green key in this picture). コンテンツ キーはドキュメントごとに固有であり、Azure Information Protection のテナント ルート キー (図では赤の鍵) によって保護されてファイル ヘッダーに配置されています。It is unique for each document and is placed in the file header where it is protected by your Azure Information Protection tenant root key (the red key in this picture). Microsoft がテナント キーを生成して管理することも、ユーザーが独自のテナント キーを生成して管理することもできます。Your tenant key can be generated and managed by Microsoft, or you can generate and manage your own tenant key.

Azure RMS が暗号化と暗号化解除、承認、制限の適用を行う保護プロセス全体を通じて、秘密の調合が Azure に送信されることはありません。Throughout the protection process when Azure RMS is encrypting and decrypting, authorizing, and enforcing restrictions, the secret formula is never sent to Azure.

Azure RMS がファイルを保護する方法

処理については、この記事の「Azure RMS の動作のチュートリアル: 初めての使用、コンテンツ保護、コンテンツ消費」を参照してください。For a detailed description of what’s happening, see the Walkthrough of how Azure RMS works: First use, content protection, content consumption section in this article.

Azure RMS が使うアルゴリズムとキー長に関する技術的な詳細は、次のセクションをご覧ください。For technical details about the algorithms and key lengths that Azure RMS uses, see the next section.

Azure RMS で使用される暗号化制御: アルゴリズムとキーの長さCryptographic controls used by Azure RMS: Algorithms and key lengths

この技術のしくみを詳しく知る必要がない場合であっても、この技術で使われている暗号化制御について質問されることがあるかもしれません。Even if you don't need to know in detail how this technology works, you might be asked about the cryptographic controls that it uses. たとえば、セキュリティ保護が業界標準であることを確認する場合などです。For example, to confirm that the security protection is industry-standard.

暗号化制御Cryptographic controls Azure RMS での用途Use in Azure RMS
アルゴリズム: AESAlgorithm: AES

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

キーの長さ: 2048 ビット [2]Key length: 2048 bits [2]
キーの保護Key protection
SHA-256SHA-256 証明書の署名Certificate signing
脚注 1Footnote 1

次のシナリオでは、Azure Information Protection クライアントによって 256 ビットが使用されます。256 bits is used by the Azure Information Protection client in the following scenarios:

  • 汎用的な保護 (.pfile)。Generic protection (.pfile).

  • PDF 暗号化用の ISO 標準を使用してドキュメントが保護されている場合、または結果としての保護されたドキュメントのファイル名拡張子が .ppdf である場合、PDF ドキュメントに対するネイティブ保護。Native protection for PDF documents when the document has been protected with the ISO standard for PDF encryption, or the resulting protected document has a .ppdf file name extension.

  • テキスト ファイルまたはイメージ ファイル (.ptxt や .pjpg など) のネイティブ保護。Native protection for text or image files (such as .ptxt or .pjpg).

脚注 2Footnote 2

Azure Rights Management サービスがアクティブになっているときのキーの長さは、2048 ビットです。2048 bits is the key length when the Azure Rights Management service is activated. 以下のオプション シナリオでは、1024 ビットがサポートされます。1024 bits is supported for the following optional scenarios:

  • オンプレミスからの移行中に、AD RMS クラスターが暗号化モード 1 で実行している場合。During a migration from on-premises if the AD RMS cluster is running in Cryptographic Mode 1.

  • 移行前にオンプレミスで作成されてアーカイブされたキーの場合、以前に AD RMS によって保護されていたコンテンツを、移行後も引き続き Azure Rights Management サービスで開くことができるようにする場合。For archived keys that were created on-premises before the migration, so that content that was previously protected by AD RMS can continue to be opened by the Azure Rights Management service post migration.

Azure RMS 暗号化キーの格納方法と保護方法How the Azure RMS cryptographic keys are stored and secured

Azure RMS によって保護されるドキュメントまたはメールごとに、Azure RMS は 1 つの AES キー ("コンテンツ キー") を作成します。そのキーは、ドキュメントに埋め込まれ、ドキュメントの各エディションを通じて保持されます。For each document or email that is protected by Azure RMS, Azure RMS creates a single AES key (the "content key"), and that key is embedded to the document, and persists through editions of the document.

コンテンツ キーはドキュメントのポリシーの一部として組織の RSA キー ("Azure Information Protection テナント キー") で保護され、ポリシーもドキュメントの作成者によって署名されます。The content key is protected with the organization’s RSA key (the "Azure Information Protection tenant key") as part of the policy in the document, and the policy is also signed by the author of the document. このテナント キーは組織の Azure Rights Management サービスによって保護されるすべてのドキュメントとメールに共通であり、組織が顧客によって管理されるテナント キー ("Bring Your Own Key" (BYOK) と呼ばれます) を使っている場合、このキーを変更できるのは Azure Information Protection 管理者だけです。This tenant key is common to all documents and emails that are protected by the Azure Rights Management service for the organization and this key can only be changed by an Azure Information Protection administrator if the organization is using a tenant key that is customer-managed (known as "bring your own key", or BYOK).

このテナント キーは、Microsoft のオンライン サービスにより、高度に制御された環境と厳しい監視の下で保護されます。This tenant key is protected in Microsoft’s online services, in a highly controlled environment and under close monitoring. 顧客が管理するテナント キー (BYOK) を使う場合は、どのような状況でもキーを抽出、エクスポート、または共有する機能を持たない、Azure リージョンごとのハイエンド ハードウェア セキュリティ モジュール (HSM) のアレイを使うことで、このセキュリティが強化されます。When you use a customer-managed tenant key (BYOK), this security is enhanced by the use of an array of high-end hardware security modules (HSMs) in each Azure region, without the ability for the keys to be extracted, exported, or shared under any circumstances. テナント キーと BYOK については、「Azure Information Protection テナント キーを計画して実装する」を参照してください。For more information about the tenant key and BYOK, see Planning and implementing your Azure Information Protection tenant key.

Windows デバイスに送信されるライセンスと証明書は、クライアントのデバイス秘密キーで保護されます。このキーは、デバイスのユーザーが Azure RMS を初めて使ったときに作成されます。Licenses and certificates that are sent to a Windows device are protected with the client’s device private key, which is created the first time a user on the device uses Azure RMS. この秘密キーはさらに、クライアント上の DPAPI で保護されます。DPAPI は、ユーザーのパスワードから作成されたキーを使って、これらのシークレットを保護します。This private key, in turn, is protected with DPAPI on the client, which protects these secrets by using a key derived from the user’s password. モバイル デバイスでは、キーは 1 回しか使われず、クライアントに格納されないので、デバイスでこれらのキーを保護する必要はありません。On mobile devices, the keys are used only one time, so because they are not stored on the clients, these keys don’t need to be protected on the device.

Azure RMS の動作のチュートリアル: 初めての使用、コンテンツ保護、コンテンツ消費Walkthrough of how Azure RMS works: First use, content protection, content consumption

Azure RMS の動作をさらに詳しく理解するため、Azure Rights Management サービスがアクティブ化された後、ユーザーが初めて Windows コンピューター上の Rights Management サービスを使い (ユーザー環境の初期化 またはブートストラップと呼ばれることもあります)、コンテンツ (ドキュメントまたはメール) を保護 した後、他のユーザーによって保護されているコンテンツを 消費 (開いて使う) するときの一般的なフローを見ていきます。To understand in more detail how Azure RMS works, let's walk through a typical flow after the Azure Rights Management service is activated and when a user first uses the Rights Management service on their Windows computer (a process sometimes known as initializing the user environment or bootstrapping), protects content (a document or email), and then consumes (opens and uses) content that has been protected by somebody else.

ユーザー環境が初期化された後、そのユーザーはそのコンピューターでドキュメントを保護したり、保護されているドキュメントを消費したりできます。After the user environment is initialized, that user can then protect documents or consume protected documents on that computer.

注意

このユーザーが別の Windows コンピューターを使う場合、または別のユーザーがこの同じ Windows コンピューターを使う場合は、初期化プロセスが繰り返されます。If this user moves to another Windows computer, or another user uses this same Windows computer, the initialization process is repeated.

ユーザー環境の初期化Initializing the user environment

ユーザーが Windows コンピューターでコンテンツを保護する場合、または保護されたコンテンツを消費する場合は、その前に、デバイスでユーザー環境を準備する必要があります。Before a user can protect content or consume protected content on a Windows computer, the user environment must be prepared on the device. これは 1 回限りのプロセスであり、ユーザーがコンテンツを保護したり保護されたコンテンツを消費したりしようとすると、ユーザーの介入なしに自動的に行われます。This is a one-time process and happens automatically without user intervention when a user tries to protect or consume protected content:

RMS クライアント アクティブ化フロー - ステップ 1: クライアントの認証

ステップ 1 で行われること: コンピューター上の RMS クライアントは、最初に、Azure Rights Management サービスに接続し、Azure Active Directory アカウントを使ってユーザーを認証します。What's happening in step 1: The RMS client on the computer first connects to the Azure Rights Management service, and authenticates the user by using their Azure Active Directory account.

ユーザーのアカウントが Azure Active Directory とフェデレーションされていると、この認証は自動的に行われ、ユーザーが資格情報の入力を求められることはありません。When the user’s account is federated with Azure Active Directory, this authentication is automatic and the user is not prompted for credentials.

RMS クライアント アクティブ化 - ステップ 2: 証明書がクライアントにダウンロードされる

ステップ 2 で行われること: ユーザーが認証された後、接続は組織の Azure Information Protection テナントに自動的にリダイレクトされます。テナントは、ユーザーが保護されたコンテンツを消費したり、オフラインでコンテンツを保護したりするために、Azure Rights Management サービスへの認証を実行できる証明書を発行します。What's happening in step 2: After the user is authenticated, the connection is automatically redirected to the organization’s Azure Information Protection tenant, which issues certificates that let the user authenticate to the Azure Rights Management service in order to consume protected content and to protect content offline.

これらの証明書の 1 つとして権利アカウント証明書 (RAC) があります。One of these certificates is the rights account certificate, often abbreviated to RAC. この証明書は、Azure Active Directory するためにユーザーを認証し、31日間有効です。This certificate authenticates the user to Azure Active Directory and is valid for 31 days. 証明書は、ユーザー アカウントが Azure Active Directory にあり、アカウントが有効になっている場合、RMS クライアントによって自動的に更新されます。The certificate is automatically renewed by the RMS client, providing the user account is still in Azure Active Directory and the account is enabled. この証明書は、管理者が構成することはできません。This certificate is not configurable by an administrator.

この証明書のコピーは Azure に保存され、ユーザーが別のデバイスに移動した場合は、同じキーを使用して証明書が作成されます。A copy of this certificate is stored in Azure so that if the user moves to another device, the certificates are created by using the same keys.

コンテンツの保護Content protection

ユーザーがドキュメントを保護すると、RMS クライアントは保護されていないドキュメントに対して次の操作を実行します。When a user protects a document, the RMS client takes the following actions on an unprotected document:

RMS ドキュメントの保護 - ステップ 1: ドキュメントが暗号化される

ステップ 1 で行われること: RMS クライアントは、ランダムなキー (コンテンツ キー) を作成し、このキーと AES 対称暗号化アルゴリズムを使って、ドキュメントを暗号化します。What's happening in step 1: The RMS client creates a random key (the content key) and encrypts the document using this key with the AES symmetric encryption algorithm.

RMS ドキュメントの保護 - ステップ 2: ポリシーが作成される

ステップ 2 で行われること: RMS クライアントは、ドキュメントに対するポリシーを含む証明書を作成します。ポリシーには、ユーザーまたはグループに対する 使用権限と、有効期限などの他の制限事項が含まれます。What's happening in step 2: The RMS client then creates a certificate that includes a policy for the document that includes the usage rights for users or groups, and other restrictions, such as an expiration date. これらの設定は、それ以前に管理者が構成するテンプレートで定義することも、またはコンテンツを保護するときに指定することも ("アドホック ポリシー" とも呼ばれます) できます。These settings can be defined in a template that an administrator previously configured, or specified at the time the content is protected (sometimes referred to as an "ad hoc policy").

選択されたユーザーやグループの識別に使われるメインの Azure AD 属性は、Azure AD の ProxyAddresses 属性であり、この属性にはユーザーまたはグループのすべてのメール アドレスが格納されます。The main Azure AD attribute used to identify the selected users and groups is the Azure AD ProxyAddresses attribute, which stores all the email addresses for a user or group. ただし、ユーザー アカウントの AD ProxyAddresses 属性に値が何も含まれない場合は、ユーザーの UserPrincipalName の値が代わりに使われます。However, if a user account doesn't have any values in the AD ProxyAddresses attribute, the user's UserPrincipalName value is used instead.

その後、RMS クライアントは、ユーザー環境の初期化時に取得された組織のキーを使って、ポリシーと対称コンテンツ キーを暗号化します。The RMS client then uses the organization’s key that was obtained when the user environment was initialized and uses this key to encrypt the policy and the symmetric content key. また、RMS クライアントは、ユーザー環境の初期化時に取得されたユーザーの証明書でポリシーに署名します。The RMS client also signs the policy with the user’s certificate that was obtained when the user environment was initialized.

RMS ドキュメントの保護 - ステップ 3: ポリシーがドキュメントに埋め込まれる

手順3で 行われること: 最後に、RMS クライアントは、以前に暗号化されたドキュメントの本文と共にポリシーをファイルに埋め込みます。これは、保護されたドキュメントを構成します。What's happening in step 3: Finally, the RMS client embeds the policy into a file with the body of the document encrypted previously, which together comprise a protected document.

このドキュメントは、任意の方法を使って、任意の場所に格納したり共有したりでき、ポリシーは暗号化されたドキュメントと共に常に存在します。This document can be stored anywhere or shared by using any method, and the policy always stays with the encrypted document.

コンテンツの消費Content consumption

ユーザーが保護されたドキュメントの消費を望むと、RMS クライアントは最初に Azure Rights Management サービスへのアクセスを要求します。When a user wants to consume a protected document, the RMS client starts by requesting access to the Azure Rights Management service:

RMS ドキュメントの消費 - ステップ 1: ユーザーが認証されて、権限の一覧を取得する

ステップ 1 で行われること: 認証されたユーザーは、ドキュメントのポリシーとユーザーの証明書を Azure Rights Management サービスに送信します。What's happening in step 1: The authenticated user sends the document policy and the user’s certificates to the Azure Rights Management service. サービスはポリシーの暗号化を解除して評価し、ユーザーがドキュメントに対して持っている権限の一覧を作成します (ある場合)。The service decrypts and evaluates the policy, and builds a list of rights (if any) the user has for the document. ユーザーを識別するには、Azure AD の ProxyAddresses 属性が、ユーザーのアカウントとユーザーがメンバーであるグループに対して使われます。To identify the user, the Azure AD ProxyAddresses attribute is used for the user's account and groups to which the user is a member. パフォーマンス上の理由から、グループ メンバーシップはキャッシュされます。For performance reasons, group membership is cached. ユーザー アカウントの Azure AD ProxyAddresses 属性に値がない場合は、Azure AD UserPrincipalName の値が代わりに使われます。If the user account has no values for the Azure AD ProxyAddresses attribute, the value in the Azure AD UserPrincipalName is used instead.

RMS ドキュメントの消費 - ステップ 2: 使用ライセンスがクライアントに返される

ステップ 2 で行われること: その後、サービスは暗号化解除されたポリシーから AES コンテンツ キーを抽出します。What's happening in step 2: The service then extracts the AES content key from the decrypted policy. このキーは、要求で取得されたユーザーの公開 RSA キーで暗号化されます。This key is then encrypted with the user’s public RSA key that was obtained with the request.

再暗号化されたコンテンツ キーは、暗号化された使用ライセンスとユーザー権限の一覧に埋め込まれて、RMS クライアントに返されます。The re-encrypted content key is then embedded into an encrypted use license with the list of user rights, which is then returned to the RMS client.

RMS ドキュメントの消費 - ステップ 3: ドキュメントが暗号化解除されて、権限が適用される

ステップ 3 で行われること: 最後に、RMS クライアントは暗号化された使用ライセンスを取得し、独自のユーザー秘密キーで暗号化を解除します。What's happening in step 3: Finally, the RMS client takes the encrypted use license and decrypts it with its own user private key. これにより、RMS クライアントは必要に応じてドキュメント本文の暗号化を解除し、画面にレンダリングできます。This lets the RMS client decrypt the document’s body as it is needed and render it on the screen.

また、クライアントは、権限一覧の暗号化を解除してアプリケーションに渡し、アプリケーションのユーザー インターフェイスにそれらの権限を適用します。The client also decrypts the rights list and passes them to the application, which enforces those rights in the application’s user interface.

注意

組織の外部のユーザーが組織で保護されているコンテンツを消費するときのフローも同じです。When users who are external to your organization consume content that you've protected, the consumption flow is the same. このシナリオで異なる点は、ユーザーを認証する方法です。What changes for this scenario, is how the user is authenticated. 詳細については、「保護されたドキュメントを社外のユーザーと共有する場合、そのユーザーはどのようにして認証されますか」を参照してください。For more information, see When I share a protected document with somebody outside my company, how does that user get authenticated?

バリエーションVariations

これまでに示した流れは標準的なシナリオのものですが、いくつかのバリエーションがあります。The preceding walkthroughs cover the standard scenarios but there are some variations:

  • 電子メールの保護: Exchange Online と新しい機能を備えた Office 365 Message Encryption を使ってメール メッセージを保護するとき、消費するための認証では、ソーシャル ID プロバイダーとのフェデレーションまたはワンタイム パスコードを使うこともできます。Email protection: When Exchange Online and Office 365 Message Encryption with new capabilities is used to protect email messages, authentication for consumption can also use federation with a social identity provider or by using a one-time passcode. その後のプロセス フローは、送信メールの一時的なキャッシュ コピーを介して Web ブラウザー セッションのサービス側でコンテンツの消費が行われるのを除けば、よく似ています。Then, the process flows are very similar, except that content consumption happens service-side in a web browser session over a temporarily cached copy of the outbound email.

  • モバイル デバイス: モバイル デバイスが Azure Rights Management サービスでファイルを保護または消費するときのプロセス フローはとても簡単です。Mobile devices: When mobile devices protect or consume files with the Azure Rights Management service, the process flows are much simpler. モバイル デバイスでは、(コンテンツを保護または消費するための) 各トランザクションが独立しているため、最初にユーザー初期化プロセスを行う必要はありません。Mobile devices don’t first go through the user initialization process because instead, each transaction (to protect or consume content) is independent. Windows コンピューターと同様に、モバイル デバイスは Azure Rights Management サービスに接続して認証を行います。As with Windows computers, mobile devices connect to the Azure Rights Management service and authenticate. コンテンツを保護するには、モバイル デバイスはポリシーを送信し、Azure Rights Management サービスはドキュメントを保護するための発行ライセンスと対称キーを送信します。To protect content, mobile devices submit a policy and the Azure Rights Management service sends them a publishing license and symmetric key to protect the document. コンテンツを消費するには、モバイル デバイスは、Azure Rights Management サービスに接続して認証を行うときに、Azure Rights Management サービスにドキュメント ポリシーを送信し、ドキュメントを消費するための使用ライセンスを要求します。To consume content, when mobile devices connect to the Azure Rights Management service and authenticate, they send the document policy to the Azure Rights Management service and request a use license to consume the document. 応答で、Azure Rights Management サービスはモバイル デバイスに必要なキーと制限を送信します。In response, the Azure Rights Management service sends the necessary keys and restrictions to the mobile devices. どちらのプロセスも、TLS を使って、キーの交換およびその他の通信を保護します。Both processes use TLS to protect the key exchange and other communications.

  • RMS コネクタ: Azure Rights Management サービスが RMS コネクタで使われるときも、プロセス フローは変わりません。RMS connector: When the Azure Rights Management service is used with the RMS connector, the process flows remain the same. 唯一の違いは、コネクタがオンプレミスのサービス (Exchange Server や SharePoint Server など) と Azure Rights Management サービスの間のリレーとして機能することです。The only difference is that the connector acts as a relay between the on-premises services (such as Exchange Server and SharePoint Server) and the Azure Rights Management service. コネクタ自体は、ユーザー環境の初期化、暗号化、暗号化解除など、いかなる操作も実行しません。The connector itself does not perform any operations, such as the initialization of the user environment, or encryption or decryption. コネクタは、通常は AD RMS サーバーに送られる通信をリレーし、それぞれの側で使われているプロトコル間の変換を処理するだけです。It simply relays the communication that would usually go to an AD RMS server, handling the translation between the protocols that are used on each side. このシナリオでは、オンプレミスのサービスで Azure Rights Management サービスを使うことができます。This scenario lets you use the Azure Rights Management service with on-premises services.

  • 一般的な保護 (.pfile): Azure Rights Management サービスが一般的にファイルを保護しているときは、RMS クライアントがすべての権限を許可するポリシーを作成する点を除き、フローは基本的にコンテンツ保護の場合と同じです。Generic protection (.pfile): When the Azure Rights Management service generically protects a file, the flow is basically the same for content protection except that the RMS client creates a policy that grants all rights. ファイルが消費されるときは、ターゲット アプリケーションに渡される前にファイルが暗号化解除されます。When the file is consumed, it is decrypted before it is passed to the target application. このシナリオでは、ファイルが RMS をネイティブにサポートしない場合でも、すべてのファイルを保護できます。This scenario lets you protect all files, even if they don’t natively support RMS.

  • Microsoft アカウント: Microsoft アカウントで認証されていれば、Azure Information Protection で消費用の電子メール アドレスを承認できます。Microsoft accounts: Azure Information Protection can authorize email addresses for consumption when they are authenticated with a Microsoft account. ただし、Microsoft アカウントが認証に使用されている場合、アプリケーションによっては、保護されたコンテンツを開けない場合があます。However, not all applications can open protected content when a Microsoft account is used for authentication. 詳細については、こちらを参照してください。More information.

次のステップNext steps

Azure Rights Management サービスについては、「理解と調査」セクションの「アプリケーションによる Azure Rights Management サービスのサポート」などの他の記事で、既存のアプリケーションを Azure Rights Management と統合して情報保護ソリューションを提供する方法を学習してください。To learn more about the Azure Rights Management service, use the other articles in the Understand & Explore section, such as How applications support the Azure Rights Management service to learn how your existing applications can integrate with Azure Rights Management to provide an information protection solution.

Azure Information Protection の用語」で、Azure Rights Management サービスを構成および使用するときに目にする用語をよく理解してください。また、展開を始める前に、「Azure Information Protection の要件」も確認してください。Review Terminology for Azure Information Protection so that you’re familiar with the terms that you might come across as you’re configuring and using the Azure Rights Management service, and be sure to also check Requirements for Azure Information Protection before you start your deployment. すぐに試してみたい場合は、クイックスタートとチュートリアルを使用してください。If you want to dive right in and try it out for yourself, use the quickstart and tutorials:

組織のデータ保護のデプロイを開始する準備ができたら、AIP デプロイロードマップを使用して、展開の手順と具体的な操作手順へのリンクについて、 分類、ラベル付け、保護を 行います。If you’re ready to start deploying data protection for your organization, use the AIP deployment roadmap for classification, labeling, and protection for your deployment steps and links for how-to instructions.

ヒント

追加情報やヘルプについては、「Azure Information Protection の情報とサポート」のリソースとリンクをご覧ください。For additional information and help, use the resources and links in Information and support for Azure Information Protection.