運用

監査ログ

デプロイメント上のすべての変更、サインイン、発行されたイベントを記録する、改ざんできない監査証跡と診断ログを読みます。

対応エディション

監査ログは、デプロイメントで何が起きたかの改ざんできない記録です。誰が、何を、いつ、どこから変更したかを示します。このページは、Setup → Diagnostics の下にある診断サーフェスの詳細なリファレンスです。ログ、メトリクス、リクエストの識別についてのオペレーター向けの概要は、オブザーバビリティを参照してください。

これらのサーフェスには manage_platform_settings 権限が必要です。

次のことを証明または調査する必要があるときに、監査ログを使います。

  • 権限に関わる変更
  • 設定と構成の変更
  • ユーザーとセッションのアクティビティ
  • 連携と自動化のアクティビティ
  • 拒否されたアクセスの分析

監査ログ

Setup → Diagnostics → Audit Logs(sys_audit_log)にあります。このオブジェクトは読み取り専用で改ざんできません。プラットフォームのイベントを追記専用で記録した証跡です。行の絞り込み、グループ化、確認はできますが、Setup から行を編集・削除することはできません。

各閲覧者に提供されるもの

すべての行は保存されたままですが、ObjectStack 17.6 以降、あるレコードに関する行は、閲覧者がそのレコード自体を読める場合にだけ提供されます。レコードを開けるかどうかを決めるのと同じ、オブジェクト権限、共有、行レベルセキュリティです。これにより次のものが除外されます。

  • すべての delete の行と、その後削除されたレコードに関するその他すべての行
  • サインアウトの行と、その後セッションが削除されたサインインの行
  • 閲覧者が開けないレコードに関する行

どのレコードにも関係しない行(構成の変更、ユーザーインポートの実行、セッションを持たない認証イベント)は、従来どおり台帳自体の付与のもとで提供されます。

view_all_audit_log 機能はこの絞り込みを解除します(ObjectStack 17.7)。その保持者には、削除とサインアウトの証跡、そして開けないレコードに関する行が提供されます。プラットフォーム管理者はデフォルトでこれを保持していますが、組織の管理者は保持していないため、証跡全体を読む必要があるその他の人には明示的に付与してください。

フィールドレベルのセキュリティは、すべての行の中で引き続き適用されます。old_value と new_value は、マスクなしでそのフィールドを読める閲覧者にだけそのフィールドを提供します。また、フィルターが等価条件で 1 つのオブジェクトを指定し(object_name)、かつそのオブジェクトのすべてのフィールドを読める場合を除き、これらでの絞り込み、並べ替え、グループ化は拒否されます(403)。

プリセットビュー

一覧は、アクションのカテゴリで絞り込むタブとともに開きます。どのタブにも上記のルールが適用されます。

ビュー表示内容
Recentすべてのイベント、新しい順
Writes作成 / 更新 / 削除のアクション。delete の行は view_all_audit_log がある場合のみ
Authサインインとサインアウトのイベント。サインアウトと、その後セッションが削除されたサインインは view_all_audit_log がある場合のみ
Config設定と構成の変更

列とフィールド

デフォルトの列は Timestamp、Action(create / update / … を示す色付きのピル)、Object、Record ID、Actor です。フッターにはレコードの総数が表示されます(例:36 records)。

各行は完全なフィールドのセットを持ちます。

フィールド意味
created_atイベントが記録された日時
action操作(create、update、delete、auth など)
user_id実行した User へのルックアップ
actor実行者の識別情報(テキスト)
object_nameイベントが影響したオブジェクト(例:sys_user)
record_id影響を受けたレコード
old_value変更前の値(テキストエリア)
new_value変更後の値(テキストエリア)
ip_addressリクエストの送信元 IP
user_agentクライアントのユーザーエージェント
tenant_id所有するテナント
metadata追加の構造化されたコンテキスト

Config ビューは、「誰がこの設定を変更したか」に答える最も速い方法です。行を読み始める前に、証跡を構成のアクションに絞り込みます。

変更を読む

書き込みアクションで重要な詳細は、変更前と変更後です。行の ⋮ メニューを開いて old_value と new_value を展開すると、そのレコードで何が変わったかが表示されます。読めるフィールドはすべて完全に表示され、それ以外は何も表示されません。Object と Record ID の列は何が影響を受けたかを、old_value/new_value はどのようにを、actor、ip_address、user_agent は誰が、どこからを示します。

規制のある環境では、ストレージの層でも改ざん不可能性を担保してください。データベースでテーブルを追記専用にし、保持ポリシーを定めます。

通知イベント

Setup → Diagnostics → Notification Events(sys_notification)にあります。これは通知システムの受信ログであり、emit() ごとに 1 行が、配信の判断より前に書き込まれます。通知が受信トレイに届いた理由、届かなかった理由の診断に使います。その後のルーティングと具体化については、通知に記載されています。

プリセットビューは Recent と By Topic です。デフォルトの列は Topic(例:project.digest)、Severity(info/warn/… を示すピル)、Actor、Source Object、Created At です。

フィールド意味
topic発行されたトピック
payloadイベントのペイロード(JSON)
severity重大度
dedup_key重複した発行をまとめるためのキー
source_objectイベントを発生させたオブジェクト
source_idイベントを発生させたレコード
actor_id発行をトリガーしたプリンシパル
created_atイベントが取り込まれた日時

dedup_key は重複した発行をまとめ、payload はテンプレートの描画元となる生のイベントコンテキストを保持します。このログはルーティングの上流にあるため、ここに行があるのに対応する受信トレイのメッセージがない場合、通常は対象者がそのユーザーに解決されなかったか、ユーザーの設定がそのチャネルでそのトピックをミュートしています。ユーザーからアラートが届かないと報告があったときは、通知を確認してください。

下流では、各イベントはユーザーごとの受信トレイのメッセージ(sys_inbox_message)に具体化されます。受信者側の表示については通知にあります。

セッション

Setup → Diagnostics → Sessions にあります。Sessions には有効なサインインセッションと最近のサインインセッションが一覧表示されるため、ユーザーのアクティビティを調査したり、アクセスを取り消したりできます。サインインのインシデントを確認するときは、Auth 監査ビューと組み合わせて使います。

次に進む

タスクページ
ログ、メトリクス、リクエストの識別についてのオペレーター向けの概要オブザーバビリティ
通知のルーティングと描画の仕組みを理解する通知
本番稼働の前にデプロイメントを堅牢化する本番環境への準備
運用の概要に戻る運用