Preguntas más frecuentes sobre máquinas virtuales confidenciales de Azure

Las máquinas virtuales confidenciales son una solución IaaS para inquilinos con requisitos de seguridad y confidencialidad elevados. Las máquinas virtuales confidenciales ofrecen lo siguiente:

• Cifrado de "datos en uso", incluido el estado del procesador y la memoria de la máquina virtual. El procesador genera las claves y nunca las deja.
• La atestación de host le ayuda a comprobar el estado completo y el cumplimiento del servidor antes de que comience el procesamiento de datos.
• Se puede conectar el módulo de seguridad de hardware (HSM) para proteger las claves de los discos de máquina virtual confidenciales, que el inquilino posee exclusivamente.
• Nueva arquitectura de arranque UEFI que admite el sistema operativo invitado para mejorar la configuración de seguridad y las capacidades.
• Un módulo de plataforma de confianza (TPM) virtual dedicado certifica el estado de la máquina virtual, proporciona administración de claves protegida y admite casos de uso como BitLocker.

Las máquinas virtuales confidenciales abordan las preocupaciones de los clientes sobre cómo mover cargas de trabajo confidenciales remotas a la nube. Las máquinas virtuales confidenciales proporcionan protecciones elevadas para los datos de los clientes a partir de la infraestructura subyacente y los operadores en la nube. A diferencia de otros enfoques y soluciones, no es necesario adaptar las cargas de trabajo existentes para ajustarlas a las necesidades técnicas de la plataforma.

SEV-SMP significa Secure Encrypted Virtualization-Secure Nested Paging. Es una tecnología de entorno de ejecución de confianza (TEE) proporcionada por AMD y ofrece varias protecciones: cifrado de memoria, claves de CPU únicas, cifrado para el estado del registro del procesador, protección de integridad, prevención de reversión del firmware, protección de reversión del firmware, protección del canal lateral y restricciones en el comportamiento de interrupciones y excepciones. Conjuntamente, las tecnologías AMD SEV refuerzan las protecciones de invitado para denegar el acceso del hipervisor y otro código de administración de host a la memoria y el estado de la máquina virtual. Las máquinas virtuales confidenciales combinan AMD SEV-SNP con tecnologías de Azure, como el cifrado de disco completo y HSM administrado de Azure Key Vault. Puede cifrar los datos en uso, en tránsito y en reposo gracias a claves que controla. Con funcionalidades de Azure Attestation integradas, puede establecer de forma independiente la confianza en el estado de seguridad y la infraestructura subyacente de las máquinas virtuales confidenciales.

Intel TDX significa Intel Trust Domain Extensions. Es una tecnología de entorno de ejecución de confianza (TEE) proporcionada por Intel y ofrece varias protecciones. Intel TDX usa extensiones de hardware para administrar y cifrar la memoria y protege tanto la confidencialidad como la integridad del estado de la CPU. Además, Intel TDX ayuda a proteger el entorno virtualizado al denegar al hipervisor, a otro código de administración de host y a los administradores el acceso a la memoria y al estado de la máquina virtual. Las máquinas virtuales confidenciales combinan Intel TDX con tecnologías de Azure, como el cifrado de disco completo y HSM administrado de Azure Key Vault. Puede cifrar los datos en uso, en tránsito y en reposo gracias a claves que controla.

Las máquinas virtuales de Azure ya ofrecen seguridad y protección líderes del sector contra otros inquilinos e intrusos malintencionados. Las máquinas virtuales confidenciales de Azure aumentan estas protecciones mediante TEE basadas en hardware como SEV-SNP de AMD e Intel TDX para aislar y proteger criptográficamente la confidencialidad e integridad de los datos. Ni los administradores de host ni los servicios (incluido el hipervisor de Azure) pueden ver o modificar directamente el estado de memoria o CPU de la máquina virtual. Además, con la capacidad de atestación completa, el cifrado de disco del sistema operativo completo y los módulos de plataforma segura virtual protegidos por hardware, el estado persistente está protegido de modo que ni las claves privadas ni el contenido de la memoria se exponen nunca al entorno de hospedaje no cifrado.

Actualmente, los discos del sistema operativo para máquinas virtuales confidenciales se pueden cifrar y proteger. Para mayor seguridad, puede habilitar el cifrado de nivel de invitado (como BitLocker o dm-crypt) para todas las unidades de datos.

Sí, pero solo si pagefile.sys se encuentra en el disco del sistema operativo cifrado. En máquinas virtuales confidenciales con un disco temporal, el archivo pagefile.sys se puede mover al sistema operativo cifrado. Sugerencias para mover pagefile.sys a la unidad c:\ .

No, esta capacidad no existe para las máquinas virtuales confidenciales.

Estas son algunas maneras de implementar una máquina virtual confidencial:

• Implementación desde Azure Portal
• Implementación desde la Interfaz de la línea de comandos de Azure (CLI de Azure)
• Implementación mediante una plantilla de ARM
• Implementación mediante VMSS y cifrado de disco confidencial

Las máquinas virtuales confidenciales de Azure en AMD SEV-SNP se someten a la atestación como parte de su fase de arranque. Este proceso es opaco para el usuario y lo lleva a cabo el sistema operativo en la nube junto con los servicios Microsoft Azure Attestation y Azure Key Vault. Las máquinas virtuales confidenciales también permiten a los usuarios realizar una atestación independiente para sus máquinas virtuales confidenciales. Esta atestación se produce mediante nuevas herramientas denominada atestación de invitado de máquina virtual confidencial de Azure. La atestación de invitado permite a los clientes atestiguar que sus máquinas virtuales confidenciales se ejecutan en procesadores AMD con SEV-SNP habilitado.

Las máquinas virtuales confidenciales de Azure que usan Intel TDX se pueden certificar de forma transparente como parte del flujo de arranque para asegurarse de que la plataforma sea compatible y esté actualizada. El proceso es opaco para el usuario y tiene lugar mediante Microsoft Azure Attestation y Azure Key Vault. Si quiere seguir realizando comprobaciones posteriores al arranque, está disponible la atestación en la plataforma invitada. Esto le permite comprobar que la máquina virtual se ejecuta en la tecnología Intel TDX auténtica. Para acceder a esta característica, visite nuestra rama de versión preliminar. Además, se admite intel® Trust Authority para empresas que buscan atestación independiente del operador. La compatibilidad con la atestación completa en invitado, similar a AMD SEV-SNP estará disponible próximamente. Esto permite a las organizaciones profundizar y validar otros aspectos, incluso hasta el nivel de aplicación invitada.

Para poder ejecutarse en una máquina virtual confidencial, las imágenes del sistema operativo deben cumplir determinados requisitos de seguridad y compatibilidad. Esto permite que las máquinas virtuales confidenciales se monten, atesten y aislen de forma segura desde la infraestructura de la nube subyacente. En el futuro, tenemos previsto proporcionar instrucciones sobre cómo realizar una compilación personalizada de Linux y aplicar un conjunto de revisiones de código abierto para calificarla como una imagen de máquina virtual confidencial.

Sí. Puede usar Azure Compute Gallery para modificar una imagen de máquina virtual confidencial como, por ejemplo, al instalar aplicaciones. Después, puede implementar máquinas virtuales confidenciales en función de la imagen modificada.

El esquema de cifrado de disco completo opcional es el más seguro de Azure y cumple los principios de Computación confidencial. Pero también se pueden usar otros esquemas de cifrado de disco junto con el cifrado de disco completo, o en lugar de este. Si usa varios esquemas de cifrado de disco, el cifrado doble podría afectar negativamente al rendimiento.

Cada máquina virtual confidencial de Azure tiene su propio TPM virtual, donde los clientes pueden sellar sus secretos o claves. Se recomienda que los clientes comprueben el estado de vTPM (mediante TPM.msc para máquinas virtuales Windows). Si el estado no está listo para su uso, se recomienda reiniciar las máquinas virtuales antes de sellar secretos o claves en vTPM.

No. Después de crear una máquina virtual confidencial, no se puede desactivar ni reactivar el cifrado de disco completo. En su lugar, cree una máquina virtual confidencial.

Los desarrolladores que buscan más "separación de tareas" para los servicios TCB del proveedor de servicios en la nube deben usar el tipo de seguridad "NonPersistedTPM".

• Esta experiencia solo está disponible como parte de la versión preliminar pública de Intel TDX. Las organizaciones que lo usan o proporcionan servicios con él tienen el control de TCB y de las responsabilidades que conlleva.
• Esta experiencia omite los servicios nativos de Azure, lo que le permite traer su propia solución de cifrado de disco, administración de claves y atestación.
• Cada máquina virtual sigue teniendo un vTPM, que se debe usar para recuperar evidencias de hardware, pero el estado de vTPM no se conserva a través de reinicios, lo que significa que esta solución es excelente para cargas de trabajo efímeras y organizaciones que quieren desacoplarse aún más desde el proveedor de servicios en la nube.

No. Por motivos de seguridad, se debe crear una máquina virtual confidencial como tal desde el principio.

Sí, se permite la conversión de una máquina virtual confidencial a otra máquina virtual confidencial en DCasv5/ECasv5 y DCesv5/ECesv5 en las regiones que comparten. Si usa una imagen de Windows, asegúrese de tener todas las actualizaciones más recientes. Si usa una imagen de Ubuntu Linux, asegúrese de usar la imagen confidencial de Ubuntu 22.04 LTS con la versión mínima del kernel 6.2.0-1011-azure.

Asegúrese de haber seleccionado una región disponible para las máquinas virtuales confidenciales. Asegúrese también de seleccionar Borrar todos los filtros en el selector de tamaño.

No. Las máquinas virtuales confidenciales no admiten Redes aceleradas. No se pueden habilitar Redes aceleradas para ninguna implementación de máquina virtual confidencial ni ninguna implementación de clúster de Azure Kubernetes Service que se ejecute en Computación confidencial.

Puede recibir este error No se pudo completar la operación porque se superó la cuota de Núcleos de familia DCasv5/ECasv5 estándar aprobada. Este error de plantilla de Resource Manager (plantilla de ARM) significa que se produjo un error en la implementación debido a la falta de núcleos de proceso de Azure. Las suscripciones de evaluación gratuita de Azure no tienen una cuota de núcleo lo suficientemente grande para máquinas virtuales confidenciales. cree una solicitud de soporte técnico para aumentar la cuota.

Las series ECasv5 y ECesv5 son tamaños de máquina virtual optimizados para memoria, que ofrecen una mayor proporción de memoria a CPU. Estos tamaños son especialmente adecuados para servidores de bases de datos relacionales, memorias caché de tamaños medio y grande, y análisis en memoria.

No. En este momento, estas máquinas virtuales solo están disponibles en determinadas regiones. Para obtener una lista actual de las regiones disponibles, vea Productos de máquinas virtuales por región.

Azure no tiene procedimientos operativos para conceder acceso a las máquinas virtuales confidenciales a sus empleados, incluso si un cliente lo autoriza. Como consecuencia, no hay varios escenarios de recuperación y soporte técnico disponibles para máquinas virtuales confidenciales.

No, las máquinas virtuales confidenciales no admiten actualmente la virtualización anidada, como la capacidad de ejecutar un hipervisor dentro de una máquina virtual.

La facturación de las máquinas virtuales confidenciales depende del uso y el almacenamiento, así como del tamaño y la región de la máquina virtual. Las máquinas virtuales confidenciales usan un disco de estado invitado de máquina virtual cifrada (VMGS) pequeño de varios megabytes. VMGS encapsula el estado de seguridad de la máquina virtual de componentes como el cargador de arranque vTPM y UEFI. Este disco puede dar lugar a un precio de almacenamiento mensual. Además, si decide habilitar el cifrado de disco completo opcional, los discos cifrados del sistema operativo incurrirán en costos mayores. Para obtener más información sobre los precios de almacenamiento, vea la guía de precios de discos administrados. Por último, para obtener algunas opciones de seguridad y privacidad elevadas, puede optar por crear recursos vinculados, como un Grupo de HSM administrado. Azure factura estos recursos independientemente de los costos de las máquinas virtuales confidenciales.

Rara vez algunas máquinas virtuales de la serie DCesv5/ECesv5 pueden experimentar una pequeña diferencia de tiempo de UTC. Pronto estará disponible una corrección a largo plazo. Mientras tanto, estas son las soluciones alternativas para las máquinas virtuales Windows y Ubuntu Linux:

sc config vmictimesync start=disabled
sc stop vmictimesync

Para las imágenes de Ubuntu Linux, ejecute el siguiente script:

#!/bin/bash

# Backup the original chrony.conf file
cp /etc/chrony/chrony.conf /etc/chrony/chrony.conf.bak

# check chronyd.service status
status=$(systemctl is-active chronyd.service)

# check chronyd.service status is "active" or not
if [ "$status" == "active" ]; then
  echo "chronyd.service is active."
else
  echo "chronyd.service is not active. Exiting script."
  exit 1
fi

# Comment out the line with 'refclock PHC /dev/ptp_hyperv'
sed -i '/refclock PHC \/dev\/ptp_hyperv/ s/^/#/' /etc/chrony/chrony.conf

# Uncomment the lines with 'pool ntp.ubuntu.com' and other pool entries
sed -i '/#pool ntp.ubuntu.com/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 0.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 1.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 2.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf

echo "Changes applied to /etc/chrony/chrony.conf. Backup created at /etc/chrony/chrony.conf.bak."

echo "Restart chronyd service"
systemctl restart chronyd.service


echo "Check chronyd status"
systemctl status chronyd.service