監査ログ - Browserflow

監査ログページ（/audit）は、組織内で行われたすべての機密性の高い変更を、追記専用かつ新しい順で記録します。記録される内容には、APIキーの発行や取り消し、オートメーションの公開、シークレットの登録、スケジュールの作成や削除、メンバーやロールの変更が含まれます。

このページはオーナー専用です。オーナーではないメンバーにはナビゲーション上で非表示になり、基盤となるAPIもサーバー側で同じ制限を適用します。非オーナーのセッションには、単にリンクが隠されるだけでなく 403 が返されます。

ページに表示される内容

各行は1つの監査エントリで、5つの列があります。

列	説明
日時	イベントが発生した時刻を、ロケールに左右されない絶対時刻として表示します。
実行者	操作を実行したユーザーです。
操作	イベント名を示すバッジです。たとえば、キー発行、オートメーション公開、シークレット登録、スケジュール作成/削除、メンバー追加/ロール変更/メンバー削除が表示されます。破壊的な操作（`.revoked`、`.removed`、`.deleted`）は赤で表示され、`automation.published` と `key.issued` はアクセントカラーで表示されます。
対象	操作が適用されたオブジェクトです。
詳細	イベントのメタデータをコンパクトな `key=value` 形式で要約します。

シークレットの値が監査ログのメタデータに書き込まれることはありません。記録されるのは、シークレットが登録されたという事実と、その対象だけです。ページ上にも「シークレットの値はここには表示されません」と繰り返し表示されます。

監査イベントがまだない場合、ページには空のテーブルではなく空状態のメッセージが表示されます。

ページを開いている間、監査ログ一覧は15秒ごとにポーリングします。そのため、新しいイベント（チームメイトによるキーのローテーション、スケジュールの削除など）は手動でリロードしなくても表示されます。

アクセス制御は、独立した2つの層で適用されます。

クライアント側: ページは現在のセッションのロールを確認し、サインイン中のユーザーがオーナーでない場合は「監査ログを表示できるのは組織オーナーのみです」というメッセージを、テーブルなしで表示します。これにより、非オーナーに対しては監査ログのクエリ自体も実行されません。
サーバー側: GET /api/audit には有効なセッションと owner ロールが必要です。オーナーのセッションを持たないリクエストは、ストアが照会される前に拒否されます。このエンドポイントは結果をロールでフィルタするだけではなく、非オーナーからのリクエストを 403 で明示的に拒否します。

どちらの層も同じロールチェックに基づいているため、非オーナーがURLを知っていたとしても、ログを表示できるルートやAPI呼び出しはありません。

APIはカーソルベースでページネーションされ、各リクエストで組織の監査履歴全体を読み込むのではなく、1ページに必要な分だけログを読み取ります（next_cursor が存在するかどうかを判定するために1行だけ多く取得します）。ログは追記専用で、無期限に増え続ける可能性があります。

キーの発行と取り消しは、ここに表示されるイベントの一部です。

Buildからオートメーションを公開すると、automation.published エントリが生成されます。