AWSの重大な侵害事例とその防止方法
2023年6月7日
0 分で読めます2021年のクリスマスの数日前、予約スケジュールサービスFlexbookerの従業員と顧客は、脅威アクターが顧客ID情報1,000万件を持ち出したことに気づきました。情報には写真、運転免許証、ハッシュ化されたパスワードが含まれていました。
攻撃者は、個人を特定できる情報（PII）を数百万件持ち出しました。原因は、FlexbookerのAWSアカウント設定ミス、具体的には、内容が一般公開されていたAWS S3バケットでした。このAWS侵害は大きなニュースになりましたが、それは目新しい事例だったからではありません。Capital One、Twilio、UberなどもAWSを介した侵害を受けています。いずれのケースも、攻撃者がAWSそのものを侵害したのではなく、AWSの設定ミスを突いて企業に侵入しました。
こうした侵害は多岐にわたりますが、クラウドセキュリティの問題の根本原因はたいてい同じです。それは設定ミスです。クラウドセキュリティは責任共有モデルに基づいています。プロバイダーはインフラストラクチャを安全に整備しますが、すべての環境（本番環境だけでなく）でアプリケーションを安全にデプロイする責任は顧客にあります。多くの場合、デプロイされたアプリケーションやサービスの単純な設定ミスが、侵害につながる大きな隙を生み出します。
この記事では、過去数年間に設定ミスが原因で発生したAWSの重大なセキュリティ侵害事例を紹介し、より適切なセキュリティ対策によって侵害を防ぐ方法を解説します。
Capital One：ファイアウォールの設定ミスで1億人の顧客に影響
2019年7月、大手銀行・金融サービスプロバイダーのCapital Oneは、元Amazon社員がAWSサーバーに不正侵入したことを公表しました。
この攻撃は1億人を超える顧客に影響を及ぼし、社会保障番号、銀行口座番号、信用スコアなど、個人を特定できる情報が流出しました。Amazonは、AWSに過失はなく、基盤となるクラウドサービスも侵害されていないと明言しました。実際、Capital Oneが認めたように、ハッカーはオープンソースのWebアプリケーションファイアウォール（WAF）の設定ミスを利用してアクセスしていました。
顧客は集団訴訟を起こし、Capital Oneは和解に応じました。顧客には、請求1件あたり最大2万5,000ドルが支払われました。原告は、Capital Oneが「データ侵害を可能にした特定のセキュリティ上の脆弱性を認識していた」にもかかわらず、修正しなかったと主張しました。Capital Oneは訴訟への賛否を表明せず、「訴訟を継続する時間、費用、不確実性を避けるため」に和解すると述べました。
Pegasus Airlines：保護されていないS3バケットから6.5テラバイトのデータが流出
2022年5月、トルコの航空会社Pegasus Airlinesは、セキュリティ企業の調査により、AWS S3バケットの設定ミスが判明しました。このバケットには、飛行図、航法資料、多数の従業員の個人を特定できる情報など、機密性の高いフライトデータが保存されていました。
公開状態のS3バケットからは、同社のソースコードの一部も見つかりました。そこには平文のパスワードと秘密鍵が含まれており、攻撃者がこれらを利用して、さらに機密性の高いデータにアクセスできる可能性がありました。
セキュリティ企業は、合計で約2,300万件、約6.5テラバイトのファイルが公開されていることを確認しました。同社は「この情報漏えいは、世界中のPegasusの乗客と乗務員全員の安全に影響を及ぼす可能性がある」と指摘しました。
セキュリティ企業はPegasus Airlinesに通知しました。同社によると、「AWS S3バケットは速やかに保護され、その後PegasusEFBから通知への謝意を伝える返信がありました」とのことです。
Twilio：公開状態のS3バケットを悪用し、攻撃者が悪意あるコードを挿入
2020年7月、クラウド通信企業のTwilioは、攻撃者が設定ミスのあるS3バケットにアクセスし、同社のツールTaskRouterのJavaScript SDKを改ざんしたことを確認しました。
攻撃者は、TwilioのTaskRouter JS SDKライブラリをホストするS3バケットの設定ミスを悪用しました（TaskRouterはTwilioの顧客がタスクのルーティングに利用できるツールです）。攻撃を受けて改ざんされたライブラリは、ブラウザーに追加のURLを読み込ませるもので、後に悪名高いMagecart攻撃との関連が指摘されました。
Twilioは公表の中で、15分以内にインシデントに対処し、1時間後にはS3バケットを再設定したと説明しました。また、攻撃者は顧客データにも社内システムにもアクセスしていないと述べました。
Twilioは「AWS S3バケットの1つで、アクセス制御ポリシーを適切に設定できていませんでした」と率直に説明しました。同社がこの経路を実装した2015年当時、脆弱性はありませんでした。しかし数カ月後、問題のトラブルシューティング後に権限を「適切にリセット」できていなかったとTwilioは説明しています。
Uber：認証の弱さから秘密鍵が流出し、ハッカーがAWS S3データストアにアクセス。米国のドライバー60万人の記録が流出
ライドシェア企業のUberは2017年11月、2016年に攻撃者が5,000万人を超える乗客とドライバーの個人情報、および免許証番号を含む米国のドライバー60万人分の記録を盗んでいたことを公表しました。
Uberが多要素認証を有効にしていなかったため、攻撃者は同社のGitHubリポジトリにアクセスできました。セキュリティ対策が不十分だったこれらのリポジトリには重要なAWS認証情報が含まれており、攻撃者はそれを使ってUberのAWS S3データストアにアクセスしました。
Uberは、データを保護し、不正アクセスを遮断し、攻撃者にデータを削除させ、クラウドストレージアカウントの管理を強化したと説明しました。しかし後の報道によると、Uberは最初のハッキングをバグ報奨金プログラムの成功事例に偽装し、口止め料として攻撃者に10万ドルを支払っていました。
Imperva：AWS APIキーの流出により、攻撃者が顧客のメールアドレスとパスワードを含むデータベースにアクセス
2019年10月、サイバーセキュリティ企業Impervaは、攻撃者がAWSインスタンスの設定ミスを悪用して顧客データを盗んだことを公表しました。
ImpervaのCEOは、同社のAWSアカウントの1つで見つかった管理用APIキーを使って、攻撃者がメールアドレスとパスワードを含むデータベースのスナップショットにアクセスしたと説明しました。
ImpervaはAWSのセキュリティ侵害につながったミスを率直に説明し、顧客データの流出には次の4つの段階が関わったと明らかにしました。
ImpervaはAWSの評価中に、テスト用のデータベーススナップショットを作成しました。
Impervaは、AWS APIキーを含む社内のコンピューティングインスタンスを一般公開しました。
攻撃者はそのコンピューティングインスタンスを侵害し、AWS APIキーを盗みました。
攻撃者はAWS APIキーを使ってデータベーススナップショットにアクセスし、そこに含まれるすべてのデータを取得しました。
その後同社は、セキュリティアクセス制御の強化やアクセス監査の導入など、数々の是正措置を講じています。
AWSのデータ侵害から得られる3つの教訓
AWSのこうした侵害事例から学び、自社のAWS利用をより安全にするための教訓をいくつか紹介します。
環境を把握する：AWSの侵害の多くは設定ミスが原因です。環境をよく把握し、監査するほど、攻撃者に悪用される設定ミスが起きにくくなります。
開発者を支援する：設定ミスを見つけて修正するのに最適な立場にいるのは開発者です。開発者に安全な環境を構築するためのツールとガイダンスを提供すれば、AWSの侵害をより効果的に防げます。
予防とセキュアな設計を重視する：影響を受けた企業がセキュアな設計をより重視していれば、こうしたAWSの侵害の多くは防げたはずです。SnykのAWS脆弱性スキャンなどのツールを活用すれば、攻撃者に狙われる前に脆弱性を特定できます。SnykとAWSのセキュリティツールの連携方法はこちらをご覧ください。
クラウドセキュリティについて詳しく知りたい方は、電子書籍『クラウドセキュリティの5つの基本』をダウンロードしてください。SnykとAWSの連携について詳しく知りたい方は、AWSクイックスタートガイドをご覧ください。