Внедрение постквантовой криптографии в управление ключами с геозонированием23.10.2026 21:06

Сегодня Cloudflare запускает в закрытой бета-версии постквантовый менеджер ключей с географическими ограничениями в рамках нашего пакета Data Localization Suite (DLS). Этот новый PQ GeoKey Manager — ключевой компонент решений Cloudflare для обеспечения суверенитета данных: он гарантирует, что ключи расшифрования клиента доступны только в выбранном им регионе. GeoKey Manager обеспечивает это, оборачивая каждый ключ расшифрования таким образом, чтобы расшифровать его могли только серверы Cloudflare, расположенные в разрешённом регионе.

Общедоступный запуск (GA) запланирован на первый квартал 2027 года, но сегодняшний запуск — важная веха на пути к поддержке целей клиентов в области суверенитета данных и одновременной миграции всех продуктов Cloudflare на постквантовую криптографию (PQ).

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

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

Развитие GeoKey Manager

В 2017 году Cloudflare первой внедрила концепцию географически ограниченных ключей безопасности транспортного уровня (TLS) с помощью GeoKey Manager. Это позволило клиентам контролировать, в каких точках anycast-сети Cloudflare можно раскрывать их закрытые ключи TLS, и обеспечило более строгие технические гарантии того, в каком регионе расшифровываются их запросы. Например, клиент мог выбрать раскрытие закрытых ключей только в Индии. Вместо того чтобы разрешать расшифрование по всей глобальной сети Cloudflare, GeoKey Manager гарантирует, что подпись TLS для каждого запроса клиента выполняется в нашей сети в Индии.

В 2022 году GeoKey Manager получил дальнейшее развитие благодаря шифрованию на основе атрибутов с политиками для шифротекста (ABE). Вместо привязки зашифрованных ключей к фиксированному набору дата-центров ABE задавала географические требования с помощью таких атрибутов, как страна или регион, например «регион = Европейский союз» или «регион = Канада + США + Мексика». Новые серверы, получившие соответствующие разрешения, могли получать необходимые возможности расшифрования без повторного оборачивания каждого ключа клиента.

Эта гибкость создала и новые сложности, и новые возможности для перехода на постквантовую криптографию. Сегодня не существует готовой к промышленному использованию постквантовой схемы ABE, а клиентам не требуется большое количество регионов. Более простая архитектура отвечает этим требованиям и упрощает сопровождение и эксплуатацию. Поэтому Cloudflare использует гибридную защиту на основе ML-KEM-768 и X25519, а также два вида ключей. ML-KEM-768 — это стандарт NIST, который также открывает возможности для работы с клиентами, предъявляющими особо строгие требования к безопасности. Региональный корневой ключ — это симметричный секрет, привязанный к одному региону, на основе которого для отдельной службы, например Gateway или Tunnel, создаётся собственная пара ключей. Это защищает материал закрытых ключей от атак по принципу «собрать сейчас, расшифровать позже», сохраняя при этом региональные ограничения на использование ключей.

Глобальное распространение шифротекста, региональное раскрытие ключей

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

Во время инициализации служба ключей на периферии (компонент на каждом периферийном сервере Cloudflare, который раскрывает закрытые ключи клиентов и использует их для обработки запросов) проверяет, загружены ли все региональные корневые ключи, необходимые согласно её конфигурации. Если настроенный ключ отсутствует или имеет неверный формат, служба не запускается. После инициализации обработка отдельного запроса также завершается отказом по умолчанию — Cloudflare отклоняет его, чтобы не допустить раскрытия ключа за пределами региона, — если в метаданных указан региональный корневой ключ, недоступный локально. Если запрос для Германии по какой-либо причине попытался бы расшифровать трафик в Испании или Франции, он завершился бы ошибкой, поскольку ни в Испании, ни во Франции нет регионального корневого ключа для Германии. Это гарантирует, что региональный корневой ключ ни при каких обстоятельствах не покидает свой регион.

Cloudflare необходимо поддерживать высокую производительность и одновременно надёжно защищать регионализированные данные клиентов в больших масштабах. Именно здесь пригодится следующая версия GeoKey Manager. Мы обеспечиваем высокую скорость работы и логически разделяем сеть, используя постквантовую криптографию для ограничения регионов, в которых раскрываются закрытые ключи клиентов. Большинство регионов будет доступно клиентам для регионализации рабочих процессов; при этом для отдельных продуктов могут действовать особые условия. Клиенты выбирают регион, а Cloudflare берёт на себя всё остальное, необходимое для раскрытия их закрытых ключей в пределах этого региона.

Как GeoKey Manager гарантирует доступность ключей только в одном регионе

GeoKey Manager контролирует, где на плоскости передачи данных можно раскрывать и использовать обёрнутые закрытые ключи. Он не управляет пересылкой и маршрутизацией запросов — за это отвечает Regional Services, —, а также завершением туннелей и проверкой трафика (это тоже входит в Regional Services).

GeoKey Manager отделяет обёрнутые закрытые ключи, распределённые по всему миру, от регионального корневого ключа, необходимого для их раскрытия. Quicksilver, наша глобальная система распространения конфигураций, распределяет по сети обёрнутые закрытые ключи и их метаданные. Региональные корневые ключи через неё не распространяются: для этого используется отдельная служба подготовки, которая хранит региональные корневые ключи и передаёт их только тем периферийным серверам, которым разрешён доступ для соответствующего региона. Для региональных корневых ключей предусмотрен отдельный контролируемый канал. На плоскости передачи данных региональная конфигурация узла, определяющая, к какому региону он относится, задаёт, какие узлы могут получать те или иные региональные корневые ключи.

Иерархия ключей и ключи для отдельных приложений

Метаданные каждого обёрнутого закрытого ключа клиента указывают контекст службы, региональные границы и эпоху.

Контекст службы — это служба Cloudflare, использующая ключ, например Tunnel или Gateway. Региональные границы — это утверждённый набор дата-центров Cloudflare, где ключ можно раскрывать и использовать, например дата-центры в Германии или Европейском союзе. Эпоха указывает, к какому поколению регионального корневого ключа относится ключ; при каждой ротации создаётся новая эпоха.

Например, у Acme Co. может быть один ключ для Tunnel в Германии (acme0001) и другой для Gateway в Германии (acme0002). У Road Runner Inc. может быть один ключ для Tunnel в Германии (runner0001) и другой для Gateway в Европейском союзе (runner0002).

Для ключей с одинаковыми контекстом службы, региональными границами и эпохой используется одна и та же пара ключей для соответствующего приложения. Поэтому компрометация закрытого ключа приложения Tunnel для Германии может раскрыть acme0001 и runner0001, но не ключи Gateway. Компрометация регионального корневого ключа для Германии может затронуть все ключи приложений, созданные на его основе для той же эпохи, в том числе acme0001, acme0002 и runner0001.

В текущей архитектуре пара ключей для отдельного приложения асимметрична. Открытый компонент оборачивает материал закрытого ключа клиента, а для его раскрытия необходим закрытый компонент. Полученный обёрнутый закрытый ключ распространяется вместе с указанием контекста службы (Access, Gateway, Tunnel, клиент Cloudflare One), региона и эпохи.

Подготовка региональных корневых ключей

Процессы создания и подготовки региональных корневых ключей

Когда Cloudflare/администратор настраивает регион для сценария использования CF1, служба управления ключами (которая также создаёт пары ключей для отдельных приложений и оборачивает закрытые ключи клиентов) создаёт региональный корневой ключ, связывает его с региональными границами и эпохой, а затем отправляет в службу подготовки для хранения и распространения. В основе этой службы используется Vault, которым мы управляем локально.

Авторизация периферийных серверов для работы в регионе

Процессы распространения региональных корневых ключей

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

1. Доверенный платформенный модуль (TPM) подтверждает, что сервер обладает зарегистрированной аппаратной идентичностью
2. Zinc, система учёта серверов Cloudflare, сопоставляет эту идентичность с дата-центром и местоположением
3. Служба подготовки определяет, к каким региональным корневым ключам серверу разрешён доступ

Zinc обновляет записи о принадлежности каждого периферийного сервера. Этот асинхронный процесс добавляет новые серверы по мере расширения сети и удаляет выведенные из эксплуатации. Когда Cloudflare проводит техническое обслуживание дата-центров в Германии, определение того, какие дата-центры относятся к Германии, меняется в Zinc. Эти изменения быстро распространяются по нашей сети через Quicksilver, поэтому данные на периферии остаются актуальными. Работает и обратный процесс: когда мы расширяем сеть, определение Германии или любого другого региона обновляется в Zinc и также быстро распространяется по сети через Quicksilver.

Zinc также связывает зарегистрированную аппаратную идентичность с сервером и его физическим местоположением, что помогает обеспечивать соответствие требованиям FIPS 140–3. Аппаратная идентичность, подтверждённая TPM, данные учёта серверов и региональные конфигурации определяют, к какому региону относится периферийный сервер и к каким региональным корневым ключам он может получить доступ.

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

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

Оборачивание закрытых ключей для глобального распространения

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

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

Процесс оборачивания закрытого ключа клиента

Раскрытие ключей для отдельных приложений на плоскости передачи данных

Процесс раскрытия закрытого ключа клиента

Почему мы выбрали такую криптографическую архитектуру

Симметричные корневые ключи и асимметричное оборачивание ключей

Региональные корневые ключи — это симметричные секреты длиной 256 бит. GeoKey Manager создаёт ключи для отдельных приложений на основе каждого регионального корневого ключа. Для текущего сценария Cloudflare One служба управления ключами на плоскости управления создаёт пару ключей гибридного шифрования с открытым ключом (HPKE) для отдельного приложения.

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

В Cloudflare One используется HPKE, определённый в RFC 9180. Механизм инкапсуляции ключей (KEM) объединяет ML-KEM-768 и X25519, а HKDF-SHA-256 используется для выработки ключей, а AES-256-GCM — для аутентифицированного шифрования. Сочетание постквантовых и классических компонентов сохраняет конфиденциальность, пока хотя бы один из компонентов остаётся безопасным.

Архитектура с учётом ротации

Проверенная архитектура поддерживает два типа ротации ключей: мягкую и жёсткую.

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

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

Компромисс между безопасностью и доступностью

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

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

Эксплуатация GeoKey Manager

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

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

Что дальше: интеграция с Cloudflare One и CDN

GeoKey Manager станет основой улучшенного предложения Regional Services для Cloudflare One; новые возможности будут представлены через несколько месяцев.

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

С чего начать

Если вы уже пользуетесь DLS и регионализируете трафик CDN, вы можете здесь сообщить о намерении протестировать эту функцию до её общедоступного запуска для трафика CDN.

Спасибо всем, кто помог воплотить этот продукт в жизнь. Над ним проделали огромную работу команды Data Localization Suite, Cloudflare One и Cloudflare Research.

Cloudflare Blog прочитано 772 раза