O que é modelagem de ameaças
Modelagem de ameaças é o exercício de olhar para um sistema e perguntar 'o que pode dar errado do ponto de vista de segurança' antes que ele exista por completo. É pensar como atacante enquanto o desenho ainda está aberto.
Não é um documento extenso nem uma ferramenta cara. É uma conversa estruturada sobre fluxos, dados e confiança, que produz decisões concretas de projeto.
O ganho é simples: corrigir uma falha de desenho custa uma conversa; corrigir a mesma falha em produção custa incidente, retrabalho e reputação.
Por que fazer antes de codar
Falhas de segurança têm custos muito diferentes conforme o momento em que são encontradas. No desenho, é uma decisão a mudar. No código, é refatoração. Em produção, é incidente.
Modelar cedo também evita decisões irreversíveis. Uma arquitetura que assume confiança implícita entre serviços é difícil de consertar depois.
O objetivo não é prever tudo, e sim evitar os erros de desenho que são caros e previsíveis. É o mesmo princípio do shift-left aplicado à arquitetura.
- No desenho: decisão a ajustar.
- No código: refatoração.
- Em produção: incidente e retrabalho.
- Cedo evita decisões irreversíveis.
STRIDE: uma lista para não esquecer
STRIDE é um acrônimo que organiza os tipos de ameaça: falsificação (spoofing), adulteração (tampering), repúdio (repudiation), divulgação de informação, negação de serviço e elevação de privilégio.
Ele funciona como checklist mental: ao olhar um fluxo, percorrer as seis categorias reduz o risco de esquecer uma classe inteira de problema.
Não é a única metodologia, mas é simples o bastante para ser usada por qualquer time, sem treinamento pesado.
- Spoofing: se passar por outro.
- Tampering: alterar dados.
- Repudiation: negar uma ação.
- Information disclosure: expor dados.
- Denial of service: derrubar o serviço.
- Elevation of privilege: ganhar mais acesso.
Quando e com quem fazer
O momento mais valioso é o desenho de algo novo: um serviço, uma integração, um fluxo com dados sensíveis. Também vale ao mudar algo relevante em sistema existente.
Quem participa importa. Precisa de quem entende o negócio, quem desenha a arquitetura e quem constrói. Segurança pode facilitar, mas o exercício é do time.
Sessões curtas e frequentes funcionam melhor que um workshop enorme e raro. O hábito vale mais que o evento.
- Novos serviços, integrações e fluxos com dados sensíveis.
- Mudanças relevantes em sistemas existentes.
- Com negócio, arquitetura e desenvolvimento.
- Sessões curtas e frequentes.
As entradas do modelo
Modelagem de ameaças precisa de insumos concretos: um diagrama de fluxo, os dados que trafegam, as fronteiras de confiança e os atores envolvidos.
Fronteiras de confiança são o ponto mais importante. Onde um dado sai do seu controle e volta é onde a maioria das ameaças vive.
Não precisa ser um desenho perfeito. Um esboço de fluxos e confiança já revela problemas que passariam batido.
- Diagrama de fluxo de dados.
- O que trafega e o que é sensível.
- Fronteiras de confiança entre componentes.
- Atores e seus níveis de acesso.
Do modelo ao backlog
O erro mais comum é produzir um belo documento de riscos que ninguém executa. Modelagem só vale se virar trabalho: itens de backlog, critérios de teste e decisões de arquitetura.
Cada ameaça relevante deve ter uma resposta: mitigar, aceitar, transferir ou eliminar. E cada mitigação precisa de dono e prazo.
Assim, o exercício de segurança deixa de ser abstrato e passa a produzir mudanças reais no produto.
- Transformar ameaças em itens de backlog.
- Decidir: mitigar, aceitar, transferir ou eliminar.
- Definir dono e prazo por mitigação.
- Virar critério de teste.
Ferramentas e artefatos
Ferramentas ajudam, mas não são o centro. Diagramas, quadros e templates atendem perfeitamente para começar. O valor está na conversa e nas decisões, não na ferramenta.
Os artefatos úteis são poucos: diagrama de fluxo com fronteiras de confiança, lista de ameaças por fluxo e registro das decisões tomadas.
Mantenha os artefatos versionados junto ao projeto. Modelo que fica numa pasta esquecida deixa de refletir o sistema real.
- Diagrama com fronteiras de confiança.
- Ameaças mapeadas por fluxo.
- Registro de decisões de mitigação.
- Artefatos versionados com o projeto.
Tornando contínuo
Modelagem não é evento único. Sistemas mudam, e novas fronteiras aparecem. O modelo precisa ser revisitado quando a arquitetura muda.
Uma prática sustentável é incorporar perguntas de ameaça ao processo normal: todo novo fluxo com dados sensíveis passa por uma sessão curta.
Com o tempo, o time internaliza o olhar de segurança e a modelagem deixa de ser tarefa separada para virar parte do jeito de projetar.
- Revisitar quando a arquitetura muda.
- Sessão curta por novo fluxo sensível.
- Internalizar o olhar de segurança.
- Modelagem como parte do projeto.
Modelagem para APIs, integrações e nuvem
APIs e integrações concentram boa parte das ameaças modernas, porque são a porta de entrada para dados de negócio. Modelá-las é olhar para quem consome, o que pode pedir e o que pode fazer com o que recebe.
Em APIs, as fronteiras de confiança são explícitas: cada chamada é um ponto onde um dado entra e precisa ser validado. Perguntas de autorização — 'quem pode acessar este recurso?' — costumam revelar as falhas mais graves, como confiar no identificador enviado pelo cliente.
Integrações com terceiros adicionam outro risco: o que você confia de fora pode não ser confiável. Tratar toda integração externa como fronteira de confiança evita assumir que o outro lado está sempre correto.
Na nuvem, a modelagem precisa considerar identidade e permissão como o centro. Serviços, funções e contas com privilégio amplo transformam um erro pequeno em comprometimento grande. Menor privilégio e escopo restrito valem aqui tanto quanto em qualquer arquitetura.
O exercício é o mesmo em todos os casos: diagramar o fluxo, marcar as fronteiras, aplicar as categorias de ameaça e transformar os achados em decisões. Muda o contexto, não o método.
- Validar tudo que cruza a fronteira da API.
- Checar autorização por recurso, não só autenticação.
- Tratar toda integração externa como não confiável.
- Aplicar menor privilégio a identidades na nuvem.
Modelagem, pentest e código: cada um no seu tempo
Modelagem de ameaças, pentest e revisão de código atuam em momentos diferentes e se complementam. Modelagem antecipa falhas de desenho antes de existir código. Revisão e análise contínua cuidam da implementação ao longo do ciclo. Pentest verifica o que existe em execução.
Confundir os papéis leva a expectativas erradas: esperar que o pentest encontre tudo que deveria ter sido evitado no desenho, ou achar que a modelagem substitui o teste real. Cada um responde a uma pergunta distinta.
Quando os três operam juntos, o sistema fica protegido em profundidade: o desenho evita os erros caros, a implementação é verificada de forma contínua e o ambiente real é testado de fato.
Erros comuns
Os erros mais frequentes são fazer modelagem só no fim, produzir documento sem virar ação, convidar só segurança e tentar cobrir tudo num exercício gigante.
Todos levam ao mesmo resultado: um artefato bonito que não muda o produto. O antídoto é simplicidade, participação do time e conexão direta com o backlog.
- Modelar apenas no fim do projeto.
- Gerar documento sem execução.
- Deixar só a segurança envolvida.
- Tentar cobrir tudo de uma vez.
Checklist de modelagem
O checklist abaixo resume o essencial para fazer modelagem de ameaças que gera resultado.
- Fazer antes de codar, no desenho.
- Diagramar fluxos e fronteiras de confiança.
- Aplicar STRIDE por fluxo.
- Envolver negócio, arquitetura e desenvolvimento.
- Transformar ameaças em itens de backlog.
- Definir dono e prazo por mitigação.
- Revisitar quando a arquitetura mudar.
Como a SECVOLT ajuda
Facilitamos sessões de modelagem de ameaças e ajudamos a transformar os riscos em decisões concretas de arquitetura e backlog. O trabalho é guiado por referências como STRIDE e OWASP, sem prometer que tudo será previsto.
Começamos por um diagnóstico curto: quais fluxos são mais críticos, onde estão as fronteiras de confiança e o que precisa entrar no desenho antes de virar código.
Perguntas frequentes
O que é STRIDE?
É um acrônimo para seis tipos de ameaça — spoofing, tampering, repudiation, information disclosure, denial of service e elevation of privilege. Funciona como checklist para não esquecer categorias de risco ao analisar um fluxo.
Quando fazer modelagem de ameaças?
O melhor momento é no desenho de algo novo — serviços, integrações, fluxos com dados sensíveis — e sempre que a arquitetura mudar de forma relevante.
Precisa de ferramenta específica?
Não. Diagramas, quadros e templates bastam para começar. O valor está na conversa sobre fluxos e confiança e nas decisões que ela gera, não na ferramenta.
Como saber se a modelagem funcionou?
Se as ameaças viraram itens de backlog com dono e prazo, e o desenho mudou por causa delas. Documento de riscos que não altera o produto não é resultado.