Partekatu honen bidez:


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 se ha creado correctamente una instancia de los archivos binarios de software 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. Los clientes llevan tiempo solicitando la posibilidad de comprobar de forma independiente la ubicación de una máquina, la posición de una máquina virtual en esa máquina y el entorno en el que se ejecutan los enclaves en esa máquina virtual. Azure Attestation hace posible estas y muchas otras peticiones de los clientes.

Azure Attestation recibe la evidencia de entidades de proceso, las convierte en un conjunto de notificaciones, las valida con respecto a directivas configurables y genera pruebas criptográficas para aplicaciones basadas en notificaciones (por ejemplo, usuarios de confianza 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 la opción de cifrado del disco de sistema operativo de la VM con claves administradas por la plataforma, y enlazan las claves de cifrado del disco al TPM de la máquina virtual. Cuando se arranca una CVM, el informe de SNP que contiene las medidas de firmware de la VM invitada se envía 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 capturar el informe de atestación de hardware de AMD directamente desde el 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 esta colección es un paso esencial para democratizar las tecnologías de enclave basadas en hardware, como SGX, y aumentar su aceptació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 directivas específicas del inquilino.
  • 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 de 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 el token de atestación: el token de atestación que genera Azure Attestation está firmado 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. El usuario de confianza puede recuperar el certificado de firma y comprobar la firma del token de atestación. Consulte códigos de ejemplo para obtener más información
  2. Compruebe si Azure Attestation se ejecuta dentro de un enclave de SGX: los certificados de firma de tokens incluyen la cita SGX del TEE dentro del cual se ejecuta Azure Attestation. Si el usuario de confianza 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. Consulte códigos de ejemplo para obtener más información
  3. Valide el enlace de la cita de Azure Attestation SGX con la clave que firmó el token de atestación: el usuario de confianza puede comprobar si el hash de clave pública que firmó el token de atestación coincide con el campo de datos del informe de la cita de Azure Attestation SGX. Consulte códigos de ejemplo 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 cita SGX insertada en los certificados de firma de tokens de atestación incluye medidas de código de Azure Attestation, como MRSIGNER. Si el usuario de confianza está interesado en validar si la cita de SGX pertenece a Azure Attestation que se ejecuta dentro de Azure, el valor MRSIGNER se puede recuperar de la cita de SGX en el certificado de firma de tokens de atestación y en comparación con el valor proporcionado por el equipo de Azure Attestation. Si desea hacer 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 con usted cuando planeemos rotar MRSIGNER.

Se espera que mrsigner de Azure Attestation cambie cuando se roten los certificados de firma de código. El equipo de Azure Attestation seguirá la siguiente programación de lanzamiento para cada rotación de MRSIGNER:

i. El equipo de Azure Attestation enviará una notificación sobre el próximo valor MRSIGNER con un período de gracia de dos meses para que se hagan los cambios de código pertinentes

ii. Después de este período de gracia de dos meses, Azure Attestation empezará a usar el nuevo valor MRSIGNER

iii. Azure Attestation dejará de usar el valor MRSIGNER anterior tres meses después de la fecha de notificación

Compatibilidad con la continuidad empresarial y recuperación ante 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 de plano de datos, incluidas las llamadas de atestación y la configuración de directiva, se atenderán en 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