La llegada del Q-day, el momento en que una computadora cuántica pueda vulnerar los sistemas criptográficos actuales, ha dejado de ser un escenario lejano.
Los agentes malintencionados ya están adoptando la estrategia de “recolectar ahora, descifrar después”, que significa capturar hoy el tráfico corporativo cifrado, la propiedad intelectual y los registros de datos para procesarlos en hardware cuántico tan pronto como esté disponible.
En lugar de tratar la criptografía postcuántica (PQC) como un requisito de cumplimiento normativo para un futuro lejano, Red Hat está liderando esta transformación al incorporar recursos resistentes a la computación cuántica directamente en las capas fundamentales de la infraestructura de nube híbrida con las herramientas necesarias para proteger tus activos digitales hoy.
Esta urgencia no es hipotética. De acuerdo con la Orden Ejecutiva 14412 de la Casa Blanca, se espera que las agencias federales logren un proyecto piloto de migración para la preparación en criptografía postcuántica para 2027 y concluyan la implementación a gran escala para 2029. A ello se suma el mandato de CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) de la Agencia de Seguridad Nacional de los Estados Unidos, que exige algoritmos resistentes a la computación cuántica para sistemas de seguridad nacional, con implementaciones comerciales de TLS sujetas a plazos rigurosos hasta 2030.
Red Hat enfrenta estos desafíos con un enfoque unificado e integrado, que incorpora la seguridad cuántica a la propia base de su nube híbrida. Red Hat Enterprise Linux (RHEL) 10 es la primera distribución Linux empresarial en incluir algoritmos post-cuánticos estandarizados por el NIST, como ML-KEM y ML-DSA.
Construido integralmente sobre esta base reinforced, Red Hat OpenShift hereda estas capacidades sin necesidad de desarrollar sus propias bibliotecas criptográficas desde cero. Utiliza RHEL como mecanismo subyacente responsable del cumplimiento normativo y los algoritmos criptográficos, mientras operacionaliza y escala estos recursos en entornos distribuidos.
De esta manera, las organizaciones llegan a una plataforma más segura, compatible y con mejor costo-beneficio. A continuación 4 acciones para prepararse para el Q-day.
1. Haz un inventario de tu superficie criptográfica oculta en toda la nube híbrida
La mayoría de las empresas opera millones de conexiones automatizadas entre softwares que aún dependen de algoritmos de criptografía de clave pública antiguos y vulnerables a la computación cuántica. Los equipos de seguridad necesitan tener una visión integral de dónde se cifran los datos y dónde se generan las claves digitales en entornos distribuidos. Esto cambia el enfoque operacional hacia el mapeo de activos de alto valor, como pesos de modelos de IA y registros de entrenamiento.
Red Hat Enterprise Linux 10 proporciona configuraciones criptográficas de próxima generación al habilitar algoritmos avanzados resistentes a la computación cuántica. Los operadores pueden activar estándares cuánticos para encapsulamiento de claves en todas las comunicaciones esenciales del host. Los equipos de seguridad también deben evaluar las plataformas de software esenciales e identificar patrones de seguridad legados, codificados directamente en las aplicaciones o desactualizados, garantizando que las capas fundamentales de la infraestructura ofrezcan visibilidad clara de las comunicaciones internas de la red.
2. Prueba algoritmos criptográficos de próxima generación en entornos de no producción
La transición en la seguridad exige evaluar cómo los nuevos métodos matemáticos de criptografía afectan el rendimiento general de las aplicaciones, los tiempos de respuesta de la red y la sobrecarga de procesamiento. Los perfiles de políticas criptográficas de RHEL 10, incluida la política FUTURE, permiten que los operadores cambien toda la postura criptográfica del host a estándares resistentes a la computación cuántica con un solo comando. Así, se vuelve viable para los equipos de seguridad probar el comportamiento en condiciones reales en todo el stack.
Red Hat OpenShift 4.22 ofrece intercambio de claves resistente a la computación cuántica como un recurso de disponibilidad general, listo para producción. El intercambio híbrido de claves basado en ML-KEM se activa por defecto. Así, todo handshake TLS entre los componentes del plano de control utiliza criptografía resistente a la computación cuántica desde el inicio, sin necesidad de configuración. Las cargas de trabajo ejecutadas en la plataforma heredan recursos de TLS compatibles con PQC sin exigir ninguna alteración en el código de las aplicaciones.
Como RHEL es responsable de las bibliotecas de seguridad de bajo nivel (como OpenSSL), los desarrolladores no necesitan reescribir código ni gestionar la selección de algoritmos. Esta herencia contrasta con enfoques fragmentados tradicionales de otras plataformas derivadas de Kubernetes, que no ofrecen integración nativa, de extremo a extremo y lista para usar de PQC en el plano de control.
3. Transfiere los límites de la seguridad de la capa de aplicación a la capa de plataforma
Esperar que equipos individuales de desarrollo reescriban manualmente todas las aplicaciones para ofrecer soporte a la criptografía post-cuántica genera enorme fricción operacional, retrasa cronogramas y aumenta el riesgo de errores de configuración.
La seguridad cuántica ya es un requisito inmediato para proteger activos de IA en tránsito. Esto cambia la conversación de una preocupación teórica sobre navegadores en el futuro a la protección inmediata de tus datos propietarios de entrenamiento, pesos de modelos y registros de agentes contra interceptaciones. Los clientes de Red Hat pueden beneficiarse al establecer una capa de plataforma de aplicaciones unificada y criptográficamente ágil, capaz de realizar automáticamente handshakes seguros en nombre de las cargas de trabajo subyacentes.
El uso de herramientas de red segura en toda la plataforma permite que las organizaciones prueben conexiones criptográficas post-cuánticas, protegiendo instantáneamente la comunicación entre containers contra interceptaciones, sin exigir alteraciones en el código fuente de las aplicaciones. Las actualizaciones criptográficas se realizan una única vez en RHEL, se propagan automáticamente a OpenShift y pasan a proteger todas las cargas de trabajo ejecutadas sobre la plataforma.
4. Asegura el control operacional absoluto sobre la ubicación y la ejecución de los datos
Estar realmente preparado también requiere control total sobre dónde se almacenan los datos y cómo la infraestructura ejecuta las cargas de trabajo. Renunciar a esta autonomía arquitectónica para un plan centralizado en nube pública deja a la organización operacionalmente vulnerable a decisiones de plataforma y políticas de gestión que no están bajo su control.
Los operadores pueden maximizar el dominio sobre la infraestructura utilizando entornos de plataforma aislados para mantener límites rigurosos entre diferentes cargas de trabajo computacionales. Esto ayuda a verificar que los caminos recorridos por los datos nunca crucen ubicaciones donde esta información pueda verse comprometida.
