Aegirex | Threat model public

Méthodologie : STRIDE (Spoofing / Tampering / Repudiation / Information disclosure / Denial of service / Elevation of privilege) appliquée à cinq surfaces du produit. Chaque ligne : menace → mitigation Aegirex → trade-off assumé.

Document destiné aux RSSI, auditeurs et chercheurs en sécurité. Le code source AGPL est public sur github.com/aegirex/server. Les runbooks opérationnels détaillés restent réservés aux design partners sous NDA.

1. Acteurs modélisés

Les neuf profils d'attaquant pris en compte dans le modèle.

Acteur	Description	Capacités
Attaquant externe	Internet, aucun accès initial	Force brute, phishing, exploits web, MITM réseau
Utilisateur phishé	Utilisateur cible d'un site clone	Soumet ses credentials à un domaine attaquant
Co-locataire malveillant	Utilisateur d'une autre organisation Aegirex	Tente de lire les secrets d'organisations voisines
Navigateur compromis	Navigateur infecté par malware ou extension malveillante	Accès au DOM, peut lire les champs de saisie
Administrateur serveur	Opérateur d'infrastructure avec accès SSH au serveur	Lit la base de données, lit la mémoire, modifie le code
Exfiltration de base de données	Backup volé, dump SQL fuité	Snapshot complet de la base de données
Autorité judiciaire	Réquisition légale, mandat administratif	Force l'hébergeur à fournir les données stockées
Insider Aegirex	Salarié ou prestataire futur de la EI	Revue de code, accès déploiement, lecture des logs
Adversaire quantique	Ordinateur quantique opérationnel (horizon > 2030)	Casse RSA / ECC en temps polynomial (Shor)

2. Données protégées

Classification des données et niveau de protection au repos.

Donnée	Sensibilité	Stockage
Mot de passe maître utilisateur	Critique	Hash Argon2id uniquement (RFC 9106)
Contenu des secrets (payload)	Critique	Chiffré de bout en bout (OpenPGP), serveur stocke un blob opaque
Clé privée OpenPGP utilisateur	Critique	Jamais sur le serveur. Stockée localement, protégée par passphrase utilisateur
Secrets TOTP au repos	Critique	Chiffrés XChaCha20-Poly1305 (clé hors base de données)
Secrets webhook au repos	Critique	Chiffrés XChaCha20-Poly1305 (clé hors base de données)
Noms de secrets et de dossiers	Modérée	En clair côté serveur. Trade-off documenté §5.1
Journal d'audit	Élevée	Chaîne HMAC-SHA-256, tamper-evidence en O(1)

3. Menaces et mitigations par surface

3.1 Application web SaaS

Menace	Mitigation	Statut
Force brute sur le mot de passe	Rate limiter 5 tentatives / 15 min par IP + Argon2id (256 MiB, 5 passes) ≈ 1 s par tentative locale	Livré
Credential stuffing	Même rate limiter + scan HIBP opt-in après login (consentement RGPD explicite)	Livré
Bypass 2FA	TOTP RFC 6238 avec issuer pinning + codes de récupération à usage unique + WebAuthn PRF	Livré
XSS stocké ou réfléchi	CSP stricte (script-src 'self' 'wasm-unsafe-eval'), Trusted Types activés, échappement automatique Twig	Livré
Compromission de la dépendance OpenPGP.js	Bibliothèque vendorée avec empreinte SHA-256 vérifiée au build (manifeste d'intégrité SRI)	Livré
Phishing du mot de passe maître	Mitigation forte à venir : passkeys WebAuthn PRF, qui suppriment la transmission du mot de passe et sont liées au domaine d'origine par le navigateur. En attendant : formation utilisateur + indicateurs UI.	À venir

3.2 Stockage chiffré

Menace	Mitigation	Statut
Dump de la base de données volé	Payload chiffré OpenPGP E2E illisible sans la clé privée utilisateur. Mots de passe en hash Argon2id non récupérables	Livré
Backup volé	Backups chiffrés (Argon2id + ChaCha20-Poly1305), multi-destinataires. Test de restauration automatisé en CI	Livré
Administrateur serveur lit le contenu d'un secret	Impossible sans la clé privée utilisateur. Le serveur ne stocke que des blobs opaques	Livré
Altération du journal d'audit (tampering)	Chaîne HMAC-SHA-256, détection en O(1) à la vérification. Détail de la chaîne	Livré

3.3 API REST

Menace	Mitigation	Statut
Fuite de données cross-organisation	Chaque jeton API lié à une organisation unique. Filtrage systématique à chaque endpoint. Tests d'isolation explicites en CI à chaque commit	Livré
Vol de jeton API	Jeton hashé Argon2id en base. Rotation libre par l'utilisateur. Scope minimal (lecture / écriture) configurable	Livré
Déni de service applicatif	Rate limiter par jeton et par IP (cadre Symfony)	Livré

3.4 Extensions navigateur

Menace	Mitigation	Statut
Compromission du pipeline de build	Vérification d'empreinte SHA-256 des dépendances chaînée au build. SBOM signé planifié	Livré
Fermeture du popup = perte temporaire d'accès	Trade-off de la première version : la clé privée n'est pas persistée pour limiter la surface d'attaque. À venir : auto-lock paramétrable + persistance via service worker contrôlé.	À venir
Capture de credentials sur un site phishant	L'utilisateur voit le nom de domaine réel dans la pop-up de l'extension avant de cliquer sur « Enregistrer »	Livré

3.5 Infrastructure auto-hébergée

Menace	Mitigation	Statut
Image Docker compromise	Scan de vulnérabilités automatisé en CI. Signature Sigstore planifiée pour vérification utilisateur côté déploiement	En cours
Backup non testé	Test de restauration automatisé en CI sur chaque release. Pas de backup non vérifié en production	Livré
mTLS en production	Activable par configuration. Modes audit (logs seuls) puis enforcement disponibles	Livré

4. Périmètre de protection - limites assumées

Honnêteté éditoriale : voici les surfaces que Aegirex ne couvre pas seul, et la mitigation recommandée.

Limite	Pourquoi	Mitigation recommandée
Compromission complète du poste de l'utilisateur	Un malware ayant accès à la RAM du navigateur peut lire la clé privée déchiffrée	Passkey hardware (YubiKey, TPM) qui confine la clé dans un élément sécurisé
Compromission du serveur Aegirex (root)	Un attaquant root peut lire les sessions HTTP actives	Les secrets stockés restent illisibles (zero-knowledge). Seules les sessions ouvertes au moment de la compromission sont à risque. Auto-lock court recommandé
Perte du mot de passe maître	Conséquence directe du zero-knowledge strict : aucun moyen côté serveur de récupérer la clé	Codes de récupération imprimés à la création. À venir : partage Shamir M-sur-N pour les plans Enterprise
Adversaire quantique (horizon > 2030)	OpenPGP v6 + AES-256 sont estimés sûrs 5 à 10 ans selon le RGS ANSSI 2024	Migration post-quantique (ML-KEM, ML-DSA) en évaluation à long terme
Attaque physique sur le poste utilisateur	Aegirex est un coffre-fort logique, pas un coffre physique	Auto-lock court du coffre + passkey WebAuthn matérielle
Insider Aegirex (salarié futur)	Limite assumée du modèle de confiance d'éditeur SaaS	NDA, séparation des responsabilités, revue de code obligatoire, chaîne d'audit tamper-evidente, principe du moindre privilège

5. Trade-offs assumés

5.1 Noms de secrets et de dossiers en clair côté serveur

Choix : noms stockés en clair côté serveur.

Pourquoi : recherche côté serveur instantanée, affichage de l'arborescence sans déchiffrement à chaque navigation, partage hiérarchique de dossiers possible.

Impact : un attaquant qui exfiltre la base de données voit qu'un secret nommé « AWS Prod » existe dans le dossier « DevOps / Cloud ». Il NE voit PAS le contenu (payload chiffré E2E).

Alternative envisagée : option « anonymise me » qui chiffre aussi les noms. Coût UX significatif : pas de recherche côté serveur, scan client complet à chaque requête.

5.2 Mot de passe en clair dans le DOM lors de la saisie

Choix : OpenPGP chiffre le payload après que l'utilisateur ait tapé son mot de passe.

Pourquoi : pas d'alternative - le navigateur doit voir le clair pour permettre à l'utilisateur de le saisir.

Mitigations : Trusted Types CSP empêche le DOM XSS d'injecter du JavaScript exfiltrant. À venir : passkeys WebAuthn qui suppriment totalement la transmission de mots de passe.

5.3 Mot de passe maître = unique clé du coffre

Choix : pas de récupération si l'utilisateur perd à la fois son mot de passe maître ET ses codes de récupération.

Pourquoi : zero-knowledge strict. Si nous pouvions récupérer, il y aurait un chemin de déchiffrement côté serveur.

Mitigation à venir : partage Shamir de la clé privée (M-sur-N parts), une part chez Aegirex avec garde-fous procéduraux (déblocage uniquement avec présence de N-1 autres parts validée par l'utilisateur). Réservé aux plans Enterprise.

6. Plan de réponse incident

Niveau	Déclencheur	Action
L1 Suspicion	Anomalie dans le journal d'audit, signalement utilisateur	Investigation interne sous 24 h, vérification chaîne d'audit
L2 Compromission confirmée	Compromission technique confirmée par l'investigation	Notification utilisateurs sous 72 h (RGPD Art. 33), rotation des clés impactées, mise en place de mitigations
L3 Compromission majeure	Base de données ou code source compromis	Notification CNIL et ANSSI, transparency report public, audit forensique externe

Divulgation responsable : conformément à la RFC 9116, un fichier /.well-known/security.txt à la racine du site indique notre adresse de contact security@aegirex.eu. Délai d'accusé de réception : 72 h.

Préciser le document ?

Ce threat model est un document vivant. Si vous êtes RSSI, auditeur ou chercheur en sécurité et qu'une menace est mal modélisée, contactez-nous directement.

Matrice claims/preuves security@aegirex.eu

Threat model public.