Пароли в облаке: как безопасно управлять доступами когда инфраструктура в российских облаках
Миграция в облако резко ускорилась после 2022 года. Российские компании переходят на Яндекс Облако, VK Cloud, SberCloud, МТС Cloud и другие отечественные платформы. Это решает задачу импортозамещения — но порождает новые вопросы для безопасности.
Инфраструктура в облаке управляется через API-ключи, сервисные аккаунты, консольные пароли. Их значительно больше чем в on-premise среде. Они ротируются чаще. И если они хранятся там же где хранится сама инфраструктура — это единственная точка отказа.
Чем облачная инфраструктура отличается с точки зрения управления паролями
API-ключи вместо паролей. Доступ к облачным ресурсам осуществляется преимущественно через API-ключи и токены сервисных аккаунтов, а не через традиционные пары логин-пароль. У каждого сервиса своя система: Yandex Cloud IAM tokens, VK Cloud API keys, SSH-ключи для виртуальных машин, пароли к managed-базам данных.
Большее количество учётных данных. В облаке легко создать десятки сервисных аккаунтов, ключей и токенов — и потерять им счёт. Инвентаризация учётных данных в облачной среде без централизованного хранилища быстро становится неуправляемой.
Ротация по расписанию. Лучшая практика облачных провайдеров — ротировать API-ключи каждые 90 дней. Без централизованного управления это превращается в ручную операцию которую нередко откладывают бесконечно.
Риск хардкодинга. Разработчики нередко вписывают API-ключи прямо в код или в конфигурационные файлы на серверах «чтобы работало». Попавший в репозиторий ключ или ключ на скомпрометированном сервере — немедленная компрометация.
Почему on-premise менеджер паролей нужен даже при облачной инфраструктуре
Распространённое заблуждение: раз инфраструктура в облаке — и управление паролями тоже должно быть в облаке.
Это логика которая создаёт единую точку отказа. Если облачный аккаунт скомпрометирован — злоумышленник получает доступ и к инфраструктуре и к ключам от неё одновременно.
Правильная архитектура разделяет эти слои. Инфраструктура в облаке. Управление доступами к ней — в on-premise системе на отдельном сервере который физически или логически изолирован от облачной среды.
Если злоумышленник компрометирует облачную инфраструктуру — у него нет доступа к хранилищу ключей. Если скомпрометировано хранилище ключей — у него нет прямого доступа к облачным ресурсам без прохождения дополнительной аутентификации.
Как организовать хранение облачных ключей в BearPass
Структура папок по облачным провайдерам и проектам. Создаётся иерархия: папка «Яндекс Облако» → подпапки по проектам → внутри каждой ключи с типами (IAM-токены, SSH-ключи, пароли к managed-сервисам).
RBAC по ролям. Разработчик backend-сервиса видит ключи своего проекта. DevOps-инженер видит инфраструктурные ключи. Разработчик фронтенда не видит ничего из production. Администратор БД видит только ключи к управляемым базам данных.
Получение ключей через API в пайплайнах. Для CI/CD пайплайнов которые деплоят в облако — паттерн получения ключей через BearPass REST API в момент выполнения. Ключ не хранится в переменных окружения платформы, не попадает в логи, используется только в текущей сессии.
bash
# Получение Yandex Cloud API ключа из BearPass
YC_TOKEN=$(bearpass get "YC Production IAM Token" \
--field password \
--server "$BEARPASS_URL" \
--token "$CI_JWT")
yc config set token "$YC_TOKEN"
yc serverless function deploy ...
Ротация ключей. При ротации API-ключа в облаке — сразу обновить его в BearPass. Журнал изменений фиксирует кто и когда обновил ключ. Политика паролей в BearPass настроена на срок жизни 90 дней — система уведомит о приближении срока.
Аудит активности. Журнал BearPass показывает кто и когда обращался к каждому облачному ключу. При подозрении на компрометацию — видна вся история использования конкретного ключа за весь период хранения.
Специфика разных российских облаков
Яндекс Облако. Использует IAM-токены (краткоживущие, до 12 часов) и API-ключи (долгоживущие). Рекомендуется хранить API-ключи в BearPass и получать их через CLI при необходимости. IAM-токены генерируются автоматически и не требуют хранения.
VK Cloud (Mail.ru Cloud Solutions). Использует access key и secret key по модели аналогичной AWS S3 API. Оба ключа требуют надёжного хранения — особенно secret key который показывается только один раз при создании.
SberCloud. Аналогичная модель с проектными ключами и сервисными аккаунтами. Рекомендации те же: централизованное хранение, ротация по расписанию, RBAC по проектам.
SSH-ключи для виртуальных машин. Во всех облаках доступ к виртуальным машинам осуществляется через SSH-ключи. Приватные ключи должны храниться в централизованном хранилище с ограниченным доступом — не на рабочих станциях разработчиков.
Чеклист безопасности для облачной инфраструктуры
Используйте этот список чтобы проверить текущее состояние управления ключами в вашей облачной среде.
- Все API-ключи и токены хранятся в централизованном защищённом хранилище, а не в файлах на серверах и репозиториях.
- Для каждого проекта и сервиса создан отдельный сервисный аккаунт с минимальными необходимыми правами — не используется общий аккаунт «для удобства».
- Настроена политика ротации ключей: API-ключи обновляются не реже раза в 90 дней.
- CI/CD пайплайны получают ключи через API хранилища, а не из переменных окружения платформы.
- RBAC настроен: каждый разработчик и инженер имеет доступ только к ключам нужных ему проектов.
- Журнал событий фиксирует каждое обращение к ключам — кто, когда, какой ключ.
- Настроен алерт при доступе к production-ключам вне рабочего времени.
Итог
Облачная инфраструктура не упрощает задачу управления паролями — она усложняет её. API-ключи, токены, SSH-ключи к виртуальным машинам, пароли к managed-базам данных — всё это требует централизованного управления с RBAC и журналом событий.
On-premise менеджер паролей на отдельном сервере — правильная архитектура для облачной инфраструктуры. Разделение хранилища ключей и самой инфраструктуры — базовый принцип защиты от компрометации.