API security gateway: WAF e rate limiting na borda

1. Por que a borda é o lugar certo para segurança de APIs?

A borda da rede — o ponto onde o tráfego externo encontra sua infraestrutura — é o local estratégico para aplicar as primeiras camadas de defesa. Colocar segurança na borda reduz drasticamente a superfície de ataque antes que qualquer requisição maliciosa toque seu backend.

Quando você aplica WAF (Web Application Firewall) e rate limiting no gateway de borda, separa responsabilidades: o gateway vira um escudo dedicado, enquanto seus serviços internos focam em lógica de negócio. Ameaças comuns mitigadas na borda incluem:

  • Injeção SQL e XSS (bloqueadas por regras WAF)
  • Ataques DDoS em camada 7 (absorvidos por rate limiting)
  • Scraping abusivo de endpoints públicos
  • Tentativas de brute force em autenticação

Sem essa proteção na borda, cada requisição maliciosa consome recursos do seu backend — processamento, memória, banco de dados — aumentando custos e riscos.

2. WAF (Web Application Firewall) na borda: como funciona?

Um WAF inspeciona o payload das requisições HTTP/HTTPS em tempo real, comparando com um conjunto de regras de segurança. O padrão mais adotado é o OWASP Core Rule Set (CRS), que contém centenas de regras para detectar ataques como SQL injection, cross-site scripting (XSS), path traversal e injeção de comandos.

Os modos de operação típicos são:

  • Bloquear: nega a requisição se alguma regra for violada
  • Registrar: apenas loga a violação sem bloquear (útil para testes)
  • Aprender: modo que coleta dados para ajustar regras sem impacto

Para endpoints específicos, você pode customizar regras. Por exemplo, um endpoint /login pode exigir regras mais rigorosas contra brute force, enquanto /graphql precisa de regras específicas para consultas profundas.

3. Implementação prática de WAF com gateway

Vamos usar o Kong Gateway como exemplo. A configuração pode ser feita via código com decK (declarative Kong) ou API REST.

Exemplo de configuração declarativa para ativar o plugin owasp-crs:

_format_version: "3.0"
services:
  - name: minha-api
    host: meu-backend.internal
    port: 3000
    protocol: http
    routes:
      - name: rota-api
        paths:
          - /api
    plugins:
      - name: owasp-crs
        config:
          paranoia_level: 2
          mode: BLOCK
          rules:
            - id: 942100
              action: BLOCK
              description: "Bloqueia SQL injection clássico"
            - id: 941100
              action: BLOCK
              description: "Bloqueia XSS via script tags"

Essa política bloqueia automaticamente requisições com padrões de SQL injection (regra 942100) e XSS (regra 941100). Em produção, integre com logs para SIEM ou Slack:

# Exemplo de log estruturado enviado pelo Kong
{
  "timestamp": "2025-03-28T10:30:00Z",
  "client_ip": "203.0.113.42",
  "rule_id": 942100,
  "action": "BLOCKED",
  "uri": "/api/users?id=1 OR 1=1",
  "severity": "CRITICAL"
}

4. Rate limiting: proteção contra abuso e DDoS

Rate limiting controla quantas requisições um cliente pode fazer em um intervalo de tempo. Os algoritmos mais comuns são:

  • Token Bucket: permite bursts controlados, ideal para APIs com picos naturais
  • Sliding Window: conta requisições em uma janela deslizante, mais preciso que fixed window
  • Leaky Bucket: processa requisições em taxa constante, suavizando picos

As estratégias de limitação variam conforme o contexto:

  • Por IP: simples, mas vulnerável a ataques de múltiplos IPs (botnets)
  • Por chave de API: mais preciso, vincula ao consumidor autenticado
  • Por endpoint: endpoints críticos (/login, /checkout) podem ter limites mais baixos

Cuidado com falsos positivos: usuários legítimos podem ter bursts momentâneos. Use burst handling para permitir picos curtos sem bloquear.

5. Configurando rate limiting em gateways modernos

Exemplo com Kong usando o plugin rate-limiting:

plugins:
  - name: rate-limiting
    config:
      minute: 60
      hour: 1000
      policy: local
      fault_tolerant: true
      hide_client_headers: false

Isso limita a 60 requisições por minuto e 1000 por hora. O Kong retorna headers de feedback:

HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 42

Exemplo com Envoy usando o filtro envoy.filters.http.local_ratelimit:

http_filters:
  - name: envoy.filters.http.local_ratelimit
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
      stat_prefix: http_local_rate_limiter
      token_bucket:
        max_tokens: 100
        tokens_per_fill: 10
        fill_interval: 1s
      filter_enabled:
        default_value:
          numerator: 100
          denominator: HUNDRED

Quando o limite é excedido, o Envoy retorna 429 Too Many Requests com header Retry-After.

6. Monitoramento e ajuste fino das regras

Métricas essenciais para acompanhar:

  • Taxa de bloqueio: quantas requisições foram bloqueadas vs. permitidas
  • Falsos positivos: requisições legítimas bloqueadas incorretamente
  • Latência adicionada: impacto do WAF e rate limiting no tempo de resposta

Use Prometheus + Grafana para dashboards em tempo real:

# Métricas expostas pelo Kong
kong_rate_limiting_remaining{service="minha-api"} 45
kong_owasp_crs_blocked_total{rule_id="942100"} 127
kong_http_requests_total{service="minha-api", code="429"} 34

Estratégia de rollback: antes de aplicar novas regras WAF, teste em modo REGISTER por 24-48 horas. Use testes A/B com um subconjunto de tráfego para validar impacto.

7. Integração com Zero Trust e outras camadas de segurança

O gateway de borda não substitui outras camadas — ele as complementa. Em uma arquitetura Zero Trust, o gateway funciona como enforcement point:

  • WAF bloqueia ameaças conhecidas na borda
  • Rate limiting protege contra abuso de recursos
  • mTLS (mutual TLS) garante que apenas clientes autorizados se conectem
  • Autenticação e autorização (JWT, OAuth) validam identidade antes de chegar ao backend

Essa combinação cria segurança em profundidade: mesmo que uma camada falhe, a próxima ainda protege. Por exemplo, se o WAF não detecta uma variação de ataque, o rate limiting limita o dano, e a autenticação no backend bloqueia acesso não autorizado.

Em resumo, WAF e rate limiting na borda são práticas fundamentais para qualquer API exposta à internet. Eles reduzem a carga no backend, melhoram a resiliência contra ataques e permitem que sua equipe de desenvolvimento foque no que importa: entregar valor com segurança.

Referências