ログは後から足しても、過去は戻らない

障害が起きてから「この操作のログを出しておけばよかった」と思っても、過去の分は二度と取れません。ログは、機能を作るときに一緒に決めるものです。

講座34ではログを読む側を学びました。ここでは、読む人が困らないように残す側を考えます。

追えるようにする：いつ・誰が・何を

1件のログから、少なくとも次が分かるようにします。

最後の「一続きの印」は、リクエストIDと呼ばれます。1回のアクセスの中で、画面の処理・データベース・通知のログがばらばらに出ても、同じ番号でたどれます。naminori の本番のログにも、行ごとにこの番号を付けています。

監査ログは、普通のログと分けて持つ

「誰がどのデータを見て、何を変えたか」を後から確かめるための記録を、監査ログと呼びます。普通のログは調査のためのもので、古くなったら消します。監査ログは普通のログと分けて、長く残す前提で持ちます。

監査ログの中身（何を残し、何を伏せるか）は、講座33「認証・認可の設計」の第8回で詳しく扱っています。運用の側から押さえておくのは次の2点です。

• 成功だけでなく、認証の失敗や、権限が無くて断ったものも残す。不正を疑うときに見たいのは、むしろそちらだから（naminori の、管理者がAIを通してデータを操作する窓口もそうしている）
• 普通のログを消す仕組み（下で扱う）に、監査ログを巻き込まない

個人情報をログに出さない

第1回で挙げた例を、もう少し詳しく見ます。よくあるのは次の形です。

• フレームワークの初期設定のまま、送られてきた入力（氏名・メールアドレスなど）がログにそのまま書かれる
• ログは日ごとに分けて保存されるが、古いものを消す仕組みが無い
• 気づいたときには、何年分ものログに個人情報が貯まっている

こうなってから直すことは3つです。

1. ログに出すときに、氏名・メールアドレス・生年月日・電話番号・住所などの値を伏せる
2. 貯まっていた古いログを消す。その結果、それより前の出来事はログでは調べられなくなる（エラー監視に別に集めていれば、エラーの記録はそちらに残る）
3. ログを何日で消すかを決めて、自動で消す

最初に「何を出さないか」と「何日で消すか」を決めていれば、個人情報が貯まることも、調査の手がかりを失うことも起きません。naminori でも、ログに出す値を伏せ、ログは30日で消す設定にしています。

通知の本文も、ログと同じ

通知はスマホやチャットに表示され、ログより多くの人の目に触れます。naminori の会員の行動の通知は、本文に氏名・メールアドレス・電話番号を入れず、会員の番号と、職種や都道府県などの属性までにしています。誰なのかは、通知のリンクから管理画面で確かめます。

最初に決めること

• どの操作に、いつ・誰が・何を・結果を残すか
• 監査ログが必要な操作はどれか（個人情報の閲覧・データの変更・権限の変更）
• ログに出さない項目はどれか
• ログを何日残し、何で消すか

• ログは後から足しても、過去は戻らない
• いつ・誰が・何を・結果・リクエストID
• 監査ログを分けて持つ（拒否も残す）
• 個人情報を出さない、残す期間を決める