Threat Modeling com Data Flow Diagrams: do fluxo de dados às ameaças e mitigações

Um sistema não se torna seguro porque possui autenticação, criptografia ou um firewall. Ele se torna mais seguro quando o time entende o que está protegendo, como os dados atravessam a arquitetura, onde a confiança muda e de que formas o sistema pode ser abusado.

Este artigo inaugura a série Engineering Security in Practice.

A proposta da série não é apresentar segurança como uma coleção de produtos, siglas ou serviços isolados. O objetivo é construir um método de engenharia que permita responder, para cada arquitetura:

• qual risco existe;
• onde esse risco se manifesta;
• quem ou o que pode explorá-lo;
• qual controle previne, detecta ou reduz o impacto;
• como validar se o controle funciona;
• qual risco residual permanece;
• quando o modelo precisa ser revisado.

Neste primeiro capítulo, usaremos Threat Modeling e Data Flow Diagrams — DFDs para transformar uma arquitetura em um conjunto de ameaças, decisões e ações rastreáveis.

O estudo de caso será um sistema modular de saúde com pacientes, diagnósticos, documentos, mensageria, auditoria e integrações. O domínio foi escolhido porque combina requisitos técnicos comuns a muitos sistemas:

• autenticação;
• autorização por recurso;
• isolamento entre usuários ou tenants;
• dados pessoais e dados sensíveis;
• documentos;
• processamento assíncrono;
• auditoria;
• integrações externas;
• continuidade operacional.

O método, porém, é independente de provedor e pode ser aplicado a e-commerce, fintech, SaaS B2B, sistemas governamentais, IoT, plataformas educacionais e aplicações com IA.

1. O problema: diagramas de arquitetura não são modelos de segurança

Um diagrama de arquitetura tradicional costuma responder:

• quais componentes existem;
• onde estão implantados;
• quais tecnologias são usadas;
• como os serviços estão conectados;
• quais bancos, filas e APIs fazem parte da solução.

Isso é necessário, mas insuficiente para segurança.

Considere o diagrama simplificado:

Ele comunica a estrutura básica, mas não responde:

• quais dados passam em cada seta;
• quem controla cada componente;
• onde a identidade é verificada;
• onde a autorização é aplicada;
• quais fluxos carregam dados sensíveis;
• onde a confiança muda;
• quem pode publicar na mensageria;
• como o consumidor valida a origem do evento;
• se o banco é acessado por múltiplos módulos;
• se um identificador pode ser alterado para acessar outro paciente;
• se dados sensíveis aparecem em logs;
• o que ocorre quando um consumidor processa a mesma mensagem duas vezes.

Um Data Flow Diagram orientado a Threat Modeling torna essas questões explícitas.

A OWASP trata DFDs como uma das abordagens mais comuns para modelar um sistema antes de identificar ameaças. A AWS também recomenda usar diagramas, como DFDs, para estabelecer o escopo e compreender o workload antes de priorizar mitigações. [1][2]

2. O que é Threat Modeling

Threat Modeling é um processo estruturado para:

1. compreender o sistema;
2. identificar o que pode dar errado;
3. decidir o que será feito;
4. validar se a resposta foi suficiente.

A OWASP organiza a prática por meio de quatro perguntas:

1. Em que estamos trabalhando?
2. O que pode dar errado?
3. O que faremos a respeito?
4. Fizemos um bom trabalho? [1]

Essa estrutura corrige um erro comum: começar pela ferramenta ou pelo controle.

Uma conversa de segurança frequentemente começa assim:

Devemos usar WAF, criptografia, SIEM ou Zero Trust?

A pergunta correta vem antes:

Qual ameaça estamos tentando reduzir?

Um controle só pode ser avaliado quando existe clareza sobre:

• ativo protegido;
• ameaça;
• caminho de ataque;
• impacto;
• probabilidade;
• contexto operacional;
• risco residual.

A AWS classifica a ausência de Threat Modeling como uma prática de alto risco no pilar de segurança do Well-Architected Framework e recomenda manter um registro atualizado de ameaças e mitigações, revisado conforme o workload e o cenário de segurança evoluem. [2]

3. O que Threat Modeling não é

3.1 Não é pentest

Pentest testa uma implementação existente, geralmente procurando formas reais de explorar falhas.

Threat Modeling pode ocorrer antes da implementação e busca identificar problemas de design.

Threat Modeling
    identifica riscos de design
            ↓
Requisitos e controles de segurança
            ↓
Implementação
            ↓
Testes automatizados e revisão
            ↓
Pentest
    valida cenários na solução implementada

3.2 Não é vulnerability scanning

Um scanner identifica vulnerabilidades conhecidas em:

• bibliotecas;
• imagens;
• pacotes;
• sistemas operacionais;
• configurações específicas.

Ele dificilmente entende sozinho uma falha como:

Um profissional autenticado consegue acessar o documento de outra organização porque o endpoint valida apenas o documentId, mas não o tenantId.

Essa é uma falha de autorização contextual. Threat Modeling ajuda a encontrá-la ainda no design.

3.3 Não é um checklist universal

Checklists ajudam, mas não substituem contexto.

A mesma tecnologia pode representar riscos diferentes em arquiteturas diferentes. Uma fila pode ser:

• apenas transporte de notificações sem dados sensíveis;
• transporte de diagnósticos;
• canal de comandos administrativos;
• mecanismo de integração entre tenants.

O componente é o mesmo; o risco não.

3.4 Não elimina todos os riscos

O objetivo não é produzir uma arquitetura “sem ameaças”.

O objetivo é:

• identificar;
• priorizar;
• mitigar;
• aceitar conscientemente;
• transferir quando aplicável;
• monitorar;
• revisar.

4. O que é um Data Flow Diagram

Um DFD representa como os dados entram, circulam, são processados e são armazenados.

Os elementos fundamentais são:

A Microsoft destaca esses mesmos elementos em seu treinamento de DFD para Threat Modeling, incluindo processo, data store, entidade externa, fluxo e trust boundary. [3]

4.1 Entidade externa

Exemplos:

• paciente;
• profissional de saúde;
• administrador;
• sistema parceiro;
• gateway de pagamento;
• provedor de identidade;
• serviço de assinatura;
• webhook de terceiro.

Entidade externa não significa necessariamente maliciosa. Significa que ela está fora do limite de controle daquele processo.

4.2 Processo

Exemplos:

• frontend;
• API Gateway;
• Patient Service;
• Document Service;
• serviço de autorização;
• worker;
• função serverless;
• agente de IA.

O processo deve ter responsabilidade clara.

Um processo chamado Core Service que valida, coordena, persiste, publica e integra tudo pode esconder acoplamento e dificultar a análise.

4.3 Data store

Exemplos:

• banco relacional;
• object storage;
• cache;
• fila;
• vector store;
• arquivo;
• sistema legado;
• índice de busca.

O DFD deve registrar não apenas “Database”, mas que dados estão armazenados e qual módulo é responsável por eles.

4.4 Data flow

Uma seta sem descrição tem pouco valor.

Evite:

Patient Service → Database

Prefira:

Patient Service → Database
Dados: cadastro, vínculo com clínica e metadados de consentimento
Protocolo: conexão privada com TLS
Autorização: role exclusiva do serviço

4.5 Trust boundary

Trust boundary é o ponto em que mudam:

• identidade;
• controle administrativo;
• tenant;
• nível de privilégio;
• rede;
• provedor;
• classificação do dado;
• política de segurança;
• contexto de execução.

Exemplos:

Internet → aplicação
Frontend → backend
Conta cloud A → conta cloud B
Tenant A → plataforma compartilhada
Aplicação → provedor externo
Serviço → banco
Usuário → função administrativa
Sistema → modelo de IA

A OWASP e a documentação de DFD da Microsoft descrevem trust boundaries como mudanças de zona ou de controle que precisam ser explicitamente modeladas. [3][10]

4.6 Como marcar fronteiras sem confusão

Uma fronteira de confiança não é sinônimo de firewall, VPC ou subnet. Ela representa uma mudança relevante nas suposições de confiança ou no controle administrativo. Para evitar diagramas ambíguos, registre a dimensão da fronteira:

Uma mesma conexão pode cruzar mais de uma dimensão. O modelo deve explicitar isso em vez de sugerir que uma única linha tracejada resolve toda a análise.

5. O estudo de caso

Vamos modelar um sistema com os seguintes módulos:

• Identity Service — autenticação e sessão;
• Patient Service — cadastro e vínculo do paciente;
• Diagnostic Service — registro de diagnósticos;
• Document Service — geração e acesso a documentos;
• Notification Service — notificações;
• Audit Service — trilha de auditoria;
• Message Broker — distribuição de eventos;
• Object Storage — documentos;
• Databases — dados de domínio separados.

5.1 Requisitos de negócio

1. Um paciente pode consultar seus próprios documentos.
2. Um profissional autorizado pode registrar diagnósticos.
3. Um profissional só pode atuar dentro da clínica ou tenant ao qual está vinculado.
4. Um diagnóstico criado deve gerar um documento de forma assíncrona.
5. A operação precisa ser auditável.
6. O link de download deve expirar.
7. Dados clínicos não devem aparecer em logs operacionais.
8. Falhas de notificação não podem desfazer o diagnóstico registrado.

5.2 Suposições iniciais

• autenticação usa um provedor de identidade;
• cada requisição possui subject, tenantId e roles;
• cada módulo possui banco próprio ou schema isolado;
• eventos são enviados por mensageria;
• documentos ficam em object storage privado;
• logs técnicos e de auditoria são separados;
• dados sensíveis são criptografados em trânsito e em repouso.

Suposições devem ser registradas porque podem estar erradas. Uma suposição não verificada é uma possível ameaça futura.

5.3 Escopo, atores e exclusões

O recorte precisa declarar quem pode atacar, falhar ou operar o sistema:

Nesta primeira versão, o foco é o caminho diagnóstico → documento → auditoria. Backup e restauração, disaster recovery, endpoint management, segurança física e conformidade jurídica ficam fora do recorte, mas devem aparecer como itens pendentes ou em modelos complementares.

O caso é fictício e educacional. A expressão “sistema de saúde” não significa que o desenho esteja pronto para uso clínico ou regulado.

6. DFD nível 0: contexto

6.1 Trust boundaries no nível 0

Esse diagrama revela três fronteiras:

1. usuários externos para a plataforma;
2. plataforma para provedor de identidade;
3. plataforma para serviço de notificações.

7. DFD nível 1: componentes e fluxos

7.1 Legenda operacional dos DFDs

Para que o diagrama seja útil em uma revisão real, cada fluxo crítico deve ter contexto suficiente para responder:

• qual protocolo e mecanismo de transporte são usados;
• qual identidade produz e consome o fluxo;
• qual ação está sendo autorizada;
• qual é o tenant e o proprietário do dado;
• qual classificação o payload possui;
• se o fluxo é síncrono ou assíncrono;
• onde ocorre criptografia e onde ela termina;
• qual retenção existe em banco, fila, DLQ, log e backup;
• qual equipe é responsável e qual evidência valida o controle.

O Gateway pode validar o token e propagar um contexto de identidade, mas o serviço de domínio precisa revalidar autorização de recurso, tenant e ação. A borda não conhece todas as regras clínicas ou relacionamentos entre profissional e paciente.

O fluxo acima separa autenticação de autorização e mostra que a emissão de uma URL temporária acontece somente depois da decisão de acesso.

8. Catálogo de fluxos

8.1 Princípio de minimização

Não envie o diagnóstico completo em todos os eventos apenas porque ele está disponível.

Prefira:

{
  "eventType": "DiagnosticCreated",
  "eventId": "evt-123",
  "diagnosticId": "diag-456",
  "patientReference": "pat-789",
  "tenantId": "clinic-001",
  "occurredAt": "2026-07-26T15:00:00Z",
  "schemaVersion": 1
}

O consumidor autorizado busca os dados necessários pelo identificador.

Isso reduz:

• exposição em filas;
• cópias desnecessárias;
• vazamento em dead-letter queues;
• risco em observabilidade;
• dificuldade de retenção e exclusão.

8.2 Metadados mínimos por fluxo

Além do catálogo funcional, mantenha um inventário técnico para os fluxos críticos:

Em eventos assíncronos, adicione producerId, consumerId, correlationId, causationId, schemaVersion, occurredAt, idempotencyKey e uma política explícita para replay, duplicidade, reordenação e DLQ.

9. Classificação de dados

Antes de aplicar STRIDE, classifique os dados.

Uma taxonomia interna simples:

Subcategorias úteis:

• Personal Data;
• Sensitive Personal Data;
• Health Data;
• Payment Data;
• Authentication Secrets;
• Security Telemetry;
• Audit Evidence.

O NIST destaca que classificar dados permite descobrir, identificar e rotular informações sensíveis, apoiando a redução do risco de perda ou tratamento inadequado. [5]

9.1 Classificação no estudo de caso

Este artigo usa classificações técnicas. Obrigações legais devem ser avaliadas segundo a jurisdição e o contexto da organização.

9.2 Privacidade e abuso além da classificação

Classificar o dado não basta. O modelo também deve perguntar:

• o fluxo coleta mais dados do que a finalidade exige;
• existe uso secundário ou exportação em massa;
• um operador pode consultar muitos pacientes sem justificativa;
• a identidade pode atuar em emergência e como isso é auditado;
• a retenção de logs, eventos, DLQs e backups excede a retenção do dado original;
• uma integração externa recebe dados que não precisa conhecer.

STRIDE organiza ameaças de segurança, mas não substitui uma análise de privacidade ou de abuso. Para dados pessoais e de saúde, complemente o modelo com propósito de uso, minimização, acesso emergencial, insider misuse e risco de correlação. A referência [14] apresenta o Privacy Framework do NIST como vocabulário complementar; isso não substitui avaliação jurídica ou regulatória.

10. Aplicando STRIDE

STRIDE organiza ameaças em seis categorias:

A OWASP apresenta STRIDE como uma técnica madura e flexível para identificar ameaças depois que o sistema foi modelado. [6]

10.1 STRIDE não cobre todo o espaço de risco

STRIDE é um excelente mecanismo de geração de ameaças, mas não deve ser tratado como uma lista universal. Complemente-o quando o contexto exigir:

Use STRIDE por elemento e por fluxo, escolhendo as categorias que fazem sentido para cada contexto. Não é necessário preencher as seis categorias para todos os componentes.

11. STRIDE por elemento

11.1 Gateway

Spoofing

Cenário: token forjado, roubado ou emitido para outro audience.

Controles:

• validar assinatura;
• validar issuer;
• validar audience;
• validar expiração;
• limitar algoritmos aceitos;
• reduzir duração de sessões;
• MFA para operações sensíveis.

Denial of Service

Cenário: alto volume de requisições esgota capacidade.

Controles:

• rate limiting;
• quotas;
• WAF;
• cache;
• autoscaling;
• circuit breaker;
• limites por tenant.

Information Disclosure

Cenário: mensagens de erro retornam stack trace ou dados internos.

Controles:

• erro externo padronizado;
• correlation ID;
• detalhes somente em logs restritos;
• redaction.

11.2 Authorization Policy Enforcement

Elevation of Privilege

Cenário: o sistema valida role, mas ignora ownership e tenant.

Exemplo vulnerável:

SELECT *
FROM documents
WHERE id = :documentId;

Exemplo mais seguro:

SELECT *
FROM documents
WHERE id = :documentId
  AND tenant_id = :tenantId
  AND patient_id IN (
      SELECT patient_id
      FROM authorized_patient_access
      WHERE professional_id = :subject
  );

Controles:

• autorização por ação e recurso;
• tenant no filtro;
• policy consistente;
• testes negativos;
• deny by default;
• revisão de policies.

11.3 Message Broker

Spoofing

Cenário: serviço não autorizado publica DiagnosticCreated.

Controles:

• identidade por workload;
• ACL por tópico ou fila;
• assinatura de mensagem quando necessário;
• isolamento de ambientes;
• proibir credenciais compartilhadas.

Tampering

Cenário: payload alterado em trânsito ou por produtor comprometido.

Controles:

• TLS;
• schema validation;
• envelope com versionamento;
• integridade;
• validação do produtor;
• consumer-side validation.

Repudiation

Cenário: não é possível provar qual serviço publicou o evento.

Controles:

• event ID;
• producer identity;
• timestamp;
• trace ID;
• append-only audit;
• logs de broker.

Denial of Service

Cenário: backlog cresce indefinidamente ou poison message bloqueia o consumidor.

Controles:

• DLQ;
• retry com backoff;
• limite de tentativas;
• autoscaling;
• alarmes de idade da mensagem;
• isolamento por consumidor;
• payload máximo.

11.4 Document Service e Object Storage

Information Disclosure

Cenário: URL permanente, bucket público ou chave previsível.

Controles:

• armazenamento privado;
• URLs temporárias;
• autorização antes da emissão;
• chave não enumerável;
• criptografia;
• monitoramento de acesso;
• bloqueio de acesso público.

Tampering

Cenário: documento substituído após aprovação.

Controles:

• versionamento;
• digest;
• immutable retention quando aplicável;
• separação entre geração e aprovação;
• auditoria de escrita.

Repudiation

Cenário: não há prova de quem gerou, aprovou ou baixou.

Controles:

• auditoria separada;
• subject;
• tenant;
• documento;
• ação;
• timestamp;
• resultado;
• request ID.

11.5 Autenticação, autorização e identidade de workload

Não trate “JWT válido” como sinônimo de “operação autorizada”. A decisão precisa considerar, quando aplicável:

• issuer, audience, expiração e algoritmo;
• subject, client ou workload que originou a chamada;
• scopes, roles e permissões;
• tenant e recurso alvo;
• vínculo entre profissional e paciente;
• finalidade, estado do recurso e ação;
• revogação, rotação de chaves e clock skew;
• acesso emergencial com justificativa e auditoria.

Para chamadas entre serviços, prefira identidade de workload e credenciais temporárias. Separe a permissão de publicar um evento da permissão de ler documentos. Isso reduz o blast radius e ajuda a evitar confused deputy.

A orientação da OWASP recomenda negar por padrão e validar permissões em toda requisição [11]. Para APIs que recebem identificadores de objeto, a falha correspondente é tratada como Broken Object Level Authorization (BOLA) [12].

12. Registro de ameaças

12.1 Registro operacional e critério de pontuação

A tabela resumida é útil para leitura, mas o registro versionado deve manter pelo menos:

Uma escala 1–5 pode ser usada, desde que o time publique o critério. Por exemplo, impacto considera sensibilidade, integridade clínica, alcance entre tenants, indisponibilidade e recuperação; probabilidade considera exposição, privilégio necessário, complexidade, frequência e controles já comprovados. A classificação “crítica” deve ser consequência dessa regra, não apenas uma impressão editorial.

13. Priorização de riscos

Uma matriz simples:

13.1 Critérios de impacto

• exposição de dados;
• alteração de dados clínicos;
• indisponibilidade;
• impacto regulatório;
• impacto financeiro;
• impacto reputacional;
• alcance entre tenants;
• dificuldade de recuperação;
• capacidade de detecção.

13.2 Critérios de probabilidade

• exposição à internet;
• complexidade do ataque;
• necessidade de credencial;
• controles existentes;
• frequência do fluxo;
• histórico de falhas;
• facilidade de exploração;
• número de atores com acesso.

13.3 Risco residual

Ameaça:
Acesso indevido a documento de outro tenant.

Mitigações:
- autorização por recurso;
- filtro de tenant;
- signed URL de 5 minutos;
- teste negativo;
- auditoria.

Risco residual:
Credencial válida de profissional comprometida ainda pode acessar
documentos permitidos àquele profissional.

Resposta:
MFA, sessões curtas, detecção de comportamento anormal e revogação.

13.4 Aceite de risco e confiança da avaliação

Risco residual não é uma frase final. Para cada risco não eliminado, registre:

• decisão: mitigar, eliminar, transferir ou aceitar;
• responsável por aceitar;
• justificativa;
• prazo de expiração;
• gatilho de reabertura;
• evidência disponível;
• nível de confiança da avaliação.

Uma credencial válida de profissional comprometida é um exemplo de risco residual. MFA, sessões curtas, detecção de comportamento anormal e revogação reduzem o impacto, mas não provam que o risco foi eliminado.

14. Attack Tree

14.1 Objetivo do atacante

Acessar o diagnóstico de outro paciente.

14.2 Por que usar attack trees

Elas ajudam a:

• visualizar caminhos alternativos;
• identificar controles comuns a vários caminhos;
• revelar dependências;
• separar causa, pré-condição e objetivo;
• priorizar controles com maior cobertura.

15. Backlog de mitigações

A tabela deve ser mantida como backlog operacional, não como uma lista decorativa. Cada item precisa de status, prazo, evidência e link para o teste, policy, alerta ou decisão de risco. “Owner” deve identificar uma equipe ou pessoa responsável por concluir e demonstrar o controle.

16. Prevenir, detectar e responder

16.1 Exemplo: acesso indevido a documentos

Prevenir

• autorização por recurso;
• tenant isolation;
• URL temporária;
• armazenamento privado.

Detectar

• volume anormal de downloads;
• acesso sequencial a IDs;
• acesso de região incomum;
• múltiplos pacientes em curto intervalo;
• falhas repetidas de autorização.

Responder

• revogar sessão;
• bloquear identidade;
• reduzir permissões;
• preservar logs;
• investigar escopo;
• notificar responsáveis;
• revisar modelo de ameaças.

17. Como validar as mitigações

A quarta pergunta do Threat Modeling é frequentemente esquecida:

Fizemos um bom trabalho?

17.1 Testes de segurança derivados

Autorização

• usuário A tenta acessar documento do usuário B;
• profissional da clínica A tenta acessar paciente da clínica B;
• role sem permissão tenta publicar evento;
• usuário autenticado sem vínculo tenta consultar diagnóstico.

Mensageria

• payload sem campo obrigatório;
• schemaVersion desconhecida;
• mensagem duplicada;
• mensagem fora de ordem;
• poison message;
• produtor não autorizado.

Documentos

• URL expirada;
• URL reutilizada;
• tentativa de enumerar chave;
• acesso direto sem autorização;
• alteração após geração.

Logging

• token no header;
• diagnóstico no payload;
• CPF em mensagem de erro;
• stack trace retornado ao cliente;
• logs acessíveis a role indevida.

17.2 Evidência de validação

17.3 Cenário end-to-end: T01

Para a ameaça de acesso cross-tenant, a evidência deve atravessar o fluxo inteiro:

actor autorizado na clínica A
  -> altera documentId para um documento da clínica B
  -> API autentica a sessão
  -> policy nega tenant/recurso
  -> serviço não emite URL
  -> auditoria registra deny sem conteúdo clínico
  -> alerta avalia repetição ou enumeração

Exemplo de contrato de teste:

@Test
fun `nao permite que um profissional acesse documento de outro tenant`() {
    val response = client.getDocument(
        subject = professionalFromTenantA,
        documentId = documentFromTenantB,
    )

    assertThat(response.status).isIn(403, 404)
    verify { signedUrlIssuer wasNot Called }
    verify { auditStore.recordDeny(match { it.tenantId == tenantA }) }
}

O teste não deve apenas verificar o status HTTP. Ele precisa confirmar que o efeito colateral sensível, como emissão de URL ou leitura do objeto, não ocorreu.

18. Template do Threat Model

# Threat Model — [Sistema ou feature]

## 1. Escopo

## 2. Objetivos de negócio

## 3. Suposições

## 4. Atores

## 5. Dados e classificação

## 6. Data Flow Diagram

## 7. Trust boundaries

## 8. Registro de ameaças

| ID | Elemento | STRIDE | Cenário | Impacto | Probabilidade |

## 9. Mitigações

| ID | Mitigação | Owner | Prazo | Evidência |

## 10. Riscos aceitos

## 11. Testes de segurança

## 12. Data de revisão

## 13. Mudanças que exigem nova revisão

18.1 Estrutura mínima de artefatos

Um repositório pode manter o modelo de forma pequena e revisável:

threat-model/
  scope.md
  actors-and-assumptions.md
  dfd-level-0.mmd
  dfd-level-1.mmd
  data-classification.md
  flows.md
  threats.yaml
  mitigations.md
  security-tests.md
  review-log.md

A revisão do pull request deve verificar que o DFD, o registro de ameaças, os testes e as decisões de risco evoluíram juntos.

19. Threat Model as Code

O modelo pode ser versionado com:

• Markdown;
• Mermaid;
• PlantUML;
• JSON ou YAML;
• OWASP Threat Dragon;
• ferramentas como código;
• relatórios gerados em CI.

A OWASP disponibiliza o Threat Dragon para criar DFDs, registrar ameaças e mitigações e trabalhar com classificações como STRIDE. [7]

A documentação da AWS também apresenta recursos para registrar ameaças, severidade, classificação STRIDE, evidências e recomendações. Verifique o escopo e a disponibilidade do produto antes de adotá-lo como dependência do processo. [2][8]

19.1 Exemplo de ameaça em YAML

id: T01
title: Cross-tenant document access
component: document-api
flow: F08
category:
  - elevation-of-privilege
  - information-disclosure
asset:
  - clinical-document
scenario: >
  An authenticated user changes the document identifier and accesses
  a document belonging to another tenant.
impact: high
likelihood: medium
risk: critical
mitigations:
  - resource-level-authorization
  - tenant-filter
  - short-lived-signed-url
  - access-audit
owner: document-team
status: open
reviewDate: 2026-08-15

19.2 Validação no CI

O modelo como código ganha valor quando a mudança de arquitetura exige uma evidência mínima no pull request:

O CI pode validar sintaxe Mermaid, schema YAML, campos obrigatórios, links de evidência e ausência de segredos. Ele não substitui a revisão humana do cenário e do risco residual.

20. Quando revisar o modelo

Threat Model é um artefato vivo.

Revise quando houver:

• nova feature;
• novo fluxo de dados;
• novo tenant model;
• nova integração;
• novo provedor;
• migração de banco;
• mudança de autenticação;
• novo agente de IA;
• novo uso de dados;
• incidente;
• vulnerabilidade relevante;
• alteração regulatória;
• mudança arquitetural.

A OWASP recomenda atualizar o modelo após novas features, incidentes e mudanças de arquitetura ou infraestrutura. [9]

20.1 Gatilho de revisão no ciclo de desenvolvimento

Para evitar que o modelo fique separado do código, converta os gatilhos em perguntas de pull request:

• este PR adiciona ou altera um fluxo de dados;
• muda tenant, autenticação, autorização ou identidade de workload;
• adiciona dado sensível, integração ou armazenamento;
• muda retenção, logs, eventos ou acesso administrativo;
• altera componente de IA, ferramenta ou fonte de dados;
• implementa ou encerra uma mitigação do registro.

Se a resposta for sim, o PR deve apontar o modelo revisado ou registrar por que o impacto foi descartado.

21. Erros comuns

21.1 Modelar tudo de uma vez

Um sistema completo pode produzir centenas de ameaças genéricas.

Prefira:

• workload;
• feature;
• fluxo crítico;
• mudança arquitetural;
• integração específica.

21.2 Diagrama profundo demais

Detalhe excessivo impede colaboração.

Comece no nível 0 e aprofunde somente os fluxos críticos.

21.3 Ameaças vagas

Ruim:

Pode haver vazamento de dados.

Melhor:

Um profissional autenticado altera documentId e acessa um documento de outro tenant porque o endpoint não aplica autorização por recurso.

21.4 Mitigação sem owner

“Implementar segurança melhor” não é uma ação.

Toda mitigação precisa de:

• owner;
• prioridade;
• prazo;
• evidência.

21.5 Confundir controle com garantia

“Usamos JWT” não prova autorização correta.

“Usamos criptografia” não prova que:

• chaves estão protegidas;
• o dado não aparece em logs;
• permissões são restritas;
• backups estão seguros.

21.6 Fazer uma vez e esquecer

Arquitetura muda. O modelo também precisa mudar.

22. Definition of Done de segurança

Uma feature crítica só está pronta quando:

• DFD atualizado;
• trust boundaries identificadas;
• dados classificados;
• ameaças registradas;
• riscos priorizados;
• mitigações implementadas;
• testes de segurança criados;
• logs e alertas definidos;
• risco residual documentado;
• owner e data de revisão registrados.

23. Resultado final do estudo de caso

O DFD não entregou apenas um desenho.

Ele gerou:

1. requisitos de autorização por tenant e recurso;
2. política de minimização de eventos;
3. workload identity na mensageria;
4. schema validation;
5. idempotência;
6. DLQ;
7. signed URLs curtas;
8. redaction de logs;
9. auditoria append-only;
10. alertas de acesso anormal;
11. testes negativos;
12. registro de risco residual.

Esse é o valor real do Threat Modeling:

converter uma conversa abstrata sobre segurança em decisões técnicas, testes, owners e evidências.

24. Conclusão

Threat Modeling não precisa ser uma cerimônia pesada nem uma atividade exclusiva do time de segurança.

Ele funciona melhor quando:

• é feito cedo;
• possui escopo claro;
• usa um modelo visual compreensível;
• envolve desenvolvimento, arquitetura, produto e segurança;
• produz ameaças concretas;
• gera ações rastreáveis;
• é revisado ao longo do ciclo de vida.

O Data Flow Diagram é especialmente valioso porque obriga o time a observar o sistema pelo caminho dos dados.

Quando descrevemos:

• quem envia;
• o que é enviado;
• quem recebe;
• onde é armazenado;
• onde a confiança muda;

as ameaças deixam de ser genéricas.

No próximo capítulo da série, usaremos as ameaças de identidade encontradas neste modelo para construir uma estratégia completa de IAM na AWS, separando identidades humanas, workloads, credenciais temporárias, permission sets, roles, boundaries, SCPs, auditoria e resposta a comprometimento.

Checklist rápido

Sistema

• escopo definido;
• atores identificados;
• componentes identificados;
• integrações registradas;
• suposições documentadas.

Dados

• fluxos nomeados;
• data stores identificados;
• dados classificados;
• minimização avaliada;
• retenção registrada;
• política de logging definida.

Segurança

• trust boundaries marcadas;
• STRIDE aplicado;
• attack tree criado para risco crítico;
• impacto e probabilidade avaliados;
• risco residual registrado.

Execução

• mitigação com owner;
• prazo definido;
• evidência definida;
• testes criados;
• data de revisão registrada.

Referências

[1]: OWASP Threat Modeling Project

[2]: AWS Well-Architected Framework — SEC01-BP07: Identificar ameaças e priorizar mitigações usando um modelo de ameaça

[3]: Microsoft Learn — Create a threat model using data-flow diagram elements

[4]: OWASP Threat Model Library

[5]: NIST SP 1800-39 — Data Classification Practices

[6]: OWASP Threat Modeling Cheat Sheet — STRIDE

[7]: OWASP Threat Dragon

[8]: AWS Security Agent — Run and review a threat model

[9]: OWASP Community — Threat Modeling

[10]: NIST SP 800-154 — Guide to Data-Centric System Threat Modeling

[11]: OWASP Authorization Cheat Sheet

[12]: OWASP API1:2023 — Broken Object Level Authorization

[13]: OWASP Logging Cheat Sheet

[14]: NIST Privacy Framework

[15]: CISA Secure by Design

[16]: MITRE ATT&CK

Nota editorial

Este artigo apresenta práticas de engenharia e não substitui análise jurídica, regulatória ou de privacidade. Em sistemas que tratam dados pessoais, dados de saúde, pagamentos ou informações reguladas, envolva as áreas responsáveis por segurança, privacidade, jurídico e compliance.