Modelagem de ameaças

Modelar ameaças é analisar uma representação do sistema para descobrir o que pode comprometer a sua segurança e a privacidade, e decidir o que fazer a respeito. O resultado não é um relatório para a gaveta: é um registro vivo de ameaças e mitigações, que orienta quais controles implementar.

A boa prática SEC01-BP07 pede exatamente isso: identificar ameaças, manter esse registro atualizado e priorizar mitigações para prevenir, detectar e responder. O risco de não fazer é classificado como alto.

O quanto antes, de preferência na fase de design. Como acontece com bugs, ameaças encontradas cedo custam menos para corrigir: mudar um diagrama é mais barato que reescrever um serviço em produção. É o mesmo raciocínio do shift-left.

Depois, revisite o modelo sempre que houver:

• uma mudança relevante na arquitetura (novo fluxo de dados, nova integração externa, nova conta);
• uma mudança no cenário de ameaças (por exemplo, uma nova técnica de ataque contra algo que você usa);
• a adoção de um serviço ou recurso novo (tema da lição 15).

Existem vários métodos. O Well-Architected sugere começar pelo arcabouço de quatro perguntas de Adam Shostack, o mesmo adotado pelo Threat Modeling Manifesto:

1. No que estamos trabalhando? (What are we working on?; alguns textos da AWS usam "o que estamos construindo?") — alinhar o que está sendo construído, o escopo e as suposições. Normalmente com um diagrama.
2. O que pode dar errado? (What can go wrong?) — levantar ameaças: ações ou eventos, intencionais ou acidentais, com impacto indesejado.
3. O que vamos fazer a respeito? (What are we going to do about it?) — definir mitigações. Inclui perguntar quem é responsável: você ou a AWS, conforme o modelo de responsabilidade compartilhada.
4. Fizemos um bom trabalho? (Did we do a good job? — no Manifesto, good enough) — revisar o resultado e melhorar a qualidade e a velocidade dos próximos modelos.

A forma mais comum de responder à primeira pergunta é um diagrama de fluxo de dados (DFD). Ele mostra quatro tipos de elemento: entidades externas (usuários, sistemas de terceiros), processos (uma função Lambda, um container), repositórios de dados (bucket S3, tabela DynamoDB) e os fluxos entre eles.

Sobre o diagrama, marque os limites de confiança (trust boundaries): os pontos em que o dado passa de uma zona com um nível de confiança para outra. Exemplos na AWS: internet → API Gateway; uma conta → outra conta; uma sub-rede pública → uma sub-rede privada; seu código → um serviço de terceiro. É nesses cruzamentos que a maior parte das ameaças aparece.

Anote também as suposições ("o IdP corporativo exige MFA", "o bucket só recebe tráfego da VPC") — elas delimitam o escopo e, se falharem, viram ameaças.

STRIDE é um mnemônico de seis categorias que ajuda a responder "o que pode dar errado?":

Categoria	Propriedade violada	Exemplo na AWS	Mitigação típica
Spoofing (falsificação)	Autenticação	Chave de acesso vazada usada para chamar APIs como se fosse a aplicação.	Roles com credenciais temporárias, MFA, federação.
Tampering (adulteração)	Integridade	Alguém altera objetos de log em um bucket S3 para apagar rastros.	S3 Object Lock, validação de integridade de logs do CloudTrail.
Repudiation (repúdio)	Não repúdio	Uma mudança em produção sem registro de quem fez.	Trail da organização no CloudTrail, identidades individuais.
Information disclosure	Confidencialidade	Bucket com dados pessoais exposto publicamente.	S3 Block Public Access, criptografia com AWS KMS, IAM Access Analyzer.
Denial of service	Disponibilidade	Inundação de requisições em uma API pública.	AWS WAF com regras baseadas em taxa, throttling do API Gateway, AWS Shield.
Elevation of privilege	Autorização	Role com iam:PassRole amplo usada para obter uma role mais poderosa.	Menor privilégio, permissions boundaries, SCPs.

Para as mitigações do lado do cliente, use o capítulo de segurança da documentação de cada serviço: ele lista os controles disponíveis (identidade, criptografia, rede, logging).

A AWS mantém o Threat Composer, ferramenta de código aberto (licença Apache-2.0) citada na própria SEC01-BP07. Ela ajuda a:

• escrever ameaças com uma gramática de ameaças: "uma [fonte de ameaça] com [pré-requisitos] pode [ação] levando a [impacto], afetando [ativos]";
• registrar diagramas, suposições e mitigações ligadas a cada ameaça;
• gerar um modelo legível por pessoas e outro em JSON, versionável no Git (threat model as code);
• apontar lacunas de qualidade e cobertura em um painel de insights.

Dá para testar na demo pública (os dados ficam no navegador) e abrir o workspace de exemplo, que modela a própria ferramenta. O roteiro desta trilha está no template de modelagem de ameaças.

Modelagem de ameaças responde a quatro perguntas: no que estamos trabalhando, o que pode dar errado, o que vamos fazer e se fizemos um bom trabalho. Comece no design, desenhe o fluxo de dados e os limites de confiança, use STRIDE para não esquecer categorias e mantenha o modelo vivo. Na próxima lição, como priorizar as mitigações encontradas.

SEC01-BP07 Identify threats and prioritize mitigations using a threat model

• How to approach threat modeling — AWS Security Blog
• Threat Modeling Manifesto
• Threat Composer — GitHub (awslabs)
• Exemplo de capítulo de segurança: Security in Amazon S3