conceito
etapa: design
2 min de leitura
Princípios de arquitetura de segurança
Um arquiteto de segurança projeta os controles uma vez, como padrões, para que centenas de equipes os herdem. O ofício é um pequeno conjunto de princípios aplicados de forma consistente em nuvem, rede, identidade e dados.
threat modeling (STRIDE)architecture decision records (ADR)SABSA / TOGAF (optional)reference architectures and landing zonesNIST SP 800-207 (zero trust)C4 diagrams
Princípios centrais
- : cada identidade e carga de trabalho recebe apenas o acesso que sua tarefa exige, pelo tempo que for necessário.
- : várias camadas independentes, para que uma falha não seja uma violação.
- : nunca confiar pela localização na rede; autenticar e autorizar cada requisição, usando identidade, dispositivo e contexto, e assumir que a violação já ocorreu.
- Seguro por padrão: o caminho fácil é o caminho seguro; opções inseguras exigem esforço explícito.
- Separação de funções e de ambientes: nenhuma pessoa ou comprometimento isolado deve conseguir fazer tudo.
- Minimizar a e o : expor menos, segmentar mais e limitar o que uma falha consegue alcançar.
- Falhar fechado e manter simples: a complexidade é inimiga da segurança.
De princípios a padrões
Princípios não escalam sozinhos; padrões escalam. Uma landing zone dá a cada nova conta de nuvem o mesmo logging, a mesma linha de base de rede e os mesmos guardrails. Um serviço de identidade padrão dá a cada aplicação autenticação e autorização. Um caminho pavimentado (paved path) para pipelines carrega as verificações de segurança. A entrega do arquiteto são esses blocos reutilizáveis, mais a orientação sobre quando usá-los e um processo para exceções.
Registrar decisões
Escreva as decisões significativas com seu contexto e trade-offs. Registros curtos de decisão de arquitetura mantêm o raciocínio fácil de encontrar quando a equipe muda.
# ADR-0012: A autenticação entre serviços usa identidade de workload (mTLS)
Status: aceito Data: 2026-10-02 Responsável: security-architecture
## Contexto
Os serviços chamam uns aos outros dentro do cluster. Hoje a única proteção é uma lista de permissões de rede; um pod comprometido pode chamar qualquer coisa.
## Decisão
Cada serviço recebe uma identidade de workload e TLS mútuo por meio da malha. Políticas de autorização definem qual serviço pode chamar qual endpoint. O padrão é negar.
## Consequências
+ O comprometimento de um serviço não concede mais acesso de rede a todos.
+ As chamadas são rastreáveis nos logs.
- As equipes precisam definir seus chamadores permitidos; a malha acrescenta complexidade operacional.
## Alternativas consideradas
Apenas políticas de rede (rejeitada: sem identidade, difícil de auditar); chaves de API compartilhadas (rejeitada: sem rotação, sem atribuição).Trabalhando com as equipes
- Revise os designs cedo, quando mudar é barato; use modelagem de ameaças em novos sistemas e mudanças importantes.
- Dê às equipes padrões de autosserviço e guardrails, em vez de filas de aprovação que as atrasam.
- Explique o risco por trás de cada requisito; regras sem motivo acabam contornadas.
- Acompanhe as exceções com responsáveis e datas de expiração, e devolva as exceções recorrentes ao padrão.
- Meça a adoção dos padrões: uma arquitetura de referência não utilizada não protege ninguém.
conexões no mapa
- Frameworks e padrões de segurançaé implementado por meio dePrincípios de arquitetura de segurança
- Princípios de arquitetura de segurançatorna a evidência automáticaConformidade na prática: controles, evidências e auditorias
atualizado em 14/10/2026 · fontes para aprofundar · reportar erro
em outros domínios
- Zero-trust - modelo de confiançacloudseco princípio e a implementação em nuvem
Estude antes
teste o que entendeu
Carregando perguntas…