Modelação de ameaças: transformar a arquitetura em decisões de segurança

A modelação de ameaças pergunta o que pode correr mal num determinado sistema e o que a equipa deve fazer a esse respeito. O seu resultado útil não é um catálogo de possibilidades assustadoras. É um conjunto de decisões de conceção e implementação ligadas à arquitetura, com responsáveis e evidências de que as defesas escolhidas funcionam.

Para um CTO, a questão central é se a engenharia consegue explicar como é que as propriedades de segurança importantes resistem ao comportamento real do sistema: novas tentativas, tarefas em segundo plano, ações privilegiadas de suporte, indisponibilidades de fornecedores e entradas maliciosas. Um diagrama torna essas conversas concretas. Um modelo de ameaças mantido transforma as conclusões em trabalho de entrega.

A orientação da OWASP sobre modelação de ameaças fornece uma base útil: compreender o sistema, identificar ameaças, decidir como responder e avaliar se o trabalho é suficiente. O fluxo de trabalho abaixo aplica esse raciocínio às decisões de engenharia.

Descrever o sistema antes de discutir ataques

Comece por uma capacidade delimitada, como as exportações de clientes, a iniciação de pagamentos ou as atualizações de dispositivos. Modelar uma plataforma inteira de uma só vez produz frequentemente observações superficiais, porque ninguém consegue explicar todas as dependências com detalhe suficiente.

Defina os ativos e os objetivos de segurança em termos operacionais. «Proteger os dados dos clientes» é demasiado amplo. «Um utilizador autenticado só pode exportar registos pertencentes ao seu tenant autorizado» dá à equipa uma propriedade para testar. Outros objetivos podem dizer respeito à integridade das transações, à disponibilidade do serviço, à recuperação ou à atribuição de ações administrativas.

Identifique utilizadores, serviços, repositórios de dados, dependências externas, pontos de entrada e fronteiras de confiança. Desenhe os fluxos de dados importantes, incluindo o processamento assíncrono e os caminhos administrativos. Indique nos fluxos os dados transportados, o mecanismo de autenticação e o contexto de autorização, quando estes afetam a análise.

Uma fronteira de confiança marca uma mudança de pressupostos ou de autoridade, e não necessariamente um perímetro de rede. Um navegador que chama uma API atravessa uma fronteira. Um worker partilhado que atua em nome de um cliente atravessa outra, mesmo que ambos os serviços corram no mesmo cluster.

Numa aplicação multi-tenant, mostre onde a identidade do tenant é estabelecida e como chega às verificações de autorização, às tarefas em segundo plano e às exportações. Inclua identidades de serviço, acesso ao armazenamento de objetos, ferramentas de suporte e callbacks externos. Caso contrário, o diagrama pode descrever o caminho ideal e omitir os caminhos com maior probabilidade de contornar o isolamento.

Registe os pressupostos separadamente dos factos. «A fila não pode ser escrita por clientes» precisa de evidências de configuração que o sustentem. As incógnitas devem tornar-se tarefas de investigação, e não defesas aceites em silêncio.

Escolher um método que ajude a equipa a raciocinar

Um método fornece pistas e estrutura. Não determina que ameaças são mais importantes, não prova que uma conceção é segura nem substitui o conhecimento do sistema.

STRIDE para pistas sistemáticas

O STRIDE analisa seis categorias. Aplique-as aos componentes, fluxos e fronteiras relevantes, em vez de forçar todas as categorias em todos os elementos do diagrama.

Um cenário pode abranger várias categorias. Mantenha um único registo acionável quando adequado, em vez de criar pedidos duplicados para satisfazer a taxonomia.

Outros métodos para outras perguntas

O PASTA, Process for Attack Simulation and Threat Analysis, oferece uma abordagem de sete fases orientada para o risco, que liga objetivos de negócio, âmbito técnico, decomposição, análise de ameaças e vulnerabilidades, modelação de ataques e tratamento de riscos. Adequa-se a análises mais profundas em que o comportamento do atacante e as consequências para o negócio precisam de atenção explícita.

As árvores de ataque partem de um objetivo do atacante e decompõem-no em caminhos alternativos ou combinados. Para «obter a exportação de outro tenant», as alternativas podem incluir contornar a autorização da API, confundir o contexto de tenant do worker ou roubar uma credencial de descarga. As relações E (AND) representam condições que têm de ocorrer em conjunto; as relações OU (OR) representam alternativas.

O VAST, Visual, Agile, and Simple Threat modeling, privilegia uma modelação escalável que abrange perspetivas aplicacionais e operacionais. As equipas que o considerem devem analisar se as suas ferramentas e o seu processo de desenvolvimento conseguem manter essas perspetivas de forma coerente.

Uma recomendação prática para começar é um diagrama de fluxo de dados com STRIDE, seguido de uma árvore de ataque para o cenário mais grave. Mais metodologia só é útil quando melhora as decisões.

Conduzir a revisão em torno de cenários concretos

Reúna as pessoas que conhecem a implementação e o funcionamento: um programador, um arquiteto ou líder técnico, um revisor de segurança e alguém familiarizado com o comportamento em produção. Inclua especialistas de produto, privacidade ou fornecedores quando o seu conhecimento afetar o âmbito.

Antes da sessão, faça circular o diagrama, os objetivos de segurança, a configuração relevante e os pressupostos por resolver. Durante a revisão, percorra um pedido ou evento desde a entrada até à conclusão. Pergunte onde muda a identidade, onde os dados persistem, o que é repetido e que componente tem autoridade para aprovar uma ação.

Escreva as ameaças como cenários, não como rótulos. «Problema de autorização» não é suficientemente útil. Uma formulação mais sólida é: «Um utilizador autenticado substitui o identificador de exportação de outro tenant; o endpoint de descarga verifica o início de sessão, mas não a propriedade do objeto, expondo registos de clientes.»

Separe três conceitos:

• Uma ameaça descreve uma ação ou evento adverso, como a obtenção não autorizada de uma exportação.
• Uma vulnerabilidade é uma fragilidade que a pode possibilitar, como uma verificação de propriedade em falta.
• O risco considera a probabilidade e a consequência do cenário no ambiente real.

Uma ameaça pode merecer investigação antes de uma vulnerabilidade ser confirmada. Do mesmo modo, encontrar uma fragilidade não estabelece que todos os ataques imagináveis são exequíveis.

Inclua a utilização abusiva por utilizadores legítimos, pessoas internas com privilégios, erros de configuração e falhas de fornecedores, a par dos ataques externos. Pergunte o que acontece quando uma dependência excede o tempo limite ou devolve uma resposta inesperada. Comportamentos de falha aberta (fail-open) e novas tentativas inconsistentes surgem frequentemente nestas discussões.

Exemplo prático: um pipeline de exportação multi-tenant

O exemplo seguinte é ilustrativo. Suponha que uma aplicação SaaS tem um cliente de navegador, uma API, uma base de dados partilhada, uma fila de tarefas, um worker de exportação e armazenamento de objetos. Os utilizadores dos tenants pedem exportações em CSV; o worker gera os ficheiros e a API emite ligações de descarga temporárias. Os administradores de suporte têm uma interface de resolução de problemas separada.

Os objetivos de segurança são o isolamento entre tenants, a iniciação autorizada de exportações, o consumo limitado de recursos e a atribuição das ações de suporte. Suponha que o worker tem um acesso à base de dados suficientemente amplo para servir vários tenants. Isso faz do tratamento do contexto de tenant uma decisão central, e não um pormenor menor de implementação.

Acompanhar a autoridade ao longo do fluxo

Na API, o principal autenticado é associado à pertença autorizada a um tenant. Um identificador de tenant fornecido pelo navegador é um pedido de seleção, não uma prova de autorização. A API verifica a pertença e a permissão de exportação antes de criar um registo de tarefa imutável que contém o tenant autorizado, o requerente e o âmbito de exportação permitido.

A mensagem na fila referencia esse registo. O worker valida a tarefa e aplica um acesso aos dados limitado ao tenant ao produzir a exportação. Os metadados do armazenamento associam o objeto resultante à tarefa e ao tenant. Antes de emitir uma ligação de descarga, a API verifica a autorização do requerente atual face a essa associação.

Esta conceção continua a precisar de decisões explícitas sobre a revogação de acessos: um utilizador que perde a pertença depois de pedir uma exportação deve manter o acesso ao ficheiro concluído? A equipa tem de definir essa política e implementá-la de forma coerente.

Converter cenários em controlos e testes

As ligações temporárias introduzem uma janela de exposição residual: a posse pode permitir o acesso até à expiração, consoante o mecanismo. A equipa deve decidir se isso é aceitável para os dados em causa ou se as descargas precisam de um intermediário autenticado com verificações de autorização atuais.

Não feche o modelo depois de testar apenas a API síncrona. Verifique tarefas diferidas, novas tentativas, pedidos cancelados, pertenças expiradas, tenants eliminados e falhas parciais. Por exemplo, uma tarefa repetida não pode reutilizar um objeto associado a outro tenant nem publicar como bem sucedida uma exportação incompleta.

O resultado é uma arquitetura revista, um registo de ameaças, tarefas de implementação e resultados de verificação ligados. Não é apenas o diagrama.

Priorizar em função da exposição e das consequências

Priorize os cenários plausíveis em função da exposição, do impacto, das condições prévias e das defesas existentes. Distinga uma falha de autorização diretamente acessível de um cenário que exige vários comprometimentos não comprovados. Considere os dados afetados, a perturbação do serviço, as consequências financeiras, as implicações para a segurança física e a dificuldade de recuperação, quando relevante.

Use uma escala simples e coerente se ajudar a equipa, mas registe a fundamentação da classificação. Uma pontuação numérica com entradas não explicadas cria uma falsa precisão. O CVSS pode informar a avaliação de uma vulnerabilidade concreta; não substitui a compreensão do impacto no negócio nem um caso de abuso arquitetural.

As opções de tratamento incluem alterar a conceção, reduzir a exposição, acrescentar controlos preventivos ou de deteção, evitar a capacidade ou aceitar o risco remanescente. Os contratos com fornecedores podem repartir responsabilidades, mas não eliminam os modos de falha técnicos.

O risco residual deve ter um decisor identificado, uma razão, um prazo de validade ou um fator de revisão e quaisquer condições de funcionamento. A conclusão da engenharia e a aceitação do risco são decisões diferentes. Um pedido pode estar concluído enquanto persiste um risco significativo.

Levar o modelo para a entrega e para as evidências

Para cada cenário material, registe o seu identificador, os componentes afetados, as condições prévias, a consequência, as defesas existentes, o tratamento, o responsável e o método de verificação. Ligue o registo à versão da arquitetura e ao trabalho de implementação relevante, para que os revisores saibam que conceção foi avaliada.

Traduza os tratamentos em critérios de aceitação testáveis. «Melhorar o controlo de acessos» é vago. «O tenant A não consegue pedir, consultar, cancelar nem descarregar a exportação do tenant B através de nenhum endpoint suportado» identifica um comportamento que a engenharia pode verificar.

Use evidências adequadas à afirmação:

• A revisão de código pode estabelecer onde a autorização é aplicada.
• A inspeção da configuração pode estabelecer as permissões dos serviços e a exposição do armazenamento.
• Os testes de integração negativos podem exercitar as fronteiras entre tenants e de privilégios.
• Os testes de carga e de injeção de falhas podem examinar a disponibilidade e o comportamento em caso de falha.
• Os testes de intrusão direcionados podem investigar caminhos de ataque que precisam de exploração independente.

Nenhum artefacto isolado prova o modelo inteiro. Uma captura de ecrã de uma definição não prova que todos os workers a utilizam, e um teste aprovado não demonstra um caminho não testado. Registe o ambiente de teste, o âmbito, os resultados e as limitações.

A modelação de ameaças complementa a programação segura, a avaliação de dependências, a análise de vulnerabilidades e os testes de intrusão. O seu contributo distintivo é o raciocínio arquitetural: pode revelar uma atribuição perigosa de autoridade mesmo quando os componentes individuais não têm nenhuma vulnerabilidade conhecida.

Manter as ferramentas e a automatização subordinadas ao modelo

Um diagrama partilhado e um registo estruturado podem suportar uma primeira revisão focada. As ferramentas dedicadas tornam-se úteis quando as equipas precisam de bibliotecas de componentes reutilizáveis, identificadores coerentes, colaboração e ligações fiáveis entre as ameaças e os registos de entrega.

Avalie se uma ferramenta suporta fronteiras de confiança, cenários personalizados, histórico de versões, registos exportáveis, responsabilidades e referências a evidências. As ameaças geradas automaticamente são pistas a examinar, não constatações confirmadas. Listas longas sem contexto podem esconder as poucas decisões que importam.

O apoio de IA pode redigir descrições de cenários, sugerir caminhos em falta ou comparar alterações com um modelo anterior. Os revisores humanos continuam a ter de validar a arquitetura, a exequibilidade, a cobertura das mitigações e o risco residual. Mantenha diagramas confidenciais e credenciais fora de serviços não aprovados. A geração de modelos de ameaças é também distinta da deteção em tempo de execução; produzir um modelo não estabelece monitorização contínua nem correção automática.

Rever quando a arquitetura ou os pressupostos mudam

Atualize o modelo em caso de novas integrações, alterações de autenticação, ações privilegiadas, categorias de dados, exposição de rede e alterações importantes de dependências. Um incidente ou um resultado de teste inesperado pode também invalidar um pressuposto anterior.

Sistemas diferentes precisam de ênfases diferentes. As aplicações cloud exigem atenção às permissões de identidade e ao acesso ao plano de gestão. Os clientes móveis devem ser tratados como ambientes controlados pelo atacante, e não como pontos de aplicação de confiança. Os dispositivos ligados introduzem acesso físico, integridade das atualizações, recuperação e, potencialmente, consequências para a segurança física. As funcionalidades com IA acrescentam conteúdo não fiável e fronteiras de utilização de ferramentas; a autorização tem de restringir as ações independentemente do resultado do modelo.

Meça se os fluxos importantes têm modelos atuais, se os tratamentos de alta prioridade têm evidências de verificação, se há pressupostos por resolver e se os riscos aceites têm revisões em atraso. Contar apenas ameaças premeia o volume e não a análise útil. Peça periodicamente a um revisor independente que conteste um cenário crítico e as respetivas evidências.

Fazer uma primeira revisão suficientemente pequena para ser concluída

A Secani pode preservar o fluxo de trabalho em torno destas decisões ao modelar os sistemas e dependências relevantes, atribuir responsáveis e revisores e ligar as evidências a requisitos, controlos e decisões. Os pressupostos por resolver tornam-se tarefas; o material de origem e as aprovações humanas permanecem associados à revisão. Quaisquer sugestões assistidas por IA devem ser verificadas antes da aprovação.

Comece por um fluxo de dados crítico. Acompanhe a sua autoridade de ponta a ponta, identifique um punhado de cenários plausíveis e termine com tratamentos com responsável e critérios de verificação explícitos. Agende a próxima revisão em função das alterações de arquitetura que possam invalidar essas decisões.