Audit Log
コンプライアンスとデバッグのために、コンテンツとメディアの変更 (作成/更新/削除) を追跡します。
プラグイン
Audit Log
コンプライアンスとデバッグのために、コンテンツとメディアの変更 (作成/更新/削除) を追跡します。
監査ログが存在するのは、真剣な編集チームが、誰が、いつ、どのような状況で何を変更したかを把握する必要があるためです。特に、複数の人がコンテンツに触れたり、コンプライアンスで追跡可能性が求められたりした場合はそうです。実装は packages/plugins/audit-log にあります。
インストール
- EmDash 管理プラグイン リストから監査ログを有効にするか、開発中にソースから監査ログを統合します。
- ログをバックアップするストレージが保持ポリシーを満たしていることを確認します (データベース テーブル、ワーカー KV、またはリリースでプラグインが使用するもの - README を確認してください)。
- 監査ビューへの 読み取り アクセスを、必要なロールにのみ付与します。書き込みパスはシステム制御のままにする必要があります。
構成
一般的なオプションには次のものがあります。
- 記録するイベント — 作成、更新、削除、公開、および場合によってはログインまたはプラグインのアクション。
- 保存期間 — エントリがオンラインに保持される期間と、コールド ストレージにアーカイブされる期間。
- PII 編集 - ユーザー識別子が完全な電子メール、内部 ID、またはハッシュ値であるかどうか。
例 (概念): 規制対象のマーケティング チームは、監査エントリを 24 か月間保持し、毎月 SIEM にエクスポートし、アプリ内監査 UI を管理者とコンプライアンス担当者のみに制限する場合があります。
使用シナリオ
- マルチエディターのワークフロー — 「これを誰が発行したか?」を解決します。チャットログの代わりに証拠を使って争う。
- インシデント対応 — 不適切なロールアウトまたは誤った編集を変更ウィンドウまで追跡します。
- 顧客監査 — より広範なセキュリティ ストーリーと組み合わせて、SOC 2 スタイルのアンケートの内容変更の制御を実証します。
運用上のヒント
- 監査人から要求される前に、復元パスとエクスポート パスをテストします。
- 機密コンテンツの種類に関するリアルタイムのアラートが必要な場合は、Webhook Notifier と調整します。
- 監査エントリ自体が不変かどうかを文書化します。そうでない場合は、その表面が改ざんされないように保護してください。