Управление секретами: почему пароли в коде опасны

Секреты — это пароли к базам данных, API-ключи, токены, приватные ключи и сертификаты. Когда они лежат в коде, конфигурационных файлах или переменных CI, любая утечка репозитория превращается в утечку доступа к инфраструктуре. Правильный подход — единое хранилище, доступ по идентичности, минимальные привилегии, короткоживущие учётные данные и аудит.

Где обычно «живут» секреты

Прямо в исходном коде и истории git — даже удалённый секрет остаётся в истории коммитов
В конфигурационных файлах и docker-образах (OWASP отдельно предостерегает от секретов в инструкциях ENV и ARG Dockerfile)
В переменных CI/CD, доступных слишком широкому кругу
В мессенджерах, wiki и таблицах

Это явление называют secret sprawl — «расползание секретов». Чем больше копий, тем сложнее понять, кто имеет доступ, и тем дороже ротация.

Почему это опасно на практике

Секрет в коде видят все, у кого есть доступ к репозиторию: разработчики, подрядчики, сервисные учётные записи CI. Если репозиторий попадёт во внешний мир, злоумышленник получает рабочие учётные данные без взлома. Откат коммита не помогает: секрет остаётся в истории, поэтому найденный секрет нужно считать скомпрометированным и заменить. Дополнительная проблема — долгоживущие пароли: украденный вечный пароль работает, пока кто-то не заметит утечку.

Принципы правильного управления секретами

Эти принципы совпадают с рекомендациями OWASP Secrets Management Cheat Sheet:

Централизация. Одно защищённое решение вместо десятков мест, чтобы команды знали, для чего нужен каждый секрет и где он хранится.
Доступ по идентичности и минимальные привилегии. Доступ выдаётся к конкретным секретам, а не ко всему хранилищу; сервисные учётные записи CI получают только то, что нужно задачам.
Короткоживущие учётные данные. Вместо вечного пароля — временный, выданный на ограниченный срок и отзываемый после использования.
Автоматическая ротация. Регулярная смена секретов ограничивает срок жизни украденных данных.
Аудит. Журнал фиксирует, кто и когда запрашивал секрет, было ли это одобрено и какие были неудачные попытки.

Как это решает HashiCorp Vault

HashiCorp Vault — одно из самых распространённых решений для управления секретами:

Secrets: централизованное хранение и программная выдача секретов через API.
Динамические секреты: к каждому динамическому секрету Vault привязывает lease со сроком жизни (TTL); по окончании срока или при отзыве секрет перестаёт действовать. Например, секретный движок баз данных создаёт пользователя по роли и отзывает его по истечении lease (по документации — 1 час по умолчанию, максимум 24 часа).
Статические роли с ротацией: для существующих учётных записей Vault может хранить пароль и менять его по расписанию.
Certificates: выпуск, ротация и отзыв сертификатов по требованию.
Encryption as a service: шифрование данных без хранения ключей в приложении.
Интеграции с Kubernetes, CI/CD, облаками и LDAP/AD.

У динамических секретов есть заметное преимущество для расследований: каждый экземпляр сервиса получает собственные учётные данные, и сомнительный запрос к базе можно отследить до конкретного экземпляра. Если вы выбираете между Vault и альтернативами, прочитайте сравнение HashiCorp Vault, CyberArk Conjur и облачные KMS.

С чего начать

Просканируйте репозитории на наличие секретов (SAST-инструменты, например DerScanner, находят захардкоженные пароли и ключи). OWASP рекомендует использовать несколько инструментов поиска секретов и сопоставлять их результаты, а проверки запускать на уровне разработчика (pre-commit, IDE) и в CI.
Ротируйте найденные секреты — считайте их скомпрометированными.
Разверните хранилище и переведите на него сначала самые критичные системы.
Добавьте в CI/CD проверку, запрещающую новые секреты в коде. Технические детали — в статье SAST и SCA в GitLab CI.
Настройте журналирование обращений и оповещения о подозрительных запросах.

Управление секретами — один из шагов общего плана внедрения безопасной разработки; остальные шаги описаны в материале DevSecOps: с чего начать.

Секреты в CI/CD и контейнерах

Конвейеры сборки — одно из самых уязвимых мест. Сервисные учётные записи CI часто имеют широкие права, а переменные окружения видны всем, кто может изменять конфигурацию задач. Рекомендации OWASP для CI/CD: ограничивать права сервисных аккаунтов только нужными секретами, оповещать об извлечении секретов и не допускать наследования секретов форками репозитория. Журналы CI/CD тоже могут раскрыть секреты, если инструмент печатает переменные, поэтому их нужно проверять и хранить с контролем доступа.

В контейнерах основной риск — «запекание» секрета в образ. Всё, что передано через ENV или ARG в Dockerfile, остаётся в слоях образа и доступно любому, кто получил образ. Вместо этого секреты выдаются приложению в момент запуска из хранилища, а образ остаётся чистым.

Типичные ошибки

Один общий пароль на всех. Невозможно понять, кто и что сделал, и ротация затрагивает всех сразу.
Хранилище без ограничения доступа. Если любой инженер читает все секреты, вы лишь переложили проблему в другое место.
Нет плана ротации. Секрет, который нельзя безболезненно заменить, фактически вечный.
Нет аудита. Без журнала обращений расследование инцидента превращается в догадки.
Единый корневой ключ в открытом виде. Основные учётные данные самого хранилища тоже нужно защищать во вторичной системе.

Как перейти без остановки разработки

Миграцию лучше проводить по приложениям, а не «большим взрывом». Для каждого приложения порядок примерно такой: инвентаризация секретов, создание политик доступа в хранилище, перенос секретов, изменение кода или конфигурации для получения секретов во время выполнения, проверка и только затем удаление старых копий и ротация. Начинайте с систем, где последствия утечки наиболее тяжёлые: базы данных с персональными и платёжными данными, облачные учётные записи, ключи подписи. Старые значения после миграции нужно заменить, иначе они продолжат жить в истории репозиториев и резервных копиях.

Чем хранилище секретов отличается от менеджера паролей

Менеджер паролей рассчитан на людей: он помогает хранить личные и командные пароли и подставлять их в формы. Хранилище секретов, такое как Vault, рассчитано на машины и автоматизацию: приложения, сервисы и конвейеры аутентифицируются по своей идентичности, получают секреты через API, а политики определяют, к чему именно у них есть доступ. Кроме хранения, такое решение умеет выдавать динамические учётные данные, ротировать их, шифровать данные как сервис и вести детальный журнал. Поэтому заменить хранилище менеджером паролей нельзя, хотя для личных нужд сотрудников он по-прежнему полезен.

Роли и процессы вокруг хранилища

Само по себе хранилище не решает проблему без ролей и регламентов. Определите, кто администрирует хранилище, кто утверждает политики доступа, кто отвечает за ротацию и кто реагирует на инциденты. Разделяйте полномочия: администратор платформы не обязан иметь доступ к содержимому всех секретов. Заранее опишите порядок аварийного доступа и восстановления, чтобы потеря одного ключа или сотрудника не остановила работу всех систем.

Как проверить, что всё работает

После внедрения полезно регулярно задавать себе несколько вопросов и проверять ответы на практике:

Можно ли найти в репозиториях и образах хотя бы один действующий секрет? Если да — процесс не завершён.
Сколько времени займёт замена скомпрометированного ключа и сколько систем придётся перезапускать?
Кто из сотрудников и сервисов может прочитать самые чувствительные секреты и действительно ли им это нужно?
Что произойдёт, если сотрудник с широким доступом уволится или его учётная запись будет скомпрометирована?
Видите ли вы в журнале необычные обращения: новые адреса, нетипичное время, повторяющиеся отказы?

Если ответы вызывают затруднения, это сигнал к доработке политик доступа и ротации. Регулярные учения, например имитация утечки ключа и замена его в боевом контуре, показывают, насколько процесс действительно готов к инциденту, а не только описан в регламенте.

Частые вопросы

Достаточно ли удалить секрет из репозитория?

Нет. Секрет остаётся в истории git и мог быть скопирован. Его нужно считать скомпрометированным: выпустить новый и отозвать старый.

Чем динамические секреты лучше обычных паролей?

Они выдаются по запросу, имеют ограниченный срок жизни и отзываются автоматически. Украденные данные перестают работать быстро, а каждый потребитель получает собственную учётную запись, что упрощает аудит.

Хватит ли переменных окружения CI/CD?

Для небольших задач они могут быть начальным шагом, но у них нет полноценного аудита, динамической выдачи и ротации, а доступ часто слишком широк. Для критичных систем нужно отдельное хранилище.

Как часто ротировать секреты?

OWASP рекомендует регулярную автоматическую ротацию, чтобы украденные учётные данные работали недолго. Конкретная периодичность зависит от критичности системы и возможностей хранилища; пользовательские пароли обычно меняют при подозрении на компрометацию.

Внедряем HashiCorp Vault в Казахстане и Центральной Азии — от пилота до промышленной эксплуатации.

Обсудить проект

Источники

Решения по теме

HashiCorp Vault →