侵害事例

【事例研究】Capital One クラウド侵害事件

― クラウドは破られたのか、それとも設定が破られたのか ―

1. 事実（What happened）

■ 発生年

2019年

■ 被害規模

  • 約1億人超の顧客データ
  • 氏名、住所、クレジット情報の一部
  • 社会保障番号（約14万人分）

■ インフラ

AWS（Amazon Web Services）上で運用

2. 攻撃の仕組み（How it happened）

今回の侵害は、AWSそのものが破られたわけではありません。

攻撃は以下の流れで進みました。

Step 1：WAF（Web Application Firewall）の設定不備

攻撃者はWAFの設定ミスを悪用。

Step 2：SSRF攻撃（Server-Side Request Forgery）

内部メタデータサービスへアクセス。

Step 3：IAMロールの悪用

EC2インスタンスに付与されたIAMロールから一時的認証情報を取得。

Step 4：S3バケットへアクセス

権限が広く設定されていたため、大量データを取得。

3. 本質的な問題（Root Cause）

この事件の核心はここです。

❌ AWSが破られたわけではない

❌ 暗号技術が破られたわけでもない

✅ 原因は「設定」と「権限管理」

具体的には：

  1. WAF設定が不十分
  2. SSRF対策未実施
  3. IAMロールの権限過多
  4. S3アクセス制御の甘さ
  5. ログ監視体制の弱さ

つまり、クラウドの共有責任モデルの“顧客側責任領域”が破られたのです。

4. 構造的考察

この事件から見える構造は非常に重要です。

クラウド移行
    ↓
開発スピード重視
    ↓
利便性優先の広い権限設計
    ↓
内部リソースへの横展開
    ↓
大規模漏えい

問題は技術力ではありません。

「利便性を優先した設計思想」です。

5. なぜ検知が遅れたのか？

実は、ログは存在していました。

しかし：

  • ログのリアルタイム分析不足
  • 異常な大量データアクセスのアラート不備
  • 監視運用の未成熟

クラウドでは「ログがある」ことと「守れている」ことは別です。

6. 具体的対策（What should be done）

① 最小権限の徹底（Least Privilege）

IAMロールは：

  • 読み取り専用
  • 特定バケットのみ
  • IP制限付き

などに細分化すべきです。

② メタデータサービス保護

IMDSv2の使用（AWS推奨）
メタデータアクセスの制限

③ SSRF対策

  • 外部URL制限
  • ホワイトリスト方式採用
  • アプリ層でのURL検証

④ S3バケットの制限

  • Block Public Access強制
  • 組織ポリシー適用
  • 暗号化必須化

⑤ CloudTrailの常時監視

  • 大量取得アラート
  • 地理的異常アクセス検知
  • IAMロール利用状況分析

7. 経営的インパクト

Capital Oneは

  • 約8000万ドル以上の制裁金
  • ブランド毀損
  • 経営責任問題

クラウド侵害はIT問題ではありません。

経営リスクです。

8. DSCSS的結論

この事件から学ぶべき本質は：

クラウドは安全か？ではなく
設計思想は安全か？である。

クラウド侵害は偶発的事故ではなく、

「権限設計の思想の結果」

です。

9. 日本企業への示唆

日本企業でよくある状況：

  • とりあえずAdmin権限
  • IAM棚卸し未実施
  • セキュリティ専任不在
  • クラウド監査未経験

これは非常に危険です。

まとめ

Capital One事件は、

クラウドの危険性ではなく、
クラウド運用思想の危険性を示した事件

でした。

-侵害事例