Ротация криптографических ключей без остановки бизнес-систем

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

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

Что именно меняется при ротации?​

Термин «ротация ключа» описывает несколько разных операций. В управляемом сервисе управления ключами (KMS) ротация часто создает новую версию внутри логического объекта ключа: новые операции шифрования начинают использовать актуальную версию, а старые версии остаются доступны для расшифрования. При самостоятельной замене ключевого материала в приложении могут понадобиться выпуск нового ключа, обновление конфигурации, распространение открытого ключа, перешифрование данных и изменение формата метаданных. Эти сценарии нельзя считать взаимозаменяемыми.

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

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

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

Для шифрования данных важно различать ключ шифрования данных (DEK) и ключ шифрования ключей (KEK). При конвертном шифровании данные шифруются DEK, а сам DEK защищается KEK в KMS. Ротация KEK может сводиться к повторному оборачиванию DEK новым ключом, без расшифрования и повторного шифрования всего массива данных. Это снижает нагрузку на приложения и хранилище, но только если формат объекта сохраняет зашифрованный DEK, идентификатор версии KEK и необходимые параметры криптографической операции. При этом ротация KEK не заменяет ротацию DEK, если есть основания считать скомпрометированным именно ключ, которым шифровались данные.



Управление версиями помогает развести две задачи: назначить новый материал для новых операций и сохранить контролируемый доступ к прежнему материалу для чтения старых данных. В документации Google Cloud KMS прямо указано, что ротация не перешифровывает ранее защищенные данные автоматически; AWS KMS описывает сохранение предыдущего материала для расшифрования. Это поведение характерно для конкретных управляемых сервисов и не должно автоматически переноситься на самописные хранилища или сторонние криптопровайдеры.

Подготовка: зависимости, версии и условия перехода​

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

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

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

Инвентаризация должна описывать не только прямые обращения к KMS, но и косвенные зависимости. Сервис может получать ключ через секрет-хранилище, переменную окружения, sidecar-контейнер или библиотеку, которая кэширует материал внутри процесса. Для каждой зависимости следует установить, что именно хранится на стороне потребителя: ссылка на ключ, открытый ключ, зашифрованный DEK или сам секретный материал. Эти варианты требуют разных мер при переключении. Если приложение держит ключ в памяти, обновление конфигурации не гарантирует обновления уже работающего процесса: может понадобиться контролируемый перезапуск экземпляров или механизм обновления кэша.

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

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



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

Переход без простоя: параллельная работа ключей​

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

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

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

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

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


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

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

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

Проверка результата и вывод старого ключа из эксплуатации​

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

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

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


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

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

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

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

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