プログラマでありたい

おっさんになっても、プログラマでありつづけたい

Capital Oneの個人情報流出事件に思うこと

 2019年7月末に、米大手金融機関であるCapital Oneが不正アクセスによる1億人を超える個人情報の流出を発表しました。規模もさることながら、Capital OneはAWSから何度も事例に取り上げられるような先進的な企業だったので、個人的にかなり衝撃を受けました。また、攻撃手法についても、従来の単純な設定ミスを狙ったものではなく、より一歩踏み込んだ攻撃という印象を受けました。

攻撃手法


 攻撃手法については、piyologさんのSSRF攻撃によるCapital Oneの個人情報流出についてまとめてみたが非常に解りやすいので、まずはご参照してください。
piyolog.hatenadiary.jp

 攻撃手法を簡単にまとめると、WAFの脆弱性を利用してIAM Roleのクレデンシャル情報を取得し、それを手元から利用して情報を取得したという形です。piyologさんの図を、再描画させて貰いました。
f:id:dkfj:20190812151512p:plain

どうすれば良かったのか?


 情報流出の一次的な原因としては、WAFです。セキュリティ製品については、もう独自の運用でカバーできる範囲ではないので、AWS WAF等のマネージド・サービスもしくは、専門の会社が提供する製品を利用するのがあ良いでしょう。ただ、あくまでWAFについては一次的な原因で真の問題については、別のところにあると思います。それは、不用意に大きな権限を持ったIAM Roleを利用した点にあります。

 対策としては、2点考えられます。

IAM Role側の対策
  • 特定のS3 Bucketのみ接続できるようにする
  • 必要なアクション(例えばPut)のみ権限を付与する
S3 Bucket側の対策
  • Bucket Policyでec2 instanceが属するVPCからのみ接続できるように制限する

f:id:dkfj:20190812152706p:plain

 S3に格納する情報は、非常に重要なものが含まれるケースがあります。その場合、IAMポリシーのみの設定のみで防御するのは危険です。必ずBucket Policyでも制限を加えるべきです。Bucket Policyの制限は強力で、どのようなIAMの権限を与えていても、ポリシーに合致していないと見ることはできません。

悩ましい点


 上記の設定をすれば今回の事件は防げたと思います。一方で、IAM Roleを付与していたec2がgetとput両方の権限が必要であった場合、ec2からの操作で情報流出の可能性はあったでしょう。また、それ以前に全てのAWSの設定のうちで、1箇所だけ設定を間違っていただけで、このような甚大な被害が発生する可能性があるのです。Capital Oneがどれほどの規模のシステムか具体的に知りませんが、おそらくかなり巨大なシステムでしょう。AWSアカウントやIAMロール、S3バケットの数は無数にあると思います。上記のような個別防御の他に、様々な観点で防御する必要があるでしょうね。

感想と宣伝


 AWSのセキュリティを考える上で、IAMに対する理解はかなり重要です。ということで、IAMに特化した150ページほどの薄い本を2019年9月の技術書典7に出展予定です。上記のような設計の考え方、具体的なポリシーの実例をドドンと挙げています。出展については、こちらを参照してください。
 また書いているうちに確信したのですが、IAMの防御は基本だけどそれのみでは、もはや足りません。そのうちどこかで、その他のセキュリティについても書こうと思います。

f:id:dkfj:20190812161833p:plain

AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト

AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2019/04/20
  • メディア: 単行本
  • この商品を含むブログを見る
Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)