Azure RMS の機能のHow does Azure RMS work? 詳細Under the hood

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

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). マイクロソフトがテナント キーを生成して管理することも、ユーザーが独自のテナント キーを生成して管理することもできます。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

2048 ビットは、Azure Rights Management サービスがアクティブ化されているときのキーの長さです。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 サービスの構成や使用で目にする用語を理解できるようにします。また、デプロイを開始する前に、「Requirements for Azure Information Protection」 (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 Edit the policy and create a new label tutorial.

データ保護を組織にデプロイする準備ができたら、「Azure Information Protection デプロイ ロードマップ」で、デプロイの手順と具体的な操作手順へのリンクを参照してください。If you’re ready to start deploying data protection for your organization, use the Azure Information Protection deployment roadmap 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.