В этой статье приводятся ответы на некоторые распространенные вопросы об Аттестации Azure.
Если решение для вашей проблемы с Azure в этой статье отсутствует, вы можете отправить запрос на поддержку Azure на странице поддержки Azure.
Что такое доверенное управление аппаратными удостоверениями (THIM) и ее роль в аттестации анклава?
Trusted Hardware Identity Management (THIM) получает базовые показатели безопасности Azure для узлов конфиденциальных вычислений Azure (ACC) из Intel и кэширует данные. Аттестация Azure также использует кэшированные сведения при проверке доверенных сред выполнения (TEEs).
Служба THIM рекомендуется по следующим причинам:
- Обеспечивает высокий уровень доступности.
- Сокращает зависимости от внешних размещенных служб и подключения к Интернету.
- Периодически извлекает новые версии сертификатов Intel, CRLs, доверенных вычислительных баз (TCB) и удостоверений анклавов узлов ACC из Intel. Служба подтверждает, что базовые показатели безопасности Azure будут ссылаться на Аттестация Azure при проверке teEs, значительно уменьшая сбои аттестации из-за недопустимости или отзыва сертификатов Intel.
Поддерживается ли аттестация расширений Software Guard (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 в географическом регионе, в который клиент развертывает экземпляр службы.