En los últimos años hemos aprendido a cifrarlo “todo”: discos, bases de datos, comunicaciones… pero había un agujero en la seguridad: el momento en el que los datos se procesan en memoria. Ahí es donde entra la computación confidencial y una nueva hornada de chips que la hacen posible.
1. ¿Qué es exactamente la computación confidencial?
La definición “oficial” que utilizan grandes proveedores de nube y el Confidential Computing Consortium es más o menos esta:
Computación confidencial = proteger los datos “en uso” mediante un entorno de ejecución de confianza (TEE) basado en hardware
Básicamente, hasta ahora se ha estado protegiendo los datos en reposo y los datos en tránsito. Siendo los datos en reposo los correspondientes al cifrado de discos, bases de datos, backups, etc. y los datos en tránsito los que enviamos mediante TLS/HTTPS, VPN, etc.
Ahora se añade una tercera pata, los datos en uso. Los datos en uso que se están cargando en memoria durante un proceso y sobre los que se ejecuta una lógica.
La idea clave: incluso si el sistema operativo, el hipervisor o el administrador de la nube quedan comprometidos, no pueden ver lo que está pasando dentro de ese entorno protegido (el TEE).
2. ¿Cuales son los conceptos básicos que hay que manejar?
Los conceptos que manejamos en este tipo de computación son el estado del dato, el TTE y la atestación. Veámoslos:
2.1. El estados del dato
El datos puede estar en varios estados: en reposo (almacenado en disco, S3, base de datos), en tránsito (viajando por la red) o en uso (cargado en memoria y procesándose por CPU o GPU). Bien, pues la computación confidencial se enfoca en este último punto, que es el más difícil de proteger con técnicas clásicas.
2.2 El TEE (Trusted Execution Environment)
Un TEE es una “zona blindada” dentro del procesador (CPU o GPU). Esta zona se caracteriza por que:
- Tiene memoria cifrada y aislada del resto del sistema.
- Solo puede ejecutarse en él código que ha sido medido y verificado.
- El hardware ofrece mecanismos criptográficos que impiden que el SO, el hipervisor o procesos vecinos lean o modifiquen lo que pasa dentro.
En la práctica, el TEE puede materializarse como:
- Enclaves de proceso (modelo Intel SGX).
- Máquinas virtuales completas aisladas por hardware (Intel TDX, AMD SEV-SNP).
- “Reinos” o Realms (Arm CCA) que aíslan entornos completos de ejecución
2.3 La Atestación remota
La atestación es el mecanismo que cierra el círculo. Es básicamente un informe que permite validar el proceso. Veamos un proceso ejemplo:
- El TEE arranca y mide criptográficamente el código y la configuración que se van a ejecutar.
- Genera un informe firmado por el hardware donde constan esas mediciones.
- El cliente (por ejemplo, tu backend on-prem o tu HSM) verifica que el informe viene de hardware legítimo (CPU/GPU de un fabricante concreto) y el código y la configuración coinciden con lo que tú esperas.
- Solo entonces comparte claves o datos sensibles.
Ejemplos: AMD SEV-SNP genera informes de atestación firmados que permiten validar que una VM corre en hardware AMD autorizado y con un estado de arranque concreto
3. La nueva generación de chips para computación confidencial
La computación confidencial deja de ser teoría cuando aparece silicio específico que la soporta. Esto no va solo de software; es un stack completo desde microarquitectura hasta la nube. Aquí encontramos a:
3.1 Intel con SGX y TDX
- Intel SGX: introdujo el concepto de enclaves dentro de procesos concretos. Muy granular, pero difícil de programar y con limitaciones de memoria.
- Intel TDX (Trust Domain Extensions). Crea Trust Domains (TDs) que son VMs aisladas por hardware incluso del hipervisor, permiten usar cifrado de memoria a nivel de hardware, tablas de memoria extendidas seguras y mecanismos de atestación remota. Se está integrando masivamente en nubes públicas: por ejemplo, Google Cloud y otros proveedores ya ofrecen VMs confidenciales basadas en TDX, ampliando regiones y tipos de máquina de forma acelerada.
Traducción práctica: puedes levantar una VM casi “normal”, pero que ni el propio proveedor Cloud pueda inspeccionar en claro.
3.2 AMD con el modelo de VMs cifradas: SEV, SEV-ES y SEV-SNP
AMD ha apostado fuerte por el modelo de VMs cifradas:
- SEV (Secure Encrypted Virtualization): cifra la memoria de cada VM con una clave distinta.
- SEV-ES: extiende la protección también a registros de CPU.
- SEV-SNP (Secure Nested Paging): añade protección de integridad y contra ataques de manipulación de tablas de memoria. Ene ste caso la VM tiene memoria cifrada y con integridad garantizada, el hipervisor no puede leer ni alterar su contenido y ofrece atestación remota para verificar el estado de la VM
3.3 Arm con CCA y los “Realms”
En el mundo Arm (clave para móvil, edge y muchos data centers modernos) aparece Arm CCA (Confidential Compute Architecture):
- Introduce el concepto de Realms: entornos aislados que coexisten con el mundo normal (SO) y el mundo seguro clásico, pero separados de ambos
- Está pensado para nubes Arm, 5G, edge y dispositivos donde el proveedor o el operador no deberían ver los datos que se procesan.
Esto abre la puerta a computación confidencial en el edge: desde estaciones base 5G a gateways industriales.
3.4 NVIDIA y las GPUs confidenciales
La gran novedad de los últimos años: la computación confidencial ha llegado a las GPUs y a la IA generativa.
- La GPU NVIDIA H100 es la primera GPU que incorpora soporte nativo de computación confidencial. Incluye una root of trust hardware, arranque medido, memoria protegida y generación de informes de atestación. Además permite ejecutar cargas de IA aceleradas dentro de un entorno cifrado, protegiendo tanto los datos como los pesos del modelo.
- Azure Confidential GPUs combina CPUs AMD EPYC de 4ª generación con SEV-SNP, y GPUs NVIDIA H100 en modo confidencial, creando VMs con TEE que abarca CPU y GPU a la vez, orientadas a IA confidencial.
Estudios recientes muestran que, en H100, el overhead no viene tanto del cómputo dentro de la GPU, sino de los cuellos de botella en las transferencias de datos CPU-GPU, lo que obliga a pensar en arquitecturas de IA más “data-locales” cuando se activa el modo confidencial.
4. El cambio en la Nube pública: el “sistema operativo” de la computación confidencial
Dentro de a Nube, los grandes proveedores como Microsoft Azure, Google Cloud, AWS y otros ya tienen ya catálogos de:
- Confidential VMs (CPU)
- Confidential Containers
- Confidential GPUs / Confidential AI
Ejemplo: Azure documenta explícitamente su plataforma de computación confidencial como la infraestructura para aislar datos mientras se procesan, con soporte para VMs, contenedores y GPUs confidenciales
En la práctica, esto significa que no tienes por qué comprar hardware: puedes consumir computación confidencial como servicio.
5. Y ¿cuales son los objetivos estratégicos de la computación confidencial?
Más allá de la tecnología, la computación confidencial pretende:
- Reducir drásticamente la superficie de confianza. Ya no es necesario confiar al 100 % en el proveedor cloud, el administrador del sistema o el hipervisor. El “contrato de confianza” se desplaza al chip y a la cadena de atestación)
- Cumplir normativas de datos sensibles. Especialmente en sectores como banca, salud, administración pública, defensa. Facilita justificar ante supervisores que ni siquiera el operador de la infraestructura puede acceder a los datos en claro.
- Permitir nuevas formas de colaboración entre organizaciones. Varios actores pueden subir sus datos cifrados a un entorno compartido, ejecutar cómputo y obtener resultados sin revelarse mutuamente las entradas.
- Proteger modelos de IA como activos estratégicos. Modelos propios (LLMs, scoring, detección de fraude…) pueden ejecutarse en la nube sin riesgo razonable de ser extraídos en claro por el proveedor o por insiders.
6. Algunos casos de uso donde tiene más sentido
Entre los casos de uso, los más proclives al uso de este tipo de computación son:
6.1 Banca y seguros
- En la analítica avanzada sobre datos de clientes, historiales de crédito, scoring de riesgo.
- En la externalización a la nube de procesos que antes requerían infraestructura propia por razones de confidencialidad.
6.2 Salud y farmacéuticas
- Para el entrenamiento de modelos de IA sobre historias clínicas, imágenes médicas o datos genómicos sin exponer datos identificables.
- Para mejorar la colaboración entre hospitales o entre países con fuertes restricciones regulatorias.
6.3 Sector público y defensa
- Para permitir el procesamiento de datos tributarios, registros de empleo, historial educativo… sin exponer información sensible a proveedores tecnológicos.
- En el uso de nubes públicas para cargas clasificadas de forma controlada.
6.4 IA generativa y LLMs
- Para el Fine-tuning de modelos sobre datos internos (documentación, correos, bases de conocimiento) en nubes públicas, asegurando que los datos de entrenamiento se cargan en un TEE y los pesos ajustados se almacenan y sirven desde entornos confidenciales.
6.5 SaaS multi-cliente
- Permite ofrecer garantías fuertes a clientes enterprise (“ni siquiera nosotros podemos ver tus datos”).
- Ayuda a diferenciar tu propuesta de valor en mercados saturados.
7. Cómo encaja en tu arquitectura actual
Piensa la computación confidencial como una capa adicional, no como un reemplazo. Se añade en los puntos donde los datos pasan a memoria.
8. Retos y malentendidos frecuentes
“Si uso computación confidencial, ya estoy seguro”.
No: sigues necesitando buenas prácticas de desarrollo seguro, gestión de claves, segmentación de red, etc.
Complejidad de la atestación
- Entender y gestionar informes de atestación, raíces de confianza, certificados… tiene curva de aprendizaje.
- Cada fabricante (Intel, AMD, NVIDIA, Arm) tiene matices en su modelo.
Overhead de rendimiento
- En CPUs modernas, el impacto suele ser razonable (del orden de un solo dígito en muchos casos), pero hay cargas muy intensivas en I/O o en contexto que sufren más.
- En GPUs, el cuello de botella principal hoy está en el movimiento de datos en modo confidencial.
Lock-in de proveedor
- La forma de crear, gestionar y atestar TEEs varía entre clouds y fabricantes.
- Estándares como los impulsados por el Confidential Computing Consortium intentan homogeneizar, pero aún hay diferencias.
Gestión del ciclo de vida
- Rotación de claves, actualización de firmware seguro, revocación de equipos comprometidos… todo esto requiere procesos maduros de seguridad.
9. Conclusiones
La computación confidencial no es un “capricho criptográfico”, sino la respuesta a una realidad incómoda: hemos llevado los datos más sensibles y los modelos más valiosos a infraestructuras que no controlamos.
La combinación de:
- Nuevos chips (Intel TDX, AMD SEV-SNP, Arm CCA, NVIDIA H100 y sucesores),
- Plataformas cloud que los exponen como servicio, y
- Patrones de arquitectura y atestación bien diseñados,
permite dar un salto de nivel: pasar de “confío en mi proveedor” a “confío en la prueba criptográfica de que mi código se ejecuta donde y como yo he definido”.
Para muchas organizaciones, este salto será la diferencia entre no poder mover ciertas cargas a la nube y poder hacerlo con garantías razonables —especialmente en IA.