Modelagem de Ameaças - ifpebj-ti/controle-acesso-veiculos GitHub Wiki

Modelagem de Ameaças

Método: STRIDE aplicado a um diagrama de fluxo de dados

Escopo: produto, frontend, backend, banco, CI/CD, containers e operação

Status: versão 3.7 integrada e sincronizada com os fluxos operacionais, encerramento excepcional auditado, consulta restrita da auditoria, atores humanos e de sistema, credenciais temporárias com troca obrigatória, recuperação administrativa definida, ciclo administrativo de contas, renovação segura de sessão, key ring persistente e protegido, recuperação local com manifesto SHA-256, direção de continuidade e proteção OCI aprovada, observabilidade OTLP, rate limiting, publicação multi-arquitetura no GHCR com proveniência e SBOM verificáveis e baseline DAST passiva com OWASP ZAP

Issues: #26, #30, #90, #100, #102, #104, #106, #190, #191, #218, #220, #227, #258, #260, #261, #268, #271, #308, #311, #312 e #355

Objetivo

Identificar antecipadamente ameaças aos dados, aos registros operacionais, às credenciais, à auditoria e à disponibilidade da portaria. A modelagem não afirma que controles planejados já estão implementados.

A fonte versionada e revisável por Pull Request está em docs/security/threat-model.md no repositório.

Metodologia

STRIDE considera:

  • S — Spoofing: falsificação de identidade;
  • T — Tampering: adulteração de dados ou componentes;
  • R — Repudiation: negação de uma ação sem evidência suficiente;
  • I — Information Disclosure: divulgação indevida;
  • D — Denial of Service: indisponibilidade;
  • E — Elevation of Privilege: obtenção de permissão indevida.

O processo segue quatro etapas: representar o desenho, localizar fronteiras de confiança, enumerar ameaças e acompanhar as mitigações.

Ativos principais

  • dados pessoais e documentos opcionais;
  • placas, vínculos e histórico de acesso;
  • itinerários e quilometragens institucionais;
  • credenciais, sessões, perfis e permissões;
  • auditoria e logs;
  • banco, migrations e backups;
  • código, workflows, imagens e dependências;
  • continuidade operacional da portaria.

Atores

  • porteiro, vigilante e Setor de Transporte;
  • administrador autorizado;
  • equipe de desenvolvimento, infraestrutura e QA;
  • usuário externo ou autenticado mal-intencionado;
  • atacante com acesso à rede, dispositivo ou credencial;
  • serviço, dependência ou imagem comprometida.

Fluxo de dados e fronteiras

flowchart LR
    Usuario[Usuário]
    Browser[Navegador]
    Frontend[React e Nginx]
    Api[ASP.NET Core API]
    Db[(PostgreSQL)]
    Audit[Logs e auditoria]
    Backup[(Backup local verificável)]
    GitHub[GitHub Actions]
    Registry[GitHub Container Registry]
    Oci[OCI futura]

    Usuario --> Browser
    Browser -->|B1| Frontend
    Frontend -->|B2| Api
    Api -->|B3| Db
    Api -->|B4| Audit
    Db -->|B5| Backup
    GitHub -->|B6 build, scan e publicação| Registry
    Registry -->|B7| Oci
Fronteira Estado
B1 — dispositivo/rede para frontend Local implementado; produção pendente
B2 — navegador para API Contratos operacionais, sessão renovável e primeiro acesso obrigatório integrados; access token e credencial temporária somente em memória, refresh token opaco em cookie protegido, CSRF, repetição limitada e coordenação entre abas; dois Administradores funcionais e entrega direta ao titular definidos para recuperação; HTTPS e matriz final pendentes
B3 — API para PostgreSQL Implementado localmente
B4 — aplicação para auditoria Eventos relevantes são gravados transacionalmente; consulta paginada da trilha restrita a Administrador
B5 — banco para backup Dump, manifesto SHA-256 e restauração isolada implementados localmente; Object Storage privado, Vault, instance principal e retenção imutável aprovados no desenho e pendentes na Issue #311
B6 — repositório para CI/registry CI valida Pull Requests e main sem publicação, incluindo build, scan e SBOM por arquitetura; executa smoke test e baseline DAST passiva com OWASP ZAP em stack descartável; uma tag SemVer revisada publica imagens AMD64/ARM64 no GHCR, cria o manifesto final e registra proveniência e os dois SBOMs por digest no GitHub Artifact Attestations com permissões restritas ao job
B7 — registry para OCI Não implementado

Riscos prioritários

ID Categoria Risco Nível Mitigação rastreada
TM-01 Spoofing Credencial compartilhada, roubada ou temporária reutilizada Alto Issues #29, #190, #220, #251 e #258; contas individuais, bloqueio, sessão renovável, versão de credencial, credencial temporária expirável e de uso único, troca obrigatória, revogação transacional, dois Administradores funcionais e entrega direta ao titular; procedimento e prazo ainda devem ser observados na #162
TM-03 Tampering Alteração de IDs, status, horário ou quilometragem Alto Issues #29 e #31
TM-05 Tampering Workflow, dependência, variante de arquitetura ou imagem comprometida Alto Issues #25, #90, #104, #106 e #218; actions fixadas, scan AMD64/ARM64 anterior ao push, rejeição de toda vulnerabilidade crítica e das altas com correção, tags por commit, manifesto com conjunto exato de plataformas, permissão mínima, proveniência SLSA v1 e dois SBOMs SPDX 2.3 verificáveis; política de admissão depende do ambiente de destino
TM-06 Repudiation Operador nega inclusão ou correção Alto Issues #29 e #31
TM-07 Disclosure Erro, log ou telemetria expõe dado, token ou configuração Alto Issues #31, #49 e #102; OTLP limitado a métricas/traces, valores de query redigidos e revisão externa pendente
TM-09 Disclosure Segredo entra no Git, imagem, artefato ou Wiki Alto Issue #25
TM-11 DoS Payload ou volume de requisições esgota API ou banco Médio Payload de 1 MiB, paginação e rate limiting por usuário/IP nas Issues #49, #59, #63 e #69; carga e controle distribuído pendentes
TM-12 DoS Falha de rede, API ou banco interrompe a portaria Alto Issues #25, #30, #92, #100 e #102; inicialização integrada e sinais OTLP configurados, mas collector, alertas, homologação e reconciliação segura permanecem pendentes
TM-13 Elevation Usuário executa operação acima do perfil, corrige registro ou consulta histórico indevido Alto Issues #29, #59, #63 e #65
TM-15 Disclosure Backup desprotegido expõe histórico Alto Diretório fora do Git e manifesto SHA-256 nas Issues #67/#308; Object Storage privado, Vault, instance principal, MFA, separação IAM e retenção imutável aprovados, mas ainda não provisionados na #311
TM-16 Disclosure Retenção mantém dado sem finalidade Alto Cinco anos para registros/papel, 90 dias para logs e 35 dias para backups na Issue #30; revisão arquivística e expurgo seguro pendentes
TM-17 Tampering Migration causa perda ou transformação inválida Alto Testes de migration e restauração local nas Issues #23 e #67; processo de produção na #30
TM-18 Repudiation Operação persiste sem trilha de auditoria Alto Mitigado para autenticação, fluxos geral e institucional e catálogos da frota e de motoristas nas Issues #31, #51, #53, #55, #57, #61 e #71; demais operações pendentes
TM-19 Disclosure Collector falso ou mal configurado recebe telemetria Alto Issue #102; exportação desabilitada por padrão, endpoint sem credenciais e TLS/autenticação da infraestrutura pendentes
TM-22 Tampering / Disclosure Conteúdo não autorizado é carregado ou a aplicação é incorporada por página externa Médio CSP e cabeçalhos defensivos na Issue #196; baseline DAST passiva e não autenticada na Issue #227; HTTPS, HSTS e fluxos autenticados pendentes
TM-25 Tampering / DoS Perda, divergência ou exposição do key ring invalida tokens antifalsificação ou expõe material protegido Médio Issue #355; armazenamento durável compartilhável, nome de aplicação estável, XML protegido por certificado X.509 externo, falha fechada e ensaio de substituição implementados; OCI Vault e armazenamento compartilhado pendentes na #311

A matriz completa contém probabilidade, impacto, controles atuais, riscos residuais e responsáveis na fonte versionada.

Controles existentes

  • separação arquitetural entre camadas;
  • migrations versionadas e revisadas;
  • falha explícita diante de migração semanticamente insegura;
  • autenticação JWT, hash de senha, bloqueio temporário, contas individuais e validação do estado da conta/perfil em cada requisição autenticada;
  • access token curto somente em memória, refresh token opaco em cookie HttpOnly, Secure e SameSite, rotação com detecção de reutilização, revogação e proteção CSRF;
  • key ring do ASP.NET Core Data Protection em armazenamento durável compartilhável, com XML protegido por certificado X.509 externo e configuração obrigatória em produção;
  • restauração e renovação controladas no frontend, com uma repetição máxima por requisição, encerramento local previsível e coordenação entre abas sem compartilhar tokens;
  • ciclo administrativo restrito, auditado e serializado para preservar um Administrador ativo;
  • criação administrativa e bootstrap auditados atomicamente, distinguindo ator autenticado de origem de sistema sem duplicar dados da conta;
  • credencial temporária gerada pelo servidor com 144 bits de aleatoriedade, expiração, uso único, resposta no-store, persistência somente do hash e bloqueio das operações até a troca permanente;
  • redefinição administrativa de outra conta ativa com motivo obrigatório, revogação de sessões, versão de credencial e auditoria transacional sem guardar o segredo;
  • frontend com exibição única da credencial somente em memória, limpeza ao fechar ou perder a sessão e fluxo obrigatório acessível antes das rotas operacionais;
  • autorização deny-by-default e política operacional preliminar;
  • políticas separadas para leitura e gestão da frota institucional;
  • políticas separadas para histórico geral e histórico institucional;
  • política de correção separada, limitada a Vigilante e Administrador;
  • consultas históricas com período máximo de 366 dias, paginação limitada e índices temporais;
  • horários definidos pelo servidor e ator persistido nos fluxos geral e institucional;
  • transações e índices únicos parciais contra registros abertos duplicados;
  • correlation ID, erros seguros, limite global de 1 MiB e logging HTTP mínimo;
  • métricas HTTP/runtime e traces ASP.NET Core exportáveis por OTLP somente quando habilitados, com valores de query redigidos e health checks fora dos traces;
  • rate limiting sem fila, particionado por usuário autenticado ou endereço da conexão, com política específica para login e health checks isentos;
  • auditoria atômica de login bem-sucedido e bloqueio de conta, sem duplicar e-mail, senha ou token;
  • auditoria atômica dos fluxos geral e institucional e cadastro da frota, atribuída ao operador e sem duplicar dados pessoais, placa, identificação patrimonial ou itinerários;
  • placa e identificação institucional normalizadas, com unicidade garantida no PostgreSQL;
  • dados de testes fictícios;
  • .env ignorado e exemplos sem credenciais reais;
  • dump lógico local fora do Git, acompanhado por manifesto SHA-256, restaurado em banco temporário isolado e testado também com adulteração na CI; o checksum não substitui autenticidade, criptografia ou armazenamento protegido;
  • branch protegida, PRs e CI;
  • imagens AMD64 e ARM64 de backend e frontend reconstruídas e analisadas separadamente antes da publicação no GHCR por uma tag de release revisada, com tags imutáveis por commit e arquitetura e credencial efêmera de privilégio mínimo;
  • manifesto final validado para conter exatamente linux/amd64 e linux/arm64, publicado com tag por commit e versão SemVer imutável somente depois da aprovação de todas as variantes;
  • toda vulnerabilidade crítica bloqueia a publicação, mesmo sem correção disponível; vulnerabilidades altas são sempre reportadas e bloqueiam quando existe correção;
  • proveniência SLSA v1 assinada e verificável por nome, digest, repositório, workflow e tag para cada manifesto de release;
  • um SBOM SPDX 2.3 por arquitetura é gerado pelo Trivy, validado e registrado no GitHub Artifact Attestations para o digest do manifesto final, sem cópia OCI no GHCR;
  • stack de PostgreSQL, API e frontend iniciada com credenciais, portas e volume descartáveis na CI, com readiness obrigatório antes da publicação;
  • baseline DAST passiva com OWASP ZAP 2.17.0 fixado por digest, executada somente contra a stack descartável, com política explícita de PASS, WARN e FAIL, relatórios temporários preservados por 14 dias e uma amostra histórica sanitizada versionada;
  • 262 testes de backend e 432 testes de frontend validados na baseline de 30/09/2026, incluindo PostgreSQL real, navegador, teclado, reflow e leitor de tela;
  • auditoria de dependências NuGet nas Issues #23 e #24.

Risco residual

O risco atual continua alto para identidade institucional, autorização definitiva, privacidade e continuidade de produção. O ciclo técnico de credenciais temporárias reduz o risco de senha permanente conhecida pelo Administrador. Dois Administradores funcionais e a entrega direta ao titular foram definidos para o MVP; o procedimento e o prazo ainda devem ser observados na Issue #162. O ensaio local reduz o risco de manter um dump irrecuperável. A Issue #30 e o ADR 0002 definem retenção, papéis, RPO/RTO e proteção na OCI, mas as Issues #311 e #312 ainda precisam provisionar e provar esses controles. A aplicação não deve ser apresentada como pronta para exposição pública ou produção.

Mitigações abertas

Gatilhos de revisão

Revisar quando houver novo endpoint, perfil, dado pessoal, exportação, integração, mudança de autenticação, implantação, backup, incidente ou alteração de fronteira de confiança.

Referências