Dev Study
← コードの外の約束 — 個人情報・ライセンス・生成物の権利
レッスン 2 / 10·約 9 分·第23期 コードの外の約束

ログに残さないものは、秘密と個人の2軸で決まる

リクエストがアプリケーションに届くまで
  1. ブラウザURL入力
  2. DNS名前→IP
  3. ルータ経路選択
  4. ロードバランサ振り分け
  5. Nginx受け口
  6. アプリ処理今ここ
  7. DB保存

義務はデータそのものではなく、それで何をしたかに付いてきます。今回は「残した」という行為を、アプリが書くログで見ます。

まず結論

ログから外すものを「パスワードやトークン」だけで考えると、半分しか見ていません。OWASP の Logging Cheat Sheet は、秘密と個人に関するデータを別の項目として並べています。

キー名で秘密を伏せるロガーは、秘密の軸では働きますが、URL に埋まったメールアドレスや IP アドレスは素通りします。本回は一次ソースが何を書いているかの紹介で、個別の事案の適否は判断しません。

? 読む前に予測

OWASP の Logging Cheat Sheet は、ログに直接記録すべきでないものの一覧で、秘密(パスワード・トークン・鍵)と個人に関するデータをどう扱っているでしょうか。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

除外リストの中で、秘密と個人は別の行にある

既存のクイズは「パスワードやトークンはログに出さず、必要なら成否やユーザーIDなど非機密の情報だけ記録する」を正解にしています。正しい判断ですが、それは1つの軸です。OWASP の Logging Cheat Sheet は、Data to exclude の節で次のように始めます。

The following should usually not be recorded directly in the logs, but instead should be removed, masked, sanitized, hashed, or encrypted:

続く12項目から、秘密と個人に関するものを抜き出すと次のとおりです(順序は原文どおり)。

OWASP Logging Cheat Sheet — Data to exclude の最初の一覧(抜粋)表
- Session identification values (consider replacing with a hashed value if needed to track session specific events)
- Access tokens
- Sensitive personal data and some forms of personally identifiable information (PII) e.g. health, government identifiers, vulnerable people
- Authentication passwords
- Database connection strings
- Encryption keys and other primary secrets

個人に関するデータは、秘密と同じ一覧に別の行として入っています。 秘密をすべて伏せても、この行は片づきません。

ログの1項目を、2つの問いで分ける
ログに書こうとしている値
2つの問いを別々に当てる
秘密の軸漏れたらその値で成り代わる・解読できるか
個人の軸特定の人に関する情報か
例
password・token秘密。個人に関するかとは別に判定
email・IP アドレス秘密ではない。個人の軸で問う
  • ・「非機密」は秘密の軸の答えで、個人の軸の答えではない
  • ・IP アドレスが個人情報に当たるかは、この回では断定しない
具体実物

要求をまるごと書くエラーログ

ログイン失敗時に要求まるごとをログへ出し、キー名 authorization・cookie・password の値だけを伏せる、よくある形を Node v24.21.0 で動かしました。値はすべてダミーで、アドレスとドメインは文書用のものです。

伏せる処理(キー名で決め打つ)設定ファイル
const DENY = new Set(["authorization","cookie","password"]);
const redact = v => (v && typeof v==="object") ? Object.fromEntries(Object.entries(v).map(([k,x])=>[k, DENY.has(k.toLowerCase())?"[REDACTED]":redact(x)])) : v;
$ node l2-logdemo.mjs(出力の3行目以降は別の実演のため省略)コマンド出力
naive : {"level":"error","msg":"login failed","req":{"method":"POST","url":"/api/login?email=taro%40example.jp","headers":{"authorization":"Bearer eyJhbGciOi.demo.sig","cookie":"sid=abc123","user-agent":"Mozilla/5.0"},"body":{"email":"taro@example.jp","password":"hunter2"},"ip":"203.0.113.7"}}
keyred: {"level":"error","msg":"login failed","req":{"method":"POST","url":"/api/login?email=taro%40example.jp","headers":{"authorization":"[REDACTED]","cookie":"[REDACTED]","user-agent":"Mozilla/5.0"},"body":{"email":"taro@example.jp","password":"[REDACTED]"},"ip":"203.0.113.7"}}

2行目(keyred)を分けると次のとおりです。

伏せる処理を通したあと表
場所 秘密の軸 個人の軸 結果
headers.authorization 秘密 — [REDACTED]
headers.cookie 秘密 — [REDACTED]
body.password 秘密 — [REDACTED]
url のクエリ — メール 残った
body.email — メール 残った
ip — IP アドレス 残った

秘密の軸では働いています。個人の軸は、最初から問われていません。 しかも URL の中の email= はキーではなく文字列の一部なので、拒否リストに email を足してもこの処理では届きません。「リストを増やせば解決」でも「無意味」でもなく、この方式が見る範囲がここまでだということです。

✓ ここまでの確認

キー名の拒否リスト(authorization・cookie・password)で伏せたロガーの出力について、正しい記述はどれですか。

抽象原理

個人の軸は、さらに2段に分かれる

では、メールアドレスも除外リストに入っているのでしょうか。OWASP の同じ節は、最初の一覧のあとに2つ目の一覧を置きます。

Sometimes the following data can also exist, and while useful for subsequent investigation, it may also need to be treated in some special manner before the event is recorded:

その最後の行が Non sensitive personal data (e.g. personal names, telephone numbers, email addresses) です。OWASP は個人データを、除外の一覧(健康・公的な識別子など)と、特別な扱いが要るかもしれない一覧(氏名・電話・メール)の2段で扱っています。 「OWASP はメールをログから除けと言う」は原文より強い言い方です。

同じ節はこう続けます。

Consider using personal data de-identification techniques such as deletion, scrambling or pseudonymization of direct and indirect identifiers where the individual's identity is not required, or the risk is considered too great.

本人の特定が要らない場面では識別子を消す・かき混ぜる・仮名化(pseudonymisation)する、という勧めです。最初の一覧の処置にも hashed が並んでいます。ハッシュにすれば個人の軸が片づくのか、は別に問うべきことです。

日本の法令にも、この軸に触れる条文があります。個人情報保護法(e-Gov、2026-07-17 施行版)第23条です。

個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない。

対象は「個人データ」です。第16条第1項は「個人情報データベース等」を、個人情報を含む情報の集合物で「特定の個人情報を電子計算機を用いて検索することができるように体系的に構成したもの」等と定めます。アプリのログがこれに当たるかを、本回は判断しません。 エンジニアに言えるのは、個人の軸の値がログにあるなら、この問いが立つ、までです。

節の冒頭の一文も、同じ向きです。

Never log data unless it is legally sanctioned. For example, intercepting some communications, monitoring employees, and collecting some data without consent may all be illegal.

結びは may all be illegal(違法となり得る)で、断定していません。

具体実物

WAF の検知ログでは、秘密がキー名なしで出てくる

逆向きの例です。第3期「WAFの誤検知」で、パスワードを /bin/bash に設定した利用者を見ました。WAF がこれを攻撃と誤検知すると、アラートには一致した入力が残り、そのパスワードが平文でエラーログに書かれます(「壊れた後に何をするか」の FieldNote にも同じ例があります)。

ここで漏れているのは秘密の軸です。ただし password というキーの値としてではなく、「規則に一致した文字列」として出てきます。アプリ側の拒否リストは、アプリが自分で書くログにしか働きません。WAF のログは別の段が書いています。

前の例とあわせると、キー名で決め打つ方式は、どちらの軸でも取りこぼしうることが分かります。

✓ ここまでの確認

OWASP の Logging Cheat Sheet は、メールアドレス・電話番号・氏名をどこに置いていますか。

⇄ 2つを見比べる
具体例 A

アプリのエラーログ(要求まるごと)

キー名で秘密を伏せた。秘密の軸は働いたが、メールアドレスと IP アドレスは個人の軸で問われないまま残り、URL の中の email はキーでないため方式上も届かない。

取りこぼした軸表
軸 結果
秘密 キー名で伏せた
個人 問われず残った
具体例 B

WAF の検知ログ(誤検知)

パスワードがキー名ではなく、規則に一致した入力として記録される。アプリ側の伏せる処理は別の段のログには届かず、秘密の軸で漏れる。

取りこぼした軸表
軸 結果
秘密 一致した入力として残った
個人 この例では確かめていない

片方は個人の軸で、片方は秘密の軸で取りこぼしました。共通する原因は何でしょうか。

「伏せる処理が、どこに書かれた、どんな形の値を見ているか」を両方で比べてください。

ここから先は法務へ

(a) エンジニアが気づける信号: ログに email・IP アドレス・ユーザーIDなど個人の軸の値が残っている。そのログが社外の監視サービスへ送られている。伏せる処理がキー名で決め打つ方式である。

(b) 法務に持っていく材料: 残っている値の種類と、その値がどのログのどの段に出るか。保存期間と、読める人の範囲。ログの送り先と契約の相手。外部の監視サービスへの送信が委託(第25条)に当たるか第三者提供(第27条)に当たるかは法務の判断で、第27条第1・2項は 2028-07-16 施行の改正で変わります。

(c) この回が言っていないこと: アプリのログが「個人情報データベース等」に当たるか。IP アドレスやユーザーIDが個人情報に当たるか。email を残すことが違法か適法か。いずれも本回は判断していません。

この章のまとめ

  • OWASP の除外の一覧では、秘密と個人に関するデータが別の行。秘密を全部伏せても、個人の行は残る。
  • 個人データは2段。健康・公的な識別子などは除外の一覧、氏名・電話・メールは特別な扱いが要るかもしれない一覧。
  • キー名で伏せる処理は秘密の軸では働くが、URL の中の email や IP は素通りした(実演)。
  • WAF の誤検知ログでは、秘密がキー名なしで別の段から出る。
  • 既存問の「非機密の情報だけ記録」は秘密の軸で正しい。個人の軸を足して考える。
  • 個人情報保護法第23条の対象は個人データ。アプリのログが当たるかは本回は判断しない。

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 3正解: 0

既存問の正解「パスワードやトークンはログに出さず、必要なら成否やユーザーIDなど非機密の情報だけ記録する」と、本回の関係として適切なのはどれですか。

用語集(3語)
Data to exclude
OWASP Logging Cheat Sheet の節。直接記録すべきでない一覧と、記録前に特別な扱いが要るかもしれない一覧の2つを置く。
拒否リスト方式(教材側の呼び名)
特定のキー名の値だけを伏せるやり方。キーの付いていない場所(URL の文字列、照合された入力)にある値は見えない。
個人情報データベース等
同法第16条第1項の語。個人情報を含む情報の集合物で、特定の個人情報を検索できるよう体系的に構成したもの等。