Design Resistente a Insider: UEBA, Resposta Autônoma e Auditoria Verificável

seeded

O Capítulo 01 terminou numa verdade incômoda: o insider autorizado paciente, agindo dentro do próprio escopo a partir de um navegador real, derrota todo controle probabilístico, e só três coisas o contêm — escopo, accountability, revogação. Este capítulo toma esse teto como ponto de partida e vai mais fundo. É o relato da área sobre os sistemas que se constroem *em torno* do piso determinístico quando o adversário já está dentro: analítica comportamental (UEBA), referências de objeto por capability, defesa centrada no dado (DLPwatermarktraitor-tracing), sinal anti-instrumentação, resposta automatizada (SOAR) com humano-no-laço, auditoria à prova de adulteração, governança de acesso do insider e a disciplina de medir a cobertura de detecção. Ao longo de tudo, uma honestidade se repete até virar reflexo: nada disso é gate sobre o insider autorizado — encurta a latência de detecção, encarece e produz prova. É deliberadamente vendor-agnóstico; mecanismos reais (Isolation Forest, DeepLog, códigos de Tardos, árvores de Merkle, DPoP, CAEP, MITRE ATT&CK) aparecem como exemplos de uma classe. Onde a Koder Stack toma uma decisão concreta de composição, ela vive no cânone de engenharia (stack-RFC-036, 19 controles C1–C19; stack-RFC-037, UEBA + SOAR + auditoria verificável), que cita este capítulo.

1. O problema que este capítulo herda

O capítulo anterior estabeleceu que a interface de usuário não é fronteira de segurança, que esconder o formato da requisição não é defesa, e que o conserto de raiz é a autorização por-objeto no servidor mais validação de invariantes — um piso determinístico que decide escopo pela identidade autenticada, nunca por id, filtro ou flag do cliente. Ele também nomeou o modelo de ameaça que organiza tudo aqui: o adversário autorizado. Concretamente, um operador atual ou recém-desligado — o "ex-prestador" — que já detém credencial válida e conhece a API, e que a abusa por um conjunto pequeno e bem-entendido de vetores:

V1 — IDOR / URL-crafting. Fornecer ou incrementar um id de objeto para alcançar registros que
a identidade não deveria ver. Dois subproblemas distintos se escondem aqui: enumeração (um espaço de ids adivinhável) e falha de autorização (o servidor honrar a referência sem checar escopo). Têm consertos diferentes; confundi-los é erro comum.
V2 — Replay de sessão via Copy-as-cURL. Capturar uma requisição válida, com token e tudo, e
reemiti-la de outra máquina ou repetidamente dentro da janela de validade do token.
V3 — Exfiltração em lote. Emitir um read legítimo centenas ou milhares de vezes para drenar
dado — cada chamada válida isoladamente, o agregado um abuso.
V4 — Pulo de etapa. Chamar o endpoint final consequente direto, pulando as etapas de
consentimentovalidaçãorevisão que a UI impõe entre telas.
V5 — Máquina-a-máquina (M2M) direto. Falar com a API sem navegador algum. O teste ácido: toda
defesa client-side está simplesmente ausente aqui.
V6 — Reconhecimento in-UI / DevTools. Usar dev tools, CDP, webdriver ou RPA para mapear a
surface e montar os outros vetores.
V7 — Adulteração anti-forense. Editar ou deletar a trilha de audit para apagar a prova de
qualquer um dos acima — o meta-vetor que ataca a própria accountability.

A espinha do capítulo é a contenção de três pernas do insider autorizado, e a partição honesta de cada técnica contra ele:

Escopo — menor-privilégio, autorização por-objeto (RLS) e caps de volume decidem o que a
identidade pode tocar e quanto, mesmo dentro do papel. É a única coisa que previne.
Accountability — uma trilha de audit à prova de adulteração + alerta tornam o abuso
detectável e imputável, convertendo mau-uso silencioso em evento investigável e provável.
Revogação — desabilitar na hora o certificado, passkey, refresh token ou chave de device de
um operador desligado fecha a janela do ex-insider.

Todo o resto deste capítulo — UEBA, SOAR, watermark, capability-URLs, anti-instrumentação — é defesa em profundidade sobre essas três pernas. Cada um ganha seu lugar por encurtar o tempo entre abuso e detecção, encarecer as variantes rápidas/scriptadas ou produzir prova. Nenhum é a parede. Dizer o contrário é a desonestidade específica que esta área deve recusar.

2. Escopo vs. accountability vs. revogação — o enquadramento

Vale precisar por que estas três, e só estas três, contêm o insider autorizado, porque a precisão dita onde cada técnica posterior pode e não pode ser vendida.

Escopo é a única perna preventiva. A autorização por-objeto imposta na camada de dado (row/object-level security) significa que uma query por um registro que a identidade não pode ver retorna nada — independentemente de qual URL, id ou capability o cliente apresentou. Caps de volume e taxa limitam a quantidade mesmo do acesso in-scope. Crucialmente, escopo é uma propriedade determinística: dado o sujeito autenticado e o objeto, a resposta é um sim/não fixo, plenamente explicável a um auditor. É por isso que escopo pode ser gate e um score probabilístico jamais.

Accountability é detetiva e atributiva, nunca preventiva. Uma trilha de audit verificável não impede o insider de ler o que está autorizado a ler; torna a leitura *um registro que não pode ser apagado silenciosamente*, para que o abuso seja provável depois. Seu valor é inteiramente condicionado a duas coisas que a própria trilha não garante: que o evento foi de fato emitido (completude) e que alguém vai olhar (propriedade operacional, não criptográfica). A Seção 9 trata ambas com honestidade.

Revogação endereça só a dimensão temporal do ex-insider: encolhe a janela em que a credencial ainda-viva de um operador desligado funciona. Sua eficácia é limitada pelo elo mais lento na vida da credencial — um access token auto-contido de quinze minutos de TTL não é revogável no meio da vida sem introspecção por-request, então "revogar" na prática é *revogar o caminho de refresh e os certificados, e contar com o TTL curto para o access token*. Esse é um gap real e declarado, não um problema resolvido (Seção 10).

O enquadramento produz uma prioridade arquitetural direta: *invista primeiro no piso determinístico e na revogação rápida; trate toda analítica, watermark e automação de resposta como observabilidade e atrito por cima.* O resto do capítulo é um passeio por esse "por cima" — cada técnica apresentada como a área a entende, embasada em como indústria e academia de fato a constroem, e fechada com o que ela não faz.

3. UEBA — User and Entity Behavior Analytics

User and Entity Behavior Analytics é a disciplina de construir um modelo estatístico do "normal" de cada ator e entidade, e então pontuar a atividade viva contra ele para revelar anomalias. No contexto de insider seu papel é estreito e honesto: *encurtar a latência de detecção das variantes rápidas, scriptadas ou fora-de-padrão do abuso, e produzir prova explicável* — nunca gatear acesso, que segue sendo tarefa do piso determinístico. A instância Koder é um engine self-hosted (o braço UEBA do stack-RFC-037, em services/ai/ueba), mas os conceitos abaixo são da área.

3.1 Baseline por peer-group vs. auto-baseline

A ideia fundadora, comum a todo produto UEBA sério (Splunk UBA, Securonix, Exabeam, Microsoft Sentinel UEBA), é que "normal" se define relativo a uma população de comparação. Dois baselines importam:

Auto-baseline — o ator comparado ao próprio histórico ("este operador nunca exportou antes da
meia-noite até hoje").
Baseline de peer-group — o ator comparado a outros no mesmo papel ou unidade ("enfermeiros
nesta UBS tocam ~40 registros por turno; este tocou 4.000").

A escolha de design crítica é como o peer-group se forma. A abordagem tentadora é aprender clusters do comportamento. A abordagem auditável — e a que uma implantação de setor público deve preferir — é derivar o peer-group de metadado declarado e autoritativo: papel, unidade, UBS, do sistema de identidade. Um grupo derivado é explicável ("este baseline é a mediana dos 23 operadores com papelenfermeiro em UBSCentro") e resolve o cold-start (um operador novinho herda o baseline do peer no dia um). Um cluster aprendido é uma caixa-preta que o auditor não interroga e que se move sob a própria influência do adversário. O engine Koder deriva a filiação de peer do metadado de identidade exatamente por isso.

As estatísticas de peer são computadas de forma robusta — mediana e *desvio absoluto mediano (MAD)* em vez de média e desvio-padrão, porque um punhado de insiders extremos, do contrário, envenenaria o próprio baseline que deveria pegá-los. O score robusto canônico é o z-score modificado z = 0.6745·(x − mediana)/MAD, cuja atribuição é exata: o score aponta a feature específica que cruzou o limiar.

3.2 A explicabilidade é uma restrição dura

Para uma auditoria de governo, "o modelo apontou" não é razão aceitável. Qualquer controle que possa disparar uma consequência precisa *enumerar suas razões em termos que um auditor humano confere*. Isso divide o zoológico de modelos em dois tiers:

Determinístico / exatamente-atribuível — z-score robusto, surpresa de transição Markov/n-grama,
Exact Data Match. Podem ser gatilho de resposta automatizada porque a razão é a feature ou transição exata que disparou.
Aproximadamente-atribuível — Isolation Forest, autoencoders, LSTMs de sequência. Detectores
poderosos, mas sua atribuição (via Local-DIFFI [Carletti et al., 2019], KernelSHAP ou pesos de atenção) é aproximação declarada, rotulada como tal, nunca vendida como verdade causal.

A regra dura, a que mantém verdadeiro o "sem ML opaco decidindo ato de governo": uma resposta automatizada irreversível, ou que restringe uma pessoa, exige as razões exatas de um modelo determinístico ou um humano no laço. Os modelos aproximados podem priorizar e alertar; jamais podem ser o gatilho único de ação irreversível. É precisamente a linha que os melhores produtos da indústria traçam — as "Smart Timelines" da Exabeam são pontuadas por razões enumeráveis por exatamente isso; o Google Chronicle é rules-first, ML-augment (YARA-L). A Darktrace é o contra-exemplo de cautela da área: matemática de peer-group excelente embrulhada em opacidade que um auditor público não aceita. A postura madura pega a matemática e recusa a opacidade.

3.3 O ensemble: do simples ao complexo, fusão transparente

Um engine robusto roda vários detectores em espaços de feature distintos e os funde *de forma aditiva ou por weighted-max*, nunca como produto opaco. Uma escada representativa:

M0/M1 — z-score robusto por peer-group (determinístico). O cavalo-de-batalha; exatamente
atribuível; o único membro autorizado a contribuir para um gate duro (e mesmo assim só via caps, não pelo score em si).
M2 — não-supervisionado multivariado — Isolation Forest (score = comprimento-de-caminho inverso
normalizado) ou autoencoder (erro de reconstrução, resíduo por-feature = atribuição). Pega anomalias multi-feature que limiar isolado nenhum pegaria.
M3 — modelos de sequência — surpresa de transição Markov/n-grama count-based
−log P(aₜ | aₜ₋ₖ…aₜ₋₁) (determinística, aponta a transição improvável = pulo de etapa), e opcionalmente uma LSTM tipo DeepLog [Du et al., CCS 2017] que sinaliza quando a ação observada cai fora das top-g ações-seguintes previstas.

Cada membro emite um sub-veredito nomeado e assinado com suas top-N features contribuintes. A discordância de modelo é ela própria sinal logado, nunca veto silencioso. A fusão por weighted-max é de alta sensibilidade, o que é aceitável só porque a postura é log-antes-de-block — o ensemble sobe alertas e, no máximo, atrito reversível; nunca auto-nega.

3.4 As famílias de feature são o modelo de ameaça tornado mensurável

As features são escolhidas para discriminar os vetores específicos:

Volume / velocidade (V3 exfiltração) — contagens e taxas em janelas rolantes.
Dispersão de objetos / entropia de ids / razão de caminhada sequencial (V1 IDOR/URL-crafting) —
um pico de objetos distintos tocados, ou uma caminhada suspeitamente sequencial por um espaço de ids.
Fração-UI vs. API-direta + presença de atestação de integridade do cliente (V5 M2M, V2 replay)
— um sinal que encarece o canal scriptado. Essa atestação roda no hardware do adversário e é forjável; sua ausência nunca é verdade de base. Replay e M2M são *contidos por escopo (RLS) e audit*, não pela atestação.
Coeficiente de variação do intervalo entre requisições (cadência robótica), hora fora-de-turno.
Divergência UA↔JA4, geo-velocidade, churn de device — sinais de origem de rede (Seção 4).
Surpresa de transição sobre n-gramas de ação + completude de etapa (V4). Note a divisão de
trabalho: impor uma etapa obrigatória é tarefa do guard de máquina-de-estado (controle estrutural, determinístico); o UEBA aqui só detecta o desvio, não impõe.

3.5 Cold-start e a armadilha da coorte pequena

Dois problemas distintos de dado esparso, com consertos distintos:

Cold-start — pouco histórico para um indivíduo. O conserto é um fallback hierárquico
indivíduo → peer → população → cap absoluto, com shrinkage empírico-Bayes puxando a estatística esparsa do indivíduo pro prior do peer com peso w = n/(n+k). Abaixo de um número mínimo de sessões, o ator fica log-only com cap absoluto. Nunca se infere "normal" de amostra vazia.
Privacidade de coorte pequena — um peer-group tão pequeno que seu baseline vaza o indivíduo. O
conserto é um piso de k-anonimato: uma estatística de peer só é publicada/usada acima de um tamanho mínimo de grupo n; abaixo dele, o baseline escala pro tier de população. É conserto de privacidade, não de acurácia, e é distinto do shrinkage.

3.6 Reprodutibilidade como invariante

Para a prova ser admissível, um veredito precisa ser reprodutível: versão de modelo + um *snapshot versionado das estatísticas de peer* (com o ruído de privacidade diferencial materializado, não re-sorteado) + o snapshot de feature + um hash da entrada devem permitir a um auditor re-executar a pontuação e obter o mesmo score. A sutileza que pega implementações ingênuas: se o ruído DP no baseline é regenerado no replay, o replay diverge e a reprodutibilidade é falsa. O ruído tem de ser persistido. O engine Koder registra, por veredito, o hash do vetor de feature, a versão do ensemble, a versão do snapshot de peer-stat e as atribuições, sob o store à prova de adulteração da Seção 9.

3.7 Preserva privacidade e é robusto a adversário por construção

Duas propriedades que a área cada vez mais trata como não-opcionais (a Seção 12 aprofunda):

Privacidade — sub-scores de integridade do cliente são computados na borda/device; só o
resultado sobe, nunca o stream comportamental cru. Baselines usam pseudonimização keyed por-tenant (HMAC, que sob a LGPD é pseudonimização, não anonimização — segue sendo dado pessoal) e privacidade diferencial (ruído Laplace/Gaussian, budget epsilon contabilizado por tenant, à la precedente TopDown do Censo US 2020) nas agregações de população. Nenhuma métrica de telemetria carrega o pseudônimo, um valor de feature ou uma atribuição — PII fora do plano de observabilidade.
Robustez — ensemble heterogêneo (evadir um membro não transfere), features *ancoradas no piso
não-forjável* (comportamento não falsifica escopo), um monitor de drift (PSI / KS / Jensen-Shannon) que rebaixa modelo driftado a log-only até revalidação humana, e a disciplina de *log antes de block*. Features que parecem server-side-caras de forjar (JA4, divergência UA↔JA4) são *caras, não impossíveis* de forjar — ferramental classe-uTLS derrota spoof preguiçoso mas não o adversário competente que alinha UA e JA4. O valor honesto é custo elevado, mais o piso determinístico fora do alcance da manipulação comportamental.

3.8 Embasamento industrial e limites honestos

As escolhas de design não são inventadas: peer-group + risco aditivo é o modelo Splunk UBA / Securonix; score reproduzível por-razões-declaradas é da Exabeam; baseline de uso de API por-principal é a lógica do AWS GuardDuty/CloudTrail (adotada sem o egress do dado); modelagem de sequência de chamadas é o Cloudflare API Shield; rules-first-ML-augment é o YARA-L do Chronicle.

Os limites, ditos claramente: o insider autorizado, lento, in-scope não é gated por UEBA — escopo + audit + revogação o contêm; o UEBA só encurta a latência de detecção e encarece as variantes rápidas/scriptadas. A qualidade do peer-group depende de metadado de papel limpo. A atribuição de M2/M3 é aproximada. Um adversário que conhece o modelo mimetiza comportamento normal. DP protege o indivíduo mas cega coortes pequenas (daí o piso de k-anonimato + tier de população). E a finalidade-limitada — que isto nunca vire vigilância de produtividade de funcionário — é garantia de governança, não da matemática.

4. Origem de rede como feature: reputação e impossible-travel

Um sinal barato, passivo e independente do cliente é de onde a requisição veio. Como não depende de o cliente executar nada, é um dos poucos sinais presentes no canal cURL/M2M (V5), onde CAPTCHAs e bot-scores simplesmente não estão. É sinal, nunca gate — a NAT municipal, sozinha, proíbe bloqueio duro por IP.

4.1 Um feed self-hosted de reputação e geolocalização

O invariante de soberania-e-privacidade é absoluto: *nenhuma resolução em request-time toca serviço externo*. Toda fonte — aberta ou licenciada — entra *exclusivamente como arquivo de snapshot baixado*, refrescado por agenda, nunca como chamada de API por-request. O IP do cidadão ou operador jamais deixa o perímetro. Um feed self-hosted (infra/net/krep na instância Koder) importa periodicamente fontes abertas — listas de saída Tor, Spamhaus DROP/EDROP, FireHOL Level 1, Team Cymru IP→ASN, PeeringDB (tipo de rede do ASN), espelho MaxMind GeoLite2 City+ASN — cada escrita produzindo um snapshot versionado (rollback) mais uma métrica de frescor com alerta de SLA. Adaptadores licenciados (as únicas fontes que rotulam um proxy residencial) são opcionais, atrás de flag de capability, e ingeridos como data-file baixado no mesmo caminho de snapshot, nunca como lookup SaaS ao vivo. Esse é o padrão geral de qualquer defesa self-hosted que precisa importar dado externo: refrescar periodicamente por design, nunca egressar por request.

4.2 Algoritmos

Resolução de origem — longest-prefix match numa radix-trie em memória construída *do snapshot
local*, hot-reload no bump de versão. Zero rede no caminho quente.
Classificação — ASN → classe (datacenter / cloud / VPN / Tor / proxy-residencial / residencial /
CGNAT-móvel / gov-conhecido / desconhecido) via tipo de rede PeeringDB e listas de hosting; Tor é conjunto exato de exit-IPs; VPN e proxy-residencial só de feed licenciado ingerido (senão unknown — sem chute).
Geo-velocidade (impossible travel) — haversine(atual, último-visto)Δt → kmh implícito. Emite
impossible_travel só quando: a velocidade excede um limiar (≈900 km/h) E o raio de acurácia é menor que a distância nos dois pontos E não é mesmo ASN nem handoff móvel E ambos não estão no allowlist de egress conhecido do tenant. Sem histórico, nunca emite — não se infere "normal" de amostra vazia.

O allowlist de egress conhecido do tenant (os CIDRs/ASNs da própria prefeitura) é o que converte um IP de ruído num baseline por-tenant.

4.3 O que morde, e o limite honesto duro

Morde o replay de sessão de outra máquina (V2) — mas só quando a origem de fato muda: um replay de datacenter ou VPN muda a classe de origem e pode disparar impossible-travel; um replay rodado *da mesma rede municipal* (o insider on-site) não muda nada e não dispara nada. Morde a automação em nuvem (V3). Sendo independente do cliente, cobre o canal cURL/M2M (V5).

Os limites são severos e precisam ser ditos: *a NAT municipal/CGNAT apaga o IP como discriminante intra-tenant* — o discriminante real é o par (conta × origem atípica), não o IP isolado. A geolocalização por IP é grosseira (cidade ~55–80%); CGNAT/VPN legítimo geram falso impossible-travel. Um proxy residencial é quase indetectável (só com feed licenciado, e ainda evadível rotacionando saídas na cidade-alvo). Tor é alto-sinal mas trivial de evitar. *Não contém o insider operando do IP legítimo da prefeitura com credencial válida* — esse é contido só por *escopo + accountability + revogação*. Nada aqui é segredo; um adversário informado evade ficando in-region em egress residencial. Entra no score como telemetria responsabilizável, jamais como barreira. (ATT&CK: T1078, T1090.002.003, T1583.003T1584, T1550.004, T1020T1119T1567.)

5. Defesa centrada no dado: DLP, watermark e traitor-tracing

Todo controle até aqui tenta restringir acesso. Mas a propriedade definidora do insider autorizado é que seu acesso é legítimo — ele tem direito de ver o prontuário que depois exfiltra. Contra esse ator o eixo tem de mudar de "impedir o acesso" para "responsabilizar o vazamento". Isto é defesa *centrada no dado: ela *marca, rastreia e encarece a exfiltração. É *detetiva / dissuasiva / atributiva — nunca gate* (com uma exceção estreita abaixo). Corresponde ao controle C17 do cânone Koder.

5.1 Três camadas, do visível ao forense

Overlay visível ladrilhado — um watermark semitransparente (nome do operador, código curto do
trace-id, timestamp) composto no servidor, no buffer de pixels que o operador vê. Dissuade foto-de-tela e é capturado em screenshot de quadro cheio. Não tem elemento de DOM para remover no DevTools porque o pixel é do servidor — alavanca estrutural de uma *UI server-side-rendered, sem DOM* (a surface Koder Kroma). Ainda pode ser recortado da região de dado, então é dissuasor, não garantia.
Watermark invisível robusto (só artefatos rasterizados) — um token opaco (nunca PII crua) embutido
em artefatos de pixel (PNG, PDF-raster) via espalhamento espectral no domínio DCT + códigos corretores (Reed-Solomon/BCH) + repetição ladrilhada, de modo que um crop de ≥1 ladrilho ainda decodifica. Um caminho de amadurecimento usa encoder treinado (classe HiDDeN/StegaStamp) para robustez a print→foto. A fronteira honesta: *exports estruturados (xlsxCSVJSON) não carregam watermark de pixel* — são dado já "redigitável" que qualquer re-sort normaliza — então esses são cobertos só pelas camadas de canário + Exact Data Match + audit, nunca anunciados como marcados.
Canário por-operador / traitor-tracing — o token é sorteado de um *código de fingerprint de
Tardos* [Tardos, 2003] por (tenant, operador, época), resistente à colusão de até c traidores: um documento colidido de várias cópias ainda acusa ≥1 contribuinte dentro do limite projetado. É a única camada que sobrevive ao insider que redigita ou parafraseia o dado (nenhum pixel sobrevive a isso) — e ainda assim só quando o canal carrega entropia suficiente (Seção 5.4).

5.2 Segurança de canário num sistema de saúde

Injetar um paciente falso num sistema de saúde é perigoso — pode virar consulta ou receita reais. Ordem de preferência: (a) o watermark do artefato; (b) *variantes clinicamente-inertes do dado verdadeiro* (ordenação de registros, espaçamento, metadado não-clínico) — *só se provado inerte por-dataset por construção, nunca presumido*, porque ordem de registro pode carregar sentido clínico (cronologia, prioridade) e é frágil (qualquer ORDER BY/re-export downstream normaliza); (c) um anel pequeno de pacientes sintéticos marcados por construção, admitido só se billing, dispensação e atendimento rejeitarem a flag por design. Canário nunca é dispensável nem faturável.

5.3 DLP com reconhecimento de conteúdo, mantido explicável

O data-loss-prevention inspeciona dois pontos de egress (o caminho de export e a borda). Fica determinístico e explicável: detectores de infoType BR (CPF, cartão CNS/SUS, RG, CEP, telefone com dígito verificador) mais Exact Data Match — um fingerprint com *HMAC de chave secreta rotacionável e selada* (não sal simples: CPF/CNS são espaços pequenos, enumeráveis por checksum, e um sal vazado tornaria o índice reversível) sobre o conjunto de ids de paciente conhecidos do tenant. Um match diz "este export contém 143 registros que casam com ids conhecidos" — explicável, *sem copiar PII em claro. Um classificador clínico de texto-livre pode rodar, mas *consultivo / log-only — nunca dispara BLOCK (o requisito de explicabilidade de governo), e como sua saída é *inferência sobre conteúdo de saúde do cidadão, ela vive *só no plano de audit por-tenant, nunca numa métrica de observe. Regra herdada: log antes de block; bloquear só em regra determinística de alta confiança (lote acima do cap) — a única aresta preventiva desta camada, e ela nada faz contra o insider lento, sub-cap e in-scope.

5.4 O envelope de robustez, dito com honestidade

Sobrevive: screenshot, JPEG q≳50, crop a ≥1 ladrilho, escala/rotação moderadas. Degrada: crop sub-ladrilho, downscale agressivo, print→foto de baixa resolução, filtragem adversarial. *Redigitar / re-sort derruba todo pixel e canal de layout/ordem.* Colusão além de c: a atribuição de Tardos degrada — declare o limite, não venda além dele. Tenant pequeno / canal de baixa capacidade: poucos operadores, ou um canal clinicamente-inerte de baixa entropia, não comportam um codeword de Tardos do comprimento exigido O(c² log(N/ε)), então a atribuição enfraquece ou c excede a população de operadores — declare quando o esquema não é aplicável. O overlay visível é o fallback quando o invisível falha; o canário é o único que sobrevive à redigitação, e só com entropia.

5.5 Limites honestos e a disciplina de Kerckhoffs

Detetivodissuasivoatributivo, não preventivo (exceto o bloqueio de lote-acima-do-cap, que nada
faz contra o exfil lento sub-cap). Ele marca e rastreia; não é gate.
M2M/API (V5) não renderiza pela UI → sem pixel; só DLP-egress + canário + audit cobrem.
OCR dos pixels do servidor extrai o dado — "sem DOM" tira o caminho de cópia barato, não a
extração.
Uma acusação de watermark/Tardos é pista investigativa com confiança, nunca prova por si — a
imputação vem do audit à prova de adulteração (Seção 9). Nunca venda um decodificador probabilístico como gate ou prova única.
Obscuridade não é segurança (Kerckhoffs): o esquema é público; a robustez vem de ECC + redundância
+ código de colusão + o backbone de audit determinístico — não de esconder o algoritmo. A chave HMAC-EDM é o único segredo, e sua perda só torna o índice reversível, não o resto.
Um falso positivo do DLP em export clínico legítimo pode ferir o atendimento → bloqueio
conservador. (Vetor primário V3; ATT&CK T1567, T1020, T1119, T1213, T1030, T1005; foto-de-tela aproxima T1052, tocado só por overlay + canário.)

6. Capability-URLs e referências de objeto moving-target

Uma capability-URL é uma referência de objeto que carrega a própria autoridade: um handle imprevisível e criptograficamente-protegido em vez de um id sequencial. Feita corretamente, *elimina a enumeração na raiz* — mas entender seu escopo exato é essencial, porque ela é rotineiramente sobrevendida como mecanismo de autorização, o que ela não é. É o controle C18.

A regra dura reiterada: a capability nunca é a autoridade. O servidor *resolve e revalida o escopo (RLS)* a cada uso. Isto não é segurança por obscuridade: o formato do token é aberto e verificável offline; a força vem de uma assinatura Ed25519 e uma chave AEAD (num KMS), não de esconder o esquema.

6.1 Um formato representativo

Sobre um formato de token assinado sem confusão de algoritmo (ex.: PASETO v4.public, Ed25519). Claims: sub = HMAC por-tenant do id de conta (pseudônimo, sem PII); obj = um handle cego AEAD(key_epoch, tenant‖tipo‖id, aad=sub); act (ações permitidas); um exp curto; um jti (id único); e um cnf ligando o token ao thumbprint do certificado mTLS ou à chave DPoP do apresentador.

6.2 Por que mata enumeração — e o que não mata

Nenhum id sequencial sai do servidor, então não há espaço a incrementar. O handle é um ciphertext AEAD stateless (o servidor decifra; não há tabela handle→id a roubar) e é subject-bound (aad=sub, então um handle roubado por outro principal falha a tag de autenticação). A propriedade moving-target é a rotação de época de chave: um handle de época N fica criptograficamente indecifrável quando a chave N expira (mantendo K épocas vivas para honrar o TTL-máx) — o link capturado *morre por construção*, não só "por política". Ganho marginal honesto: como as K épocas vivas cobrem o TTL-máx, essa morte criptográfica é backstop do check de exp, não um encurtamento independente da janela.

A ressalva de escopo-de-verbo é o cerne: isto mata a enumeração (o espaço de ids). Não mata o IDOR-como-falha-de-autorização. Uma capability válida, vazada ou compartilhada que resolve para um objeto fora do escopo é barrada só pelo escopo (RLS). Se o backend confia na capability sem revalidar escopo, um vazamento é um IDOR. Este é o limite (a) abaixo, e é a coisa mais importante a entender sobre a técnica.

6.3 Fluxo de resolução e single-use

(1) O cliente envia a capability num POST/header, nunca uma query GET (que vaza por logs e Referer). (2) A borda faz o gate estrutural (assinaturaexpcnf/rate) sem tocar o origin. (3) O SDK decifra o handle, confere sub contra o principal autenticado desta requisição, consome o jti se single-use, e revalida o escopo rodando a query sob RLS — RLS nega ⇒ nega, ignore o que a capability diz. (4) Um evento de audit verificável registra jti + id do objeto + decisão + trace id.

Single-use é um insert-if-absent atômico numa tabela cap_nonce_consumed(jti, …) com índice UNIQUE — mas isto só é correto se o insert for linearizável. Num store multi-região, um replay contra réplica stale antes da replicação pode furar o single-use; garanta insert linearizável ou declare a janela explicitamente.

6.4 Limites honestos

(a) Não é autorização — confiar na capability sem revalidar escopo transforma um vazamento em IDOR. (b) Inútil contra o insider dentro do próprio escopo — ele minta uma capability legítima; contenção é só escopo + audit + revogação. (c) A borda vê a capability para validá-la, então uma borda comprometida ou log mal-scoped a vaza — mitigado por redaction secret-class + TTL curto + single-use + cnf. cnf é opcional por API; uma capability sem cnf é um bearer puro, vivo até o TTL — daí cnf ser obrigatório para capabilities single-useexportsensíveis, para que um vazamento seja inerte sem o certificado ou a chave DPoP. (d) O transporte web depende de o browser honrar Referrer-Policy. (e) Single-use exige idempotency-key para não punir retry legítimo; TTL curto exige sincronia de relógio. Ela elimina a enumeração de V1 e (com cnf+TTL+single-use) limita V2/V5; não elimina o IDOR-como-falha-de-autz — ver (a). Sinergia com UI sem-DOM: nenhum id ou esquema chega ao cliente, fechando o recon via DevTools (V6) para ids de objeto.

7. Anti-instrumentação como sinal (nunca gate)

DevTools, o Chrome DevTools Protocol, webdrivers e frameworks RPA são o ferramental do reconhecimento in-UI (V6) — hoje em grande parte invisível ao defensor. O propósito de um coletor de integridade de cliente é tornar esse reconhecimento visível como telemetria, elevando o score de user-risk e disparando um alerta. É estritamente sinal, nunca gate. Não morde o insider autorizado; só escopo + audit + revogação o contêm. É o controle C19.

7.1 O coletor e seus reason-codes

Um coletor (no cliente web/WASM) emite um report com reason-codes determinísticos (sem ML opaco), cada um um bit low-trust:

DEVTOOLS_OPEN — armadilha de timing debugger, getter em console, delta de dimensão de viewport.
CDP_DETECTED / WEBDRIVER / HEADLESS_ENV — leak de Runtime.enable via getter de Error.stack,
navigator.webdriver, artefatos $cdc_, WebGL SwiftShader/llvmpipe, UA headless.
NATIVE_FN_TAMPERED — check de native-code via Function.prototype.toString em fetch/XHR. *Alto
falso-positivo* (extensões legítimas — ad-blocker, gerenciador de senha, a11y — fazem monkeypatch): peso baixo, exige corroboração, nunca dispara sozinho.
NONHUMAN_CADENCE — entropia de timing de input (pega RPA em browser real). *Só o reason-code é
emitido; a série de timing bruta nunca sai do cliente nem é armazenada* — é biometria comportamental e re-identifica (Seção 7.4).
EXEC_PROOF_ABSENT — um atestador WASM assinado do cliente oficial não completou um
challenge-response. Pontuado só na surface oficial onde a prova é garantida; em web genérica, ausência = navegador antigo / WASM bloqueado / CSP, então não é pontuado — ausência de sinal nunca é segurança.

7.2 A regra de ouro da assimetria de confiança

O report é dado controlado pelo atacante; entra como low-trust. Só sinais auto-incriminatórios têm peso (o atacante não reporta o próprio DevTools aberto; o operador curioso sim), e só quando corroborados no servidor — a borda carimba JA4TLS, IPASN/geo, origin. *A magnitude do score vem dessa verdade-de-servidor, jamais de número afirmado pelo cliente.* Um campo confidence afirmado pelo cliente não existe no scoring; um HMAC de sessão só liga o report à sessão (anti-replay), não eleva confiança porque a chave está no cliente. "O cliente diz: sem DevTools" vale zero.

7.3 Nunca bloqueia; e é ausente no canal API por design

O alcance máximo é um alerta mais rungs SOAR reversíveis R0–R2 (Seção 8). Bloquear DevTools é hostil e inútil — não se faz. No canal M2M/cURL o coletor nem carrega; sua ausência é esperada, não suspeita. Ali a defesa é escopo + binding de posse + capability-URLs, não este sinal.

7.4 Limites honestos e transparência obrigatória

Trivialmente evadível (não abrir DevTools; usar undetected-chromedriver/nodriver; ou falar direto com a API) — gato-e-rato admitido onde truques específicos morrem. Cego no canal M2M (o caminho honesto do insider). Não morde o insider autorizado em browser real a ritmo humano — aqui é early-warning/dissuasão, não barreira. exec-proof prova execução, não humano (RPA no cliente oficial passa). NATIVE_FN_TAMPERED/WEBDRIVER têm falso-positivo legítimo (extensões, RPA de dados sancionado) → daí R0–R2, nunca gate. No lado LGPD: cadência de input é biometria comportamental — *dado sensível que re-identifica mesmo sob pseudônimo* — então é computada edge-side, o timing bruto *nunca é transmitido nem armazenado, a finalidade é *só-segurança (nunca perfilamento de produtividade), a retenção é definida, e a transparência é obrigatória (Art. 6 e 38): o operador é informado de que há monitoramento de client-integrity e de sua finalidade de segurança, com RIPD/DPIA documentado. As heurísticas de detecção podem ficar secretas (isso é segurança, não direito do titular); a existência do monitoramento não pode (vigilância encoberta de empregado seria ilícita). A dissuasão soft não é vendida como proteção — obscuridade não é segurança.

8. Resposta autônoma: SOAR com humano no laço

Detecção sem resposta é um relatório que ninguém lê a tempo. *Security Orchestration, Automation and Response* (SOAR) transforma um veredito em ação sob o modelo proposta → execução → prova. A instância Koder vive em infra/observe, atua via adaptadores capability-scoped por-tenant nas camadas de borda / identidade / dado, e reporta de volta no pipeline de alerta do tenant. Herda *log antes de block*.

8.1 A escada reversível-primeiro

O princípio industrial central: ações reversíveis automaticamente, ações irreversíveis com humano. A Cloudflare e a Akamai não "bloqueiam" — sobem um degrau barato e reversível (challengetarpitdelay) antes da negação dura; a AWS liga finding → EventBridge → runbook com um estado de aprovação humana antes de qualquer coisa destrutiva; CAEP/SSF (Continuous Access Evaluation Profile) propaga uma revogação em segundos, não no expiry. Uma escada representativa:

Rung	Ação	Gate	Reversão
R0	log + alerta	auto	—
R1	throttle da sessão	auto	auto-lift por TTL
R2	step-up forçado	auto	reversível
R3	quarentena de sessão (+ sinal CAEP a todos os resource servers)	auto + notifica afetado	auto-lift por TTL
R4	suspensão de credencial	HITL por default; auto só com opt-in explícito do tenant E fora de encontro ativo → então revisão pós-fato com SLA	reversível
R5	revogação de certificado / passkey (push CRL/OCSP)	HITL pré-ação, dois-humanos, step-up	não-trivial

Dead-man / auto-lift: toda ação reversível expira sozinha se o caso não for renovado — nunca há penalidade permanente silenciosa.

8.2 Humano-no-laço, LGPD Art. 20 e o care-safety interlock

Rungs que restringem uma pessoa identificável (R3 quarentena, R4 suspensão) são *decisões automatizadas que afetam o titular* sob a LGPD Art. 20 → o afetado é notificado e tem direito a revisão humana. A reversibilidade + auto-lift + revisão são a salvaguarda do Art. 20, não um extra opcional. Os rungs irreversíveis (R5, e R4 por default) só propõem: montam um dossiê (veredito explicável + trilha) e criam tarefa de aprovação com N-de-M, timer de SLA, e a própria aprovação step-up-autenticada e auditada. Estourou o SLA sem aprovação, o default é seguro — mantém o rung reversível vigente, nunca auto-escala pro irreversível. Desligar um operador de saúde sem humano é *vetor de DoS por falso-positivo* — inaceitável por default.

O care-safety interlock é a regra domínio-específica mais afiada: com atendimento de paciente ativo, nunca auto-R4/R5 — e como uma quarentena (R3) no meio da consulta já disrupta o cuidado, o interlock degrada para R2 + alerta (step-up não-disruptivo); R3-ou-acima só pós-encontro ou via HITL. Playbooks são por-tenant, versionados (WORM), editados sob dois-humanos, e dry-run simuláveis contra trilhas reproduzidas (Seção 11) — reportando o que cada rung faria sem atuar.

8.3 A máquina-de-estado do caso e o ledger de ação

Um caso de resposta roda uma máquina-de-estado guardada: proposed → active → under_review → confirmed | rolled_back | expired → closed; uma transição ilegal é violação de invariante → deny duro + crítico. Cada rung grava num ledger de ação append-only, hash-chained (reusando a Seção 9): {actor, target, rung, verdict_snapshot, trace_id, ttl, rollback_token, approvers}, idempotente por (case, rung). É o registro probatório da própria resposta.

8.4 Limites honestos

O SOAR só age no detectável — contra o insider lento in-scope ele adiciona nada sobre escopo + audit + revogação; a escada é evadível por adversário paciente low-and-slow, e o piso determinístico é o que morde. Automatizar o irreversível é arma de DoS (daí HITL + reversível-primeiro + interlock). O motor SOAR é ele próprio um ator privilegiado (adaptadores capability-scoped, edição dois-humanos, ledger hash-chained, governado pela policy de acesso do insider). Thresholds não são segredo-como-defesa — concealment não é segurança. CAEP é quase-instantâneo, não instantâneo, e R5 via CRL/OCSP fica limitado pelo TTL de cache do OCSP/CRL — sem parear o sinal CAEP de revogação de sessão com certificados de vida curta / OCSP must-staple, um certificado revogado é aceito até o cache expirar. HITL vale o quanto vale o humano (rubber-stamp às 3h — mitigado por dois-humanos + dossiê explicável, não eliminado). E o ledger comportamental é dado pessoal sensível: finalidade-limitada, retenção definida, nunca repurposed como monitor de produtividade/RH, ancoragem Merkle in-soberania (sem transparency log SaaS cross-border). (D3FEND Credential Revocation, Session Termination, Auth Cache Invalidation; ATT&CK T1550T1078T1119T1567T1087T1213T1592.)

9. Auditoria verificável, à prova de adulteração

A accountability repousa inteiramente numa trilha de audit que não pode ser alterada silenciosamente — inclusive pelo próprio administrador (root/DBA) que roda o banco. O enquadramento duro e honesto: não se PREVINE que um root edite um log que ele administra — torna-se DETECTÁVEL publicando um compromisso (um hash) num domínio de confiança que esse mesmo administrador não controla, o mais cedo possível, para que uma edição posterior não passe silenciosa. Sem ancoragem externa, criptografia de log é decoração. Este é o design detalhado por trás do controle C15.

9.1 Hash-chain append-only

Cada evento carrega um seq monotônico, um prev_hash e entry_hash = SHA-256( JCS(evento_sem_hashes) ‖ prev_hash ), canonicalizado com RFC 8785 para que todo produtor emita bytes idênticos. Editar ou remover um elo quebra todos os entry_hash seguintes. O enforcement é estrutural: o papel de app tem só INSERT; um trigger rejeita UPDATE/DELETE. *Pré-condição de corretude: como cada hash depende do elo anterior, o append é um *single-writer por tenant — sob inserção concorrente/em lote (justo o cenário de exfil) dois writers lendo o mesmo prev_hash bifurcam a cadeia; serialize o append (lock consultivo per-tenant ou fila) e aceite esse custo de liveness como parte do contrato. Nota: uma sequência de banco não é gapless (rollback/cache deixam buracos benignos), então um gap de seq não é, por si, adulteração (a Seção 9.6 desambigua).

9.2 Integridade não é completude

O hash-chain prova que nada foi alterado depois de logado — não prova que tudo foi logado. Por isso o evento de acesso é emitido na mesma transação do read/write guardado por RLS (log-on-access): não se faz o acesso pelo caminho enforçado sem o log existir. Dois limites duros: (a) a completude cobre *só o caminho de policyapp* — uma leitura *físicaout-of-band* de um DBA abaixo da camada de policy (um SELECT cru) não dispara o log-on-access e não deixa rastro aqui; isso é problema de controle at-rest e de governança de acesso, não de Merkle; (b) remover a chamada de emissão via acesso a código/deploy derrota a completude silenciosamente — o evento nunca ganha seq, então não gera gap (não confundir com deleção, que gera). Completude é propriedade operacional do caminho não-contornável, não garantia criptográfica.

9.3 Checkpoints de Merkle e Signed Tree Heads

A cada janela (por-minuto ou por-10k eventos) um checkpointer monta uma árvore de Merkle RFC 6962 sobre os entry_hash de folha em ordem de seq e grava um Signed Tree Head (STH): audit_checkpoint(tree_size, root_hash, prev_root, signature). A chave de assinatura vive num KMS, fora do domínio do DBA (separação de deveres: o DBA corrompe linhas mas não forja um STH válido). Roots encadeados (prev_root) suportam uma prova de consistência (append-only entre dois checkpoints) e uma prova de inclusão (um evento sob uma raiz, O(log n)).

9.4 Ancoragem externa — a defesa real, self-hosted primeiro

Em camadas: (1) STHs espelhados num *log de transparência Koder em hostorgtenant administrado separadamente* — LGPD-safe, já que só root-hash + assinatura saem, nunca eventos; (2) witness cosigning (modelo Sigsum / Go checksum-db): ≥2 testemunhas contra-assinam cada STH — mas independência é tudo: num deploy soberano de operador único, testemunhas que o mesmo root administra são teatro. A testemunha naturalmente independente aqui é o regulador / controlador de dados (a autoridade de saúde) como entidade jurídica distinta rodando um nó-testemunha — cruzando uma fronteira de confiança real sem SaaS de terceiro; (3) opcionalmente, por tenant, um timestamp público de última instância (RFC 3161 TSA / OpenTimestamps → Bitcoin) do super-root diário — a única peça não-self-hostable (dependência permanente de terceiro): só 32 bytes não-pessoais cruzam a fronteira, dando um "existiu-até-T" impossível de retrodatar. Nunca é o piso default (o quórum de testemunhas + host separado carregam o default); é escolha de policy por-tenant.

9.5 WORM e erasure

Segmentos selados de checkpoint + lotes de eventos sob object-lock/compliance-mode ou mídia offline, sob retenção legal. Honesto: WORM em software é tão forte quanto quem o reconfigura — contra o insider privilegiado que modelamos, WORM no mesmo cluster é lombada; a âncora externa é a garantia. A purga de retenção é evento append (um tombstone) + crypto-shredding do dado subjacente, nunca um DELETE silencioso — uma erasure LGPD não pode parecer adulteração, e a âncora segue validando a estrutura (agora shredada).

9.6 Verificador sob demanda

Um verificador (kaudit no SDK Koder) é rodável por um auditor com acesso read-only (independência é o ponto): verify recomputa a cadeia e cada root contra o STH assinado + cosignatures + âncora externa; prove <seq> emite uma prova de inclusão; consistency <A> <B> prova append-only entre checkpoints. Ele desambigua gaps de seq: um buraco benigno de sequência (sem quebra de cadeia adjacente) ≠ uma deleção (mismatch de entry_hash a jusante); só o segundo é adulteração, e um gap não prova que todo evento foi emitido (isso é §9.2, operacional). A saída é um *laudo assinado nomeando o intervalo/raiz exato que falhou* — valor probatório para auditoria pública, plenamente determinístico (hashassinaturaMerkle, sem ML). Uma UI sem-DOM pode renderizar o status server-side (verde/vermelho) como *anti-spoof do painel* — mas a garantia é a própria execução kaudit do auditor; um insider que controla o checkpointer e o painel pode pintá-lo verde, então o verde do dashboard nunca substitui a verificação independente.

9.7 Limites honestos

Tamper-evidence, não prevention: só detecta se um STH honesto foi ancorado+testemunhado antes da adulteração e se alguém roda o verificador (condições operacionais, não criptográficas). Existe uma janela pré-âncora (eventos entre o último STH e o próximo checkpoint) — encurtada por checkpoint frequente, nunca zerada; um checkpointer parado a alarga, então sua liveness é monitorada fora do domínio do DBA (senão o check é circular). Ancorar em "outro tenant" vale zero se um mesmo root controla ambos — o quórum precisa ser genuinamente independente (idealmente o regulador). A completude cobre só o caminho enforçado; a leitura out-of-band de DBA e um emit removido são silenciosos a ela. L8 *não previne o breach* do insider autorizado no próprio escopo (isso é escopo/RLS + revogação); sua contribuição única é tornar detectável o encobrimento posterior de qualquer vetor (V1–V7) — é o anti-anti-forense. (ATT&CK T1070.001.002.004, T1565.001, T1485 via a âncora sobrevivente; parcial e dependente de monitor: T1562.008/.001; T1222 só com compliance-mode / control plane separado.)

10. Governança de acesso do insider

As técnicas acima encurtam o tempo entre sinal e ação e produzem prova. A governança ataca a raiz do ator central — o ex-prestador — encolhendo o escopo permanente que ele carrega. O princípio herdado é zero standing privilege: o acesso permanente é a exceção recertificada, nunca o default. Nada aqui gatea abuso dentro do escopo legítimo vigente (Seção 10.7); reduz o escopo permanente e a janela.

10.1 Elevação just-in-time — um lease que morre sozinho

Uma máquina-de-estado request → approve, guardada por invariante de modo que um pedido nunca se auto-aprova (aprovador ≠ requerente, senão o SoD barra). Na aprovação, a identidade *emite um claim elevado de escopo estreito* dentro do token DPoP-bound com exp = fim da janela; o refresh não re-afirma a elevação. Passada a janela, a autz do backend simplesmente não vê o claim → nega. *A expiração é estrutural, não uma varredura.* Elevações alimentam o score de user-risk — sinal, não gate.

10.2 Segregação de funções

Em grant-time e request-time, o SDK avalia combinações tóxicas (um conjunto de pares tóxicos — executor↔aprovador da mesma ação; admin↔auditor). Uma ação terminal-sensível (export em massa) exige aprovação multi-parte (MPA) — uma aprovação humana assinada como evento de audit antes de o lote liberar. MPA é um gate preventivo real (um segundo humano), não probabilístico — mas só no caminho de alto risco; o export in-scope na taxa normal não passa por ele. Onde a separação total é inviável (uma UBS de 1 operador), o controle compensatório é audit verificável + MPA nas ações de maior risco — sem fingir que uma pessoa são duas, e ciente de que 2 admins podem colludir.

10.3 Recertificação, determinística

Um cron dispara campanhas; a evidência de "ainda precisa?" é determinística (last-use do audit + comparação com o peer-group), nunca ML opaco — auditável por governo. Um grant sem uso na janela ou sem dono que recertifique auto-revoga por default. A recertificação é intervalar: um grant pode ficar stale entre campanhas — o auto-revoga por last-use estreita, não elimina, essa lacuna. A decisão do dono-de-função é evento assinado.

10.4 Break-glass

Uma credencial selada por-tenant num KMS; a retirada exige justificativa, dispara um *alerta CRITICAL automático, tem *TTL curto, grava a sessão inteira (pixels server-side + audit), e o braço SOAR abre um ticket de revisão pós-fato obrigatório. A frequência de break-glass é métrica — uso frequente sinaliza JIT mal-calibrado. Break-glass é um buraco deliberado: sua segurança é detetiva (alerta + sessão gravada + revisão), não preventiva — um admin privilegiado malicioso pode abusá-lo e é pego *só depois*, via a cadeia de audit ancorada externamente. É por-tenant (não fura o isolamento RLS) mas contorna SoD/MPA — daí a revisão obrigatória.

10.5 Offboarding = revogação dirigida por RH — o cerne do ex-prestador

O sistema de RH/contrato é a fonte da verdade. Uma transação offboard cascateia: revoga todos os grants; serial do certificado → CRL + push OCSP; revoga os credential-ids de passkey/WebAuthn; *revoga o refresh token no servidor* (checado na renovação); e para o access token auto-contido, *conta com o TTL curto* — sem introspecção por-request não há como invalidá-lo no meio da vida; desliga contas de serviço de dono único. TTL curto + OCSP-must-staple fazem a revogação morder sem esperar a propagação total da CRL.

Contra um replay Copy-as-cURL (V2), dois casos: (a) um replayer terceiro falha imediatamente pelo binding DPoP — a prova é assinada por chave que ele não tem; (b) o próprio ex-prestador, que detém a chave da sessão que capturou, só é barrado depois que a revogação morde ou o access token expira — entre a captura e o sinal de offboarding, dentro da janela válida, o token replayado ainda funciona. time-to-revoke é um SLO, alvo quase-zero (a policy diz "no mesmo dia"; "instantâneo" é meta, não garantia). Retorna um offboard_receipt assinado enumerando cada certificadopasskeytoken/grant morto.

10.6 Contas de serviço

Um SVID curto estilo SPIFFE, escopo mínimo, um dono humano nomeado, rotação e recertificação como qualquer conta; o offboarding do dono cascateia. Isto estreita o vetor M2M (V5) — sem credencial de máquina "onipotente e eterna" — mas não o fecha: o dono legítimo ainda usa o SVID *dentro do escopo/janela* até revogação ou expiração.

10.7 Limites honestos

Não contém o insider dentro do escopo legítimo vigente — a governança encolhe o escopo permanente e a janela; o abuso dentro do escopo atual válido é contido só por RLS + accountability + revogação. Offboarding é tão rápido quanto o sinal do RH — um processo de RH manual/noturno abre janela; TTL curto + must-staple + revocation-list de passkey encurtam, mas um access token cacheado de vida longa é gap real, então o TTL curto é load-bearing. Além disso, *o próprio sistema de RH precisa ser self-hosted/soberano*: se a fonte-da-verdade do offboarding for um SaaS externo (Workday via SCIM), isso é uma dependência de terceiro na fronteira LGPD — a declarar, nunca a esconder. *Um access token auto-contido não é revogável no meio da vida* sem introspecção por-request; trocar TTL curto por introspecção por-request é a única forma de fechar essa janela — trade-off de latência declarado. *Dado já exfiltrado antes do offboarding é irrecuperável por revogação* — território de DLPwatermarkjurídico. SoD exige gente suficiente; uma UBS de 1 operador compensa com audit + MPA nos pontos de maior risco, e com poucos admins, MPA é vulnerável a conluio. Recertificação é intervalar — um grant pode ficar stale entre campanhas. Nada de obscuridade vendida como proteção — tudo aqui é minimização de escopo + time-box + accountability, explicável ao auditor; nenhum score probabilístico é gate.

11. Cobertura de detecção e validação purple-team

Um catálogo de controles não se prova sozinho. Uma alegação de cobertura só é verdadeira depois de exercitada contra uma emulação realista do vetor. A disciplina (do DeTT&CT e da doutrina ATT&CK Evaluations) é: visibilidade ≠ detecção, mapeamento ≠ validação, e uma *matriz totalmente verde ≠ um sistema seguro*.

11.1 Cobertura é medida, nunca presumida

Uma célula não-exercitada é presumida, não coberta, e a matriz a marca visualmente assim. A regra dura: sem exercício adversarial dentro de um TTL, uma célula decai para presumido — anti-cobertura-silenciosa. Todo atomic é um proxy seguro de um adversário real; uma variante criativa que ninguém scriptou é invisível à matriz (gap de fidelidade de emulação — declarado, não escondido). Um % de cobertura é piso de pontos cegos, não teto de segurança.

11.2 Um ledger de cobertura máquina-legível

Uma tabela coverage_cell(control, vetor, tecnica, kind∈{Prevent,Detect,Govern}, sinal_esperado, status∈{presumido|validado|parcial|falho|na}, grade, last_validated_ts, ttl, mttd, mttr, last_run_id), persistida sobre o audit à prova de adulteração da Seção 9 — de modo que um insider forjando um "verde" seja detectável (quebra a cadeia e diverge da âncora externa). Isso não fecha V7 sobre o próprio validador: um admin que controla ao mesmo tempo o ledger e a âncora permanece raiz de confiança residual, governada pela policy de acesso, não por este framework. O ledger emite um *layer JSON compatível com o ATT&CK Navigator* (verdevalidado-technique · amareloparcial · vermelho=falho · cinza=presumidodecaído), renderizado numa *instância Navigator self-hostedoffline* — o heatmap de pontos cegos nunca sobe pro Navigator hospedado da MITRE nem a qualquer terceiro (o mapa de onde a detecção falha não sai da stack).

11.3 Um harness de emulação self-hosted

Um harness de breach-and-attack-simulation (koder-atk) roda numa VM isolada (nunca no laptop). Atomics, um por técnica/vetor, dirigem o stack real (craft-id V1, copy-as-cURL V2, loop-de-lote V3, endpoint-final-direto V4, M2M headless V5, cred-válida-de-novo-device V6, edição-de-linha-de-audit V7). Atomic Red Team, CALDERA e VECTR entram só como doutrina/inspiração — nenhum é dependência de runtime nem SaaS; o harness é 100% self-hosted.

11.4 Identidade sintética, oráculo e métricas

O harness autentica como operador sintético (um certificado/passkey purple-team no sistema de identidade), o que permite exercitar o braço SOAR de verdade — quarentena (R3) e até revogação (R5) sobre essa identidade, sem tocar operador real. Um oráculo puxa o stream por trace_id e mede por atomic: prevenido? (bloqueio do piso determinístico), detectado? (+ grade estilo Engenuity), respondido? (rung), MTTD (evento → alerta), MTTR (alerta → ação). As métricas são timing/contagem por trace_id — sem PII no caminho de telemetria. Tudo explicável (prosa + trace-ids), *sem ML no caminho de validação. O UEBA é o *alvo sob teste; seus falso-neg/falso-pos realimentam o tuning de thresholds — nunca gera o ataque (mantido scriptado por auditabilidade).

11.5 Segurança da própria simulação

Dois modos, impostos pelo harness. PROD-SHADOW: só atomics não-mutantes cujo resultado esperado é um bloqueio do piso (um V1-read que C1 nega, um replay que C3 rejeita). Ler não basta como salvaguarda — uma leitura fora de escopo que o piso deixasse passar (o próprio bug que o atomic caça) seria acesso não autorizado a dado real de paciente = incidente LGPD. Portanto, em prod: (i) o alvo do IDOR é *sempre um registro honeytoken semeado, nunca linha de paciente real; (ii) se o piso *falha em negar, o harness registra o veredito pela decisão de autorização/status e não materializa, loga nem retém o payload retornado — aborta e coloca em quarentena. Payload mutante é recusado em prod. TENANT-SINTÉTICO: fidelidade total sobre dataset honeytoken (nunca dado real de paciente), onde R0–R5 rodam de verdade. Todo tráfego de emulação é tagueado sintético na ingestão (roteia resultado pro canal purple-team, marca a linha de audit) — mas a tag é invisível ao controle sob teste (um controle que enxergasse a tag estaria colando; deve bloquear por mérito próprio).

11.6 Cadência e o gate de CI (detecção-como-código)

(a) Um controleplaybookregra mudado re-roda os atomics afetados; *uma release que toca controle de segurança não sobe se seus atomics regridem validado → falho*. (b) Um run completo semanal/mensal. (c) Pós-incidente, toda falha real vira atomic de regressão permanente. Atomics de mutação/variante (uma assinatura fuzzeada) barram o "ensinar para a prova"; a revisão humana purple-team permanece (mitiga, não elimina, a gamificação do BAS).

11.7 Limites honestos

Verde ≠ seguro. O ATT&CK Enterprise mapeia mal abuso de APIlógica-de-negócio: V1V4 mapeiam frouxo (T1190T1213) — carregue um mapeamento paralelo OWASP API (BOLABFLA/business-flow) e não finja cobertura ATT&CK limpa. Obscuridade não é segurança: em V1 o piso é a autorização C1/RLS; a célula rola verde só no DENY de C1 — um id não-enumerável (C18) é defesa-em-profundidade, jamais o gate; uma célula V1 nunca rola verde porque o id era imprevisível. Idem watermark/traitor-trace (C17): é atribuição, nunca prevenção. O insider autorizado, lento, in-scope (V3 degenerado) não é problema de detecção, e a célula nunca rola verde — contido por escopo + audit + revogação, não por analítica; um V3 validado cobre só a variante que estoura o rate-cap, não a leitura sub-limiar a ritmo humano. O atomic V5 demonstra a ausência total de sinal client-side — ponto cego confirmado, não célula verde. SOAR irreversível (R5) só é medido no tenant sintético; a paridade em prod é inferida e reportada como tal. Nenhuma célula rola coberta sem run validado dentro do TTL.

12. Robustez adversarial e privacy-by-design

A camada final trata duas propriedades como engenharia de primeira classe, não pós-pensamentos: a analítica precisa sobreviver a um adversário que sabe que ela existe, e precisa proteger os próprios cidadãos e operadores cujo comportamento ela modela. Ela não cria piso novo — o insider segue contido por escopo + audit + revogação; tudo aqui é sinal sobre o piso, log-antes-de-block.

12.1 Resistência à evasão (MITRE ATLAS)

Quatro alavancas, nenhuma sobrevendida: (a) heterogeneidade — evadir um membro do ensemble não transfere a outro em espaço de feature distinto; (b) features server-side-caras — caras, *não impossíveis*, de forjar (JA4 é forjável via TLS-shaping; a divergência UA↔JA4 pega spoof preguiçoso, não o adversário que alinha ambos); o valor real é custo elevado mais o piso determinístico fora do alcance comportamental; (c) endurecimento do oráculo — nunca devolver o risk_score numérico ao cliente; a saída do oráculo é um desfecho grosseiro (allow / step-up), rate-limited e logado, para negar probing (ATLAS AML.T0040); (d) holdout randomizado — uma fração das sessões em shadow/log-only, scoring profundo amostrado ao acaso. Honesto: (c) e (d) são obscuridade-que-encarece, jamais gate.

12.2 Step-up não é gate probabilístico

O único desfecho não-allow que o ensemble probabilístico pode disparar é um step-up — um desafio reversível (re-authpasskey), não um deny. Um denygate duro permanece exclusivo do piso determinístico mais caps. Todo step-up disparado por sinal probabilístico é logado, rate-limited, revisável sob a LGPD Art. 20, e nunca base única para ação irreversível (R5 exige humano-no-laço). Assim nenhum ML opaco decide um acesso de escopo-de-governo.

12.3 Detecção de drift como fail-safe

Por feature × peer-group × endpoint: PSI + KS/chi-quadrado sobre agregados-DP (diário vs trailing-30d); drift de predição via Jensen-Shannon; ADWIN/Page-Hinkley por endpoint. Drift benigno (população-wide, gradual, evento conhecido) é separado de um slow-trend por-conta. Um *modelo driftado é auto-rebaixado a log-only* até revalidação humana — nunca gate degradado (defendendo ATLAS AML.T0031). Um registro de modelo (versão, janela de treino, hash de schema, métricas, status) dá reprodutibilidade de governo.

12.4 A fronteira de privacidade diferencial, dita com precisão

Baselines de população (médias, variâncias, quantis por papelunidadeendpoint) usam um mecanismo Laplace/Gaussian com budget epsilon por-tenant, contabilizado e auditável (o precedente TopDown do Censo US 2020). A fronteira precisa: DP protege só os baselinesagregadosdashboards/estatística de drift. O scoring individual não é DP, e — crítico — o *feature store individual guarda features brutas (pseudonimizadas) NÃO cobertas por DP: é uma *concentração de PII de alto valor protegida por RLS + pseudonimização keyed + retenção + break-glass auditado, não por DP; um vazamento dela expõe comportamento individual. Contra membership-inference (AML.T0024) a defesa primária é o *oráculo de scoring interno-mTLS não-exposto* (nega query de inferência), não o DP nos agregados; modelos treinados em dado individual seguem memorizando — mitigue com DP-SGD no treino ou aceite e declare o limite de memorização.

12.5 LGPD-hard por construção

Purpose-limitation é estrutural: features são um schema declarado e allow-listed no contrato de evento — uma métrica de produtividade de funcionário é não-derivável (não existe dashboard de throughput por-operador para construir). Pseudonimização keyed por-tenant; re-identificação só via o sistema de identidade sob RLS + break-glass auditado. Explicabilidade satisfaz a LGPD Art. 20 + humano-no-laço para o irreversível. Um RIPD é documentado por tenant — o UEBA é ele próprio processador de dado sensível de saúde. Tudo self-hosted; nenhuma telemetria de cidadão sai para SaaS de terceiro.

12.6 Limites honestos

(1) Não contém o insider autorizadolentoin-scope melhor que piso + audit + revogação — só encarece e antecipa a detecção; o detector de slow-trend pega escalada, não o padrão plano in-scope. (2) Evasão por probing é possível (oráculoholdout são obscuridade que só eleva custo; JA4UA↔JA4 são forjáveis por adversário competente). (3) DP × utilidade é assimétrico: epsilon apertado enfraquece detecção em peer-group pequeno — onde o risco de re-identificação é maior — trade-off explícito por-tenant, não escondido. (4) DP não é anonimização plena sob LGPD: o feature store segue sendo dado pessoal, de PII-sensível concentrada — seu risco é de RLSretençãobreach, não de DP. (5) Modelos explicáveis detectam menos anomalia exótica que black-box — trade-off aceito. (6) O UEBA é ele próprio processador de dado sensível de saúde — exige RIPDminimizaçãoretenção. (7) O "ritmo não-humano" da sequência só discrimina no canal humano — em M2M/API é a linha de base legítima, então V5 é carregado por caps + JA4 + audit + mTLSDPoP, não pelo modelo de sequência. (8) GeoASN/reputação são dado externo importado (refresh periódico), não capacidade nativa.

13. Síntese: o que de fato contém o insider

Dez técnicas, uma espinha. Vale terminar exatamente onde a honestidade da área exige, com a partição explícita:

A única prevenção do insider autorizado é o escopo — autorização por-objeto (RLS) e caps de volume
(C1C5C18). Determinístico, explicável, um gate legítimo.
A única accountability é uma trilha de audit verificável (C15) — ancorada externamente para que um
encobrimento posterior (V7) seja detectável. Não previne; torna provável.
A única defesa contra o relógio do ex-prestador é a revogação (C2/CAEP) — limitada pela credencial
mais lenta na vida útil, então TTLs curtos são load-bearing.

Todo o resto — UEBA (Seção 3), origem de rede (Seção 4), marcação centrada no dado (Seção 5), capability-URLs (Seção 6), anti-instrumentação (Seção 7), SOAR (Seção 8), governança (Seção 10), validação de cobertura (Seção 11), analítica adversarial-robusta e preservadora de privacidade (Seção 12) — é defesa em profundidade medida contra essas três pernas. Cada um ganha seu sustento por um de três efeitos: encurtar a latência de detecção, encarecer as variantes rápidas/scriptadas ou produzir prova. Nenhum deles é a parede.

A postura madura é portanto um sistema em camadas, honesto: um piso determinístico que gatea; um audit ancorado externamente que prova; revogação rápida que expira o ex-insider; e, por cima, um tecido de analítica-e-resposta reprodutível, explicável e preservador de privacidade que observa, denuncia e — reversivelmente, com humano no irreversível — responde. Venda qualquer camada probabilística como o gate e você mentiu ao auditor e ao paciente. Nomeie escopo + accountability + revogação como a contenção, e tudo acima vira o que de fato é: observabilidade e atrito que compram tempo e prova contra um adversário que você já deixou entrar.

Ver também

stack-RFC-036 — Secure Surface & Tenant Security Alerting (cânone de engenharia da Koder Stack): o
catálogo de 19 controles (C1–C19) e a decisão de postura por-tenant, por-surface que este capítulo embasa. Ele cita este capítulo para o conhecimento da área; este capítulo fica vendor-agnóstico (D6 — um fato, um home).
stack-RFC-037 — Insider-Resistant Detection & Response (cânone de engenharia da Koder Stack): o
engine UEBA da Stack (services/ai/ueba), o braço SOAR (infra/observe) e a implementação de audit verificável — a instância concreta das Seções 3, 8 e 9.
Parte VIII, 01-defending-applications-against-automated-abuse — a taxonomia de ameaça, o núcleo
obscuridade-não-é-segurança, o catálogo de controles e o enquadramento de limites-honestos que este capítulo aprofunda.
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 escopo.
Parte VIII, 03-authentication-and-identity (planejado) — WebAuthnpasskeys, OAuthOIDC, DPoP/token
binding e PKI/CAEP referenciados pelos controles de posse, step-up e revogação.