| Princípio | O que significa | Exemplo |
|---|---|---|
| Security by Design | segurança desde o desenho, não colada depois | pensar em ameaças antes de codar |
| Least Privilege | cada peça só acessa o mínimo | token com escopo estreito; RLS |
| Defense in Depth | várias camadas; se uma falha, a próxima segura | WAF + validação + RLS |
| Zero Trust | nada é confiável por padrão; verifique sempre | serviço interno também autentica |
| Fail Secure | se não dá para validar, negue | JWT sem exp → rejeitar, não aceitar |
| Secure Defaults | o padrão já é seguro; inseguro exige esforço | bucket privado por padrão |
| Segmentação / KISS | separar e simplificar reduz o raio do dano | rede de banco isolada; menos peças |
| Complete Mediation | toda ação sensível é verificada, sempre | authz em todo endpoint, não só na UI |
Estes princípios já aparecem no seu programa: o menor privilégio (anon vs service_role), a defesa em profundidade (traversal em 3 camadas do Ex. 5), o fail secure (rejeitar JWT sem exp). Arquitetura é aplicá-los de propósito, desde o início.
PARTE B — Os 8 pilares da arquitetura segura
Pilar 1 — Defesa em profundidade (camadas)
Nenhuma camada protege tudo. O modelo do seu projeto (DOC §3.1), do exterior ao núcleo:
1. PERÍMETRO Cloudflare (WAF, DDoS, TLS, rate limit, bot)
2. REDE firewall, egress, isolamento de sub-rede
3. HOST VPS hardening, SSH, fail2ban
4. APLICAÇÃO auth, validação, CSP, sanitização
5. DADOS RLS, criptografia, backup
6. IDENTIDADE MFA, menor privilégio, rotação de chaves
Fura uma, ainda há cinco. Cada camada é uma chance de parar o ataque.
Pilar 2 — Zero Trust (nunca confie, sempre verifique)
- Ideia: não existe "rede interna confiável". Todo pedido — inclusive entre seus próprios serviços — é autenticado e autorizado.
- No projeto: o n8n não confia na API "por estar na mesma rede" — valida a assinatura do webhook (HMAC); a saída da IA é tratada como input hostil (DOC §3.4, corrige Ex. 8/30/33).
Pilar 3 — Least privilege & segmentação
- Identidade: cada token/chave com o mínimo (Módulo 6). Rede: banco em sub-rede privada; serviços separados.
- Efeito: se um componente cai, o atacante não herda o reino — o raio de explosão é pequeno.
Pilar 4 — Gestão de identidade
- IAM central, MFA em tudo (humano e, quando possível, serviço), rotação de chaves, revogação no offboarding. É a "camada 6".
Pilar 5 — Gestão de secrets
- Cofre (Cloudflare Secrets/KMS/Vault), rotação em cadência, dev ≠ prod, nunca no código (Módulos 3/6, DOC §5).
Pilar 6 — Criptografia
- Trânsito (TLS 1.2+) e repouso (disco/objeto cifrado, chaves no KMS). Dados sensíveis nunca em claro.
Pilar 7 — Logging & monitoramento (observabilidade de segurança)
- Projetar o sistema para ser observável: todo acesso privilegiado logado, log imutável, alertas em eventos sensíveis. Sem isso, o sistema é cego (prepara a Fase 7 — Blue Team).
Pilar 8 — Resiliência (alta disponibilidade + DR)
- Disponibilidade é parte da segurança (o "D" da tríade CIA). Redundância, backups testados (3-2-1), plano de recuperação (DOC §8). Um sistema fora do ar é uma falha de segurança.
PARTE C — Threat Modeling (a habilidade central do arquiteto) 🧠
Modelar ameaças é perguntar "como isso poderia ser atacado?" antes de construir. É a ferramenta que transforma princípios em decisões.