Сообщить об ошибкеКороткий ответ
Нужно выбрать между статическими долгоживущими секретами с периодической ручной ротацией и динамическими краткоживущими секретами, выдаваемыми по требованию (например, временные учётные данные БД на 15 минут через Vault), балансируя между операционной сложностью внедрения и радиусом поражения при утечке.
Как это работает подробнее
Централизованное хранилище секретов выдаёт доступ сервисам по их идентичности (service identity, например через Kubernetes service account или cloud IAM role) и политике наименьших привилегий — каждый сервис видит только свои секреты. Динамические секреты генерируются хранилищем на лету с ограниченным сроком жизни и автоматически отзываются, что устраняет проблему «вечных» учётных данных.
- Компромисс. Динамические краткоживущие секреты существенно снижают ущерб от утечки и автоматизируют ротацию, но увеличивают зависимость всех сервисов от доступности и производительности хранилища секретов и усложняют отладку (секрет может истечь посреди длительной операции); статические секреты с ручной ротацией проще в эксплуатации для legacy-систем, но ротация в реальности откладывается месяцами, увеличивая окно риска. Выбор зависит от критичности данных, зрелости инфраструктуры и готовности команды эксплуатировать дополнительный критичный сервис.
Пример кода
example.txt
Vault dynamic secrets engine для PostgreSQL:
сервис запрашивает credentials -> Vault создаёт временного пользователя БД
с TTL=15 минут и правами только на нужную схему
-> по истечении TTL Vault автоматически отзывает доступ
Легаси-сервис без поддержки Vault SDK:
статический пароль, ротируемый раз в 30 дней через scheduled job,
с принудительным уведомлением команды о предстоящей ротацииЧто использовать на практике
- Практика. Переход обычно делают поэтапно — сначала выносят самые критичные и широко используемые секреты (доступ к продовой БД, платёжным системам), внедряют аудит обращений и алертинг на аномальный доступ, затем постепенно переводят остальные сервисы; для legacy-сервисов, не поддерживающих динамическую выдачу, допустим промежуточный вариант с автоматической ротацией статических секретов по расписанию.
Подводные камни
- Риск. Внедряют единое хранилище, но дают всем сервисам одинаково широкий доступ «чтобы не разбираться с политиками», сводя на нет изоляцию; не планируют поведение на случай недоступности самого хранилища секретов при рестарте сервисов; забывают про секреты, уже зашитые в истории git, которые нужно ротировать отдельно.