Confidential computing en data center: qué cambia cuando tus datos están cifrados en uso

Cifrado en reposo y en tránsito es estándar en data centers profesionales desde hace más de una década. Lo que cambió en 2022 a 2026 es el cifrado en uso: datos cifrados dentro de un enclave de hardware en la CPU, sin que el SO, hipervisor ni operador del data center pueda leerlos.

Este artículo desgrana qué cambia al implementar confidential computing, qué ataques se vuelven imposibles, qué certificaciones aplican (CCC, NIST SP 800-193, LFPDPPP en México), y cuándo SÍ conviene un deployment en Latam.

Qué es confidential computing (en 60 segundos)

Confidential computing es un modelo de seguridad donde el cálculo ocurre dentro de un TEE (Trusted Execution Environment) del procesador, no en la memoria accesible al SO. Los TEEs actuales dominantes: AMD SEV-SNP (Secure Encrypted Virtualization, presente en EPYC 3ª generación en adelante) e Intel TDX (Trust Domain Extensions, presente en Xeon Scalable de 4ª generación en adelante). Ambos crean un enclave cifrado dentro de la CPU, donde el código corre con la garantía de que ni el hipervisor, ni el administrador del servidor, ni el operador del data center puede leer la memoria del enclave.

Diferencia operativa con cifrado tradicional: en reposo protege datos en disco; en tránsito protege datos en red. En uso protege datos mientras la CPU ejecuta cálculos sobre ellos. Esa diferencia es lo que vuelve confidencial a confidential computing.

Qué ataques se vuelven imposibles y cuáles siguen posibles

Con confidential computing correctamente implementado, se vuelven inviables: extracción de secretos vía dump de RAM física; inspección del estado de CPU por acceso admin al hipervisor; instalación de implantes en el SO invitado; robo de claves API en uso; ataques por firmware del SO comprometido (BootGuard, Intel TXT, AMD Secure Boot).

Siguen posibles: compromiso de hardware físico (fault injection o side-channel attack sobre la CPU); compromiso del firmware de la CPU (requiere colaboración con el fabricante, muy raro); ingeniería social sobre el operador; ataques laterales microarquitectónicos como Spectre y Meltdown (mitigados parcialmente, no erradicados); compromiso de la cadena de suministro del fabricante. Confidential computing cierra ataques de software y administración, no de hardware físico.

Cambios operativos para un data center en México

Un deployment de confidential computing implica cuatro cambios operativos casi no documentados:

1. El hipervisor del cliente debe ser compatible con SEV-SNP o TDX. KVM, VMware vSphere 8 (licencia correcta), Microsoft Hyper-V 2022 con Windows Server 2022 Datacenter, y OpenShift con operators específicos soportan confidential VMs. La BIOS del servidor debe habilitar SEV-SNP o TDX explícitamente; Dell PowerEdge, HPE ProLiant y Supermicro nuevos lo traen por defecto.
2. Las CPUs deben ser de la generación correcta. Para AMD SEV-SNP necesitas EPYC 7003 (Milan) o posterior; 7002 (Rome) solo soporta SEV sin SNP. Para Intel TDX necesitas Xeon Scalable de 4ª generación (Sapphire Rapids) o posterior. Costo de upgrade si tu flota es anterior: entre 1.5 y 2.5 veces el costo de servidor nuevo. En México, operadores principales (KIO, Triara, Ascenty, ODATA, Axtel) ya tienen servidores compatibles en Tier III y Tier IV.
3. Infraestructura de attestation y sellado criptográfico. Cada TEE genera un attestation report firmado por el fabricante (AMD o Intel) que prueba que el enclave se creó con una versión específica de firmware y microcódigo. Esos reports deben ser verificados por la aplicación cliente antes de cargar secretos en el enclave. Librería más usada: Constellation (OpenSSL-compatible, AMD). Implementar y mantener este pipeline es trabajo de ingeniería de 4 a 8 semanas para un equipo experimentado.
4. La certificación del Confidential Computing Consortium (CCC) es opcional pero diferenciadora. La CCC publica especificación técnica y un programa de attestation review que demuestra que un operador de nube cumple con requisitos específicos. Para operadores en México, certificarse con CCC frente a clientes enterprise europeos o de EE UU es palanca comercial real, aunque toma entre 6 y 12 meses y costo entre 50,000 y 180,000 USD.

Cuándo SÍ conviene un deployment con confidential computing

Cuatro casos donde el ROI se justifica:

1. Cargas donde el cliente exige que el operador no pueda acceder a datos en uso (financieros, salud HIPAA, secretos industriales). Certificación CCC o attestation independiente cubre el requisito.
2. Regulación aplicable a datos en uso (LFPDPPP en México para datos personales sensibles, RGPD en Europa, HIPAA en EE UU; autoridad en México: INAI). Cifrado en reposo no cumple la norma; cifrado en uso sí.
3. Multi-tenancy en hyperscale donde múltiples clientes comparten servidor físico: confidential computing garantiza aislamiento real entre ellos.
4. Entrenamiento federado de IA donde varios clientes aportan gradientes sin revelar datasets propios: confidential computing habilita cómputo sobre datos cifrados.

Cuándo NO conviene confidential computing todavía

Tres casos donde esperar:

1. Cargas legacy sin re-arquitectura. Confidential computing requiere attestation y secret management que pocas legacy tienen. Migrar un monolito tradicional a confidential VMs es entre 2 y 6 meses de re-trabajo.
2. Workloads GPU donde los TEEs aún maduran. NVIDIA H100 y A100 soportan confidential computing parcialmente (attestation report), pero con overhead de performance entre 5% y 15% y compatibilidad limitada con frameworks de ML. Para entrenamiento de modelos grandes es útil pero no resuelve el caso completo; espera a Blackwell y siguientes generaciones.
3. Data centers donde el operador es de confianza del cliente. Si tu SLA y contrato confirman que solo personal autorizado accede al hipervisor con controles robustos, confidential computing agrega una capa pero no es mandatoria. Evalúa costo del cambio contra riesgo residual; en Latam muchos clientes enterprise están cómodos con sus operadores.

El dato regulatorio en México

La LFPDPPP y su reglamento regulan datos personales sensibles: salud, biométricos, financieros, patrimoniales, de menores. El INAI es la autoridad regulatoria. Para datos en reposo el estándar es cifrado en disco; en tránsito, cifrado en red. Para datos en uso la LFPDPPP no exige confidential computing explícitamente pero sí exige medidas apropiadas según el estado de la técnica. El estándar internacional (citado en resoluciones del INAI) reconoce cifrado en uso con TEE como medida razonable para multi-tenancy. Resumen: no mandatorio por ley en México hoy, pero es la respuesta técnica más sólida para clientes que exijan protección razonable de datos en uso.

Fuentes

1. Confidential Computing Consortium (CCC): especificación técnica y membresía para operadores — https://confidentialcomputing.io/
2. NIST SP 800-193: Platform Resiliency Guidelines (referencia para attestation y firmware) — https://csrc.nist.gov/publications/detail/sp/800-193/final
3. Linux Foundation: documentación de proyectos de confidential computing — https://www.linuxfoundation.org/
4. AMD SEV-SNP: documentación oficial para desarrolladores (attestation y APIs) — https://www.amd.com/en/developer/sev.html
5. Microsoft Azure Confidential Computing: documentación pública del modelo de deployment — https://learn.microsoft.com/en-us/azure/confidential-computing/overview