2 
VK Cloud добавил в Object Storage поддержку Bucket Access Policy. Теперь правила доступа хранятся прямо в бакете в формате JSON и проверяются самим хранилищем на каждый запрос. Это позволяет убрать внешний прокси и перенести авторизацию внутрь S3-совместимого сервиса. Для команд, которые раньше держали nginx или самописный шлюз перед Ceph и MinIO, такое изменение снижает задержки и количество точек отказа. Object Storage — это масштабируемое хранилище объектов, совместимое с протоколом Amazon S3, где данные хранятся в бакетах — логических контейнерах. Bucket Access Policy представляет собой JSON-документ, который описывает разрешения на уровне всего бакета и применяется независимо от того, какой ключ доступа использован. В отличие от прокси-слоя, где правила приходилось дублировать и поддерживать отдельно, политика внутри хранилища проверяется на стороне VK Cloud. Это важно при принятии решения о переходе: сокращается число компонентов, которые могут выйти из строя, и уменьшается время отклика на запросы, поскольку не требуется дополнительная обработка на внешнем сервере. Однако перед отказом от прокси стоит оценить текущую нагрузку и убедиться, что все необходимые условия доступа можно выразить средствами политики бакета.
Как устроена проверка прав
Политика описывает, кто, какие операции и над какими объектами может выполнять. В отличие от IAM-политик ключа, она применяется на уровне бакета и не зависит от того, через какой ключ пришёл запрос. IAM-политики привязаны к конкретным ключам доступа и задают, какие действия разрешены владельцу ключа. ACL (Access Control List) — это более простой механизм, который позволяет назначать права на уровне отдельных объектов или бакетов. Хранилище последовательно проверяет три механизма: политику бакета, ACL и политику ключа. Приоритет отдаётся явному Deny, поэтому даже разрешённый ключ может получить отказ, если политика бакета его запрещает. Явный запрет имеет высший приоритет и перекрывает любые разрешения, что важно учитывать при проектировании правил: одна неправильно сформулированная строка может заблокировать легитимный доступ. При переносе готовой политики из AWS часто возникает ошибка: поле Resource содержит ARN с регионом и аккаунтом, которых нет в VK Cloud. ARN (Amazon Resource Name) — это уникальный идентификатор ресурса, который в AWS включает регион и номер аккаунта. После замены ARN на локальный формат и указания правильного Principal запросы начинают проходить. Principal определяет, к кому применяется правило — к конкретному пользователю, роли или всем. Дальше добавляют условие aws:SourceIp, чтобы ограничить доступ только по белому списку адресов. На четвёртой итерации вводят явный Deny для всех остальных источников, чтобы закрыть оставшиеся векторы. При решении о внедрении важно понимать, что политика бакета даёт централизованный контроль над ресурсами и операциями, но требует точной настройки Principal и условий, иначе возможны непредвиденные отказы в доступе.
Тестирование и метрики
Для проверки готовят матрицу из 16 комбинаций: разные ключи, IP-адреса и пути к объектам. Каждый запрос фиксируют и сравнивают с ожидаемым кодом ответа. Результаты прогона скрипта показывают долю отказов. В Cloud Audit эту метрику можно выгрузить и передать службе ИБ как доказательство разграничения доступа без скриншотов консоли. Cloud Audit — это сервис логирования событий в VK Cloud, который фиксирует все обращения к хранилищу с указанием источника, ключа и результата. Матрица из 16 комбинаций покрывает основные сценарии: разрешённый и запрещённый IP, разные ключи и пути к объектам. Это позволяет выявить конфликты между политикой бакета и политиками ключей до перевода в продакшн. При переходе с AWS S3, Ceph или MinIO нужно проверить поддержку условий aws:SourceIp и формата Principal. В VK Cloud эти поля работают, но синтаксис ARN отличается. Если проект уже использует политики ключей для ограничения по IP, их можно оставить, а бакет-политику использовать только для ресурсов и операций. При оценке целесообразности перехода важно учесть, что политики бакета не отменяют существующие политики ключей, а дополняют их; поэтому в сложных инфраструктурах требуется анализ взаимодействия всех трёх механизмов, чтобы избежать избыточных или противоречивых правил.
Применение в российских проектах
В российских контурах часто требуется хранить данные с ограниченным доступом и подтверждать разграничение при аудите. Bucket Access Policy даёт выгружаемый JSON-файл, который можно хранить в системе контроля версий и показывать регуляторам. При этом не нужно держать дополнительный прокси, что упрощает аттестацию и снижает затраты на поддержку. Команды, мигрирующие из зарубежных облаков, могут взять политику из AWS, заменить ARN и протестировать по матрице из 16 запросов. Это быстрее, чем переписывать правила под каждый S3-совместимый продукт заново. Для российских проектов критично наличие выгружаемого артефакта политики: он служит доказательством соблюдения требований по разграничению доступа и может быть версионирован вместе с кодом приложения. Отказ от прокси также уменьшает поверхность атаки и количество компонентов, подлежащих аттестации. Перед полным отказом от внешнего шлюза рекомендуется провести нагрузочное тестирование и убедиться, что политика бакета справляется с нужным объёмом проверок без заметного роста задержек.
Источник
Это краткий разбор материала VK. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Политики бакетов вместо прокси в S3.
Курс по теме — Каталог курсов Школы Больших Данных
