Ротация ключей в веб-приложении: цена и метрики
Замена ключа подписи не должна одновременно отключить вход всем пользователям. Разбираем ротацию JWT-ключей по шагам, риски переходного периода и метрики, которые покажут цену операции без выдуманных цифр.
При ротации ключа подписи JWT недостаточно заменить значение в конфигурации: экземпляры приложения могут обновляться не одновременно, а старые токены продолжат приходить после переключения. Если проверяющая сторона уже забыла прежний ключ, пользователи получат ошибки авторизации; если хранит его слишком долго, компрометация затронет больше токенов. Ниже — разбор плановой ротации ключей для подписанных JWT и способ измерить её влияние на конкретный сервис.
Что именно меняется
Речь здесь о ключах подписи токенов, а не о TLS-сертификатах, паролях пользователей или ключах шифрования данных в базе. Для JWT в формате JWS приложение подписывает токен приватным ключом, а проверяющие компоненты используют соответствующий публичный ключ. Для HMAC один и тот же секрет нужен и для подписи, и для проверки — поэтому его нельзя бездумно публиковать получателям.
В примерах понятийный уровень опирается на форматы JWT и JWK из RFC 7519 и RFC 7517. Конкретных вызовов SDK здесь нет: библиотека и её API зависят от языка и версии, а последовательность ротации — от вашей схемы выпуска и проверки токенов.
Термин. JWKS — набор открытых ключей в формате JWK, который проверяющая сторона может получить, чтобы найти ключ по идентификатору. Параметр kid в заголовке токена помогает выбрать ключ, но сам по себе не доказывает подлинность токена.
Переход — это период с двумя ключами
В штатной ротации новый ключ сначала становится доступен проверяющим системам, и только потом начинает подписывать токены. Старый публичный ключ временно остаётся в наборе: без него не пройдут проверку токены, выпущенные до переключения. Это не бесконечная поддержка старого ключа, а ограниченное окно совместимости.
- Создайте новую пару ключей. Приватную часть передайте только компоненту выпуска токенов, публичную подготовьте для проверяющих сервисов. Проверьте, что у нового ключа корректные тип и назначение, а его идентификатор не совпадает с действующим.
- Опубликуйте новый публичный ключ. Дождитесь, пока его увидят все проверяющие компоненты, включая реплики, региональные кластеры и кеши. Проверка: запрос к каждому источнику ключей возвращает новый ключ, а тестовый токен с новым
kidпроходит верификацию. - Переключите выпуск. Начните подписывать новые токены новым приватным ключом. Проверяйте долю успешных выпусков и ошибок проверки отдельно: успешный выпуск ещё не означает, что потребители уже умеют проверить подпись.
- Оставьте старый публичный ключ на время жизни старых токенов. Учитывайте максимальный срок действия токена, допустимый рассинхрон часов и задержку обновления конфигурации или кеша. Проверка: токены, выпущенные до переключения и ещё не истёкшие, проходят проверку.
- Удалите старый ключ из набора проверки. Делайте это после окончания окна совместимости. Проверка: новые токены принимаются, а истёкшие либо подписанные удалённым ключом отклоняются ожидаемым способом.
Точный интервал нельзя назначить одной цифрой для всех сервисов. Его рассчитывают по максимальному сроку жизни токена и фактическому времени распространения нового набора ключей. Если проверяющие узлы кешируют JWKS, измерьте время обновления кеша, а не берите значение из предположения.
Безопасная ротация — не переключатель, а переход с контролируемым перекрытием. Сначала убедитесь, что новый ключ умеют читать все потребители; затем меняйте подпись; старый ключ убирайте последним.
Где появляется цена: проверка, кеши и отказы
Сама подпись обычно не главный риск операции. Проблемы чаще возникают на границах систем: один сервис уже выпустил токен с новым kid, другой ещё не обновил список ключей; кеш сохранил старый набор; либо компонент выпуска и компонент проверки разошлись в настройках алгоритма. Если при неизвестном kid проверяющая сторона каждый раз загружает JWKS, поток токенов с незнакомыми идентификаторами может превратиться в поток сетевых запросов.
Измеряйте не только среднюю задержку. Среднее скрывает редкие паузы, а именно они часто становятся заметны пользователям во время обновления ключей. Снимайте базовую линию до переключения, показатели во время него и результат после удаления старого ключа. Записывайте условия замера: число экземпляров, долю запросов с JWT, настройки кеша, число ключей в наборе и способ доставки JWKS.
| Что измерять | Как снять | Что может показать |
|---|---|---|
Ошибки проверки подписи и неизвестный kid | Считать по типу ошибки и по экземпляру, сравнить интервалы до, во время и после ротации | Неравномерное распространение ключа, неверный идентификатор или слишком раннее удаление старого ключа |
| Задержка проверки токена | Сравнить p50, p95 и p99 на одинаковом профиле трафика | Рост хвоста задержек из-за загрузки ключей, блокирующего обращения к сети или дополнительного поиска |
| Запросы к источнику JWKS и доля кеш-попаданий | Считать обращения и промахи отдельно, привязать метрики к экземплярам | Частые обновления или синхронные промахи, способные перегрузить источник ключей |
| Ошибки авторизации и повторные входы | Сопоставить с версиями приложения и моментами смены ключа, не записывая сами токены | Пользовательский ущерб, который не виден по успешности криптографической операции отдельно |
Сравнивайте одинаковые окна и нагрузку. Если во время ротации выросли p99 или ошибки, проверьте, совпал ли рост с переключением выпуска, истечением кеша либо конкретной группой экземпляров. Не делайте вывод по одному графику: ошибка авторизации может происходить и до проверки подписи.
Плановая замена и компрометация — разные сценарии
При плановой замене перекрытие ключей помогает сохранить работу старых токенов. При подозрении на утечку приватного ключа такое перекрытие может продлить возможность использования поддельных токенов. Тогда приоритет меняется: старый ключ нужно перестать принимать как можно быстрее, а затронутым пользователям может потребоваться повторная аутентификация. Это означает намеренные отказы и не должно маскироваться под обычную плановую ротацию.
| Ситуация | Что делать с прежним ключом | Цена решения |
|---|---|---|
| Плановая ротация | Оставить старый публичный ключ до истечения выпущенных им токенов и распространения нового | Короткое время система принимает подписи обоих ключей; нужны учёт срока токена и контроль кешей |
| Подтверждённая или вероятная компрометация | Отключить доверие к старому ключу по процедуре реагирования, не ждать обычного срока токена | Часть действующих сессий может оборваться; вероятны повторные входы и всплеск обращений в поддержку |
Публичный ключ можно распространять, приватный — нет. Доступ к приватной части ограничивают компонентом подписи и средствами управления секретами. Логи не должны содержать токены целиком: токен может дать доступ к аккаунту до истечения срока или отзыва. Для диагностики достаточно безопасных идентификаторов, типа ошибки и версии конфигурации.
Граничные случаи, которые стоит проверить
- Старый токен живёт дольше ожидаемого. Проверьте фактические настройки времени жизни на всех путях выпуска, включая отдельные типы токенов. Одного значения из основной конфигурации может быть недостаточно.
- Кеш обновляется только после ошибки. Убедитесь, что неизвестный
kidне вызывает неограниченное число загрузок JWKS. Нужны ограничение частоты, разумный кеш и безопасное поведение при недоступности источника. - Принимается неожиданный алгоритм. Проверяющая сторона должна использовать ожидаемые для приложения алгоритмы и соответствующий им тип ключа, а не выбирать политику только по данным из заголовка токена.
- Есть несколько потребителей. Обновление одного веб-сервера может не затронуть фоновые задачи, мобильный API, шлюз или внешний сервис. Составьте список всех проверяющих сторон и проверяйте каждую.
- Меняется схема доверия. Переход с общего HMAC-секрета на пару асимметричных ключей меняет не только ключ, но и то, кто способен выпускать токены. Это отдельное архитектурное изменение, а не простая замена значения.
Что делать дальше
Сначала инвентаризируйте издателей и потребителей токенов, максимальный срок их жизни и места кеширования ключей. Затем проведите тестовую ротацию на стенде с теми же настройками распространения, что и в рабочей среде. На проде включите наблюдение за неизвестным kid, ошибками подписи, задержкой проверки и повторными входами; удаляйте старый ключ только после подтверждённого окна совместимости. Отдельно подготовьте аварийный сценарий, где сохранение старых сессий уступает отзыву скомпрометированного ключа.
Проверка рекламы на риски: Что в макете вызовет вопросы ФАС: превосходные степени, сравнения, обещания результата, маркировка.
Спросить за 40 ₽Источники: RFC 7517: JSON Web Key (JWK), RFC 7519: JSON Web Token (JWT)
Частые вопросы
Нужно ли оставлять старый ключ после переключения?
Как понять, сколько держать оба ключа?
Что произойдёт, если проверяющий сервис не получил новый ключ?
Можно ли хранить старый ключ постоянно, чтобы ничего не сломать?
Что делать, если ключ скомпрометирован?
Нужно ли менять все ключи приложения одновременно?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.