Skip to content

Gateway segmentado

1. Introdução

Nesta opção, um API Gateway (normalmente combinado com WAF) vira a porta de entrada única para todos os consumidores. Ele funciona como um “produto de APIs”: expõe conjuntos diferentes de rotas por consumidor e aplica políticas de governança antes de a requisição chegar no backend.

Exemplos típicos: - Parceiros só enxergam rotas de /partners/* - Superapp só enxerga rotas de /app/* (ou /superapp/*) - Webhooks entram por uma faixa isolada, com validação própria - Portais (cliente/corretor) entram com políticas específicas

Além de roteamento, o gateway pode aplicar: - rate limit e quotas por consumidor - autenticação e validação de credenciais (token/chave) - bloqueios e proteções (WAF) - auditoria e rastreabilidade centralizada - regras de exposição (quem vê o quê)

2. Visão estratégica

2.1. O que esta opção resolve

  • Centraliza governança e políticas de acesso: limites, bloqueios, autenticação primária e roteamento ficam padronizados em um único lugar.
  • Reduz rapidamente a superfície exposta do legado: mesmo que o backend ainda seja “grande e antigo”, o gateway consegue “travar” o que cada público enxerga.
  • Melhora controle para terceiros: parceiros e integrações externas passam a ter visibilidade e controle por consumidor (quota, chaves, logs e rastreabilidade).
  • Prepara terreno para evoluções futuras: depois, você pode trocar o backend por trás (API única, áreas, BFF) sem mudar tanto a borda.

2.2. O que esta opção não resolve sozinha

  • Gateway não substitui autorização real no backend: se o backend não validar vínculo/ownership e permissões corretamente, um erro de configuração no gateway pode virar incidente.
  • Complexidade de configuração pode explodir: regras detalhadas demais no gateway podem virar “inferno de configuração”.
  • Pode virar gambiarra de roteamento: se o backend não tiver contratos claros, o gateway vira o lugar onde se tenta “consertar” modelagem ruim com roteamento e exceções.

3. Visão de negócio

3.1. Benefícios

  • Parceiros com contrato controlado: fica mais fácil garantir que um parceiro só enxerga o que foi contratado (escopos, quotas, limites).
  • Resposta rápida a riscos e incidentes: dá para bloquear rotas, consumidores ou padrões de ataque no gateway sem deploy do backend.
  • Governança e auditoria por consumidor: excelente para “quem consumiu o quê e quando”, útil para compliance e gestão.
  • Facilita expansão de integrações: novas integrações podem ser habilitadas com chaves e políticas sem “abrir a API toda”.

3.2. Pontos de atenção para o negócio

  • É preciso tratar o gateway como produto:
    • cadastro de consumidores (parceiros, canais, integrações),
    • definição de contratos (escopos, quotas),
    • trilha de auditoria e SLAs por consumidor.
  • Mudanças de política no gateway precisam de governança (ex.: aprovação, versionamento, rollback), porque podem impactar vários consumidores ao mesmo tempo.

4. Fluxo de funcionamento

%%{init:{   "theme":"neutral",   "fontSize":22,   "flowchart":{"curve":"basis","htmlLabels":true,"nodeSpacing":50,"rankSpacing":70} }}%% flowchart TB   A["Consumidor faz requisicao<br/>internet"]:::ui_input --> B["WAF e Gateway<br/>porta de entrada unica"]:::ui_input   B --> C["Aplicar protecoes basicas<br/>bloqueios e limites"]:::ui_input   C --> D{Identificar consumidor}:::decision   D -- Nao --> E["Bloquear requisicao<br/>retornar 401 ou 403"]:::ui_button   D -- Sim --> F["Aplicar politicas do produto<br/>rotas quotas rate limit"]:::ui_input   F --> G{Politicas ok}:::decision   G -- Nao --> E   G -- Sim --> H["Validar credenciais<br/>token ou chave"]:::ui_input   H --> I{Credenciais validas}:::decision   I -- Nao --> E   I -- Sim --> J["Roteamento para backend<br/>por publico e rota"]:::ui_input   J --> K{Destino}:::decision   K -- API Unica --> L["Backend API Unica<br/>autorizacao interna"]:::ui_input   K -- Areas --> M["Backend por Areas<br/>cliente corretor app"]:::ui_input   K -- BFF --> N["Backends BFF<br/>cliente corretor superapp"]:::ui_input   K -- Parceiros --> O["Backend Parceiros<br/>contrato externo"]:::ui_input   K -- Webhooks --> P["Backend Webhooks<br/>entrada minima"]:::ui_input   L --> Q["Autorizacao por vinculo<br/>recurso e dados"]:::ui_input   M --> Q   N --> Q   O --> Q   P --> R["Validacao webhook<br/>assinatura idempotencia"]:::ui_input   Q --> S{Vinculo permitido}:::decision   S -- Nao --> T["Negar acesso<br/>retornar 403"]:::ui_button   S -- Sim --> U["Executar operacao no dominio<br/>contratos cobranca docs"]:::endpoint_post   U --> V["Registrar auditoria central<br/>gateway e backend"]:::ui_input   V --> W["Resposta para consumidor"]:::endpoint_get   R --> X{Webhook valido}:::decision   X -- Nao --> T   X -- Sim --> U   classDef endpoint_get     fill:#e0f2fe,stroke:#0284c7,color:#0f172a,stroke-width:1px;   classDef endpoint_post    fill:#dcfce7,stroke:#16a34a,color:#052e16,stroke-width:1px;   classDef endpoint_put     fill:#fef9c3,stroke:#a16207,color:#3b2f0b,stroke-width:1px;   classDef endpoint_delete  fill:#fee2e2,stroke:#ef4444,color:#7f1d1d,stroke-width:1px;   classDef ui_input   fill:#eef2ff,stroke:#6366f1,color:#111827,stroke-width:1px;   classDef ui_button  fill:#ede9fe,stroke:#7c3aed,color:#1f2937,stroke-width:1px;   classDef decision   fill:#fff7ed,stroke:#f59e0b,color:#78350f,stroke-width:1px;

5. Manutenção e longo prazo

5.1. Manutenção do código

  • Menos mudanças no backend para governança básica: muitas ações de bloqueio/limite/roteamento acontecem no gateway.
  • Risco de “duas fontes de verdade”:
    • gateway define exposição e política,
    • backend define autorização e regras reais.

Se não houver alinhamento, o time começa a “se perder” entre regra no gateway e regra no backend.

Boas práticas para manter sustentável:

  • Regras no gateway devem ser de borda (ex.: quotas, rate limit, roteamento, bloqueios, autenticação inicial).
  • Regras no backend devem ser de domínio (ex.: vínculo, ownership, permissões por recurso).
  • Versionamento e revisão de mudanças no gateway (evitar alterações manuais sem rastreio).
  • Pipeline de configuração (infra como código) para evitar “configuração na mão”.

5.2. Escalabilidade

  • Escala e resiliência centralizadas: gateway/WAF viram parte crítica (precisa HA, observabilidade e capacidade).
  • Controle fino por consumidor:
    • quotas por parceiro,
    • limites por canal,
    • proteção por rotas sensíveis.
  • Melhor controle de abuso: o gateway é o lugar ideal para cortar ataque de volume, scraping e tentativas de brute force antes do backend.

Ponto de atenção: - Se o gateway ficar muito pesado (muitas regras, validações complexas), pode virar gargalo. A regra é: gateway filtra, não processa negócio.

6. Adaptação ao legado do PASI

Essa opção é uma das mais eficazes para “ganhar controle rápido” quando existe legado com riscos altos (como endpoints públicos demais e autenticação fraca), porque o gateway consegue impor disciplina na borda mesmo antes de uma grande refatoração interna.

6.1. Caminho de adaptação recomendado

  1. Colocar o gateway na frente do legado
    • Centralizar entrada e evitar acesso direto ao backend.
  2. Inventariar consumidores e rotas
    • Definir quais rotas cada público pode enxergar (cliente, corretor, superapp, parceiros, webhooks).
  3. Bloquear legado perigoso por padrão
    • Fechar o que não deveria ser público (especialmente endpoints sensíveis que hoje estão expostos).
  4. Criar política forte para parceiros
    • Chaves por parceiro, quotas, rate limit, auditoria por consumidor, escopos claros.
  5. Tratar webhooks como área isolada
    • Assinatura, idempotência, validação de origem e limites agressivos.
  6. Endurecer backend em paralelo
    • Mesmo com gateway, revisar autorização por vínculo e remover AllowAnonymous indevido (o gateway não substitui isso).

6.2. Por que esta opção é boa para transição

  • Permite reduzir risco rapidamente (bloqueios e exposição controlada) sem depender de mudanças profundas no código legado.
  • É excelente para viabilizar parceiros com governança forte, mesmo antes de uma reescrita do core.
  • Mantém flexibilidade: dá para trocar a arquitetura por trás (API única, áreas, BFF) sem reinventar a borda.

7. Principais prós e contras

7.1. Prós

  • Centraliza políticas (limites, bloqueios, roteamento).
  • Excelente para parceiros (quota, chaves, auditoria por consumidor).
  • Ajuda a “travar” o legado rapidamente.

7.2. Contras

  • Gateway não substitui autorização correta no backend (se confiar demais nele, dá ruim).
  • Regras complexas no gateway podem virar “config infernal”.
  • Se o backend não for bem modelado, vira gambiarra de roteamento.

8. Quando esta opção faz sentido

  • Quando você quer governança forte para parceiros e controle de exposição rapidamente.
  • Quando existe risco alto no legado e você precisa reduzir superfície pública sem esperar uma refatoração completa.
  • Quando você quer uma borda única e controlada que sobreviva a mudanças internas de arquitetura.
%%{init:{ "theme":"neutral", "fontSize":22, "flowchart":{"curve":"basis","htmlLabels":true,"nodeSpacing":50,"rankSpacing":70} }}%% flowchart TB A[Venda de produto PASI]:::ui_input --> B{Venda via corretor<br/>ou direta}:::decision B -- Corretor --> C[Corretor participa da venda]:::ui_input B -- Direta --> D[Cliente contrata sem corretor]:::ui_input C --> E[Convenio e criado]:::ui_input D --> E E --> F[Convenio associado a apolice Icatu]:::ui_input E --> G[Convenio associado a cliente]:::ui_input F --> H[Convenio define CCT e modulos]:::ui_input G --> H H --> I[Primeira manutencao do convenio]:::ui_input I --> J[Gerar fatura da manutencao]:::ui_input K[Abertura do mes]:::ui_input --> L[Criar manutencao do mes]:::ui_input L --> M{Cliente enviou movimentacao<br/>no mes}:::decision M -- Nao --> N[Manutencao repetida<br/>status e valores repetidos]:::ui_input M -- Sim --> O[Receber relacao de segurados<br/>portal ou planilha]:::ui_input O --> P[Registrar log de importacao]:::ui_input P --> Q[Atualizar funcionarios no convenio<br/>tb_funcionario_v2]:::ui_input Q --> R[Atualizar manutencao do mes<br/>quantidades e valores]:::ui_input R --> S[Gerar ou atualizar fatura]:::ui_input N --> S J --> T{Fatura paga}:::decision S --> T T -- Nao --> U[Manter status de cobranca]:::ui_input T -- Sim --> V[Repasse para Icatu]:::ui_input V --> W[Comissoes por convenio<br/>tb_comissao]:::ui_input X[CCT alterada]:::ui_input --> Y[Atualizar modulos do convenio<br/>padrao ou adicional]:::ui_input Y --> Z[Impacta manutencao e fatura<br/>a partir da mudanca]:::ui_input AA[Segurado acessa canais]:::ui_input --> AB[Informar CPF]:::ui_input AB --> AC{CPF tem vinculo ativo<br/>em convenio}:::decision AC -- Nao --> AD[Acesso negado<br/>sem vinculo ativo]:::ui_button AC -- Sim --> AE[Buscar convenio e apolice do vinculo]:::ui_input AE --> AF[Resolver coberturas do mes<br/>modulos e coberturas]:::ui_input AF --> AG[Gerar certificado on the fly<br/>mes de referencia]:::ui_input AG --> AH[Exibir beneficios e documentos]:::ui_button %% estilos classDef endpoint_get fill:#e0f2fe,stroke:#0284c7,color:#0f172a,stroke-width:1px; classDef endpoint_post fill:#dcfce7,stroke:#16a34a,color:#052e16,stroke-width:1px; classDef endpoint_put fill:#fef9c3,stroke:#a16207,color:#3b2f0b,stroke-width:1px; classDef endpoint_delete fill:#fee2e2,stroke:#ef4444,color:#7f1d1d,stroke-width:1px; classDef ui_input fill:#eef2ff,stroke:#6366f1,color:#111827,stroke-width:1px; classDef ui_button fill:#ede9fe,stroke:#7c3aed,color:#1f2937,stroke-width:1px; classDef decision fill:#fff7ed,stroke:#f59e0b,color:#78350f,stroke-width:1px;