Gatekeeper

Põe um processo dedicado entre a internet e o core bancário: é a única porta publicada, autentica o canal, limita o tamanho, valida e limpa o payload, e só então repassa ao core com um segredo compartilhado. O core fica em redes internas, sem porta publicada, e recusa qualquer chamada sem o segredo — mesmo vinda de dentro. Use para backends que nunca podem ser alcançados da internet.

passos: 6
arquivos: 7
testes: 0
tecnologias: 5

Infraestrutura realTypeScriptBunElysiaPostgreSQLDocker

Cenário Relações Comparar

Baixar cartão

Cenário

O app do banco envia transferências pela internet. Só o gatekeeper escuta de fora; ele recusa canal desconhecido (401) antes de ler o corpo, corpo acima de 2 KB (413) e conta malformada (400, dizendo só o campo). Campos injetados como isAdmin são removidos antes do repasse. O core não tem porta no host, e dentro da rede interna responde 403 a quem não tem o segredo. O gatekeeper não está na rede do banco de dados: nem comprometido ele escreve lá.

Planta

Fluxo

5/5

5 passos — reproduza para seguir o fluxo

chamada
resposta ou assíncrono
falha
passo
toque num nó para focar
Outras plantas de fluxo

Como funciona

6 passos

Host dedicado valida antes de liberar.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

timingSafeEqual+1

Token Auth

01
onRequest confere o token do canal em tempo constante e o content-length, antes de qualquer parse; maxRequestBodySize cobre corpo sem tamanho declarado
02
O schema da transferência valida o corpo; o Elysia remove os campos não declarados antes do handler
03
Erro de validação sai como 400 { error: "invalid <campo>" }, sem expor o schema
04
O repasse leva x-gatekeeper-secret e timeout de 3 s; erro do core vira um 502 genérico
05
O core compara o segredo com timingSafeEqual (tamanho conferido antes) e valida o schema de novo
06
Três redes Dockerdmz com a única porta, gate entre gatekeeper e core, core entre core e banco — as duas últimas internal: true

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

O core nunca fica exposto, nem ao host
Rede isolada e segredo de aplicação: uma camada cobre a falha da outra
Limpeza e validação centralizadas antes do backend
Gatekeeper sem acesso ao banco limita o estrago se for comprometido

Custos

Um salto a mais de latência
O gatekeeper vira ponto crítico de disponibilidade
O schema precisa ser mantido nos dois lados
O segredo compartilhado exige rotação e gestão próprias

apps/security/gatekeeper

7 arquivos

src/

gatekeeper.tsCanal, tamanho, schema, limpeza e repasse com segredo e timeout
core_bank.tsCore: segredo em tempo constante, schema de novo e escrita no banco
schema_transfer.tsContrato da transferência usado pelos dois lados
secret_match.tsComparação de segredo em tempo constante
demo.tsdemoCliente externo: válida, campos injetados, malformada, sem canal, grande demais e acesso direto

src/config_core.ts, src/config_gatekeeper.ts, src/

config_demo.tsdemoConfiguração validada de cada processo

docker-compose.ymlinfraBanco, core e gatekeeper em três redes, só o gatekeeper publicado

Executar · com Docker

$ cp .env.example .env# variáveis de ambiente
$ bun install# dependências
$ docker compose up -d --wait# sobe PostgreSQL
$ bun run demo# roda o cenário
$ bun run test# integração contra o serviço real
$ docker compose exec gatekeeper bun -e "console.log((await fetch('http://core-bank:8705/transfers')).status)"# 403 sem o segredo
$ docker compose exec gatekeeper bun -e "await fetch('http://db:5432').catch((e) => console.log(e.code))"# sem rota para o banco
$

Isolamento visto de dentro do gatekeeper:

Requisitos: BunDocker
Sobe junto: PostgreSQL

Relações

Onde ele se encaixa

Mapa

Gatekeeper

Combina com3

Por que se relacionam

Combina com

Teste rápido

Qual destes combina com Gatekeeper?

Próximo projeto · Segurança & AuditoriaFederated Identity

Contatos

Gatekeeper