Encriptación y protección de API: TLS, HSTS, PFS, rotación de secretos

1) Cuadro de amenazas y objetivos

API bajo ataque de MitM, interceptación de tráfico, ataques de downgrade, falsificación de tokens, filtraciones de claves y abuso de secretos de larga vida. Objetivos de protección:

Privacidad e integridad (TLS 1. 3 + cifrados fuertes).
Protección contra downgrade/stripping (HSTS, versiones/cifrados prohibidos).
Minimización de daños por compromiso (PFS, TTL cortos, rotación rápida).
Autenticación confiable del cliente/servicio (mTLS/tokens) y trazabilidad.

2) TLS como base (servidor y servicio-a-servicio)

Versiones y cifrados:

De forma predeterminada, TLS 1. 3; permitir TLS 1. 2 sólo para compatibilidad. Desactivar 1. 1/1. 0.

Prioridades de cifrado TLS 1. 3:

`TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`.
Para TLS 1. 2: sólo ECDHE con firma AES-GCM/ChaCha20 y ECDSA/RSA (por ejemplo, 'ECDHE-ECDSA-AES128-GCM-SHA256').

Claves y certificados:

Claves de servidor: ECDSA P-256/P-384 (más rápido y más corto) o RSA 2048 +/3072.
Claves de cliente para mTLS: ECDSA P-256; emisión a través de su propia CA o HSM/KMS de pago.
Active OCSP stapling, preferiblemente con la bandera Must-Staple, y ALPN (HTTP/2/3).

PFS (Perfect Forward Secrecy):

Provisto de intercambios efímeros (ECDHE) - incluso si la clave del servidor es un pato, las sesiones pasadas no se descifran.
Apague el acuerdo clave DH/RSA estático.

Adiciones modernas:

ECH (Encrypted Client Hello), si es compatible con el frente/CDN, oculta el SNI.
HTTP/2/3 sólo con cifrados fuertes; prohibición de HTTP sin protección, redireccionamiento en HTTPS.

3) HSTS vs TLS-stripping

Habilite la Seguridad de Transporte Strict HTTP en el dominio raíz y subdominios:


Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Coloque el dominio en la lista de preload de HSTS.

Asegúrese de que es correcto antes de publicar (la reversión es difícil).

4) Autenticación mutua: mTLS y/o tokens

mTLS entre microservicios/API internas: certificados bidireccionales, rotación automática a través de mesh de servicio (Istio/Linkerd) o PKI propio.

Clientes API (integraciones móviles/de socios): tokens (OAuth2/OIDC, JWT), opcional mTLS para alto riesgo.

Para los frentes públicos: TLS + tokens OAuth2/OIDC de vida corta con enlace al dispositivo/DPoP.

5) Administración de certificados y ciclo de vida

Automatización ACME (por ejemplo, Let's Encrypt/Organization CA) con actualización automática 30 días antes de la expiración.

Certificaciones de corta vida (≤ 90 días) + monitoreo de plazos, alertas y paquetes de deploy canario.

PKI centralizado: CA raíz/intermedio, CRL/OCSP, auditoría de lanzamientos y revocación.

Ejemplo nginx (fragmento):

nginx ssl_protocols TLSv1. 3 TLSv1. 2;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve X25519:P-256:P-384;
ssl_stapling on; ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

6) Rotación de secretos: principios y patrones

Objetivos de rotación: limitar el «radio explosivo» de las fugas, reducir el tiempo de abuso, garantizar liberaciones sin fisuras.

Reglas básicas:

Almacenar secretos sólo en el administrador secreto (KMS/Vault/Cloud SM). No hay secretos en Git/imágenes.
TTL cortos y rotación automática: claves de firma, contraseñas de BD, claves API de proveedores.
Doble publicación (dual-key window): las claves antiguas y nuevas están activas simultáneamente durante el período de encrucijada.
Versioning + kid (para JWT/JWKS), ventana «grace» para validar tokens antiguos.

Qué rotar regularmente:

Claves JWT (firma/cifrado), secretos HMAC de webhooks y callback's, contraseñas/cuentas de DB, créditos de caché (Redis), fichas CI/CD, secretos de proveedores (KYC/AML, pagos, SMS/e-mail), llaves SSH automáticas.

Los desencadenantes de la rotación no programada son: sospecha de fuga, despido de empleados con acceso, cambio de proveedor, requerimientos del regulador.

7) JWT/JWKS: roles de roles seguros

Publica JWKS endpoint con la clave actual y futura ('kid' es obligatorio).

Procedimiento de rotación:

1. Generar una nueva clave → añadir a JWKS como «segundo».

2. Actualizar los firmantes → emitir nuevos tokens con una nueva clave.

3. Espere al TTL de los tokens antiguos → elimine la clave antigua de JWKS.

Configure tokens TTL cortos (por ejemplo, 5-15 minutos) + hilos refresh con verificación adicional.

8) Gestión secreta en la práctica

KMS + envelope encryption: clave maestra en HSM/KMS, los datos están cifrados por DEK «envueltos».

Vault/Cloud Secret Manager: créditos dinámicos a la DB (emisión de libros con TTL), rotación periódica.

Kubernetes: External Secrets/Secrets Store CSI; cifrado etcd; RBAC; prohibición de la lógica de secretos.

Acceso por roles: IAM/ABAC, principio de menor privilegio, límites de hardware (HSM, TPM).

Auditoría completa: quién, qué, cuándo, por qué leyó/cambió.

9) Protección del transporte dentro del perímetro

No confíe en la «red interna»: TLS/mTLS (zero-trust) en todas partes.

Service mesh automatiza los certificados, el reinicio y la rotación, la observabilidad (mTLS por defecto).

Minimice las terminaciones TLS: ya sea en edge + encriptado east-west o cifrado de extremo a extremo.

10) Políticas de seguridad API sobre TLS

Rate limiting/DoS-protection, verificación de firma de webhooks (HMAC con rotación de secretos).

Content-Security-Policy/Referrer-Policy/X-Content-Type-Options для фронта.

mTLS para endpoint's críticos (pagos, administración), IP allow-list por partner.

Respuesta-protección: timestamp + nonce en solicitudes firmadas, ventanas de no más de 5 minutos.

11) Monitoreo y pruebas

Observabilidad TLS: versiones/cifrados en métricas, alertas para intentos de downgrade, aumento de fallos de apretones de manos.

Escáneres (en CI/CD y regularmente en venta): validación de cifrados compatibles, certificados, HSTS, OCSP.

Ejercicios Chaos/DR: caducidad del certificado, caída del administrador secreto, compromiso de clave de firma - comprobar los planes de reacción.

12) Procedimientos de respuesta

Compromiso de clave: revocación inmediata del certificado/eliminación de clave de JWKS, reversión de respaldo, regeneración forzada de tokens.

Caducidad sin renovación: degradación temporal (sólo tráfico interno), reinstalación automática de certificados.

Informe de incidentes: línea de tiempo, sujetos afectados, tech. detalles, medidas correctivas.

13) Lista de verificación rápida (prod-ready)

Sólo TLS 1. 3 (+ 1. 2 para legasi), una lista estricta de cifrados.
HSTS с `preload`, OCSP stapling, ALPN.
ECDHE para PFS; ECDSA P-256/384 o RSA 3072.
mTLS dentro del clúster/entre servicios críticos.
JWKS + kid, fichas TTL cortas, plan de rotación.
Secretos - sólo en KMS/Vault, BD/proveedores de rotación automática.
Actualización automática de certificados (ACME), alertas en 30 días.
Verificación CI/CD de encabezados de seguridad y cifrados vulnerables.
Runbook documentado 'y: rotación, revocación, incidentes.

Resumen

La API segura es una combinación de TLS 1. 3 + HSTS + PFS como mínimo obligatorio y procesos de gestión de claves y secretos maduros. Agregue mTLS entre los servicios, automatice la liberación/rotación a través de KMS/Vault/mesh, mantenga cortas TTL y «ventanas dobles» al cambiar las llaves, y minimice los riesgos de interceptación, downgrade y abuso de secretos acotados sin romper la disponibilidad y la velocidad del producto.