Постквантовая миграция начинается с инвентаризации, а не с нового алгоритма

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

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

Очертите область обследования

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

Материалы проекта NCCoE при NIST описывают криптографический реестр как запись о криптографии в системах, приложениях, сервисах, устройствах и потоках данных. В него могут входить алгоритмы, сведения о ключах без самого ключевого материала, сертификаты, цепочки доверия, протоколы, библиотеки и аппаратные модули.

Отмечайте RSA и эллиптическую криптографию в механизмах установления ключей, цифровых подписях и сертификатах. Симметричные алгоритмы и хеш-функции тоже заносите в реестр, но одно лишь наличие AES или SHA-2 не делает компонент кандидатом на первоочередную замену: решение зависит от назначения, параметров и протокола.

Соберите реестр конкретных применений

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

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

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

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

Определите, что переносить первым

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

Аутентификацию и цифровые подписи стоит оценивать отдельно от каналов конфиденциальности: здесь риск связан с доверием к учётным данным, программному обеспечению и инфраструктуре открытых ключей. План Google от 25 марта 2026 года задаёт компании целевой срок миграции к 2029 году и прямо называет сервисы аутентификации приоритетом её модели угроз.

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

Подготовьте криптографическую гибкость

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

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

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

Проведите ограниченный пилот и закрепите результат

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

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

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

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

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

Читайте также:

• Android 17 превращает смартфон в настоящего интеллектуального помощника: что нового принёс Google
• Редактор Google Ads вместо Редактора AdWords: обзор нового приложения