Azure Information Protection クラシック クライアントに関するよく寄せられる質問
ラベルを統合ラベル付けに移行する適切なタイミングはいつですか。
Azure Information Protection ラベルを統合ラベル付けプラットフォームに移行することをお勧めします。これにより、他の統合ラベル付けをサポートするクライアントおよびサービスと共に、それらを秘密度ラベルとして使用できるようになります。
詳細と手順については、「Azure Information Protection ラベルを統合秘密度ラベルに移行する方法」を参照してください。
秘密度ラベルと統合ラベル付けプラットフォームに移行した後、ファイルを再暗号化する必要がありますか。
いいえ。AIP クラシック クライアントと Azure portal で管理されているラベルからの移行後、秘密度ラベルと統合ラベル付けプラットフォームに移行した後に、ファイルを再暗号化する必要はありません。
移行後は、Microsoft 365 コンプライアンス センターからラベルとラベル付けポリシーの管理を行います。
詳細については、Microsoft 365 のドキュメントに含まれる「秘密度ラベルの詳細」と、ブログ「統合ラベル付けの移行について」を参照してください。
Microsoft 365 のラベルと Azure Information Protection のラベルの違いは何ですか。
もともと、Microsoft 365 には保持ラベルしかありませんでした。これを使うと、その内容が Microsoft 365 サービスに格納されていた場合に、監査と保持のためにドキュメントとメールを分類できました。
これに対し、Azure portalの AIP クラシック クライアントを使用して当時構成されていた Azure Information Protection ラベルを使用すると、ドキュメントと電子メールがオンプレミスまたはクラウドに格納されているかどうかに関係なく、一貫した分類と保護ポリシーを適用できます。
Microsoft 365 では、保持ラベルに加えて秘密度ラベルもサポートされています。 秘密度ラベルは、Microsoft 365 コンプライアンス センターで作成および構成できます。
Azure portal で従来の AIP ラベルが構成されている場合は、それらを秘密度ラベルと統合ラベル付けクライアントに移行することをお勧めします。 詳細については、「チュートリアル: Azure Information Protection (AIP) クラシック クライアントから、統合ラベル付けクライアントへの移行」を参照してください。
詳細については、「Announcing availability of information protection capabilities to help protect your sensitive data」(機密データを保護するために使用できる情報保護機能の発表) をご覧ください。
Azure Information Protection client は分類とラベル付けを含むサブスクリプション用のみでしょうか。
いいえ。 クラシック AIP クライアントは、Azure Rights Management サービスのみが含まれるサブスクリプションで、データ保護の目的でのみ使用できます。
クラシック クライアントが Azure Information Protection ポリシーなしでインストールされている場合、そのクライアントは自動的に保護専用モードで動作します。これにより、ユーザーは Rights Management テンプレートとカスタム アクセス許可を適用できます。
分類とラベル付けを含むサブスクリプションを後で購入した場合、Azure Information Protection ポリシーをダウンロードする際に、クライアントは自動的に標準モードへと切り替わります。
Rights Management 所有者の設定
既定では、Windows Server FCI と Azure Information Protection スキャナーの両方で、Rights Management 所有者はファイルを保護するアカウントに設定されます。
既定の設定を次のようにオーバーライドします。
Windows Server FCI の場合: すべてのファイルに対して単一アカウントとなるように Rights Management 所有者を設定するか、各ファイルの Rights Management 所有者を動的に設定します。
Rights Management 所有者を動的に設定するには、-OwnerMail [ソース ファイルの所有者の電子メール] パラメーターと値を使用します。 この構成では、ファイルの所有者プロパティのユーザー アカウント名を使用して、Active Directory からユーザーのメール アドレスを取得します。
Azure Information Protection スキャナー: 新しく保護されたファイルの場合は、スキャナー プロファイルで -Default 所有者設定を指定して、指定したデータ ストア上のすべてのファイルに対して単一アカウントとなるように Rights Management 所有者を設定します。
ファイルごとに Rights Management 所有者を動的に設定することはできません。また、以前に保護されたファイルの Rights Management 所有者は変更されません。
注意
スキャナーで SharePoint サイトおよびライブラリのファイルを保護する場合、Rights Management 所有者は SharePoint エディターの値を使用して、ファイルごとに動的に設定されます。
1 つのファイルに複数の分類を適用することはできますか?
ユーザーが一度に選択できるのはドキュメントまたは電子メールごとに 1 つのラベルのみです。したがって、多くの場合、適用できる分類は 1 つのみとなります。 ただし、ユーザーがサブラベルを選択した場合、実際は同時に 2 つのラベル (プライマリ ラベルとセカンダリ ラベル) が適用されます。 サブラベルを使用すれば、1 つのファイルで 2 つの分類 (制御の追加レベルの親\子関係を示す) を適用することができます。
たとえば、Confidential というラベルに、Legal や Finance などのサブラベルを含めることができます。 これらのサブラベルには、異なる分類の視覚的なマーキングと異なる Rights Management テンプレートをそれぞれ適用することができます。 ユーザーは Confidential ラベル自体を選択することはできません。選択できるのは、Legal などのそのサブラベルのいずれか 1 つのみです。 したがって、表示されるラベル セットは Confidential \ Legal のようになります。 そのファイルのメタデータには、Confidential のカスタム テキスト プロパティが 1 つ、Legal のカスタム テキスト プロパティが 1 つ、さらに両方の値 (Confidential Legal) を含むものが含まれます。
サブラベルを使用する場合は、プライマリ ラベルで視覚的なマーキング、保護、および条件を構成しないでください。 サブレベルを使用する場合は、サブラベルのみにこれらの設定を構成します。 プライマリ ラベルとそのサブラベルでこれらの設定を構成した場合は、サブラベルの設定が優先されます。
他のユーザーがラベルを削除または変更しないようにするには、どうすればいいですか?
分類ラベルを下げる場合、ラベルを削除する場合、保護を解除する場合にその理由をユーザーが説明しなければならないポリシー設定がありますが、この設定ではこれらの操作を回避しません。 ユーザーによるラベルの削除または変更を防ぐには、コンテンツが既に保護されている必要があります。保護のアクセス許可ではユーザーにエクスポートまたはフル コントロールの使用権限が付与されません。
DLP ソリューションや他のアプリケーションは Azure Information Protection とどのように統合できますか?
Azure Information Protection は分類に永続的メタデータを使用し、これにはクリア テキストのラベルが含まれるので、DLP ソリューションや他のアプリケーションはこの情報を読み取ることができます。
このメタデータの詳細については、「メールやドキュメントに格納されるラベル情報」を参照してください。
Exchange Online のメール フロー ルールで、このメタデータを使用する例については、「Azure Information Protection ラベルの Exchange Online メール フロー ルールの構成」をご覧ください。
分類が自動的に含まれるドキュメント テンプレートを作成できますか?
はい。 ラベルを構成して、ラベル名を含むヘッダーまたはフッターを適用することができます。 ただし、それがご自身の要件を満たしていない場合は、Azure Information Protection クラシック クライアントでのみ、必要な書式設定を持つドキュメント テンプレートを作成し、フィールド コードとして分類を追加することができます。
例として、ドキュメントのヘッダーに分類を表示するテーブルがあるとします。 または、概要向けにドキュメントの分類を参照する具体的な表現を使用します。
このフィールド コードをドキュメントに追加するには:
ドキュメントにラベルを付けて保存します。 このアクションにより新しいメタデータ フィールドが作成され、これをフィールド コード用に使用できます。
ドキュメント内で、ラベルの分類を追加したい位置にカーソルを合わせた後、[挿入] タブから [テキスト]>[クイック パーツ]>[フィールド] を選択します。
[フィールド] ダイアログ ボックスの [カテゴリ] ドロップダウンから、[ドキュメント情報] を選択します。 次に、[フィールド名] ドロップダウンから [DocProperty (文書プロパティ)] を選択します。
[プロパティ] ドロップダウンから [秘密度] を選択し、[OK] を選択します。
現在のラベルの分類がドキュメントに表示され、この値はドキュメントを開くかテンプレートを使用するたびに自動的に更新されます。 このため、ラベルが変更されると、このフィールド コードに対して表示される分類がドキュメント内で自動的に更新されます。
Azure Information Protection を使用した電子メールの分類は、Exchange のメッセージ分類とどのように違いますか。
Exchange のメッセージ分類は電子メールを分類する古い機能で、分類が適用される Azure Information Protection ラベルまたは秘密度ラベルとは別に実装されます。
ただし、ユーザーが Outlook on the web や一部のモバイル用メール アプリケーションを使用して電子メールを分類するときに、ラベルによる分類および対応するラベル マーキングが自動的に追加されるように、この古い機能をラベルと共に統合することができます。
同じ手法を使用して、Outlook on the web とこれらのモバイル用メール アプリケーションで独自のラベルを使用できます。
Exchange Online で Outlook on the web を使用している場合は、これを行う必要はないことに注意してください。この組み合わせにより、Microsoft 365 コンプライアンス センターから秘密度ラベルを発行するときに組み込みのラベル付けがサポートされるためです。
Outlook on the web で組み込みのラベル付けを使用できない場合は、「従来の Exchange メッセージ分類との統合」にて、これを回避する構成手順を確認してください。
ドキュメントを保護および追跡するように Mac コンピューターを構成するにはどうすればよいですか。
まず、https://admin.microsoft.com のソフトウェア インストール リンクから Office for Mac がインストールされていることを確認します。 詳しい手順については、Microsoft 365 または Office 2019 の PC または Mac へのダウンロード、インストール、再インストールに関する記事を参照してください。
Microsoft 365 の職場または学校のアカウントを使用して、Outlook を開き、プロファイルを作成します。 次に新しいメッセージを作成し、次の操作を行って、Azure Rights Management サービスを使用してドキュメントや電子メールを保護できるように Office を構成します。
新規のメッセージで、[オプション] タブの [アクセス許可] をクリックし、[資格情報の確認] をクリックします。
プロンプトが表示されたら、Microsoft 365 の職場または学校アカウントの詳細情報をもう一度指定し、[サインイン] を選択します。
これによって Azure Rights Management テンプレートがダウンロードされ、[資格情報の確認] が、[無制限]、[転送不可]、およびテナントに公開されたすべての Azure Rights Management テンプレートを含むオプションで置換されます。 この新しいメッセージは、ここで取り消すことができます。
電子メール メッセージやドキュメントを保護するには、[オプション] タブで [アクセス許可] をクリックし、電子メールやドキュメントを保護するオプションまたはテンプレートを選択します。
ドキュメントを保護した後、ドキュメントを追跡するには、Azure Information Protection クラシック クライアントをインストールした Windows コンピューターから、Office アプリケーションまたはエクスプローラーを使用して、ドキュメントをドキュメント追跡サイトに登録します。 手順については、ドキュメントの追跡と取り消しに関するページを参照してください。 Mac コンピューターから、Web ブラウザーを使用してドキュメント追跡サイト (https://track.azurerms.com) に移動し、このドキュメントを追跡して取り消すことができるようになりました。
ドキュメント追跡サイトで失効をテストすると、最大 30 日間はドキュメントにアクセスできるというメッセージが表示されます。この期間を構成することはできますか。
はい。 このメッセージは、その特定のファイルの使用ライセンスを反映しています。
ファイルを取り消すと、そのアクションは、Azure Rights Management サービスでユーザーを認証する際にのみ適用できます。 そのため、ファイルに 30 日間の使用ライセンス有効期間があり、ユーザーが既にそのドキュメントを開いている場合、ユーザーはその使用ライセンスの期間中は引き続きドキュメントにアクセスすることができます。 使用ライセンスの期限が切れると、ユーザーの再認証が必要になりますが、ドキュメントが取り消されているため、その時点でユーザーのアクセスが拒否されます。
ドキュメントを保護したユーザーである Rights Management 発行者は、この取り消しから除外されており、常に自分のドキュメントにアクセスできます。
テナントに適用される使用ライセンスの有効期間の既定値は 30 日間です。ラベルまたはテンプレートで、この設定をより制限の厳しい値でオーバーライドできます。 使用ライセンスの詳細および構成方法については、「Rights Management の使用ライセンス」を参照してください。
BYOK と HYOK の違いは何ですか。また、どのような場合に使用することが推奨されますか。
Azure Information Protection において独自キーを持ち込む (BYOK) のは、Azure Rights Management 保護の独自キーをオンプレミスで作成する場合です。 そのキーを Azure Key Vault のハードウェア セキュリティ モジュール (HSM) に転送し、そこでそのキーの所有と管理を続行します。 このようにしない場合、Azure Rights Management 保護では Azure 内で自動的に作成、管理されるキーが使用されます。 この既定の構成は、"顧客管理" (BYOK オプション) ではなく "マイクロソフト管理" と呼ばれます。
BYOK の詳細と、組織でこのキー トポロジを選択するかどうかについては、「Azure Information Protection テナント キーを計画して実装する」を参照してください。
Azure Information Protection において独自キーを保持する (HYOK) 機能は、クラウドに格納されているキーで保護することができないドキュメントや電子メールのサブセットを持つような、少数の組織のためのものです。 こうした組織では、BYOK を使用してキーを作成し管理する場合でも、この制限が適用されます。 この制限は多くの場合、規制やコンプライアンス上の理由によるもので、HYOK 構成は "最高機密" 情報のみに適用されます。つまり、組織外には決して共有されず、内部ネットワークのみで利用され、モバイル デバイスからアクセスする必要のない情報です。
これらの例外 (通常は、保護する必要のあるすべてのコンテンツの 10% 未満) については、オンプレミスのソリューションである Active Directory Rights Management サービスを使用して、オンプレミスのキーを作成することができます。 このソリューションでは、コンピューターはクラウドから Azure Information Protection ポリシーを取得しますが、この識別されたコンテンツはオンプレミスのキーを使用して保護することができます。
HYOK の詳細、制限についての正しい理解、およびどのような場合に使用するかのガイダンスについては、「AD RMS 保護の Hold Your Own Key (HYOK) の要件と制限事項」を参照してください。
私の質問がここに見つからない場合はどうすればよいですか。
最初に、以下に示す分類、ラベル付け、またはデータ保護に関してよく寄せられる質問を確認してください。 Azure Rights Management サービス (Azure RMS) では、Azure Information Protection のデータ保護テクノロジを提供しています。 Azure RMS は分類およびラベル付けと併用するか、単体で使用できます。
回答が得られない場合は、「Azure Information Protection の情報とサポート」に示すリンクとリソースを確認してください。
さらに、エンドユーザー向けの FAQ が用意されています。