Red Hat y Arqit despliegan contenedores confidenciales con red post-cuántica para dar soberanía de datos al SaaS
El patrón mantiene el servicio en nube pública y añade atestación externa de los TEE y TLS híbrido con ML-KEM para que el cliente no tenga que llevarse nada a su CPD.
Red Hat y Arqit Quantum han publicado un patrón de despliegue que junta contenedores confidenciales, un proveedor de confianza externo y red híbrida post-cuántica para que un proveedor de SaaS pueda garantizar soberanía de datos sin sacar el servicio de la nube pública. Lo aplican a Encryption Intelligence (EI), la plataforma multitenant de Arqit para descubrimiento e inventario criptográfico automatizado.
El problema no es nuevo. Un ISV que aloja su servicio en nube pública recibe cada vez más exigencia de clientes que quieren garantías de que sus datos siguen bajo su control cuando se procesan fuera. La salida tradicional es desplegar on-premise, y eso le trae al proveedor mantenimiento extra, problemas de escalado, riesgo para su propiedad intelectual y bastante complejidad. La alternativa que plantean aquí es quedarse en la nube y compensar con controles criptográficos.
Dos entornos y tres clústeres
La arquitectura parte del patrón validado de Red Hat para contenedores confidenciales, sobre OpenShift y hardware con soporte de computación confidencial. Hay un entorno on-premise de Arqit, que actúa como raíz de confianza y reparte confianza al resto, y un entorno no confiable donde viven los contenedores confidenciales y los servicios asociados. Ahí dentro corren tres clústeres: uno de gestión, con la interfaz de administración y la vista de atestación de los contenedores en ejecución; otro con los servicios de trustee (key broker, proveedor de valores de referencia y atestación); y el entorno propiedad del cliente, donde este ejecuta sus propias cargas junto a un servicio de Arqit. Los tres van conectados entre sí.
El punto delicado es el trustee. En un despliegue normal de contenedores confidenciales hay un único servicio que atestigua, gestiona políticas, controla secretos y guarda los valores de referencia. Si ese trustee corre en infraestructura no confiable, tiene que ir a su vez dentro de un TEE, y ahí aparece una dependencia circular: no puede atestiguarse a sí mismo. La solución es partirlo en dos. Un trustee externo, en el entorno on-premise de Arqit, fuera de la computación confidencial, sirve de ancla y distribuye confianza al trustee interno que corre en la nube. Así se puede alojar casi toda la gestión en la nube sin renunciar a una fuente de confianza independiente.
Para que los datos no se descifren en el borde del contenedor, tiran de TLS híbrido: ECDH clásico más intercambio de claves ML-KEM post-cuántico. La terminación de la capa de transporte ocurre dentro del límite del TEE, de modo que el entorno anfitrión nunca ve texto plano. Eso cubre el tráfico entre contenedores y clústeres, y también el que va del on-premise a la nube.
El patrón es interesante porque ataca un problema real de operación y no solo de cifrado: qué haces cuando el servicio que gestiona la confianza vive en el mismo sitio que no te fías. Lo que no trae la nota es nada medido. No hay cifras de latencia, ni comparación con un despliegue equivalente sin TEE, ni coste del hardware compatible. Y todo sale de los dos fabricantes implicados. Queda por ver si esto se sostiene cuando el cliente quiere auditar el trustee externo o cambiar de proveedor de nube, que es justo donde estos diseños suelen apretar.
