Ротация секретов: как менять ключи и пароли без простоя сервиса

Прямой ответ

Ротация секретов — плановая замена ключей, паролей и токенов. Она выполняется либо по расписанию, либо срочно после подозрения на компрометацию. Простой при ротации возникает по одной причине: старый секрет отзывается раньше, чем все потребители перешли на новый.

Решение — стратегия двух ключей с периодом перекрытия:

Ключевое правило: на этапах 1–3 оба ключа валидны. Отзыв старого ключа — последний шаг, а не первый.

Порядок действий для API-ключа внешнего сервиса:

1. Создать второй ключ в панели сервиса (не удаляя первый).
2. Положить новый ключ в хранилище секретов.
3. Обновить приложение: перезапуск подов подхватывает новое значение.
4. Убедиться по метрикам, что ошибки аутентификации отсутствуют.
5. Выждать период, превышающий время жизни кешей и длительных процессов.
6. Отозвать первый ключ.

Ошибка на шаге 6 без выполнения шага 4 приводит к отказу аутентификации. Ошибка при пропуске шага 5 — к отказу фоновых задач, которые держали старый ключ в памяти.

Для баз данных ротация пароля выполняется так же: создаётся вторая учётная запись, приложение переключается на неё, первая удаляется после проверки.

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

В Kubernetes секрет хранится как объект, а под читает его при запуске. Изменение секрета не перезапускает работающие поды — это частая причина «залипания» старого значения; о механизме — в статье про ConfigMap и Secret.

Что усложняет ротацию

Четыре обстоятельства превращают плановую смену ключа в риск отказа.

Секрет читается один раз при старте. Процесс загружает значение в память и не видит обновления, поэтому без перезапуска ротация не применяется. Это основная причина расхождения между «секрет обновлён» и «секрет используется».

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

Сторонние интеграции. Ключ может использоваться не только вашим сервисом: партнёрская интеграция или отдельный скрипт продолжают работать со старым значением. Реестр потребителей обязателен, иначе отзыв ключа ломает то, о чём никто не вспомнил.

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

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

Практика: внедрение ротации без простоя

1. Заведите реестр секретов. Список: где хранится, кто использует, срок действия, дата последней замены. Без реестра ротация выполняется выборочно, а самые старые секреты остаются незамеченными.

2. Используйте стратегию двух ключей везде, где это возможно. Период перекрытия превращает ротацию из рискованной операции в рутинную.

3. Не храните секреты в переменных окружения на долгий срок. Процесс читает их при старте и не видит обновления; о рисках — в статье про секреты в разработке.

4. Перезапускайте потребителей после смены. В Kubernetes это перезапуск подов, на виртуальной машине — перезапуск службы. Без перезапуска процесс продолжает использовать старое значение.

5. Проверяйте переход метриками. Число ошибок аутентификации должно остаться нулевым. Рост означает, что часть потребителей не обновилась.

6. Учитывайте фоновые задачи и долгоживущие процессы. Задача, запущенная до ротации, держит старый секрет в памяти весь срок выполнения.

7. Автоматизируйте по расписанию. Ротация вручную выполняется нерегулярно; задача в CI или хранилище секрета выполняется независимо от памяти команды.

8. Отделите плановую ротацию от аварийной. При компрометации отзыв старого ключа выполняется немедленно, и простой допустим; о проверках — в статье про аудит зависимостей.

Рекомендации:

1. Начинайте с самых долгоживущих секретов. Ключ, созданный три года назад и ни разу не менявшийся, — наибольший риск.
2. Фиксируйте дату последней ротации в реестре. Метрика возраста секрета показывает, выполняется ли политика.
3. Проверяйте ротацию на стенде. Первая ротация продуктивного ключа не должна быть экспериментом.
4. Не логируйте секреты. Значение в логе обнуляет смысл ротации; о фильтрации — в статье про структурированные логи.
5. Ограничьте срок действия токенов. Токен на 15 минут не требует частой ротации, поскольку истекает сам.

Практический сценарий: отказ аутентификации после отзыва старого ключа

Контекст: плановая ротация ключа платёжного провайдера. Новый ключ создан и развёрнут, старый отозван через час. После отзыва часть запросов начала возвращать ошибку аутентификации.

1. Диагностика. Ошибки приходили от одного из четырёх подов. Остальные использовали новый ключ корректно.
2. Причина. Под не был перезапущен после обновления секрета: значение читается при старте процесса, а изменение объекта Secret в Kubernetes не перезапускает работающие поды. Метрика ошибок аутентификации отсутствовала, поэтому переход не проверялся.
3. Действия. (а) Временно восстановили старый ключ, чтобы вернуть работоспособность; (б) перезапустили все поды и убедились, что значение подхватилось; (в) добавили перезапуск развёртывания в процедуру ротации; (г) добавили метрику ошибок аутентификации с порогом тревоги; (д) включили проверку по всем потребителям перед отзывом ключа; (е) описали процедуру в runbook.
4. Результат. Повторная ротация прошла без ошибок, а проверка перед отзывом ключа исключила повторение инцидента.

Вывод: ротация без простоя требует периода перекрытия, принудительного перезапуска потребителей и проверки метриками перед отзывом старого секрета. Отзыв до проверки — главная причина отказов при плановой смене ключей.

FAQ

Как часто менять секреты? По политике: обычно раз в 90 дней для долгоживущих ключей. Токены с коротким сроком жизни в частой ротации не нуждаются.

Что делать при подозрении на компрометацию? Отозвать секрет немедленно, выпустить новый и проверить журнал использования. Плановая процедура с периодом перекрытия здесь неприменима.

Нужно ли перезапускать поды после смены секрета? Да, если секрет читается при старте процесса. Автоматическое обновление возможно только при чтении значения на каждый запрос.

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

Источники: HashiCorp Vault docs (secrets), Kubernetes docs (Secret), OWASP Secrets Management — ссылки в шапке.