ARDNTECH | Threat model público

Metodologia: STRIDE (Spoofing / Tampering / Repudiation / Information disclosure / Denial of service / Elevation of privilege) aplicada a cinco superfícies do produto. Cada linha: ameaça - mitigação ARDNTECH - trade-off assumido.

Documento destinado aos RSSI, auditores e investigadores de segurança. O código-fonte AGPL é público em github.com/aegirex/server. Os runbooks operacionais detalhados permanecem reservados aos design partners sob NDA.

1. Intervenientes modelizados

Os nove perfis de atacante tidos em conta no modelo.

Interveniente	Descrição	Capacidades
Atacante externo	Internet, nenhum acesso inicial	Força bruta, phishing, exploits web, MITM de rede
Utilizador vítima de phishing	Utilizador alvo de um site clone	Submete as suas credenciais a um domínio atacante
Coinquilino malicioso	Utilizador de outra organização ARDNTECH	Tenta ler os segredos de organizações vizinhas
Navegador comprometido	Navegador infetado por malware ou extensão maliciosa	Acesso ao DOM, pode ler os campos de introdução
Administrador de servidor	Operador de infraestrutura com acesso SSH ao servidor	Lê a base de dados, lê a memória, modifica o código
Exfiltração de base de dados	Backup roubado, dump SQL com fuga	Snapshot completo da base de dados
Autoridade judicial	Requisição legal, mandato administrativo	Força o alojador a fornecer os dados armazenados
Insider ARDNTECH	Colaborador ou prestador futuro da ARDNTECH	Revisão de código, acesso ao deployment, leitura dos logs
Adversário quântico	Computador quântico operacional (horizonte > 2030)	Quebra RSA / ECC em tempo polinomial (Shor)

2. Dados protegidos

Classificação dos dados e nível de proteção em repouso.

Dado	Sensibilidade	Armazenamento
Palavra-passe mestra do utilizador	Crítica	Hash Argon2id apenas (RFC 9106)
Conteúdo dos segredos (payload)	Crítica	Cifrado de ponta a ponta (OpenPGP), o servidor armazena um blob opaco
Chave privada OpenPGP do utilizador	Crítica	Nunca no servidor. Armazenada localmente, protegida por passphrase do utilizador
Segredos TOTP em repouso	Crítica	Cifrados XChaCha20-Poly1305 (chave fora da base de dados)
Segredos de webhook em repouso	Crítica	Cifrados XChaCha20-Poly1305 (chave fora da base de dados)
Nomes de segredos e de pastas	Moderada	Em claro no servidor. Trade-off documentado 5.1
Registo de auditoria	Elevada	Cadeia HMAC-SHA-256, tamper-evidence em O(1)

3. Ameaças e mitigações por superfície

3.1 Aplicação web SaaS

Ameaça	Mitigação	Estado
Força bruta sobre a palavra-passe	Rate limiter 5 tentativas / 15 min por IP + Argon2id (256 MiB, 5 passes) - 1 s por tentativa local	Entregue
Credential stuffing	Mesmo rate limiter + scan HIBP opt-in após login (consentimento RGPD explícito)	Entregue
Bypass 2FA	TOTP RFC 6238 com issuer pinning + códigos de recuperação de uso único + WebAuthn PRF	Entregue
XSS armazenado ou refletido	CSP estrita (script-src 'self' 'wasm-unsafe-eval'), Trusted Types ativados, escape automático Twig	Entregue
Comprometimento da dependência OpenPGP.js	Biblioteca vendored com impressão digital SHA-256 verificada no build (manifesto de integridade SRI)	Entregue
Phishing da palavra-passe mestra	Mitigação forte a chegar: passkeys WebAuthn PRF, que suprimem a transmissão da palavra-passe e estão ligadas ao domínio de origem pelo navegador. Entretanto: formação de utilizadores + indicadores UI.	A chegar

3.2 Armazenamento cifrado

Ameaça	Mitigação	Estado
Dump da base de dados roubado	Payload cifrado OpenPGP E2E ilegível sem a chave privada do utilizador. Palavras-passe em hash Argon2id não recuperáveis	Entregue
Backup roubado	Backups cifrados (Argon2id + ChaCha20-Poly1305), multidestinatários. Teste de restauração automatizado em CI	Entregue
Administrador de servidor lê o conteúdo de um segredo	Impossível sem a chave privada do utilizador. O servidor armazena apenas blobs opacos	Entregue
Alteração do registo de auditoria (tampering)	Cadeia HMAC-SHA-256, deteção em O(1) na verificação. Detalhe da cadeia	Entregue

3.3 API REST

Ameaça	Mitigação	Estado
Fuga de dados cross-organização	Cada token API ligado a uma organização única. Filtragem sistemática em cada endpoint. Testes de isolamento explícitos em CI a cada commit	Entregue
Roubo de token API	Token com hash Argon2id em base de dados. Rotação livre pelo utilizador. Scope mínimo (leitura / escrita) configurável	Entregue
Negação de serviço aplicacional	Rate limiter por token e por IP (quadro Symfony)	Entregue

3.4 Extensões de navegador

Ameaça	Mitigação	Estado
Comprometimento do pipeline de build	Verificação de impressão digital SHA-256 das dependências encadeada ao build. SBOM assinado planeado	Entregue
Fecho do popup = perda temporária de acesso	Trade-off da primeira versão: a chave privada não é persistida para limitar a superfície de ataque. A chegar: auto-lock parametrizável + persistência via service worker controlado.	A chegar
Captura de credenciais num site de phishing	O utilizador vê o nome de domínio real no pop-up da extensão antes de clicar em « Guardar »	Entregue

3.5 Infraestrutura auto-alojada

Ameaça	Mitigação	Estado
Imagem Docker comprometida	Scan de vulnerabilidades automatizado em CI. Assinatura Sigstore planeada para verificação do utilizador no deployment	Em curso
Backup não testado	Teste de restauração automatizado em CI a cada release. Sem backup não verificado em produção	Entregue
mTLS em produção	Ativável por configuração. Modos auditoria (apenas logs) e depois enforcement disponíveis	Entregue

4. Perímetro de proteção - limites assumidos

Honestidade editorial: eis as superfícies que a ARDNTECH não cobre sozinha, e a mitigação recomendada.

Limite	Porquê	Mitigação recomendada
Comprometimento completo do posto do utilizador	Um malware com acesso à RAM do navegador pode ler a chave privada decifrada	Passkey de hardware (YubiKey, TPM) que confina a chave num elemento seguro
Comprometimento do servidor ARDNTECH (root)	Um atacante root pode ler as sessões HTTP ativas	Os segredos armazenados permanecem ilegíveis (zero-knowledge). Apenas as sessões abertas no momento do comprometimento estão em risco. Auto-lock curto recomendado
Perda da palavra-passe mestra	Consequência direta do zero-knowledge estrito: nenhum meio no servidor de recuperar a chave	Códigos de recuperação impressos na criação. A chegar: partilha Shamir M-de-N para os planos Enterprise
Adversário quântico (horizonte > 2030)	OpenPGP v6 + AES-256 são estimados seguros 5 a 10 anos segundo o RGS ANSSI 2024	Migração pós-quântica (ML-KEM, ML-DSA) em avaliação a longo prazo
Ataque físico ao posto do utilizador	A ARDNTECH é um cofre lógico, não um cofre físico	Auto-lock curto do cofre + passkey WebAuthn de hardware
Insider ARDNTECH (colaborador futuro)	Limite assumido do modelo de confiança de editor SaaS	NDA, separação de responsabilidades, revisão de código obrigatória, cadeia de auditoria tamper-evidente, princípio do menor privilégio

5. Trade-offs assumidos

5.1 Nomes de segredos e de pastas em claro no servidor

Escolha: nomes armazenados em claro no servidor.

Porquê: pesquisa no servidor instantânea, apresentação da árvore sem decifragem a cada navegação, partilha hierárquica de pastas possível.

Impacto: um atacante que exfiltre a base de dados vê que um segredo chamado « AWS Prod » existe na pasta « DevOps / Cloud ». NÃO vê o conteúdo (payload cifrado E2E).

Alternativa considerada: opção « anonymise me » que cifra também os nomes. Custo UX significativo: sem pesquisa no servidor, scan completo do cliente a cada pedido.

5.2 Palavra-passe em claro no DOM durante a introdução

Escolha: o OpenPGP cifra o payload depois de o utilizador ter escrito a sua palavra-passe.

Porquê: sem alternativa - o navegador tem de ver o claro para permitir ao utilizador introduzi-la.

Mitigações: Trusted Types CSP impede que o DOM XSS injete JavaScript que exfiltre. A chegar: passkeys WebAuthn que suprimem totalmente a transmissão de palavras-passe.

5.3 Palavra-passe mestra = única chave do cofre

Escolha: sem recuperação se o utilizador perder simultaneamente a sua palavra-passe mestra E os seus códigos de recuperação.

Porquê: zero-knowledge estrito. Se pudéssemos recuperar, haveria um caminho de decifragem no servidor.

Mitigação a chegar: partilha Shamir da chave privada (M-de-N partes), uma parte na ARDNTECH com limites de segurança procedimentais (desbloqueio apenas com presença de N-1 outras partes validada pelo utilizador). Reservado aos planos Enterprise.

6. Plano de resposta a incidentes

Nível	Acionador	Ação
L1 Suspeita	Anomalia no registo de auditoria, sinalização de utilizador	Investigação interna em 24 h, verificação da cadeia de auditoria
L2 Comprometimento confirmado	Comprometimento técnico confirmado pela investigação	Notificação de utilizadores em 72 h (RGPD Art. 33), rotação das chaves impactadas, implementação de mitigações
L3 Comprometimento maior	Base de dados ou código-fonte comprometido	Notificação CNIL e ANSSI, transparency report público, auditoria forense externa

Divulgação responsável: Em conformidade com a RFC 9116, um ficheiro /.well-known/security.txt na raiz do site indica o nosso endereço de contacto security@aegirex.eu. Prazo de aviso de receção: 72 h.

Precisar o documento?

Este threat model é um documento vivo. Se for RSSI, auditor ou investigador de segurança e uma ameaça estiver mal modelizada, contacte-nos diretamente.

Matriz claims/provas security@aegirex.eu

Threat model <em>público.</em>