Azure Information Protection による保護の使用状況のログと分析
Note
Microsoft Purview Information Protection をお探しですか? (以前の Microsoft Information Protection (MIP))
Azure Information Protection アドインは廃止され、Microsoft 365 アプリとサービスに組み込まれているラベルに置き換えられています。 詳細については、「他の Azure Information Protection コンポーネントのサポート状況」を参照してください。
新しい Microsoft Information Protection クライアント (アドインなし) は現在プレビュー段階であり、一般提供が予定されています。
この情報は、Azure Information Protection からの保護サービス (Azure Rights Management) の使用状況ログの使用方法を理解するのに役立ちます。 この保護サービスは、組織のドキュメントや電子メールのデータ保護機能を提供し、このサービスに対するすべての要求を記録できます。 これらの要求には、ユーザーがドキュメントと電子メールを保護する場合、ユーザーがこのコンテンツを使用する場合、このサービスの管理者によって実行されるアクション、および Azure Information Protection の展開をサポートするために Microsoft オペレーターによって実行されるアクションが含まれます。
これらの保護の使用状況ログを使用すると、次のビジネス シナリオをサポートできます。
ビジネス インサイトの分析
保護サービスで生成されるログを、選択したリポジトリ (データベース、オンライン分析処理 (OLAP) システム、map-reduce システムなど) にインポートすることによって、情報を分析してレポートを生成できます。 たとえば、保護されたデータにアクセスしているユーザーを特定できます。 ユーザーがアクセスしている保護されたデータと、どのデバイスから、どこからアクセスしているのかを判断できます。 ユーザーが保護されたコンテンツを正常に読み取ることができるかどうかを確認できます。 また、保護された重要なドキュメントを読んだユーザーを特定することもできます。
不正使用の監視
保護の使用に関するログ情報はほぼリアルタイムに提供されるため、会社での保護サービスの使用状況を継続的に監視できます。 ログの 99.9% は、サービスに対して開始されたアクションから 15 分以内に使用できます。
たとえば、標準勤務時間外に保護されたデータを読み取るユーザーが急激に増加した場合にアラートを受け取る必要があります。これは、悪意のあるユーザーが競合他社に販売する情報を収集していることを示している可能性があります。 または、同じユーザーが短時間で 2 つの異なる IP アドレスからデータにアクセスする場合は、ユーザー アカウントが侵害されたことを示している可能性があります。
フォレンジック解析を実行する
情報漏えが発生した場合は、最近特定のドキュメントにアクセスしたユーザーと、最近アクセスした疑いのあるユーザーがどのような情報にアクセスしたかを尋ねられる可能性があります。 このログを使用すれば、このような質問に答えることができます。保護されているコンテンツを使用するユーザーが Azure Information Protection サービスで保護されているドキュメントおよび画像を開くには、常に Rights Management ライセンスを取得する必要があるためです。これは、ファイルが電子メールで転送されたり、USB ドライブなどのストレージ デバイスにコピーされたりした場合も同様です。 このため、Azure Information Protection を使用してデータを保護していれば、これらのログをフォレンジック分析のための最終的な情報源として活用できます。
この使用しているログに加えて、次のログオプションもあります。
| ログ オプション | 説明 |
|---|---|
| 管理ログ | 保護サービスの管理タスクをログに記録します。 たとえば、サービスが非アクティブ化されている場合、スーパー ユーザー機能が有効になっている場合、およびユーザーがサービスに管理者アクセス許可を委任されている場合などです。 詳細については、PowerShell コマンドレット「Get-AipServiceAdminLog」をご覧ください。 |
| ドキュメント追跡 | ユーザーが Azure Information Protection クライアントを使用して追跡したドキュメントを追跡および取り消すことができる。 全体管理者は、ユーザーに代わってこれらのドキュメントを追跡することもできます。 詳細については、「Azure Information Protection のドキュメント追跡の設定と使用」を参照してください。 |
| クライアント イベント ログ | Azure Information Protection クライアントの使用アクティビティに、ローカルの Windows アプリケーションとサービスへのログイン イベント ログ、Azure Information Protection。 詳細については、Azure Information Protection クライアントの使用状況ログに関するページをご覧ください。 |
| クライアントのログ ファイル | %localappdata%\Microsoft\MSIP にある Azure Information Protection クライアントのトラブルシューティング ログ。 これらのファイルは、Microsoft サポート用に設計されています。 |
さらに、Azure Information Protection クライアントの使用ログと Azure Information Protection スキャナーからの情報が収集および集計され、Azure portal でレポートを作成する。 詳細については、「Azure Information Protection のレポート」を参照してください。
次のセクションでは、保護サービスの使用状況ログの詳細について説明します。
保護の使用状況のログを有効にする方法
保護の使用状況のログは、すべてのお客様に対して既定で有効になっています。
ログ保存またはログ機能に追加コストは発生しません。
保護の使用状況ログにアクセスして使用する方法
Azure Information Protection のログは、テナントに対して自動的に作成される Azure ストレージ アカウントに一連の BLOB として書き込まれます。 各 BLOB には、W3C 拡張ログ形式の1つまたは1つ以上のログ レコードが含まれています。 BLOB 名は、作成された順序の番号です。 このドキュメントの後述べる「Azure Rights Management の使用ログを解釈する方法」セクションには、ログの内容とその作成に関する詳細が含まれています。
保護操作の実行後、ログがストレージ アカウントに書き込まれるまで若干時間がかかります。 ほとんどのログは 15 分以内に出現できる。 使用ログは、"date" フィールド名に以前の日付 (UTC 時刻) の値が含まれている場合にのみ使用できます。 現在の日付の使用ログは使用できません。 ローカル フォルダー、データベース、map-reduce リポジトリなどのように、ローカル ストレージにログをダウンロードすることをお勧めします。
使用状況ログをダウンロードするには、Azure Information Protection 用 AIPService PowerShell モジュールを使用します。 インストール手順については、「AIPService PowerShell モジュールのインストール」を参照してください。
PowerShell を使用して使用ログをダウンロードする。
[管理者として実行] オプションを選択して Windows PowerShell を起動し、Connect-AipService コマンドレットを使用して Azure Information Protection に接続します。
Connect-AipService次のコマンドを実行して、特定の日付のログをダウンロードします。
Get-AipServiceUserLog -Path <location> -fordate <date>たとえば、後でE: ドライブに Logs という名前のフォルダーを作成する。
特定の日付 (例え2016 年 2 月 1 日など) のログをダウンロードするには、次のコマンド
Get-AipServiceUserLog -Path E:\Logs -fordate 2/1/2016を実行します。日付範囲 (例え2016 年 2 月 1 日から 2016 年 2 月 14 日までなど) のログをダウンロードするには、次のコマンド
Get-AipServiceUserLog -Path E:\Logs -fromdate 2/1/2016 –todate 2/14/2016を実行します。
この例のように日のみを指定した場合、時刻は現地時刻の 00:00:00 と見なされ、UTC に変換されます。 fromdate パラメーターまたは -todate パラメーター (例: -fordate "2/1/2016 15:00:00") で時刻を指定すると、その日付と時刻は UTC に変換されます。 Get-AipServiceUserLog コマンドは、その UTC の時間帯のログを取得します。
ダウンロードするに 1 日未満を指定することはできません。
既定では、このコマンドレットは 3 つのスレッドを使用してログをダウンロードします。 十分なネットワーク帯域幅があり、ログのダウンロードに必要な時間を短縮する場合は、 -NumberOfThreads パラメーターを使用して 1 から 32 までの値をサポートできます。 たとえば、次のコマンドを実行すると、コマンドレットによって 10 個のスレッドが生成され、ログGet-AipServiceUserLog -Path E:\Logs -fromdate 2/1/2016 –todate 2/14/2016 -numberofthreads 10がダウンロードされます。
ヒント
Microsoft の Log Parser を使用して、ダウンロードしたすべてのログ ファイルを CSV 形式に集計できます。これは、さまざまな既知のログ形式間で変換するツールです。 このツールを使用して、データを SYSLOG 形式に変換したり、データベースにインポートしたりすることもできます。 ツールをインストールしたら、このツールを使用するためのヘルプと情報を探して実行 LogParser.exe /? します。
たとえば、次のコマンドを実行して、すべての情報を .log ファイル形式にインポートできます。 logparser –i:w3c –o:csv "SELECT * INTO AllLogs.csv FROM *.log"
使用状況ログを解釈する方法
保護の使用状況ログを解釈するには、次の情報を活用してください。
ログ順位
Azure Information Protection のログは一連の BLOB として書き込まれます。
ログ内の各入力には UTC タイムスタンプがあります。 保護サービスは複数のデータ センターにまたがる複数のサーバー上で実行されるため、タイムスタンプで並べ替えられたログであっても、それらが順序どおりではないように見える場合があります。 ただし、違いは小さくい、通常は 1 分以内です。 ほとんどの場合、これはログ解析の問題となることはありません。
BLOB 形式
各 BLOB は W3C 拡張ログ形式です。 次の 2 行から始まります。
#Software: RMS
#バージョン 1.1
最初の行は、これらが Azure Information Protection による保護のログであることを示しています。 2 行目では、BLOB の残りの部分がバージョン 1.1 の仕様に従っていることを示します。 これらのログを解析するアプリケーションでは、BLOB の残りの部分を解析する前に、これらの 2 行を確認することをお勧めします。
3 行目は、タブで区切られたフィールド名の一覧を列挙します。
#Fields: date time row-id request-type user-id result correlation-id content-id owner-email issuer template-id file-name date-published c-info c-ip admin-action acting-as-user
後続の各行はログ レコードです。 フィールドの値は、前の行と同じ順序で、タブで区切られます。 次のテーブルを使用してフィールドをインタープリターします
| フィールド名 | W3Cデータ型 | 説明 | 例値 |
|---|---|---|---|
| date | 日 | 要求が処理された時 UTC 日付する。 ソースは、要求を処理したサーバー上のローカル クロックです。 |
2013-06-25 |
| time | 時刻 | 要求が処理された時 24 時間形式の UTC 時刻を記録する。 ソースは、要求を処理したサーバー上のローカル クロックです。 |
21:59:28 |
| row-id | Text | このログレコードのユニークガイド。 値が存在しない場合は、correlation-id 値を使用して入力を識別します。 この値は、ログを集計したり、ログを別の形式にコピーしたりする場合に便利です。 |
1c3fe7a9-d9e0-4654-97b7-14fafa72ea63 |
| request-type | 名前 | 要求された RMS API の名前。 | AcquireLicense |
| user-id | String | 要求を行ったユーザー。 値は単一引用符で囲まれます。 ユーザーが管理するテナント キー (BYOK) からの呼び出しの値は "要求の種類が匿名の場合にも適用されます。 |
‘joe@contoso.com’ |
| result | String | 要求が成功した場合は‘Success' です。 要求が失敗した場合のエラーの種類をは単一引用符で囲みます。 |
'Success' |
| correlation-id | Text | 特定の要求の RMS クライアント ログとサーバー ログの間で一般的な GUID。 この値は、クライアントの問題のトラブルシューティングに役立ちます。 |
cab52088-8925-4371-be34-4b71a3112356 |
| content-id | Text | 中かっこで囲まれた GUIDが保護されたコンテンツ (ドキュメントなど) を識別する。 このフィールドには、要求の種類が AcquireLicense で、他のすべての要求の種類に対して空白の場合にのみ値があります。 |
{bb4af47b-cfed-4719-831d-71b98191a4f2} |
| オーナーのメール | String | オーナーのドキュメントのメール アドレス。 要求の種類が RevokeAccess の場合、このフィールドは空白です。 |
alice@contoso.com |
| issuer | String | ドキュメント発行者の電子メール アドレス。 要求の種類が RevokeAccess の場合、このフィールドは空白です。 |
alice@contoso.com (または )FederatedEmail.4c1f4d-93bf-00a95fa1e042@contoso.onmicrosoft.com' |
| template-id | String | テンプレートの IDがドキュメントを保護に使用される。 要求の種類が RevokeAccess の場合、このフィールドは空白です。 |
{6d9371a6-4e2d-4e97-9a38-202233fed26e} |
| file-name | String | Windows 用 Azure Information Protection クライアントを使用して保護されたドキュメントのファイル名が追跡される。 現在、一部のファイル (Office ドキュメントなど) は、実際のファイル名ではなく GUID として表示されます。 要求の種類が RevokeAccess の場合、このフィールドは空白です。 |
TopSecretDocument.docx |
| date-published | 日 | ドキュメントが保護された時の日付。 要求の種類が RevokeAccess の場合、このフィールドは空白です。 |
2015-10-15T21:37:00 |
| c-info | String | 要求を行っているクライアント プラットフォームに関する情報。 特定の文字列は、アプリケーション (オペレーティング システムやブラウザーなど) によって異なります。 |
'MSIPC;version=1.0.623.47;AppName=WINWORD.EXE;AppVersion=15.0.4753.1000;AppArch=x86;OSName=Windows;OSVersion=6.1.7601;OSArch=amd64' |
| c-ip | 番地 | 要求を行ったクライアントの IP アドレスです。 | 64.51.202.144 |
| 管理者の操作 | Bool | 管理者がドキュメントをアクセスかどうかにして、ドキュメント追跡サイトは管理者モードにしています。 | True |
| acting-as-user | String | 管理者がドキュメント追跡サイトにアクセスしているユーザーの電子メール アドレス。 | 'joe@contoso.com' |
ユーザー ID フィールドの例外
user-id フィールドは通常、要求を行ったユーザーを示しますが、値が実際のユーザーにマップされない例外が 2 つあります。
値 'microsoftrmsonline@<君のテナントID.rms>。<region.aadrm.com>'.
これは、Office 365 サービス (Exchange Online や Microsoft SharePoint など) が要求を行っていることを示します。 文字列では、<君のテナントID> はテナントの GUID であり、<リージョン>はテナントが登録される場所のリージョンです。 たとえば、na は北米を表し、eu はヨーロッパを表し、ap はアジアを表します。
RMS コネクタを使用している場合。
このコネクタからの要求は、RMS コネクタの インストール時に自動的に生成される Aadrm_S-1-7-0 のサービス プリンシパル名でログに記録されます。
典型的な要求の種類
保護サービスには多くの要求の種類がありますが、次の表に最も一般的に使用される要求の種類をいくつか示します。
| 要求の種類 | 説明 |
|---|---|
| AcquireLicense | Windows ベースのコンピューターのクライアントが、保護されているコンテンツのライセンスを要求しています。 |
| AcquirePreLicense | ユーザーに代わってクライアントが、保護されているコンテンツのライセンスを要求しています。 |
| AcquireTemplates | テンプレート ID に基づいてテンプレートを取得するための呼び出しが行われました |
| AcquireTemplateInformation | サービスからテンプレートの ID を取得するための呼び出しが行われました。 |
| AddTemplate | Azure portal から、テンプレートを追加するための呼び出しが行われます。 |
| AllDocsCsv | [すべてのドキュメント] ページから CSV ファイルをダウンロードするために、ドキュメント追跡サイトから呼び出しが行われます。 |
| BECreateEndUserLicenseV1 | モバイル デバイスから、エンド ユーザー ライセンスを作成するための呼び出しが行われます。 |
| BEGetAllTemplatesV1 | モバイル デバイス (バックエンド) から、すべてのテンプレートを取得するための呼び出しが行われます。 |
| Certify | クライアントは、保護されたコンテンツの使用と作成についてユーザーを認定しています。 |
| FECreateEndUserLicenseV1 | AcquireLicense 要求に似ていますが、モバイル デバイスから。 |
| FECreatePublishingLicenseV1 | モバイル クライアントからの Certify と GetClientLicensorCert の組み合わせと同じです。 |
| FEGetAllTemplates | モバイル デバイス (フロントエンド) から、テンプレートを取得するための呼び出しが行われます。 |
| FindServiceLocationsForUser | CERTIFY または AcquireLicense を呼び出すために使用される URL をクエリするための呼び出しが行われます。 |
| GetClientLicensorCert | クライアントは、(後でコンテンツを保護するために使用される) 発行証明書を Windows ベースのコンピューターから要求しています。 |
| GetConfiguration | Azure RMS テナントの構成を取得するために、Azure PowerShell コマンドレットが呼び出されます。 |
| GetConnectorAuthorizations | RMS コネクタから、構成をクラウドから取得するための呼び出しが行われます。 |
| GetRecipients | 1 つのドキュメントのリスト ビューに移動するために、ドキュメント追跡サイトから呼び出しが行われます。 |
| GetTenantFunctionalState | Azure portal が、保護サービス (Azure Rights Management) がアクティブかどうかを調べています。 |
| KeyVaultDecryptRequest | クライアントが RMS で保護されたコンテンツの暗号化を解除しようとしています。 Azure Key Vault の顧客管理 テナント キー (BYOK) にのみ適用されます。 |
| KeyVaultGetKeyInfoRequest | Azure Information Protection テナント キーに対して Azure Key Vault で使用するように指定されたキーにアクセス可能であり、まだ使用されていないことを確認する呼び出しが行われます。 |
| KeyVaultSignDigest | Azure Key Vault の顧客管理キー (BYOK) が署名目的で使用されると、呼び出しが行われます。 これは特に、AcquireLicence (または FECreateEndUserLicenseV1)、Certify、GetClientLicensorCert (または FECreatePublishingLicenseV1) ごとに 1 回呼び出されます。 |
| KMSPDecrypt | クライアントが RMS で保護されたコンテンツの暗号化を解除しようとしています。 従来の顧客管理 テナント キー (BYOK) にのみ適用されます。 |
| KMSPSignDigest | 従来の顧客管理キー(BYOK) が署名目的で使用されると、呼び出しが行われます。 これは特に、AcquireLicence (または FECreateEndUserLicenseV1)、Certify、GetClientLicensorCert (または FECreatePublishingLicenseV1) ごとに 1 回呼び出されます。 |
| ServerCertify | RMS 対応クライアント (SharePoint など) から、サーバーを認証するための呼び出しが行われます。 |
| SetUsageLogFeatureState | 使用状況ログを有効にするための呼び出しが行われます。 |
| SetUsageLogStorageAccount | Azure Rights Management サービス ログの場所を指定するための呼び出しが行われます。 |
| UpdateTemplate | Azure portal から、既存のテンプレートを更新するための呼び出しが行われます。 |
使用ログとの保護と Microsoft 365 統合監査ログ
ファイル アクセスイベントと拒否イベントには現在、ファイル名は含まれていません。また、Microsoft 365 統合監査ログではアクセスできません。 これらのイベントはスタンドアロン使用できるようにて補正され、後日 Rights Management サービスから追加されます。
PowerShell リファレンス
保護の使用状況ログにアクセスするために必要な PowerShell コマンドレットは、Get-AipServiceUserLog だけです。
Azure Information Protection 用に PowerShell を使用する方法の詳細については、「PowerShell を使用して Azure Information Protection による保護を管理する」を参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示