事故図鑑
Capital One 情報漏えい事件（2019）— SSRFから1億人分が漏れた原因と防御
2019年、米大手銀行 Capital One で約1億600万人分の申込データが漏えいしました。入口は1つの SSRF（サーバーサイド・リクエスト・フォージェリ）。そこからクラウドのメタデータ提供先に到達し、過剰な権限を持つIAMの一時鍵を奪われ、S3ストレージが一括コピーされました。攻撃の連鎖を防御の地図として分解し、あなたの環境で同じ轍を踏まないための具体策（IMDSv2・最小権限・送信先の許可リスト）を、公開記録の事実だけにもとづいて解説します。
実際に起きた公開事故を、ニュースの再放送ではなく 「あなたの環境でどう防ぐか」 の視点で読み解きます。本記事は 公開記録（規制当局・報道・学術分析・公式発表）にもとづく解説です。出典は末尾に明記します。
- 対象
- Capital One（米大手銀行）
- 公表
- 2019年7月29日（発覚 7月19日／侵入 3月）
- 手口分類
- SSRF を起点としたクラウド認証情報の奪取と外部持ち出し
- 影響規模
- 米・加で約1億600万人分の申込データ（SSN 約14万、連携銀行口座番号 約8万 を含む）
- 根本原因
- SSRFの欠陥 ＋ メタデータ提供先の無防備 ＋ IAMロールの過剰権限という多層の崩れ
- 本命の対策
- 送信先の許可リスト・IMDSv2・IAM最小権限による多層防御
何が起きたか（平易に）
Capital One は申込処理の一部をクラウド上で動かしていました。その前段にあった、本来は防御側のはずのコンポーネント（リバースプロキシ／WAFとして稼働）に、外部から指定した宛先へサーバー自身にリクエストを送らせられるという SSRF の欠陥がありました。
クラウドの仮想マシンには、内部からのみアクセスできる「メタデータ提供先」 という特別な宛先があり、そこに問い合わせると、そのマシンに割り当てられた権限の 一時的な鍵 が返ってきます。攻撃者は SSRF を使ってこの内部宛先へ到達し、鍵を入手。その鍵に紐づくIAMロール（公開記録では ISRM-WAF-Role と報じられた）が ストレージを広く読み出せる過剰な権限 を持っていたため、約700個のストレージ領域（S3バケット）の中身を そのままコピー して持ち出しました。
“内部からしか見えない”は、SSRFがあると“内部”になる
メタデータ提供先は「外部からは到達できない」という前提で守られていました。しかし SSRF はサーバー自身に代理アクセスさせる攻撃なので、その前提を崩します。「内部限定だから安全」という設計は、入口にSSRFが1つあるだけで崩壊します。
攻撃の連鎖は「防御の地図」でもある
重要なのは、これが4つのホップの連鎖で、各ホップに止め所があったことです。攻撃手順ではなく、どこで断ち切れたかとして読んでください。
① 入口：SSRF
サーバーに任意の宛先へ代理リクエストを送らせられる欠陥。
⊘ 止め所：送信先を許可リスト方式に
② 内部のメタデータ提供先に到達
内部限定のはずの宛先に、SSRF経由で到達してしまう。
⊘ 止め所：IMDSv2（トークン必須＋ホップ制限）
③ IAMの一時鍵を取得
マシンに付いたロールの一時認証情報が返ってくる。
⊘ 止め所：ロール権限を最小化（ストレージ全読み禁止）
④ ストレージ(S3)を一括コピー
約700領域の中身をそのまま外部へ持ち出し。
⊘ 止め所：egress制御＋異常な大量読み出しの検知
公表された時系列
2019-03
クラウド環境への不正アクセスが発生（後に判明）。2019-07-17
外部からの通報（GitHub上の投稿）で異常が指摘される。2019-07-19
Capital One が社内調査で侵害を確認。2019-07-29
一般公表。元AWSエンジニアの容疑者がFBIに逮捕される。2019-11
AWS が SSRF への多層防御として IMDSv2 を発表。2020-08
米OCC が約8,000万ドルの制裁金。クラウド移行前のリスク評価の不備を指摘。
根本原因は「1つのミス」ではなく層の崩れ
この事故を「SSRFのせい」で片付けると、再発します。実際には3つの層が連続して崩れたのが本質です。
崩れていた構成（事故時）
- 入口で送信先を検証していない（任意の宛先に代理リクエスト可能）
- メタデータ提供先がトークン不要で鍵を返す（旧方式）
- マシンのIAMロールがストレージを広く読める過剰権限
守られた構成（再発防止）
- 送信先を許可リスト方式に限定し、内部アドレスへの代理アクセスを拒否
- メタデータは IMDSv2：セッショントークン必須＋ホップ数制限で代理到達を遮断
- IAMロールは最小権限：必要なバケットの必要な操作だけ
“シェアード・レスポンシビリティ”の境界線
クラウド側は基盤の安全を担いますが、SSRFの修正・IAM権限設計・メタデータ保護は利用者側の責任です。事故の制裁理由も「クラウド移行前のリスク評価の不備」でした。便利な基盤に乗ること自体は問題ではなく、境界線の自分側を設計し切れているかが分かれ目です。
あなたの環境での再発防止
規模を問わず効く、優先順の対策です。「URLを受け取って取りに行く」「Webhookや画像を代理取得する」機能が1つでもあるなら、自分ごとです。
送信先を“許可リスト方式”にする（SSRFを入口で塞ぐ）
ユーザー由来のURLへサーバーが代理アクセスする処理は、許可した宛先だけに限定します。内部アドレス（メタデータ提供先や私設ネットワーク）への到達は既定で拒否。SSRFの項に、検証で外しがちな落とし穴（リダイレクト追従・DNS再解決など）をまとめています。
メタデータは IMDSv2 を強制する
クラウドのメタデータ提供先を、トークン必須・ホップ数制限のある新方式（AWSなら IMDSv2）だけに限定します。これだけでも、SSRFからの鍵奪取は大幅に難しくなります。旧方式を無効化するのが要点です。
IAMロールを最小権限にする（爆発半径を縮める）
万一鍵が漏れても被害を閉じ込めるため、マシンやサービスに付ける権限は必要な対象の必要な操作だけに絞ります。「とりあえずストレージ全許可」は、1つの侵害を全データ流出に変えます。
出口（egress）と異常検知を用意する
外向き通信を必要な宛先に限定し、短時間の大量読み出しのような異常を検知できるようにします。入口で防ぎ切れなくても、持ち出しの段で気づける層を残します。
ITDの設計思想と重なる点
ITD自身も、ユーザーのURLを扱う機能は 検証済みドメインのみを前提に設計しています（SSRF-safe by design）。この事故は、私たちが製品で守っている原則——入口の検証・最小権限・内部前提に頼らない——が、なぜ必要かを最も雄弁に語る実例です。便利さの裏で、境界線の自分側は自分で設計し切る。それが当事者にも公開事故にも共通する結論です。
出典（公開記録）
本記事の事実は、以下の公開情報にもとづきます。攻撃の再現手順やペイロードは扱わず、防御の教訓に絞っています。
- Krebs on Security「What We Can Learn from the Capital One Hack」(2019) — krebsonsecurity.com
- ACM Transactions on Privacy and Security「A Systematic Analysis of the Capital One Data Breach」— dl.acm.org
- CyberScoop「US financial regulator fines Capital One $80 million over data breach」(2020) — cyberscoop.com
- Capital One 公式プレスリリース（SEC提出 8-K, 2019） — sec.gov
次に読む
- 用語：SSRF とは（この事故の入口・検証の落とし穴つき）
- 事故：放置した CVSS 10.0 を踏まれた話（個人開発の事例）
- 対策：最小権限と機械監視を運用に組み込む
よくある質問
QCapital One事故の根本原因は何？
単一の原因ではなく、防御の層が連続して崩れたことです。入口は『サーバーに任意の宛先へリクエストを代理送信させられる』SSRFの欠陥。そこからクラウドのメタデータ提供先に到達でき、その先のIAMロールが過剰な権限を持っていたため一時鍵でストレージ全体を読み出せました。どれか1層でも正しく閉じていれば、被害は止まっていました。
Q自分の小規模なサービスでも関係ある？
あります。SSRFは『URLを受け取って取りに行く』『画像やWebhookを代理取得する』といったありふれた機能から生まれます。クラウド上で動かしているなら、メタデータ提供先からの認証情報奪取は規模を問わず起こりえます。本記事の3つの対策（IMDSv2・IAM最小権限・送信先の許可リスト）は個人開発でも有効です。
QWAF（Webアプリケーションファイアウォール）を入れていれば防げた？
いいえ。この事故では、むしろWAFとして動いていたコンポーネント自体がSSRFの踏み台になりました。WAFは“ある種の”攻撃を弾く層であって、設定を誤れば穴にもなります。『WAFがあるから安全』は誤解で、入口の検証・最小権限・メタデータの保護といった多層防御が本命です。