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

Под нагрузкой ротация ключей чаще всего ломается не из-за самого нового секрета, а из-за рассинхронизации: часть воркеров уже читает новый ключ, часть ещё отправляет старый, а удалённый сервис принимает только один вариант. В результате появляются 401 и 403, растёт очередь повторных запросов, а попытка быстро «починить» ситуацию может превратить частичный сбой в каскадный. Ниже — разбор для сервисов, которые обмениваются API-ключами, HMAC-секретами или JWT-подписами. Подход не привязан к конкретной библиотеке и применим к системам на актуальных версиях используемых рантаймов и секрет-хранилищ.

Сначала определите, что именно вы ротируете

Слово «ключ» скрывает несколько разных механизмов. У каждого свой источник отказа и свой безопасный порядок переключения.

• API-ключ клиента. Получатель сравнивает строку или её производное значение. Главная проблема — старые клиенты, которые нельзя обновить одновременно.
• Секрет HMAC. Отправитель и получатель должны использовать один и тот же секрет. Ошибка в одном из них сразу превращает все запросы в недействительные.
• Ключ подписи JWT. Подписывающая сторона выпускает токены новым ключом, а проверяющая должна некоторое время принимать старый. Для идентификации ключа в токене обычно используется поле kid, но конкретная поддержка зависит от библиотеки и конфигурации.
• Сертификат или ключ TLS. Здесь меняется не только секрет, но и цепочка доверия, срок действия и поведение долгоживущих соединений.

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

Сноска. Ключевая версия — идентификатор конкретного ключа, по которому система понимает, чем был подписан запрос или токен. Это не обязательно сам секрет и не должно раскрывать его значение.

Как выглядит безопасная ротация

Без простоя достигается не мгновенной заменой, а перекрытием периодов. В некоторый момент система должна уметь принять старый и новый вариант, хотя выпускать или отправлять уже только новый.

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

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

Безопасная ротация — это не операция «заменить A на B», а управляемый переход через состояние, в котором проверяются оба ключа, но создаётся только новый.

Что ломается первым под нагрузкой

Кэш секретов и долгоживущие воркеры

Приложение может читать секрет только при старте процесса, а не при каждом запросе. Тогда обновление в хранилище ничего не меняет для уже запущенных воркеров. В контейнерной среде ситуация усложняется: новая версия развёрнута, но часть старых экземпляров продолжает обрабатывать трафик.

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

Проверка только одного ключа

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

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

Повторные запросы и усиление нагрузки

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

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

Очереди и отложенные сообщения

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

Часы и границы срока действия

JWT и временные подписи зависят от часов на разных узлах. Небольшой сдвиг может сделать новый токен недействительным сразу после выпуска или продлить жизнь старого на разных машинах по-разному. Отдельно измеряйте синхронизацию времени и не маскируйте проблему чрезмерно большим допуском.

Подходы и цена каждого

Что измерять до и после переключения

Универсального «безопасного окна» в минутах нет. Его рассчитывают по фактической системе, а не по времени одного деплоя.

• долю успешных запросов по версии ключа и по потребителю;
• число ошибок 401, 403 и ошибок проверки подписи отдельно от сетевых ошибок;
• возраст самого старого токена, сообщения в очереди и кэша конфигурации;
• количество активных экземпляров с каждой версией ключа;
• число повторов, таймаутов и глубину очередей во время ротации;
• время между публикацией нового ключа и его фактическим появлением на последнем воркере.

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

Где схема ломается

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

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

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

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

Что делать дальше

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

Для JWT сверяйте поведение с RFC 7519 и документацией конкретной библиотеки: названия настроек, кэширование ключей и правила проверки времени отличаются. В проде первым показателем после переключения смотрите не общий процент ошибок, а распределение 401 и 403 по экземплярам, клиентам и версиям ключа.