コンテンツにスキップ

Office 365およびAzureデータの可用性🔗

このページでは以下について説明します。

  • Secureworks® Taegis™ XDRがMicrosoft APIをポーリングする方法
  • 製品内でコレクションとイベント時刻を決定するタイムスタンプ
  • イベント時刻と取り込み時刻の間にギャップが発生する場合

イベント時刻と取り込み時刻🔗

イベントを分析する際、イベント時刻は通常、Microsoft（またはエクスポート）がアクティビティが発生したと示す時刻を指します。取り込み時刻は、その行の正規化イベントがXDRで作成された時刻、すなわちその行の取り込み（正規化）が完了した時刻です。取り込み時刻は、すべての下流処理が完了した時刻ではありません。検知機、アラート、調査やケース、自動化などのワークフローは、取り込み時刻の後にも実行される場合があります。Microsoftが後からレコードを公開または更新した場合や、ポーリングがまだその時間帯に到達していない場合、または検索インデックス作成が追いついていない場合（収集後のプラットフォーム遅延を参照）、イベント時刻と取り込み時刻の間に大きなギャップが生じることはよくあります。

用語 意味
API時刻フィールド Microsoftが各ポーリングで「この時間範囲で何が変わったか」を問い合わせるために使用するタイムスタンプ（例：Graph APIのlastUpdatedDateTimeやcreatedDateTime）。このフィールドは、行がダウンロード対象になるタイミングを制御しますが、必ずしもイベント時刻と一致しません。
イベント時刻（UI上、または生データエクスポートではevent_time_usecなど） 基本的にアクティビティが発生した時刻。ベンダーフィールド（activityDateTimeやcreatedDateTimeなど、ソースによって異なる）から取得されます。API時刻フィールドと必ずしも同じではありません。
取り込み時刻（UI上、または生データエクスポートではingest_time_usecなど） 正規化イベントが作成された時刻、すなわちその行の取り込み（正規化）が完了した時刻です。アラート、調査、自動化などの後続の製品動作は、このタイムスタンプの後にも発生する可能性があります。
可用性時刻 存在する場合、元のアクティビティ時刻よりもベンダーの最終更新時刻や修正時刻に近いことが多い（例：lastUpdatedDateTimeを使用するリスク検知など）。

イベント時刻と取り込み時刻が異なる主な理由：

  1. ベンダー遅延 — Microsoftは、アクティビティ発生から数分または数時間後にログを公開したり、後から同じレコードを修正やアラートの更新の一環として更新する場合があります。取り込みはAPIの可視性や更新に従い、イベント時刻は元のアクティビティに紐づくことが多いです。
  2. ポーリングと遅延 — 収集はスケジュールで実行され、「現在」よりも意図的に遅延させているため、遅れて到着したデータも確実に取得できます。異なる遅延期間で複数の並列ストリームが一般的です。
  3. プラットフォームパイプライン — 転送、バッチ処理、インデックス作成により、データが検索可能になるまでに追加で数分かかる場合があります。

イベントの解釈方法🔗

イベント時刻と取り込み時刻のギャップが大きい場合の調査手順：

  1. どのMicrosoftインテグレーションがイベントを生成したかを特定します（Graphサインイン、リスク検知、Management API、Azure Activityなど）。その後、Microsoft Graph API、Office 365 Management Activity API、Azure Monitor REST API（ポーリング）、Azure ActivityおよびMicrosoft Graphアクティビティログ（非ポーリングインテグレーション）に関するインテグレーションテーブルを参照し、どのベンダーフィールドがイベント時刻にマッピングされ、どのフィールドが各収集サイクル（またはエクスポート頻度）を駆動しているかを確認します。
  2. オリジナルまたはベンダーのJSONがある場合、アクティビティや作成時刻とlastModified / lastUpdated / lastUpdate（APIによって名称が異なる）を比較します。
  3. 「更新時刻」が「アクティビティ時刻」よりも大幅に遅い場合、その行はサインインやアクティビティが最初に発生した時点ではなく、Microsoftがそのリビジョンを公開したタイミングで取り込まれた可能性が高いです。
  4. 両者が近いにもかかわらず取り込みがさらに遅い場合は、ポーリング間隔や遅延、Microsoftのスロットリング、下流の遅延（検索インデックス作成など）を考慮してください。

Microsoft Graph API🔗

収集はMicrosoft Graph APIへのスケジュールリクエストで行われます。各リクエストは、下記のAPI時刻フィールドを使用して、特定の時間範囲のレコードを取得します。コレクターは現在時刻よりも遅延を設け、各範囲の大きさを制限し、異なる遅延期間で並列ストリームを実行する場合があるため、遅れて到着した行も確実に取得されます。

インテグレーション、APIフィルターフィールド、イベント時刻のマッピング🔗

インテグレーション Graphリソース（list） API時刻フィールド（ポーリングを駆動） イベント時刻の主なソース
Microsoft Risk Detection; Microsoft Entra ID Protection (Identity XDR) — user risk detections .../identityProtection/riskDetections lastUpdatedDateTime activityDateTime
Microsoft Entra ID Protection — service principal risk detections .../identityProtection/servicePrincipalRiskDetections lastUpdatedDateTime activityDateTime
Microsoft Entra ID Protection — agent risk detections (beta) .../identityProtection/agentRiskDetections (beta) lastModifiedDateTime activityDateTime
Microsoft Graph — sign-ins .../auditLogs/signIns createdDateTime createdDateTime
Microsoft Graph — directory audits .../auditLogs/directoryAudits activityDateTime activityDateTime
Microsoft Graph Security — alerts (legacy) .../security/alerts lastModifiedDateTime eventDateTime、firstActivityDateTime、createdDateTime（フィールドが欠落している場合はこの順で使用）
Microsoft Graph Security — alerts v2 .../security/alerts_v2 lastUpdateDateTime eventDateTime、firstActivityDateTime、createdDateTime（フィールドが欠落している場合はこの順で使用）

注意

一部のリソースでは、API時刻フィールドが最終更新や修正のタイムスタンプである一方、XDRのイベント時刻はアクティビティやインシデントが開始した時刻（例：activityDateTime、eventDateTime、firstActivityDateTimeなど、APIによって異なる）から取得されます。リスク検知やGraph Securityアラート（レガシーおよびv2）、その他の可変オブジェクトは、Microsoftが修復やステータス変更、リフレッシュを適用した際に数時間後に変更されることがあります。その場合、更新フィールドが更新され、新たな取り込みが発生しますが、イベント時刻は元のアクティビティを反映し続けます。

代表的なポーリング間隔🔗

これらはMicrosoft Graph収集の代表的な値です。実際の間隔は環境によって異なり、可用性やレート制限の変化に応じて変更される場合があります。

レガシーと現在のGraph Audit（サインイン／ディレクトリアudit）

レガシーインテグレーションは、Secureworks管理の共有アプリケーションに対して同意を完了していたため、Microsoft Graphは多くのテナントに対して1つの共有クライアントとして認識し、より厳しいスロットリングが適用されていました。収集はストリーム数が少なく、ベースのポーリング間隔も現在のGraph Auditより長く設定されていました。現在のGraph Auditでは、各テナントが独自のアプリケーション登録を使用し、より頻繁に、より多くの並列遅延ストリームでポーリングが実行できます。

インテグレーション 代表的な間隔（分） 備考
Microsoft Graph — サインイン／ディレクトリアudit（レガシー共有アプリケーション） 10 各API（サインインとディレクトリアudit）ごとに2つのストリーム：1つは約10分の遅延、もう1つは約4時間（約250分）の長い遡り。新規セットアップではテナントアプリケーションGraph Auditに置き換えられています。
Microsoft Graph — サインイン／ディレクトリアaudit（テナントアプリケーション） 1 複数の遅延ストリーム（例：1、10、20、...50分）とオプションの開始オフセット。追加ストリームは10分間隔で長い遡り（数時間まで）をポーリングする場合があります。
Microsoft Graph — サインイン／ディレクトリアaudit（Identity XDR） 1 テナントアプリケーションGraph Auditと同様の複数遅延ストリームパターン。
Microsoft Risk Detection; Entra ID Protectionユーザーリスク検知 5 追加の遡り（例：4時間ストリーム）を含みます。
Microsoft Graph Security — アラート（レガシー）およびアラートv2 10 通常はほぼリアルタイムのストリームと長い遡りストリーム（例：遅延250分）の組み合わせ。
Microsoft Entra ID Protection — サービスプリンシパルおよびエージェントリスク検知 5 ユーザーリスクと同様のパターン。

Office 365 Management Activity API🔗

Office 365 Management Activity APIからの監査コンテンツは、XDRで検索や分析のために正規化されます。同じサブスクリプション、リスト、取得パターンが各オファリングで適用されますが、主に異なるのは商用クラウドと政府クラウドでMicrosoftが割り当てるアクティビティフィードホスト、およびテナントが現在の（顧客Entra IDアプリケーション＋証明書）オンボーディングか、古いレガシーフローを使用しているかです。

インテグレーションのセットアップ（権限、証明書、GCCと商用の違い）についてはOffice 365 Management APIを参照してください。

リスト、コンテンツURI、公開遅延🔗

Microsoftは収集を2段階のフローとして説明しています。

  1. Blobの検出 — コンテンツタイプ（例：Audit.AzureActiveDirectory）のサブスクリプションを開始した後、クライアントは利用可能なコンテンツをリスト（例：/subscriptions/content、オプションでstartTime / endTime指定）するか、新しいBlobが準備できたときにWebhookを受信します。各アイテムにはcontentUri、contentCreated（Microsoftがその集約を利用可能にした時刻）、関連メタデータが含まれます。
  2. イベントのダウンロード — クライアントは各contentUriにGETリクエストを発行し、そのBlob内のJSONアクションやイベントを取得します。

リストにBlobが現れることは、その集約がダウンロード可能になったことを意味しますが、Blob内の個々のイベントは実際のアクティビティ発生時刻よりも遅れる場合があり、Blobが現れる順序は実際のイベント発生順と一致するとは限りません。そのため、イベント時刻（通常は各レコードのCreationTime）が取り込み時刻よりもかなり早い場合があります。集約、リスト、取得、遅延に関するMicrosoftの説明は、下記追加リソースを参照してください。

インテグレーション、リストウィンドウ、イベント時刻のマッピング🔗

インテグレーション MicrosoftアクティビティフィードベースURL 各収集サイクルを駆動するもの イベント時刻の主なソース
Office 365 Management — 商用／エンタープライズMicrosoft 365 https://manage.office.com/api/v1.0/{tenant_id}/activity/feed/... コンテンツタイプごとにサブスクリプションを開始し、Blobが利用可能になった時刻（Microsoftのリストレスポンス内contentCreated）で/subscriptions/contentをリストし、各contentUriをGET。顧客登録のEntra IDアプリケーションと証明書を使用。 各監査レコードのCreationTime
Office 365 Management — GCC https://manage-gcc.office.com/api/v1.0/{tenant_id}/activity/feed/... 同じサブスクライブ→リスト→GET contentUriモデル。GCCエンドポイント（Microsoft 365 Government — GCC）。政府テナントの顧客アプリ＋証明書。 CreationTime
Office 365 Management — GCC High https://manage.office365.us/api/v1.0/{tenant_id}/activity/feed/... 同様のモデル。GCC HighエンドポイントおよびMicrosoftの主権ルール。顧客アプリ＋証明書。 CreationTime
Office 365 Management — レガシー https://manage.office.com/...（商用と同じAPI形状） 同じBlobセマンティクス。XDRの旧製品ラインで、現在の顧客Entra IDアプリ＋証明書フロー（商用／GCC向け）より前のもの。新規インテグレーションでは提供されていません。ポーリングは現行の顧客アプリ商用よりも控えめです。 CreationTime
Microsoft 365 Identity XDR — Office 365 Managementパス 顧客テナント用の商用スタイルホスト 同じManagement Activity APIと顧客テナント認証情報。Entraアプリ登録はXDRオンボーディングの一部として自動的にプロビジョニングされる場合があります。 CreationTime

代表的なポーリング間隔🔗

これらは代表的な値です。実際のタイミングは環境によって異なり、時間とともに変更される場合があります。

なぜこの表はMicrosoft Graphより具体的でないのか

Graphセクションでは、これらのインテグレーションに対応するストリーム構成と一致する分単位の間隔を記載しています。Office 365 Managementインテグレーションもプラットフォーム定義のポーリング間隔や遡りを使用しますが、このページではGraphほど正確な数値は記載していません。動作はスケジュールされたポーリングであり、各パスでBlobのリストをstartTime / endTimeで取得し、各contentUriをダウンロードします。そのため、ケイデンスはリストウィンドウの進行頻度を制御し、各イベントのCreationTimeには直接影響しません。

インテグレーション 代表的なケイデンス 備考
Office 365 Management — 商用、GCC、GCC High、Identity XDR（Managementパス） 頻繁なリストパス（多くは1分間隔程度） startTime / endTimeはBlobの可用性に適用され、各イベントのCreationTimeには適用されません。遡りで以前のウィンドウも再取得するため、遅れて公開されたBlobも確実に取得されます。Microsoftのスロットリングやテナント規模に合わせて調整されています。
Office 365 Management — レガシー 顧客アプリ商用よりも頻度が低い 旧コレクター構成およびオンボーディングモデル。新規テナントでは顧客Entraアプリインテグレーションに置き換えられています。

Azure Monitor REST API（ポーリング）🔗

ポーリングインテグレーションは、Azure MonitorのActivity Logs - List APIをリンクされた各サブスクリプションごとに呼び出します。各実行では、eventTimestampでフィルタリングした時間範囲のイベントをリクエストします（Microsoftは追加のフィルターパラメータを公開する場合があります）。コレクターは、Microsoftが後からActivity Log行を公開または修正する場合に備え、過去数時間などの以前のウィンドウも再クエリします。これはGraphやOffice 365 Managementで使用される遡りと同様です。

認証は委任された権限を使用し、設定されたユーザーの代理で動作します。詳細はMicrosoft Azure Activity Logを参照してください。

インテグレーション、APIフィルターフィールド、イベント時刻のマッピング🔗

インテグレーション API（list） 時刻フィールド（ポーリングを駆動） イベント時刻の主なソース
Azure Activity Log — Monitor REST（ポーリング） Activity Logs - List（.../providers/microsoft.insights/eventtypes/management/values） eventTimestamp（クエリウィンドウの境界） eventTimestamp、またはeventTimestampがない場合はtime

Microsoft Graphアクティビティログは通常、List APIパスではなく診断エクスポート（Event Hubや他のシンク）を通じて有効化されます。エクスポートストリームに存在する場合、イベント時刻は上記と同様にeventTimestamp / timeからマッピングされます。

代表的なポーリング間隔🔗

これらはREST Activity Logインテグレーションの代表的な値です。実際のタイミングは環境によって異なります。

インテグレーション 代表的な間隔（分） 備考
Azure Activity Log — Monitor REST（ポーリング） 5 複数の並列ストリームがあり、それぞれ5分間隔で異なる遅延（例：5、10、15、20、25、30、60、90、120、240分）でeventTimestampをクエリします。各ストリームの最大遡りは、遅れて公開または修正された行も確実に取得できるように設定されています（Microsoftのレート制限の範囲内）。

Azure ActivityおよびMicrosoft Graphアクティビティログ（非ポーリングインテグレーション）🔗

XDRは、Azure Activity（サブスクリプションレベルのAzureコントロールプレーン監査）およびMicrosoft Graphアクティビティ（テナントのGraph APIリクエスト監査）を診断エクスポート（Event Hubs、ストレージ、その他）経由で取り込むことができます。このセクションではこのパスについて説明します。Azure Activity LogはRESTポーリングでも収集できます。そのタイミングやAPIフィールドについてはAzure Monitor REST API（ポーリング）を参照してください。エクスポートとポーリングのセットアップはMicrosoft Azure Activity Logで説明しています。

診断エクスポート（Event Hubs、ストレージなど）🔗

Azure Monitorの診断設定で、選択したカテゴリをEvent Hub、ストレージアカウント、その他のサポートされるシンクに送信します。XDRはこれらのストリームやファイルを取り込みます。弊社側で固定のポーリング間隔はなく、ケイデンスやバッチ処理はAzureおよびお客様の診断設定に従います。

イベント時刻は、ペイロード内のeventTimestampやtimeなどのベンダーフィールドから取得されます（カテゴリやフォーマットによって名称が異なります）。Microsoft Graphアクティビティログレコードも、Monitor経由でエクスポートされた場合は同様のパターン（トップレベルのtimeや関連プロパティ）を使用します。

収集後のプラットフォーム遅延🔗

APIがデータを返した後：

  • コンポーネント間のハンドオフは通常1分未満ですが、負荷が高い場合はそれ以上かかることもあります。
  • バッチ書き込みやインデックス作成により、イベントが検索可能になるまでに数十分かかる場合があります。検知機は検索が利用可能になる前に実行されることもあります。

これらの影響により、ポーリングが正常でも取り込み時刻とベンダータイムスタンプの差が広がる場合があります。

コンテンツの完全性🔗

クエリパラメータはデータ取得のみに使用され、ベンダーJSONを書き換えることはありません。生データ（例：original_data）は保持されます。ベンダーJSONが不正（構造や構文が無効）または不十分（調査に必要なフィールドや値が欠落しているなど）な場合は、XDRではなくMicrosoftにお問い合わせください。

追加リソース🔗

Office 365 Management Activity API（Blob、リスト、取得、遅延）

その他