S3（エス・スリー）の設定ミスで顧客情報が漏洩！？AWS利用企業が“必ず”確認したいこと

S3で情報漏洩が起きるとき、多くの場合に共通する「思い込み」があります。

「AWSが守ってくれているはず…」その思い込みが原因で起きた事故が、世界中にあります。

2019年、米国のCapital Oneではクレジットカードの申込データ1億件以上が漏洩しました。2018年には、FedExで12万件以上の顧客パスポートが誰でもダウンロードできる状態のまま放置されていたことが発覚。国内でも、大手自動車メーカーのグループ会社で約215万人分の顧客情報が、約9年5ヶ月にわたって公開状態になっていた事例があります。

いずれも、原因はAWS S3の設定ミスです。

AWSはサーバーやネットワークなどのクラウド基盤は守ってくれますが、「誰がデータにアクセスできるか」は利用者が設定しなければいけません。この仕組みを知らないまま使っていると、意図せず全世界にデータを公開してしまうことがあります。

この記事では、よくある設定ミスの3パターンと、今日から確認できる修正方法をわかりやすく解説します。

S3の設定ミスはなぜ起きる？

S3（Amazon Simple Storage Service）は、AWSが提供するクラウドのファイル置き場です。画像・文書・バックアップなど、あらゆるファイルをインターネット経由で保存・配信できます。

S3では「バケット」と呼ばれる専用の入れ物にファイルを保存します。バケットは用途ごとに分けて作るのが一般的で、たとえば「社内資料用」「顧客データ用」「バックアップ用」のように使い分けます。

保存したファイルにはURLが自動で発行され、そのURLを知っていれば誰でもアクセスできる状態になりえます。「外部からアクセスできないようにする」設定はAWSが自動でやってくれるものではなく、利用者が“自分で設定”しなければいけません。

イメージとしては、S3は『鍵のないロッカー』のようなものです。丈夫なロッカー自体はAmazonが作ってくれますが、鍵を閉めたか？は利用者が確認する必要があるというイメージですね。設定を間違えると、外から誰でも中身を見られる状態になります。

AWSはクラウドの基盤（ハードウェア・ソフトウェア・ネットワーク）を守り、利用者はデータとアクセス設定を守る、これを「責任共有モデル」と呼びます。詳しくは別記事「AWS 責任共有モデル とは」で解説しています。

関連記事

【AWSの基礎知識】「責任共有モデル」って何？セキュリティを“Amazonに一任”はダメな理由を解説！

「AWSのセキュリティって、AWSが全部守ってくれるんじゃないの？」 「クラウドサービスだから、セキュリティはAWS側が面倒を見てくれる」 そう思っていた場合、知っておいてほしいことがあります。AWSには「AWSが守る部分」と「自社が守る部分」が最初から決まっていて、設定ミスによる情報漏えいは、

S3でよくある設定ミス3パターン

S3の設定ミスには、やってしまいがちな代表的な3つのパターンがあります。

それぞれ「どんな設定が間違いか」「放置するとどうなるか」「どう修正するか」をセットで解説します。

①パブリックアクセスブロックが「OFFのまま」になっている

S3には「ブロックパブリックアクセス」という設定があります。外部からのアクセスをまとめてブロックするためのもので、4つのスイッチで構成されています。

確認すべき4つの設定項目はこちらです。

この4つがすべてONになっていないと、意図せず外部にファイルが公開されてしまうことがあります。

バケットを作るとき「デフォルトのまま進めた」という方は、まずここを確認してみてください。

この設定ミスで起きた実例：FedExでパスポート12万件がURLで全公開

FedExの事件では、12万件以上のパスポートや運転免許証がS3バケットに入ったまま、誰でもダウンロードできる状態で放置されていました。

URLさえ知っていれば世界中の誰からでもアクセスできる。そんな状態が長期間続いていたのです。

自社の顧客情報や人事データが同じ状態だったとしたら…決して他人事ではありませんよね。

②IAMで管理者権限を使い回している

IAMとは、AWSで「誰が何にアクセスできるか」を管理する仕組みです。

管理者権限（コンソール上の名称：AdministratorAccess）は、AWSのすべてのサービスに対してフルアクセスできる権限です。たとえるなら、社内のすべての部屋が開けられるマスターキーです。「とりあえずこの権限を渡しておけば何でもできるから楽」という理由で、チーム全員に渡してしまうケースは少なくありません。

しかしこれでは、1本でも外部に漏れたとき、すべてのデータが危険にさらされます。「楽だから」は、セキュリティの理由にはなりません。

この設定ミスで起きること：アカウント1件の流出でS3の全データが危険にさらされる

管理者権限を持つアカウントが侵害された場合、攻撃者はS3の全バケットのデータを読み取り・削除・書き換えることができます。S3上のデータをすべて暗号化してから身代金を要求する、ランサムウェアと同様の攻撃が実際に行われています。「メンバー間で共有しているアカウントの1つ」から、すべてのバケットが危険にさらされる可能性があります。

③CloudTrail・S3アクセスログをまったく設定していない

「とりあえず動いているからいい」と後回しにされがちなのが、ログの設定です。

ログとは、誰がいつどのファイルにアクセスしたかを記録する機能です。ログを設定していないと、何か問題が起きても原因を調べることができません。

設定しておきたいログは主に3つあります。

【設定ミスで起きた実例】9年5ヶ月、誰がアクセスしたか記録が残らなかった

先述のトヨタコネクティッドの事例では、約9年5ヶ月にわたってデータが外部から閲覧できる状態でした。しかしログが残っていなかったため、「いつから漏れていたか」「誰がアクセスしたか」「何件取得されたか」がまったくわからない状態になっています。

ログがなければ、何が起きたかを調べることも、同じことが起きないよう対策を打つことも難しくなります。

自社環境に残る細かいリスクはプロのAWS設定レビューを！

正直に言うと、今回紹介した3つのパターンはあくまで代表例です。実際のAWS環境には、これ以外にも設定を確認すべき箇所がたくさんあります。

たとえば、IAMの権限設定の組み合わせ次第では、ブロックパブリックアクセスをONにしていても一部のアクセスを許可してしまうケースがあります。複数のAWSアカウントをまたいだ権限管理や、一時的なアクセスURLの有効期限設定なども、自力での確認が難しい部分です。

「3つを確認した。でも本当にこれで十分か」という不安が残る場合は、第三者によるレビューが選択肢の一つです。

アイ・エフ・ティのAWS設定レビューサービスでは、専門エンジニアが管理画面から設定内容を確認し、改善すべき箇所をわかりやすいレポートでお渡しします。設定変更は一切行いませんので、業務への影響はありません。

また、診断の依頼から完了までの全体的な流れを知りたい方は「AWS脆弱性診断の進め方」の記事も参考にしてください。

関連記事

AWS脆弱性診断の流れ？システムは止まる？担当者が最初に知っておくべきことを解説！

「会社からAWS脆弱性診断をやるよう言われた。でも、そもそも何をする作業なのか…、調査中にシステムが止まったりしないのか、何を見られるのか…。」 そういった疑問を抱えたまま担当者になった方も多いはずです。 脆弱性診断という言葉自体は聞いたことがあっても、実際に何が起きるのかが分からないまま進める

まとめ：S3設定ミスを防ぐために今日できること

S3の設定ミスの多くは「AWSが守ってくれる」という思い込みから始まります。どこを自分で設定する必要があるかを把握することが、対策の出発点です。

今回紹介した3つのパターンは、AWSコンソールから設定を確認できる項目ばかりです。まずはご自身の環境を開き、OFFになっている設定があれば有効化してみてください。

ただし、IAM権限の組み合わせや複数アカウントにまたがる環境では、手動確認だけでは見落としが起きることもあります。「3つを確認したが、本当にこれで十分か」と感じたときが、専門家への相談のタイミングです。お気軽にご相談ください。