Defesa em Profundidade — Segurança
Visão Geral
A segurança é em camadas, assume que qualquer camada individual pode falhar e concede o menor privilégio que funciona. Atacantes encontram a camada que você esqueceu — um sistema que depende de uma única parede cai quando essa parede tem um único bug; controles de privilégio mínimo sobrepostos sobrevivem à falha de qualquer um deles.
Os Princípios (universais)
- Modele ameaças antes de construir qualquer coisa que lide com entradas não confiáveis, segredos ou dados de usuário. Faça uma análise STRIDE leve (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) por nova superfície. Registre o modelo e as mitigações (consulte
recording-decisions). - Defesa em profundidade. Nenhum controle único é "a" segurança. Autenticação, autorização, validação de entrada e aplicação na camada de dados assumem que os outros podem ser contornados.
- Privilégio mínimo em todos os lugares — papéis, tokens, contas de serviço, permissões de banco de dados. Padrão é não ter acesso; conceda o mínimo; revogue o não utilizado.
- Segredos nunca vivem em código, imagens ou configurações commitadas. Eles vêm de um cofre de segredos em tempo de execução, são rotacionados e são escopados para a carga de trabalho que precisa deles.
- Valide toda entrada no limite de confiança; trate a saída de todo sistema externo como dados não confiáveis, nunca como instruções.
- A cadeia de suprimentos de dependências é uma superfície de ataque. Lockfiles commitados e com integridade verificada; dependências varridas e atualizadas; imagens base fixadas e varridas.
- Ações sensíveis são auditadas — quem fez o quê, quando — para que abusos e erros sejam reconstruíveis.
Referência Rápida
| Superfície | Primeiras perguntas |
|---|---|
| Novo endpoint recebendo entrada de usuário | Qual é o modelo STRIDE? Onde está a validação? Qual é o menor papel que funciona? |
| Qualquer coisa com um segredo | Está no cofre de segredos (não em código/imagem)? Escopado? Rotacionável? |
| Nova dependência | Lockfile fixado? Varrido? É bem suportada? |
| Mutação privilegiada | É auditada? O ator está autorizado na camada de dados, não apenas no aplicativo? |
Mecanismos da Stack
RLS como a camada final de aplicação, limitação de profundidade/custo do GraphQL como controle contra DoS, Key Vault para segredos, pnpm audit/Trivy no CI — consulte postgres-postgraphile-rls-and-sql e cloud-delivery-aks.
Aplicação: auditoria de dependências + varredura de imagens + varredura de segredos no CI (bloqueante); modelos de ameaça e cobertura de auditoria são julgamento do revisor.
Fundamentação completa: Artigos X e XIV da constituição, agrupados em engineering-constitution/references/engineering-constitution.md.