Qué significa la hoja de ruta PQC de Google Cloud para 2029 para los clientes empresariales.

Respuesta rápida: La hoja de ruta post-cuántica de Google Cloud, anunciada por primera vez el 25 de marzo de 2026, se divide en tres ejes con diferentes plazos: la protección de confidencialidad y almacenamiento (almacenar ahora, descifrar después) se prevé completar a finales de 2027; la integridad y el no repudio (firmas digitales, certificados, identidad) se prevén para finales de 2028; y los fundamentos criptográficos (gestión de claves, hardware, agilidad) también se prevén para finales de 2028, con plena disponibilidad para 2029. Varias partes ya están en funcionamiento: Cloud KMS alcanzó la disponibilidad general para ML-KEM, ML-DSA y SLH-DSA, y los puntos finales de la API de Google Cloud y los balanceadores de carga compatibles ya negocian el intercambio de claves híbridas ML-KEM. La dependencia del cliente que más importa: Google migra su propia infraestructura y servicios gestionados, pero la configuración TLS del lado del cliente, la criptografía de la capa de aplicación y cualquier biblioteca cliente que aún dependa exclusivamente de algoritmos clásicos siguen siendo responsabilidad del cliente, la misma división de responsabilidad compartida que se aborda en nuestra guía más amplia sobre PQC en la nube.

Una hoja de ruta con fecha de 2029 puede interpretarse fácilmente como algo que aún no es urgente. Sin embargo, esta interpretación no comprende el propósito de una hoja de ruta por fases: la prioridad en materia de confidencialidad se cierra primero, a finales de 2027, precisamente porque el riesgo de almacenar datos y descifrarlos posteriormente ya está presente. Esta guía desglosa la hoja de ruta en lo que abarca, lo que ya está en funcionamiento y lo que los clientes empresariales deben hacer por su cuenta, independientemente del cronograma de Google.

Puntos Clave

• La hoja de ruta se divide en tres ejes: confidencialidad (finales de 2027), integridad y no repudio (finales de 2028) y fundamentos criptográficos (finales de 2028), con el objetivo de alcanzar la plena operatividad en 2029.
• Cloud KMS ya admite de forma general ML-KEM, ML-DSA y SLH-DSA para el cifrado y la firma de claves; los puntos finales de la API de Google Cloud y los balanceadores de carga compatibles ya negocian el intercambio de claves ML-KEM híbrido.
• Google está impulsando los certificados Merkle Tree, desarrollados con socios de la industria, como una alternativa a la incrustación de grandes firmas post-cuánticas directamente en los certificados X.509.
• La responsabilidad de Google abarca el tráfico de red, las interfaces globales, el protocolo interno ALTS y el hardware y los sistemas operativos subyacentes; las políticas TLS configuradas por el cliente, la criptografía de la capa de aplicación y las bibliotecas de cliente siguen siendo responsabilidad del cliente.
• El objetivo de Google de completar el servicio en 2029 ahora coincide con el de Cloudflare y con un calendario revisado y acelerado de Microsoft, lo que convierte a 2029 en un referente común del sector en lugar de una fecha aislada de un solo proveedor.

Las tres vías y por qué la confidencialidad se cierra primero.

La hoja de ruta de Google Cloud prioriza deliberadamente la confidencialidad sobre la integridad, y este razonamiento es importante para que los clientes puedan priorizar su propio trabajo. El riesgo de almacenar datos ahora y descifrarlos después, es decir, que un adversario capture el tráfico cifrado hoy para descifrarlo cuando exista una computadora cuántica criptográficamente relevante, ya está presente. Por ello, la ruta de confidencialidad, que abarca el cifrado de red y el intercambio de claves, tiene la fecha límite más temprana: finales de 2027. La integridad y el no repudio, las firmas digitales, los certificados y los mecanismos de autenticación que impiden la falsificación de identidades o la manipulación de datos, tienen un plazo más amplio, hasta finales de 2028, lo que refleja tanto una menor urgencia inmediata (una firma falsificada requiere un ataque activo hoy, no solo la captura de datos) como el problema de ingeniería realmente más complejo que supone la migración de firmas en todo un ecosistema de certificados. El trabajo fundamental, que incluye bibliotecas de gestión de claves, módulos de seguridad de hardware, la integración de gestores de claves externos y la agilidad criptográfica, también se extiende hasta finales de 2028, ya que sirve de base a las otras dos rutas en lugar de ser una herramienta independiente.

Lo que ya está disponible

Varios elementos de la hoja de ruta no son compromisos futuros; son funcionalidades que se implementarán y estarán disponibles de forma general a partir de 2026:

• KMS en la nube: Se ofrece soporte generalizado para ML-KEM, ML-DSA y SLH-DSA tanto para claves de cifrado como de firma, con implementaciones subyacentes mantenidas como código abierto a través de las bibliotecas BoringCrypto y Tink de Google para garantizar su auditabilidad.
• Puntos de conexión de la API de Google Cloud y balanceadores de carga: google.com y *.googleapis.com, junto con los balanceadores de carga de aplicaciones y proxies compatibles, ya negocian el intercambio de claves híbridas ML-KEM, incluido X25519MLKEM768 para TLS 1.3.
• ALTERNATIVAS: El protocolo de transporte interno de la capa de aplicación de Google completó su transición a la confidencialidad post-cuántica en 2025.
• Importación de claves seguras frente a la computación cuántica a Cloud KMS: Previsto para 2026 dentro del programa de fundaciones.

En la hoja de ruta a corto plazo, aún quedan por implementar: VPN en la nube e interconexión (2026-2027), CA privada a través del Servicio de Autoridad de Certificación (2027) y HSM en la nube y soporte para computación confidencial post-cuántica (2028).

Certificados de árbol Merkle: Un enfoque diferente para la infraestructura de clave pública (PKI).

Una decisión estructural en la hoja de ruta de Google merece ser analizada por sí sola: en lugar de integrar firmas post-cuánticas directamente en el formato de certificado X.509 existente, un enfoque que aumenta considerablemente el tamaño de los certificados y las cadenas, Google está desarrollando certificados de árbol Merkle junto con socios de la industria como una arquitectura de certificado alternativa diseñada desde cero en torno a las limitaciones post-cuánticas, en lugar de adaptar el formato clásico. Este enfoque aún está en desarrollo, no es un reemplazo directo para X.509 en la actualidad, y no cambia lo que los clientes necesitan hacer en su propia infraestructura de certificados a corto plazo, pero indica que la innovación en el formato de certificado, y no solo la sustitución de algoritmos, forma parte de la manera en que los mayores operadores de nube y CDN están abordando el aspecto de las firmas en esta transición.

¿Qué sigue siendo responsabilidad del cliente?

La propia definición de responsabilidad compartida de Google es directa: Google gestiona la seguridad de la nube, incluyendo el tráfico de red, los front-ends globales, ALTS y el hardware y los sistemas operativos subyacentes, manteniendo la integridad del hardware mediante bases de silicio resistentes a la computación cuántica como Caliptra y OpenTitan. Los clientes siguen siendo responsables de configurar sus propias cargas de trabajo para utilizar las capacidades post-cuánticas que Google pone a su disposición, la configuración TLS de la capa de aplicación, las versiones de las bibliotecas cliente y cualquier criptografía implementada en su propio código en lugar de delegarla a un servicio gestionado por Google. Esta es la misma distinción que se aborda en términos más generales en nuestra guía de responsabilidad compartida en la nube : un proveedor que migra su propia infraestructura no migra automáticamente las dependencias de la capa de aplicación de un cliente.

Lo que realmente recomendamos

Priorice su propio trabajo de seguimiento de confidencialidad, configuración TLS e intercambio de claves, por encima del trabajo de seguimiento de firmas, siguiendo la lógica de secuenciación de Google, ya que la exposición de almacenamiento inmediato y descifrado posterior es el riesgo a corto plazo. Confirme qué claves de Cloud KMS en su entorno ya utilizan ML-KEM o ML-DSA y cuáles aún utilizan algoritmos clásicos, ya que la disponibilidad general de esta funcionalidad no implica que sus claves existentes se hayan migrado automáticamente. Siga de cerca los hitos de Google Private CA y Cloud HSM posteriores a la computación cuántica, especialmente si su arquitectura depende de alguno de ellos, ya que estos se implementarán más adelante en la hoja de ruta que las funcionalidades de API y balanceador de carga que ya están disponibles.

Cómo puede ayudar la consultoría de cifrado

Saber cuáles de tus claves KMS de Google Cloud, políticas TLS del balanceador de carga y dependencias de certificados ya son compatibles con la era post-cuántica, y cuáles aún requieren alguna acción por tu parte, es precisamente la brecha de inventario que CBOM Secure está diseñado para cerrar, mapeando tu huella criptográfica en la nube con lo que Google Cloud ha migrado y lo que aún no.

Nuestros servicios de asesoramiento sobre PQC crean una hoja de ruta para el cliente, secuenciada según el cronograma de tres fases de Google Cloud. De esta forma, el trabajo relacionado con la confidencialidad se realiza antes de la ventana de exposición de almacenamiento y descifrado, y el trabajo relacionado con las firmas está listo antes de que se alcancen los hitos de certificación y CA privada de Google. Cuando la emisión de certificados abarca Google Cloud junto con otros entornos, CertSecure Manager gestiona los certificados clásicos, híbridos y post-cuánticos desde un único plano de políticas.

Un cronograma del proveedor, no una fecha límite para el cliente.

La hoja de ruta de Google Cloud indica cuándo la infraestructura de Google estará preparada para la era post-cuántica. Sin embargo, no indica cuándo lo estarán su aplicación, su cadena de certificados ni la configuración específica de su clave Cloud KMS, ya que esto sigue siendo responsabilidad del cliente, independientemente de la rapidez con la que Google avance. Interpretar la secuencia de tres fases como una guía de priorización (la confidencialidad primero, seguida de las firmas y los fundamentos) es la forma más útil de traducir la hoja de ruta de un proveedor en su propio plan de migración.

Preguntas frecuentes

¿Cuándo anunció Google Cloud su hoja de ruta post-cuántica?

Google anunció por primera vez el objetivo para toda la compañía en 2029 el 25 de marzo de 2026, y poco después publicó la hoja de ruta detallada de tres vías y sus propios hitos.

¿Por qué el plazo para la autorización confidencial es anterior al plazo para la firma?

El riesgo de almacenar y descifrar posteriormente el tráfico de red cifrado es una vulnerabilidad actual, ya que un adversario puede capturar el tráfico ahora y descifrarlo más tarde. La falsificación de una firma o certificado requiere un ataque activo en el momento de su uso, lo que representa un riesgo posterior y le otorga a la detección de firmas un margen de tiempo mayor hasta finales de 2028.

¿La migración de PQC de Google Cloud cubre mi aplicación automáticamente?

No del todo. Google migra su propia infraestructura administrada, el tráfico de red y los servicios, pero las políticas TLS configuradas por el cliente, la criptografía de la capa de aplicación y las bibliotecas de cliente siguen siendo responsabilidad del cliente para su actualización y activación.

¿Qué son los certificados Merkle Tree?

Google está desarrollando una arquitectura de certificados alternativa con socios de la industria, diseñada desde cero teniendo en cuenta las limitaciones de tamaño y rendimiento de la era post-cuántica, en lugar de integrar grandes firmas post-cuánticas en el formato X.509 existente. Se trata de un enfoque emergente, no de un reemplazo directo para X.509.

¿Qué funcionalidades post-cuánticas de Google Cloud ya están disponibles de forma general?

Compatibilidad de Cloud KMS con ML-KEM, ML-DSA y SLH-DSA; intercambio de claves ML-KEM híbrido en los puntos finales de la API de Google Cloud y en los balanceadores de carga compatibles; y confidencialidad post-cuántica para el protocolo ALTS interno de Google, finalizada en 2025.