Preguntas más frecuentes sobre Microsoft Azure Attestation

Trusted Hardware Identity Management (THIM) obtiene la línea de base de seguridad de Azure para los nodos de computación confidencial de Azure (ACC) de Intel y almacena los datos en caché. Azure Attestation también usa la información almacenada en caché en la validación de entornos de ejecución de confianza (TEE).

THIM se recomienda por los motivos siguientes:

• Ofrece alta disponibilidad.
• Reduce las dependencias en servicios hospedados externamente y en la conectividad a Internet.
• Obtiene periódicamente las últimas versiones de los certificados Intel, las CRL, la información de la base de computación de confianza (TCB) y la identidad de enclaves de citas de los nodos de ACC de Intel. El servicio confirma la línea de base de seguridad de Azure a la que va a hacer referencia Azure Attestation durante la validación de los TEE, lo que reduce considerablemente los errores de atestación debido a la invalidación o la revocación de los certificados de Intel.

No. Azure Attestation depende de la línea de base de seguridad indicada por Trusted Hardware Identity Management (THIM) para validar los TEE. THIM está diseñado actualmente para admitir solamente los nodos de computación confidencial de Azure.

Durante el proceso de atestación de SGX, Azure Attestation realiza las siguientes validaciones:

• Valida si la raíz de confianza de l< cita del enclave firmado pertenece a Intel
• Valida si la cita de TEE cumple la línea de base de seguridad de Azure tal y como se define en Trusted Hardware Identity Management (THIM)
• Si el cliente creó un proveedor de atestación y configuró una directiva personalizada, además de las validaciones anteriores, Azure Attestation evaluará la cotización de TEE con respecto a la directiva de atestación. Los clientes pueden usar directivas de atestación para definir reglas de autorización para el TEE y también dictar reglas de emisión para generar el token de atestación.

En general, en los modelos de atestación con Intel como raíz de confianza, el cliente de atestación se comunica con las API de enclave para capturar la evidencia del enclave. Las API de enclave llaman internamente al servicio de almacenamiento en caché de PCK de Intel para capturar los certificados de Intel del nodo que se va a atestiguar. Los certificados se usan para firmar la evidencia del enclave, con lo que se genera un colateral de forma remota.

El mismo proceso se puede implementar para Azure Attestation. Sin embargo, para aprovechar las ventajas que ofrece Trusted Hardware Identity Management (THIM), después de instalar la máquina virtual de ACC, se recomienda instalar la biblioteca de Azure DCAP. En función del contrato con Intel, cuando se instala la biblioteca de Azure DCAP, las solicitudes de generación de evidencias de enclave se redirigen desde el servicio de almacenamiento en caché de PCK de Intel a THIM. La biblioteca de Azure DCAP es compatible con entornos basados en Windows y Linux.

• Después de instalar la máquina virtual de Computación confidencial de Azure, instale la biblioteca de Azure DCAP (Windows/Linux) para aprovechar las ventajas que ofrece Trusted Hardware Identity Management (THIM).
• Es necesario crear el cliente de atestación remoto que pueda recuperar la evidencia del enclave y enviar solicitudes a Azure Attestation. Consulte estos códigos de ejemplos como referencia.
• Las solicitudes de atestación se pueden enviar al punto de conexión de la API REST de proveedores predeterminados o proveedores de atestación personalizados.
• En la versión de la API 2018-09-01-preview, el cliente debe enviar el token de acceso de Microsoft Entra junto con la evidencia para el punto de conexión de la API de atestación de SGX. El token de acceso de Microsoft Entra no es un parámetro necesario para realizar la atestación de SGX en la versión de API 2020-10-01.

El token de atestación que genera Azure Attestation se firma con un certificado autofirmado. Los certificados de firma se exponen a través de un punto de conexión de metadatos de OpenID. El usuario de confianza puede recuperar los certificados de firma de este punto de conexión y realizar la comprobación de la firma del token de atestación. El certificado de firma también incluye la cita de SGX del TEE dentro del cual se ejecuta Azure Attestation. Si el usuario de confianza también prefiere comprobar si Azure Attestation se ejecuta dentro de un enclave de SGX válido, la cita de SGX se puede recuperar del certificado de firma y validarse localmente. Para obtener más información, consulte ejemplos de código.

El tiempo de validez del token de atestación es de 8 horas. Actualmente, no hay ninguna disposición para personalizar el valor.

Hay varios certificados expuestos en el punto de conexión de metadatos de OpenID que se corresponden con distintos casos de uso (por ejemplo, la atestación de SGX) compatibles con Azure Attestation. Según los estándares especificados por RFC 7515, el certificado con el identificador de clave (kid) que coincida con el parámetro kid del encabezado del token de atestación se usará para la comprobación de la firma. Si no se encuentra ninguna clave kid coincidente, pruebe todos los certificados expuestos por el punto de conexión de metadatos de OpenID.

En el momento de la creación de pruebas TEE, el código que se ejecuta dentro del TEE puede incluir información arbitraria en la evidencia. Por ejemplo, el TEE puede crear uno o varios pares de claves asimétricas, serializar los componentes de clave pública de estos pares clave como cadena JSON de JWKS e incluir la cadena JSON de JWKS en la evidencia TEE como RunTimeData { cita, cadena JSON de JWKS }. Azure Attestation comprueba si el hash SHA256 de RuntimeData coincide con los 32 bytes inferiores del atributo "datos de informe" de la cita. Después de evaluar la evidencia de TEE, Azure Attestation genera JWT con JWKS disponible como una notificación denominada "claves" en la notificación "x-ms-runtime". RunTimeData se puede usar aún más mediante el usuario de confianza para establecer un canal seguro y transmitir datos de forma segura al TEE.

Azure Attestation guarda los datos de los clientes en reposo durante el procesamiento y la replicación, con fines de BCDR dentro de la ubicación geográfica en la que el cliente implementa la instancia de servicio.