Defendendo Aplicações Contra Abuso Automatizado

seeded

Uma aplicação expõe uma API. Tudo o que a interface de usuário faz, um script faz — mais rápido, em lote e sem browser. Este capítulo é o relato da área sobre como uma aplicação web se defende do uso automatizado e adversarial: o formato das ameaças, a única verdade de causa-raiz que organiza toda defesa, o catálogo de controles (cada um com sua fraqueza honesta) e o modelo para compô-los numa postura de segurança configurável. É deliberadamente vendor-agnóstico; onde um mecanismo real é nomeado (WebAuthn, DPoP, mTLS, JA4, App Attest, Play Integrity, reCAPTCHA, Cloudflare Turnstile), ele é atribuído de forma genérica, como exemplo de uma classe de controle.

1. O ponto de partida incômodo

Uma aplicação web convencional desenha sua interface no browser e chama o próprio backend via API para trabalhar. Essa API é observável: a aba de ferramentas do desenvolvedor mostra cada requisição — URL, headers, cookies e corpo JSON — e todo browser moderno oferece "Copy as cURL", que reproduz uma requisição exatamente, fora da UI, a partir de um shell. Dali, poucas linhas de script a replayam, enumeram seus identificadores ou a disparam milhares de vezes.

Isso não é um ataque exótico. É a capacidade padrão de qualquer pessoa com login legítimo e alfabetização técnica comum. As consequências seguem direto:

A interface de usuário não é uma fronteira de segurança. É uma conveniência para humanos;
a API por trás é a superfície real, e ela é alcançável sem a UI.
Esconder a API — minificar rotas, embaralhar payloads, não documentar — não a defende. Só
eleva o esforço de descobrir o formato da requisição, que as ferramentas do desenvolvedor entregam de graça.
O ator mais perigoso é frequentemente autorizado. Um funcionário, prestador ou parceiro de
integração atual ou recém-desligado já detém uma credencial válida e conhece o domínio. Nenhum perímetro o barra, porque ele foi admitido.

Tudo neste capítulo decorre de levar esse ponto de partida a sério.

2. Taxonomia de ameaça

Abuso automatizado não é uma coisa só. Distinguir atores e vetores é o que permite ao defensor raciocinar sobre quais controles de fato mordem.

2.1 Atores, do menos ao mais perigoso

Automação externa grosseira — scanners, browsers headless, bots de credential-stuffing
atingindo a superfície anonimamente. Barulhentos, não-autenticados e os mais fáceis de detectar e limitar. A maior parte do "bot management" comercial é calibrada para este ator.
Sessão roubada / replayada — um atacante que capturou um cookie ou bearer token válido
(via "Copy as cURL", um log vazado ou uma máquina comprometida) e o replaya de outro device. Autenticado, mas não no device nem no fluxo originais.
Insider autorizado — um operador atual com credencial real, abusando do acesso que detém
legitimamente: lendo ou exportando muito além do que o trabalho exige, roteirizando operações em lote, agindo fora do fluxo pretendido.
Ex-insider — um operador recém-desligado cuja credencial, certificado ou chave de device
ainda não foi revogada. O mesmo conhecimento do insider, agora hostil, correndo contra a revogação.

A assimetria crucial: defesas probabilísticas de bot são feitas para o primeiro ator e ficam progressivamente mais fracas contra o último. Um humano autorizado, paciente, num browser real parece exatamente um usuário legítimo — porque é um.

2.2 Vetores

IDOR / URL-crafting — Insecure Direct Object Reference: o cliente fornece um identificador
de objeto (um id de registro, um número de conta) na URL ou no corpo, e o servidor o retorna sem checar se ESTE sujeito pode ver ESTE objeto. Enumerar ou adivinhar ids leva o atacante direto aos dados de outros tenants ou usuários, plenamente autenticado. Isso está consistentemente no topo (ou perto) das listas de risco de segurança de aplicação da OWASP (como Broken Object Level Authorization, BOLA/IDOR).
Replay de requisição — capturar uma requisição válida (token e tudo) e reemiti-la, de
outra máquina ou repetidamente, dentro da janela de validade do token.
Automação em lote / exfiltração — disparar uma leitura ou escrita legítima centenas ou
milhares de vezes para drenar dados ou executar ações em massa, mantendo-se individualmente "válido" enquanto o agregado é abuso.
Pulo de etapas de fluxo — chamar o endpoint final, consequente (exportar, confirmar,
transferir) direto, pulando as etapas de validação, consentimento ou revisão que a UI impõe entre telas. O backend, vendo só a chamada final, não sabe que o preâmbulo foi pulado. É uma espécie de abuso de lógica de negócio: explora a função legítima da aplicação, não um bug de memória.
Máquina-a-máquina (sem browser) — a API é chamada direto por cURL, uma biblioteca de
script ou uma integração, com nenhum browser presente. Este vetor é decisivo: toda defesa client-side (sensor JavaScript, CAPTCHA, score comportamental, sensor de device) está simplesmente ausente — o código que as rodaria nunca carrega.

O vetor máquina-a-máquina é o teste ácido de qualquer controle proposto. Se uma defesa só funciona quando o browser do atacante coopera executando seu JavaScript, ela não faz nada contra o caminho de maior risco.

3. A verdade central: ofuscação não é segurança

Três princípios organizam todo controle que segue.

3.1 Esconder o formato da requisição não é defesa

Minificar rotas, cifrar payloads na camada de aplicação, não documentar a API, embutir a lógica de chamada em código de cliente compilado — tudo isso é security by obscurity. Eleva o custo de descoberta, e contra um scraper casual isso tem valor. Mas contra o modelo de ameaça aqui — um adversário que lê a aba do desenvolvedor e copia a requisição — a obscuridade já está derrotada. Qualquer defesa que dependa do atacante não aprender o formato da requisição já nasce morta.

3.2 Causa-raiz: autorização por-objeto no servidor + validação de invariantes

O sintoma é "alguém scriptou a API". A causa-raiz é que *o backend confiou no cliente em vez de decidir o escopo por conta própria*. O único conserto de raiz é que toda requisição prove, no servidor, duas coisas independentes de como a requisição chegou:

Autorização por-objeto — ESTE sujeito (este usuário, neste tenant) tem permissão de tocar
ESTE objeto específico. Não "o usuário está logado", mas "este usuário exato pode agir sobre este registro exato". Aplicada no servidor, em toda leitura e escrita, usando a identidade autenticada — nunca um id, filtro ou flag fornecido pelo cliente. Segurança por linha/objeto (RLS) na camada de dados é a expressão durável disso: o escopo é aplicado na fonte da verdade, então uma checagem esquecida num handler não vaza entre tenants.
Validação de invariantes / consistência de estado — a operação precisa respeitar as
invariantes de negócio: estado válido, ownership, limites, transições de máquina-de-estado permitidas. O cliente pode mentir qualquer parâmetro que envia; o servidor precisa re-derivar a verdade. Um corolário poderoso é a técnica *"estado de UI impossível = sinal de adversário"*: se uma requisição afirma uma combinação de valores que a interface real jamais poderia ter produzido (uma etapa concluída que nunca foi iniciada, uma quantidade que o formulário limita abaixo, um campo que só um script preencheria), essa inconsistência é, por si, evidência de alta confiança de automação ou adulteração — o servidor a rejeita e pode disparar alerta. As restrições da UI, re-checadas no servidor, viram um detector.

A autorização por-objeto neutraliza IDOR/URL-crafting diretamente e deterministicamente: mesmo plenamente autenticado, mesmo com sessão válida, o backend recusa objetos fora do escopo do sujeito e recusa transições inválidas — e faz isso contra cURL puro, porque a checagem não depende de nenhum código client-side rodando.

3.3 Todo o resto é defesa em profundidade

Rate-limit, risk score, challenge, fingerprint, atestação — todos valiosos, mas todos são camadas sobre o piso, nunca substitutos dele. Pegam automação grosseira e sessão roubada, adicionam observabilidade e elevam o custo do abuso paciente. O que não podem fazer é substituir a autorização: um sistema cujo backend confia na URL não é salvo por nenhuma quantidade de bot-scoring na frente dele. Componha os controles; não confunda uma camada com o piso.

4. O catálogo de controles

Cada controle é descrito do mesmo jeito: como funciona, força, fraqueza honesta, *atrito para o usuário* e quando ligar. Os controles são agrupados pelo papel que exercem. Em todo o texto, "o piso" refere-se aos controles determinísticos e sempre-on de §4.1.

4.1 O piso determinístico

Não são opcionais e nenhum controle probabilístico os substitui.

Autorização por-objeto / RLS + validação de invariantes

Como funciona. Toda leitura e escrita checa, no servidor, se o sujeito autenticado pode
tocar o objeto-alvo (segurança por linha/objeto na camada de dados) e se a operação satisfaz as invariantes de negócio (estado, ownership, limites, transições permitidas). A verdade é re-derivada no servidor; nada vindo do cliente é confiável.
Força. Determinístico, auditável e independente de qualquer código client-side — funciona
contra cURL puro. Neutraliza diretamente IDOR/URL-crafting e adulteração de fluxo. É o único controle que conserta a causa-raiz em vez de inferir intenção.
Fraqueza honesta. Não limita o volume de ações legitimamente escopadas — um insider
abusando de dados dentro do próprio escopo autorizado passa. Exige disciplina de engenharia: todo endpoint precisa aplicar a checagem, e um único handler esquecido é um IDOR. Modelar invariantes de uma API rica é trabalho real e contínuo.
Atrito. Nenhum para o usuário; o custo é de engenharia.
Quando ligar. Sempre. É o piso.

Requisição assinada curta + nonce (anti-replay)

Como funciona. Cada ação sensível carrega um token de vida curta ligado ao contexto — um
nonce, um hash da requisição e um timestamp — verificado no servidor dentro de uma janela estreita e lembrado para não poder ser reusado. Opcionalmente o token é ligado a uma *ação esperada*, então um token emitido para uma operação é rejeitado em outra.
Força. Fecha a janela do "Copy as cURL": uma requisição capturada e replayada sem token
fresco ligado ao contexto falha. Determinístico e verificável no servidor.
Fraqueza honesta. Não impede replay dentro da mesma sessão válida e dentro da janela
do token — encurtar a janela é o mitigante. Exige estado no servidor (relógio e nonce store). Sozinho, não limita volume.
Atrito. Baixo; transparente quando implementado no SDK do cliente.
Quando ligar. Em toda ação sensível, ao lado dos controles de posse e volume.

Binding de posse: DPoP, token binding, mTLS / certificado de cliente

Como funciona. Ligar a credencial a uma chave que o atacante não consegue copiar. DPoP
(Demonstrating Proof-of-Possession) e token binding anexam a cada requisição uma prova de que quem chama detém uma chave privada específica, tornando um bearer roubado inútil sem a chave. Mutual TLS (mTLS) exige que o cliente apresente um certificado X.509 no handshake TLS; a borda o valida contra uma autoridade certificadora gerenciada. Quando a chave privada vive em hardware — um smartcard ou secure element, como nas PKIs nacionais tipo os certificados ICP-Brasil A3 — a chave nunca sai do device, e revogar o certificado (via CRL/OCSP) desliga instantaneamente um operador desligado.
Força. É a única classe de controle que ataca a raiz e não infere comportamento: um cookie
copiado sem a chave privada não completa o handshake nem a prova, e toda requisição fica atada à posse física. A revogação é imediata e autoritativa.
Fraqueza honesta. O custo é de ciclo de vida: emitir, distribuir, renovar e revogar
chaves por operador, mais disponibilidade de CRL/OCSP. Chaves em hardware exigem middleware no cliente que nem todo device suporta. Um certificado emitido como arquivo exportável em vez de atado a hardware perde a maior parte do valor anti-replay (o arquivo copia junto com o cookie). E o mTLS termina na borda: o salto borda→backend precisa carregar a identidade de forma não-forjável, ou o backend confia num header spoofável.
Atrito. Alto (ciclo de vida do cert; middleware de hardware) para mTLS; baixo para DPoP.
Quando ligar. Onde os operadores são um conjunto conhecido e credenciável — o piso de
posse mais forte para login e para o canal de API direta. DPoP/token binding é o substituto sem-browser quando mTLS é inviável.

Audit-log forense por tenant

Como funciona. Uma trilha imutável, por tenant, de quem / o-quê / quando / de-onde para
toda ação sensível — identidade, série do certificado, fingerprint, device-id, endpoint, volume, verdict de risco — correlacionada por trace id, alimentando métricas e alertas de anomalia.
Força. Torna o insider detectável e responsabilizável mesmo quando um controle
preventivo falha, e fornece a evidência para revogar um certificado ou desligar o acesso. Explicável e auditável — essencial em contextos regulados e governamentais. É o substrato de todo sinal probabilístico abaixo.
Fraqueza honesta. É detectivo, não preventivo — registra o dano já feito. A
cardinalidade tem budget, e dado pessoal nunca pode entrar na telemetria. Sem revisão e alerta configurados por cima, o log é só forense post-mortem.
Atrito. Baixo; transparente.
Quando ligar. Sempre. É parte do piso e o feeder do alerting (§6).

4.2 Atrito condicional — eleve o custo quando o risco justifica

Estes adicionam custo e devem disparar seletivamente, para não punir operadores legítimos de alta frequência.

Enforcement de sequência / máquina-de-estado de fluxo

Como funciona. Exigir que o cliente autenticado percorra a ordem legítima de chamadas —
o endpoint final é recusado a menos que as etapas pré-requisito tenham sido feitas, em ordem, dentro de uma janela. No servidor, é um guard de estado por sessão.
Força. Ataca diretamente o pulo de etapas de fluxo: disparar o endpoint consequente fora
de ordem é recusado mesmo autenticado. Fecha um atalho de URL que a autorização e o rate-limit, sozinhos, não cobrem.
Fraqueza honesta. Modelar e manter toda sequência legítima de uma API rica é trabalhoso
e frágil — apodrece conforme o produto muda. Um insider paciente pode *reproduzir a sequência inteira* via script (mais lento e caro, não impossível). Exige um identificador de sessão estável.
Atrito. Baixo para o operador legítimo, que segue o fluxo naturalmente.
Quando ligar. Só nos endpoints críticos (escritas irreversíveis, exportações,
confirmações), nunca em toda rota.

Rate + limites de volume/velocidade e caps anti-exfiltração

Como funciona. Dois mecanismos casados. Um baseline adaptativo por sessão aprende as
taxas normais de requisição por endpoint, atado à sessão autenticada (não ao IP), e sinaliza desvio; e caps absolutos impõem um teto duro de registros ou ações por janela ("no máximo N registros lidos por operador por hora"), independente de qualquer baseline.
Força. Atar à sessão em vez do IP é essencial onde muitos operadores legítimos
compartilham poucos IPs (um NAT corporativo ou municipal) — um limite por IP puniria todos juntos, enquanto um limite por sessão isola o abusador. O cap absoluto põe um teto direto no quanto um insider pode exfiltrar dentro do próprio escopo — a defesa de volume que a autorização por-objeto não dá.
Fraqueza honesta. Se o insider abre muitas sessões, um cap por sessão precisa ser atado de
volta ao mesmo ator (via posse ou perfilamento). Endpoints de baixo tráfego nunca acumulam baseline (usar um cap absoluto conservador). É reativo a volume: um abusador lento, abaixo do baseline e do cap, passa.
Atrito. Médio — mal calibrado, bloqueia operadores intensos mas legítimos, por isso todo
limiar deve rodar em modo log antes de modo block.
Quando ligar. Em toda surface de lote/exportação e no canal de API direta; sempre em modo
log primeiro, depois block.

Step-up auth baseado em risco

Como funciona. Uma elevação cirúrgica da autenticação, disparada por risco (um score
alto, um verdict de device caído, uma divergência de fingerprint) ou pela *sensibilidade da ação* (exportação em lote, primeira ação do dia). Exige uma prova de posse fresca — um passkey atado ao device (WebAuthn) ou uma aprovação por QR cross-device (aprovar no celular uma ação iniciada no desktop). É um gate pontual, não um challenge a cada clique.
Força. Atrito quase-zero no caminho comum (só dispara sob risco). O passkey *re-prova a
posse* no momento da ação sensível — um cookie roubado não completa a cerimônia WebAuthn. Preserva privacidade (sem tracking).
Fraqueza honesta. Contra um insider com o próprio device e passkey, o step-up passa —
ele é o detentor legítimo do fator. Encarece automação headless e mata sessão roubada; não impede abuso autorizado. Implementado como widget CAPTCHA DOM/JS, também falha em servir UIs nativas sem-DOM.
Atrito. Baixo (só em ações de alto impacto).
Quando ligar. Em ações de alto impacto e quando o score de risco justifica; nunca a cada
clique rotineiro.

4.3 Superfície estrutural

UIs sem-DOM / renderizadas em canvas

Como funciona. A interface é renderizada num canvas ou superfície GPU (WebGL, WebGPU,
WASM) em vez de um DOM HTML. Não há árvore HTML para inspecionar, não há fetch nomeado atado a um elemento rotulado, não há seletor CSS para um scraper prender; a lógica de chamada vive em código compilado.
Força. Eleva estruturalmente o custo de reconhecer e roteirizar a superfície: o vetor
"aprender a API pela aba do desenvolvedor" fica muito mais caro do que num app DOM clássico. É a maior alavanca estrutural anti-automação — uma propriedade da superfície, não um gate por-request.
Fraqueza honesta. Não é segurança por si. O tráfego de rede continua observável (o
cliente compilado ainda fala HTTPS com a API); um adversário determinado desmonta o cliente e reconstrói as chamadas. É obscuridade com custo maior, não uma barreira criptográfica — nunca substituto do piso de autorização. Seu valor real é atrasar e encarecer, e negar o caminho trivial das-ferramentas-do-desenvolvedor-ao-cURL.
Atrito. Zero (é a UI nativa).
Quando ligar. Onde já é a escolha nativa de renderização; documentar honestamente como
defesa estrutural, não gate.

4.4 Sinais probabilísticos — observar e pontuar, raramente bloquear sozinho

Estes alimentam um risk score e alertas. Por padrão não bloqueiam sozinhos; disparam step-up ou revisão humana.

Perfil comportamental / user-risk score

Como funciona. Um modelo por conta ao longo do tempo — devices, locais, rede, horários,
ritmo — mais um baseline populacional para cold-start, produzindo um risk score por login ou ação com desvio sinalizado. Produtos comerciais de defesa de identidade expõem labels de "conta e device batem" versus reasons de classificação como automação, *ambiente inesperado* ou padrão de uso inesperado — sinais distintos que não devem ser conflatados.
Força. É a camada que de fato morde o insider autorizado: "a conta é real mas o uso não
bate com o histórico" (device, geografia, rede ou velocidade atípicos — ex.: um operador que sempre usa uma máquina de repente disparando 500 operações por minuto de uma rede nova). Opera na identidade, não num sensor client-side, então sobrevive ao canal sem-browser via metadata observada no servidor. Um profile match defende uma sessão roubada usada de outra máquina.
Fraqueza honesta. Precisa de uma janela de aprendizado (cold-start), *gera falso
positivo* e produz sinais, não bloqueios automáticos. Um ex-insider reproduzindo o *próprio padrão normal, lento* passa. Uma frota homogênea (máquinas idênticas, uma rede) reduz seu poder discriminante.
Atrito. Baixo (passivo; só o step-up derivado tem atrito).
Quando ligar. Amplamente, em modo sinal, alimentando step-up e alerting.

Biometria comportamental + timing (bot-score client-side)

Como funciona. Um motor client-side coleta interação (mouse, teclado, scroll, touch,
timing) mais sinais de ambiente e produz um score de automação, muitas vezes normalizado a uma escala 0.0–1.0 ou 1–99. É o mecanismo por trás de scores CAPTCHA invisíveis (ex.: reCAPTCHA v3) e de scores de bot-management por ML.
Força. Atrito zero (passivo); pega automação grosseira/headless em escala; detecta
discrepância entre user-agent e comportamento. O conceito "prova de execução + fingerprint de ambiente" é relevante contra roteirização casual.
Fraqueza honesta. *Roda no cliente → é contornável e, decisivamente, ausente numa chamada
direta cURL/Postman* — exatamente o vetor do insider (o sensor nem carrega). Um humano legítimo que automatiza a própria interação genuína pontua alto (humano) — então não morde abuso autorizado. Depende de um runtime DOMJSCanvas, então não roda nativamente em superfícies sem-DOM. É uma caixa-preta proprietária (ruim para auditoria), e biometria comportamental é dado pessoal — mandá-la a terceiro é um problema de soberania e proteção de dados.
Atrito. Baixo (passivo).
Quando ligar. Baixo valor isoladamente contra o insider autenticado; útil só como sinal de
que o cliente não é o app oficial, o que é melhor resolvido por atestação ou tokens atados. Se usado, preferir um atestador de primeira parte emitindo prova-de-execução assinada, e nunca enviar telemetria biométrica a terceiro.

Fingerprint de device & TLS (canvasWebGLaudio, JA3/JA4)

Como funciona. Fingerprint de TLS faz hash do ClientHello do cliente (ordenação de
ciphers e extensões) num identificador estável. JA3 (2017) é o original; JA4 (2023) é um fingerprint em múltiplas partes (um prefixo legível mais hashes ordenados de ciphers e extensões) mais resistente à randomização e que cobre QUIC. Fingerprint de device adiciona traços de canvas, WebGL, audio e hardware. Ambos são passivos — não precisam de cooperação do cliente.
Força. Passivo, atrito zero e estável através de trocas de IP: pega o insider que *rota IP
mas usa a mesma ferramenta* (uma biblioteca de script ou browser headless tem um fingerprint característico distinto de um browser real). Seu melhor uso é cruzar com o user-agent: uma requisição que se diz "Chrome" cujo fingerprint TLS é de uma biblioteca de script é uma mentira que vale alertar. Fingerprints de TLS existem para qualquer cliente TLS, inclusive cURL direto — que é onde ajudam no canal sem-browser.
Fraqueza honesta. Spoofável — bibliotecas de impersonação clonam o fingerprint de um
browser real. Ausente sob TLS session resumption e onde a borda não vê o ClientHello. Fingerprints de device/canvas são instáveis (updates mudam o hash → falso positivo) e de baixa entropia numa frota homogênea. É um sinal probabilístico, nunca um gate.
Atrito. Baixo (passivo).
Quando ligar. Como defesa em profundidade e observabilidade (tráfego autenticado-como-
operador-X com fingerprint de biblioteca de script é um alerta). Nunca substitui binding de posse, e nunca é bloqueio sozinho.

Atestação de plataforma (App Attest, Play Integrity, atestação WebAuthn)

Como funciona. Ligar a sessão a um app e device genuínos com uma prova enraizada em
hardware. Plataformas mobile fornecem verdicts de integridade de device e app (ex.: chaves Apple App Attest no Secure Enclave; verdicts Android Play Integrity de integridade de app e device, alguns dos quais sinalizam risco de captura de tela, overlay ou controle remoto). A atestação WebAuthn prova que um passkey vive num autenticador genuíno. Um equivalente soberano usa a atestação de chave em hardware da plataforma diretamente, sem depender do serviço do vendor.
Força. O sinal mais forte do stack (enraizado na cadeia de boot / secure element),
resistente a bypass. Alguns verdicts *denunciam ferramentas de acesso remoto, overlays e gravação de tela* — as próprias ferramentas de automação remota. Atar sessão-a-device bloqueia uma sessão clonada rodando de outra máquina.
Fraqueza honesta. A atestação de plataforma cobre só apps mobile nos serviços do vendor
— nada em web/desktop, e acopla você àquele vendor. Não cobre o operador num browser desktop — justamente o vetor ferramentas-do-desenvolvedor/cURL. É contornável com esforço num device comprometido, e verdicts inconclusivos em devices legítimos causam atrito e falso positivo.
Atrito. Médio (um verdict falho bloqueia um device legítimo; exige app nativo).
Quando ligar. Alto para o canal mobile de operador; inútil para desktop/web (usar mTLS +
passkey lá). Preferir o equivalente soberano, self-hosted, a um serviço de vendor.

4.5 Controles detectivos — não bloqueiam, denunciam

Honeypots / honeytokens

Como funciona. Iscas plantadas para denunciar quem opera fora do fluxo legítimo: registros
falsos que nenhum operador legítimo tem motivo para acessar (honeypot); ids, tokens ou rotas atraentes que só aparecem para quem enumera ou lê o tráfego em vez de usar a UI (honeytoken); campos de formulário ocultos que só um script preencheria. *Tocar a isca é um evento de segurança de alta confiança*, praticamente sem falso positivo.
Força. Atrito zero e altíssima especificidade — um honeytoken tocado é evidência
quase-certa de reconhecimento ou automação, porque o operador legítimo, pela UI, nunca o vê. Excelente early-warning exatamente do comportamento do modelo de ameaça (enumeração, URL-crafting, replay de tráfego capturado), e barato de plantar.
Fraqueza honesta. Detectivo, não preventivo — sinaliza em vez de bloquear (embora uma
policy possa escalar um toque para bloqueio). Cobre só os caminhos onde a isca foi plantada. Um adversário que conhece o sistema pode aprender a evitar iscas conhecidas. Precisa de curadoria para as iscas nunca poluírem dados ou relatórios reais.
Atrito. Zero (invisível ao operador legítimo).
Quando ligar. Onde for barato, especialmente em superfícies de lista/leitura onde
enumeração é o risco; rotear um toque de isca direto ao alerting como evento crítico.

4.6 Borda & analytics

WAF / enforcement na borda

Como funciona. Um web application firewall na borda inspeciona e decifra o token de risco
ou atestação inline (sem round-trip ao backend) e aplica allow / deny / rate-limit / challenge / redirect por policy sobre os atributos do token; um baseline de ML sinaliza anomalias de camada 7, idealmente apontando qual atributo desviou e por quanto.
Força. Enforcement na borda — o backend nunca vê tráfego malicioso. Baixa latência
(token decifrado inline). Bans por taxa param enumeração em lote. Saída de anomalia que nomeia o atributo e o desvio é explicável, o que importa para auditoria.
Fraqueza honesta. Um challenge gerenciado reintroduz DOM/JS e não serve UIs nativas
sem-DOM. O baseline tem cold-start e falso-positiva picos legítimos. Seu valor *herda a qualidade do sinal subjacente* — um WAF é um ponto de enforcement, não uma fonte de verdade.
Atrito. Médio (mal calibrado, bloqueia tráfego legítimo).
Quando ligar. Alto como padrão de arquitetura: "identidade e score decididos numa camada,
ENFORCED na borda sem envolver o backend" é exatamente o que o abuso de lote/enumeração pede.

Alerting SIEM / UEBA

Como funciona. Um pipeline SIEM (Security Information and Event Management) / UEBA (User
and Entity Behavior Analytics) ingere a trilha de auditoria e os sinais probabilísticos, os correlaciona e alerta tanto sobre eventos consumados quanto tentados — não só "dado foi exfiltrado", mas "um objeto fora de escopo foi negado", "um replay foi rejeitado", "um cap foi atingido". A classe tentado é o ouro do early-warning: revela o adversário tentando, antes do sucesso.
Força. Transforma o piso detectivo em resposta em tempo hábil. Alertar sobre tentativas
(que o piso determinístico já bloqueia) revela reconhecimento que sistemas legados nunca reportavam. Roteamento por tenant deixa o time de segurança de cada org ver só os próprios eventos.
Fraqueza honesta. Fadiga de alerta é real — sem deduplicação e rollup, o volume afoga o
sinal. É detectivo. E carrega uma regra dura de privacidade: *nunca armazenar uma senha tentada em texto puro* — um evento de login falho registra um flag ("senha incorreta"), nunca o segredo tentado, e dado pessoal nunca entra na telemetria (um hash com sal, não reversível, só onde a correlação for genuinamente necessária).
Atrito. Nenhum (lado do backend).
Quando ligar. Sempre, sobre o piso de auditoria; é o consumidor de todo sinal acima.

5. O modelo de postura de segurança configurável

Uma defesa madura não é uma lista fixa de features "ligadas para todo mundo". É uma *postura ajustável por contexto*, e a área converge para uma estrutura em três partes.

Um catálogo de controles — o conjunto deduplicado e versionado do que o sistema sabe
fazer, cada entrada com categoria, força, fraqueza honesta e atrito (o §4 deste capítulo). O catálogo enumera; não decide.
Uma policy por contexto — uma policy declarativa que, para cada `(tenant, surface,
sensibilidade-da-ação)`, liga ou desliga controles e os parametriza por risco. Ela classifica o catálogo em determinístico sempre-on (o piso — autorização, posse, anti-replay, auditoria; nunca desligado, só reforçado), sinal probabilístico (coletado amplamente, alimentando score e alerta, sem bloquear sozinho) e atrito condicional (step-up, rate-limit agressivo, enforcement de sequência — disparado só quando sensibilidade ou score justificam).
Borda decide / backend escopa — a borda aplica checagens de token, score e certificado
inline sem envolver a origin, enquanto o backend faz a decisão de escopo que nenhum sinal de borda substitui. Uma requisição sensível só passa se satisfaz o piso determinístico e o tier condicional que a surface exige e não está bloqueada por um sinal probabilístico acima do limiar configurado.

Dois princípios operacionais completam o modelo. Log antes de block: todo limiar nasce em modo só-observação contra tráfego real e é promovido a bloqueio só depois de calibrar — chutar um limiar fixo derruba produção. E tier por sensibilidade: uma leitura de alta frequência roda o piso mais sinais passivos com nenhum challenge, enquanto uma exportação em lote roda o piso mais enforcement de sequência mais caps agressivos mais step-up obrigatório. Mesmo catálogo, postura diferente, escolhida por surface.

6. Alertar sobre o consumado e o tentado

Uma propriedade definidora de uma postura madura é alertar o time de segurança de um tenant sobre duas classes de evento:

Consumado — a ação indevida aconteceu (dado lido ou exportado fora do padrão, uma escrita
irreversível, um honeytoken tocado com sucesso). Prioridade forense máxima; entra na resposta a incidente.
Tentado (não consumado) — o piso bloqueou: um login falho, um replay rejeitado, um objeto
fora de escopo negado, um lote acima do cap bloqueado, uma sequência inválida. Esta classe é o ouro do early-warning — revela o adversário tentando, antes de qualquer sucesso. Sistemas legados quase nunca alertavam sobre uma tentativa bloqueada; uma postura madura alerta.

Alerting eficaz exige tiering (info / warning / critical, atado à policy da surface), agregação anti-spam (dedup e rollup por (ator, classe, surface) num alerta com contador — "47 tentativas fora de escopo pelo operador X em 5 minutos", não 47 alertas — com escalada por taxa), roteamento por tenant (o time de cada org vê só os próprios eventos; isolamento cross-tenant é dado) e um contexto forense carregando o mínimo necessário para agir — identidade pseudonimizada, série do certificado (sem chave), fingerprint, endpoint, volume, geo/ASN e um trace id para puxar a trilha completa — nunca o payload sensível em si, só ponteiros para o store auditado. E a regra dura merece repetição: um alerta de login falho nunca carrega a senha tentada em texto puro.

7. Limites honestos: o que contém um insider autorizado paciente

A honestidade mais importante da área é sobre o teto desses controles. Ranqueados contra o *insider autorizado, paciente e lento, agindo dentro do próprio escopo, de um browser ou app real*:

Controles client-side (score comportamental, sensor JavaScript, CAPTCHA) estão ausentes no
canal direto cURL/Postman e pontuam um humano legítimo-mas-automatizando como humano. Não mordem este ator.
Controles probabilísticos (perfilamento, fingerprint, baselines de rate) pegam a automação
e a sessão roubada, mas um humano reproduzindo o próprio padrão normal escapa por baixo.
Só três coisas de fato contêm o insider autorizado:
1. Escopo de menor privilégio — autorização por-objeto e invariantes (e caps de volume)
  limitam o que ele pode tocar e quanto, mesmo dentro do seu papel.
2. Auditabilidade e alerting — o log forense e os alertas de tentativa/consumação o tornam
  detectável e responsabilizável, transformando abuso silencioso em evento investigável.
3. Revogação — desligar instantaneamente o certificado, passkey ou chave de device de um
  operador desligado (CRL/OCSP) fecha a janela do ex-insider.

Nenhuma quantidade de bot-scoring substitui essas três. Vender defesas probabilísticas como barreira contra o insider paciente é desonesto; nomear *escopo + responsabilização + revogação* como a contenção real é a posição madura da área. O corolário para a arquitetura é direto: invista primeiro no piso determinístico e na revogação, e trate toda camada probabilística como defesa em profundidade e observabilidade por cima — nunca como o muro.

Ver também

stack-RFC-036 — Secure Surface & Tenant Security Alerting (cânone de engenharia da Koder
Stack): a decisão da Stack sobre como compor este catálogo numa postura configurável por tenant e por surface, e um pipeline de alerting multi-tenant. Ela cita este capítulo para o embasamento da área; este capítulo permanece vendor-agnóstico e não codifica nenhuma escolha específica da Stack (D6 — um fato, um home).
Parte VIII, 02-authorization-models (planejado) — os modelos de controle de acesso
(RBACABACReBAC, capabilities, segurança por-linha/objeto) por trás do piso de autorização.
Parte VIII, 03-authentication-and-identity (planejado) — WebAuthnpasskeys, OAuthOIDC,
token binding e PKI referenciados pelos controles de posse e step-up.