https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1
Краткое изложение — автор статьи в результате экспериментов получил счёт на 1000+ долларов за пустой (!) приватный (!) S3 бакет.
Прочитав документацию, он обнаружил, что всё верно, так может быть. Мало того, техподдержка подтвердила: да, это предполагаемое поведение — владелец бакета платит за обращения к нему, включая те, что дают ошибку аутентификации. То есть в том числе от анонимных пользователей (читай "через интернет").
И это только сейчас заметили?!?
Нет, на моей памяти раз в несколько лет эта тема поднимается. Например, вот свежее обсуждение на Reddit (2024):
https://www.reddit.com/r/aws/comments/1cg7ce8/how_an_empty_private_s3_bucket_can_make_your_bill/
А вот она же трёхлетней давности (2021):
https://www.reddit.com/r/aws/comments/mwpuys/exploitable_hole_in_s3_requester_pays_bucket_to/
Вот обобщение в виде Denial-of-Wallet attacks (2020):
https://portswigger.net/daily-swig/denial-of-wallet-attacks-how-to-protect-against-costly-exploits-targeting-serverless-setups
S3 Requester Pays
Кто сдавал на сертификацию :) знают про существование такого режима и даже предполагают, что его недавно сделали как раз для борьбы с подобными проблемами.
Нет, это древняя фича (2008):
https://aws.amazon.com/blogs/aws/bits-for-sale-amazon-s3-requester-payment-model/
Но главное, она не защитит от подобной проблемы, так как:
Bucket owner is charged for the request under the following conditions:
• Request authentication fails (HTTP code 403).
• The request is anonymous (HTTP code 403).
Как же защититься от этого?!?
◾ Можно генерировать длинные имена S3 бакетов из случайных символов (бесплатно)
◾ Использовать AWS Shield Advanced (3k$/month)
◾ Написать
<что угодно> в S3 bucket policy — не поможет (см. Request authentication fails)◾ Разрешить доступ только из своей VPC (см. предыдущий пункт)
◾ Добавить в Readme "Я тебя найду по айпи!!" (недорого)
В общем, рекомендация почитать книжку оказывается наиболее актуальной.
But why?!?
It is not a bug, it is by design.S3 — очень старый сервис, некоторые даже думают, первый (в реальности первый SQS). Когда его придумывали, не было проблемы с приватностью (этого добра всегда есть и будет в on-premise варианте), была обратная проблема — сделать публичным. По дизайну сервис S3 и, главное, S3 API — публичные. Это нужно зафиксировать.
Все объекты в бакете можно сделать публичными с помощью S3 ACL. Да, именно того, что лишь год назад был по дефолту выключен.
Концепция VPC , а после и понятие "приватные бакеты", появились существенно позже, в 2011-м году. То есть важно отметить, это больше "маркетинговое" название, ибо by design сами бакеты публичные или могут таким стать, а также уникальные (всегда можно определить наличие такого, просто попытавшись создать и получив ошибку, что имя "занято").
Короче, невозможно полностью и бесплатно защититься от Denial-of-Wallet attacks по определению.
И что, реально так всё плохо?
Нет. Стоит помнить — проблема была всегда. У AWS есть способы её детекта и разрешения, в том числе с помощью техподдержки. Случайно сгенерировать существенный биллинг непросто, т.к. это должны быть не миллионы. а миллиарды запросов. Плюс, конечно же, у вас обязательно должен быть настроен алерт на бюджет. :)
А как у других?
В Google:
Generally, you are not charged for operations that return 307, 4xx, or 5xx responses. The exception is 404 responses returned by buckets with Website Configuration enabled and the NotFoundPage property set to a public object in that bucket.
Итого, AWS есть, что улучшать. И публичное обсуждение старой архитектурной проблемы — отличный стимул.
#S3
