Desenhe o fluxo e marque onde a confiança muda (uma linha tracejada = fronteira de confiança). Onde os dados cruzam uma fronteira é onde você precisa de um controle:

[ usuário (não confiável) ] ┊ [ WAF ] → [ API (valida) ] ┊ [ banco (RLS) ]
                            ↑ fronteira            ↑ fronteira
                    (aqui: authN, validação)   (aqui: authz, RLS)

PARTE D — Desenhar uma arquitetura segura (o exercício do arquiteto)

A arquitetura de referência — e a pergunta que o arquiteto faz em cada ponto: "onde posso colocar um controle de segurança?"

              INTERNET
                 │        ← [WAF, DDoS, rate limit, TLS, bot mgmt]
              Load Balancer
                 │        ← [TLS termina; health checks]
             API Gateway
                 │        ← [authN, authZ, rate limit por rota, validação]
        ┌────────┴────────┐
     Backend           Backend      ← [least privilege; secrets do cofre; egress filtrado]
        │
   ┌────┴────┐
   DB       Cache                   ← [RLS/criptografia; rede privada; sem IP público]
   │
 Backup                             ← [3-2-1; versionado; offline; canary]

O seu stack, lido assim: Internet → Cloudflare (WAF/TLS/rate limit) → Workers (authN/authZ/validação) → Supabase (RLS/criptografia) → backups. Você já tem uma arquitetura em camadas — este módulo te ensina a projetá-la de propósito e achar os pontos fracos.

PARTE E — Labs práticos 🧪

O "lab" aqui é pensar e desenhar — a habilidade do arquiteto. Não precisa de terminal.

Lab 1 — Threat model de uma funcionalidade sua ⭐

Escolha um fluxo do seu projeto (ex.: o cadastro de lead, ou o login admin). Aplique as 4 perguntas:

Desenhe o fluxo (usuário → API → banco), marcando as fronteiras de confiança.
Para cada elemento, passe o STRIDE (spoofing? tampering? …).
Para cada ameaça, escreva o controle.
Revise. Entregável: uma página de threat model.

Lab 2 — Diagrama de confiança do seu stack

Desenhe Cloudflare → Workers → Supabase → n8n e marque cada fronteira de confiança e o controle que a protege. Onde falta controle = achado arquitetural.

Lab 3 — "Onde ponho um controle?"

Pegue a arquitetura de referência (Parte D) e, camada por camada, liste um controle de segurança que caberia ali. Compare com o que seu projeto já tem (DOC §3).

Lab 4 — Ler a arquitetura do próprio programa

Leia a DOCUMENTACAO §3 (defesa em profundidade, trust boundaries, princípios) — ela é a arquitetura de segurança do seu sistema. Identifique qual princípio (A.2) cada decisão aplica.

Lab 5 — Ferramenta de threat modeling (opcional)

Use o Microsoft Threat Modeling Tool (gratuito) ou o OWASP Threat Dragon para desenhar um fluxo e gerar as ameaças STRIDE automaticamente.

PARTE F — Autoavaliação ✅

Responda de memória:

Qual é a virada de mentalidade desta fase?
O que é "fail secure"? Dê um exemplo do seu projeto.
O que significa Zero Trust "entre serviços"?
Quais são as 4 perguntas do threat modeling?
O que cada letra do STRIDE representa (cite ao menos 4)?
O que é uma "fronteira de confiança" num diagrama, e por que ela importa?
Por que disponibilidade (DR/HA) é uma questão de segurança?

<details><summary>👉 Gabarito</summary>

De "como acho a falha?" para "como projeto o sistema para a falha ser difícil de acontecer?" — eliminar classes de falha pelo desenho (A.1).
Se algo não pode ser validado com segurança, negue (não aceite). Ex.: o middleware deve rejeitar um JWT sem exp, não aceitá-lo (A.2/Ex. 12).
Nenhum serviço confia em outro só por estarem na "mesma rede" — todo pedido é autenticado/autorizado (ex.: assinatura HMAC no webhook do n8n) (Pilar 2).
O que estamos construindo? O que pode dar errado? O que fazemos a respeito? Fizemos um bom trabalho? (C).
Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege (C).
É onde o nível de confiança muda (ex.: do usuário para o servidor). Importa porque é ali que os controles (authN/authZ/validação) precisam estar — onde os dados cruzam a fronteira (C).
Porque disponibilidade é o "D" da tríade CIA — um sistema fora do ar (por DoS ou desastre) é uma falha de segurança; resiliência é um controle (Pilar 8).</details>

Checklist prático:

[ ] Fiz um threat model (4 perguntas + STRIDE) de 1 funcionalidade minha
[ ] Desenhei o diagrama de confiança do meu stack e marquei os controles
[ ] Fiz o exercício "onde ponho um controle?" na arquitetura de referência
[ ] Li a DOCUMENTACAO §3 e liguei cada decisão a um princípio
[ ] Consigo citar os 8 princípios e o STRIDE
[ ] (opcional) Usei o Threat Dragon / MS Threat Modeling Tool

Conclusão: 5/7 do quiz + 1 threat model escrito.