ハクソク

世界を動かす技術を、日本語で。

ログから秘密を排除する (2024)

2025年9月8日原文(allan.reyes.sh)

概要

  • ログにおける機密情報漏洩 は、単一の解決策では防げない複雑な問題。
  • 多層的な対策（lead bullets） を組み合わせることで、現実的な防御力を確保。
  • 原因は多岐にわたり、直接的なログ記録から設計や設定ミス、ユーザー入力まで様々。
  • インシデントの影響範囲は広く、信頼性や法的リスクにも直結。
  • 本記事は実践的な対策と考え方 を10の観点から紹介。

ログから機密情報を守るには：銀の弾丸は存在しない

  • 単一の解決策（銀の弾丸）は存在しない 問題であり、様々な対策（lead bullets）の組み合わせが必要。
  • 80/20ルールが通用しない 難しさ。SQLインジェクションのように一つの対策で大半を防ぐことはできない。
  • ログに機密情報が混入する原因 は多様で、予想外の場所や方法で発生。
  • 原因を知り、対策の枠組みを持つこと が、再発防止やインシデント対応の第一歩。
  • 本記事では10の具体的なlead bullets （実践的な対策）を紹介。

ログに機密情報が混入する主な原因

  • 🤦 直接的なログ記録

    • デバッグやテスト目的で 意図せず機密情報をログに記録 するケース。
    • コードレビューやgrepで発見しやすいが、ヒューマンエラーが根本原因。

  • 🚰 キッチンシンク問題

    • エラーオブジェクトやレスポンス全体を丸ごとログ に出力し、意図せず機密情報も含まれる。
    • 型安全な言語や型定義を活用すれば検出しやすくなる。

  • 🔧 設定変更による副作用

    • ログレベルや設定の変更により、本来出力されないはずの情報がログに流出。
    • 低レイヤーやグローバルな設定変更が原因になりやすい。

  • 🥧 埋め込み型の機密情報

    • URLやRPC、リクエストパラメータ など、設計段階で機密情報が一般データに埋め込まれている。
    • ログ以外の層（例：HTTPアクセスログ）でも漏洩リスク。

  • 📡 テレメトリ・モニタリング

    • エラーモニタリングや分析ツール が、意図せず機密情報を収集・保存。
    • ログパイプライン外の経路に注意が必要。

  • 🕺🏻 ユーザー入力

    • ユーザーが意図せず機密情報を不適切なフィールドに入力 し、ログに残る。
    • UIやユーザー教育だけでなく、入力値の扱い全般に注意。

ログにおける機密情報漏洩の影響

  • 被害範囲の広さ

    • 内部APIキーなどすぐにローテーション可能なものから、 PIIや顧客パスワード のように回収困難なものまで幅広い。
    • 法的・規制上のリスクや、 信頼性の低下 に直結。

  • 対策をすり抜ける特性

    • データベース暗号化やアクセス制御 など、他のセキュリティ対策をログが無効化してしまう危険性。
    • ログ＝データの最終出口 として、特別な注意が必要。

  • 規模や成熟度を問わず発生

    • 大企業・成熟したセキュリティ体制でも 完全防御は困難。
    • 公開事例も多く、透明性のある対応が重要。

まとめと今後の展開

  • 単一の解決策は存在せず、多層防御（defense-in-depth）が現実的なアプローチ。
  • 原因を正しく理解し、各層でlead bulletsを配置 することが有効。
  • 次回以降、 具体的な10のlead bullets（実践的対策） について解説予定。

（次回に続く場合は、「ログから機密情報を守る10のlead bullets」などの新しいセクションタイトルで整理してください。）

Hackerたちの意見

いい読み物だった。

「人々がコードを書いて、うっかり機密データをログに入れてしまうことはあるけど、そういう人たちが報告して、対応して、修正するんだよね。これが最後のポイントじゃなくて、最初のポイントであるべきだと思う。」

著者の結論に賛成か反対かに関わらず、これは素晴らしいリソースだよ。問題を分解して、よく説明されていて、提案された修正の技術的な説明もちゃんとついてるからね（その修正に対する意見は別として）。問題領域にアプローチして明確にする方法の素晴らしい例だと思う。

JavaにはGuardedStringの実装があるよ。 https://docs.oracle.com/en/middleware/idm/identity-governanc...

ログから秘密を守りたい気持ちはわかるけど、ログ自体も秘密と見なされるべきじゃない？ 完全にサニタイズされたログでも、敵に共有したくないようなプロダクション環境のデータがたくさん含まれてると思うよ（例えば、ピーク使用時間とか）。

└

ログはサポートチームや、姉妹チームのオンコール、全ての開発者に公開される必要があると思う。だから、秘密にアクセスする必要がある人よりも、はるかに多くの人がログにアクセスすることになる。ログに秘密が含まれていると、内部の脅威のリスクが広がるし、フィッシングされた人から高い権限に移行するのがずっと簡単になる。監査記録がある場合、秘密にアクセスするのはログにアクセスするのとは別に記録しておきたいよね。

└

そうだね、でも防御は深く考えよう。競合他社に移るチームメンバーがピーク使用時間を教えることはできるけど、全ての顧客のパスワードを教えるべきじゃないよね。

└

敵からの秘密と、内部の区分けがあるよね。ルーターのsyslogを見なきゃいけないビジネスニーズがある人が何百人もいるかもしれないけど、管理者ユーザーのログイン情報にアクセスするべき人はほとんどいないし、自動化ロールアカウントの情報にアクセスできる人も数十人程度だと思う。

└

PIIは独自情報とは違うよ。顧客のメールアドレス？PIIだね。マスクしなきゃ。コードのスタックトレース？独自情報だよ。従業員はそれを見てトラブルシューティングできるから。

ランタイムの露出防止については、インバンドシグナルの方がアウトオブバンドよりもこの問題には効果的かもしれないね。言及された汚染チェック技術のように、ソースで機密文字列に何か魔法の文字列（例えば、認識できるプレフィックス + ランダムに生成されたUUID）を挿入して、シンクでそれを取り除くって感じ。 （または、秘密をその魔法の文字列で包むとか。）その後、その魔法の文字列を含む文字列が永続データ、ログに入らないようにブロックまたはマスクする。露出ポイントは、seal()/unseal()関数を呼び出すところにあるから、特定するのも簡単だよ。

└

このアプローチが適切になる状況や理由について詳しく教えてもらえる？一見すると、この記事の技術の複雑で劣った近似に見えるんだけど、自動的に使い捨てじゃないし、静的チェックもされてないし、正しい秘密の使い方に対してはエラーが出やすいし、善意のバカが秘密を誤って抽出したり「洗浄」したり漏らしたりするのを防げてない気がする。ログから秘密を危険なタイミングで削除することで漏洩の可能性もあるし。

うわ、マジか - ちょうど1ヶ月前に職場でその問題が出たんだ。開発システムはテスト用だから、すごくシンプルなユーザー名とパスワードを使ってたんだけど、その中の一つが「秘密」を含んでたせいで、全部消されちゃった。これについてはすごく強い意見があって、要するに「お前ら、なんで全部ログ取ってるの？怠け者かよ」ってことと、「秘密を別のツールに入れて、ログでスキャンするために追加するなんて、漏洩のリスクを増やすだけじゃん」ってこと。特に、秘密が単語の一部でも検閲されるってことは、たぶんハッシュ化もされてなかったってことだし。でもセキュリティツールだから、そのまま残るんだよね。カッサンドラみたいな気分だけど、将来的にこれや同じ機能を持つ他のツールで大きなセキュリティ問題が起こるのは予測できる気がする。Xを防ぐためのソフトウェアがXに脆弱であってはいけないはずなのに、なぜかしばしば脆弱になっちゃうっていう、まさに盲点みたいなもんだよね。

└

なんで全部ログ取るのが怠けてるって考えられるの？

Hacker Newsで議論の続きを見る