В VK Cloud доступ к бакету можно проверять прямо на Object Storage, а не держать правила только в прокси. Для команд это меняет не только схему безопасности, но и то, как быстро ломается доступ, когда ключи уже расползлись по CI, локалкам и скриптам.
Суть события
В статье разбирают Bucket Access Policy для VK Cloud Object Storage — JSON-политику, которая живёт на самом бакете и решает, кому что можно делать с объектами. Это не косметическая настройка, а перенос точки принятия решения ближе к данным. Хранилище само проверяет правила на каждый запрос, и это сразу убирает старую зависимость от внешнего прокси, если он был единственным местом, где сидела авторизация.
Сценарий знакомый: есть nginx или внутренний сервис, есть общий S3-ключ, есть привычка раздавать его туда-сюда под задачи CI, поддержки и ручных разборов. Пока всё идёт через прокси, схема выглядит аккуратно. Но как только тот же ключ всплывает где-то ещё, прямой вызов на endpoint обходит прокси целиком. И вот уже доступ определяется не тем, что вы задумали в конфиге, а тем, что разрешено на самом бакете.
Детали
Ключевая мысль статьи простая и неприятная: если правила живут только в прокси, а у кого-то есть валидная пара ключей, он может пойти напрямую в Object Storage. В примере это бьёт по аналитикам, подрядчикам и CI. Аналитику нужен один префикс, а он внезапно видит лишнее. Подрядчик уже выключен в прокси, но старый ключ всё ещё работает. Раннер должен класть артефакты, а способен случайно снести чужой каталог. Самое скользкое здесь то, что хранилище видит всё как один и тот же аккаунтный запрос, если не сузить область ключа и не задать политику на бакете.
VK Cloud в этой логике предлагает не просто ещё один переключатель, а другой порядок действий: сначала выдать ключ с минимально нужной областью, потом закрепить ограничения политикой бакета. Для практики это важнее, чем кажется. Если доступ нужен только к одному бакету или даже к одному префиксу, можно не тащить лишнюю авторизацию в свой код и не строить отдельный мини-прокси ради одного правила. Но статья честно оставляет прокси там, где он всё ещё нужен: TLS-терминация, бизнес-логика, более тонкие лимиты и часть аудита остаются внешним задачам.
Контекст
Здесь хорошо видно более широкий сдвиг: облака всё чаще отдают базовую защиту на уровень самой платформы, а не на совесть команды. В AWS это давно стало нормой через Block Public Access и политики на ресурсы. В российском облаке логика похожая, но с местными деталями: у VK Object Storage нет прямой account-level policy как в AWS, зато есть ключи с разной областью действия, политика бакета и ACL. Для инженера это означает, что модель доступа надо читать не по привычке, а по тому, где именно в цепочке решается вопрос «можно или нельзя».
Для бизнеса это тоже не абстракция. Когда ключи живут в CI, у подрядчиков и в локальных скриптах, риск утечки превращается в риск лишнего доступа, лишних операций и лишнего инцидента. А это уже деньги: время на разбор, ручные блокировки, пересборка прав, иногда — остановка процессов, которые должны были просто читать или писать один префикс. Поэтому перенос авторизации в хранилище — это не про красоту архитектуры, а про то, где дешевле и надёжнее держать границу доступа.
Что дальше
Если у вас сейчас правила доступа живут только в прокси, стоит проверить три вещи: где лежит самый широкий S3-ключ, что произойдёт при прямом запросе на endpoint и можно ли сузить доступ ключом бакета или префикса. После этого становится ясно, что именно можно перенести в Bucket Access Policy, а что лучше оставить на внешнем слое. И да, иногда честный ответ будет: прокси ещё нужен, но уже не для авторизации. Это тоже хороший результат.
Параллельно имеет смысл посмотреть на похожие практики переноса контроля на уровень платформы — например, как меняются модели доступа в других облачных сценариях и почему <a href=»https://ai-digest.ru/anthropic-vzyala-pauzu-v-riskovannom-obuchenii-claude-posle-kiber-ocenok/»>Anthropic остановила рискованное обучение Claude после кибер-оценок</a>. Там логика другая, но вывод близкий: когда безопасность становится частью самой системы, а не внешней накладкой, команды меньше зависят от героизма и больше — от нормальной инженерии.
