Ротация ключей без простоя: как устроено внутри
Мгновенная замена секрета ломает сервисы, которые ещё используют старый ключ. Разбираем схему с перекрытием, идентификаторами ключей, кэшем и проверками, которая позволяет обновлять доступ без массовых 401 и аварийного отката.
Если сервер перестаёт принимать старый ключ в момент выпуска нового, часть клиентов сразу получает 401 или 403. Причина обычно не в самой криптографии: старый секрет ещё живёт в кэше, очереди, переменных окружения или экземпляре приложения, который не успел перезапуститься. Безостановочная ротация строится на перекрытии двух ключей: новый уже принимается, а старый временно остаётся действительным.
Что именно ломается при жёсткой замене
У запроса есть две стороны. Клиент подписывает или авторизует его секретом, сервер проверяет результат. При ротации они должны перейти на новую пару не одновременно, а с безопасным интервалом.
Жёсткий сценарий выглядит так: администратор создаёт ключ B, немедленно отзывает ключ A, а затем обновляет клиентов. Между этими действиями возникают ошибки. Даже если обновление занимает секунды, запросы уже находятся в полёте, сообщения лежат в очереди, а часть процессов продолжает работать со старой конфигурацией.
Для токенов с подписью ситуация похожая. Сервис, который выпускает токены новым ключом, может столкнуться с потребителем, у которого закэширован старый набор открытых ключей. Если старый ключ исчез из публикации слишком рано, проверка подписи начнёт падать.
Ротация без простоя — это не мгновенная замена секрета, а управляемый период, в котором старый и новый ключи работают одновременно.
Базовая схема с перекрытием
Для симметричных API-ключей и секретов у схемы четыре состояния. Названия полей зависят от вашего хранилища, поэтому ниже описана логика, а не конкретный API.
- Создайте ключ B. Сохраните его в хранилище секретов, но пока не удаляйте ключ A. На этом этапе B не обязан использоваться всеми клиентами.
- Разрешите серверу принимать A и B. Проверяющий компонент должен уметь находить оба секрета. Это можно сделать через идентификатор ключа в заголовке или через последовательную проверку допустимых ключей. Проверка: запросы с A и B проходят отдельно.
- Переведите клиентов на B. Обновите конфигурацию, переменные окружения, секреты в оркестраторе и фоновые воркеры. Проверка: в логах и метриках доля запросов с A снижается, а с B растёт.
- Выдержите окно перекрытия. Его длительность должна покрывать время доставки конфигурации, кэширования, перезапуска, обработки очередей и повторных попыток. Проверка: новые запросы с A не появляются дольше согласованного периода.
- Отзовите A. Удалите его из списка допустимых ключей и из хранилища, если он больше не нужен. Проверка: запрос с A получает ожидаемый отказ, а запрос с B продолжает проходить.
Почему порядок важен: сначала сервер должен научиться принимать новый ключ, затем клиенты переходят на него, и только после этого старый ключ можно отзывать. Обратный порядок превращает ротацию в короткий отказ в обслуживании.
Как сервер понимает, каким ключом проверять запрос
Симметричный ключ и идентификатор
В простом варианте клиент передаёт идентификатор ключа вместе с подписью. Сервер по идентификатору выбирает секрет B и проверяет подпись. Идентификатор не должен считаться секретом: это метка, а не пароль. Сам ключ передавать в логах, URL, сообщениях об ошибках и трассировках нельзя.
Если протокол не поддерживает идентификатор, сервер может временно проверить запрос по обоим активным ключам. Такой вариант проще внедрить, но он увеличивает работу на каждый запрос и усложняет диагностику: в журнале нужно фиксировать не значение ключа, а его безопасный идентификатор и результат проверки.
Асимметричная подпись и набор открытых ключей
При асимметричной схеме закрытый ключ остаётся у выпускающей стороны, а потребители получают открытые ключи. В период ротации публикация должна содержать старый и новый открытые ключи. Выпускатель начинает подписывать новые токены ключом B, а проверяющие продолжают принимать подписи A до окончания срока жизни последних токенов A плюс запас на задержки.
Для JSON Web Key (JWK)1 обычно используют поле идентификатора ключа, чтобы проверяющая сторона не перебирала весь набор. Удалять открытый ключ A сразу после переключения нельзя: старые токены ещё могут быть законными и не должны внезапно стать непроверяемыми.
Три стратегии и их цена
| Стратегия | Как работает | Цена и риск |
|---|---|---|
| Жёсткая замена | A отзывается сразу после выпуска B | Простая логика, но возможен массовый отказ из-за кэша, очередей и не обновившихся процессов |
| Перекрытие A и B | Сервер принимает оба ключа, клиенты постепенно переходят на B | Нужны метрики использования A и процедура завершения ротации |
| Версионированные ключи | Каждый ключ имеет идентификатор, а проверяющий сервис выбирает его явно | Надёжнее при нескольких потребителях, но нужно поддерживать хранение и публикацию набора ключей |
Для одного приложения и нескольких контролируемых воркеров достаточно перекрытия. Если ключ используют десятки сервисов, мобильные клиенты или внешние партнёры, явный идентификатор и реестр активных ключей заметно упрощают переход.
Как выбрать окно перекрытия
Фиксированное правило вроде «оставить старый ключ на час» не гарантирует безопасность. Сначала соберите максимальные задержки конкретной системы:
- период обновления секретов и перезапуска процессов;
- время жизни кэша конфигурации и открытых ключей;
- максимальный срок сообщения в очереди и количество повторных попыток;
- время жизни токена, подписанного старым ключом;
- задержку доставки изменений внешним потребителям.
Окно должно быть больше суммы критичных задержек, а не среднего времени обновления. Для токенов ориентиром становится срок действия последнего токена A: отзыв ключа раньше этого срока нарушит проверку ранее выданных токенов, если у системы нет отдельного механизма отзыва.
Точные значения нужно измерить в вашей инфраструктуре. Полезные показатели: доля запросов по идентификатору ключа, число отказов проверки, возраст самого старого запроса с A, задержка обновления секрета на каждом экземпляре и размер очереди сообщений.
Что ломается первым
Кэш открытых ключей
Проверяющий сервис может не увидеть B сразу после публикации. Если он запрашивает набор ключей только по расписанию, новые токены будут получать ошибки до следующего обновления. Нужны понятные правила кэширования и безопасное обновление набора при неизвестном идентификаторе, но без бесконечных запросов к поставщику ключей.
Долгоживущие процессы
Веб-приложение обновило секрет в хранилище, но уже запущенный воркер держит старое значение в памяти. Проверяйте не только хранилище, но и фактическое состояние каждого экземпляра. Особенно часто это проявляется в планировщиках, обработчиках очередей и долгих WebSocket-соединениях.
Повторные попытки
После ротации запрос со старым ключом может повториться из очереди или от прокси. Ошибка авторизации не должна автоматически запускать бесконечный retry: это увеличит нагрузку и растянет инцидент. Для каждого клиента определите, когда обновлять секрет, когда повторять запрос, а когда отправлять сообщение в отдельную очередь ошибок.
Отсутствие финального отзыва
Если старый ключ никогда не удаляется, перекрытие превращается в постоянное расширение зоны доступа. У ротации должен быть владелец, срок завершения, подтверждение перехода всех потребителей и запись об отзыве A.
Граничные случаи и безопасность
Компрометация меняет порядок действий. Если ключ A утёк, ждать окончания обычного окна нельзя: его нужно отозвать по аварийной процедуре, понимая, что часть клиентов может потерять доступ. Для регулярной ротации и экстренного отзыва должны существовать разные сценарии.
Не передавайте секреты через командную строку, не записывайте их в логи и не кладите в репозиторий даже временно. Доступ к хранилищу ключей должен быть ограничен сервисной ролью, а операции выпуска, чтения и отзыва — аудитироваться. Сам факт успешной ротации не доказывает, что старый ключ нигде не остался: отдельно проверяйте резервные копии, CI/CD, локальные конфигурации и сторонние интеграции.
Тема инвалидации уже выданных токенов шире ротации ключей: здесь рассматривается только безопасное переключение проверяющей стороны.
Что делать дальше
Начните с инвентаризации: кто выпускает ключ, кто его проверяет, где он хранится, сколько живёт кэш и какие потребители нельзя перезапустить сразу. Затем добавьте метрику использования ключа и проведите тестовую ротацию на отдельном окружении. В продакшене сначала проверьте переход B, затем дождитесь нулевого или объяснимого использования A, и только после этого отзывайте его.
Для реализации на уровне протоколов сверяйтесь с документацией конкретного хранилища секретов, сервиса авторизации и формата токенов. В этой статье нет привязки к версии библиотеки: описанная схема — архитектурный паттерн для HTTP-сервисов и систем, использующих симметричные или асимметричные ключи, а не конкретный вызов API.
1 JWK — JSON-описание открытого или закрытого криптографического ключа. Набор таких объектов обычно публикуют как JWKS, чтобы другие сервисы могли выбирать ключ по идентификатору.
Логотип и фирменный стиль: Три концепции разного характера, палитра с обоснованием, проверка на читаемость в малом размере и в один цвет.
Спросить за 60 ₽Источники: OWASP Secrets Management Cheat Sheet, RFC 7517: JSON Web Key (JWK)
Частые вопросы
Можно ли заменить ключ без одновременного запуска всех клиентов?
Сколько времени держать старый ключ активным?
Что делать, если старый ключ уже скомпрометирован?
Почему новый ключ выпущен, но сервис всё ещё получает ошибки проверки?
Нужно ли отзывать старый ключ сразу после перехода клиентов?
Поможет ли автоматический повтор запроса при 401?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.