TL;DR
- 漏えい疑惑が出た瞬間にマネージャーが握るべき３点：影響範囲 / 封じ込めETA / 説明責任者
- “完璧に防ぐ”より“燃え広がらない仕組み”を先に作れ
- コードレビューを信じるのは自由だが、信じたあとに焼け跡が残る覚悟は必要
1. 事件は「IT歴２週間」に起こった
配属されたばかりの金融サービスの運用保守プロジェクト。
私の業歴は2週間、役割はPMOだ。なお、先輩PMは4PJほど掛け持っておりこちらに手を割けない。
フロントはスマホアプリ、バックエンドは Rails——要するに 「事故るとニュースになる金融サービス」 である。
その本番環境に、なぜか
https://api.example.com/debug/test
という “おかわり自由の個人情報食べ放題” エンドポイントが鎮座。
外部セキュリティ診断のランダム URL 叩きで見事にヒットし、
「おや、個人情報がこんなに…」 と報告書に書かれて爆発した。
2. 初動で実行したこと —— 技術より“疑惑の消火手順”
ここで重要なのは “技術詳細を握る” ではなく “決断と説明のタイミングを握る” こと。
私がコンソールを叩くより、エンジニアに叩かせて 締切だけ首根っこを掴む 方が 100 倍速い。
2-1. 本当に漏れたのか？ -“漏れてない” を証明する地味な闘い-
技術的詳細は割愛するが、要は S3 の墓場からログを掘り返し “アクセス 0” の数字 を取るだけ。
この数字が無いと、法務・経営・顧客すべての質疑応答は無限ループになる。
幸い外部アクセス０件でした
2-2. 何時間で塞げる？ -封じ込めは「フレーム」だけ指定-
開発チームへの指示は３行で足りた。
- 「問題のエンドポイントだけ塞いだ修正を30分で実施してPRすること」
- 「公開リスト外 URL を 要不要を色分け して理由含め一覧化し 4時間後に報告すること」
- 「公開リスト外 URLが全て不要であれば全てのエンドポイントを塞ぐ修正を今日中にPRすること」
※残す必要あるものを発見したら即報告すること
中身をどう実装するかはプロに任せる。その代わり 時計の針は私が回す。
問題になったエンドポイント以外に5つほど公開リスト外URLを発見し
全て不要なのを確認し修正し緊急リリースしました
3. 原因？ - “ブラックホール開発” で誰も覚えていない -
重大なヒヤリハットなので事故報告書提出もワンセットである。。。
当然、原因調査はするものの以下のような理由となった。。
- 納期：死線超え —— PR 30 本／日をレビューゼロでマージ
- 当時の開発者：全員卒業 —— git blame は退職者の墓標
☠ 会議の内容
「犯人は誰だ？」→“時効” という便利な単語が飛び交い、会議は終わった。
4. 恒久対策 -マネージャーとして引いた“ガードレール”-
| ガードレール | 目的 | ブラックな本音 |
|---|---|---|
| CIで更新コード中に"debug"、"test"という文字を検知したらmergeしないように設定 | CI が勝手に蹴る | 人の良心より機械の冷酷 |
IT ガバナンスは “善意” ではなく “システムと公開処刑” で回す方が平和だ。
5. 教訓 —— 「起こさない」より「燃え広がらない」
- 漏えい疑惑は まず“数字”で黙らせる。
- 技術は任せ、マネージャーは 時間・情報・責任 を束ねる。
- 完璧主義より 失敗しても半径５ｍで鎮火 できる組織設計を。
Debug エンドポイントは “いつか見つかる時限爆弾”。
私のように冷や汗１リットル流したくなければ、
ガードレールを先に作り、爆弾は小出しに爆破試験 しておくといい。
6. 最後に言いたいこと
今にして思えば、SEとして単価80万クラスのエンジニアが冷静にコードレビューしていれば絶対に防げるレベルの話デス。
また、どうしようもない理由でstaging環境にdebugエンドポイント公開したい場合は、railsであればproductionモードで起動した時は公開しないように設定しないといけないデス。
ここまでレビューの質落とすくらいの炎上は悪death...
この記事があなたの次の炎上を“ボヤ”で終わらせる手助けになれば、
私の残業魂も少しは成仏する。読後に “いいね” で供養してくださいwX（旧Twitter）でもこんな話をよくつぶやいてるので、フォローも歓迎です！
→ @puchan_pig