Compartir a través de

Microsoft Azure Attestation

Microsoft Azure Attestation es una solución unificada para comprobar de forma remota la confiabilidad de una plataforma y la integridad de los archivos binarios que se ejecutan en ella. El servicio admite la atestación de las plataformas respaldadas por módulos de plataforma segura (TPM), junto con la posibilidad de atestiguar el estado de los entornos de ejecución de confianza (TEE), como los enclaves Software Guard Extensions de Intel® (SGX) y de seguridad basada en virtualización (VBS), Módulos de plataforma de confianza (TPM), inicio seguro para VM de Azure y VM confidenciales de Azure.

La atestación es un proceso que se utiliza para demostrar que los archivos binarios de software se han instanciado correctamente en una plataforma de confianza. Así, los usuarios de confianza remotos pueden tener la seguridad de que solo se ejecuta el software previsto en el hardware de confianza. Azure Attestation consta de un servicio y un marco de trabajo unificados orientados al cliente para la atestación.

Azure Attestation utiliza paradigmas de seguridad de vanguardia, como la computación confidencial en Azure y la protección de inteligencia perimetral. El servicio recibe evidencia de las entidades computacionales, las convierte en un conjunto de reclamos, las valida según políticas configurables y genera pruebas criptográficas para aplicaciones basadas en reclamos (por ejemplo, partes confiables y autoridades de auditoría).

Azure Attestation admite tanto la atestación de plataforma como de invitado de máquinas virtuales confidenciales (CVM) basadas en SEV-SNP de AMD. La atestación de plataforma basada en Azure Attestation se produce automáticamente durante la ruta de arranque crítica de las CVM, sin necesidad de realizar ninguna acción del cliente. Para más información sobre la atestación de invitado, consulte Anuncio de la disponibilidad general de la atestación de invitado para máquinas virtuales confidenciales.

Casos de uso

Azure Attestation proporciona completos servicios de atestación para varios entornos y diferentes casos de uso.

Atestación de AMD SEV-SNP sobre máquinas virtuales confidenciales

Las máquinas virtuales confidenciales (CVM) de Azure se basan en procesadores AMD con tecnología SEV-SNP. Las CVM ofrecen una opción de cifrado del disco del sistema operativo de la VM con claves administradas por la plataforma o por el cliente, y vinculan las claves de cifrado del disco al TPM de la máquina virtual. Cuando se inicia un CVM, se envía un informe de SNP que contiene las medidas de firmware de la máquina virtual invitada a Azure Attestation. El servicio valida las medidas y emite un token de atestación que se usa para liberar claves de HSM administrado o Azure Key Vault. Estas claves se usan para descifrar el estado de vTPM de la VM invitada, desbloquear el disco de SO e iniciar la CVM. El proceso de atestación y emisión de claves se realiza automáticamente en cada arranque de la CVM, y el proceso garantiza que la CVM arranque solo tras la atestación correcta del hardware.

Atestación de AMD SEV-SNP sobre contenedores confidenciales

Los contenedores confidenciales (CVM) de Azure se basan en procesadores AMD con tecnología SEV-SNP. Los contenedores confidenciales, hospedados en Azure Container Instances y en Azure Kubernetes Service (en versión preliminar) ofrecen la capacidad de ejecutar grupos de contenedores en un entorno de ejecución de confianza protegido por SEV-SNP que aísla ese grupo de contenedores del plano de control de administración de contenedores y otros contenedores en ejecución. La atestación en contenedores confidenciales implica obtener el informe de atestación de hardware de AMD directamente del procesador. Esto se puede lograr con nuestro contenedor sidecar de SKR o compilar directamente en la lógica de la aplicación. A continuación, el informe de hardware se puede intercambiar con Azure Attestation y managed-HSM o Premium Azure Key Vault (AKV) para recuperar secretos. También puede proporcionar el informe de hardware a su propio sistema de almacén de claves según sea necesario.

Atestación de inicio seguro

Los clientes de Azure pueden evitar las infecciones de bootkit y rootkit habilitando el inicio seguro para sus máquinas virtuales (VM). Cuando la VM está habilitada para el arranque seguro y vTPM con la extensión de atestación de invitado instalada, las mediciones del vTPM se envían a Azure Attestation periódicamente para supervisar la integridad del arranque. Un error de atestación indica un posible malware, que se muestra a los clientes a través de Microsoft Defender for Cloud, mediante Alertas y Recomendaciones.

Atestación de TPM

La atestación basada en módulos de plataforma segura (TPM) es fundamental para proporcionar una prueba del estado de una plataforma. Un TPM actúa como raíz de confianza y coprocesador de seguridad para proporcionar validez criptográfica a las medidas (evidencia). Los dispositivos con un TPM pueden confiar en la atestación como prueba de que la integridad del arranque no está comprometida y usar las notificaciones para detectar la habilitación del estado de las características durante el arranque.

Las aplicaciones cliente se pueden diseñar para aprovechar las ventajas de la atestación de TPM mediante la delegación de tareas que afectan a la seguridad para que solo tengan lugar después de que se haya validado una plataforma como segura. Estas aplicaciones pueden usar Azure Attestation para establecer de forma rutinaria la confianza en la plataforma y su capacidad para acceder a datos confidenciales.

Atestación de enclaves de SGX

Intel® Software Guard Extensions (SGX) hace referencia al aislamiento de nivel de hardware que ofrecen algunos modelos de CPU de Intel. SGX permite que el código se ejecute en compartimientos saneados conocidos como enclaves SGX. Después, el hardware administra los permisos de acceso y memoria para garantizar una superficie mínima de ataque con el aislamiento adecuado.

Las aplicaciones cliente se pueden diseñar para aprovechar las ventajas de los enclaves SGX y delegar tareas que afectan a la seguridad de modo que se lleven a cabo dentro de esos enclaves. Estas aplicaciones pueden usar Azure Attestation para establecer de forma rutinaria la confianza en el enclave y su capacidad para acceder a datos confidenciales.

Los procesadores escalables Intel® Xeon® solo admiten soluciones de atestación basadas en ECDSA para la atestación remota de enclaves SGX. Mediante el modelo de atestación basado en ECDSA, Azure Attestation admite la validación de plataformas de servidor basadas en los procesadores escalables Intel® Xeon® E3 e Intel® Xeon®.

Nota:

Para realizar la atestación de plataformas de servidor basadas en los procesadores escalables Intel® Xeon® mediante Azure Attestation, se espera que los usuarios instalen la versión 1.10.0 de Azure DCAP o posterior.

Atestación de Open Enclave

Open Enclave (OE) es una colección de bibliotecas destinadas a crear una única abstracción unificada de enclave para que los desarrolladores creen aplicaciones basadas en TEE. Ofrece un modelo de aplicación segura universal que reduce las características específicas de cada plataforma. Microsoft considera que es un paso esencial para democratizar las tecnologías de enclave basadas en hardware, como SGX, y aumentar su adopción en Azure.

OE normaliza los requisitos específicos para la comprobación de una evidencia de enclave. Esto hace de OE un consumidor de atestación de Azure Attestation con gran capacidad de ajuste.

Azure Attestation se ejecuta en un TEE

Azure Attestation es fundamental en los escenarios de computación confidencial, ya que realiza las acciones siguientes:

  • Comprueba si la evidencia del enclave es válida.
  • Evalúa la evidencia del enclave con respecto a una directiva definida por el cliente.
  • Administra y almacena políticas específicas del arrendatario.
  • Genera y firma un token que emplean los usuarios de confianza para interactuar con el enclave.

Para mantener Microsoft operativamente fuera de la base informática de confianza (TCB), las operaciones críticas de Azure Attestation, como la validación de ofertas, la generación de tokens, la evaluación de directivas y la firma de tokens, se mueven a un enclave SGX.

Razones para usar Azure Attestation

Azure Attestation es la opción preferida para la atestación de los entornos de ejecución de confianza, ya que ofrece las siguientes ventajas:

  • Ofrece un marco unificado para la atestación de varios entornos, como los TPM y los enclaves SGX y VBS.
  • Permite la creación de proveedores de atestación personalizados y la configuración de directivas para restringir la generación de tokens.
  • Protege sus datos mientras están en uso con la implementación en un enclave SGX o en una Máquina Virtual Confidencial basada en SEV-SNP de AMD.
  • Servicio de alta disponibilidad

Cómo se establece confianza con Azure Attestation

  1. Compruebe si Azure Attestation genera un token de atestación : se firma un token de atestación generado por Azure Attestation mediante un certificado autofirmado. La URL de certificados de firma se expone a través de un punto de conexión de metadatos de OpenID. Un usuario de confianza puede recuperar el certificado de firma y realizar la comprobación de firma del token de atestación. Consulte ejemplos de código para obtener más información.
  2. Compruebe si Azure Attestation se ejecuta dentro de un enclave SGX o SEV-SNP contenedor : los certificados de firma de tokens incluyen información sobre el TEE dentro del que se ejecuta Azure Attestation. Esta garantía TEE puede ser una cotización SGX o un informe SEV-SNP. El usuario de confianza puede comprobar si Azure Attestation se está ejecutando dentro de un TEE válido validando localmente la cita o el informe. Consulte ejemplos de código para obtener más información: SGX, SEV-SNP
  3. Validar el enlace del informe TEE de Azure Attestation con la clave que firmó el token de atestación – La parte confiable puede comprobar si el hash de la clave pública que firmó el token de atestación coincide con el campo de datos del informe TEE de Azure Attestation. Consulte aquí para obtener más información.
  4. Compruebe si las medidas del código de Azure Attestation coinciden con los valores publicados de Azure: la garantía TEE insertada en los certificados de firma de tokens de atestación incluye medidas de código TEE de Azure Attestation. Un usuario de confianza puede validar que la cita o el informe pertenecen a Azure Attestation comparando valores específicos recuperados de la garantía TEE en el certificado de firma de tokens de atestación con los valores proporcionados por el equipo de Azure Attestation. Para SGX, MRSIGNER debe ser validado. Para SEV-SNP, se debe validar HOST_DATA. Consulte aquí para obtener más información. Si está interesado en realizar esta validación, envíe una solicitud en la página de soporte técnico de Azure. El equipo de Azure Attestation se pondrá en contacto contigo cuando estos valores específicos estén programados para la rotación.

Se espera que los valores que identifican instancias válidas de Azure Attestation cambien cuando se rotan los certificados de firma de código o cuando las actualizaciones de seguridad requieren nuevas versiones de directiva. El equipo de Azure Attestation sigue la programación de lanzamiento siguiente para cada rotación planeada:

i. El equipo de Azure Attestation notifica a los consumidores los nuevos valores con un período de gracia de dos meses para implementar los cambios de código pertinentes.

ii. Después del período de gracia de dos meses, Azure Attestation comienza a usar los nuevos valores.

iii. Tres meses después de la fecha de notificación, Azure Attestation deja de usar los valores antiguos.

En el caso de las rotaciones no planeadas, incluidas las requeridas por las actualizaciones de seguridad, el equipo de Azure Attestation comunica nuevos valores con un período de gracia de un mes.

Soporte para la continuidad empresarial y recuperación de desastres (BCDR)

La continuidad empresarial y recuperación ante desastres (BCDR) para Azure Attestation permite mitigar las interrupciones del servicio que se producen como consecuencia de desastres o de problemas de disponibilidad significativos en una región.

En circunstancias normales, los clústeres implementados en dos regiones funcionan de forma independiente. Si se produce un error o una interrupción en una región, sucederá lo siguiente:

  • La BCDR de Azure Attestation proporcionará una conmutación por error fluida, en la que los clientes no tendrán que realizar ningún paso adicional para la recuperación.
  • El servicio de Azure Traffic Manager para la región detecta si el sondeo de estado está degradado y cambia el punto de conexión a la región emparejada.
  • Las conexiones existentes no funcionarán y recibirán problemas de tiempo de espera o errores internos del servidor.
  • Se bloquearán todas las operaciones del plano de control. Los clientes no podrán crear proveedores de atestación en la región primaria.
  • Todas las operaciones del plano de control, incluidas las llamadas de atestación y la configuración de directivas, serán gestionadas desde la región secundaria. Los clientes pueden seguir trabajando en las operaciones de plano de datos con el URI original correspondiente a la región primaria.

Pasos siguientes