Сегодня Cloudflare представляет менеджер ключей с постквантовой защитой и географическими ограничениями в поддержку нашего пакета решений для локализации данных (Data Localization Suite, DLS) в режиме закрытого бета-тестирования. Новый PQ GeoKey Manager является краеугольным камнем решений Cloudflare для обеспечения суверенитета данных, гарантируя, что ключи расшифровки клиента доступны только в выбранной им географической зоне. GeoKey Manager реализует это путём обёртки каждого ключа расшифровки таким образом, что его могут расшифровать только серверы Cloudflare, расположенные в разрешённой географической зоне.
Хотя общая доступность (GA) запланирована на первый квартал 2027 года, сегодняшний запуск — важная веха на нашем пути к поддержке целей клиентов в области суверенитета данных и одновременному переводу всех продуктов Cloudflare на постквантовую (PQ) криптографию.
Правительства, финансовые учреждения, поставщики медицинских услуг и оборонные организации обрабатывают особо чувствительные данные, которые могут оставаться конфиденциальными на протяжении многих лет или даже десятилетий после их создания. Для защиты этих данных часто требуется шифрование. При использовании классического шифрования с открытым ключом злоумышленникам не нужен квантовый компьютер уже сегодня, чтобы подвергнуть эти данные риску: они могут сохранить зашифрованный текст и хранить его до тех пор, пока квантовые компьютеры не смогут взломать защищающую его криптографию с открытым ключом — стратегия атаки, известная как «собрать сейчас, расшифровать позже».
Для организаций с географическими требованиями противостояние этой угрозе — лишь половина задачи. При масштабах Cloudflare высокая доступность требует репликации клиентских данных на множество серверов по всей нашей глобальной сети. Однако многие нормативы в области суверенитета данных требуют, чтобы определённые типы данных обрабатывались только в пределах заданного географического региона. Поэтому мы должны обеспечить сквозное шифрование данных таким образом, чтобы доступ к открытому тексту имели только серверы внутри региона. В этой статье мы описываем систему, которая делает это возможным.
Эволюция GeoKey Manager
Компания Cloudflare в 2017 году первой представила концепцию ключей TLS с географическими ограничениями, запустив GeoKey Manager. Это решение позволило клиентам определять, в каких локациях их приватные ключи TLS могут быть развёрнуты в anycast-сети Cloudflare, обеспечивая более надёжные технические гарантии того, в каком регионе расшифровываются их запросы. Например, клиент мог указать, что развёртывание приватных ключей допускается только в Индии. Таким образом, вместо расшифровки по всей глобальной сети 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 client), регионом и эпохой.
Подготовка региональных корневых ключей
Когда Cloudflare/Admin настраивает регион для сценария использования CF1, сервис управления ключами (который также создаёт пары ключей для конкретных приложений и шифрует приватные ключи клиентов) создаёт региональный корневой ключ, связывает его с региональной границей и эпохой и отправляет его в сервис подготовки для хранения и распространения, который под капотом использует Vault, управляемый нами на собственной инфраструктуре.
Авторизация граничных серверов для региона
Прежде чем граничный сервер сможет получить региональный корневой ключ, сервис подготовки оценивает три входных данных:
- Trusted Platform Module (TPM) подтверждает, что сервер обладает зарегистрированной аппаратной идентичностью
- Zinc, система инвентаризации серверов Cloudflare, сопоставляет эту идентичность с дата-центром и местоположением
- Сервис подготовки определяет, к каким региональным корневым ключам сервер может иметь доступ
Zinc обновляет данные о членстве для каждого пограничного сервера. Этот асинхронный процесс добавляет новые серверы по мере роста сети и исключает серверы при выводе из эксплуатации. Когда Cloudflare проводит обслуживание дата-центров в Германии, в Zinc меняется определение того, какие дата-центры относятся к Германии. Это определение быстро распространяется по нашей сети с помощью Quicksilver, чтобы наш периметр оставался актуальным. Работает и обратный процесс. Когда мы наращиваем мощности сети, определение Германии или любого другого региона обновляется в Zinc и также оперативно распространяется по нашей сети через Quicksilver.
Zinc также связывает зарегистрированную аппаратную идентичность с сервером и физическим местоположением, что обеспечивает соответствие FIPS 140-3. Идентичность на основе TPM, данные инвентаризации серверов и региональные конфигурации определяют, к какому региону относится пограничный сервер и к каким региональным корневым ключам он имеет доступ.
Каждый пограничный сервер обращается к службе подготовки контрольной плоскости и предоставляет свою зарегистрированную аппаратную идентичность. После проверки аппаратной идентичности сервера и его региональной принадлежности служба подготовки выдаёт токен, который позволяет серверу получить только те региональные корневые ключи, которые авторизованы для его местоположения. Каждый пограничный сервер получает свой токен и использует его для извлечения региональных корневых ключей.
Авторизованные пограничные серверы загружают региональные корневые ключи в kernel keyring, а не сохраняют их на диске. Управление доступом на уровне процессов ограничивает, какие службы могут их использовать. Поскольку эта память энергозависима, перезапуск машины удаляет ключи, и сервер должен снова пройти аутентификацию и подготовку. Это добавляет операционную сложность в обмен на сокращение объёма постоянного ключевого материала, который мог бы стать вектором атаки для злоумышленников.
Обёртка приватных ключей для глобального распространения
Когда служба управления ключами получает приватный ключевой материал клиента с контекстом службы и региональной границей, она использует региональную границу запроса, чтобы получить региональный корневой ключ и его последнюю настроенную эпоху. Затем она выводит соответствующую асимметричную пару ключей приложения и использует её публичный компонент для обёртки приватного ключа. Результатом являются обёрнутый приватный ключ и его метаданные.
Затем Quicksilver распространит обёрнутый закрытый ключ и метаданные по нашей сети. Поскольку обёрнутый ключ требует указанного региона для расшифровки, глобальное распространение обёрнутого ключа не даёт граничным серверам глобального доступа к закрытому ключу, так как для развёртывания по-прежнему необходимы соответствующий региональный корневой ключ и сервисный контекст.
Развёртывание с использованием ключей, специфичных для приложения, на уровне данных
Почему мы выбрали именно такой криптографический дизайн
Симметричные корни с асимметричной обёрткой ключей
Региональные корневые ключи представляют собой 256-битные симметричные секреты. GeoKey Manager выводит ключи, специфичные для приложения, из каждого регионального корневого ключа. Для текущего пути Cloudflare One сервис управления ключами на уровне управления выводит специфичную для приложения пару ключей Hybrid Public Key Encryption (HPKE).
HPKE с гибридным постквантовым KEM
Путь 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.