PQC para entornos en la nube: Responsabilidad compartida entre AWS, Azure y Google Cloud.

Respuesta rápida: La responsabilidad compartida en la nube para la criptografía postcuántica se divide claramente según una línea conocida, pero los detalles varían considerablemente según el proveedor y el servicio. AWS ha publicado la descripción operativa más clara: AWS KMS, ACM y Secrets Manager ya admiten el acuerdo de clave híbrida ML-KEM en puntos finales que no cumplen con FIPS, el cifrado simétrico en reposo (como el cifrado predeterminado de AWS KMS) ya es resistente a la computación cuántica, y la actualización de los recursos propiedad del cliente, como los balanceadores de carga, a una política TLS habilitada para PQ es explícitamente responsabilidad del cliente bajo el modelo de responsabilidad compartida de AWS. Azure y Google Cloud avanzan cada uno a su propio ritmo y no se encuentran uniformemente en el mismo punto de preparación en todos sus servicios. La tarea práctica para cualquier cliente multi-nube es auditar a cada proveedor por separado, servicio por servicio, en lugar de hacer una sola pregunta de sí o no sobre si la nube admite PQC, una pregunta que ningún proveedor puede responder honestamente con una sola palabra.

Los proveedores de servicios en la nube están migrando rápidamente, y es tentador suponer que la migración cubre automáticamente todas tus cargas de trabajo. Sin embargo, no es así en todos los casos. Esta guía detalla qué migra cada proveedor principal en tu nombre, qué sigue siendo tu responsabilidad y cómo auditar las deficiencias con precisión, en lugar de basarte en suposiciones.

Puntos Clave

• AWS KMS, ACM y Secrets Manager ya admiten el acuerdo de clave post-cuántica híbrida ML-KEM en puntos finales que no cumplen con la norma FIPS en todas las regiones de AWS en la partición estándar.
• La actualización de los recursos de red propiedad del cliente, como los balanceadores de carga, a una política TLS habilitada para PQ es responsabilidad explícita del cliente dentro del modelo de responsabilidad compartida de AWS, no algo que AWS haga automáticamente.
• El cifrado simétrico en reposo, incluido el cifrado de clave predeterminado de AWS KMS, ya se considera resistente a la computación cuántica y no requiere migración por sí solo.
• La preparación de los proveedores no es uniforme en todos los servicios dentro de la misma nube, y mucho menos entre los distintos proveedores; una pregunta general como "¿es compatible con PQC?" no revela las deficiencias específicas de cada servicio que son importantes durante una auditoría.
• Una auditoría útil de preparación de PQC entre nubes prueba la negociación real y el comportamiento de la API, el intercambio de claves híbridas, la creación de claves de firma KMS y el límite de validación de HSM, en lugar de basarse en afirmaciones de marketing sobre soporte general.

AWS: Qué se migró vs. Cuál es tu responsabilidad

AWS ha publicado la guía de migración de PQC más específica desde el punto de vista operativo de los principales proveedores. A la fecha de publicación de esta guía, los puntos de conexión de AWS KMS, AWS Certificate Manager y AWS Secrets Manager admiten ML-KEM para el acuerdo de clave post-cuántica híbrida en puntos de conexión que no cumplen con FIPS en todas las regiones de AWS en la partición estándar de AWS, una capacidad que AWS ofrece de forma transparente, sin que el cliente tenga que realizar ninguna acción para beneficiarse de ella en esos puntos de conexión específicos. Los algoritmos simétricos utilizados para el cifrado en reposo, incluido el cifrado de clave estándar de AWS KMS, ya se consideran resistentes a la computación cuántica y no necesitan migración por sí mismos.

La responsabilidad del cliente queda claramente reflejada en las directrices de AWS: la actualización de los recursos de red propiedad del cliente, como los balanceadores de carga, a una política TLS habilitada para PQ, recae en el cliente dentro del modelo de responsabilidad compartida. AWS proporciona políticas TLS actualizadas que admiten el intercambio de claves híbrido ML-KEM y políticas de control de recursos de IAM para aplicar la política TLS deseada en la creación de recursos futuros; sin embargo, la aplicación de dicha política a los recursos existentes es una acción del cliente, no un cambio automático de AWS. AWS Private CA y AWS KMS, en conjunto, admiten capacidades post-cuánticas para la infraestructura de certificados y claves, también como herramientas que el cliente configura, en lugar de una configuración predeterminada que se aplica automáticamente.

Azure y Google Cloud: Plazos diferentes, pero no ausentes

Azure y Google Cloud están invirtiendo en la preparación para la era post-cuántica, pero no de forma uniforme ni al mismo ritmo que AWS en todas las categorías de servicios para 2026. Auditorías independientes entre nubes han revelado que la documentación de HSM administrado de Azure, por ejemplo, todavía se centra en los tipos de clave RSA, de curva elíptica y AES, en lugar de ML-KEM o ML-DSA, incluso cuando Microsoft ha implementado capacidades post-cuánticas en otras partes de la plataforma Windows, incluyendo la compatibilidad con ML-DSA en los Servicios de certificados de Active Directory. Esta es una brecha específica del servicio, no una declaración sobre la postura general de Azure respecto a la computación post-cuántica, razón por la cual la verificación servicio por servicio es más importante que un juicio a nivel de proveedor único.

Google Cloud ha publicado su propia hoja de ruta detallada de PQC, que abarca la migración de la confidencialidad, la integridad de la firma y los hitos de cada servicio; analizamos esa hoja de ruta y sus implicaciones específicas para los clientes empresariales en una guía dedicada, ya que merece un tratamiento detallado propio en lugar de un resumen aquí.

Las preguntas de auditoría que realmente importan

La pregunta "¿Esta nube admite criptografía postcuántica?" es demasiado general para evaluarla, ya que un proveedor puede responder afirmativamente con toda honestidad porque una biblioteca TLS en algún punto de la pila negocia un KEM híbrido, mientras que un servicio completamente diferente en la misma nube sigue emitiendo únicamente claves clásicas. Las preguntas que realmente revelan deficiencias reales durante una auditoría son más específicas:

• ¿Puedo establecer una clave secreta compartida post-cuántica estandarizada por NIST en el punto final TLS de este servicio específico?
• ¿Puede el KMS en la nube crear una clave de firma ML-DSA, y se realiza esa generación de clave y operación de firma dentro de un HSM validado?
• ¿El protocolo TLS post-cuántico está disponible simplemente como una opción, o se negocia automáticamente en la ruta del cliente que mi aplicación utiliza realmente en producción?
• ¿Qué dependencias de certificados FIPS 140-2 o FIPS 140-3 tiene este servicio específico y cómo le afecta la finalización de la certificación FIPS 140-2 en septiembre de 2026?

Pruebe en lugar de dar por sentado: capture el protocolo de enlace TLS real y la negociación de intercambio de claves para los servicios de los que depende, utilice directamente las API de firma, verificación, encapsulación y desencapsulación de KMS, y pruebe el comportamiento alternativo cuando no esté disponible una negociación post-cuántica, en lugar de confiar en la afirmación general de marketing de un proveedor sobre la compatibilidad con PQC.

Cómo elaborar su inventario de responsabilidades compartidas

Un inventario completo de PQC en la nube abarca más que TLS: autoridades de certificación, certificados de servidor y cliente, claves KMS y HSM, dependencias SSH, claves de firma de código, configuraciones VPN, terminadores TLS, mallas de servicios y cualquier administrador de claves externo superpuesto al de la nube. Para cada elemento, se debe determinar en qué lado de la línea de responsabilidad compartida se encuentra, cuál migra el proveedor de la nube por defecto, cuál requiere un cambio de configuración por parte del cliente y cuál depende de una funcionalidad del proveedor que aún no se ha implementado. Los datos confidenciales de larga duración también necesitan su propia capa de seguimiento, independiente de la categoría de infraestructura, ya que los datos con un requisito de confidencialidad de varios años conllevan un riesgo de recopilación y descifrado posterior, independientemente del servicio en la nube que los almacene o transmita.

Lo que realmente recomendamos

Audite cada proveedor de nube que utilice por separado y a nivel de servicio, no como una simple casilla de verificación para toda la organización sobre si estamos preparados para la gestión de calidad en la nube (cloud PQC). Aplique ahora las políticas TLS híbridas ya disponibles de AWS a los recursos de sus clientes, en lugar de asumir que el progreso del servicio de AWS las cubre automáticamente. Realice un seguimiento de la preparación de Azure y Google Cloud servicio por servicio según sus propios plazos, en lugar de asumir la paridad de funciones con AWS, y cree su inventario para distinguir explícitamente las dependencias administradas por el proveedor de las configuradas por el cliente, ya que esa distinción es lo que realmente activa una auditoría de responsabilidad compartida.

Cómo puede ayudar la consultoría de cifrado

El inventario detallado de servicios que propone esta guía, que distingue lo que cada proveedor de nube migra automáticamente de lo que sigue siendo responsabilidad de su configuración, es precisamente lo que CBOM Secure está diseñado para producir en entornos multinube e híbridos, asignando certificados, claves y configuraciones TLS a su estado de gestión por parte del proveedor o del cliente.

Nuestros servicios de asesoramiento PQC analizan las preguntas de auditoría descritas en esta guía en su entorno real en la nube, probando la negociación TLS real y el comportamiento de la API KMS en lugar de basarse en las afirmaciones de marketing del proveedor. Las deficiencias detectadas se integran en un plan de remediación priorizado para el cliente. Cuando la emisión de certificados abarca varios proveedores de nube, CertSecure Manager gestiona certificados clásicos, híbridos y post-cuánticos desde un único plano de políticas en AWS, Azure y Google Cloud.

Verifica la línea, no la des por sentada.

Los proveedores de servicios en la nube están avanzando hacia la criptografía postcuántica, y AWS, en particular, ha publicado una descripción operativa muy clara de lo que migra automáticamente y lo que deja a la configuración del cliente. Esta claridad no se extiende por igual a todos los proveedores y servicios, razón por la cual la pregunta "¿mi nube admite PQC?" no es la correcta. La pregunta adecuada es específica del servicio y verificable: ¿este punto final en concreto negocia un intercambio de claves híbridas validado en la ruta del cliente que utiliza mi aplicación, y quién es responsable de activarlo?

Preguntas frecuentes

¿AWS habilita automáticamente TLS post-cuántico en mis recursos?

No de forma uniforme. AWS ofrece compatibilidad híbrida ML-KEM de forma transparente en los puntos finales de AWS KMS, ACM y Secrets Manager, pero la actualización de los recursos propiedad del cliente, como los balanceadores de carga, a una política TLS habilitada para PQ recae explícitamente en el cliente, dentro del modelo de responsabilidad compartida.

¿Necesito migrar datos cifrados con el cifrado simétrico predeterminado de AWS KMS?

No. Los algoritmos de cifrado simétrico utilizados para el cifrado en reposo ya se consideran resistentes a la computación cuántica y no requieren una migración post-cuántica por sí mismos.

¿Está Azure por detrás de AWS en criptografía postcuántica?

Varía según el servicio. Las auditorías independientes han detectado deficiencias en áreas específicas, como la compatibilidad con tipos de claves HSM administradas por Azure, mientras que Microsoft ha implementado capacidades post-cuánticas en otros ámbitos, incluyendo la compatibilidad con ML-DSA en los Servicios de certificados de Active Directory. Es recomendable verificar la preparación servicio por servicio, en lugar de evaluar la postura general de un proveedor basándose en un solo servicio.

¿Cuál es la mejor manera de comprobar si un servicio en la nube realmente admite el intercambio de claves post-cuánticas?

Captura el protocolo de enlace TLS real para el punto final específico usando una herramienta como Wireshark o las herramientas para desarrolladores integradas de tu navegador, en lugar de confiar en la publicidad general del proveedor. Para los servicios KMS, prueba directamente la API de firma, verificación, encapsulación o desencapsulación para confirmar la compatibilidad con algoritmos post-cuánticos, en lugar de basarte únicamente en la documentación.

¿Qué debería incluir un inventario PQC multi-nube?

Autoridades de certificación, certificados de servidor y cliente, claves KMS y HSM, dependencias SSH, claves de firma de código, configuraciones VPN, terminadores TLS y mallas de servicios, cada uno asignado a si es administrado por el proveedor, configurado por el cliente o depende de una funcionalidad que aún no se ha lanzado.