Audit Trail (監査証跡)

Audit Trail とは、Datadog の中で誰がいつ何を操作したかを記録し、検索できるようにする機能のこと。監視対象で起きた出来事を扱うイベントとは別で、モニターの削除やダッシュボードの変更、ログインといった Datadog 自体への操作が対象になる。

概要

Audit Trail は、組織の中で誰が Datadog をどう使っているかを、管理者やセキュリティ担当が確かめるための操作記録です。個々のユーザーは自分の操作の流れを見られます。記録は API へのリクエストを写した「リクエストイベント」と、モニターやダッシュボードの変更のような「製品固有イベント」の 2 種類で、Log Explorer と同じ操作感で絞り込みと集計ができます。気にする場面は、消えたモニターを誰が消したかを特定する変更管理、ロール変更やログインを追う権限整理、そして監査対応で証跡の提出を求められたときです。有効化は組織設定から行い、保持期間は既定で 90 日です。

監視対象の出来事ではなく、Datadog を操作した記録

Audit Trail は、組織の中で誰が Datadog をどのような文脈で使っているかを、管理者やセキュリティチームが確認できる機能です。個人としては、自分自身の操作の流れを見ることもできます (2026 年 9 月時点・出典: Datadog Audit Trail)。ここで混同しやすいのがイベントです。イベントはデプロイやモニターの状態変化のように、監視対象の側で起きた出来事を記録します。Audit Trail が記録するのはその手前、つまり利用者や API が Datadog 自体に対して行った操作です。モニターが「発報した」はイベントで、モニターを「誰かが消した」は Audit Trail の領分だと分けて考えると迷いません。

記録される 2 種類のイベント

記録は 2 種類に分かれます。1 つはリクエストイベントで、Datadog の API に対するすべてのリクエストを利用者の記録として写したものです。もう 1 つは製品固有イベントで、公式ドキュメントは例として、インデックスの保持期間を誰が変えたか、パイプラインやプロセッサーを誰がいつ変えたか、除外フィルターを誰が変えたかを挙げています (2026 年 9 月時点)。いずれも、請求額の変化や、壊れたダッシュボードやモニターの原因を追う場面として書かれています。セキュリティの観点では、重要なダッシュボードやモニターの更新と削除、ログイン、アカウントやロールの変更の証跡を残す用途が挙がります。記録は Cloud SIEM で分析し、脅威検知のシグナルにすることもできます。

誰がモニターを消したかを突き止める手順

公式ドキュメントによれば、Audit Trail の画面は Log Explorer のログと同じ機能を持ちます。絞り込みに使えるのは、Dashboards や Monitors、Authentication といったイベント名と、操作した人や API キー ID、メールアドレスなどの認証属性です。Status や HTTP メソッドなどのファセットも使えます (2026 年 9 月時点)。

  • イベント名を Monitors、メソッドを DELETE に絞る
  • 該当イベントの属性タブで usr.email や client.ip を確かめる
  • Inspect Changes タブで変更前後の設定の差分を JSON で見る
  • 同じ条件を Audit Trail モニターにして、次回は通知で受け取る
消えたモニターの操作者を追う流れ (出典: Datadog 公式ドキュメント Datadog Audit Trail の記述を基に整理)

差分の表示はダッシュボード、Notebook、モニターの設定変更で使えます。調査した結果は最大 10 万件まで CSV に書き出せるので、監査で提出を求められたときにそのまま渡せます。

保持は既定 90 日 - 有効化と権限の前提

有効化の入口は組織設定の Compliance にある Audit Trail Settings です。この操作ができるのは Audit Trail Write 権限を持つユーザーで、記録を見るには Audit Trail Read 権限が要ります。有効化すると監査イベントの保持期間は既定で 90 日になり、3、7、15、30、90 日から選べます。無効化すると既定の 7 日に戻ります (2026 年 9 月時点)。任意でアーカイブも設定でき、Amazon S3、Google Cloud Storage、Azure Storage へ 15 分ごとにイベントが書き出されるため、SIEM 側から読み取る構成が組めます。誰が Audit Trail を有効にしたかは、「A user enabled Datadog Audit Trail」という記録がイベントとして残るので、Events Explorer から確認できます。

API キーの使われ方も見える

ログ管理を使っている組織なら、取り込まれたログに datadog.api_key_uuid というタグが付き、どの API キーで収集されたかが分かります。公式ドキュメントはこれを、組織内で API キーがどう使われているかの把握と、ローテーションや管理に役立てるものと位置づけています (2026 年 9 月時点)。アプリケーションキーの一覧にある Last used の表示も、Audit Trail が有効で Audit Trail Read 権限があるときだけ出ます (出典: API and Application Keys)。鍵の棚卸しをするなら、Audit Trail を先に有効にしておく方が材料が揃います。タグとして付くので、ログ側の集計にもそのまま使えます。

変更管理と権限整理で効く場面

Audit Trail が無いときに困るのは、設定が変わった事実には気づけても、誰がいつ変えたかを辿る手段が無いことです。あると、モニターやダッシュボードの変更を本人に確認でき、意図しない変更なら差分を見て元に戻せます。ダッシュボードが削除されたら発報する、特定のユーザーがログインしたら知らせる、といったモニターも公式ドキュメントが例に挙げています。組み込みのダッシュボードにはインデックス保持期間の変更やパイプラインの変更などが並び、複製して自分の観点に直せます。権限を細かく分ける作業に取りかかる前に、まず記録を残す側を整えるのが順番です。

共有する