Cloudflare Audit Logs はアカウントベースです。ユーザー起点の操作は、Cloudflare API とダッシュボードの両方で自動記録されます。システム起点のログも取得され、設定更新、バックグラウンド処理、内部ポリシーの適用など、Cloudflare システムが自動で行った操作を反映します。
ユーザー起点の操作が追加の自動動作を起動すると、対応するシステム起点ログが生成されます。場合によっては、ユーザー起点ログに、何が変更されたかの追加コンテキストを与えるエンリッチメントが含まれ、操作の完全なライフサイクルをより深く可視化できます。
操作が発生すると、Cloudflare の監査ログパイプラインを通じてストリーミングされ、保存されます。すべての製品にわたるアクティビティを一貫して可視化できます。
ユーザー起点の操作が自動記録されるしくみの詳細は、Cloudflare Blog ↗ を参照してください。
Audit Logs(version 2)は、Cloudflare 製品全体の操作を追跡・記録するための、統一され標準化されたシステムです。Cloudflare 環境内のユーザー起点およびシステム起点のアクティビティへの包括的な洞察を提供し、透明性と説明責任を高めます。
- 標準化されたログ: 監査ログはすべての Cloudflare サービスで一貫した形式で自動生成され、均一性を確保し、不整合をなくします。
- 拡大した製品カバレッジ: Audit Logs は Cloudflare 製品の約 95% をカバーし、
/accounts、/zones、/user、/membershipsAPI などの主要エンドポイントからの操作を取得します。 - 細かい絞り込み: 均一な形式のログにより、操作、アクター、メソッド、リソースで精密に絞り込め、調査を効率化できます。
- 強化されたコンテキストと透明性: 各ログエントリには、使われた認証方法、操作が行われたインターフェイス(API またはダッシュボード)、追跡性を高める Cloudflare Ray ID へのマッピングなどの詳細なコンテキストが含まれます。
- 包括的なアクティビティ取得: Audit Logs は、対応するすべての製品で create、update、delete 操作を記録します。機微な読み取り操作向けの選択的な
GETリクエストのログは、今後のリリースで予定しています。
-
監査ログは削除前に 18 か月保持されます。追加のセットアップは不要です。
-
Audit Logs v2 UI では、パフォーマンス上の理由でクエリは直近 90 日に制限されます。18 か月分のデータ全体にアクセスするには、API または Logpush を使います。
-
Enterprise のお客様は Logpush を使い、18 か月を超えて監査ログを保存できます。
Audit Logs v2 は Customer Metadata Boundary(CMB) に対応しています。アカウントレベルの CMB 設定は Audit Logs v2 に自動適用されます。たとえば eu を選ぶと、Audit Logs v2 は EU のメタデータ境界を使います。Audit Logs を別に設定する必要はありません。
Cloudflare ダッシュボードまたは /accounts/{account_id}/logs/control/cmb/config API で CMB を設定するには、Customer Metadata Boundary を始める を参照してください。CMB は Data Localization Suite の一部です。アカウントで CMB が有効でない場合は、アカウントチームに連絡してください。
監査ログは、Cloudflare ダッシュボード、API、または Logpush で取得できます。
監査ログは Cloudflare API 経由で利用できます。監査ログを取得するには、次のエンドポイントを使います。
https://api.cloudflare.com/client/v4/accounts/{account_id}/logs/audit次は、一定期間の監査ログを取得するリクエスト例と、対応する応答です。URL 内の例の値を実際の値に置き換えます。
account_id: Cloudflare アカウント識別子です。since(必須): 監査ログ取得の開始日です。yyyy-mm-dd(UTC として解釈)または RFC3339 タイムスタンプ(yyyy-mm-ddTHH:MM:SSZ)を受け付けます。before(必須): 監査ログ取得の終了日です。形式はsinceと同じです。
GET https://api.cloudflare.com/client/v4/accounts/1234567890abcdef/logs/audit?since=2025-03-01T00:00:00Z&before=2025-03-26T23:59:59Z{
"result": [
{
"action": "zone.settings.change",
"actor": {
"email": "[email protected]",
"id": "0987654321abcdef"
},
"ip": "192.0.2.1",
"method": "PUT",
"interface": "dashboard",
"resources": [
{
"resource_id": "zone123",
"resource_type": "zone"
}
],
"timestamp": "2025-03-15T14:25:37Z"
}
// Additional log entries
],
"success": true,
"errors": [],
"messages": []
}詳細は API ドキュメント ↗ を参照してください。
Cloudflare ダッシュボードで監査ログにアクセスするには、Manage Account > Audit Logs を開きます。
Audit logs を開く ↗アカウントレベルの Audit Logs v2 ダッシュボードには、選択した期間の分析が含まれます。Actions over time チャートは成功した操作と失敗した操作を分けます。サマリーカードは Total actions、Unique actors、Products impacted、Failure rate を示します。
サマリーカードを選択すると、詳細を確認できます。
- Total actions: 操作タイプと認証方法
- Unique actors: 操作数が最も多いアクター
- Products impacted: 操作数が最も多い製品
- Failure rate: 失敗した操作とその HTTP ステータスコード
詳細パネルから Filter または Exclude を選択し、分析と監査ログ表をその値に絞り込みます。分析、表、フィルター、期間は同期されたままです。
Logpush ジョブを作成するには:
-
Cloudflare ダッシュボードで Logpush ページを開きます。
Logpush を開く ↗ -
Create a Logpush job を選択します。
-
Select a destination で任意の送信先を選び、送信先の詳細を追加します。
-
データセットのセクションで Audit Logs v2 データセット を選択します。Audit Logs v2 はアカウントベースのデータセットです。
-
Logpush ジョブの設定が終わったら、Submit を選択します。
Resource History は、Audit Logs で取得したすべての設定変更について、何が変わったかを示します。任意の監査ログエントリについて、同じリソースへの以前の変更の一連を確認し、変更内容の並べて比較する diff を表示できます。
Resource History は Cloudflare ダッシュボードと Audit Logs API で利用できます。すでに持っている監査ログエントリを使います。追加の設定、バックエンドでの再取得、監査ログの生成方法の変更はありません。
任意の監査ログエントリについて、Resource History は同じリソースの他のすべての監査ログエントリを時系列で取得します。その履歴から以前のエントリを選び、2 つのあいだでどのフィールドが変わったかを正確に確認できます。
- Manage Account > Audit Logs を開きます。
- 任意の監査ログエントリを開きます。
- History タブを選択し、そのエントリが示すリソースの完全な履歴を確認します。
- 履歴ビューで以前のエントリを選択し、それと現在のエントリのあいだで変わったフィールドの並べて比較する diff を確認します。
Resource History が基盤リソースを識別できない場合(一部のシステム起点イベントなど)、ダッシュボードは、そのエントリでは変更履歴が利用できないことを示す空の状態を表示します。
History エンドポイントを使い、任意の監査ログエントリの変更履歴を取得できます。ソース監査ログエントリの id を渡すと、エンドポイントはそのエントリから識別フィルターを導き、指定した日付ウィンドウ内の一致する監査ログエントリを返します。
アカウントスコープの監査ログでは次を使います。
GET https://api.cloudflare.com/client/v4/accounts/{account_id}/logs/audit/{id}/history組織スコープの監査ログでは次を使います。
GET https://api.cloudflare.com/client/v4/organizations/{organization_id}/logs/audit/{id}/history{id} パスパラメーターは、リソース履歴を取得したいソース監査ログエントリの id です。
エンドポイントには 3 つのクエリパラメーターが必要です。
action_time(必須): ソース監査ログエントリの操作時刻の RFC3339 タイムスタンプです。{id}で識別される監査ログのaction.time値を指定します。ソースエントリの検索ウィンドウを狭めます。since(必須): 返される結果をこの日より新しいエントリに制限します。日付文字列(2024-10-30、UTC として解釈)または RFC3339 タイムスタンプを受け付けます。before(必須): 返される結果をこの日より古いエントリに制限します。形式はsinceと同じです。
省略可能なクエリパラメーター:
direction:desc(デフォルト)またはasc。limit: ページあたり返すエントリ数です。デフォルトは100です。cursor: 前回の応答のresult_info.cursorからのページネーションカーソルです。
Required API token permissions
At least one of the following token permissions is required:Account Settings WriteAccount Settings Read
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/logs/audit/$ID/history" \
--request GET \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"result 内の各エントリは、Audit Logs の list エンドポイントが返すエントリと同じ形です。結果は result_info の cursor 値でページネーションされます。
result_info.history_status フィールドは、履歴の構築に使ったリソース識別の品質を示します。
exact: ソースエントリにリソース URI が含まれていたため、履歴は正確なリソース一致から構築されました。approximate: ソースエントリにリソース URI が含まれていなかったため、履歴は近似一致(同じ製品とタイプの他のリソース)から構築されました。ダッシュボードはこの状態を警告バナーで示します。unavailable: ソースエントリにリソースを識別するのに十分な情報がありませんでした。resultは空です。一部のシステム起点イベントで起こることがあります。
Resource History は、Audit Logs v2 が現在保持している監査ログエントリを反映します(保持期間 を参照)。保持ウィンドウより古いエントリは返りません。Resource History はクエリ時の機能であり、audit_logs_v2 Logpush データセットの追加フィールドとしては公開されません。
Cloudflare の監査ログは、操作の発生源と、それが起きたコンテキストを取得することで、環境全体のアクティビティを詳しく見られます。これらのログは、誰が操作を開始したか(ユーザーまたはシステム)と、アクティビティが特定のアカウント内で起きたか、同じユーザープロフィール下の複数アカウントにまたがったかで分類されます。この構造により、柔軟な絞り込み、調査、コンプライアンス監視が可能です。
監査ログはユーザーまたはシステムが開始できます。関与するアクターの種類を理解すると、操作の発生源と意図の特定に役立ちます。
ダッシュボードと API を含む Cloudflare インターフェイス経由でユーザーが開始した操作を追跡します。これらのログは、誰または何が操作を実行したかを取得します。いつ発生し、どのリソースが影響を受けたかも記録します。ユーザー起点の操作には 4 つのアクタータイプがあります。
actor_type="user": 個人ユーザーが操作を実行しました。actor_type="cloudflare_admin": Cloudflare が操作を実行しました。actor_type="account": アカウント API トークンを使って操作を実行しました。詳細は Account API tokens のドキュメントを参照してください。actor_type="delegated_service": ユーザーの代わりに Cloudflare サービスが操作を実行しました。ログは開始したユーザーを識別しません。
ユーザーの直接入力なしに、Cloudflare システムが自動で行った変更を記録します。これらのログは、内部プロセス、自動化タスク、セキュリティイベントを可視化します。一部のエントリには追跡性のための関連ユーザーコンテキスト(actor_type="system")が含まれることがあります。
単一の Cloudflare アカウントにスコープされたイベントを含みます。これらのログは account ID で絞り込め、そのアカウント内の操作だけを反映します。resource_scope フィールドでイベントをさらに絞り込むこともできます。このフィールドは、リソースがユーザー、アカウント、またはゾーンに関連するかを指定します(resource_scope ="user"、resource_scope ="accounts"、または resource_scope ="zones")。
複数アカウントにわたる、ユーザーのログイン(メール)に関連する操作を反映します。これらのログはアカウント横断の追跡を可能にし、user ID または email で絞り込めます。アクティビティ時点でユーザーがアクセスできた任意のアカウントで表示できます。User Profile Activity Logs は resource_scope ="user" で絞り込めます。
GET /memberships エンドポイントはアカウント横断アクセスに対応しています。メンバーシップを照会するには、パラメーター resource_scope=memberships を使います。
特定の Cloudflare Organizations にスコープされたイベントを含みます。これらのログは、組織レベルの API 経由で Org Admins が実行したユーザー起点の操作を取得します。
Organization の監査ログは、API または Cloudflare ダッシュボードのいずれかで取得できます。
Audit Logs v2 API 経由で取得します。
GET https://api.cloudflare.com/client/v4/organizations/{organization_id}/logs/auditCloudflare ダッシュボードで組織の監査ログにアクセスするには、Organizations > (組織を選択) > Manage Organization > Audit Logs を開きます。
アカウントレベルの監査ログを表示していて、そのアカウントが Organization Super Administrator である組織に属している場合は、View Organization Audit Logs ボタンで親組織の監査ログへ移動できます。
次の例を使い、Cloudflare アカウントの監査ログ一覧を取得します。
Required API token permissions
At least one of the following token permissions is required:Account Settings WriteAccount Settings Read
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/logs/audit" \
--request GET \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"{
"errors": [
{
"message": "message"
}
],
"result": [
{
"account": {
"id": "4bb334f7c94c4a29a045f03944f072e5",
"name": "Example Account"
},
"action": {
"description": "Add Member",
"result": "success",
"time": "2024-04-26T17:31:07Z",
"type": "create"
},
"actor": {
"id": "f6b5de0326bb5182b8a4840ee01ec774",
"context": "dash",
"email": "[email protected]",
"ip_address": "198.41.129.166",
"token_id": "token_id",
"token_name": "token_name",
"type": "user"
},
"raw": {
"cf_ray_id": "8e9b1c60ef9e1c9a",
"method": "POST",
"status_code": 200,
"uri": "/accounts/4bb334f7c94c4a29a045f03944f072e5/members",
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Safari/605.1.15"
},
"resource": {
"id": "id",
"product": "members",
"request": {},
"response": {},
"scope": {},
"type": "type"
},
"zone": {
"id": "id",
"name": "example.com"
}
}
],
"result_info": {
"count": "1",
"cursor": "ASqdKd7dKgxh-aZ8bm0mZos1BtW4BdEqifCzNkEeGRzi_5SN_-362Y8sF-C1TRn60_6rd3z2dIajf9EAPyQ_NmIeAMkacmaJPXipqvP7PLU4t72wyqBeJfjmjdE="
},
"success": true
}アクターは、誰または何が操作を実行したかを表します。その識別属性はアクタータイプによって異なります。これらの属性には、ユーザー ID、メールアドレス、IP アドレスが含まれます。アクタータイプには user、account、cloudflare_admin、delegated_service、system があります。アクターには、操作の開始に使ったコンテキストも含まれます。
api: API 経由で操作を実行しました。具体的な資格情報タイプは記録されませんでした。api_key: Cloudflare Global API Key で操作を認証しました。api_token: API トークンで操作を認証しました。dash: Cloudflare ダッシュボード経由で操作を実行しました。oauth: OAuth トークンで操作を認証しました。origin_ca_key: Origin CA キーで操作を認証しました。
action フィールドは、イベントの性質と成功したかを取得します。高レベルのタイプ(たとえば create、update、delete)、具体的な説明(SSO_LOGIN など)、操作が発生したタイムスタンプ、結果(success または failure)を含みます。
view 操作は GET リクエストに対応します。スキーマでは定義されていますが、現在 Audit Logs では取得されていません。機微な読み取り操作向けの選択的な GET ログは、今後のリリースで予定しています。
このフィールドは、操作が実行された Cloudflare アカウントを指します。一意のアカウント ID と、アクティビティを顧客環境に関連付けるための人が読めるアカウント名を含みます。
リソースは、操作の影響を受けたオブジェクトを識別します。リソースタイプ、一意のリソース ID、スコープ(user、account、または zone)、省略可で変更に関連する製品を含みます。
これはログレコード自体の一意の識別子です。重複排除、相関、調査中の特定操作の参照に使えます。