API Gateway: arquitectura y seguridad

TL; DR

La puerta de enlace API es el único punto de política (authz, rate, transformaciones, auditoría) y la frontera de confianza entre el mundo exterior y los servicios. El éxito lo dan: Zero-Trust (mTLS/JWT), policy-as-code, control de tráfico orientado a SLO y observabilidad ortogonal. Construya: edge gateway → BFF → service mesh; mantenga la versificación y las banderas de fichas; Automatice la protección de webhooks y claves; probar lanzamientos canarios.

1) Roles y patrones de colocación

Edge/API Gateway (norte-sur): frontera exterior. Termination TLS, WAF, DDoS, authN/Z, rate/quotas, CORS, transformaciones, caché, webhooks.
BFF (Backend-for-Frontend): capa de adaptación a clientes específicos (web/mobile/partners). Esquemas, agregaciones, límites, caché de respuestas.
Internal Gateway (este-oeste )/Service Mesh Ingress: autorización interna de servicio a servicio, mTLS, política de enrutamiento.
gRPC/NAT/GraphQL gateway: un único punto del traductor de protocolo y los circuitos validadores.

Anti-patrones: «todo a través de una sola puerta de enlace monolítica sin aislar los entornos», «lógica de negocio latente en los plugins», «regla manual de reglas».

2) Modelo de confianza y autenticación

TLS 1. 2+/1. 3 en el perímetro, HSTS en dominios públicos; dentro - mTLS entre la puerta de enlace y los servicios.
OAuth2/OIDC: Código de Authorización (PKCE) para clientes; client-credentials para integraciones de servidores; JWT con TTL corto y rotación de claves (JWKS).
Firmas HMAC para integraciones de socios y webhooks (clave de cliente, SHA-256/512, verificación de tiempo de espera y anti-replay).
Las claves API son sólo como factor dop./para el seguimiento; limitar scope, IP, plazo.

• Comparta authN (quién) y authZ (qué se puede). Utilice atributos (scopes, roles, tenant, risk flags).
• Todos los tokens son con aud/iss/amb/nbf; clock-skew ≤ 60s; kid obligatorio y caché JWKS ≤ 5 min.

3) Autorización y políticas (Zero-Trust)

ABAC/RBAC en la puerta de enlace: reglas sobre claims + contexto de consulta (IP/ASN/geo/tenant).
Policy-as-Code (por ejemplo, OPA/Rego): almacenamiento de reglas en Git, validación CI, posts canarios.
Multi-alquiler: aislamiento por 'X-Tenant-Id', SSO en la frontera tenant; cuotas/límites por inquilino.

4) Control de tráfico y fiabilidad

Rate limiting: leaky/token bucket, granularidad: clave/tenant/route/BIN/país (para API de pago).
Quotas: diurnos/mensuales, separados por operaciones pesadas (por ejemplo, informes).
Control Burst y trottling dinámico basado en carga y SLO.
Circuit breaker: abrir en errores/latencia; outlier detection por Apstrim.
Retry with backoff+jitter; identidad: clave 'Idempotency-Key' + ventana TTL + almacenamiento de resultados.
Timeouts: cliente <gateway <apstream; puntos de referencia p95 razonables (por ejemplo, 1. 5s/3s/5s).
Failover/Canary:% -routing (weighted), session-affinity opcional, blue/green.

5) Transformaciones y validadores

Diagramas: OpenAPI/JSON Schema para NAT; Protobuf para gRPC; SDL para GraphQL. Validación request/response en la puerta de enlace.
Transpilación gRPC↔REST, federación GraphQL (para BFF).
Normalización de encabezado (trace-ids, headers de seguridad), respuesta filtering (PII-edición).
CORS: whitelistas, 'Vary' correcto, prohibición "en las solicitudes de 'Authorization'.
Compression и response caching (ETag/Cache-Control) для safe-GET.

6) Seguridad perimetral

WAF: OWASP Top-10 reglas, modelo positivo para routs críticos, parches virtuales.
Bot-protection: firmas rate-based, fingerprint de dispositivo, capchas protegidas para endpoints públicos.
Escudo DDoS: upstream (cloud) + límites locales; geo/ASN hojas de flujo.
CSP/Referrer-Policy/X-Frame-Options - Si la puerta de enlace sirve estática/widgets.
WebSockets/SSE/WebPort: perfiles de límite y tiempo de espera individuales; prolongación automática del token.

7) Webhooks: seguridad y entrega

Cada receptor tiene su propio secreto; la firma 'HMAC (signature, timestamp' path 'body)'; ventana de tiempo permitido (por ejemplo, 5 min).
Idempotencia en la recepción: dedoup por 'event _ id'.
Retraídas: exponenciales, máximo N; status-endpoint para hand-shake.
mTLS/Allow-list IP; posibilidad de replay bajo petición con restricciones.

8) Observabilidad y auditoría

Registros: no lógica secretos/PAN/PII; corear por 'trace _ id '/' span _ id'; enmascaramiento.
Métricas: RPS, error rate por clase, latency p50/p95/p99, circuitos abiertos, retry rate, 4xx vs 5xx, saturation.
Tracks: W3C Trace Context; pisar 'traceparent '/' tracestate' en apestrimes.
Auditoría: flujo separado de «quién y qué llamó/cambió», almacenamiento inmutable; eventos de política (access-denied, quota-hit).

9) Secretos y criptografía

Almacenamiento de claves: KMS/Vault, rotación cada 90 días (o más frecuentemente), roles individuales por lectura.
Certificados: emisión/actualización automática (ACME), pinning para móviles (TOFU/HPKP-like cuidadosamente).
Rotación JWKS: dos llaves activas (antiguo/nuevo), ventanas encrucijadas claras.
Criptoprofili TLS: preferencia por ECDHE, prohibición de cifrados/protocolos vulnerables.

10) Cumplimiento y datos

PCI DSS: hilos PAN-safe, tokenización; Nunca busque raw-PAN a través de plugins.
GDPR/DSAR: enrutamiento por región/tenante, residencia de datos, eliminación/anonimización.
Límite de exposición PII: filtrado de campos en la puerta de enlace, cifrado de encabezados sensibles.

11) Topologías y multirregionales

Self-managed vs Managed (Envoy/Kong/NGINX vs cloud API gateway). Para un control estricto/PCl - más a menudo autogestionado.
Active-Active-Active Multi-AZ/Multi-Región: DNS/GSLB global, health-based y geo-routing, po-regional secret-stores.
Plan DR: RPO/RTO, puerta de enlace standby fría/cálida con política azul.

12) Versificación y evolución de la API

Estrategias: URI vN, header-versioning, content-negotiation. Para los públicos, una política clara de depreción (≥6 -12 meses).
Backward-compat: ampliar los esquemas añadiendo campos opcionales; contratos en Git, linters OpenAPI.
Canary/Shadow: ejecutar el tráfico en la «sombra» de la nueva versión, comparando las respuestas.

13) Rendimiento y caché

Caché en edge para solicitudes GET/idempotent; condiciones: ETag/Cache-Control correctos.
Conexión pooling a Apstrim; HTTP/2 mantener activado; para gRPC, el beneficio máximo.
budgets de pago: limitar el tamaño de los cuerpos; gzip/br.
Pre-computación de respuestas BFF para paneles/directorios de alta frecuencia.

14) Administración de configuración

GitOps: manifiestos declarativos de rutas/políticas; review/CI (lint, security scan); CD con los partidos canarios.
Banderas de fichas en la pasarela: interruptor rápido de rutas/reglas sin desbroce.
Templates para directivas repetitivas (OIDC, rate, CORS).

15) Mini-snippets (pseudo)

yaml plugins:
- name: idempotency config:
header: Idempotency-Key ttl: 24h storage: redis

yaml
- name: rate-limiting config: {policy: local, minute: 600, key: consumer_id}
- name: response-ratelimiting config: {limits: {"heavy": {minute: 60}}, key: route_id}

yaml
- name: oauth2-introspection config:
jwks_uri: https://idp/.well-known/jwks. json required_scopes: ["payments:write","payments:read"]

yaml
- name: waf config:
mode: block ruleset: owasp_crs exclusions: ["/health", "/metrics"]

pseudo sig = HMAC_SHA256(secret, timestamp + "\n" + method + "\n" + path + "\n" + sha256(body))
assert     now - timestamp     < 300s

16) NFT (NFR) y SLO para gateway

Uptime (mes): ≥ 99. 95% (edge), ≥ 99. 9% (internal).
Latency p95: ≤ 50-100 ms suplementos de Apstream.
Error budget: ≤ 0. 05% 5xx de la puerta de enlace (excluyendo el upstream).
Políticas de seguridad: 100% de las consultas con TLS; 0 incidentes de filtración de secretos; MTTR vulnerabilidad de reglas WAF ≤ 24h.

17) Lista de verificación de implementación

• Mapa arquitectónico: edge → BFF → mesh, lista de dominios/routs.
• TLS/mTLS, rotación JWKS, secretos en KMS/Vault.
• OAuth2/OIDC, scopes/claims, ABAC/OPA.
• Rate/quotas, circuit-breaker, retry/backoff, idempotencia.
• Validadores OpenAPI/JSON Schema, transformaciones gRPC/NAT/GraphQL.
• WAF/DDoS/bot profile, CORS/CSP.
• Seguridad Webhook: HMAC, anti-replay, allow-list.
• Registros/métricas/tracks; Auditoría de acceso/cambios.
• GitOps/policy-as-code; Las colocaciones canarias; Plan DR.
• Control PCI/GDPR: enmascaramiento, retenciones, procedimientos DSAR.

18) Errores frecuentes

Almacenar secretos en la configuración de gateway/logs.
Global "en CORS/confianza a todos 'Origin'.
Falta de idempotencia y tiempos de espera honestos → dobles y avalanchas.
Mezcla authN y lógica empresarial en los plugins de gateway.
No hay rotación JWKS y kid → llaves «pegadas».
La observabilidad sin correlación trace → ACR ciegas.

Resumen

La API Gateway no es solo un proxy inverso, sino una plataforma de política y seguridad en la que se mantiene el rendimiento, el cumplimiento y la monetización. Construye Zero-Trust, arregla contratos con circuitos, controla el tráfico a través de SLO, automatiza configuraciones a través de GitOps y policy-as-code. Entonces la pasarela se convertirá en un «borde» sostenible de su arquitectura, no en un cuello estrecho.