Как защитить S3-бакет: доступ, ключи, версии, Object Lock и аудит

Безопасность S3-бакета нельзя свести к одному переключателю «приватный». Данные можно закрыть от интернета, но они останутся доступными сервису с избыточными правами, и их можно будет удалить скомпрометированным ключом или незаметно перезаписывать ошибочной интеграцией.

Рабочая схема строится в несколько слоев:

• бакеты и объекты по умолчанию закрыты;
• пользователи и сервисы получают только необходимые операции и префиксы;
• постоянные ключи не попадают в браузер, мобильное приложение, репозиторий и журналы;
• для разовой загрузки и скачивания используются короткоживущие подписанные ссылки;
• критичные данные защищаются версиями и, при необходимости, Object Lock;
• действия с объектами и правами журналируются;
• команда регулярно проверяет не только резервное копирование, но и восстановление;
• возможности конкретного S3-совместимого хранилища проверяются на тестовом контуре.

S3-бакет – это логический контейнер для объектов (резервных копий, документов, изображений, видео, логов и данных приложений). Доступ к нему выполняется через S3 API, а решения о разрешенных операциях принимаются на основании учетных данных и политик.

Для практической защиты недостаточно не допустить публичного чтения. Необходимо одновременно обеспечить:

• конфиденциальность – чтобы объект получал только тот пользователь или сервис, которому он нужен;
• целостность – дабы файл нельзя было незаметно подменить или повредить;
• доступность – когда данные можно получить в нужный момент, в том числе после сбоя;
• восстанавливаемость – ошибочное удаление или перезапись не становятся необратимыми;
• наблюдаемость – команда сможет установить, кто, когда и с какими объектами выполнял операции.

Эти задачи решают разные механизмы. Шифрование не исправляет слишком широкую политику доступа. Версионирование (Versioning) не заменяет независимую резервную копию. Object Lock защищает объект от удаления в течение заданного срока, но не определяет, кто имеет право его прочитать.

До настройки политик полезно составить модель угроз: какие данные хранятся, кто с ними работает и какие ошибки наиболее вероятны.

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

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

1. Пользователь авторизуется в приложении.
2. Backend проверяет роль, тип документа, допустимый размер и бизнес-объект, к которому относится файл.
3. Backend формирует ключ объекта и создает короткоживущую подписанную ссылку на загрузку.
4. Браузер передает файл напрямую в закрытый бакет или префикс pending.
5. Система проверяет фактический формат, размер, контрольную сумму и безопасность содержимого.
6. После успешной проверки объект переводится в рабочий статус, а сведения о нем сохраняются в прикладной базе данных.
7. Для скачивания приложение снова проверяет права и выдает отдельную временную ссылку.

Такая схема снимает передачу тяжелого файла с backend, но не отдает клиенту постоянный доступ к S3.

Закрывайте бакеты по умолчанию

Первое правило – не делать бакет публичным только ради удобной загрузки или выдачи файлов. Сложное имя бакета или объекта не является защитой: URL может попасть в историю браузера, аналитическую систему, переписку или журнал приложения.

В S3-совместимом хранилище PC-Storage реализованы IAM для создания пользователей, и ACL и Bucket Policies для определения прав пользователей. По умолчанию бакеты приватные. В других объектных хранилищах набор и семантика защитных переключателей могут отличаться, поэтому необходимо отдельно проверить ACL, Bucket Policy и поведение публичных объектов в документации выбранного решения.

Если часть контента должна быть открыта посетителям сайта, лучше отделить ее от приватных данных:

• публичные изображения – в отдельный бакет или префикс публикации;
• исходники – в закрытый контур;
• документы пользователей – в приватный бакет;
• временные загрузки – в «ожидание» или «карантин»;
• резервные копии – в отдельный бакет с самостоятельными учетными данными и политикой хранения.

Такое разделение упрощает политики и снижает вероятность того, что изменение доступа для одной задачи затронет все данные.

Выдавайте сервисам минимальные права

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

Права удобно проектировать от операций:

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

Ниже упрощенный пример Bucket Policy в PC-Storage S3. Он разрешает сервисной роли читать только объекты из префикса reports/. Это пример логики, а не готовая политика для копирования: идентификаторы, поддерживаемые условия и формат «principal» нужно сверить с документацией конкретного S3-хранилища.

{

«Version»: «2012-10-17»,

«Id»: «AllowAllPolicy»,

«Statement»: [

{

«Sid»: «AllowStatement»,

«Effect»: «Allow»,

«Principal»: {

«AWS»:»64ef2deea0c47250f3ff4117″

},

«Action»: [«s3:*»],

«Resource»: [

«arn:aws:s3:::yourbucket»,

«arn:aws:s3:::yourbucket/*»

]

}

]

}

Избыточное разрешение s3:* удобно на этапе быстрого прототипа, но опасно в рабочем контуре. Ошибка приложения с такой ролью может изменить политики, удалить объекты или затронуть соседние данные.

Не передавайте постоянные S3-ключи клиентскому приложению

Access Key и Secret Key – это учетные данные сервисного уровня. Их нельзя встраивать в JavaScript, мобильное приложение, настольный клиент, публичный образ контейнера или файл конфигурации в репозитории. Даже если интерфейс скрывает значение, пользователь может извлечь секрет из кода, памяти приложения или сетевого окружения.

Для серверных компонентов постоянные ключи также не должны храниться в исходном коде. Рабочие варианты зависят от инфраструктуры:

• менеджер секретов;
• защищенные переменные среды в системе развертывания;
• временные учетные данные;
• отдельная сервисная учетная запись для каждого приложения;
• автоматическая ротация ключей;
• запрет вывода секретов в логи и диагностические сообщения.

Ротация должна быть процессом, а не разовой инструкцией. Сначала выпускается новый ключ, затем сервис переводится на него, после проверки старый ключ отзывается. Если удалить действующий секрет до обновления приложения, защита превратится в простой.

Используйте presigned URL для ограниченной операции

Presigned URL – это подписанная ссылка, которая временно разрешает конкретную S3-операцию без передачи пользователю постоянных учетных данных. Ее можно применять для прямой загрузки файла из браузера или выдачи приватного объекта после авторизации.

Подписанная ссылка наследует полномочия учетной записи, которая ее создала. Если сервисная роль может читать весь бакет, ошибка в генераторе ссылок потенциально затронет весь бакет. Поэтому минимальные права нужны и для роли, выпускающей URL.

Важно учитывать ограничения:

• ссылка работает как токен, и тот, кто получил URL, может использовать его до истечения срока;
• она разрешает операцию с объектом, но не проверяет бизнес-права повторно при каждом байте передачи;
• ссылка на загрузку не определяет, безопасно ли содержимое файла;
• повторная загрузка по тому же ключу может перезаписать объект, если это разрешено;
• срок ссылки не должен быть длиннее реальной пользовательской операции.

В PC-Storage S3 срок presigned URL зависит от способа создания и срока жизни учетных данных. Например, ссылка, созданная временными учетными данными, перестает работать после истечения или отзыва этих учетных данных, даже если в URL указан более поздний срок. У разных S3-совместимых провайдеров ограничения могут отличаться.

CORS не является системой авторизации

CORS (Cross-Origin Resource Sharing, совместное использование ресурсов между источниками) определяет, каким сайтам браузер разрешает выполнять запросы к S3 из клиентского кода. Он нужен, например, для прямой загрузки по подписанной ссылке с домена интернет-магазина.

Но CORS не заменяет политику доступа. Он ограничивает поведение браузера, а запрос через серверный клиент, curl, AWS CLI или другой инструмент не обязан подчиняться браузерной модели. Если объект публичен или ключ скомпрометирован, строгий список CORS-origin сам по себе не закроет данные.

Узко настраивайте CORS:

• указывайте конкретные домены вместо *, если это возможно;
• разрешайте только необходимые методы, например PUT и GET;
• не открывайте лишние заголовки;
• проверяйте preflight-запросы из реального браузера;
• отдельно тестируйте доступ вне браузера.

Проверяйте файл после загрузки

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

Непроверенную загрузку лучше считать недоверенной и помещать в закрытый контур. Конвейер проверки может включать:

• ограничение размера до выдачи ссылки и контроль фактического размера после загрузки;
• проверку MIME-типа и сигнатуры файла, а не только расширения;
• антивирусную проверку;
• декодирование изображения или медиаконтента;
• удаление нежелательных метаданных;
• вычисление контрольной суммы;
• проверку владельца и связи с бизнес-объектом;
• модерацию содержимого;
• перевод объекта из «pending» в «approved» только после успешного завершения всех стадий.

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

Шифруйте передачу и данные, но не подменяйте шифрованием контроль доступа

При передаче объектов следует использовать HTTPS с актуальной версией TLS. Это защищает запрос и содержимое от перехвата между клиентом и S3 endpoint.

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

• серверное шифрование проще для приложений, но необходимо понять, кто управляет ключами и где они находятся;
• клиентское шифрование позволяет не передавать открытые данные провайдеру, но усложняет поиск, обработку, восстановление и ротацию ключей;
• отдельные ключи для разных классов данных уменьшают область воздействия, но увеличивают операционную сложность.

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

До внедрения проверьте:

1. Какие режимы шифрования поддерживает выбранное хранилище.
2. Кто создает, хранит, меняет и отзывает ключи.
3. Что произойдет с данными при потере ключа.
4. Попадают ли идентификаторы или сами ключи в журналы.
5. Как выполняется восстановление зашифрованной резервной копии.

Versioning

Versioning, или версионирование, сохраняет несколько версий объекта с одним ключом. Если приложение загрузило новый report.csv или выполнило обычное удаление, предыдущую версию можно восстановить.

Версионирование полезно против ошибок, но требует управления:

• старые версии занимают место;
• правила жизненного цикла не должны удалять их раньше необходимого срока;
• доступ к окончательному удалению версии нужно ограничивать отдельно;
• восстановление следует регулярно проверять;
• приложение должно корректно работать с delete marker и идентификаторами версий, если они используются реализацией.

Object Lock

Object Lock реализует модель WORM (Write Once Read Many, однократная запись и многократное чтение) и защищает конкретную версию объекта от удаления или перезаписи в течение срока хранения либо до снятия legal hold, если такой режим поддерживается.

В PC-Storage Object Lock работает вместе с Versioning и защищает именно версию объекта. Создание новой версии с тем же ключом возможно, а защищенная версия продолжает храниться до завершения срока хранения. У S3-совместимого решения детали режимов Governance, Compliance, retention и legal hold нужно проверить отдельно.

Object Lock особенно полезен для критичных резервных копий, финансовых документов и материалов расследования. Но ошибочно заданный срок может помешать законному удалению данных и увеличить стоимость хранения. Перед включением нужно определить:

• какие объекты действительно должны быть неизменяемыми;
• кто задает срок;
• можно ли его увеличить или обойти в выбранном режиме;
• как политика связана с юридическими требованиями;
• что произойдет с приложением при попытке перезаписи;
• кто контролирует накопление защищенных версий.

Почему Versioning и Object Lock не равны резервной копии

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

Для критичных данных полезно разделять:

• рабочее хранилище;
• версионную историю;
• неизменяемую копию;
• копию в отдельном административном или инфраструктурном контуре.

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

Журналируйте операции с данными и правами

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

Минимальный набор событий зависит от возможностей провайдера, но обычно включает:

• создание и удаление бакетов;
• изменение Bucket Policy, ACL и CORS;
• выпуск, замену и отзыв ключей;
• загрузку, чтение, копирование и удаление объектов;
• массовые операции;
• ошибки авторизации;
• изменение Versioning и Object Lock;
• выдачу подписанных ссылок на уровне приложения;
• административные входы и изменения ролей.

Логи безопасности желательно отправлять в отдельный контур, куда учетная запись рабочего приложения не может вносить изменения. Иначе злоумышленник или ошибочный скрипт сможет удалить одновременно объект и след операции.

Полезные сигналы для мониторинга:

Одного сбора логов недостаточно. Для критичных событий нужны правила обнаружения, ответственный и понятное действие: отозвать ключ, закрыть политику, остановить сервисную роль или сохранить журнал для расследования.

Разделяйте данные по назначению и сроку хранения

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

Перед проектированием составьте карту:

Такой документ помогает определить бакеты, префиксы, сервисные роли, lifecycle-правила и необходимость неизменяемости до написания первой политики.

Проверяйте конфигурацию как атакующий и как оператор восстановления

Успешный PutObject не доказывает безопасность интеграции. До запуска необходимо проверить разрешенные и запрещенные действия с каждой ролью.

Для S3-совместимого endpoint базовая диагностика через AWS CLI может выглядеть так:

aws —endpoint-url https://eu-s3.platformcraft.com s3api list-buckets

aws —endpoint-url https://eu-s3.platformcraft.com s3api put-object \

—bucket app-pending \

—key uploads/test.txt \

—body test.txt

aws —endpoint-url https://eu-s3.platformcraft.com s3api get-object \

—bucket app-pending \

—key uploads/test.txt \

downloaded.txt

Проверять нужно не только успешные операции. Попробуйте той же ролью:

• прочитать соседний префикс;
• удалить объект;
• получить список всего бакета;
• изменить Bucket Policy;
• открыть объект без подписи;
• повторно использовать истекшую presigned URL;
• загрузить файл большего размера или другого типа;
• восстановить предыдущую версию;
• удалить защищенную версию;
• выполнить запрос после отзыва ключа.

Ожидаемый отказ следует фиксировать так же явно, как ожидаемый успех. Это превращает модель доступа в проверяемый контракт.

План реагирования лучше подготовить до инцидента. Минимальная последовательность:

1. Определить скомпрометированную учетную запись и затронутые сервисы.
2. Отозвать или деактивировать ключ, не удаляя доказательства инцидента.
3. Перевести приложение на новый секрет через штатную процедуру ротации.
4. Проверить журналы чтения, записи, удаления и изменения политик за соответствующий период.
5. Сравнить текущие политики с эталонной конфигурацией.
6. Найти новые версии, delete marker, массовые операции и необычные скачивания.
7. Восстановить данные из версий или независимой копии.
8. Устранить источник утечки: репозиторий, образ, лог, рабочая станция или процесс развертывания.
9. Обновить правила обнаружения и сократить права учетной записи.

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

Перед вводом в эксплуатацию проверьте:

1. Составлена карта данных, владельцев и сроков хранения.
2. Публичные, приватные, временные и резервные данные разделены.
3. Бакеты закрыты по умолчанию.
4. Публичный доступ разрешен только там, где он действительно нужен.
5. Для каждого сервиса создана отдельная учетная запись или роль.
6. Права ограничены операциями, бакетами и префиксами.
7. Постоянные ключи отсутствуют в браузере, приложении и репозитории.
8. Секреты хранятся централизованно и имеют процедуру ротации.
9. Для разового доступа используются короткоживущие presigned URL.
10. CORS настроен отдельно и не считается авторизацией.
11. Непроверенные файлы попадают в закрытый контур.
12. После загрузки проверяются размер, тип, сигнатура и безопасность файла.
13. Передача выполняется через HTTPS.
14. Для критичных данных определены Versioning, Object Lock и независимая копия.
15. Lifecycle не удаляет необходимые версии раньше срока.
16. Изменения политик, ключей и защитных механизмов журналируются.
17. Логи защищены от изменения рабочим приложением.
18. Настроены сигналы на массовое удаление, необычное чтение и ошибки доступа.
19. Проверены запрещенные операции для каждой роли.
20. Выполнено тестовое восстановление после удаления и перезаписи.
21. Подготовлен план действий при утечке ключа.
22. Реализация IAM, ACL, Bucket Policy, presigned URL, Versioning и Object Lock проверена у конкретного S3-провайдера.

Как применить эти меры в PC-Storage

PC-Storage – это S3-совместимое объектное хранилище собственной разработки PlatformCraft. Его можно подключать к приложениям через S3 REST API и стандартные инструменты, указывая endpoint сервиса.

В решении доступны основные операции с бакетами и объектами, ACL и Bucket Policy, presigned URL, CORS, Versioning, Object Lock, multipart upload и пользовательские метаданные, что позволяет строить описанные выше контуры:

• закрывать исходные данные,
• выдавать временный доступ к отдельному объекту,
• разделять роли и защищать критичные версии от удаления.

При этом PC-Storage не заменяет прикладную авторизацию. Приложение по-прежнему определяет, какому пользователю принадлежит файл, можно ли ему скачать документ, прошел ли объект модерацию и когда закончился юридический срок хранения.

Во время тестового периода вы можете проверить именно свой сценарий, а также: совместимость используемого SDK; подпись запросов и работу endpoint; разрешенные и запрещенные операции каждой учетной записи; прямую загрузку по presigned URL; поведение CORS в браузере; восстановление версии; режим и срок Object Lock; журналирование и ротацию ключей и прочее.

Как закрыть S3-бакет от публичного доступа?

Запретите публичные ACL и политики, проверьте настройки блокировки публичного доступа и протестируйте чтение объекта без учетных данных. В S3-совместимом хранилище названия и поведение механизмов могут отличаться, поэтому используйте документацию конкретного провайдера.

Можно ли хранить Access Key и Secret Key в приложении?

В серверном приложении секреты нужно получать из защищенного хранилища или системы развертывания. В браузерном и мобильном приложении постоянных S3-ключей быть не должно: для отдельных операций лучше выдавать короткоживущие подписанные ссылки.

Защищает ли presigned URL весь бакет?

Нет. Ссылка разрешает конкретную операцию с указанным объектом на ограниченное время. Ее безопасность зависит от прав учетной записи, срока действия, корректности ключа объекта и того, кому URL стал доступен.

Нужен ли антивирус, если файл загружается прямо в S3?

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

Чем Versioning отличается от Object Lock?

Versioning хранит предыдущие версии объекта и помогает восстановиться после перезаписи или обычного удаления. Object Lock защищает конкретную версию от удаления или изменения в течение заданного срока либо до снятия legal hold. Точная семантика зависит от реализации S3.

Заменяет ли Object Lock резервное копирование?

Нет. Неизменяемая версия может оставаться в том же инфраструктурном и административном контуре. Для критичных данных нужна независимая копия и проверенный процесс восстановления.

Нужно ли шифровать данные в S3?

Для чувствительных данных обычно требуется защита при передаче и хранении. Конкретный режим зависит от модели угроз и требований к ключам. Шифрование нужно сочетать с минимальными правами, журналированием и контролем доступа.

Как проверить безопасность S3-совместимого хранилища?

Создайте тестовые роли и выполните как разрешенные, так и запрещенные операции через используемый SDK или AWS CLI с пользовательским endpoint. Отдельно проверьте публичный доступ, presigned URL, CORS, версии, Object Lock, отзыв ключа, журналирование и восстановление.