​​Визуальный вариант SSE-S3 шифрования для Amazon S3.

#security #S3 #пятничное

Меньше месяца до re:Invent 2021. Можно (нужно) делать прогнозы.

Amazon S3 - прогнозы

🔸 Глобальная S3 файловая система

Тренд на "мультирегиональность всего" для S3 в этом году уже вылился в фичу Amazon S3 Multi-Region Access Points. Что круто, хотя, понятно, и за (дополнительные) деньги.

Но что дальше? Что на счёт глобальной рапределённой глобальной файловой системы на базе S3?

Есть популярная s3fs, а недавно Яндекс выкатил сильно улучшенную по производительности GeeseFS на Go, полностью совместимую с Amazon S3. Чем ответит AWS?

🔸 S3 bucket Backup

Дальше, обещали бэкап для S3 бакетов — я ведь помню (потому что записываю)! 😁 Где он, спрашивается?! Давайте уже, сколько ж можно.

🔸 S3 bucket name - проблема уникальности

В прошлом году порешали, наконец, консистентность, которая с момента создания S3 создавала столько сложных вопросов при сдаче на AWS сертификацию.

Другая такая же застарелая проблема - уникальность имени бакетов. Уже есть и средства для решения (S3 Access Points), и прямо реальная очевидность проблемы в виде S3 Bucket Namesquatting, когда команде из AWS Security пришлось просить Ian Mckay вернуть им нужные для работы имена.

Можно ожидать её решения. Нужно закрывать столь застарелый technical debt.

===

А у вас какие прогнозы на re:Invent (и просто пожелания) по фичам для Amazon S3?

#S3 #reInvent

Как раз в продолжение темы предыдущего поста - советы по мультирегиональной репликация S3:

https://aws.amazon.com/blogs/storage/ten-tips-for-multi-tenant-multi-region-object-replication-in-amazon-s3/

This blog summarized the challenges ISV customers face when building a durable, scalable, and highly available data storage layer for their multi-tenant, multi-Region applications. Examples include the need to replicate data within and between AWS Regions and to reduce undifferentiated heavy lifting. 

#S3

​​AWS Backup для S3:

https://aws.amazon.com/blogs/aws/preview-aws-backup-adds-support-for-amazon-s3/

Добавление в ресурсы для бэкапа (Resource assignment) происходит обычным образом – перечислением конкретных (Include specific resources types), либо добавлением тэгов. При выборе через консоль конкретных бакетов, в списке будут лишь бакеты текущего региона.

Восстановить можно весь S3 бакет целиком, либо отдельные объекты. В какой-то конкретный бакет или создать новый. Можно изменить шифрование – использовать или нет.

Есть следующие опции восстановления:

• Restore time — point-in-time вариант восстановления за последние 35 дней
• Restore type — целиком бакет или выборочные файлы
• Restore destination — тот же (текущий) бакет, другой или создать новый в процессе восстановления
• Restored object encryption — восстанавливать с шифрованием или без, тем же ключом (по умолчанию) или другим

Пока это лишь preview и пока это лишь в регионе US West (Oregon) Region only.

#Backup #S3

​​S3 ACL отправили на пенсию (наконец-то):

https://aws.amazon.com/blogs/aws/new-simplify-access-management-for-data-stored-in-amazon-s3/

В прошлом году сначал разобрались с застарелой проблемой "чей же объект в бакете?" S3 Object Ownership. Сразу после добили, наконец, Strong Read-After-Write Consistency. Пришло время разобраться, "кто в бакете хозяин" — древние S3 ACL или новомодные (ага, уже 10 лет как!) IAM и S3 Bucket Policy.

И вот мощь S3 Object Ownership теперь выросла до возможности полностью игнорировать давно устаревшие S3 ACL. В результате теперь при создании бакета функционал S3 ACL по умолчанию выключен!

Жаль, конечно, что такое нельзя сделать с существующими бакетами, но то и понятно. В любом случае S3 ACL disabled сделает S3 бакеты безопаснее и проще в работе, т.к. не будет требовать знаний, как работал доступ к объектам в S3 15 лет назад.

В прошлом году спрашивал у Василия Пантюхина, когда же, наконец, задеприкейтят S3 ACL. И тут такой подарок под Новый Год. Низкий поклон команде Amazon S3 до самого бакета! 😀

#S3

​​S3 console — generating a presigned URL:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html#ShareObjectPreSignedURLConsole

The credentials that you can use to create a presigned URL include:

🔸 IAM instance profile: Valid up to 6 hours

🔸 STS: Valid up to 36 hours when signed with permanent credentials, such as the credentials of the AWS account root user or an IAM user

🔸 IAM user: Valid up to 7 days when using AWS Signature Version 4

#S3 #AWS_Console

​​S3 Replication vs AWS Datasync vs S3 Batch Operations vs S3 CopyObject API:

https://aws.amazon.com/blogs/storage/considering-four-different-replication-options-for-data-in-amazon-s3/

#S3

​​Replicate Existing Objects with S3 Batch Replication:

https://aws.amazon.com/blogs/aws/new-replicate-existing-objects-with-amazon-s3-batch-replication/

When to Use Amazon S3 Batch Replication
◻️ Replicate existing objects – use S3 Batch Replication to replicate objects that were added to the bucket before the replication rules were configured.
◻️ Replicate objects that previously failed to replicate – retry replicating objects that failed to replicate previously with the S3 Replication rules due to insufficient permissions or other reasons.
◻️ Replicate objects that were already replicated to another destination – you might need to store multiple copies of your data in separate AWS accounts or Regions. S3 Batch Replication can replicate objects that were already replicated to new destinations.
◻️ Replicate replicas of objects that were created from a replication rule – S3 Replication creates replicas of objects in destination buckets. Replicas of objects cannot be replicated again with live replication. These replica objects can only be replicated with S3 Batch Replication.

#S3 #Batch

S3 POST Policy:

https://apptrail.com/blog/2022/02/14/s3-post-policy

p.s. Link to official documentation:

https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-UsingHTTPPOST.html

#S3

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

​​S3 как container registry вместо ECR — в 5-8 раз быстрее и в 4 раза дешевле!

https://ochagavia.nl/blog/using-s3-as-a-container-registry/

#S3 #ECR