Seguridad en API Gateway: Autenticación, Protección de Amenazas y Endurecimiento

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

El API Gateway es el punto de entrada central para todo el tráfico de APIs. Si no está asegurado, tampoco lo están los servicios que hay detrás. Si está configurado correctamente, protege toda la infraestructura, desde la validación de autenticación hasta la protección contra bots.

¿Qué es la seguridad en API Gateway?

La seguridad en API Gateway comprende todas las medidas que protegen el gateway en sí y las APIs que lo atraviesan contra ataques, abuso y configuraciones incorrectas. Dado que el gateway es el único punto de entrada para tráfico externo, es el lugar ideal para aplicar políticas de seguridad de forma centralizada.

La capa de seguridad del API Gateway se divide en cuatro áreas:

1. Control de acceso: ¿Quién puede llamar a la API? (Autenticación y Autorización)
2. Control de tráfico: ¿Cuánto puede consultar un cliente? (Rate Limiting, Quotas, Throttling)
3. Protección contra amenazas: ¿Qué ataques se bloquean? (WAF, Bot Protection, Schema Validation)
4. Endurecimiento: ¿Cómo está protegido el gateway en sí? (mTLS, IP Whitelisting, Protección de Admin API, Audit Logs)

¿Quién utiliza la seguridad en API Gateway?

• Los Platform Teams configuran políticas de seguridad centralizadas para todas las APIs
• Los Security Engineers definen reglas de protección contra amenazas y supervisan ataques
• Los API Teams establecen requisitos de autenticación por endpoint
• Los DevOps Engineers endurecen la infraestructura del gateway (TLS, acceso administrativo, secretos)

¿Por qué es importante este tema en informática y para exámenes?

La seguridad en API Gateway es un tema central en certificaciones cloud (AWS Certified Security, Azure Security Engineer) y en el OWASP API Security Top 10. Los exámenes de IHK frecuentemente preguntan sobre autenticación centralizada frente a descentralizada. La decisión arquitectónica de centralizar la seguridad en el gateway reduce complejidad y fuentes de error, pero se convierte en un punto único de fallo si no está correctamente asegurado.

Conceptos clave en detalle

1. Autenticación centralizada en el gateway

El gateway realiza la autenticación para todas las APIs. El cliente envía su token (JWT, API Key, OAuth Access Token) al gateway. Este valida la firma del token, extrae los claims y reenvía la solicitud con headers enriquecidos al backend.

El flujo:

1. El cliente envía Authorization: Bearer <token>
2. El gateway valida la firma del token y su fecha de expiración
3. El gateway extrae los claims (User ID, roles, scopes)
4. El gateway reenvía la solicitud con headers como X-User-Id, X-Roles
5. El backend confía en estos headers (porque provienen del gateway) y ejecuta la lógica de autorización

Importante: La red interna entre gateway y backend debe ser confiable. Los headers no deben poder ser manipulados desde el exterior. En setups cloud, esto se logra mediante aislamiento VPC o mTLS.

Integración OAuth 2.0

El gateway puede actuar como OAuth Resource Server. Valida Access Tokens contra el Authorization Server (mediante introspection o verificación JWKS). Por cada endpoint se define qué scopes son requeridos:

• /api/orders — Scope orders:read para GET, orders:write para POST
• /api/admin/users — Scope admin:users

Gestión de API Keys

Para clientes B2B sin infraestructura OAuth, el gateway gestiona API Keys. Cada key está asociada a un consumer y tiene permisos específicos. El gateway puede rotar keys, revocarlas y asignar quotas.

2. Rate Limiting y Quotas

El rate limiting en el gateway es la primera línea de defensa contra el abuso. Se diferencia del rate limiting de un reverse proxy por su granularidad:

• Por Consumer: Cada API Key tiene su propio límite
• Por Endpoint: Los endpoints críticos tienen límites más bajos
• Por Combinación: Un consumer puede hacer 100 req/min globalmente, pero solo 10 req/min en /api/export
• Escalonado: Free tier 100 req/h, Pro tier 1000 req/min, Enterprise sin límite

Algoritmos:

• Fixed Window: Cuenta por ventana de tiempo (ej. 100 por minuto). Simple, pero permite ráfagas en los bordes de ventanas.
• Sliding Window: Ventana de tiempo deslizante, distribución más uniforme.
• Token Bucket: Un bucket se llena con tokens por unidad de tiempo, cada solicitud consume un token. Permite ráfagas mientras haya tokens.

Al exceder el límite: 429 Too Many Requests con header Retry-After.

3. Web Application Firewall (WAF) en el gateway

Una WAF en el gateway filtra solicitudes maliciosas antes de que lleguen al backend:

• SQL Injection: Bloquea patrones como ' OR 1=1 -- en parámetros de query
• XSS: Detecta y bloquea tags <script> en entradas
• Path Traversal: Bloquea ../../etc/passwd en rutas URL
• Command Injection: Detecta comandos como ; rm -rf / en parámetros
• Detección de anomalías: Tamaños de solicitud inusuales, combinaciones extrañas de headers

Las reglas WAF pueden ser positivas (whitelist: solo solicitudes conocidas como válidas) o negativas (blacklist: bloquear ataques conocidos). La mejor práctica es una combinación: whitelist para endpoints críticos, blacklist para tráfico general.

4. Validación de Schema

El gateway valida cada solicitud contra un schema OpenAPI:

• ¿Están presentes todos los campos obligatorios?
• ¿Son correctos los tipos de datos?
• ¿Están los strings dentro de la longitud permitida?
• ¿Son válidos los valores de enum?

Las solicitudes inválidas se rechazan con 400 Bad Request antes de llegar al backend. Esto protege al backend de errores por entrada inválida y reduce la carga.

5. Protección contra bots y detección de anomalías

• Detección de bots: Análisis de User-Agent, detección de navegadores headless, desafío CAPTCHA
• Análisis de comportamiento: Patrones de acceso inusuales (ej. 1000 logins en 1 segundo desde una IP)
• Geobloqueo: Bloquear solicitudes desde ciertos países
• Reputación de IP: Bloquear IPs conocidas como maliciosas (feeds de threat intelligence)

6. mTLS (Mutual TLS)

En mTLS, no solo los clientes se autentican en el servidor, sino que el servidor también se autentica en el cliente. Ambos lados presentan certificados. El gateway puede exigir y validar certificados de cliente, lo cual es más seguro que API Keys porque los certificados son más difíciles de robar y expiran automáticamente.

Uso: APIs B2B, comunicación service-to-service interna, industrias altamente reguladas (banca, sanidad).

7. Audit Logging y Security Monitoring

El gateway registra cada solicitud:

• Quién (ID del consumer, IP)
• Cuándo (timestamp)
• Qué (endpoint, método)
• Cómo (código de estado, latencia)
• Por qué se rechazó (qué regla de seguridad se activó)

Estos logs alimentan security monitoring (SIEM), alertas y auditorías de cumplimiento.

¿Por qué es importante la seguridad en API Gateway en la práctica?

Escenario 1: Credential Stuffing

Un atacante prueba 10.000 combinaciones de contraseña/correo robadas contra el endpoint de login. Sin rate limiting en el gateway, todas las 10.000 solicitudes llegan. Con rate limiting basado en consumer (5 intentos de login por minuto por IP), se bloquean 9.995.

Escenario 2: API Scraping

Un competidor escribe un bot que consulta el endpoint /api/products con alta frecuencia para hacer scraping de todo el catálogo. Sin quotas y detección de bots, obtiene todos los datos. Con token bucket limiting (100 req/min) y detección de bots (reconocimiento de navegador headless), el bot se bloquea.

Escenario 3: Exposición de servicios internos

Un servicio backend implementó accidentalmente un endpoint administrativo sin verificación de autenticación. Sin la obligación de autenticación en el gateway para todos los endpoints, el endpoint queda públicamente accesible. Con autenticación centralizada en el gateway, cada solicitud se autentica, incluso la del endpoint olvidado.

Ejemplo práctico: Configuración de seguridad en Kong API Gateway

Este ejemplo muestra una configuración de seguridad completa para Kong: autenticación JWT, limitación de tasa por consumer, CORS, restricción de IP, limitación de tamaño de solicitud y auditoría de logs. Se eligió porque integra los cuatro ámbitos de seguridad (control de acceso, control de tráfico, protección ante amenazas, endurecimiento) en una configuración declarativa.

# kong-security.yml
# Configuración de seguridad completa para un Kong API Gateway

services:
  - name: payment-api
    url: http://payment-service.internal:3000
    routes:
      - name: payment-route
        paths:
          - /api/payments
        methods:
          - GET
          - POST
          - DELETE
        strip_path: false

  - name: user-api
    url: http://user-service.internal:3001
    routes:
      - name: user-route
        paths:
          - /api/users
        methods:
          - GET
          - POST
          - PUT
        strip_path: false

plugins:
  # --- 1. CONTROL DE ACCESO ---

  # Autenticación JWT para todas las rutas
  - name: jwt
    config:
      secret_is_base64: false
      run_on_preflight: true
      maximum_expiration: 3600
      header_names:
        - Authorization

  # ACL para control de acceso basado en roles
  - name: acl
    config:
      allow:
        - admin
        - user
      hide_groups_header: false

  # --- 2. CONTROL DE TRÁFICO ---

  # Limitación de tasa: 100 req/min por consumer, 1000 req/h
  - name: rate-limiting
    config:
      minute: 100
      hour: 1000
      policy: redis
      redis_host: redis.internal
      redis_port: 6379
      limit_by: consumer
      fault_tolerant: true
      retry_after: true

  # Limitación de tamaño de solicitud: máximo 1MB de body
  - name: request-size-limiting
    config:
      allowed_size: 1000000
      size_unit: bytes

  # --- 3. PROTECCIÓN ANTE AMENAZAS ---

  # CORS: solo orígenes permitidos
  - name: cors
    config:
      origins:
        - https://app.example.com
        - https://admin.example.com
      methods:
        - GET
        - POST
        - PUT
        - DELETE
      headers:
        - Authorization
        - Content-Type
        - X-Request-ID
      credentials: true
      max_age: 3600

  # Restricción de IP: solo rangos de IP conocidas
  - name: ip-restriction
    config:
      allow:
        - 10.0.0.0/8
        - 192.168.0.0/16
        - 203.0.113.0/24

  # Transformador de solicitud: agregar headers de seguridad
  - name: response-transformer
    config:
      add:
        headers:
          - Strict-Transport-Security:max-age=31536000; includeSubDomains
          - X-Content-Type-Options:nosniff
          - X-Frame-Options:DENY
          - Cache-Control:no-store

  # --- 4. ENDURECIMIENTO ---

  # Métricas Prometheus para monitoreo de seguridad
  - name: prometheus
    config:
      per_consumer: true
      status_code_metrics: true
      latency_metrics: true

  # Auditoría de logs por HTTP Log Plugin
  - name: http-log
    config:
      http_endpoint: https://siem.internal/api/logs
      method: POST
      timeout: 5000
      keepalive: 30000
      retry_count: 3

consumers:
  - username: web-app
    acls:
      - group: user
    jwt_secrets:
      - key: web-app-key
        secret: ${WEB_APP_SECRET}

  - username: admin-panel
    acls:
      - group: admin
    jwt_secrets:
      - key: admin-key
        secret: ${ADMIN_SECRET}

// jwt-validation.js
// Ejemplo: Validación JWT con verificación de scope (Node.js)
// Así es como un plugin personalizado o backend complementaría la validación

const jwt = require('jsonwebtoken');
const jwksClient = require('jwks-rsa');

// Cliente JWKS para rotación de claves
const client = jwksClient({
  jwksUri: 'https://auth.example.com/.well-known/jwks.json',
  cache: true,
  cacheMaxEntries: 10,
  cacheMaxAge: 36000000
});

function getKey(header, callback) {
  client.getSigningKey(header.kid, (err, key) => {
    if (err) return callback(err);
    callback(null, key.getPublicKey());
  });
}

function validateToken(token, requiredScopes) {
  return new Promise((resolve, reject) => {
    jwt.verify(token, getKey, {
      algorithms: ['RS256'],
      audience: 'api.example.com',
      issuer: 'https://auth.example.com'
    }, (err, decoded) => {
      if (err) {
        reject({ code: 'INVALID_TOKEN', message: err.message });
        return;
      }

      // Verificación de scope: el token debe contener todos los scopes requeridos
      const tokenScopes = decoded.scope ? decoded.scope.split(' ') : [];
      const hasAllScopes = requiredScopes.every(s => tokenScopes.includes(s));

      if (!hasAllScopes) {
        reject({
          code: 'INSUFFICIENT_SCOPES',
          message: `Scopes requeridos: ${requiredScopes.join(', ')}`
        });
        return;
      }

      // El token es válido y tiene todos los scopes
      resolve(decoded);
    });
  });
}

// Middleware para Express
function requireScopes(...scopes) {
  return async (req, res, next) => {
    const authHeader = req.headers.authorization;
    if (!authHeader || !authHeader.startsWith('Bearer ')) {
      return res.status(401).json({
        error: 'UNAUTHORIZED',
        message: 'Bearer Token requerido'
      });
    }

    try {
      const decoded = await validateToken(authHeader.split(' ')[1], scopes);
      req.user = decoded;
      next();
    } catch (err) {
      const status = err.code === 'INSUFFICIENT_SCOPES' ? 403 : 401;
      res.status(status).json({
        error: err.code,
        message: err.message
      });
    }
  };
}

Información detallada

Endurecimiento del gateway: proteger el gateway mismo

El gateway en sí es una superficie de ataque. Las medidas de endurecimiento incluyen:

• Proteger la API de administración: La API de administración del gateway (por ejemplo, Kong Admin API en el puerto 8001) no debe ser públicamente accesible. Solo a través de VPN, VPC o localhost.
• Gestión de secretos: Los secretos (JWT secrets, API keys, TLS keys) no en configuración en texto plano, sino en Vault, AWS Secrets Manager o Kubernetes Secrets.
• Endurecimiento de TLS: Solo TLS 1.2 y 1.3, sin cipher suites antiguos, headers HSTS.
• Protección contra DDoS: Colocar Cloudflare o AWS Shield delante del gateway para protección contra DDoS volumétricos.
• Configuración como código: La configuración del gateway versionada en Git, cambios a través de CI/CD, sin modificaciones manuales en producción.

Zero Trust en el API Gateway

En el modelo Zero Trust, el gateway no confía en nadie. Cada solicitud se autentica, incluso las internas. Cada conexión está cifrada (mTLS). Cada solicitud se registra. El gateway no se considera parte de la red interna confiable, es parte de la línea de defensa.

Rotación de API Keys

Las API keys deben ser rotables. La mejor práctica incluye:

• Las keys tienen una fecha de vencimiento
• Rotación cada 90 días o ante sospecha de compromiso
• Período de gracia: la clave antigua y la nueva son válidas simultáneamente durante la migración
• Notificación automática al consumer antes del vencimiento

Headers de seguridad en el gateway

El gateway establece headers de seguridad centrales para todas las respuestas:

Monitoreo y alertas

El gateway debe activar alertas cuando:

• Aumentan abruptamente las respuestas 401/403 (posible ataque)
• Se superan los límites de velocidad (posible abuso)
• Hay tráfico inusual desde una IP o un consumer
• Las tasas de error del backend superan el umbral
• Se accede a la API de administración

FAQ: Seguridad del API Gateway

Continuación en la ruta de aprendizaje de APIs

El próximo artículo aborda API Gateway Patterns — patrones arquitectónicos como Backend for Frontend, API Composition, Protocol Translation y Aggregation, que se implementan en el gateway.

Fuentes y recursos adicionales

1. https://docs.konghq.com/hub/
2. https://owasp.org/API-Security/
3. https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-policies
4. https://docs.aws.amazon.com/apigateway/latest/developerguide/
5. https://www.cloudflare.com/learning/ddos/glossary/web-application-firewall-waf/

Libros recomendados para desarrollo de APIs

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert