【実例あり】AWSの設定ミスで情報漏洩！？使用システムの脆弱性診断方法を解説！

「他社でAWSの情報漏洩事例を見て、うちは大丈夫だろうか」そう感じながら、“自社の設定”は確認できていますか？

AWSはセキュリティレベルの高いクラウドサービスですが、情報漏洩や不正アクセスの多くはAWS側の問題ではなく、利用者側の設定ミスが原因です。

実際に、ガートナー社の調査では「クラウドセキュリティ障害の99%は“利用者の過失”が原因になる」と指摘されており、この傾向は現在も続いています。

この記事では、被害の規模が分かる代表的な事例を3つ取り上げ、自社で今日から確認できる対策をIFTのセキュリティエンジニア（クラウド設定診断実績1,000件超）が監修して整理します。

前提知識：「AWSの情報漏洩」の大半は“設定ミス”が原因！

「AWSのような大きなクラウドサービスを使っていれば、セキュリティはAWS側が守ってくれるんでしょ？」そう思っている方は多いです。

しかし実際は、AWSと利用者の間には、「どこまでをAWSが守り、どこからを利用者が守るか」という分担されたルールがあるんです。

AWSが守るのは、

• データセンターの建物
• 物理サーバー
• ネットワークの基盤設備

これらの「利用者が触れない部分」に限定されます。

一方、利用者が管理しなければならないのは、「誰がどのデータにアクセスできるか」という権限の設定、ファイルを外部に公開するかどうかの設定、不審なアクセスを遮断するための設定などです。

クラウド上でどう使うかに関わる設定は、すべて“利用者の責任”になります。

マンションで例えるならば、建物の構造や共用部分の管理はマンション側の責任ですが、自室のドアに鍵をかけるかどうかは住人の責任ですよね。この「自室の鍵管理」を怠ることが、AWS上の情報漏洩につながります。

「専門担当者ではないし、確認の仕方がよく分からない」という方は少なくないですし、実際にこの誤解を持ったまま運用されているケースを現場で多く見てきました。意図せずリスクを抱えたまま運用している、というのは決して珍しいことではないのです。

AWSでよくある3つの設定ミス

AWSでよく起きる設定ミスには、主に3つのパターンがあります。

ミス1…ファイルを外部に公開してしまっている

AWSには「S3（Simple Storage Service）」と呼ばれる”クラウド上のファイル保管サービス”があり、書類・画像・データのバックアップなどを保存できる場所で、多くの企業が活用しています。

このS3には、「このファイルをインターネット上の誰でも見られるようにする」か「特定の人だけに限定する」かを設定できる機能があるのですが、この設定が誤って「誰でも見られる」状態になってしまうのが、報告例が多い設定ミスの一つです。

意図してそうしたわけではなくても、AWSの機能追加や設定変更の積み重ねで、気づかないうちに外部公開状態になるケースがあります。

ミス2…「管理者権限」が広すぎる

AWSには「IAM（Identity and Access Management）」と呼ばれる“アクセス権限管理の仕組み”があります。誰がどの機能を使えるかを一元管理している状態です。

本来は担当者ごとに必要な機能だけを割り当てるべきですが、現場では「とりあえず全部使えるようにしておこう！」という判断が積み重なりがちです。退職した社員のアカウントや使わなくなったシステムの認証情報が残ったまま放置されているケースも多くあります。

さらに、「2段階認証（MFA※）」が設定されていないと、パスワードが1つ漏れただけで不正アクセスが成立してしまいます。

※MFA：Multi-Factor Authentication / パスワードに加えてスマートフォンへの確認コードなど、複数の方法で本人確認を行う仕組み

ミス3…通信制御に“抜け穴”がある

AWSでは、外部からの不審なアクセスを遮断するための「通信制御」の設定が複数あります。「どのIPアドレス（通信の発信元）からの通信を許可するか」「どのポート（通信の入口）を開けるか」といった設定です。

これらの設定が緩すぎると、本来は内部にしか届かないはずの通信が外部から届いてしまったり、管理用のシステムが外部からアクセスできる状態になってしまいます。

Capital One事件（後述）でも、この通信制御の設定ミスが攻撃の入口になりました。

【被害実例】情報漏洩につながった3つのパターン

【事例1】トヨタ自動車の“クラウド設定ミス”事例（215万人の位置情報が約10年間公開状態に）

2023年5月、トヨタ自動車が公式に公表した国内事例です。

コネクティッドカーサービス（T-Connect・G-Linkなど）を管理するクラウドストレージで、外部からのアクセスを遮断する設定が機能しておらず、誰でもデータを参照できる状態が続いていました。

漏洩した可能性のあるのは、約215万人分の「車載端末ID」「車台番号」「車両の位置情報」「時刻」です。

最も深刻なのはその期間です。2013年11月から2023年4月まで、約9年半にわたって外部からアクセスできる状態が続いたこと。

日本を代表する大企業でも、約10年間設定ミスに気づかなかった…、「自社は大丈夫」という過信がいかに危険かを示す事例として、国内外のセキュリティレポートで繰り返し取り上げられています。

事例2：Uberのアクセスキー流出で5700万件が漏洩（制裁金約222億円に）

2016年、配車サービス大手のUberで、AWSにアクセスするための「鍵」が外部に漏れ、5700万人分の乗客・ドライバーの個人情報が盗まれました。

原因はIAMの管理ミスが「2つ」重なったことでした。

1つ目は、エンジニア全員が「何でもできる」管理者レベルの鍵を“1本だけ”共有して使いまわしていたこと。

2つ目は、コードを管理するシステム（GitHub）へのログインに2段階認証（MFA※）をかけていなかったこと。過去に別のサービスから流出したパスワードを使って攻撃者がログインし、コード内に書かれたAWSの鍵を見つけ出し、その鍵は全データへのアクセス権を持っていたため、手に入れた瞬間に「全部持ち出せる状態」になっていました。

Uberはアメリカの連邦当局から約222億円の制裁金を科され、 事件を1年以上隠していたセキュリティ担当役員が刑事訴追を受け、2022年に有罪判決が出ています。

事例3：設定ミスの連鎖で1億人超が漏洩した「Capital One事件」

2019年に発覚したCapital One（アメリカの大手銀行）の情報漏洩事件は、1億人以上の個人情報が漏洩した大規模な事件です。

この事件の教訓は、「1つの設定ミスではなく、複数の設定ミスが連鎖したことで大きな被害になった」 という点です。

攻撃の流れを整理すると、次のとおりです。

1. 外部からの通信を制御する設定に穴があり、攻撃者はシステムの内側に向けてリクエストを送り込める状態になっていました
2. その穴を使って、AWSのサーバーが内部的に保持している「他の機能を使うための合言葉」を取り出されました
3. その合言葉を使ってデータの保管場所（S3）に侵入し、顧客情報が大量に持ち出されました

「アメリカの大企業だから起きた特殊な話」ではありません。

攻撃に使われた設定項目（通信制御・権限管理・ファイル保管設定）は、AWSを使っている企業であれば規模を問わず必ず持っているものです。個別の設定が正しく見えていても、組み合わせてはじめてリスクが生まれる…、それがこの事件の示した現実です。

制裁金と集団訴訟の和解金を合わせると、Capital Oneが支払った金額は2億7,000万ドル超（約400億円超）にのぼっています。

【対策】今日から確認できる基本3つ

実例のような設定ミスへの対策として、まず確認しやすい3つのポイントを整理します。

「知識がないと難しいのでは」と思うかもしれませんが、ここで挙げるのはAWSコンソールから今すぐ確認できる基本です。

対策1：必要な人に／必要な権限だけ渡す！

AWSの操作権限は、「業務上必要な機能だけを使えるよう」各担当者に設定します。

社員証で例えると『全フロアに入れる社員証より、必要なフロアだけに入れる社員証のほうがリスクが低い』というイメージです。

「とりあえず全部使える権限」を付与するのは、不正アクセスがあったときの被害を大きくする原因になりますので、退職した社員のアカウントや、使わなくなったシステムの認証情報は定期的に削除・無効化する習慣をつけておきましょう！

対策2：パスワードだけに頼らない「2段階認証」を設定する！

ミス2で触れたMFAは、設定の手間に比べて効果が大きい対策です。

Microsoftの調査では、MFAを設定したアカウントの侵害率は全体の0.1%未満とされています。パスワードが1つ漏れても、不正ログインを大幅に防げます。

AWSにアクセスするすべてのアカウントにMFAを設定しておきましょう！

対策3：ファイルが外部に公開されていないか確認する！

S3に保存しているファイルが「誰でもアクセスできる」状態になっていないか、定期的に確認します。

確認すべきポイントは2つです。

• S3の「パブリックアクセスブロック」設定がオンになっているか
• 特定の相手以外にアクセスを許可する設定が残っていないか

ただし、これら2点はあくまで「基本の確認」で、AWSには他にも操作ログの記録設定・通信制御の設定など、設定ミスのリスクがある箇所が多数あります。3点だけ見ていても、他の箇所でリスクが蓄積していることがあります。

まとめ：AWS設定ミスへの対策は基本確認から始めよう！

AWSの設定ミスは、S3の公開設定・IAMの権限管理・通信制御の3パターンが、情報漏洩や不正アクセスの主な原因になっています。

本記事でも紹介したように、AWSは非常に便利なシステムな反面、1つの設定ミスが企業の信頼低下に繋がってしまいます。

当社IFTの脆弱性診断では、このようなシステムの抜け穴を確認するのはもちろん、ホワイトハッカーは実際に起きた被害事例をもとにハッキングテスト（実際に攻撃）を行う『ペネトレーションテスト』も実施可能です。

またテスト後の報告はもちろん、「どこを／どう直せばいいか？」というレポートもお出ししておりますので、システム担当者にレポートを共有するだけでOK。

“もしも”への備えとして、定期的な確認を推奨しています。セキュリティに関するどんな些細な質問でも構いませんので、ぜひ一度ご相談くださいませ。