操作の記録と異常の検知/ Audit Logs & Alerting

2 本用意しました。1 本目は Box のメンバーが自分たちの操作履歴を辿るところ、2 本目はシステム管理者がアラートに気づいて手を打つところです。この先の各章は、ここで起きていることを分解してご説明します。

この仕組みを構成する稼働リソース（サービス・バッチ・テーブル・バケット）と、その間を流れるものを一枚にまとめました。①記録の蓄積 → ②3 つの読み口 → ③長期保管、そして独立した ④異常の検知と運用、の 4 区画で読めます。②の 3 本はどれも同じ 1 本の記録を読んでいて、書き込み経路は 1 つしかありません。各要素の詳しい役割は、この先の各章で扱います。

何を解決したか

取引先とのやり取りをメールと紙から Web に移すと、それまで受信箱と稟議書に散っていた「誰がいつ何をしたか」が、原理的には 1 か所に集められるようになります。ただし集める仕組みを作らなければ集まりません。松葉では、ファイルのアップロード・差し替え・削除・復元、フォルダの操作、メンバーの追加とロール変更、共有リンクとファイルリクエストの発行と無効化、コメント、Box の設定変更、そしてダウンロードとプレビューまで、163 種類の操作を発生した時点で記録しています。

もう 1 つの問題は、システム側の異常が誰にも届かないことでした。サーバが落ちればクラウドの監視が拾いますが、実際に困るのは「サーバは動いているのに通知メールだけ出ていない」「日次の同期が 2 日続けて失敗している」「ウイルス検査が詰まっている」といった状態です。これらはアプリの中の数字を見なければ判定できません。松葉では、アプリ自身が 29 種類の事象を判定し、1 つの運用画面に集約しています。

1 本の記録を 3 つの読み口で出す

記録を保存するテーブルは 1 本だけです。表示用に別のテーブルを設けると、同じ出来事を 2 か所へ書くことになり、片方だけ書けたときに食い違いが残ります。そこで書き込み経路を 1 本に固定し、読む側を 3 つに分けました。

記録が消せないことを、どうやって担保するか

監査ログの価値は「都合の悪い行を後から消せない」ことに依存します。松葉ではこれをアプリの実装で守るのではなく、データベースの権限設計で守っています。追加は誰でもできますが、更新と削除の許可規則そのものを作っていません。規則が無ければ、システム管理者であっても更新も削除もできません。参照はシステム管理者だけに開き、Box のメンバーには前述の関数経由の道しか通していません。

気づけない欠落を作らない

検知の設計でいちばん気を配ったのは「何も起きていないのか、見ていないだけなのか」を区別できる形にすることです。5 分ごとに回る 6 つの検知器は互いに独立に動かし、1 つが失敗しても残りが止まらないようにしています。1 つの失敗で全部が止まる作りにすると、この仕組み自身が「静かな欠落」を作ってしまいます。外部の監視サービスから数値が取れなかったときは、0 件と報告せず取得の失敗として扱います。前回の報告件数が読めないときは、黙るのではなく鳴らす側に倒します。

記録が溜まる側（記録の基盤 → 全社の監査ログ → 長期保管 → Box のアクティビティ）と、異常に気づく側（異常の検知 → アラートの運用）に分かれています。どこから読んでも読めるように書いていますが、通しで読む場合はこの一覧の順が読みやすい並びです。

設計上の数値です。件数の根拠はすべて共有定数の一覧か自動テストで固定されており、増減するとテストが落ちる形にしてあります。

実装の規模