Сегодня компания Cloudflare запускает в режиме закрытого бета-тестирования географически ограниченный менеджер ключей с постквантовой защитой в рамках нашего пакета Data Localization Suite (DLS). Этот новый PQ GeoKey Manager является краеугольным камнем решений Cloudflare по обеспечению суверенитета данных, гарантируя, что ключи расшифрования клиента доступны только в выбранном им географическом регионе. GeoKey Manager реализует это путем инкапсуляции каждого ключа расшифрования таким образом, чтобы его могли расшифровать только серверы Cloudflare, расположенные в разрешенном регионе.
Хотя полноценный общий доступ (GA) запланирован на первый квартал 2027 года, сегодняшний запуск является важным этапом на нашем пути к достижению целей клиентов в области суверенитета данных, а также к переводу всех продуктов Cloudflare на постквантовую (PQ) криптографию.
Правительства, финансовые институты, организации здравоохранения и оборонные ведомства обрабатывают конфиденциальные данные, которые могут оставаться таковыми в течение многих лет или десятилетий после их создания. Для защиты таких данных часто требуется шифрование. При использовании классического шифрования с открытым ключом злоумышленникам не обязательно иметь квантовый компьютер прямо сейчас, чтобы поставить эти данные под угрозу: они могут сохранить зашифрованный текст и удерживать его до тех пор, пока квантовые компьютеры не смогут взломать защищающую его криптосистему с открытым ключом (стратегия атак, известная как «перехвати сейчас, расшифруй потом»).
Для организаций с географическими требованиями противодействие этой угрозе — лишь половина задачи. В масштабах Cloudflare для обеспечения высокой доступности требуется репликация клиентских данных на множестве серверов по всей нашей глобальной сети. Однако многие правила обеспечения суверенитета данных требуют, чтобы определенные типы данных обрабатывались только в пределах заданного географического региона. Поэтому мы должны гарантировать сквозное шифрование данных, при котором доступ к открытому тексту имеют только серверы внутри этого региона. В этой статье мы описываем систему, которая делает это возможным.
Эволюция GeoKey Manager
Компания Cloudflare заложила основы концепции ключей безопасности транспортного уровня (TLS) с географическим ограничением еще в 2017 году с помощью GeoKey Manager. Это дало клиентам контроль над тем, в каких точках глобальной сети anycast от Cloudflare их закрытые TLS-ключи могут быть распакованы, обеспечив более надежные технические гарантии региона, в котором расшифровываются их запросы. Например, клиент мог выбрать распаковку своих закрытых ключей исключительно в Индии. Таким образом, вместо разрешения расшифрования по всей глобальной сети Cloudflare GeoKey Manager гарантирует, что TLS-подписание для каждого запроса клиента происходит именно в нашей сети в Индии.
GeoKey Manager получил дальнейшее развитие в 2022 году с внедрением шифрования на основе атрибутов с политикой шифротекста (ABE). Вместо привязки зашифрованных ключей к фиксированному набору дата-центров, ABE выражала географические требования с помощью таких атрибутов, как страна или регион, например «region = European Union» или «region = Canada + United States + Mexico». Вновь авторизованные серверы получали соответствующие возможности расшифрования без необходимости повторного шифрования каждого ключа клиента.
Эта гибкость создала как проблему, так и возможность для перехода к постквантовой криптографии. На сегодняшний день не существует готовых к производственному использованию схем 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-Germany может поставить под угрозу как acme0001, так и runner0001, но не ключи Gateway. Компрометация регионального корневого ключа Германии может затронуть каждый специфичный для приложения ключ, производный от этого корня для той же эпохи, включая acme0001, acme0002 и runner0001.
В текущей архитектуре специфичная для приложения пара ключей является асимметричной. Публичный компонент шифрует материал приватного ключа клиента, в то время как приватный компонент требуется для его расшифрования. Полученный зашифрованный приватный ключ распространяется вместе с его контекстом службы (Access, Gateway, Tunnel, клиент Cloudflare One), регионом и эпохой.
Подготовка региональных корневых ключей
Когда Cloudflare/Admin настраивает регион для варианта использования CF1, служба управления ключами (которая также выводит специфичные для приложения пары ключей и шифрует приватные ключи клиентов) создает региональный корневой ключ, связывает его с региональной границей и эпохой, а затем отправляет его в службу подготовки для хранения и распространения, которая под капотом использует Vault, управляемый нами локально (on-premises).
Авторизация пограничных серверов для региона
Прежде чем пограничный сервер сможет получить региональный корневой ключ, служба подготовки оценивает три параметра:
- Доверенный платформенный модуль (TPM) доказывает, что сервер обладает зарегистрированной аппаратной идентичностью
- Zinc, система инвентаризации серверов Cloudflare, сопоставляет эту идентичность с дата-центром и местоположением
- Служба подготовки определяет, к каким региональным корневым ключам сервер может получить доступ
Zinc обновляет свои записи о принадлежности для каждого пограничного сервера. Этот асинхронный процесс добавляет новые серверы по мере роста сети и удаляет серверы при их выводе из эксплуатации. По мере того как Cloudflare выполняет обслуживание дата-центров в Германии, определение того, какие дата-центры принадлежат Германии, изменяется в Zinc. Это определение быстро распространяется по нашей сети с помощью Quicksilver, благодаря чему наш периметр всегда актуален. Обратный процесс также работает. По мере добавления емкости в нашу сеть определение Германии или любого другого региона обновляется в Zinc, и это также быстро распространяется по нашей сети с помощью Quicksilver.
Zinc также связывает зарегистрированную аппаратную идентичность с сервером и физическим местоположением, что поддерживает комплаенс. Идентичность на базе TPM, данные инвентаризации серверов и региональные конфигурации определяют, к каком региону принадлежит пограничный сервер и к каким региональным корневым ключам он может получить доступ.
Каждый пограничный сервер вызывает службу подготовки плоскости управления и предоставляет свою зарегистрированную аппаратную идентичность. После проверки аппаратной идентичности сервера и его региональной принадлежности служба подготовки выдает токен, который позволяет серверу получить только те региональные корневые ключи, которые авторизованы для его местоположения. Каждый пограничный сервер получает свой токен и использует его для получения региональных корневых ключей.
Авторизованные пограничные серверы загружают региональные корневые ключи в связку ключей ядра (kernel keyring), а не сохраняют их на диск. Контроль доступа на уровне процессов ограничивает список служб, которые могут их использовать. Поскольку эта память является энергозависимой, перезагрузка машины удаляет ключи, и сервер должен заново пройти аутентификацию и получить их. Это добавляет операционной сложности в обмен на сокращение постоянного материала ключей, который мог бы стать вектором атаки для злоумышленников.
Шифрование приватных ключей для глобального распространения
Когда служба управления ключами получает материал приватного ключа клиента с контекстом службы и региональной границей, она использует региональную границу запроса для получения регионального корневого ключа и его последней настроенной эпохи. Затем она выводит соответствующую асимметричную пару ключей приложения и использует ее публичный компонент для шифрования приватного ключа. Результатом является зашифрованный приватный ключ и его метаданные.
Затем Quicksilver распределяет зашифрованный приватный ключ и метаданные по всей нашей сети. Поскольку для расшифрования зашифрованного ключа требуется указанный регион, глобальное распространение зашифрованных ключей не дает пограничным серверам глобального доступа к приватному ключу, так как для расшифрования по-прежнему требуются соответствующий региональный корневой ключ и контекст службы.
Расшифрование с использованием специфичных для приложения ключей на плоскости данных
Почему мы выбрали такой криптографический дизайн
Симметричные корни с асимметричным шифрованием ключей
Региональные корневые ключи представляют собой 256-битные симметричные секреты. GeoKey Manager выводит специфичные для приложения ключи из каждого регионального корневого ключа. Для текущего пути Cloudflare One служба управления ключами плоскости управления выводит специфичную для приложения пару ключей HPKE (Hybrid Public Key Encryption).
HPKE с гибридным постквантовым KEM
Путь Cloudflare One использует HPKE, как определено в RFC 9180. Механизм инкапсуляции ключей (KEM) объединяет с 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-трафика here.
Спасибо всем, кто воплотил этот продукт в жизнь. Это были огромные усилия команд Data Localization Suite, Cloudflare One и Cloudflare Research.
