空の S3 バケットにより AWS の請求額が爆発的に増加する仕組み | Maciej Pocwierz 著 | 2024年4月

希望のリージョンに空のプライベート AWS S3 バケットを作成すると想像してください。 翌朝の AWS の請求額はいくらになりますか?

数週間前、私はクライアント向けのドキュメント インデックス作成システムの PoC に取り組み始めました。 単一の S3 バケットを作成しました。 EU-西-1 リージョンにアクセスし、テストのためにいくつかのファイルをそこにアップロードしました。 2 日後、私は AWS の請求ページをチェックしました。主に、自分が行っていたことが無料利用枠の制限内に収まっていることを確認するためでした。 どうやらそうではありませんでした。 私の請求額は 1,300 ドルを超え、請求コンソールには、わずか 1 日以内に約 1 億件の S3 PUT リクエストが実行されたことが示されていました。

デフォルトでは、AWS は S3 バケットに対して実行されたリクエストをログに記録しません。 ただし、そのようなログは次のコマンドを使用して有効にすることができます。 AWS クラウドトレイル または S3 サーバーのアクセスログ。 CloudTrail ログを有効にした後、複数のアカウントまたは完全に AWS の外部から発信された数千の書き込みリクエストをすぐに観察しました。

しかし、なぜ一部のサードパーティが私の S3 バケットに不正なリクエストを大量に送信するのでしょうか?

私のアカウントに対する DDoS のような攻撃でしょうか? AWS に対抗しますか? それが判明したとして、 人気のあるオープンソース ツールの 1 つは、バックアップを S3 に保存するデフォルト構成を持っていました。 そして、バケット名のプレースホルダーとして、私がバケットに使用したのと同じ名前が使用されました。。 これは、デフォルトの構成値を使用したこのツールのすべてのデプロイメントが、そのバックアップを S3 バケットに保存しようとしたことを意味します。

注: 影響を受ける企業がデータ漏洩の危険にさらされる可能性があるため、私が言及しているツールの名前は開示できません (詳細は後述)。

そのため、設定を誤った多数のシステムがデータを私のプライベート S3 バケットに保存しようとしています。 しかし、なぜ私がこのミスの代償を払わなければならないのでしょうか？ その理由は次のとおりです。

これは AWS サポートとのやり取りで確認されました。 彼らは次のように書いています。

はい、S3 は不正なリクエスト (4xx) に対しても料金を請求します[1]。 それは予期された動作です。

したがって、今ターミナルを開いて次のように入力したとします。

aws s3 cp ./file.txt s3://your-bucket-name/random_key

私は アクセスが拒否されました エラーになりますが、そのリクエストの料金を支払うのはあなたです。 そのために AWS アカウントも必要ありません。

もう 1 つの質問が私を悩ませていました。請求額の半分以上がなぜ支払われているのかということです。 米国東部-1 地域？ そこにはバケツが1つもありませんでした！ それに対する答えは、 リージョンが指定されていない S3 リクエストはデフォルトで 米国東部-1 必要に応じてリダイレクトされます。 そして、バケットの所有者は、リダイレクトされたリクエストに対して追加料金を支払います。

私の S3 バケットが何百万ものリクエストで攻撃された理由と、最終的に S3 の請求額が高額になった理由がわかりました。 その時点で、私には検討したいアイデアがもう 1 つありました。 設定を誤ったシステムがすべて、データを S3 バケットにバックアップしようとしていたのであれば、なぜそのまま放置しておけばよいのでしょうか? バケットを公開書き込み用に開き、30 秒以内に 10 GB を超えるデータを収集しました。 もちろん、誰のデータだったのかは明かせません。 しかし、悪意のない構成の見落としが危険なデータ漏洩につながる可能性があることに私は驚きました。

レッスン 1: S3 バケットの名前を知っている人は誰でも、好きなように AWS の請求額を増やすことができます。

バケットを削除する以外に、これを防ぐ方法はありません。 S3 API を介して直接アクセスされている場合、CloudFront や WAF などのサービスでバケットを保護することはできません。 標準の S3 PUT リクエストの料金は、 1,000 リクエストあたり 0.005 ドルただし、1 台のマシンで 1 秒あたり数千件のそのようなリクエストを簡単に実行できます。

レッスン 2: バケット名にランダムなサフィックスを追加すると、セキュリティを強化できます。

これにより、システムの構成ミスや意図的な攻撃に対する脆弱性が軽減されます。 少なくとも、S3 バケットに短い一般的な名前を使用することは避けてください。

レッスン 3: S3 に対して大量のリクエストを実行する場合は、必ず AWS リージョンを明示的に指定してください。

こうすることで、S3 API リダイレクトによる追加コストを回避できます。

1. 私は調査結果を脆弱なオープンソース ツールの管理者に報告しました。 デフォルト構成はすぐに修正されましたが、既存の展開を修正することはできませんでした。
2. AWSセキュリティチームに通知しました。 私は、顧客を予期せぬ請求から守り、影響を受ける企業をデータ漏洩から守るために、残念な S3 バケット名を制限することを提案しました。 しかし、彼らはサードパーティ製品の設定ミスに対処することに消極的でした。
3. 私はこの問題を 2 つの会社に報告しました。そのデータがバケット内で見つかりました。 彼らは私の電子メールに応答しませんでした。おそらくスパムとみなされたのでしょう。
4. AWS は親切にも S3 の請求をキャンセルしてくれました。 ただし、これは例外的に行われたことを強調した。

私の投稿を読んでいただきありがとうございます。 予期せぬ AWS 請求を回避するのに役立つことを願っています。