Compêndio de CC · Parte VIII — Segurança, Confiança & Defesa Adversarial
Como o software se defende quando o outro lado está tentando — não contra falhas aleatórias, mas contra um adversário deliberado que lê o tráfego, replaya a sessão, roteiriza a API e às vezes é um usuário legítimo. Esta parte é o chão enciclopédico da segurança de aplicações, defesa contra bots e automação, ameaça de insider, autorização e atestação de plataforma: os controles da área, seus limites honestos e a única verdade que organiza todos eles — *a autorização no servidor é a raiz; todo o resto é defesa em profundidade*.
Por que esta parte tem gravidade agora
Toda outra parte deste compêndio assume um ambiente cooperativo — o programa roda, a query retorna, os bytes chegam. Segurança é a parte que abandona essa premissa. Ela ganha gravidade de primeira classe na Koder Stack no momento em que a Stack passa a hospedar *sistemas de outras pessoas*: aplicações multi-tenant onde os operadores são conhecidos e credenciáveis, o dado é sensível (prontuário de saúde pública, dado pessoal sob LGPD) e o atacante realista não é uma botnet anônima, mas um insider técnico ou prestador recém-desligado que já conhece a API. Esse modelo de ameaça — o adversário autorizado — é onde a ofuscação desaba e só sobram autorização, posse e auditabilidade reais. Os capítulos aqui documentam esse conhecimento de forma vendor-agnóstica; a decisão da própria Stack sobre como compor esses controles vive no cânone de engenharia (stack-RFC-036, Secure Surface), que cita esta parte.
O mapa desta parte
| Doc | Conteúdo | Status |
|---|---|---|
01-defending-applications-against-automated-abuse |
Taxonomia de ameaça (bots, insiders, sessão roubada, máquina-a-máquina); a verdade de causa-raiz (autorização por-objeto + invariantes de estado, não ofuscação); o catálogo completo de controles (RLS, anti-replay, binding de device, step-up, fingerprint, atestação, honeytokens, WAF, SIEM/UEBA); o modelo de postura configurável; e os limites honestos de cada controle | semeado (conteúdo real) |
02-insider-resistant-system-design |
O companheiro aprofundado do cap. 01, focado no adversário insider autorizado: UEBA self-hosted (peer-group + não-supervisionado + sequência, explicável, cold-start); resposta autônoma (SOAR) com humano-no-laço para ações irreversíveis; auditoria à prova de adulteração / verificável (hash-chainMerkleWORMancoragem); capability-URLs & moving-target; defesa centrada no dado (DLP, watermark por-operador, traitor-tracing); anti-instrumentação como sinal; governança de insider (JITSoDrecertificaçãobreak-glass); cobertura ATT&CK & purple-team; robustez adversarial & privacidade-por-design. Base de campo do stack-RFC-037 |
semeado (conteúdo real) |
03-authorization-models |
Modelos de controle de acesso: DACMACRBACABACReBAC, capabilities, segurança por-linha/objeto, motores de policy | planejado |
04-authentication-and-identity |
Senhas, MFA, WebAuthnpasskeys, OAuthOIDC, token binding, PKI & identidade nacional | planejado |
05-applied-cryptography |
Primitivas simétricas/assimétricas, hashing & KDFs, assinaturas, gestão de chaves, armadilhas de protocolo | planejado |
Referência vs decisão (D6 — sem duplicação)
Esta parte guarda conhecimento ("o que a área sabe sobre defender uma superfície"). A decisão da Koder Stack sobre quais controles ligar, por tenant e por surface, é cânone de engenharia: stack-RFC-036 (Secure Surface & Tenant Security Alerting) cita este capítulo para o embasamento da área e acrescenta a policy específica da Stack por cima. Um fato, um home — o catálogo de controles vive aqui; a decisão de postura vive lá.