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,SecureeSameSite, 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;
.envignorado 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/amd64elinux/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,WARNeFAIL, 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
- #25 — CI/CD e containers
- #90 — publicação verificada no GHCR
- #104 — proveniência das imagens no GHCR
- #106 — geração e atestação de SBOM
- #29 — autenticação e autorização
- #30 — retenção, backup e contingência
- #311 — backup protegido na OCI
- #312 — recuperação pontual e RPO de uma hora
- #100 — reconciliação segura após contingência
- #31 — segurança transversal e auditoria
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.