Открытые стандарты, такие как SPIFFE и SPIRE, обеспечивают надежные гарантии изоляции, создавая основу для нулевого доверия (Zero Trust), пишет на портале The New Stack Марина Мур, научный сотрудник Edera.

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

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

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

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

SPIFFE и значение идентификации рабочих нагрузок

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

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

SPIFFE (Secure Production Identity Framework for Everyone) — это спецификация, которая напрямую решает вопрос идентификации рабочих нагрузок. Она определяет, как идентифицируются рабочие нагрузки, как эти идентификаторы представлены и как их можно проверять в распределенных системах. SPIFFE ID — это структурированный идентификатор, привязанный к домену доверия (trust domain) и конкретной рабочей нагрузке. Он не является секретом и не привязан к IP-адресу или долгосрочным учетным данным. Вместо этого он становится значимым только в паре с криптографическим документом, известным как SVID (SPIFFE Verifiable Identity Document).

SVID связывает SPIFFE ID с парой ключей и центром подписи. Это позволяет рабочим нагрузкам аутентифицироваться друг перед другом, используя кратковременные учетные данные, которые могут автоматически обновляться. С точки зрения разработчика или оператора это выглядит знакомо. Это аналогично работе двухсторонних сертификатов в Интернете, но здесь речь идёт о рабочей нагрузке, а не о доменном имени.

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

SPIRE как среда выполнения для обеспечения доверия

SPIRE — это эталонная реализация спецификации SPIFFE. Если SPIFFE определяет, как выглядит идентификация рабочей нагрузки, то SPIRE определяет, как она выдается и управляется на практике. Она включает два основных компонента: сервер SPIRE и агенты SPIRE.

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

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

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

Сочетание зонирования и изоляции

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

В этой модели зоны становятся естественными единицами доверия. Зона — это не просто конструкция планирования, а граница безопасности. Это делает ее идеальной основой для идентификации рабочей нагрузки. Задача состоит в том, чтобы доказать удаленной стороне, что рабочая нагрузка действительно выполняется внутри такой зоны.

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

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

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

Почему это важно сейчас

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

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

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

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