Облачные хранилища данных: блочные, файловые и объектные

К этой теме приложение «Заметки» уже умеет хранить данные. В теме 5 база PostgreSQL получила Docker-том, переживающий пересоздание контейнера; в теме 8 тот же PostgreSQL переехал в StatefulSet с постоянным томом, который Kubernetes запрашивает у хранилища через PersistentVolumeClaim и драйвер CSI. Там же появились режимы доступа ReadWriteOnce и ReadWriteMany, но вопрос, почему один том можно смонтировать на многих узлах, а другой — только на одном, остался без ответа: Kubernetes лишь передаёт пожелание драйверу, а возможности определяются устройством хранилища за ним.

Открытыми остаются и практические вопросы. Куда положить вложения заметок — фотографии и документы, которые пользователи загружают через браузер, — чтобы их не терять при отказе узла и не раздувать базу? Где хранить ночные резервные копии базы так, чтобы их не смог удалить злоумышленник, получивший доступ к кластеру? Где OpenTofu из темы 9 держит файл состояния и как организована его блокировка? Куда Loki из темы 12 складывает сжатые журналы? Ответ во всех четырёх случаях один — в объектное хранилище с интерфейсом S3. Этот интерфейс не похож ни на диск, ни на файловую систему, и чтобы пользоваться им правильно, нужно понимать его модель.

Изложение построено так. Первый раздел сравнивает три модели доступа к данным — блочную, файловую и объектную — и показывает, где в каждой находится файловая система и что из этого следует для совместного доступа. Второй раздел объясняет, как хранилище переживает отказы дисков: репликацией или кодами стирания, — с расчётом накладных расходов. Третий раздел разбирает S3 как протокол поверх HTTP: модель данных, сырой запрос, подпись SigV4 и presigned URL. Четвёртый посвящён жизни объекта: версиям и маркерам удаления, правилам жизненного цикла, составной загрузке и согласованности. Пятый — доступу и защите: политикам бакета, блокировке публичного доступа, шифрованию и Object Lock. Шестой собирает вопросы эксплуатации: классы хранения и стоимость, использование S3 из Kubernetes, ограничения и типичные ошибки. Учебный сервер S3 в лабораторной работе — RustFS 1.0.3; выводы команд версионирования, политик, presigned URL и составной загрузки в тексте получены на нём с клиентом AWS CLI v2.

Три модели доступа к данным

Блочное устройство: диск без смысла

Блочное устройство (англ. block device) — хранилище, которое предоставляет клиенту пронумерованный массив блоков фиксированного размера и две операции: прочитать блок с номером N и записать блок с номером N. Номер называется логическим адресом блока (англ. logical block address, LBA), размер блока исторически 512 байт, у современных дисков — 4 КиБ. Устройство ничего не знает о файлах, каталогах и правах: для него запись в блок 8 391 000 ничем не отличается от записи в блок 0. Смысл байтам придаёт файловая система — ext4, XFS, NTFS, — которая работает в ядре клиентской операционной системы и сама решает, в каких блоках лежат индексные дескрипторы, журнал и данные файлов.

Сетевое блочное хранилище сохраняет этот интерфейс, но переносит блоки на удалённые серверы. Виртуальная машина видит обычный диск /dev/vdb через паравиртуальный драйвер virtio-blk (тема 2), а гипервизор пересылает операции по сети в систему хранения. Другие способы доставки блочного протокола — iSCSI (команды SCSI поверх TCP), NVMe over Fabrics и собственные протоколы распределённых систем, например RBD (англ. RADOS Block Device) в Ceph. В Ceph блочный том разрезан на объекты по 4 МиБ, которые распределяются по серверам кластера алгоритмом CRUSH и реплицируются ²; клиенту же по-прежнему показан непрерывный диск. Облачные диски — Amazon EBS, диски Yandex Compute Cloud, тома OpenStack Cinder — устроены по той же схеме.

Главное следствие блочной модели касается совместного доступа. Файловая система кеширует метаданные и данные в памяти своего ядра, ведёт журнал и предполагает, что больше никто не меняет блоки под ней. Если один и тот же том смонтировать с ext4 на двух машинах на запись, каждая будет перезаписывать блоки, не зная о кеше и журнале другой, и файловая система разрушится — без какой-либо ошибки со стороны хранилища, которое честно выполняет все записи. Поэтому облачный диск подключается к одной виртуальной машине, а в Kubernetes такой том имеет режим ReadWriteOnce (тема 8). Существуют кластерные файловые системы (GFS2, OCFS2), которые координируют доступ нескольких узлов к одному блочному устройству через распределённый менеджер блокировок, но это отдельный класс программ, а не свойство блочного хранилища.

Достоинство блочной модели — минимум посредников. Операция fsync в PostgreSQL превращается в запись нескольких блоков и команду сброса кеша устройства; транзакционная база рассчитывает именно на такой путь: частичная перезапись страницы в 8 КиБ посреди файла данных, точный порядок записей журнала, предсказуемая задержка. Поэтому база «Заметок» живёт на блочном томе.

Файловое хранилище: общая файловая система по сети

Файловое хранилище (англ. file storage) переносит файловую систему на сервер. Клиент монтирует удалённый каталог и выполняет обычные системные вызовы — open, read, write, rename, flock, — а клиент сетевой файловой системы в ядре превращает их в запросы протокола: NFS (англ. Network File System) в мире Unix, SMB в мире Windows. Сервер хранит каталоги, имена, права и блокировки и потому может обслуживать много клиентов одновременно: это и есть режим ReadWriteMany. Распределённые файловые системы — CephFS, Amazon EFS — выносят метаданные на отдельные серверы метаданных, а данные раскладывают по узлам хранения, но для клиента остаются той же файловой системой ².

Ценность файловой модели — семантика POSIX (англ. Portable Operating System Interface): иерархия каталогов, частичная перезапись файла по смещению, дозапись в конец, атомарное переименование и консультативные блокировки. Атомарный rename — основа множества приёмов: программа пишет новую версию конфигурации во временный файл и переименовывает его поверх старого, и любой читатель видит либо старый файл целиком, либо новый. Блокировки позволяют двум процессам на разных узлах не писать в один файл одновременно. NFS версии 4 встраивает блокировки в протокол и связывает их с арендой (англ. lease): сервер считает блокировку живой, пока клиент периодически продлевает аренду, и освобождает её, если клиент пропал ⁴.

Полную семантику локальной файловой системы сетевая всё же не даёт. Клиенты NFS кешируют данные, и стандарт гарантирует согласованность «закрыть — открыть» (англ. close-to-open): изменения, сделанные одним клиентом, гарантированно видны другому, если первый закрыл файл, а второй открыл его после этого ⁴. Два процесса на разных узлах, одновременно держащие файл открытым, могут видеть разное содержимое. Каждая операция с метаданными — проверка существования файла, чтение атрибутов, создание — превращается в сетевой запрос, поэтому приложения, создающие миллионы мелких файлов, на сетевой файловой системе работают на порядки медленнее, чем на локальной.

Когда режим RWX действительно нужен? Когда несколько экземпляров приложения обязаны работать с одним деревом файлов именно как с файлами: унаследованная CMS, которая пишет загрузки пользователей в каталог uploads/; конвейер обработки, в котором стороннее ПО читает и пишет файлы по путям; общая домашняя директория пользователей вычислительного кластера. Если же приложение пишется заново и файловая семантика ему не нужна — как backend «Заметок», которому достаточно «сохранить вложение» и «отдать вложение», — общая файловая система добавляет единую точку отказа и масштабируется хуже объектного хранилища.

Объектное хранилище: ключ, байты, метаданные, HTTP

Объектное хранилище (англ. object storage) отказывается и от блоков, и от файловой системы. Единица хранения — объект (англ. object): последовательность байтов произвольного размера вместе с метаданными, адресуемая строковым ключом (англ. key) внутри бакета (англ. bucket) — именованного контейнера объектов. Операции выполняются над объектом целиком и передаются по HTTP: PUT записывает объект, GET читает его (возможно, диапазон байтов), HEAD возвращает метаданные, DELETE удаляет. Изменить десять байтов в середине объекта нельзя: можно только записать объект заново. Нет и каталогов: ключ att/2026/10/42.jpg — одна строка, а косые черты в ней ничего не создают.

Строение объекта показано на рисунке ниже. Кроме байтов данных у объекта есть системные метаданные (Content-Type, Content-Length, Last-Modified, ETag — идентификатор содержимого), пользовательские метаданные в заголовках x-amz-meta-* и, если в бакете включено версионирование, идентификатор версии.

Отказ от файловой семантики — не недостаток, а цена масштабирования. Объект неизменяем после записи, поэтому его можно разрезать на части и разложить по сотням серверов, не заботясь о том, что кто-то перепишет середину. Нет иерархии каталогов — нет и узкого места в виде сервера метаданных, который должен атомарно переименовывать поддеревья. Нет открытых файлов и блокировок — сервер не хранит состояние клиента между запросами, и любой запрос можно направить на любой экземпляр шлюза. Протокол HTTP проходит через балансировщики, прокси и сети доставки контента и понятен браузеру: картинку из бакета можно показать на странице прямой ссылкой. Де-факто стандартом интерфейса стал API Amazon S3 (англ. Simple Storage Service), который реализуют и публичные облака, и открытые серверы ⁵.

Сравнение моделей и выбор для «Заметок»

Рисунок ниже показывает путь запроса в трёх моделях. Главное различие — где находится файловая система. В блочной модели она на клиенте, и потому том принадлежит одному узлу. В файловой — на сервере, и узлов может быть много, но каждый вызов становится сетевым запросом с семантикой, близкой к POSIX. В объектной файловой системы нет вовсе: приложение через библиотеку (SDK) формирует HTTP-запросы, а шлюз хранилища проверяет подпись и права, находит объект по ключу и обращается к узлам данных.

Таблица намеренно не содержит абсолютных чисел задержки: они зависят от реализации, сети, размера объекта и нагрузки, и любые «типичные» значения без условий измерения вводят в заблуждение. В лабораторной работе латентность PUT и GET мелких объектов на учебном сервере измеряется и сравнивается с записью и чтением локальных файлов; порядок разницы — несколько сотен раз для чтения из кеша страниц — виден сразу.

Для «Заметок» выбор получается естественным. PostgreSQL остаётся на блочном томе ReadWriteOnce: ему нужны частичная перезапись и fsync. Вложения уходят в объектное хранилище: бакет notes-att, ключ вида att/<id заметки>/<имя файла>, ссылка на ключ — в строке таблицы заметок. Резервные копии базы, получаемые pg_dump, складываются в тот же или отдельный бакет с префиксом backups/. Общая файловая система не нужна вовсе.

Как хранилище переживает отказы дисков

Репликация

Любое хранилище, рассчитанное на годы работы, должно пережить отказ дисков и серверов: при тысячах дисков в кластере отказ какого-то из них — ежедневное событие. Простейший способ — репликация (англ. replication): каждый блок или объект хранится в r полных копиях на разных дисках, а лучше — на разных серверах и стойках. Запись подтверждается, когда её сохранили все копии или их кворум; чтение может обслужить любая копия; после отказа диска система копирует недостающие реплики с уцелевших на новые места ¹².

Ceph по умолчанию использует три копии, как и большинство распределённых систем. Тройная репликация переживает потерю любых двух копий, но обходится дорого: на каждый терабайт полезных данных расходуется три терабайта дисков, накладные расходы — 200 %. Для базы данных, где важны задержка записи и скорость восстановления, эта цена оправдана. Для петабайтов вложений и резервных копий — нет: здесь решающим становится коэффициент расхода дискового пространства.

Коды стирания

Код стирания (англ. erasure code) делит объект на k фрагментов данных и вычисляет по ним m фрагментов чётности так, что объект восстанавливается по любым k из k+m фрагментов. Классический пример — коды Рида — Соломона, построенные на арифметике конечных полей ³; простейший частный случай с m = 1 — чётность XOR в RAID 5. Фрагменты раскладываются по k+m разным дискам, а лучше по разным серверам, и система переживает потерю любых m из них. Схему обозначают «k+m»: 4+2, 8+3, 10+4.

Коэффициент расхода пространства (сколько байтов на дисках приходится на байт данных) и доля избыточности равны

\text{коэффициент} = \frac{k+m}{k}, \qquad \text{избыточность} = \frac{m}{k}.

Рассмотрим объект размером 1 МиБ в схеме 4+2. Он режется на четыре фрагмента данных D1–D4 по 256 КиБ; кодер вычисляет два фрагмента чётности P1 и P2 по 256 КиБ; шесть фрагментов записываются на шесть узлов. На дисках занято 6 \cdot 256 КиБ = 1{,}5 МиБ, коэффициент \frac{4+2}{4} = 1{,}5, избыточность 50 %. Если отказали узлы с D2 и P1, оставшиеся D1, D3, D4 и P2 — четыре фрагмента — достаточны, чтобы декодер вычислил D2 и отдал объект целиком. Рисунок ниже показывает именно эту ситуацию. Тройная репликация того же объекта заняла бы 3 МиБ и пережила бы те же два отказа: при равной устойчивости коды стирания расходуют вдвое меньше дисков.

Из таблицы видно, что число переживаемых отказов определяется только m, а не долей дисков. Утверждение «коды стирания переживают потерю половины дисков» верно лишь для схем с m = k (2+2, 4+4); схема 12+4 теряет данные при отказе пяти узлов из шестнадцати, то есть менее трети. Рост k при фиксированном m снижает коэффициент, но увеличивает число узлов, которые должны участвовать в каждой операции.

Цена кодов стирания: восстановление, мелкие объекты, домены отказа

Экономия дискового пространства оплачивается тремя способами. Первый — стоимость восстановления. При репликации потерянная копия восстанавливается чтением одной уцелевшей копии того же размера. При коде Рида — Соломона, чтобы заново вычислить один потерянный фрагмент, нужно прочитать k фрагментов: в схеме 4+2 восстановление 256 КиБ требует чтения 1 МиБ по сети, в схеме 10+4 — в десять раз больше данных, чем восстанавливается. После отказа сервера с десятками терабайт такой трафик заметно нагружает сеть кластера; ради его снижения разработаны локально восстанавливаемые коды, в которых часть чётности вычисляется по небольшим группам фрагментов.

Второй — мелкие объекты и задержка. Объект в 4 КиБ в схеме 4+2 превращается в шесть фрагментов по килобайту на шести дисках: шесть операций ввода-вывода и шесть наборов метаданных вместо одной записи. Чтение требует ответа k узлов, и задержку определяет самый медленный из них. Поэтому реализации хранят мелкие объекты иначе: встраивают данные прямо в файл метаданных объекта или реплицируют их. В RustFS, например, каждый объект на диске — каталог с файлом xl.meta, и у небольших объектов, судя по составу каталога, отдельных файлов данных нет. Для блочных томов с их мелкими случайными записями коды стирания тоже менее удобны, чем для объектов, записываемых целиком; Ceph поддерживает оба типа пулов и позволяет выбирать по назначению ².

Третий — домены отказа (англ. failure domains). Схема 4+2 переживает два отказа, только если шесть фрагментов лежат в шести независимых местах. Если два фрагмента оказались на двух дисках одного сервера, отказ блока питания этого сервера стоит сразу двух «отказов» из бюджета. Поэтому распределённые системы раскладывают фрагменты по иерархии «диск — сервер — стойка — зона доступности»: правила CRUSH в Ceph описывают эту иерархию явно ². Amazon заявляет для S3 Standard проектную долговечность 99,999999999 % и хранение данных минимум в трёх зонах доступности региона ⁵; это свойство организации хранения, а не одной схемы кодирования. Учебный сервер в лабораторной работе работает на одном каталоге одного диска и не переживает ни одного отказа: он воспроизводит интерфейс S3, а не его надёжность. При запуске RustFS на нескольких дисках (например, четырёх томах) он объединяет их в набор стирания (англ. erasure set) и раскладывает фрагменты объектов по ним.

S3: модель данных и протокол

Бакеты, ключи и префиксы

Пространство имён S3 двухуровневое. Бакет имеет имя длиной от 3 до 63 символов из строчных латинских букв, цифр, точек и дефисов; в AWS имя уникально во всём разделе облака, поэтому notes-att почти наверняка уже кем-то занят и в реальных системах в имя добавляют суффикс организации или аккаунта ⁵. Ключ объекта — произвольная строка UTF-8 длиной до 1024 байтов. Пользовательские метаданные ограничены 2 КБ на объект и задаются при записи; изменить их без перезаписи объекта нельзя — даже метаданные копируются операцией CopyObject в новый объект.

Иерархия «папок», которую показывают веб-консоли, — иллюзия, построенная операцией листинга. ListObjectsV2 с параметром prefix=att/ возвращает ключи, начинающиеся с этой строки, а с параметром delimiter=/ сворачивает всё, что после следующей косой черты, в «общие префиксы» (англ. common prefixes). Вывод ниже показан схематично и сокращён:

aws s3api list-objects-v2 --bucket notes-att --prefix att/ --delimiter /

{
    "Contents": [
        { "Key": "att/readme.txt", "Size": 120, ... }
    ],
    "CommonPrefixes": [
        { "Prefix": "att/41/" },
        { "Prefix": "att/42/" }
    ],
    "KeyCount": 3,
    ...
}

Префиксов att/41/ и att/42/ как сущностей нет: они вычислены из ключей att/41/a.png, att/42/b.pdf и исчезнут, когда будут удалены последние такие объекты. «Переименовать папку» в S3 означает скопировать каждый объект под новым ключом и удалить старый — операция не атомарна и стоит два запроса на каждый объект. Листинг возвращает не более 1000 ключей за запрос, остальное — через маркер продолжения, поэтому подсчёт объектов в бакете с миллионами ключей — тысячи запросов.

Ключ входит и в масштабирование. AWS документирует производительность в расчёте на префикс: не менее 3500 запросов PUT/COPY/POST/DELETE и 5500 запросов GET/HEAD в секунду на каждый префикс, причём число префиксов не ограничено ⁵. Нагрузку, которая упирается в этот предел, распределяют по нескольким префиксам.

Бакет адресуется двумя способами. В адресации path-style (англ. path-style) имя бакета — первая часть пути: http://127.0.0.1:9000/notes-att/att/42/b.pdf. В адресации virtual-hosted-style (англ. virtual-hosted-style) имя бакета — часть имени хоста: https://notes-att.s3.us-east-1.amazonaws.com/att/42/b.pdf. AWS считает основной вторую и объявила о планах прекратить поддержку path-style ⁵; S3-совместимые серверы, наоборот, по умолчанию понимают path-style, а для virtual-hosted-style им нужно знать собственное доменное имя и иметь DNS-записи вида *.s3.example.com. Расхождение стилей адресации — частая причина ошибки NoSuchBucket при подключении SDK к собственному серверу; ему посвящена одна из частей лабораторной работы.

Сырой HTTP-запрос и подпись SigV4

Каждая операция S3 — один HTTP-запрос. Запись объекта att/n.txt с телом из трёх байтов v2\n в бакет notes-att выглядит так (заголовки сокращены до значимых):

PUT /notes-att/att/n.txt HTTP/1.1
Host: 127.0.0.1:9000
Content-Length: 3
X-Amz-Date: 20261021T210642Z
X-Amz-Content-SHA256: 81db67b6a5702b9b68f0016f061c409bf3fb16d062fc854d1b424bb4e9c28c56
Authorization: AWS4-HMAC-SHA256 Credential=lab10admin/20261021/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=e5a5fc49733bde62070262cb4f529f285058fb94b6163e8c07511d77f88515e5

v2

HTTP/1.1 200 OK
ETag: "e30260020baeb0398ff07b37dd33ed16"
x-amz-version-id: a92d97c0-6e89-4432-bf08-86e977285e33
x-amz-request-id: ...
Content-Length: 0

ETag здесь — MD5 трёх байтов тела в шестнадцатеричной записи; для объектов, записанных одним PUT без шифрования ключом KMS, это верно и в AWS, но в общем случае ETag — непрозрачный идентификатор содержимого, а не контрольная сумма (для составной загрузки он вычисляется иначе, см. ниже). Заголовок x-amz-version-id появляется, когда в бакете включено версионирование.

Самое интересное в запросе — заголовок Authorization. Секретный ключ по сети не передаётся. Клиент и сервер оба знают пару «идентификатор ключа доступа — секретный ключ» (здесь lab10admin и секрет учебного стенда), клиент вычисляет по запросу подпись HMAC-SHA256, а сервер, получив запрос, повторяет вычисление своей копией секрета и сравнивает результаты. Алгоритм называется Signature Version 4, SigV4 ⁷. Он состоит из четырёх шагов.

Шаг 1 — канонический запрос (англ. canonical request): запрос приводится к однозначной текстовой форме, чтобы клиент и сервер хешировали одну и ту же строку. Это шесть строк: метод, путь в URL-кодировке, отсортированные параметры запроса (здесь их нет — пустая строка), канонические заголовки (имена в нижнем регистре, отсортированы, каждый с переводом строки), список подписанных заголовков и SHA-256 тела:

PUT
/notes-att/att/n.txt

host:127.0.0.1:9000
x-amz-content-sha256:81db67b6a5702b9b68f0016f061c409bf3fb16d062fc854d1b424bb4e9c28c56
x-amz-date:20261021T210642Z

host;x-amz-content-sha256;x-amz-date
81db67b6a5702b9b68f0016f061c409bf3fb16d062fc854d1b424bb4e9c28c56

Шаг 2 — строка для подписи (англ. string to sign): название алгоритма, время запроса, область действия (англ. credential scope) «дата/регион/сервис/aws4_request» и SHA-256 канонического запроса:

AWS4-HMAC-SHA256
20261021T210642Z
20261021/us-east-1/s3/aws4_request
58f5245dc5122a9ef42619c160526b863fa5d57e5e2638413153679ae9dea20a

Шаг 3 — ключ подписи (англ. signing key) выводится из секрета цепочкой HMAC, каждое звено которой сужает область действия:

kDate    = HMAC-SHA256("AWS4" + секрет, "20261021")
kRegion  = HMAC-SHA256(kDate,    "us-east-1")
kService = HMAC-SHA256(kRegion,  "s3")
kSigning = HMAC-SHA256(kService, "aws4_request")

Шаг 4 — подпись: Signature = hex(HMAC-SHA256(kSigning, строка для подписи)). Она вместе с идентификатором ключа, областью действия и списком подписанных заголовков помещается в Authorization.

Каждый элемент конструкции защищает от конкретной атаки. Хеш тела в каноническом запросе не позволяет подменить данные при неизменных заголовках. Подписанный Host не позволяет переслать запрос на другой сервер или в другой бакет при virtual-hosted-style. Время запроса не позволяет бесконечно воспроизводить перехваченный запрос: AWS отклоняет запросы, время которых расходится со временем сервера больше чем на 15 минут, с ошибкой RequestTimeTooSkewed ⁷. Поэтому неверно выставленные часы клиента — классическая причина отказа всех запросов к S3 при правильных ключах. Цепочка HMAC позволяет серверу кешировать производный ключ на сутки и регион, не храня секрет в каждом сервисе. Подпись можно вычислить без каких-либо библиотек AWS — скрипт sigv4_manual.py из окружения лабораторной работы делает это на стандартной библиотеке Python и проверяет себя на примере из документации Amazon S3.

Тело запроса не обязательно хешировать заранее: для больших потоков SDK используют либо значение UNSIGNED-PAYLOAD в x-amz-content-sha256 (целостность тогда обеспечивают TLS и контрольные суммы), либо потоковую подпись по кускам. Современные версии AWS CLI и SDK вдобавок по умолчанию передают контрольную сумму тела в заголовке x-amz-checksum-crc64nvme; сервер, не знающий этого заголовка, может отвечать ошибкой — с этим сталкиваются старые S3-совместимые реализации.

Presigned URL

Подпись не обязана находиться в заголовке. Если все её компоненты перенести в параметры запроса, получится presigned URL — заранее подписанная ссылка, которая разрешает одну конкретную операцию над одним объектом до заданного момента. Владелец ключа выпускает ссылку локально, без обращения к серверу:

aws s3 presign s3://notes-att/att/private.txt --expires-in 300

http://127.0.0.1:9000/notes-att/att/private.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=lab10admin%2F20261021%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20261021T210842Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=...

В подпись входят метод, путь, все параметры X-Amz-*, кроме самой подписи, и заголовок Host; тело не хешируется (UNSIGNED-PAYLOAD). Получатель ссылки выполняет обычный GET (или PUT, если ссылка выпущена для записи) без каких-либо ключей, а сервер проверяет подпись, срок X-Amz-Date + X-Amz-Expires и права того, кто подписал. На учебном сервере изменение одного символа ключа объекта, срока или подписи даёт 403 SignatureDoesNotMatch, истечение срока — 403 AccessDenied с сообщением Request has expired, а срок больше 604 800 секунд — 400 AuthorizationQueryParametersError: в AWS presigned URL с подписью SigV4 действителен не более 7 суток ⁵.

Схема на рисунке ниже показывает типичное применение в «Заметках». Браузер не получает ключей S3 и не передаёт файл через backend. Он просит backend разрешить загрузку; backend проверяет права пользователя, выбирает ключ объекта и выпускает presigned URL для PUT на несколько минут; браузер загружает файл прямо в хранилище. Backend не тратит память и сеть на пересылку мегабайтов, а хранилище получает только разрешённую операцию над заранее выбранным ключом.

У presigned URL есть свойства, которые нужно учитывать. Это токен на предъявителя: любой, кто получил ссылку (из журнала прокси, истории браузера, переписки), может воспользоваться ею до истечения срока. Отдельную ссылку нельзя отозвать: она не хранится на сервере. Прекратить её действие можно только лишив прав того, кто её подписал, или сменив его ключ — что отзовёт сразу все выпущенные им ссылки. Если ссылка подписана временными учётными данными (тема 11), она перестаёт работать, когда истекают эти учётные данные, даже если её собственный срок ещё не прошёл. Отсюда практика: короткие сроки (минуты для загрузки, часы для скачивания), отдельная учётная запись с минимальными правами для подписи ссылок и ключи объектов, которые нельзя угадать.

S3-совместимые серверы и судьба MinIO

Интерфейс S3 реализуют многие системы, и слово «совместимый» в их описании означает разное. Ceph RGW — шлюз S3 и Swift поверх распределённого хранилища RADOS, промышленная система для больших кластеров. SeaweedFS — распределённая файловая система с S3-шлюзом. Garage — лёгкий геораспределённый сервер, который по собственной таблице совместимости не поддерживает версионирование и политики бакета. versitygw — шлюз, отображающий S3 на обычный POSIX-каталог. RustFS — сервер на Rust под лицензией Apache-2.0 с версионированием, правилами жизненного цикла, Object Lock и кодами стирания. Перед выбором сервера нужно сверить таблицу поддерживаемых операций с тем, что требуется приложению: «S3-совместимый» без версионирования не годится для резервных копий, которые должны переживать удаление.

Долгое время стандартным выбором для учебных стендов и локальной разработки был MinIO. Ситуация изменилась в 2025–2026 годах. 15 октября 2025 года README репозитория объявил, что community-редакция распространяется только в исходных кодах, без готовых исполняемых файлов и образов; 3 декабря 2025 года проект переведён в режим сопровождения; в феврале 2026 года README сообщает, что репозиторий больше не сопровождается, и предлагает коммерческие продукты компании ¹³. На октябрь 2026 года репозитории minio/minio и клиента minio/mc находятся в архиве, а образы minio/minio и minio/mc на Docker Hub недоступны. Многие руководства и примеры в интернете по-прежнему начинаются с docker run minio/minio; они перестали работать, и это наглядный пример того, почему зависимость от одного поставщика открытого ПО — риск, который стоит учитывать при выборе инфраструктуры. В курсе используется RustFS 1.0.3 с клиентами AWS CLI v2 и boto3, которые не привязаны к конкретному серверу.

Жизнь объекта: версии, жизненный цикл, составная загрузка, согласованность

Версионирование и маркеры удаления

Без версионирования PUT по существующему ключу безвозвратно заменяет объект, а DELETE безвозвратно удаляет его. Версионирование (англ. versioning) включается на уровне бакета и меняет обе операции ⁵. Каждый PUT создаёт новую версию с уникальным идентификатором VersionId, старые версии сохраняются. DELETE без указания версии ничего не удаляет: он добавляет поверх стека версий маркер удаления (англ. delete marker) — особую версию без тела. Обычный GET по ключу, текущая версия которого — маркер, возвращает 404 Not Found с заголовком x-amz-delete-marker: true, и объект выглядит удалённым. DELETE с параметром versionId удаляет конкретную версию навсегда — в том числе и сам маркер.

Отсюда способ восстановить «удалённый» объект: найти маркер удаления и удалить его по идентификатору версии. Текущей снова станет предыдущая версия. На учебном сервере последовательность из двух PUT и DELETE выглядит так:

aws s3api delete-object --bucket notes-att --key att/n.txt
aws s3api list-object-versions --bucket notes-att --prefix att/n.txt

{
    "DeleteMarker": true,
    "VersionId": "1b990464-80ab-49f8-afd0-5a7daa659d52"
}
{
    "Versions": [
        { "Key": "att/n.txt", "VersionId": "a92d97c0-6e89-4432-bf08-86e977285e33", "IsLatest": false, "Size": 3, ... },
        { "Key": "att/n.txt", "VersionId": "16e7d32e-cab2-4239-95c6-c4c645f426e2", "IsLatest": false, "Size": 3, ... }
    ],
    "DeleteMarkers": [
        { "Key": "att/n.txt", "VersionId": "1b990464-80ab-49f8-afd0-5a7daa659d52", "IsLatest": true, ... }
    ]
}

Маркер имеет IsLatest: true, обе версии данных на месте. После aws s3api delete-object --bucket notes-att --key att/n.txt --version-id 1b990464-... обычный GET снова возвращает версию a92d97c0-... с содержимым v2. Временная шкала на рисунке ниже показывает тот же сценарий.

У бакета три состояния версионирования: не включено, включено (Enabled) и приостановлено (Suspended). Вернуть бакет в состояние «не включено» нельзя; приостановка прекращает создание новых версий, но сохраняет существующие. В AWS после первого включения версионирования изменение может распространяться по системе до 15 минут, и в это время записи могут вести себя как в неверсионированном бакете ⁵. Каждая версия хранится и оплачивается как отдельный объект: файл в 100 МБ, перезаписанный сто раз, занимает 10 ГБ. Поэтому версионирование почти всегда сопровождается правилом жизненного цикла, удаляющим неактуальные версии.

Правила жизненного цикла

Правила жизненного цикла (англ. lifecycle rules) — конфигурация бакета, по которой хранилище само удаляет объекты или переводит их в другой класс хранения в зависимости от возраста ⁸. Правило выбирает объекты фильтром (префикс ключа, теги, размер) и содержит одно или несколько действий:

• Expiration — удалить текущую версию через N дней после создания (в версионированном бакете — добавить маркер удаления);
• Transition — перевести объект в другой класс хранения через N дней;
• NoncurrentVersionExpiration — окончательно удалить версию через N дней после того, как она перестала быть текущей;
• AbortIncompleteMultipartUpload — прервать составную загрузку, не завершённую за N дней, и удалить её части;
• флаг ExpiredObjectDeleteMarker в действии Expiration — удалить маркер удаления, под которым не осталось версий.

Конфигурация для бакета вложений «Заметок» из лабораторной работы: неактуальные версии вложений хранятся сутки, временные объекты в tmp/ удаляются через сутки, незавершённые загрузки прерываются через сутки.

{
  "Rules": [
    { "ID": "expire-noncurrent-attachments", "Status": "Enabled",
      "Filter": { "Prefix": "att/" },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 1 } },
    { "ID": "expire-tmp", "Status": "Enabled",
      "Filter": { "Prefix": "tmp/" },
      "Expiration": { "Days": 1 } },
    { "ID": "abort-incomplete-mpu", "Status": "Enabled",
      "Filter": { "Prefix": "" },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 1 } }
  ]
}

aws s3api put-bucket-lifecycle-configuration --bucket notes-att \
    --lifecycle-configuration file://policies/lifecycle.json
aws s3api get-bucket-lifecycle-configuration --bucket notes-att

Важно понимать, когда правило срабатывает. Хранилище не ставит таймер на каждый объект: фоновый процесс периодически просматривает объекты и ставит подходящие в очередь на асинхронное выполнение. AWS отсчитывает дни от создания объекта и округляет момент срабатывания до ближайшей следующей полуночи по UTC, а между наступлением срока и фактическим удалением возможна задержка; за хранение уже просроченного объекта плата не взимается ⁸. Наименьшая единица срока — сутки, поэтому в рамках одной лабораторной работы увидеть удаление нельзя: проверяемым результатом становится то, что сервер принял правила и возвращает их без искажений. Наблюдение за срабатыванием — задача на следующий день.

Составная загрузка

Загрузка большого объекта одним PUT плоха по трём причинам: обрыв соединения на 99 % требует начинать сначала, одно TCP-соединение плохо использует широкий канал, а размер данных надо знать заранее (заголовок Content-Length). Составная загрузка (англ. multipart upload) решает все три проблемы ⁵. Клиент вызывает CreateMultipartUpload и получает идентификатор загрузки UploadId; затем загружает части (англ. parts) запросами UploadPart с номерами от 1 до 10 000 — независимо, в любом порядке, параллельно, с повтором только неудавшихся; в конце вызывает CompleteMultipartUpload со списком номеров и ETag частей, и сервер собирает из них объект. AbortMultipartUpload отменяет загрузку и удаляет части.

Максимальный размер объекта вырос в декабре 2025 года: до этого он составлял 5 ТиБ, и это значение до сих пор встречается в книгах и статьях ⁶. Нынешний предел — прямое следствие двух других: 10\,000 \times 5 ГиБ = 50\,000 ГиБ \approx 48{,}8 ТиБ. Обратный расчёт полезен на практике: при минимальной части 5 МиБ наибольший объект составит 10\,000 \times 5 МиБ \approx 48{,}8 ГиБ, поэтому для резервной копии в 1 ТиБ часть должна быть не меньше \frac{1\,048\,576 \text{ МиБ}}{10\,000} \approx 105 МиБ. Утилиты (aws s3 cp, менеджеры передачи в SDK) подбирают размер части сами; при ручной загрузке через s3api или собственный код это забота программиста. AWS рекомендует переходить на составную загрузку с объектов от 100 МБ — это рекомендация, а не правило ⁵.

ETag объекта после составной загрузки — не MD5 содержимого. Он вычисляется как MD5 от склеенных двоичных MD5 всех частей с суффиксом «-число частей». Для файла в 12 МиБ, загруженного частями 5 + 5 + 2 МиБ, учебный сервер вернул "12fe8e66682a0511b94a7f4cb257cbc5-3", и то же значение получается локально:

split -b 5M -d big.bin part.
for f in part.0*; do md5sum "$f" | cut -c1-32; done | xxd -r -p | md5sum

12fe8e66682a0511b94a7f4cb257cbc5  -

Отсюда два следствия: сравнивать ETag с md5sum файла можно только для простых загрузок, а один и тот же файл, загруженный с разным размером частей, получит разные ETag. Части незавершённых загрузок не видны в листинге объектов, но занимают место и оплачиваются; найти их можно командой aws s3api list-multipart-uploads, а убирать — правилом AbortIncompleteMultipartUpload.

Согласованность чтения после записи

Распределённое хранилище, раскладывающее данные и индекс ключей по многим серверам, может отвечать на чтение по устаревшей копии индекса. До декабря 2020 года Amazon S3 давал согласованность в конечном счёте (англ. eventual consistency) для перезаписи и удаления: после успешного PUT по существующему ключу GET некоторое время мог возвращать старое содержимое, а только что удалённый объект — появляться в листинге. Приложения обходили это записью под уникальными ключами и внешними индексами. 1 декабря 2020 года AWS объявила строгую согласованность чтения после записи (англ. strong read-after-write consistency) для всех операций PUT и DELETE с объектами во всех регионах без изменения цены и производительности ¹¹: после успешного ответа на запись любой последующий GET, HEAD и LIST видит её результат ⁵.

Строгая согласованность отдельной операции не означает транзакций. Два клиента, одновременно записывающие объект под одним ключом, не получат ошибки: побеждает последняя запись (в версионированном бакете сохранятся обе версии). Механизма блокировки объекта в S3 нет; есть условная запись: заголовок If-None-Match: * в PUT заставляет сервер отказать, если объект уже существует, а If-Match с ETag — если объект изменился после того, как клиент его прочитал ⁵. Именно условная запись позволила OpenTofu отказаться от отдельной таблицы блокировок: с параметром use_lockfile бэкенд создаёт файл блокировки рядом с состоянием (тема 9). Конфигурация самого бакета — политики, правила жизненного цикла, настройка версионирования — в AWS распространяется с задержкой, о чём сказано выше. S3-совместимые серверы реализуют согласованность по-своему, и обещание AWS на них автоматически не переносится: свойство нужно проверять по документации конкретного сервера.

Доступ и защита данных

Политика бакета и порядок её вычисления

Подпись SigV4 устанавливает, кто выполняет запрос, — это аутентификация. Решение, можно ли ему это сделать, принимает авторизация, и в S3 её основной инструмент — политики в формате JSON, подробно разбираемые в теме 11. Политика бакета (англ. bucket policy) прикрепляется к самому бакету и может давать права в том числе анонимным клиентам. Политика из лабораторной работы разрешает всем читать объекты под префиксом public/:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadOfPublicPrefix",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::notes-att/public/*"
    }
  ]
}

Поле Principal: "*" означает «любой, включая неаутентифицированных», Action — разрешённую операцию API, Resource — ARN объектов (у бакета и объектов разные ARN: arn:aws:s3:::notes-att и arn:aws:s3:::notes-att/*, и действие s3:ListBucket относится к первому). Вычисление следует общему правилу IAM: по умолчанию всё запрещено (неявный запрет), явное Allow разрешает, явное Deny побеждает любое Allow. На учебном сервере с этой политикой анонимный curl к public/h.txt получает 200, а к att/private.txt, к листингу бакета и анонимный PUT в public/ — 403 AccessDenied: политика разрешила ровно одно действие на одном префиксе.

Явный запрет полезен для обязательных требований. Например, правило с "Effect": "Deny", "Action": "s3:*" и условием "Bool": { "aws:SecureTransport": "false" } отвергает любые запросы к бакету по незашифрованному HTTP, кто бы их ни подписал.

Кроме политик у S3 есть списки управления доступом (англ. access control lists, ACL) — механизм первых лет сервиса, в котором права задаются на каждом объекте отдельно и принадлежат загрузившему его аккаунту. Совмещение ACL и политик затрудняет ответ на вопрос «кто имеет доступ к этому объекту». С апреля 2023 года новые бакеты в AWS по умолчанию создаются с отключёнными ACL (владелец бакета владеет всеми объектами), и AWS рекомендует управлять доступом только политиками ⁵.

Блокировка публичного доступа

Утечки данных из бакетов, открытых на чтение всем, — один из самых частых инцидентов облачной безопасности: достаточно одной ошибочной строки "Principal": "*" с "Resource": "arn:aws:s3:::bucket/*". Блокировка публичного доступа (англ. Block Public Access) — набор из четырёх флагов на уровне бакета или всего аккаунта, которые перекрывают политики и ACL ⁵:

Новые бакеты в AWS создаются со всеми четырьмя флагами. Блокировка работает как предохранитель уровнем выше: даже если кто-то по ошибке напишет публичную политику, она не подействует, пока блокировку явно не снимут. На учебном сервере после установки флагов анонимный запрос к public/h.txt, только что отдававшийся со статусом 200, получает 403, хотя политика осталась прежней. Правильная схема для «Заметок» — держать блокировку включённой, а публичную раздачу картинок, если она нужна, выполнять через presigned URL или сеть доставки контента с собственной идентичностью доступа к бакету.

Шифрование на стороне сервера и на стороне клиента

Шифрование данных в состоянии покоя (англ. encryption at rest) в S3 выполняется на стороне сервера (англ. server-side encryption, SSE) в одном из трёх вариантов, различающихся тем, кто управляет ключами ¹⁰:

• SSE-S3 — сервис шифрует каждый объект ключом, которым полностью управляет сам (AES-256). С 5 января 2023 года в AWS это шифрование применяется ко всем новым объектам автоматически и бесплатно. Защищает от утечки физических дисков, но не от того, кто имеет право на s3:GetObject: расшифровка выполняется прозрачно для любого авторизованного запроса;
• SSE-KMS — ключ объекта шифруется ключом из сервиса управления ключами (англ. Key Management Service, KMS), то есть применяется конвертное шифрование (англ. envelope encryption). Чтобы прочитать объект, нужно право не только на s3:GetObject, но и на kms:Decrypt для этого ключа; каждое использование ключа записывается в журнал аудита. Это вторая, независимая граница доступа, но и дополнительные запросы к KMS с их ценой и лимитами;
• SSE-C — клиент передаёт ключ шифрования в заголовках каждого запроса, сервер шифрует им данные и забывает ключ, сохраняя лишь его хеш для проверки. Потеря ключа означает потерю данных; передавать ключ можно только по HTTPS.

Шифрование на стороне клиента (англ. client-side encryption) — четвёртый вариант: приложение шифрует данные до отправки, и хранилище никогда не видит открытого текста. Это единственный вариант, защищающий от компрометации самого поставщика хранения, но он лишает сервер возможности что-либо делать с содержимым и перекладывает управление ключами на приложение.

Важно точно понимать, от чего шифрование на стороне сервера не защищает. Если утёк ключ доступа backend «Заметок», злоумышленник читает вложения через обычный API, и SSE-S3 расшифрует их для него так же услужливо, как для backend. Защитой от этого служат узкие политики, короткоживущие учётные данные (тема 11) и, для SSE-KMS, отдельные права на ключ.

Object Lock и защита резервных копий

Версионирование защищает от случайного удаления, но не от намеренного: тот, у кого есть право s3:DeleteObjectVersion, удалит все версии. Сценарий атаки программ-вымогателей на облачную инфраструктуру выглядит именно так: получив ключи администратора, злоумышленник сначала удаляет резервные копии, затем шифрует или удаляет основные данные. Object Lock — механизм хранения по модели WORM (англ. write once, read many), запрещающий удалять и перезаписывать версию объекта до заданной даты ⁹. Он работает только в версионированном бакете и защищает конкретную версию: новые версии и маркеры удаления поверх неё создавать можно, но защищённую версию удалить нельзя.

Срок хранения (англ. retention period) задаётся для версии явно или по умолчанию для всего бакета и действует в одном из двух режимов. В режиме управления (англ. governance mode) пользователи с особым правом s3:BypassGovernanceRetention могут снять защиту, передав заголовок обхода; режим удобен для проверки настроек. В режиме соответствия (англ. compliance mode) удалить версию до истечения срока не может никто, включая администратора аккаунта, а срок можно только продлевать. Отдельно существует юридическое удержание (англ. legal hold) — защита без срока, действующая до явного снятия. Документация AWS описывает также переменный срок, отсчитываемый от события.

Для «Заметок» отсюда следует схема резервного копирования: ночной pg_dump записывается в отдельный бакет с Object Lock в режиме соответствия на 30 дней, учётная запись, которая пишет копии, имеет право только на s3:PutObject, а правило жизненного цикла удаляет версии старше срока хранения. Даже полный захват кластера и ключей backend не позволит уничтожить копии последних 30 дней. Цена — невозможность удалить данные раньше срока, в том числе по ошибке записанные; поэтому режим соответствия включают после проверки настроек в режиме управления.

Эксплуатация: стоимость, Kubernetes, ограничения

Классы хранения и расчёт стоимости

Счёт за объектное хранилище в публичном облаке складывается из трёх частей: хранение (за гигабайт в месяц), запросы (за тысячу операций) и исходящий трафик в интернет (за гигабайт). Классы хранения (англ. storage classes) меняют соотношение между ними: чем дешевле хранение, тем дороже обращение и тем дольше минимальный оплачиваемый срок. Цены ниже взяты из прайс-листа AWS для региона us-east-1 (публикация 15.10.2026) ¹⁴; в других регионах и у других поставщиков они иные, но структура та же.

Числовой пример. Вложения «Заметок» занимают 1024 ГБ, средний объект — 256 КиБ. За месяц пользователи загружают 500 000 вложений и скачивают 2 000 000, все скачивания идут в интернет: 2\,000\,000 \times 256 КиБ \approx 488 ГБ трафика. Исходящий трафик стоит 0,09 долл./ГБ для первых 10 ТБ (бесплатный ежемесячный объём не учитываем). Для класса Standard в долларах США:

\begin{aligned} \text{хранение} &= 1024 \times 0{,}023 = 23{,}55 \\ \text{PUT} &= 500 \times 0{,}005 = 2{,}50 \\ \text{GET} &= 2000 \times 0{,}0004 = 0{,}80 \\ \text{трафик} &= 488 \times 0{,}09 = 43{,}95 \\ \text{итого в месяц} &\approx 70{,}80. \end{aligned}

Для Standard-IA хранение дешевле (1024 \times 0{,}0125 = 12{,}80), но запросы дороже (5{,}00 + 2{,}00) и добавляется плата за извлечение (488 \times 0{,}01 = 4{,}88); с тем же трафиком итог около 68,63 долл. Выводы из расчёта важнее чисел. Во-первых, для данных, которые активно скачивают, главная статья расхода — исходящий трафик (62 % счёта), и выбор класса хранения меняет итог лишь на несколько процентов; экономить здесь нужно кешированием и сетью доставки контента. Во-вторых, «холодный» класс выгоден только для действительно холодных данных: если бы те же вложения скачивали десять раз в месяц, плата за извлечение в Standard-IA превысила бы экономию на хранении. Для резервных копий картина обратная: терабайт копий в Standard стоит 23,55 долл. в месяц, в Glacier Instant Retrieval — 4,10 долл., а извлекаются они только при восстановлении. Перевод копий в холодный класс через 7–30 дней — типичное правило Transition. В-третьих, миллионы мелких объектов дороги не хранением, а запросами: миллион объектов по 1 КБ занимает около гигабайта (2–3 цента в месяц), а их однократная запись стоит 5 долл.

У собственного S3-совместимого сервера структура затрат другая: оплачиваются диски с учётом коэффициента кодирования из второго раздела, серверы, сеть и труд эксплуатации, а запросы и трафик внутри своей сети бесплатны. Сравнение «своё против облака» без учёта этих статей некорректно.

S3 в Kubernetes: SDK против монтирования

Приложение в Kubernetes обращается к S3 так же, как вне кластера: через SDK по HTTPS. Конфигурацию — адрес сервера, имя бакета, регион — передают через ConfigMap, а учётные данные либо через Secret (тема 8), либо, что лучше, через идентичность нагрузки: в облаке под получает короткоживущие учётные данные, привязанные к его ServiceAccount, и статический ключ не нужен вовсе (тема 11). Для backend «Заметок» это выглядит как несколько переменных окружения и вызовы put_object, get_object и generate_presigned_url в коде.

Соблазнительная альтернатива — смонтировать бакет как каталог и оставить приложение работать с файлами. Для этого есть FUSE-драйверы: s3fs-fuse, Mountpoint for Amazon S3, драйверы CSI на их основе. Но монтирование не превращает объектное хранилище в файловое; оно лишь переводит системные вызовы в запросы S3, и всё, чего нет в модели S3, либо эмулируется дорого, либо не поддерживается. Документация Mountpoint формулирует это прямо ¹²: запись поддерживается только в новые файлы, последовательно с начала (перезапись существующего файла — только с отдельным флагом и усечением до нуля), файл становится виден другим клиентам только после закрытия; дозапись и переименование работают лишь для особого класса S3 Express One Zone; каталоги нельзя удалять и переименовывать; жёстких и символических ссылок нет; права chmod/chown не меняются; операции, которые нельзя выполнить эффективно, завершаются ошибкой ввода-вывода. s3fs-fuse идёт другим путём и эмулирует больше — например, частичную запись через загрузку и повторную выгрузку всего объекта, переименование через копирование и удаление, — но эти операции неатомарны, медленны и не согласованы между несколькими клиентами.

Отсюда простое правило. Монтирование уместно для неизменяемых данных, которые читаются последовательно большими кусками приложением, не умеющим работать с S3: обучающие наборы данных, архивы журналов для анализа, медиафайлы для перекодирования. Монтирование — ошибка для всего, что рассчитывает на семантику POSIX. База данных на смонтированном бакете не работает: PostgreSQL перезаписывает страницы по 8 КиБ в середине файлов данных, дописывает журнал WAL и вызывает fsync, а каждая такая операция превратилась бы в перезапись многомегабайтного объекта или ошибку. Именно поэтому СУБД нельзя развернуть прямо поверх S3 без промежуточного слоя: даже системы, хранящие данные в объектном хранилище (Loki из темы 12, Thanos, аналитические движки), пишут туда неизменяемые блоки целиком и держат изменяемое состояние на локальном диске. Резервные копии базы в S3 — правильное решение; база на S3 — нет.

Ограничения и типичные ошибки интерпретации

Модель S3 проста, и именно поэтому её часто понимают по аналогии с файловой системой, а аналогия подводит. Ниже собраны ошибки, которые встречаются чаще всего.

«В бакете есть папки». Есть только ключи. Пустую «папку» веб-консоли создают объектом нулевого размера с ключом, оканчивающимся на /; переименование «папки» — копирование и удаление каждого объекта; права на «папку» — политика на префикс ключей.

«Объект можно дописать или поправить». Нельзя: любое изменение — запись объекта целиком. Журнал, в который приложение пишет строку за строкой, хранят локально и выгружают в S3 готовыми блоками.

«Версионирование — это резервная копия». Версии живут в том же бакете и том же аккаунте и удаляются правом s3:DeleteObjectVersion; удаление бакета или аккаунта уносит их вместе с данными. Защиту от злонамеренного удаления дают Object Lock, репликация в другой аккаунт и раздельные учётные записи.

«Правило жизненного цикла сработает сразу». Правило выполняется фоновым процессом с точностью до суток, и между сроком и удалением возможна задержка. Для удаления «через пять минут» оно не предназначено.

«Presigned URL можно отозвать». Отдельную ссылку — нельзя: только лишить прав или ключа того, кто её подписал, вместе со всеми остальными его ссылками. Срок должен быть коротким с самого начала.

«Шифрование на стороне сервера защищает от утечки ключей доступа». Не защищает: сервер расшифровывает данные для любого авторизованного запроса. От утечки ключей защищают узкие политики, короткоживущие учётные данные и отдельные права на ключ KMS.

«ETag — это MD5 файла». Только для объектов, загруженных одним PUT без SSE-KMS. После составной загрузки ETag зависит от размера частей.

«Коды стирания переживают потерю половины дисков». Схема k+m переживает ровно m отказов в разных доменах отказа; доля дисков зависит от соотношения k и m.

«S3-совместимый — значит, совместимый во всём». Реализации различаются набором операций (версионирование, политики, Object Lock, условная запись), стилем адресации по умолчанию, поддержкой новых заголовков контрольных сумм и гарантиями согласованности. Перед выбором сервера и при обновлении SDK нужна проверка именно тех операций, на которые рассчитывает приложение.

«Объектное хранилище медленное» или «быстрое». Задержка одной операции определяется HTTP-запросом, подписью, поиском ключа и сетью и заметно выше, чем у локального диска; суммарная пропускная способность параллельных запросов к многим ключам может быть очень высокой. Без указания операции, размера объекта, степени параллелизма и условий измерения такие утверждения бессмысленны — поэтому в лабораторной работе задержка измеряется, а не берётся из таблицы.

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

Итоги темы

Хранилища различаются прежде всего тем, где находится файловая система. Блочное хранилище отдаёт клиенту массив блоков, и файловая система клиента полностью им распоряжается — отсюда минимальная задержка, частичная перезапись и fsync, нужные базе данных, и принципиально один узел на запись. Файловое хранилище держит файловую систему на сервере и даёт многим клиентам общее дерево каталогов с близкой к POSIX семантикой — режим RWX, нужный унаследованным приложениям, ценой сетевого запроса на каждую операцию с метаданными и ослабленной согласованности кешей. Объектное хранилище файловой системы не имеет вовсе: объект записывается целиком по HTTP и адресуется ключом в плоском пространстве имён, и это позволяет масштабировать его почти без координации.

Надёжность обеспечивается избыточностью двух видов. Репликация проста и быстро восстанавливается, но тройная копия расходует втрое больше дисков. Код стирания k+m переживает m отказов с коэффициентом (k+m)/k — в схеме 4+2 это 1,5 вместо 3, — платя усиленным трафиком при восстановлении, неудобством для мелких объектов и требованием разнести фрагменты по независимым доменам отказа.

S3 — это протокол поверх HTTP. Каждая операция — отдельный запрос, аутентифицированный подписью SigV4: канонический запрос, строка для подписи, ключ из цепочки HMAC и сама подпись, чувствительная к каждому байту пути, к заголовку Host и к часам клиента. Presigned URL — та же подпись, перенесённая в параметры, то есть временное разрешение одной операции, которое нельзя отозвать по отдельности. Версионирование превращает удаление в добавление маркера, правила жизненного цикла выполняются фоновым процессом с точностью до суток, составная загрузка ограничена 10 000 частей от 5 МиБ, а с декабря 2020 года чтение после записи в AWS строго согласовано. Доступ определяют политики с приоритетом явного запрета и предохранитель Block Public Access; шифрование на стороне сервера защищает диски, а не данные от владельца украденного ключа; от уничтожения резервных копий защищает Object Lock.

На практике это означает: база данных — на блочном томе, вложения и резервные копии — в объектном хранилище через SDK и presigned URL, общая файловая система — только там, где без неё нельзя, а монтирование бакета — только для неизменяемых данных. Тема 11 продолжает разговор о доступе: политики IAM, идентичность нагрузок вместо статических ключей S3 и изоляция компонентов «Заметок» внутри кластера. S3-совместимый сервер этой темы служит бэкендом состояния OpenTofu в теме 9, а в теме 12 объектное хранилище появляется как долговременная память систем журналов и метрик.

Литература

1. Kleppmann M. Designing Data-Intensive Applications. — O'Reilly Media, 2017.
2. Weil S. A., Brandt S. A., Miller E. L., Long D. D. E., Maltzahn C. Ceph: A Scalable, High-Performance Distributed File System. — Proceedings of the 7th Symposium on Operating Systems Design and Implementation (OSDI '06), 2006, P. 307–320.
3. Reed I. S., Solomon G. Polynomial Codes Over Certain Finite Fields. — Journal of the Society for Industrial and Applied Mathematics, 1960, vol. 8, no. 2, P. 300–304, DOI: 10.1137/0108018.
4. Haynes T., Noveck D. (eds.) Network File System (NFS) Version 4 Protocol. — RFC 7530, IETF, 2015. https://www.rfc-editor.org/rfc/rfc7530
5. Amazon Simple Storage Service User Guide. — https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html (дата обращения: 22.10.2026).
6. Amazon S3 increases the maximum object size to 50 TB. — AWS What's New, 02.12.2025. https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-s3-maximum-object-size-50-tb/ (дата обращения: 22.10.2026).
7. Amazon S3 API Reference. Authenticating Requests (AWS Signature Version 4). — https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html (дата обращения: 22.10.2026).
8. Amazon S3 User Guide. Managing the lifecycle of objects. — https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html (дата обращения: 22.10.2026).
9. Amazon S3 User Guide. Locking objects with Object Lock. — https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html (дата обращения: 22.10.2026).
10. Amazon S3 User Guide. Protecting data with encryption. — https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingEncryption.html (дата обращения: 22.10.2026).
11. Barr J. Amazon S3 Update — Strong Read-After-Write Consistency. — AWS News Blog, 01.12.2020. https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-read-after-write-consistency/ (дата обращения: 22.10.2026).
12. Mountpoint for Amazon S3. File system behavior. — https://github.com/awslabs/mountpoint-s3/blob/main/doc/SEMANTICS.md (дата обращения: 22.10.2026).
13. MinIO. README репозитория minio/minio (история изменений октябрь 2025 — февраль 2026). — https://github.com/minio/minio (дата обращения: 22.10.2026).
14. Amazon S3 Pricing; AWS Price List API, offer AmazonS3 и AWSDataTransfer, us-east-1, публикация 15.10.2026. — https://aws.amazon.com/s3/pricing/ (дата обращения: 22.10.2026).

Дополнительные материалы

Вопросы для самопроверки

1. Где находится файловая система в блочном, файловом и объектном хранилище? Как ответ на этот вопрос объясняет, почему облачный диск подключается к одной машине на запись, а сетевой каталог NFS — ко многим?
2. Почему два узла не могут одновременно смонтировать один том с ext4 на запись, хотя хранилище корректно выполняет все их записи?
3. Какие свойства POSIX теряются при переходе от локальной файловой системы к NFS, а какие — при переходе к S3? Что такое согласованность «закрыть — открыть»?
4. Почему реляционную СУБД нельзя развернуть прямо поверх объектного хранилища или смонтированного бакета, а резервные копии той же СУБД в S3 хранить можно и нужно?
5. Посчитайте коэффициент расхода пространства и число переживаемых отказов для схем 8+3 и 6+3. Сколько дисков займёт 100 ТБ полезных данных в каждой схеме и при тройной репликации?
6. Верно ли, что коды стирания переживают потерю половины дисков? Сформулируйте условие через k и m и приведите контрпример.
7. Почему восстановление одного фрагмента в схеме 10+4 нагружает сеть сильнее, чем восстановление копии при репликации? Во сколько раз?
8. Как в S3 устроены «папки»? Что произойдёт при «переименовании папки» с миллионом объектов в веб-консоли?
9. Опишите четыре шага вычисления подписи SigV4. Что изменится в подписи, если клиент поменяет регион, время или один байт тела?
10. Backend выдал браузеру presigned URL для PUT на 10 минут. Что может сделать злоумышленник, перехвативший ссылку, и чего сделать не может? Как отозвать ссылку?
11. Пользователь удалил вложение в бакете с включённым версионированием. Перечислите команды, которыми его можно восстановить, и объясните, почему после DELETE с versionId восстановление невозможно.
12. Резервная копия базы весит 3 ТиБ. Каким должен быть наименьший размер части при составной загрузке? Что произойдёт с ETag, если ту же копию загрузить с другим размером части?
13. Что означало для приложений, что до декабря 2020 года перезапись объекта в Amazon S3 была согласована лишь в конечном счёте? Решает ли строгая согласованность задачу одновременной записи двумя клиентами?
14. Политика бакета разрешает s3:GetObject всем на arn:aws:s3:::notes-att/public/*, а на бакете включена блокировка публичного доступа. Что получит анонимный клиент и почему?
15. Утёк ключ доступа backend «Заметок». Какие из механизмов — SSE-S3, SSE-KMS, версионирование, Object Lock в режиме соответствия, блокировка публичного доступа — ограничат ущерб и как?

Глоссарий темы

Шпаргалка по инструментам

Команды согласованы с лабораторной работой: стенд из архива lr-env, переменные окружения из env.sh, имя бакета в переменной BUCKET.

# стенд
./up.sh && source ./env.sh && export BUCKET=notes-att-v03
./down.sh                                         # удалить стенд вместе с данными

# бакет и объекты
aws s3api create-bucket --bucket "$BUCKET"
aws s3api put-object --bucket "$BUCKET" --key att/n.txt --body /tmp/n.txt
aws s3api head-object --bucket "$BUCKET" --key att/n.txt
aws s3api list-objects-v2 --bucket "$BUCKET" --prefix att/ --delimiter /
aws s3 cp /tmp/file "s3://$BUCKET/att/file"       # высокоуровневая команда, сама делает multipart

# версии и восстановление
aws s3api put-bucket-versioning --bucket "$BUCKET" --versioning-configuration Status=Enabled
aws s3api list-object-versions --bucket "$BUCKET" --prefix att/n.txt
DM=$(aws s3api list-object-versions --bucket "$BUCKET" --prefix att/n.txt \
       --query 'DeleteMarkers[?IsLatest].VersionId' --output text)
aws s3api delete-object --bucket "$BUCKET" --key att/n.txt --version-id "$DM"   # снять маркер
aws s3api get-object --bucket "$BUCKET" --key att/n.txt --version-id "$V1" /tmp/v1.txt

# жизненный цикл
aws s3api put-bucket-lifecycle-configuration --bucket "$BUCKET" \
    --lifecycle-configuration file://policies/lifecycle.json
aws s3api get-bucket-lifecycle-configuration --bucket "$BUCKET"

# presigned URL: ссылку всегда брать в двойные кавычки
U=$(aws s3 presign "s3://$BUCKET/att/private.txt" --expires-in 60)
curl -s -w '\nHTTP %{http_code}\n' "$U"
P=$(python3 scripts/presign.py "$BUCKET" uploads/x.txt --method put --expires 300)
curl -s -X PUT --data-binary @/tmp/hello.txt "$P"

# составная загрузка
python3 scripts/multipart.py "$BUCKET" backups/db.dump /tmp/big.bin --part-mib 5
aws s3api list-multipart-uploads --bucket "$BUCKET"
aws s3api abort-multipart-upload --bucket "$BUCKET" --key KEY --upload-id "$UPID"

# политика и блокировка публичного доступа
sed "s/BUCKET/$BUCKET/" policies/public-prefix.json > /tmp/policy.json
aws s3api put-bucket-policy --bucket "$BUCKET" --policy file:///tmp/policy.json
aws s3api put-public-access-block --bucket "$BUCKET" --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
aws s3api delete-public-access-block --bucket "$BUCKET"
aws s3api delete-bucket-policy --bucket "$BUCKET"

# диагностика
aws s3api head-bucket --bucket "$BUCKET" --debug 2>&1 | grep -E 'Authorization|X-Amz-Date|HTTP/1.1"'
python3 scripts/sigv4_manual.py get "$BUCKET" att/n.txt            # все шаги подписи
python3 scripts/latency.py "$BUCKET-bench" --count 300 --size 4096

Что почитать и посмотреть

• Amazon S3 User Guide — https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html. Первоисточник по модели данных, версионированию, жизненному циклу, политикам и классам хранения; особенно полезны разделы о согласованности и об ограничениях составной загрузки.
• Amazon S3 API Reference, раздел «Authenticating Requests (AWS Signature Version 4)» — https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html. Пошаговое описание подписи с примерами, на одном из которых проверяется скрипт sigv4_manual.py.
• Kleppmann M. Designing Data-Intensive Applications, главы 5 «Replication» и 9 «Consistency and Consensus». Лучшее учебное изложение репликации и моделей согласованности, на которых держатся обещания хранилищ.
• Weil S. A. et al. «Ceph: A Scalable, High-Performance Distributed File System», OSDI '06. Статья, в которой описаны отделение метаданных от данных и алгоритм размещения CRUSH; помогает понять, как одна система даёт блочный, файловый и объектный интерфейсы.
• Plank J. S. «Erasure Codes for Storage Systems: A Brief Primer». — ;login:, USENIX, 2013. Короткое и понятное введение в коды стирания для инженеров хранилищ: Рид — Соломон, коды с локальным восстановлением, цена восстановления.
• Mountpoint for Amazon S3, «File system behavior» — https://github.com/awslabs/mountpoint-s3/blob/main/doc/SEMANTICS.md. Честный перечень того, какие операции файловой системы поверх S3 возможны, а какие нет; полезно прочитать перед любой попыткой смонтировать бакет.
• RustFS — https://github.com/rustfs/rustfs и https://docs.rustfs.com/. Исходный код и документация сервера из лабораторной работы: состав поддерживаемых функций, конфигурация дисков и наборов стирания, переменные окружения образа.
• Garage, «S3 Compatibility status» — https://garagehq.deuxfleurs.fr/documentation/reference-manual/s3-compatibility/. Пример честной таблицы совместимости S3-сервера с другими реализациями; хороший образец того, что проверять при выборе.
• Barr J. «Amazon S3 Update — Strong Read-After-Write Consistency», AWS News Blog, 2020 — https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-read-after-write-consistency/. Объявление о переходе S3 к строгой согласованности с описанием того, что изменилось для приложений.
• Википедия, статья «Erasure code» (англ.) — обзор семейств кодов стирания со ссылками на оригинальные работы.

Углубление (по желанию)

Почему S3 четырнадцать лет был согласован лишь в конечном счёте

Когда S3 запускался в 2006 году, индекс ключей был распределён и кеширован ради доступности и масштаба, и согласованность в конечном счёте была осознанным компромиссом в духе теоремы CAP: при сбое связи между частями системы хранилище продолжало принимать запросы, а не отказывало. Приложения научились жить с этим: писали каждую версию под новым ключом, держали список актуальных ключей во внешней базе, а аналитические системы вроде Hadoop использовали отдельные слои, проверявшие листинги по внешнему индексу. Переход к строгой согласованности в 2020 году, по публичным рассказам инженеров AWS, потребовал протокола, связывающего кеш метаданных с реплицируемым журналом записей, и был выполнен без изменения API и цены. Для разработчика это убрало целый класс трудноуловимых ошибок, но не отменило главного: S3 не даёт транзакций над несколькими объектами, и задачи вроде атомарной замены набора файлов по-прежнему решаются на уровне приложения — например, табличными форматами Apache Iceberg и Delta Lake, которые хранят в S3 неизменяемые файлы данных и журнал версий таблицы.

Коды с локальным восстановлением

Схема Рида — Соломона k+m оптимальна по месту: никакой код не переживает m отказов с меньшей избыточностью. Но восстановление одного потерянного фрагмента требует чтения k других, и в больших кластерах именно этот трафик, а не место, становится узким местом. Коды с локальным восстановлением (англ. locally repairable codes) жертвуют частью оптимальности: фрагменты данных делятся на небольшие группы, и для каждой группы вычисляется своя «локальная» чётность. Потерю одного фрагмента — самый частый случай — исправляют по своей группе, читая, например, 6 фрагментов вместо 12; глобальные фрагменты чётности нужны только при множественных отказах. Такие коды используются в крупных облачных хранилищах, и их идея хорошо иллюстрирует общий принцип: оптимизировать надо ту операцию, которая выполняется чаще всего, а не ту, что красивее выглядит в формуле.

Почему «S3-совместимый» — понятие с оговорками

API S3 никогда не был открытым стандартом, принятым комитетом: это интерфейс одного сервиса, который другие реализации воспроизводят по документации и по поведению клиентов. Отсюда регулярные расхождения. В 2025 году AWS включила в SDK и CLI по умолчанию новые контрольные суммы (x-amz-checksum-crc64nvme), и часть сторонних серверов начала отвечать ошибками на запросы свежих клиентов, пока их не обновили или пока в клиентах не отключили новую защиту настройками request_checksum_calculation и response_checksum_validation. Стиль адресации, обработка ETag при шифровании, коды ошибок, лимиты частей, поддержка условной записи и Object Lock различаются от сервера к серверу. История MinIO добавляет к техническим рискам организационный: популярный открытый сервер за несколько месяцев перестал выпускать образы и ушёл в архив. Практический вывод — держать приложение на стандартном SDK без привязки к расширениям конкретного сервера, закреплять версии образов и иметь набор тестов, которым можно быстро проверить, что новый сервер или новая версия клиента выполняют нужные приложению операции.

Лабораторная работа 10. Объектное хранилище S3: подпись запросов, версии, политики и составная загрузка

• Раздел курса: тема 10 «Облачные хранилища данных: блочные, файловые и объектные»

Введение

В теме 8 данные приложения «Заметки» хранились на постоянном томе, и работа с ними сводилась к обычным файлам. Объектное хранилище устроено иначе: каждая операция — отдельный HTTP-запрос с подписью, объект нельзя изменить по частям, «удаление» в версионированном бакете ничего не удаляет, а права определяются политикой в формате JSON. Эту модель удобнее всего понять, наблюдая её на уровне запросов, а не через графическую консоль. В работе поднимается S3-совместимый сервер RustFS в Docker, и все опыты выполняются клиентами AWS CLI v2 и boto3 — теми же, что используются с Amazon S3, — а также небольшим скриптом, который вычисляет подпись SigV4 вручную.

Сценарий работы взят из «Заметок»: бакет для вложений пользователей и резервных копий базы. Сначала разбирается, из чего состоит подписанный запрос и почему анонимный запрос отвергается. Затем на одном ключе проходят версии и маркер удаления, а «удалённый» объект восстанавливается. После этого настраиваются правила жизненного цикла, выпускаются presigned URL для скачивания и загрузки, выполняется составная загрузка с проверкой ETag, открывается публичный доступ к одному префиксу и тут же закрывается блокировкой публичного доступа. Отдельная часть измеряет, насколько запрос к объектному хранилищу медленнее чтения локального файла. В части «сломать и починить» запросы ломаются неверной подписью, сдвигом часов и неверным стилем адресации, а затем исправляются по сообщениям об ошибках.

Работа состоит из базовой части (части 1–8) и продвинутой (часть 9: Object Lock и защита резервных копий). Тот же сервер с тем же тегом образа служит бэкендом состояния OpenTofu в лабораторной работе 9.

Цель работы

Освоить модель объектного хранилища S3 на уровне HTTP-запросов: подпись SigV4, версионирование, правила жизненного цикла, presigned URL, составную загрузку и политики доступа, — и научиться диагностировать типичные ошибки по ответам сервера.

После выполнения работы можно будет:

• развернуть S3-совместимый сервер в Docker с закреплённым тегом образа и подключить к нему AWS CLI v2 и boto3;
• разобрать подписанный запрос S3 на канонический запрос, строку для подписи и подпись и вычислить подпись вручную;
• восстановить «удалённый» объект в версионированном бакете удалением маркера удаления и прочитать любую прежнюю версию;
• выпустить presigned URL для GET и PUT, объяснить, что входит в подпись, и проверить отказ по истечении срока;
• выполнить составную загрузку по шагам, найти незавершённую загрузку и вычислить ETag составного объекта;
• открыть анонимное чтение одного префикса политикой бакета и проверить, что всё остальное по-прежнему закрыто;
• измерить латентность PUT и GET мелких объектов и сравнить её с работой локальной файловой системы;
• определить причину отказа по коду и тексту ошибки: SignatureDoesNotMatch, RequestTimeTooSkewed, NoSuchBucket, AccessDenied.

Теоретический минимум

Теория изложена в теме 10: разделы «S3: модель данных и протокол», «Жизнь объекта: версии, жизненный цикл, составная загрузка, согласованность» и «Доступ и защита данных». Ниже — сжатая справка.

Учебный стенд:

  хост (Ubuntu 24.04 / WSL2)                     контейнер lab10-rustfs
  ┌───────────────────────────────┐              ┌──────────────────────────┐
  │ aws (AWS CLI v2)              │  HTTP        │ rustfs 1.0.3             │
  │ python3 + boto3 (scripts/*.py)├─────────────►│ :9000  S3 API            │
  │ curl                          │ 127.0.0.1    │ :9001  веб-консоль       │
  │ source ./env.sh               │ :9000 :9001  │ /data  ← том rustfs-data │
  └───────────────────────────────┘              └──────────────────────────┘
  ключ доступа lab10admin, секрет lab10-secret-key, регион us-east-1, path-style

Основные команды AWS CLI:

Скрипты окружения (запускаются из каталога lr-env):

Перечень оснащения

• ОС Ubuntu 24.04 (физическая машина, виртуальная машина или WSL2) либо macOS или Windows с Docker Desktop; 2 ядра, 2 ГБ свободной памяти, 2 ГБ диска.

• Docker Engine 27+ с Compose v2 2.29+ (тема 3). Образ rustfs/rustfs:1.0.3 (около 100 МБ) скачивается при первом запуске.

• AWS CLI v2 версии 2.38.4 (на ней проверены команды работы):

  curl -fsSLo /tmp/awscliv2.zip https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.38.4.zip
  unzip -q /tmp/awscliv2.zip -d /tmp && sudo /tmp/aws/install
  aws --version
  

• Python 3.12 и boto3 1.43.117 в виртуальном окружении:

  sudo apt install -y python3-venv
  python3 -m venv ~/lab10-venv && ~/lab10-venv/bin/pip install boto3==1.43.117
  source ~/lab10-venv/bin/activate
  

• Утилиты curl, jq, xxd, md5sum, split (пакеты curl jq xxd coreutils).

• Архив окружения lr-env: compose.yaml, compose.vhost.yaml, up.sh, down.sh, env.sh, aws-config, каталоги policies/ и scripts/, README.md с обоснованием выбора сервера.

Стенды лабораторных работ 9 и 10 используют один и тот же сервер и одни и те же порты 127.0.0.1:9000 и 9001. Если стенд ЛР 9 ещё поднят, сначала разберите его командой ./down.sh в каталоге files/topic-09/lr-env (в распакованном архиве ЛР 9), иначе порты будут заняты и up.sh завершится ошибкой.

Порядок выполнения работы

Распакуйте архив, поднимите стенд и подключите переменные окружения:

unzip lr-env.zip -d ~/lab10 && cd ~/lab10/lr-env && chmod +x *.sh
./up.sh
source ./env.sh
export BUCKET=notes-att-v03          # имя из своего варианта

env.sh задаёт AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION=us-east-1, AWS_ENDPOINT_URL=http://127.0.0.1:9000 и собственный файл конфигурации AWS CLI, поэтому команды aws в этой работе обращаются к учебному серверу, а не к Amazon. Переменные действуют в текущем терминале: в новом окне повторите source ./env.sh и export BUCKET=.... Все команды выполняются из каталога lr-env.

Номер варианта выберите сами. Параметры варианта:

Части 1–8 составляют базовую часть, часть 9 — продвинутую. Перед каждым опытом записывайте в журнал предсказание: код ответа, число версий, ETag. Чтобы начать заново, выполните ./down.sh && ./up.sh — том с данными удаляется вместе со стендом. По окончании работы выполните ./down.sh.

Часть 1. Стенд и анатомия подписанного запроса

Задание

1. Убедитесь, что сервер жив и отвечает на HTTP без подписи:

   docker compose ps
   curl -s http://127.0.0.1:9000/health; echo
   curl -si http://127.0.0.1:9000/
   

   Предсказание. Что ответит корень API на запрос без подписи — список бакетов, ошибку или пустую страницу? Какой будет код ответа и формат тела?

2. Выполните тот же запрос подписанным: aws s3api list-buckets. Создайте бакет своего варианта и проверьте, что он появился:

   aws s3api create-bucket --bucket "$BUCKET"
   aws s3api list-buckets --query 'Buckets[].Name'
   

3. Запишите объект и посмотрите на сырые заголовки запроса и ответа, которые печатает режим отладки:

   echo 'hello from lab10' > /tmp/hello.txt
   aws s3api put-object --bucket "$BUCKET" --key att/hello.txt --body /tmp/hello.txt --debug 2>&1 \
     | grep -E '"PUT |X-Amz-Date|X-Amz-Content-SHA256|Authorization|Response headers' | cut -c1-400
   md5sum /tmp/hello.txt
   

   Найдите в выводе метод и путь, время X-Amz-Date, хеш тела X-Amz-Content-SHA256, область действия в Credential=... и список SignedHeaders. Сравните ETag из ответа с md5sum.

4. Проверьте ручную реализацию подписи на примере из документации Amazon S3 и выполните тот же GET с подписью, вычисленной без библиотек AWS:

   python3 scripts/sigv4_manual.py selftest
   python3 scripts/sigv4_manual.py get "$BUCKET" att/hello.txt
   

   Сопоставьте четыре шага, которые печатает скрипт, с разделом «Сырой HTTP-запрос и подпись SigV4» теории. Где в каноническом запросе путь, где хеш пустого тела, почему строка параметров пустая?

Что должно получиться

Анонимный запрос к корню API отвергается ответом 403 Forbidden с телом XML:

HTTP/1.1 403 Forbidden
content-type: application/xml
...
<?xml version="1.0" encoding="UTF-8"?><Error><Code>AccessDenied</Code><Message>Access Denied</Message></Error>

Ошибки S3 всегда приходят в таком виде: HTTP-код плюс машинно-читаемый Code, по которому и ведётся диагностика. В выводе --debug видны заголовки X-Amz-Date, X-Amz-Content-SHA256 и Authorization: AWS4-HMAC-SHA256 Credential=lab10admin/<дата>/us-east-1/s3/aws4_request, SignedHeaders=..., Signature=...; современный AWS CLI добавляет в подписанные заголовки ещё и x-amz-checksum-crc64nvme. ETag совпадает с MD5 файла. selftest печатает совпадение с подписью f0e8bdb8... из документации, а ручной GET возвращает 200 OK и содержимое объекта. Если ручной запрос получает SignatureDoesNotMatch, проверьте, что env.sh подключён в этом терминале.

Часть 2. Версионирование и восстановление удалённого объекта

Задание

1. Включите версионирование и проверьте состояние:

   aws s3api put-bucket-versioning --bucket "$BUCKET" --versioning-configuration Status=Enabled
   aws s3api get-bucket-versioning --bucket "$BUCKET"
   

2. Запишите две версии одного ключа и сохраните их идентификаторы:

   echo v1 > /tmp/n.txt
   aws s3api put-object --bucket "$BUCKET" --key att/n.txt --body /tmp/n.txt
   echo v2 > /tmp/n.txt
   aws s3api put-object --bucket "$BUCKET" --key att/n.txt --body /tmp/n.txt
   aws s3api list-object-versions --bucket "$BUCKET" --prefix att/n.txt
   

3. Предсказание. Что вернёт delete-object без --version-id? Сколько версий и маркеров покажет list-object-versions после него? Что ответит head-object? Выполните:

   aws s3api delete-object --bucket "$BUCKET" --key att/n.txt
   aws s3api list-object-versions --bucket "$BUCKET" --prefix att/n.txt
   aws s3api head-object --bucket "$BUCKET" --key att/n.txt
   aws s3api list-objects-v2 --bucket "$BUCKET" --prefix att/
   

4. Восстановите объект: найдите идентификатор текущего маркера удаления и удалите именно его.

   DM=$(aws s3api list-object-versions --bucket "$BUCKET" --prefix att/n.txt \
          --query 'DeleteMarkers[?IsLatest].VersionId' --output text)
   echo "маркер: $DM"
   aws s3api delete-object --bucket "$BUCKET" --key att/n.txt --version-id "$DM"
   aws s3api get-object --bucket "$BUCKET" --key att/n.txt /tmp/restored.txt && cat /tmp/restored.txt
   

5. Прочитайте первую версию по её идентификатору:

   V1=$(aws s3api list-object-versions --bucket "$BUCKET" --prefix att/n.txt \
          --query 'Versions[?IsLatest==`false`].VersionId' --output text)
   aws s3api get-object --bucket "$BUCKET" --key att/n.txt --version-id "$V1" /tmp/v1.txt && cat /tmp/v1.txt
   

6. Ответьте письменно: чем delete-object --version-id <id версии v2> отличается от того, что было сделано в шаге 3? Какой объект станет текущим после него? Можно ли после этого вернуть v2?

Что должно получиться

После delete-object без версии сервер отвечает "DeleteMarker": true с идентификатором нового маркера, head-object возвращает 404 Not Found, листинг объектов пуст, а list-object-versions показывает обе версии данных с IsLatest: false и маркер с IsLatest: true:

{
    "Versions": [
        { "Key": "att/n.txt", "VersionId": "a92d97c0-...", "IsLatest": false, "Size": 3, ... },
        { "Key": "att/n.txt", "VersionId": "16e7d32e-...", "IsLatest": false, "Size": 3, ... }
    ],
    "DeleteMarkers": [
        { "Key": "att/n.txt", "VersionId": "1b990464-...", "IsLatest": true, ... }
    ],
    ...
}

После удаления маркера get-object возвращает версию v2 (cat печатает v2), чтение по V1 печатает v1. Идентификаторы версий у каждого свои. Если DM оказался пустым, маркер уже удалён или в бакете не включено версионирование: проверьте get-bucket-versioning. Если в DM попало несколько идентификаторов, по ключу удаляли несколько раз — IsLatest у маркера только один. Ответ на шаг 6: удаление версии по идентификатору необратимо, текущей станет v1.

Часть 3. Правила жизненного цикла

Задание

1. Изучите policies/lifecycle.json: какие объекты затрагивает каждое из трёх правил и когда.

2. Предсказание. Через сколько времени после загрузки объект tmp/x.txt исчезнет в AWS? Сможете ли вы увидеть это в рамках занятия?

3. Установите правила и прочитайте их обратно:

   aws s3api put-bucket-lifecycle-configuration --bucket "$BUCKET" \
       --lifecycle-configuration file://policies/lifecycle.json
   aws s3api get-bucket-lifecycle-configuration --bucket "$BUCKET"
   echo temp | aws s3 cp - "s3://$BUCKET/tmp/x.txt"
   aws s3api head-object --bucket "$BUCKET" --key tmp/x.txt
   

4. Измените правило так, чтобы неактуальные версии хранились 30 дней, и только для ключей, начинающихся с backups/; установите исправленный файл. Сколько правил в конфигурации теперь — добавилось ли новое правило к старым или конфигурация заменилась целиком?

5. По желанию: на следующий день проверьте, исчез ли tmp/x.txt и неактуальная версия att/n.txt из части 2.

Что должно получиться

get-bucket-lifecycle-configuration возвращает те же три правила, которые были загружены (порядок полей внутри правила может отличаться). Срок в правилах — сутки, а выполняет их фоновый процесс, поэтому в рамках занятия объекты не исчезают: проверяемый результат части — принятая сервером конфигурация и объяснение, почему удаление не наблюдается сразу. На шаге 4 конфигурация заменяется целиком: put-bucket-lifecycle-configuration не добавляет правило, а перезаписывает весь набор, и правила, не вошедшие в новый файл, пропадают. На учебном сервере исполнение правил по времени при подготовке работы не наблюдалось; результат шага 5 — ваше собственное наблюдение.

Часть 4. Presigned URL

Задание

1. Выпустите ссылку на скачивание приватного объекта сроком из своего варианта (здесь 60 с) и скачайте объект без ключей. URL содержит символы &, поэтому в оболочке он всегда берётся в двойные кавычки:

   aws s3 cp /tmp/hello.txt "s3://$BUCKET/att/private.txt"
   U=$(aws s3 presign "s3://$BUCKET/att/private.txt" --expires-in 60)
   echo "$U"
   curl -s -w '\nHTTP %{http_code}\n' "$U"
   

   Разберите параметры X-Amz-* в ссылке: что из них входит в подпись, что задаёт срок?

2. Предсказание. Что ответит сервер, если: заменить в URL один символ подписи; заменить ключ объекта на att/n.txt; увеличить X-Amz-Expires; вставить URL в команду без кавычек? Проверьте (последняя команда через eval имитирует URL, вставленный в командную строку как есть):

   curl -s -w '\nHTTP %{http_code}\n' "$(echo "$U" | sed -E 's/(X-Amz-Signature=)./\1f/')"
   curl -s -w '\nHTTP %{http_code}\n' "${U/private.txt/n.txt}"
   curl -s -w '\nHTTP %{http_code}\n' "$(echo "$U" | sed -E 's/X-Amz-Expires=[0-9]+/X-Amz-Expires=6000/')"
   eval "curl -s -w '\nHTTP %{http_code}\n' $U"
   

3. Дождитесь окончания срока и повторите исходный запрос curl -s -w '\nHTTP %{http_code}\n' "$U".

4. Выпустите ссылку на загрузку через boto3 и загрузите по ней файл без ключей, как это делал бы браузер:

   P=$(python3 scripts/presign.py "$BUCKET" uploads/from-browser.txt --method put --expires 300)
   curl -s -w 'HTTP %{http_code}\n' -X PUT --data-binary @/tmp/hello.txt "$P"
   aws s3api head-object --bucket "$BUCKET" --key uploads/from-browser.txt
   

5. Ответьте письменно: как отозвать уже выданную ссылку до истечения её срока?

Что должно получиться

В срок ссылка отдаёт содержимое объекта с кодом 200. Изменённая подпись, другой ключ и увеличенный срок дают 403 с кодом SignatureDoesNotMatch: все три элемента входят в подписанную строку. Без кавычек оболочка считает & разделителем команд: curl запускается в фоне со ссылкой, обрезанной после X-Amz-Algorithm=AWS4-HMAC-SHA256, а остальные куски выполняются как присваивания переменных. Сервер получает запрос без подписи и отвечает 403 (при подготовке работы так и было). Значение переменной $U без кавычек такой ошибки не даёт — опасна именно вставка ссылки в команду как текста. После истечения срока ответ — 403 AccessDenied с сообщением Request has expired. Срок больше 604 800 с сервер отвергает ответом 400 AuthorizationQueryParametersError. Загрузка по presigned PUT возвращает 200, объект появляется в бакете. Отозвать отдельную ссылку нельзя: можно лишить прав или сменить ключ того, кто её подписал, что отзовёт все его ссылки. Если первый curl уже получил Request has expired, срок варианта слишком мал для ручного ввода — выпустите ссылку заново и запрашивайте её сразу.

Часть 5. Составная загрузка

Задание

1. Создайте файл размером из своего варианта (здесь 16 МиБ) и рассчитайте, сколько частей получится при размере части из варианта и какого размера будет последняя часть.

   head -c $((16*1024*1024)) /dev/urandom > /tmp/big.bin
   

2. Выполните составную загрузку по шагам и сравните ETag с локальным расчётом:

   python3 scripts/multipart.py "$BUCKET" backups/db.dump /tmp/big.bin --part-mib 5
   aws s3api head-object --bucket "$BUCKET" --key backups/db.dump
   md5sum /tmp/big.bin
   

3. Повторите локальный расчёт ETag командами оболочки, не пользуясь скриптом:

   split -b 5M -d /tmp/big.bin /tmp/part.
   for f in /tmp/part.*; do md5sum "$f" | cut -c1-32; done | xxd -r -p | md5sum
   

4. Предсказание. Что произойдёт, если загружать тот же файл частями по 1 МиБ? Проверьте: python3 scripts/multipart.py "$BUCKET" backups/small-parts.dump /tmp/big.bin --part-mib 1.

5. Оставьте незавершённую загрузку, найдите её и прервите:

   python3 scripts/multipart.py "$BUCKET" backups/broken.dump /tmp/big.bin --abort-after 1
   aws s3api list-objects-v2 --bucket "$BUCKET" --prefix backups/ --query 'Contents[].Key'
   aws s3api list-multipart-uploads --bucket "$BUCKET"
   UPID=$(aws s3api list-multipart-uploads --bucket "$BUCKET" --prefix backups/broken.dump \
            --query 'Uploads[0].UploadId' --output text)
   aws s3api abort-multipart-upload --bucket "$BUCKET" --key backups/broken.dump --upload-id "$UPID"
   aws s3api list-multipart-uploads --bucket "$BUCKET"
   

6. Рассчитайте минимальный размер части для резервной копии в 2 ТиБ с учётом предела 10 000 частей.

Что должно получиться

Скрипт печатает ETag каждой части, число частей на сервере и итоговый ETag вида "<32 hex>-N", где N — число частей, и сообщает «совпадает» с локальным расчётом; ETag не равен md5sum файла. Шаг 3 даёт ту же 32-символьную строку, что и ETag до дефиса. При подготовке работы файл в 12 МиБ, загруженный частями 5 + 5 + 2 МиБ, получил ETag "12fe8e66682a0511b94a7f4cb257cbc5-3", совпавший с локальным расчётом. По спецификации S3 при частях по 1 МиБ сервер должен отклонить CompleteMultipartUpload с кодом EntityTooSmall (все части, кроме последней, — не меньше 5 МиБ); скрипт в этом случае прерывает загрузку. Если учебный сервер всё же собрал объект, зафиксируйте это как отличие реализации от AWS. Незавершённая загрузка не видна в list-objects-v2, но видна в list-multipart-uploads; после abort-multipart-upload список пуст. Для 2 ТиБ часть должна быть не меньше 2\,097\,152 / 10\,000 \approx 210 МиБ.

Часть 6. Политика бакета и блокировка публичного доступа

Задание

1. Положите два объекта — публичный и приватный:

   echo 'public avatar' | aws s3 cp - "s3://$BUCKET/public/avatar.txt"
   

   Приватным служит att/private.txt из части 4.

2. Предсказание. Какие из четырёх анонимных запросов ниже получат 200 после установки политики policies/public-prefix.json: GET public/avatar.txt, GET att/private.txt, листинг бакета, PUT в public/?

3. Установите политику, подставив имя бакета, и проверьте анонимные запросы:

   sed "s/BUCKET/$BUCKET/" policies/public-prefix.json > /tmp/policy.json
   aws s3api put-bucket-policy --bucket "$BUCKET" --policy file:///tmp/policy.json
   aws s3api get-bucket-policy --bucket "$BUCKET" --query Policy --output text | jq .
   E=http://127.0.0.1:9000/$BUCKET
   curl -s -o /dev/null -w 'GET public : %{http_code}\n' "$E/public/avatar.txt"
   curl -s -o /dev/null -w 'GET att    : %{http_code}\n' "$E/att/private.txt"
   curl -s -o /dev/null -w 'LIST       : %{http_code}\n' "$E?list-type=2"
   curl -s -o /dev/null -w 'PUT public : %{http_code}\n' -X PUT --data x "$E/public/evil.txt"
   

4. Включите блокировку публичного доступа и повторите первый запрос:

   aws s3api put-public-access-block --bucket "$BUCKET" --public-access-block-configuration \
       BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
   aws s3api get-public-access-block --bucket "$BUCKET"
   aws s3api get-bucket-policy --bucket "$BUCKET" --query Policy --output text
   curl -s -o /dev/null -w 'GET public : %{http_code}\n' "$E/public/avatar.txt"
   

5. Объясните, почему политика осталась на месте, а доступ пропал. Какой из четырёх флагов за это отвечает? Снимите блокировку (delete-public-access-block) и удалите политику (delete-bucket-policy): в остальных частях бакет должен быть закрыт.

Что должно получиться

С политикой анонимный GET к public/avatar.txt даёт 200, остальные три запроса — 403 AccessDenied: политика разрешает ровно s3:GetObject на ресурсе arn:aws:s3:::<бакет>/public/*, а листинг (s3:ListBucket на ресурсе бакета) и запись не разрешены никому анонимно. После включения блокировки тот же GET даёт 403, хотя get-bucket-policy по-прежнему показывает политику: флаг RestrictPublicBuckets запрещает анонимный доступ через публичные политики, не удаляя их. Такой результат получен при подготовке работы. Если put-bucket-policy после включения блокировки отвергается с AccessDenied, сработал BlockPublicPolicy — это ожидаемое поведение при попытке установить публичную политику поверх блокировки.

Часть 7. Латентность мелких объектов против локального диска

Задание

1. Предсказание. Во сколько раз медиана GET объекта размером из варианта медленнее чтения такого же локального файла? Запишите число до замера.

2. Создайте отдельный бакет для замера без версионирования (скрипт удаляет за собой объекты, и в версионированном бакете от них остались бы маркеры) и выполните замер с параметрами варианта:

   aws s3api create-bucket --bucket "$BUCKET-bench"
   python3 scripts/latency.py "$BUCKET-bench" --count 300 --size 4096
   python3 scripts/latency.py "$BUCKET-bench" --count 300 --size 4096 --no-fsync
   

3. Повторите замер ещё дважды и оцените разброс медиан. Сведите результаты в таблицу «операция — p50 — p95 — p99».

4. Объясните по составу операций, откуда берётся разница: что происходит при GET объекта (HTTP, подпись, поиск ключа, чтение с диска сервера, ответ) и при чтении только что записанного локального файла. Почему локальная запись с fsync может оказаться медленнее PUT в S3 на том же диске?

5. Опишите, как изменились бы числа, если бы сервер S3 находился в другом центре обработки данных, и какой из компонентов задержки при этом вырос бы.

Что должно получиться

Таблица с перцентилями четырёх операций в трёх повторах и ответы на вопросы. Ожидается, что чтение локального файла из страничного кеша занимает единицы или десятки микросекунд, а GET в S3 — от долей миллисекунды до нескольких миллисекунд даже на одной машине: разница в сотни раз и больше, и почти вся она — накладные расходы HTTP, подписи и обработки запроса сервером, а не чтение диска. Запись с fsync зависит от диска и файловой системы: на WSL2 и на виртуальных дисках fsync может стоить десятки миллисекунд (при подготовке работы в WSL2 медиана записи 4 КиБ с fsync составила около 60 мс) и оказаться дороже PUT, если сервер подтверждает запись, не дожидаясь сброса на носитель, — поэтому сравнение PUT с «записью на диск» без указания режима fsync некорректно. Разброс между повторами в несколько десятков процентов нормален для машины, на которой работают другие программы; значимыми считаются различия в разы. Если первая сотня запросов заметно медленнее остальных, увеличьте --count: прогрев в скрипте короткий.

Часть 8. Сломать и починить

Задание

В каждом пункте сначала запишите предсказание кода ошибки, затем выполните команду, по ответу определите причину и исправьте.

1. Неверный секрет. Подпишите запрос чужим секретом:

   python3 scripts/sigv4_manual.py get "$BUCKET" att/hello.txt --secret wrong-secret | tail -3
   AWS_SECRET_ACCESS_KEY=wrong-secret aws s3api head-object --bucket "$BUCKET" --key att/hello.txt
   

   Какой шаг подписи дал другой результат? Может ли сервер по ответу понять, что ошибка именно в секрете, а не в каноническом запросе?

2. Неверный регион. Подпишите запрос для другого региона: python3 scripts/sigv4_manual.py get "$BUCKET" att/hello.txt --region eu-west-1 | tail -3. Что вернул сервер и почему регион вообще влияет на подпись?

3. Часы. Имитируйте клиент с отстающими на 20 минут и на 2 минуты часами:

   python3 scripts/sigv4_manual.py get "$BUCKET" att/hello.txt --skew-minutes -20 | tail -3
   python3 scripts/sigv4_manual.py get "$BUCKET" att/hello.txt --skew-minutes -2 | tail -3
   

   Чем отличаются ответы? Как проверить часы настоящей машины (timedatectl, chronyc tracking) и почему в WSL2 часы иногда отстают после сна ноутбука?

4. Стиль адресации. Отправьте запрос в стиле virtual-hosted: бакет в имени хоста, ключ в пути:

   python3 scripts/sigv4_manual.py get "$BUCKET" att/hello.txt --style virtual | tail -4
   

   Предсказание. Как сервер, понимающий только path-style, истолкует путь /att/hello.txt? Какой бакет он будет искать? Затем включите на сервере домен для virtual-hosted-style и повторите запрос:

   docker compose -f compose.yaml -f compose.vhost.yaml up -d
   until curl -fsS http://127.0.0.1:9000/health >/dev/null; do sleep 1; done
   python3 scripts/sigv4_manual.py get "$BUCKET" att/hello.txt --style virtual | tail -4
   

   Данные в томе сохраняются: пересоздаётся только контейнер. Объясните, почему SDK с адресом http://127.0.0.1:9000 такую ошибку не воспроизводит, а с адресом http://localhost:9000 и настройкой addressing_style = virtual — воспроизводит.

5. Верните стенд в обычный режим: docker compose -f compose.yaml up -d.

Что должно получиться

Чужой секрет и чужой регион дают 403 с кодом SignatureDoesNotMatch (через AWS CLI — 403 Forbidden у head-object, поскольку у ответа на HEAD нет тела): сервер вычисляет подпись своим секретом для области действия из Credential и получает другой результат, а различить «неверный секрет» и «неверно составленный канонический запрос» он не может — видна лишь несовпадающая подпись. Регион входит в область действия и в цепочку HMAC, поэтому подпись для eu-west-1 не совпадает с ожидаемой для us-east-1. По документации AWS запрос, время которого отличается от времени сервера больше чем на 15 минут, отвергается с кодом RequestTimeTooSkewed, а сдвиг в 2 минуты проходит; допустимое окно RustFS при подготовке работы не проверялось — запишите, что ответил сервер. Запрос в стиле virtual-hosted без настроенного домена сервер понимает как path-style и ищет бакет с именем att, поэтому ожидается ошибка вида NoSuchBucket (или AccessDenied, если сервер сначала проверяет права); после запуска с RUSTFS_SERVER_DOMAINS=s3.lab10.local заголовок Host: <бакет>.s3.lab10.local:9000 относится к бакету, и запрос должен вернуть 200. Поведение RustFS в режиме virtual-hosted-style описано по справке сервера и при подготовке работы не проверялось запуском: если результат другой, зафиксируйте его. SDK для адреса-IP всегда переходят на path-style, а для имени хоста localhost в режиме virtual строят адрес <бакет>.localhost, который в зависимости от системы либо не разрешается, либо приходит на сервер с тем же неверным истолкованием.

Часть 9. Object Lock и защита резервных копий (продвинутая)

Задание

Сценарий: ночная резервная копия базы «Заметок» должна храниться 1 сутки так, чтобы её не смог удалить даже владелец ключа администратора.

1. Создайте бакет с включённым Object Lock (версионирование включается вместе с ним) и правилом хранения по умолчанию в режиме управления на 1 день:

   aws s3api create-bucket --bucket "$BUCKET-backups" --object-lock-enabled-for-bucket
   aws s3api get-bucket-versioning --bucket "$BUCKET-backups"
   aws s3api put-object-lock-configuration --bucket "$BUCKET-backups" --object-lock-configuration \
       '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":1}}}'
   aws s3api get-object-lock-configuration --bucket "$BUCKET-backups"
   

2. Запишите «резервную копию» и посмотрите её срок хранения:

   echo "pg_dump $(date -u +%FT%TZ)" > /tmp/dump.sql
   aws s3api put-object --bucket "$BUCKET-backups" --key backups/notes.sql --body /tmp/dump.sql
   aws s3api head-object --bucket "$BUCKET-backups" --key backups/notes.sql
   

3. Предсказание. Что произойдёт при удалении без версии и при удалении версии по идентификатору? Проверьте:

   VID=$(aws s3api list-object-versions --bucket "$BUCKET-backups" --prefix backups/notes.sql \
           --query 'Versions[0].VersionId' --output text)
   aws s3api delete-object --bucket "$BUCKET-backups" --key backups/notes.sql
   aws s3api delete-object --bucket "$BUCKET-backups" --key backups/notes.sql --version-id "$VID"
   

4. Удалите версию с обходом режима управления: aws s3api delete-object --bucket "$BUCKET-backups" --key backups/notes.sql --version-id "$VID" --bypass-governance-retention. Объясните, почему для настоящих резервных копий нужен режим соответствия и какие права должны быть у учётной записи, которая пишет копии.

5. Спроектируйте (без выполнения) конфигурацию для «Заметок»: режим, срок хранения, правило жизненного цикла для старых версий и перевода в холодный класс, политика для учётной записи резервного копирования.

Что должно получиться

По документации S3 удаление без версии успешно и лишь добавляет маркер удаления, а удаление защищённой версии по идентификатору отвергается с AccessDenied; head-object показывает заголовки ObjectLockMode: GOVERNANCE и ObjectLockRetainUntilDate через сутки после записи; с флагом обхода версия удаляется. RustFS заявляет поддержку Object Lock, но эта часть при подготовке работы запуском не проверялась: зафиксируйте фактические ответы сервера и отличия от описанного поведения. В проекте конфигурации должны быть режим COMPLIANCE со сроком, превышающим период обнаружения инцидента, учётная запись копирования только с s3:PutObject на префикс копий, правило NoncurrentVersionExpiration и правило Transition в холодный класс. Режим соответствия на учебном сервере не включайте: такой объект нельзя удалить до истечения срока, и down.sh останется единственным способом от него избавиться.

Журнал работы

Ведите для себя журнал: для каждой части записывайте предсказание, сделанное до эксперимента, команду, фактический вывод (код ответа, Code ошибки, идентификаторы версий, ETag, перцентили) и объяснение расхождений. Особенно полезно фиксировать опыты, в которых предсказание не совпало с ответом сервера, и отличия RustFS от описанного в документации AWS поведения. В конце сформулируйте несколько предложений собственных выводов: какие свойства S3 оказались неожиданными и как они повлияют на код backend «Заметок».

Контрольные вопросы

1. Почему анонимный запрос к корню API получает 403, а не 404 или пустой список? Какой механизм — аутентификация или авторизация — отвергает его?
2. Из каких частей состоит канонический запрос SigV4 и зачем в нём хеш тела и подписанный заголовок Host? Какую атаку предотвращает каждый элемент?
3. Почему сдвиг часов клиента на 20 минут ломает все запросы при правильных ключах? Почему такой проверки нет у presigned URL со сроком 7 суток — или она есть?
4. Чем DELETE без versionId отличается от DELETE с versionId в версионированном бакете? Как восстановить объект после первого и можно ли — после второго?
5. Почему версионирование не является резервной копией и что добавляет Object Lock в режиме соответствия?
6. Почему правило жизненного цикла со сроком в 1 день не удаляет объект ровно через 24 часа? Как проверить правило, не дожидаясь срабатывания?
7. Почему отдельный presigned URL нельзя отозвать? Какие меры ограничивают ущерб от утечки такой ссылки?
8. Как вычисляется ETag объекта после составной загрузки и почему один и тот же файл может иметь разные ETag? Чем опасны незавершённые составные загрузки?
9. Какой наименьший размер части нужен для объекта в 500 ГиБ? Почему нельзя просто взять части по 5 МиБ?
10. Почему после включения RestrictPublicBuckets анонимный доступ пропал, хотя публичная политика осталась? Зачем держать блокировку включённой, если политики пишутся аккуратно?
11. Почему GET мелкого объекта в S3 на сотни раз медленнее чтения локального файла, хотя данные лежат на том же диске? Что из этого следует для приложения, которое читает тысячи мелких объектов?
12. Почему запрос в стиле virtual-hosted к серверу без настроенного домена приводит к ошибке про бакет, имя которого совпадает с первой частью ключа?