Секреты и управление ключами

Секреты это пароли к базам, API-ключи, токены, приватные ключи, ключи шифрования. Утечка секрета часто опаснее уязвимости в коде: с ключом облака атакующему не нужно ничего ломать.

Где секреты утекают

• Код и git: ключ в конфиге «временно», закоммичен, потом удалён. В истории git он остаётся навсегда, а публичные репозитории сканируют боты за минуты.
• Логи: токены в URL, заголовки запросов, тела с паролями, дампы переменных окружения в отладке.
• Образы контейнеров: ENV API_KEY=... или скопированный .env в слое образа.
• CI/CD: секрет в YAML-файле пайплайна, вывод echo $TOKEN, секреты доступны пулреквестам из форков.
• Клиентский код: «секретный» ключ в мобильном приложении или JavaScript фронтенда виден всем. На клиенте секретов нет.
• Мессенджеры, тикеты, вики.

Где хранить

• Хранилище секретов: HashiCorp Vault (или его форк OpenBao), облачные Secrets Manager и Key Vault, Lockbox в Yandex Cloud. Доступ по ролям, аудит, версии, ротация.
• Переменные окружения приемлемы как способ доставки в процесс, но их видно в /proc, в дампах, в логах падений. Лучше монтировать файлом или читать из хранилища при старте.
• Kubernetes Secrets по умолчанию просто base64 в etcd: нужно включить шифрование etcd, ограничить RBAC, а лучше подключить внешнее хранилище (External Secrets, CSI driver).
• Зашифрованные файлы в репозитории (SOPS, sealed-secrets) для GitOps: в git только шифртекст, ключ в KMS.

Ключи шифрования: KMS и envelope encryption

Данные шифруют не мастер-ключом напрямую, а схемой конвертов:

1. Для данных генерируется ключ данных (DEK).
2. Данные шифруются DEK локально.
3. DEK шифруется мастер-ключом (KEK) в KMS или HSM, мастер-ключ никогда не покидает KMS.
4. Хранится шифртекст данных и зашифрованный DEK.

Плюсы: мастер-ключ не утечёт с сервера, ротация мастер-ключа не требует перешифровывать все данные, доступ к расшифровке контролируется и логируется в KMS.

Ротация и минимальные права

• У каждого сервиса свой секрет с минимальными правами, а не один общий ключ админа.
• Короткоживущие учётные данные лучше долгоживущих: динамические пароли БД от Vault, OIDC-федерация CI с облаком вместо статических ключей, роли сервисных аккаунтов.
• Регулярная ротация и готовая процедура экстренной ротации: если для смены ключа нужен релиз и неделя, это проблема.

Если секрет утёк

1. Отозвать и перевыпустить секрет немедленно. Удаление из git не помогает: копии уже есть.
2. Проверить логи провайдера: использовался ли ключ, откуда, что сделано.
3. Оценить ущерб и при необходимости запустить реагирование на инцидент.
4. Почистить историю (git filter-repo) как гигиену, но не вместо отзыва.
5. Найти причину и закрыть её: сканер, pre-commit, обучение.

Сканирование

• Pre-commit хуки (gitleaks, detect-secrets) ловят секрет до коммита.
• Сканер в CI и по всей истории репозиториев (gitleaks, trufflehog).
• Push protection платформ (GitHub, GitLab) блокирует пуш с известными форматами ключей.
• Провайдеры участвуют в программах сканирования: найденный в публичном репозитории ключ может быть автоматически отозван.

Частые ошибки

• «Удалили коммит, значит, всё в порядке».
• Один ключ на все окружения и сервисы.
• Секреты в docker build args и слоях образа.
• .env в репозитории «только для dev», а там прод-ключи.
• Логирование заголовка Authorization.

Что спросят на собесе

• Где хранить секреты приложения и почему не в коде.
• Что делать, если ключ попал в публичный репозиторий.
• Что такое envelope encryption и зачем KMS.
• Как безопасно передать секреты в Kubernetes.
• Как дать CI доступ к облаку без статических ключей.