System Design/05 - Reliability Patterns/Security2 min
Gatekeeper
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Uma instância dedicada valida e sanitiza toda requisição antes que ela alcance a aplicação e seus dados.
cliente → [ gatekeeper ] → aplicação → dados
valida, filtra,
sem credencial de acesso
A propriedade essencial: o gatekeeper não tem credenciais para acessar os dados. Se ele for comprometido, o invasor ganha uma máquina que não consegue ler nada — o dano fica contido.
O que ele faz
Validação de formato e tamanho, filtro de conteúdo malicioso (SQL injection, XSS), verificação de token, rate limit (Throttling), filtro de IP e geografia, e terminação TLS.
Na prática, esse papel é desempenhado por WAF, API gateway ou proxy reverso — ver Gateway Offloading.
Trade-offs
O ganho é reduzir a superfície de ataque da aplicação e conter o impacto de um comprometimento na borda.
Os custos são os de qualquer camada intermediária: mais um salto, mais latência, mais um componente crítico que precisa de redundância.
Há dois riscos específicos:
Falsa sensação de segurança. Se o serviço confia que o gatekeeper já validou, qualquer caminho que o contorne — rede interna, chamada de outro serviço, erro de configuração — é uma brecha. Validação na borda é uma camada, não a única: o serviço deve validar as próprias entradas, mesmo pagando a validação duas vezes.
Validação genérica não substitui validação de domínio. O gatekeeper checa formato, tamanho e padrões conhecidos de ataque. Ele não sabe que este usuário não pode acessar aquele pedido — isso é autorização de negócio e pertence ao serviço.
E há o custo de falso positivo: uma regra de WAF agressiva bloqueia usuários legítimos, e esse tipo de erro costuma ser descoberto tarde, porque quem é bloqueado raramente reporta.
Exemplo prático
internet → WAF (bloqueia SQLi, XSS, IPs suspeitos)
→ API Gateway (TLS, valida JWT, rate limit)
→ serviço (autorização de negócio, validação de domínio)
→ banco (acessível apenas a partir da rede do serviço)
Quatro camadas, cada uma com uma responsabilidade distinta. O WAF não sabe nada sobre usuários; o gateway não sabe nada sobre pedidos; o serviço não é alcançável de fora; o banco não é alcançável nem pelo gateway.
Comprometer o WAF não dá acesso a dado nenhum — que é exatamente o que o padrão pretende garantir.
Relacionado
Parte de Security · roadmap.sh/system-design