事故図鑑
Equifax 情報漏えい事件（2017）— 未パッチのApache Strutsで1.47億人が漏れた原因と防御
2017年、信用情報大手 Equifax で約1.47億人分の個人情報が漏えいしました。原因は、すでに修正パッチが出ていた Apache Struts の既知脆弱性（CVE-2017-5638／CVSS 10.0）を、公開システムに当てていなかったこと。さらに監視装置の証明書失効で76日間も持ち出しに気づけませんでした。既知CVEの放置・資産の棚卸し不足・検知の空白という三つの崩れを、あなたの環境で繰り返さないための具体策（パッチSLA・資産インベントリ・機械監視）を、公開記録の事実だけで解説します。
実際に起きた公開事故を、ニュースの再放送ではなく 「あなたの環境でどう防ぐか」 の視点で読み解きます。本記事は 公開記録（規制当局・公式発表・Apache Software Foundation・報道）にもとづく解説です。出典は末尾に明記します。
- 対象
- Equifax（米・信用情報大手）
- 公表
- 2017年9月7日（侵入 5月〜7月／発覚 7月29日）
- 手口分類
- 既知CVE（Apache Struts RCE）の未適用を突いた侵入と外部持ち出し
- 影響規模
- 米国で約1.47億人分（氏名・SSN・生年月日・住所ほか。一部クレカ番号も）
- 根本原因
- 既知CVEの放置 ＋ 資産インベントリの欠如 ＋ 監視の空白（証明書失効）
- 本命の対策
- パッチSLA・資産棚卸し・機械監視・検知の健全性
何が起きたか（平易に）
Equifax は、利用者が信用情報に異議を申し立てるオンライン窓口を運用していました。その土台に使われていた Apache Struts という部品に、外部から任意のコードを実行できる深刻な脆弱性（CVE-2017-5638）が見つかります。
修正パッチは 脆弱性の公表と同じ日（2017年3月7日） に出ていました。ところが、対象の窓口システムには パッチが当てられないまま放置。攻撃者は2か月後の5月から、この既知の穴を突いて侵入し、社内ネットワークを横移動しながら大量の個人情報を持ち出しました。
さらに悪いことに、通信を監視する装置が 証明書の失効で長期間停止しており、異常な持ち出しを 76日間検知できませんでした。7月29日に証明書を更新した途端、不審な通信が見えて発覚——気づくための仕組みが、止まっていたのです。
“難しい攻撃”ではなく“当てなかった”が本質
この事故で使われたのは、世界中に公開済みでパッチも出ていた既知の穴です。攻撃の高度さではなく、「既知の危険を、決められた時間内に塞ぐ運用」が無かったことが被害を生みました。これは個人開発でも組織でも、同じ構造で起こります。
連鎖は「防御の地図」でもある
重要なのは、これが5つのホップの連鎖で、各ホップに止め所があったことです。攻撃手順ではなく、どこで断ち切れたかとして読んでください。
① 既知CVEが公開（修正パッチ同日リリース）
⊘ 止め所：機械監視で“自分に関係するCVE”を即検知
② 公開システムが未適用のまま放置
どこでStrutsが動くか把握できず、修正の網から漏れた。
⊘ 止め所：資産インベントリ＋パッチSLA（公開→適用の期限）
③ RCEで侵入
未適用の穴から任意コード実行で足場を得る。
⊘ 止め所：最小権限・WAFは“補助”として併用
④ 平坦なネットワークを横移動し大量持ち出し
分離が甘く、1つの侵害が広域のデータに波及。
⊘ 止め所：ネットワーク分離で爆発半径を縮める
⑤ 監視の証明書失効で76日間検知できず
気づくための装置が止まっていた。
⊘ 止め所：証明書・監視の健全性チェックを習慣化
公表された時系列
2017-03-07
CVE-2017-5638 が公表。同日に修正パッチがリリースされる。2017-03〜
社内に注意喚起。しかし対象の窓口システムは未適用のまま。2017-05〜07
攻撃者が未適用の穴を突いて侵入し、データを持ち出す。2017-07-29
監視装置の証明書を更新した直後、不審な通信を検知して発覚。2017-09-07
一般公表。約1.47億人への影響が判明。2019-07
FTC・CFPB・各州と最大約7億ドルで和解（米史上最大規模）。
根本原因は「1つの未適用」だけではない
「パッチを当て忘れた」で終わらせると再発します。実際には複数の層が連続して崩れたのが本質です。
崩れていた構成（事故時）
- 既知CVEを放置（修正は出ていたのに公開システムへ未適用）
- 資産インベントリの欠如（どこで部品が動くか把握できず）
- 平坦なネットワーク（横移動・データ波及を許す）
- 検知の空白（監視装置が証明書失効で長期停止）
守られた構成（再発防止）
- パッチSLA：公開→適用までの時間を決め、KEV/高CVSSを優先
- 資産インベントリ：依存と稼働箇所を機械で把握し、修正の網から漏らさない
- ネットワーク分離：侵害の爆発半径を縮める
- 検知の健全性：証明書・監視の死活を定期確認
“パッチを当てる”は単発作業ではなく運用
鍵は「いつか直す」ではなく「公開からN時間/日以内に直す」という期限（SLA）を持つことです。そして当てるべき対象を取りこぼさないために、どこで何が動いているかを機械が把握している必要があります。人の記憶に頼ると、Equifaxのように“1台だけ”が残ります。
あなたの環境での再発防止
規模を問わず効く、優先順の対策です。「公開済みのCVEを放置しない」という一点を、仕組みで担保します。
資産インベントリを持つ（どこで何が動くか）
自分の依存ライブラリと、それがどのサービス・コンテナで動いているかを一覧化します。Equifaxの最大の躓きは「対象システムを取りこぼした」こと。実際に動いているバージョンで把握するのが要点です。
パッチSLAを決める（公開→適用の期限）
「重大CVEは公開からN日以内に適用」と期限を先に決めます。とくにKEV（実際に悪用中）と高CVSSを最優先。期限があるから“放置”が可視化されます。
機械に監視させる（人力で追わない）
CVEを人力で追うのは不可能です。Dependabot（GitHub）や osv-scanner でロックファイルを検査し、自分の依存に該当するCVEだけを自動通知させます。依存の機械監視の作り方に具体手順があります。
分離と検知を用意する（踏まれた後の保険）
ネットワークを分離して横移動を抑え、異常な大量持ち出しを検知できるようにします。監視や証明書が“生きているか”の確認も運用に含める——気づく仕組みが止まっていては意味がありません。
ITD自身も同じ対策を実践している
ITD自身も、ここで書いたとおり自分の依存を CVE監視の対象にしています。Equifaxの教訓——既知の穴を、人が見落とさない仕組みで塞ぐ——を、製品の説得力に変えています。「いつか直す」を「期限内に、機械の助けで直す」に置き換えることが、この事故の本当の学びです。
出典（公開記録）
本記事の事実は、以下の公開情報にもとづきます。攻撃の再現手順やペイロードは扱わず、防御の教訓に絞っています。
- Apache Software Foundation「Media Alert: Equifax Data Breach Due to Failure to Install Patches」(2017) — news.apache.org
- Equifax 公式発表「Releases Details on Cybersecurity Incident」(2017) — investor.equifax.com
- CFPB/FTC/各州 和解発表 (2019) — consumerfinance.gov
- CSO Online「Equifax data breach FAQ」— csoonline.com
次に読む
- 用語：CVE とは / CVSS とは / RCE とは
- 対策：依存を機械監視するしくみ（パッチ運用）
- 事故：Capital One — SSRFから1億人分が漏れた話
よくある質問
QEquifax事故の根本原因は何？
新種の高度な攻撃ではなく、『すでに修正パッチが公開されていた既知の脆弱性（Apache Struts の CVE-2017-5638／CVSS 10.0）を、公開システムに当てていなかった』ことです。加えて、どのシステムでその部品が動いているか把握できておらず、監視装置も証明書失効で止まっていたため、76日間も持ち出しに気づけませんでした。
Qパッチはあったのに、なぜ当たらなかったの？
公開記録によれば、修正は脆弱性公表と同日（2017年3月7日）に出ていました。社内に注意喚起も回りましたが、対象のオンライン窓口システムにパッチが適用されず放置されました。『どこでその部品が動いているか』の資産インベントリが不十分で、修正の網から漏れたことが大きな要因です。
Q自分のような小規模開発でも教訓はある？
あります。規模に関係なく『既知CVEを放置しない』『自分の依存にその部品があるか把握する』『機械に監視させて見落としをなくす』の3点は同じです。人力でCVEを追うのは不可能なので、Dependabotやosv-scannerに見張らせるのが現実解です。