AWS Backup for S3:

https://aws.amazon.com/blogs/storage/automate-and-centrally-manage-data-protection-for-amazon-s3-with-aws-backup/

AWS Backup for Amazon S3 is now generally available in all commercial AWS Regions where AWS Backup is available.

#Backup #S3

Reduce encryption costs by using S3 Bucket Keys on existing objects:

https://aws.amazon.com/blogs/storage/reduce-encryption-costs-by-using-amazon-s3-bucket-keys-on-existing-objects/

In this blog, we’ve walked through the steps to implement S3 Bucket Keys for objects with different KMS keys within same bucket. By doing so, we were able to significantly reduce request traffic from S3 to KMS, decreasing KMS costs by 80 percent.

#S3 #KMS

Официальный клиент для монтирования S3 бакета в файловую систему — Mountpoint for Amazon S3

https://aws.amazon.com/blogs/storage/the-inside-story-on-mountpoint-for-amazon-s3-a-high-performance-open-source-file-client/

Отличия от других клиентов:

1️⃣ Использует те же библиотеки, что и AWS SDK
2️⃣ Написан на Rust
3️⃣ Автонастройка как для S3

Репозиторий:

GitHub 🔗 https://github.com/awslabs/mountpoint-s3
Roadmap 🔗 https://github.com/orgs/awslabs/projects/84

p.s. Альфа версия, у меня не заработало на ARM 😐 .

#S3

​​The illustrated guide to S3 pre-signed URLs:

https://fourtheorem.com/the-illustrated-guide-to-s3-pre-signed-urls/

🔹 S3 pre-signed URLs are a great way to authorize operation on S3.
🔸 They are generally used to implement upload and download functionality.
🔹 The signature is created client-side, so you can sign anything (even actions you don’t even have the right to perform).
🔸 AWS will validate at request time whether the request itself is still valid and not forged, but also that the credentials used for signing the request are actually authorized to perform the given action.
🔹 There are two different methods to perform uploads: PUT and POST. POST is more complex but also much more flexible. POST is less used in the wild, but you should consider using it!
🔸 S3 pre-signed URLs are not the only option and they come with their own set of tradeoffs. Always evaluate what’s the best solution for the problem at hand.

#S3

Что такое S3 DSSE-KMS:

https://aws.amazon.com/blogs/aws/new-amazon-s3-dual-layer-server-side-encryption-with-keys-stored-in-aws-key-management-service-dsse-kms/

На текущий момент для S3 объектов доступно 4 типа шифрования:

1️⃣ Server-side encryption with S3 managed keys (SSE-S3)
2️⃣ Server-side encryption with KMS (SSE-KMS)
3️⃣ Server-side encryption with customer-provided encryption keys (SSE-C)
4️⃣ Dual-layer server-side encryption with keys stored in KMS (DSSE-KMS)

Если упростить, то это SSE-S3 + SSE-KMS/SSE-C в одном флаконе. То есть 4️⃣ = 1️⃣ + 2️⃣ или 3️⃣.

Если чуть более подробней, то стоит глянуть официальный ролик «Announcing Amazon S3 dual-layer server-side encryption (DSSE-KMS)»:

https://www.youtube.com/watch?v=VtpyPqYke-w

Где есть табличка сравнения типов.
К сожалению, нужно делать поправку на то, что табличка слишком маркетинговая, нужно будет сделать свою.

Если же есть желание разобраться подробней, то вот первоисточник — Data-at-Rest Capability Package V5.0:

https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/capability-packages/(U)%20Data-at-Rest%20Capability%20Package%20v5.0.pdf

В котором описано ужесточение требований к шифрованию. В нём, в отличие от документа четвёртой версии, появляется понятие "двухуровновой" защиты:

«Data-at-Rest (DAR) Capability Packages (CP) version 5.0 enables customers to implement two independent layers of encryption for the purpose of providing protection for stored information on the End User Device or DAR protected system, while in a powered off or unauthenticated state.
This CP takes lessons learned from proof-of-concept demonstrations that have implemented the Commercial National Security Algorithm Suite, modes of operation, standards, and protocols.
These demonstrations included a layered use of Commercial Off-the-Shelf products for the protection of classified information.»

Из которого следует, что одного слоя шифрования теперь недостаточно. То есть нельзя просто зашифровать весь диск/раздел/файл криптостойким алгоритмом. Нужно реализовать такой подход дважды (и обязательно с разными кредами).

Если сравнивать это с ноутбуком, то требуется иметь шифрованный диск и вводить пароль при старте компьютера. А после при доступу к нужному файлу/диску ещё раз вводить (другой) пароль.

SSE-S3 в этом сравнении — AWS за нас каждый раз вводил такой пароль "при старте компьютера". Это, так называемое, "шифрование для галочки", которое лишь защищает от того, что накопители враги вдруг выкрадут из датацентра, а там всё зашифровано. В терминах DAR CP v.5 это "outer layer" — внешний уровень защиты.

SSE-KMS или SSE-C при таком раскладе это внутренний уровень защиты ("inner layer").

Раньше можно было включить или SSE-S3 (который нонче по дефолту) или SSE-KMS/SSE-C. А с помощью DSSE-KMS включаются и работают (под капотом) сразу два уровня — все объекты шифруются дважды.

Предположу, что из-за двойного шифрования скорость работы может снизиться, пока не видел упоминания про влияние на скорость работы.

По стоимости DSSE-KMS получается дороже, чем SSE-KMS/SSE-C, так как S3 bucket keys (кэширование KMS ключей на уровне S3 бакета) для этого типа недоступно (как минимум, пока).

#S3 #security

Mountpoint for Amazon S3 + caching

https://docs.aws.amazon.com/AmazonS3/latest/userguide/mountpoint-usage.html#mountpoint-caching

mount-s3 some-bucket ~/mnt --cache /local/path

More examples:

https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md#caching-configuration

#S3 #Mountpoint

​​📁stree — directory trees of S3

https://github.com/orangekame3/stree

#S3

Generate S3 presigned URL with S3 Transfer Acceleration

https://github.com/aws-samples/generate-s3-accelerate-presigned-url

▪️ APIGW
▪️ Lambda
▪️ Java 21
▪️ AWS SAM

#S3 #examples

It is not a bug, it is by design.

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

Essential reading for understanding S3 buckets:

https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/

🔹 S3 buckets are the S3 API
🔸 ListObjects is not the only way to get object keys
🔹 Incomplete multipart uploads are Schrodinger’s objects
🔸 Multipart upload listings leak return principal ARNs
🔹 Access control lists can grant access based on email
🔸 Storage class is uploader’s choice
🔹 Pretty much everything is uploader’s choice
🔸 S3 will tell you the bucket owner if you ask nicely
🔹 Keys are case sensitive
🔸 More ways to make a bucket public

#S3