Безопасность S3 bucket: права, ссылки, шифрование и аудит

Почему безопасность S3 bucket нельзя оставлять на потом

S3 bucket нельзя воспринимать как обычную папку, перенесенную в облако. Это инфраструктурный ресурс с собственными правилами доступа, API, сервисными ключами, политиками, ссылками и журналами операций. Ошибка в одной настройке может открыть для злоумышленников документы, резервные копии или пользовательские файлы.

Безопасность S3 bucket строится вокруг нескольких уровней:

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

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

Чем опасен публичный bucket

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

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

• Bucket Policy;
• ACL бакета или объекта;
• публичный access point;
• CDN или прокси без авторизации;
• приложение с ошибкой в проверке прав;
• постоянная ссылка на объект;
• неверно настроенный сервисный аккаунт.

Например, в PC-Storage (S3-совместимое хранилище PlatformCraft) новые бакеты и объекты по умолчанию являются закрытыми. Для управления доступом рекомендуется использовать Bucket Policies, поскольку ACL считается устаревшим механизмом и применяется только в виде предустановленных настроек (бакет может быть публичным или приватным). Но администратор может изменить эти настройки, поэтому сам факт создания приватного бакета не отменяет последующий аудит.

Почему S3 bucket не просто «папка с файлами»

Бакет – это логический контейнер для объектов, доступ к которым выполняется через API. Права на просмотр списка объектов, скачивание файла, загрузку и удаление являются разными разрешениями.

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

Особенно важно разделять:

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

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

Какие данные чаще всего хранят в S3

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

Не стоит без необходимости смешивать в одном бакете:

• публичные изображения сайта;
• пользовательские документы;
• персональные данные;
• резервные копии;
• логи безопасности;
• видеоархив;
• служебные файлы приложения;
• данные типа: dev, stage и

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

К типовым причинам инцидентов относятся следующие ситуации:

1. Бакет или отдельные объекты открыты публично.
2. Приложение получило права администратора вместо минимального набора операций.
3. AccessKey и SecretKey попали в репозиторий, журнал или клиентский код.
4. Несколько сервисов используют одну учетную запись.
5. Приватные файлы раздаются по постоянным ссылкам.
6. Не включены журналы запросов и действий.
7. Отсутствует версионирование важных данных.
8. Резервные копии можно удалить тем же ключом, которым они создаются.
9. Публичные объекты используются чужими сайтами, создавая неконтролируемый трафик.
10. Логи хранятся без защиты от изменения и удаления.

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

IAM-пользователи, роли и сервисные аккаунты

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

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

• backend-приложения;
• системы резервного копирования;
• CI/CD;
• медиаплатформы;
• аналитические системы;
• CDN;
• интеграционные сервисы;
• рабочие процессы обработки данных.

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

Для сред, поддерживающих временные учетные данные и роли, они предпочтительнее постоянных статических ключей. Если используются Access Key и Secret Key, их нужно хранить централизованно, регулярно ротировать и отзывать после завершения проекта или смены владельца сервиса.

Что такое Bucket Policy

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

С помощью политики можно:

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

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

Что такое ACL и почему с ними нужно быть осторожнее

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

Одновременное использование IAM, Bucket Policy и ACL усложняет анализ итогового доступа. Администратор может закрыть объект политикой, но случайно оставить разрешение в ACL, либо наоборот.

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

Доступ на уровне префикса

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

Например:

• приложение работает только с uploads/app-1/;
• резервная система работает с backups/prod/;
• аналитика читает reports/, но не пользовательские документы;
• клиент SaaS получает доступ только к tenants/client-42/;
• CI/CD публикует файлы только в releases/frontend/.

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

Что считается публичным доступом

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

Публичность допустима для сознательно открытых материалов:

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

Но даже в этих случаях безопаснее отделить публичные данные от приватных и по возможности раздавать их через CDN. Документы клиентов, платные видео, резервные копии и внутренние файлы не должны открываться ради «удобства».

Как проверить, не открыт ли бакет

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

1. Изучить Bucket Policy.
2. Проверить настройки публичного доступа.
3. Попробовать получить тестовый приватный объект без авторизации.
4. Проверить точки доступа, CDN, прокси и приложение.
5. Найти политики с Principal: * и wildcard-разрешениями.
6. Проверить, доступен ли LIST без учетных данных.
7. Убедиться, что публичные данные отделены от приватных.

Важно тестировать не только прямой endpoint хранилища. Иногда origin закрыт, но приложение или CDN раздают файлы без проверки доступа.

Также проверьте:

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

Почему постоянные публичные ссылки опасны

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

Особенно опасно раздавать постоянными URL:

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

Удаление ссылки со страницы не закрывает доступ к объекту, если URL уже известен.

Что такое presigned URL

Presigned URL — это временная подписанная ссылка, позволяющая загрузить или скачать объект без передачи пользователю постоянных учетных данных. Ссылка использует права того субъекта, который ее создал.

Типовой безопасный сценарий выглядит следующим образом:

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

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

Как выбрать срок жизни ссылки

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

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

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

Когда нужны CDN-токены и авторизация приложения

Presigned URL подходят для точечной работы с объектом. Но для массовой доставки видео, изображений и документов чаще требуется origin-сервер, CDN, подписанные CDN-ссылки или cookies, токенизация, ограничения по времени/географии/сессии, авторизация на уровне приложения и защита от hotlinking.

Так origin-бакет не откроется напрямую, а правила публичной доставки будут контролироваться отдельным уровнем.

Access Key и Secret Key дают приложению возможность действовать от имени сервисного аккаунта. Если секрет попал в репозиторий, frontend или мобильное приложение, его нужно считать скомпрометированным.

Секреты нельзя размещать:

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

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

Как ограничивать сервисные ключи

Для каждого сервиса нужно определить:

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

Backup-сервису может требоваться запись и чтение для проверки, но право удаления старых копий можно передать отдельному процессу. CDN же нужен доступ на чтение объектов, но не изменение политики или удаление.

Что делать при утечке ключа

1. Немедленно отключить или отозвать ключ.
2. Создать новые учетные данные с минимальными правами.
3. Проверить журналы операций за период возможной компрометации.
4. Найти чтение, выгрузку, удаление и изменение политик.
5. Проверить созданные пользователи, ключи и временные ссылки.
6. Заменить секрет во всех зависимых сервисах.
7. Удалить ключ из истории репозитория и журналов.
8. Зафиксировать причины инцидента и изменить процесс хранения секретов.

Простая замена ключа в актуальном файле не удаляет его из истории Git.

В PlatformCraft S3 данные передаются только по защищенному соединению HTTPS/TLS. Во время TLS-рукопожатия клиент и сервер согласовывают параметры шифрования и проверяют подлинность друг друга с использованием SSL/TLS-сертификатов, что защищает данные от перехвата при передаче, предотвращает атаки типа «man-in-the-middle» и обеспечивает конфиденциальность сетевого трафика.

Для аутентификации и авторизации запросов используется HMAC-SHA256. Каждый запрос к S3 подписывается криптографической подписью, что позволяет удостовериться, что операции чтения и записи выполняют только авторизованные клиенты.

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

При этом серверное шифрование объектов (Server-Side Encryption, SSE), как в AWS, не поддерживается. Если данные требуется хранить в зашифрованном виде, их необходимо зашифровать до загрузки в хранилище. Вы выполняете шифрование на своей стороне до отправки данных в хранилище, соответственно, управление ключами остается на стороне пользователя или внешней системы управления ключами.

Зачем включать версионирование

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

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

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

Что такое Object Lock

Object Lock запрещает изменять или удалять версию объекта в течение установленного срока или до снятия legal hold. Механизм использует модель WORM: write once, read many.

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

В PC-Storage Object Lock работает с версионированием, режимами Governance и Compliance, retention period и legal hold.

Чем retention отличается от backup

Retention определяет, как долго объект нельзя изменить или удалить. Backup создает дополнительную копию, которую можно восстановить после сбоя исходной системы.

Для критичных данных нужны оба уровня:

• резервная копия в независимом контуре;
• версионирование;
• запрет удаления на необходимый срок;
• тест восстановления.

Какие события нужно логировать

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

Особое внимание требуют:

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

Access logs и audit logs

Access logs описывают запросы к хранилищу, а audit logs помогают восстановить последовательность административных и объектных действий. Для расследования инцидентов часто нужны оба типа.

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

Логи сами являются чувствительными данными. Они могут раскрывать:

• имена объектов;
• IP-адреса;
• учетные записи;
• время обращений;
• структуру систем;
• ошибки авторизации.

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

Как безопасно раздавать изображения, видео и документы

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

Для интернет-магазина безопасная модель может выглядеть так:

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

Для онлайн-школы:

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

Защита от hotlinking

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

Для защиты используют:

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

Проверка Referer сама по себе не является надежной авторизацией: заголовок может отсутствовать или подменяться.

Почему backup-бакет должен быть изолирован

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

Backup-бакет стоит отделять:

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

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

Почему необходим тест восстановления

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

Тестировать нужно не только скачивание одного файла, но и реальный сценарий:

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

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

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

• бакет приватен по умолчанию;
• публичный доступ запрещен на доступном уровне;
• ACL отключены или используются осознанно;
• BucketPolicy не содержит неоправданных разрешений;
• у каждого сервиса отдельный ключ, пользователь или роль;
• права ограничены конкретными действиями, бакетами и префиксами;
• приложения не используют административные ключи;
• секреты хранятся в защищенном хранилище;
• включен HTTPS/TLS;
• проверена настройка шифрования данных;
• для важных данных включено версионирование (Versioning);
• для критичных бэкапов рассмотрен Object Lock;
• включены access logs и audit logs;
• журналы защищены от удаления и изменения;
• настроены оповещения о подозрительных действиях;
• приватные файлы выдаются через presigned URL или другой контролируемый механизм;
• срок действия временных ссылок соответствует сценарию;
• публичные медиа раздаются через управляемый CDN-контур;
• dev, stage и production разделены;
• определены владелец бакета, назначение данных и срок хранения;
• права и ключи регулярно пересматриваются;
• восстановление важных данных тестируется.

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

PC-Storage – российское S3-совместимое объектное хранилище, поддерживающее типовые механизмы работы с доступом и объектами: IAM, Bucket Policy, ACL, Versioning, presigned URL и Object Lock, режимы Governance и Compliance, retention period и legal hold.

Это позволяет строить разные сценарии:

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

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

1. Какие данные будут публичными.
2. Какие сервисы получат доступ.
3. Кому разрешены чтение, запись и удаление.
4. Нужны ли Versioning и Object Lock.
5. Как будут храниться и ротироваться ключи.
6. Какие события попадут в аудит.
7. Как будут выдаваться приватные файлы.
8. Как будет проверяться восстановление.

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

Что такое объект?

Объект – это файл, загруженный в объектное хранилище, вместе с его метаданными.

Что такое бакет (bucket)?

Бакет – это логический контейнер, в котором хранятся объекты. Для каждого бакета можно настроить собственные политики доступа, версионирование и другие параметры.

Чем бакет отличается от обычной папки?

Бакет имеет собственные настройки доступа, политики безопасности, журналирование и API для работы с объектами.

Как понять, открыт ли S3 bucket публично?

Проверьте Bucket Policy, ACL, настройки блокировки публичного доступа, access points, CDN и возможность получить тестовый объект без авторизации. Отдельно убедитесь, что запрос LIST недоступен публично.

Что такое Bucket Policy?

Bucket Policy – это набор правил, определяющих, кто, над какими ресурсами и при каких условиях может выполнять операции. Она применяется к бакету и объектам внутри него.

Чем Bucket Policy отличается от ACL?

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

Что такое presigned URL?

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

Насколько безопасны временные ссылки S3?

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

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

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

Что такое Access Key и Secret Key?

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

Можно ли использовать один ключ для нескольких сервисов?

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

Что делать при утечке ключей?

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

Что делать, если Access Key попал в репозиторий?

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

Какие логи нужны для S3 bucket?

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

Что такое Object Lock?

Object Lock запрещает изменять или удалять версии объектов в течение заданного срока.

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

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

Зачем Object Lock нужен для резервных копий?

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

Можно ли безопасно раздавать видео и изображения из S3?

Да. Для публичных материалов лучше использовать приватный origin, CDN, токены или подписанные ссылки. Приватные и платные файлы не следует раздавать постоянными прямыми URL.

Что такое версионирование?

Версионирование или «Versioning» сохраняет предыдущие версии объектов и позволяет восстановить данные после удаления или перезаписи.

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

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

Почему не стоит хранить все данные в одном бакете?

Разделение данных упрощает управление доступом, аудит и применение политик хранения.

Что такое принцип минимальных привилегий?

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

Какие данные нельзя делать публичными?

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

Для чего нужен HTTPS/TLS?

Он защищает данные во время передачи между клиентом и хранилищем, предотвращая их перехват.