El cifrado en reposo y en tránsito es hoy una práctica estándar, pero los datos que residen en la RAM han estado tradicionalmente en texto plano: visibles para el hipervisor, para el operador de la nube e incluso para un administrador malintencionado. La computación confidencial cierra esa tercera brecha mediante enclaves de hardware (Intel TDX, AMD SEV-SNP) que cifran la memoria y aíslan el estado de la CPU, de modo que ningún administrador del host puede leer ni manipular una carga de trabajo mientras se ejecuta. Para las organizaciones del Reino Unido que aplican IA a datos del NHS, la FCA o el MOD, ya no es una curiosidad de laboratorio: está disponible ahora en Azure, AWS y Google Cloud, con unos costes de rendimiento medibles y un beneficio real en materia de cumplimiento normativo.
View the data behind this chart
| Cargas intensivas en CPU | Cargas intensivas en memoria | |
|---|---|---|
| Límite inferior | %2 | %5 |
| Límite superior | %5 | %10 |
El tercer estado de los datos que faltaba
Los equipos de seguridad hablan de dos estados de los datos casi por reflejo: en reposo (cifrado de disco) y en tránsito (TLS). El tercer estado —los datos en uso, es decir, todo lo que permanece descifrado en la memoria del sistema mientras la CPU lo procesa— siguió estructuralmente desprotegido hasta que los fabricantes de hardware lanzaron silicio capaz de procesar datos cifrados sin exponer nunca texto plano al sistema operativo del host. La computación confidencial es esa pieza que faltaba en el ciclo de vida del cifrado.
Esto importa más en 2026 que hace unos años porque han cambiado las cargas de trabajo que se quieren proteger. Ejecutar inferencia o entrenamiento de IA sobre datos sensibles —historiales de pacientes, historiales de transacciones, inteligencia de defensa— hace que la exposición de texto plano en un host de nube compartido resulte inaceptable para un número creciente de organizaciones del Reino Unido, con independencia de lo sólida que sea la seguridad perimetral que rodea a ese host.
Cómo funcionan realmente los entornos de ejecución de confianza
Un entorno de ejecución de confianza (Trusted Execution Environment, TEE) es una frontera impuesta por hardware. Las VM confidenciales basadas en Intel TDX y AMD SEV-SNP aíslan criptográficamente la memoria y el estado de la CPU, de forma que ningún administrador del host ni ningún proceso del hipervisor —incluidos los propios operadores del proveedor de nube— puede verlos ni modificarlos. En la práctica, el modelo de confianza se invierte: en lugar de confiar en el operador de la nube, se confía en el silicio.
El mecanismo de prueba es la atestación criptográfica. Antes de dar por fiable una carga de trabajo, la plataforma firma un informe que contiene la identidad de la plataforma, las mediciones del firmware y un nonce aportado por el verificador, lo que permite a una parte remota confirmar que la carga ejecuta código auténtico y sin modificar dentro de un TEE real, y no en un entorno suplantado o manipulado.
- •Cifrado de memoria: las claves únicas por VM impiden que el host lea la RAM del invitado
- •Aislamiento del estado de la CPU: los registros y el estado de ejecución quedan protegidos frente al hipervisor
- •Informes de atestación: prueba firmada de la identidad de la plataforma y de la integridad del código
- •TPM virtuales protegidos por hardware: certifican el estado de la VM y admiten una gestión de claves reforzada, como BitLocker en las VM confidenciales de Azure
Intel TDX frente a AMD SEV-SNP: el detalle técnico
Intel TDX utiliza Multi-Key Total Memory Encryption (MKTME) para asignar a cada Trust Domain su propia clave AES-128-XTS única, lo que aísla la memoria de ese dominio tanto del hipervisor como del sistema operativo del host. Como TDX no dispone de un procesador de seguridad dedicado, la atestación se hace en dos pasos: el módulo TDX genera un informe mediante la instrucción SEAMREPORT y un quoting enclave —que es a su vez un enclave SGX— lo firma para convertirlo en un quote verificable a distancia. Si estás definiendo plataformas para este uso, conviene entender el silicio subyacente; los procesadores Intel Xeon 6 son la generación actual con soporte para TDX (también llegó a los Xeon Scalable de 5.ª generación).
AMD SEV-SNP sigue una ruta arquitectónica distinta y añade Secure Nested Paging para frenar los ataques basados en el hipervisor contra las tablas de páginas del invitado. Cifra la memoria en tiempo de ejecución, reestructura las tablas de páginas para que el host no pueda leerlas ni manipularlas e introduce la atestación en el lanzamiento para verificar la integridad de la memoria del invitado desde el momento en que arranca la VM. En cuanto al hardware, este es el conjunto de funciones de computación confidencial integrado en los procesadores AMD EPYC Turin.
En la práctica, no son opciones intercambiables: responden a perfiles de riesgo diferentes. AMD SEV-SNP suele preferirse para cargas intensivas en CPU en servicios financieros y sanidad por su menor sobrecarga de rendimiento, mientras que Intel TDX tiende a imponerse en administración pública, defensa y cargas de IA de alta seguridad, donde su modelo de atestación se considera la garantía más sólida.
Sobrecarga de rendimiento en el mundo real
La computación confidencial no sale gratis, y la sobrecarga varía considerablemente según el perfil de la carga de trabajo; es el detalle que la mayoría de las explicaciones omiten por completo. En el caso concreto de AMD SEV-SNP, las cargas intensivas en CPU registran aproximadamente un 2–5 % de sobrecarga, mientras que las aplicaciones intensivas en memoria funcionan un 5–10 % más lentas, lo que refleja el coste adicional de cifrar y comprobar la memoria en cada acceso.
Un análisis empírico independiente de AMD SEV-SNP halló una sobrecarga de acceso a memoria de hasta el 7 % solo por el cifrado, con aumentos de la latencia de memoria de hasta 5 veces en algunos patrones de acceso. Más llamativo aún, los escenarios del peor caso con un exceso de cambios de contexto y de operaciones de copia de memoria mostraron picos de sobrecarga de hasta el 400 %, una cifra que se aplica específicamente a ese patrón patológico, no a las cargas de trabajo típicas en régimen estable.
La conclusión práctica: no hay que dar por hecho un porcentaje de sobrecarga fijo. Las cargas con mucho peso de bases de datos o de virtualización y con cambios de contexto frecuentes deben someterse a pruebas de rendimiento antes de la migración, porque se sitúan en el extremo de este rango, mientras que los trabajos sencillos de analítica o inferencia limitados por la CPU quedan mucho más cerca de porcentajes de un solo dígito.
Implicaciones de coste para los compradores del Reino Unido
Ningún gran proveedor publica una lista de precios específica en GBP para las instancias confidenciales, pero las estimaciones del sector sitúan las VM confidenciales en torno a un 15–25 % más caras que las instancias estándar equivalentes en la nube pública. Ese sobrecoste debe sopesarse frente a lo que se obtiene a cambio: una respuesta técnica y auditable a la pregunta «¿puede vuestro proveedor leer nuestros datos?», que es cada vez más la que realmente plantean reguladores y clientes.
En lo que respecta específicamente a la confianza transfronteriza, los compradores del Reino Unido deberían presionar a los proveedores en lo relativo a la ubicación de la atestación: elegir un servicio de atestación desplegado en la región que decidan (Azure Attestation, por ejemplo, funciona con instancias regionales) y, si hace falta, una conectividad privada con los endpoints de atestación (por ejemplo, mediante AWS PrivateLink) en lugar de aceptar un endpoint de atestación global predeterminado, para no introducir una dependencia de confianza innecesaria en el extranjero en un despliegue que, por lo demás, es soberano.
View the data behind this chart
| Layer | Detail |
|---|---|
| Datos en reposo | Cifrados en disco y en soportes de almacenamiento |
| Datos en tránsito | Cifrados mediante TLS a través de las redes |
| Datos en uso: la brecha cerrada | Texto plano en RAM, ahora protegido por los TEE |
Cumplimiento en el Reino Unido: RGPD y regulación sectorial
La computación confidencial ofrece a las organizaciones del Reino Unido algo que el artículo 32 del RGPD siempre ha exigido pero que rara vez se ha conseguido: evidencia técnica y verificable de la seguridad del tratamiento, en lugar de una promesa contractual. Los informes de atestación proporcionan a los auditores una prueba criptográfica de que una carga de trabajo se ejecutó en un entorno aislado y sin modificar, lo que constituye un elemento probatorio de cumplimiento sustancialmente más sólido que los términos y condiciones estándar de un proveedor de nube.
Donde más se nota es en los sectores regulados. Los organismos del NHS que ejecutan IA sobre datos sanitarios, las entidades financieras reguladas por la FCA que procesan historiales de transacciones y los trabajos de defensa vinculados al MOD comparten el mismo problema de fondo: necesitan ejecutar cómputo sobre datos demasiado sensibles para exponerlos en texto plano a un host de terceros. Tanto las obligaciones derivadas de las NIS Regulations como, para las empresas británicas que suministran sistemas de IA en la UE, el cumplimiento de la AI Act europea se benefician de que la atestación basada en TEE reduzca la carga de auditoría de las cargas de trabajo reguladas. Si la protección de los datos en uso forma parte de una revisión de seguridad más amplia, conviene combinarla con la guía de nuestras soluciones de ciberseguridad, que cubre el resto de la pila.
Implementación práctica: pasos y escollos
La migración de una carga de trabajo sensible suele seguir un patrón similar: identificar la carga y el requisito regulatorio que la motiva, elegir TDX o SEV-SNP en función de si importa más la solidez de la atestación o una menor sobrecarga, aprovisionar la instancia de VM confidencial en la nube elegida e integrar la verificación de la atestación en el pipeline de despliegue, en lugar de tratarla como una comprobación puntual. En Azure, esto puede combinarse con un TPM virtual protegido por hardware para certificar el estado de la VM y admitir una gestión de claves reforzada, como BitLocker.
Por debajo de la abstracción de la VM, TDX y SEV-SNP son primitivas de CPU para la virtualización confidencial asistida por hardware: imponen una separación a nivel de hardware entre el software del sistema y la propia VM confidencial, lo que significa que el kernel invitado debe compilarse o configurarse para ejecutarse dentro de ese modo aislado, en lugar de tratarse como una imagen que se puede usar tal cual. AMD SEV-SNP, en concreto, reestructura las tablas de páginas del invitado para excluir el acceso del host y realiza en el arranque la atestación de lanzamiento de la integridad de la memoria del invitado, de modo que la cadena de arranque medido —firmware más el estado inicial del kernel— pasa a formar parte de lo que realmente se verifica, y no es algo añadido a posteriori. La integración del TPM virtual que se usa para la gestión de claves tipo BitLocker en las VM confidenciales de Azure es en sí misma un punto de contacto a nivel del sistema operativo invitado, no algo que ocurra de forma transparente por debajo del sistema operativo.
Los escollos son operativos más que conceptuales. La atestación añade un paso de verificación que debe automatizarse y supervisarse, no ejecutarse una sola vez en el despliegue. La depuración es realmente más difícil: las herramientas a nivel de host que antes inspeccionaban la memoria del invitado para resolver problemas sencillamente no pueden ver dentro de un enclave cifrado, lo que cambia la forma de abordar la respuesta a incidentes y el diagnóstico de rendimiento. Además, los agentes de seguridad y monitorización existentes suelen necesitar versiones compatibles con TEE, ya que las herramientas estándar basadas en el host no tienen visibilidad sobre aquello que se supone que deben proteger. Para las organizaciones que comparan las VM confidenciales en la nube con una implantación on-premise o híbrida con CPU compatibles con TEE, conviene analizar las opciones al configurar un servidor.
- •Coste: las VM confidenciales conllevan un sobrecoste del 15–25 % frente a las instancias estándar de nube pública; disponer en propiedad, on-premise, de CPU compatibles con TEE (Xeon 6, EPYC Turin) evita ese sobrecoste recurrente en cargas reguladas en régimen estable, a cambio de una inversión inicial en hardware
- •Control de la atestación: los despliegues on-premise mantienen internamente toda la cadena de atestación y la línea base de mediciones del firmware; la nube pública implica confiar en el servicio de atestación del proveedor, salvo que se exija un servicio de atestación en la región que se elija, accesible mediante conectividad privada como AWS PrivateLink
- •Carga de auditoría: ambos modelos generan los mismos informes de atestación criptográfica como evidencia para el artículo 32 del RGPD, pero la opción on-premise elimina por completo cualquier cuestión de residencia de datos transfronteriza, algo relevante para cargas vinculadas al MOD o al NHS
- •Adecuación a la carga: asignar Intel TDX (atestación más sólida, preferido en administración pública, defensa e IA de alta seguridad) o AMD SEV-SNP (menor sobrecarga, preferido en finanzas y sanidad) según la carga de trabajo, con independencia de que se aloje en la nube pública o on-premise
IA confidencial y el futuro más allá de 2026
El motor más claro del impulso que vive la computación confidencial a mediados de 2026 es la IA aplicada a datos sensibles. Ejecutar cargas de inferencia o entrenamiento sobre conjuntos de datos regulados sin exponer texto plano al proveedor de nube se está convirtiendo en un requisito básico más que en un simple extra, y es el caso de uso que más está acelerando la adopción de TDX y SEV-SNP en los despliegues en la nube del Reino Unido.
Conviene ser realista sobre su alcance: la computación confidencial es muy eficaz frente a la preocupación de privacidad más común en la nube —que el propio proveedor acceda a los datos de los clientes—, pero deja riesgos residuales que siguen requiriendo controles complementarios, como la seguridad de red, la gestión de accesos y la protección de endpoints. Cierra una brecha concreta que hasta ahora estaba abierta en el ciclo de vida del cifrado; no sustituye al resto de un programa de seguridad.
Fuentes
Todas las cifras de este artículo proceden de las fuentes siguientes.
- •Stealth Cloud — análisis en profundidad de la computación confidencial y alcance del modelo de amenazas
- •Onidel — sobrecarga de rendimiento de AMD SEV-SNP frente a Intel TDX y adecuación a cada carga de trabajo
- •Red Hat — quoting enclave de Intel TDX y arquitectura de atestación
- •Microsoft Azure Docs — preguntas frecuentes sobre VM confidenciales y comparativa de funciones de TDX/SEV-SNP
- •Ian Klatzco — mecánica de la atestación criptográfica
- •Ubuntu — explicación del modelo de confianza de la computación confidencial
- •ServerMall — aislamiento de inquilinos con TEE y casos de uso con cargas reguladas
- •Sekyourity Blog — detalle de las primitivas de hardware de AMD SEV-SNP e Intel TDX
- •1C Confidential VMs (YouTube) — cifras empíricas de sobrecarga de memoria y de cambio de contexto