AWS ALB y NLB soportan políticas de seguridad RFC 9151 para CNSA 1.0

Introducción

Los equipos que operan en entornos regulados, como agencias gubernamentales o contratistas de defensa en EE.UU., enfrentaban un desafío al usar AWS Application Load Balancer (ALB) y Network Load Balancer (NLB): no podían cumplir con los requisitos de la Commercial National Security Algorithm (CNSA) 1.0 del NSA para comunicaciones TLS. Hasta ahora, las políticas de seguridad disponibles en estos balanceadores no implementaban el conjunto de algoritmos y parámetros mandatorios definidos en el RFC 9151, lo que obligaba a deployar soluciones alternativas (como instancias EC2 con software de terminación TLS personalizado) para cumplimentar estas normativas.

La falta de soporte nativo generaba compleidad operativa, mayores costos y riesgos de configuración inconsistente. Con el anuncio del 5 de agosto de 2026, AWS resolvió este gap al agregar políticas de seguridad compatibles con RFC 9151 para ALB y NLB en todas sus regiones comerciales, GovCloud (US) y China.

Qué ocurrió

AWS incorporó nuevas políticas de seguridad TLS para ALB y NLB que cumplen estrictamente con los requisitos del CNSA 1.0 Suite, definidos por el NSA en el RFC 9151. Estas políticas están diseñadas para proteger comunicaciones contra ataques criptográficos, incluso de adversarios con capacidades de computación cuántica en el futuro. El cambio permite:

• Usar ALB y NLB en entornos que exigen CNSA 1.0 (como sistemas de nivel Classified o Controlled Unclassified Information).
• Mantener compatibilidad con clientes que aún no implementan CNSA mediante políticas «interoperables» que priorizan CNSA pero permiten fallback a algoritmos legacy.

El soporte está disponible desde el 5 de agosto de 2026 en todas las regiones AWS, sin costo adicional. No requiere cambios en la infraestructura subyacente: se configura a nivel del listener del balanceador.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de Seguridad y Cumplimiento, este cambio elimina una barrera clave para certificar aplicaciones en entornos regulados. El CNSA 1.0 es mandatorio para sistemas que procesan información sensible del gobierno de EE.UU., y su adopción se está extendiendo a sectores como defensa, energía y financiero. Hasta ahora, las alternativas en AWS (como deployar NGINX o HAProxy en EC2) incrementaban la superficie de ataque, la latencia y el costo operativo.

Para DevOps e Infraestructura, simplifica la arquitectura al permitir usar balanceadores manejados para terminación TLS con CNSA. Esto reduce la necesidad de mantener instancias dedicadas para este propósito, mejorando la escalabilidad y la resiliencia. Además, las políticas interoperables permiten migrar clientes legacy de forma gradual, sin downtime.

En el plano Cloud, la integración nativa con ALB y NLB aprovecha las ventajas de estos servicios: balanceo automático, health checks, integración con Certificates Manager (ACM) y soporte para millones de solicitudes por segundo. El rendimiento no se ve afectado, ya que AWS implementó las cifras CNSA en su TLS stack optimizado.

Detalles técnicos

El RFC 9151 define un conjunto de algoritmos criptográficos para TLS 1.2 y TLS 1.3 que cumplen con CNSA 1.0. Las políticas nuevas en AWS enforcean los siguientes requisitos:

Algoritmos permitidos:

• TLS 1.3:

– Curvas elípticas: X25519, X448

• TLS 1.2:

– Curvas elípticas: X25519, X448

– Firmas: ECDSA con curvas P-256, P-384 o P-521

Algoritmos prohibidos:

• Todos los ciphers que no sean AEAD (ej: CBC, RC4).
• RSA key exchange (ephemeral o static).
• Curvas elípticas no aprobadas (ej: secp256k1, P-256K).
• Hashes truncados (ej: SHA-1).

Políticas disponibles:

AWS ofrece dos tipos de políticas RFC 9151:

1. Estricta (CNSA-only): Solo permite conexiones con clientes que soporten CNSA.

1. Interoperable: Prioriza CNSA pero permite fallback a:

– ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (TLS 1.2, solo si el cliente no soporta AEAD)

– Nombre: ELBSecurityPolicy-TLS13-1-2-2026-08-Intersop (provisional).

Componentes afectados:

• ALB: HTTPS listeners (TLS termination).
• NLB: TLS listeners (TLS pass-through con terminación en el target).
• ACM: Los certificados importados o emitidos por ACM pueden usarse con estas políticas, siempre que cumplan con CNSA (ej: curvas P-256, P-384 o P-521 para ECDSA).

Versiones y compatibilidad:

• Requiere TLS 1.2 o superior (TLS 1.0 y 1.1 están deshabilitados).
• Compatible con clients que usen OpenSSL 1.1.1, BoringSSL, Java 11+, .NET Core 3.0+, etc.
• No compatible con clients legacy como Windows 7, Android < 7.0 o Java 8.

Qué deberían hacer los administradores y equipos técnicos

1. Evaluar requisitos de cumplimiento

• Verificar si tu organización debe cumplir con CNSA 1.0 (ej: contratos con el DoD, NIST SP 800-175B).
• Identificar los balanceadores que requieren esta configuración (ej: aquellos que front-end a aplicaciones clasificadas).

2. Auditar certificados

• Asegurarse de que los certificados usados en ALB/NLB cumplan con CNSA:

– Para RSA: tamaño de clave ≥ 3072 bits (aunque CNSA prefiere ECDSA).

• Usar AWS ACM para emitir nuevos certificados si es necesario:

  aws acm request-certificate --domain-name example.com \
    --key-algorithm ECC_SECp384r1 --region us-east-1
  

3. Configurar la política de seguridad

Via AWS Console:

1. Abrir el balanceador en EC2 > Load Balancers.
2. Editar el listener HTTPS/TLS.
3. En Security policy, seleccionar ELBSecurityPolicy-TLS13-1-2-2026-08 (estricta) o ...-Intersop (interoperable).

Via AWS CLI:

aws elbv2 edit-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/1234567890abcdef \
  --listener-id listener-1234567890abcdef \
  --protocol HTTPS \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2026-08

Via Terraform:

resource "aws_elb_listener" "https" {
  load_balancer_arn = aws_elb.my_alb.arn
  port              = 443
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2026-08"
  certificate_arn   = aws_acm_certificate.cert.arn
}

4. Testear compatibilidad

• Validar con clientes CNSA-compliant (ej: OpenSSL 3.0+):

  openssl s_client -connect alb.example.com:443 \
    -ciphersuites TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256 \
    -curves X25519:X448
  

• Identificar clientes legacy que fallen con la política estricta y evaluar si usar la política interoperable o actualizarlos.

5. Monitorear y auditar

• Configurar CloudWatch alarms para el métrico TLSPolicyViolation (se incrementa cuando un cliente no cumple con la política).
• Revisar los logs de acceso del ALB/NLB para detectar conexiones rechazadas:

  aws elbv2 get-access-logs --load-balancer-arn arn:aws:elasticloadbalancing:... --s3-location s3://my-bucket/prefix/
  

Conclusión

El soporte para políticas RFC 9151 en ALB y NLB cierra una brecha importante para equipos que requieren cumplimiento con CNSA 1.0, permitiendo usar balanceadores manejados de AWS sin sacrificar seguridad. La disponibilidad de políticas interoperables facilita la transición gradual, pero es crucial planificar la actualización de clients legacy para adoptar la política estricta a mediano plazo. Para entornos no regulados, estas políticas también ofrecen un nivel de seguridad superior al default, aunque con potencial impacto en compatibilidad.

Fuentes

• https://aws.amazon.com/about-aws/whats-new/2026/08/aws-application-network/
• https://docs.aws.amazon.com/elasticloadbalancing/latest/application/elb-security-policy-2016-08.html
• https://datatracker.ietf.org/doc/html/rfc9151