В этой статье приводятся ответы на некоторые распространенные вопросы об Аттестации Azure.
Если решение для вашей проблемы с Azure в этой статье отсутствует, вы можете отправить запрос на поддержку Azure на странице поддержки Azure.
Что такое доверенное управление аппаратными удостоверениями (THIM) и ее роль в аттестации анклава
Trusted Hardware Identity Management (THIM) получает базовые показатели безопасности Azure для узлов конфиденциальных вычислений Azure (ACC) из Intel и кэширует данные. В ходе проверки доверенных сред выполнения (TEE) служба Аттестации Azure будет использовать кэшированные данные.
Служба THIM рекомендуется по следующим причинам:
- Обеспечивает высокий уровень доступности.
- Сокращает зависимости от внешних размещенных служб и подключения к Интернету.
- Периодически извлекает новые версии сертификатов Intel, CRLs, доверенных вычислительных баз (TCB) и идентификатор удостоверений анклавов узлов ACC из Intel. Таким образом, служба подтверждает базовый план безопасности Azure, на который будет ссылаться Аттестация Azure, при этом проверяя TEE, что значительно сокращает количество сбоев аттестации из-за недействительности или отзыва сертификатов Intel.
Поддерживается аттестация SGX Аттестация Azure в средах, отличных от Azure
Нет. Аттестация Azure зависит от базового уровня безопасности, указанного с помощью управления удостоверениями доверенного оборудования (THIM) для проверки сред TEE. THIM в настоящее время поддерживает только узлы Конфиденциальных вычислений Azure.
Какие проверки выполняются Аттестация Azure для проверки анклавов SGX
Во время процесса аттестации SGX Аттестация Azure выполняет следующие проверки:
- Проверяет, принадлежит ли доверенный корневой каталог подписанного анклава Intel.
- Проверяет, соответствует ли цитата TEE базовой конфигурации безопасности Azure, как определено доверенным управлением аппаратными удостоверениями (THIM)
- Если клиент создал поставщик аттестации и настроит настраиваемую политику в дополнение к приведенным выше проверкам, Аттестация Azure оценивает цитату TEE по политике аттестации. С помощью политик аттестации клиенты могут определять правила авторизации для TEE, а также диктовать правила выдачи для создания маркера аттестации.
Как проверяющий может получить залог для аттестации SGX, поддерживаемой Аттестация Azure
Как правило, для моделей аттестации с Intel в качестве корня доверия клиент аттестации взаимодействует с API анклава, чтобы получить свидетельство анклава. API анклава внутренне вызывают службу кэширования Intel PCK для получения сертификатов узла Intel, которому требуется аттестация. Сертификаты используются для подписи свидетельства анклава, тем самым создавая удаленную аттестацию для материалов.
Этот же процесс можно реализовать для Аттестации Azure. Тем не менее, чтобы воспользоваться преимуществами, предлагаемыми службой управления удостоверениями доверенного оборудования (THIM), после установки этой виртуальной машины ACC рекомендуется установить библиотеку Azure DCAP. В соответствии с соглашением с Intel, когда установлена библиотека Azure DCAP, запросы на создание свидетельства анклава перенаправляются из службы кэширования Intel PCK в службу THIM. Библиотека Azure DCAP поддерживается в средах под управлением Windows и Linux.
Переход на Аттестация Azure из других моделей аттестации SGX
- После установки виртуальной машины конфиденциальных вычислений Azure установите библиотеку Azure DCAP (Windows/Linux) для использования преимуществ, предлагаемых доверенным управлением аппаратными удостоверениями (THIM).
- Необходимо создать удаленный клиент аттестации, который может получать свидетельство анклава и отправлять запросы в Аттестацию Azure. См. примеры кода для справки
- Запросы аттестации можно отправлять в конечную точку REST API поставщиков по умолчанию или настраиваемых поставщиков аттестации.
- В версии API предварительной версии 2018-09-01-preview клиент должен отправить маркер доступа Microsoft Entra вместе с доказательствами в конечную точку api аттестации SGX. Маркер доступа Microsoft Entra не является обязательным параметром для выполнения аттестации SGX в версии API 2020-10-01
Как проверяющая сторона может проверить целостность маркера аттестации и подтвердить, что Аттестация Azure работает внутри анклава
Маркер аттестации, созданный Аттестацией Azure, подписывается с помощью самозаверяющего сертификата. Сертификаты для подписи предоставляются через конечную точку метаданных OpenID. Проверяющая сторона может получить сертификаты для подписи из этой конечной точки и выполнить проверку подписи маркера аттестации. Сертификат подписи также содержит цитату SGX TEE, в которой выполняется Аттестация Azure. Если проверяющая сторона также предпочитает проверка, если Аттестация Azure работает внутри допустимого анклава SGX, цитата SGX может быть получена из сертификата подписи и локально проверена. Дополнительные сведения см . в примерах кода
Сколько времени действителен маркер аттестации?
Срок действия маркера аттестации составляет 8 часов. В настоящее время нет подготовки для настройки значения.
Определение сертификата для проверки подписи из конечной точки метаданных OpenID
Сертификаты, предоставляемые в конечной точке метаданных OpenID, зависят от вариантов использования (например, аттестации SGX), поддерживаемых Аттестацией Azure. Согласно стандартам, заданным в RFC 7515, для проверки подписи должен использоваться сертификат с идентификатором ключа (дочерний), соответствующий параметру kid в заголовке маркера аттестации. Если соответствующий дочерний сертификат не найден, будут проверены все сертификаты, предоставляемые конечной точкой метаданных OpenID.
Можно ли проверяющей стороне совместно использовать секреты с проверенными доверенными средами выполнения (TEEs)
Во время создания доказательств TEE код, выполняемый внутри TEE, может содержать произвольные сведения в доказательствах. Например, TEE может создать одну или несколько асимметричных пар ключей, сериализовать компоненты открытого ключа этих пар ключей в виде строки JSON JWKS и включить строку JSON JWKS в доказательства TEE в качестве кавычки RunTimeData { в строке JSON JWKS }. Аттестация Azure проверка, если хэш SHA256 runtimeData соответствует нижнему 32 байту атрибута "данные отчета" кавычки. После оценки доказательств TEE Аттестация Azure создает JWT с JWKS, доступным как утверждение "ключи" в утверждении x-ms-runtime. RunTimeData можно дополнительно использовать проверяющей стороной для установления безопасного канала и безопасной передачи данных в TEE.
Где Аттестация Azure хранить данные клиента?
Аттестация Azure хранит неактивные данные клиента во время обработки и реплика для целей BCDR в географическом регионе, в который клиент развертывает экземпляр службы.