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の防御は基本だけどそれのみでは、もはや足りません。そのうちどこかで、その他のセキュリティについても書こうと思います。

追記：上記の話を盛り込んだIAM本、書きました！！
BOOTHで電子書籍販売中！！
takuros.booth.pm