ARDNTECH | Threat model public

Metodologie: STRIDE (Spoofing / Tampering / Repudiation / Information disclosure / Denial of service / Elevation of privilege) aplicată la cinci suprafețe ale produsului. Fiecare linie : amenințare - mitigare ARDNTECH - trade-off asumat.

Document destinat CISO-urilor, auditorilor și cercetătorilor în securitate. Codul sursă AGPL este public pe github.com/aegirex/server. Runbook-urile operaționale detaliate rămân rezervate design partners-ilor sub NDA.

1. Actori modelați

Cele nouă profiluri de atacator luate în considerare în model.

Actor	Descriere	Capacități
Atacator extern	Internet, niciun acces inițial	Forță brută, phishing, exploit-uri web, MITM de rețea
Utilizator phish-uit	Utilizator țintă a unui site clonat	Își trimite credențialele către un domeniu atacator
Co-locatar malițios	Utilizator al unei alte organizații ARDNTECH	Încearcă să citească secretele organizațiilor vecine
Browser compromis	Browser infectat de malware sau extensie malițioasă	Acces la DOM, poate citi câmpurile de introducere
Administrator server	Operator de infrastructură cu acces SSH la server	Citește baza de date, citește memoria, modifică codul
Exfiltrare a bazei de date	Backup furat, dump SQL scurs	Snapshot complet al bazei de date
Autoritate judiciară	Rechiziție legală, mandat administrativ	Forțează gazda să furnizeze datele stocate
Insider ARDNTECH	Angajat sau prestator viitor al ARDNTECH	Revizuire de cod, acces la desfășurare, citirea logurilor
Adversar cuantic	Calculator cuantic operațional (orizont > 2030)	Sparge RSA / ECC în timp polinomial (Shor)

2. Date protejate

Clasificarea datelor și nivelul de protecție în repaus.

Dată	Sensibilitate	Stocare
Parola master a utilizatorului	Critică	Doar hash Argon2id (RFC 9106)
Conținutul secretelor (payload)	Critică	Criptat end-to-end (OpenPGP), serverul stochează un blob opac
Cheia privată OpenPGP a utilizatorului	Critică	Niciodată pe server. Stocată local, protejată prin passphrase a utilizatorului
Secrete TOTP în repaus	Critică	Criptate XChaCha20-Poly1305 (cheie în afara bazei de date)
Secrete webhook în repaus	Critică	Criptate XChaCha20-Poly1305 (cheie în afara bazei de date)
Numele secretelor și ale folderelor	Moderată	În clar pe partea de server. Trade-off documentat 5.1
Jurnal de audit	Ridicată	Lanț HMAC-SHA-256, tamper-evidence în O(1)

3. Amenințări și mitigări per suprafață

3.1 Aplicație web SaaS

Amenințare	Mitigare	Status
Forță brută pe parolă	Rate limiter 5 încercări / 15 min per IP + Argon2id (256 MiB, 5 pase) - 1 s per încercare locală	Livrat
Credential stuffing	Același rate limiter + scan HIBP opt-in după login (consimțământ GDPR explicit)	Livrat
Bypass 2FA	TOTP RFC 6238 cu issuer pinning + coduri de recuperare cu utilizare unică + WebAuthn PRF	Livrat
XSS stocat sau reflectat	CSP strictă (script-src 'self' 'wasm-unsafe-eval'), Trusted Types activate, escape automat Twig	Livrat
Compromiterea dependenței OpenPGP.js	Bibliotecă vendor-uită cu amprentă SHA-256 verificată la build (manifest de integritate SRI)	Livrat
Phishing al parolei master	Mitigare puternică în viitor : passkeys WebAuthn PRF, care elimină transmiterea parolei și sunt legate de domeniul de origine de către browser. Între timp : formarea utilizatorilor + indicatori UI.	În viitor

3.2 Stocare criptată

Amenințare	Mitigare	Status
Dump al bazei de date furat	Payload criptat OpenPGP E2E ilizibil fără cheia privată a utilizatorului. Parole în hash Argon2id nerecuperabile	Livrat
Backup furat	Backup-uri criptate (Argon2id + ChaCha20-Poly1305), multi-destinatari. Test de restaurare automatizat în CI	Livrat
Administratorul serverului citește conținutul unui secret	Imposibil fără cheia privată a utilizatorului. Serverul stochează doar blob-uri opace	Livrat
Alterarea jurnalului de audit (tampering)	Lanț HMAC-SHA-256, detectare în O(1) la verificare. Detaliul lanțului	Livrat

3.3 API REST

Amenințare	Mitigare	Status
Scurgere de date cross-organizație	Fiecare token API legat de o organizație unică. Filtrare sistematică la fiecare endpoint. Teste de izolare explicite în CI la fiecare commit	Livrat
Furt de token API	Token hash-uit Argon2id în baza de date. Rotație liberă de către utilizator. Scope minimal (citire / scriere) configurabil	Livrat
Denial of service aplicativ	Rate limiter per token și per IP (cadru Symfony)	Livrat

3.4 Extensii de browser

Amenințare	Mitigare	Status
Compromiterea pipeline-ului de build	Verificare a amprentei SHA-256 a dependențelor înlănțuită la build. SBOM semnat planificat	Livrat
Închiderea popup-ului = pierdere temporară a accesului	Trade-off al primei versiuni : cheia privată nu este persistată pentru a limita suprafața de atac. În viitor : auto-lock parametrabil + persistență via service worker controlat.	În viitor
Captură de credențiale pe un site phishing	Utilizatorul vede numele de domeniu real în pop-up-ul extensiei înainte de a face clic pe « Salvează »	Livrat

3.5 Infrastructură auto-găzduită

Amenințare	Mitigare	Status
Imagine Docker compromisă	Scan de vulnerabilități automatizat în CI. Semnătură Sigstore planificată pentru verificarea utilizatorului pe partea de desfășurare	În curs
Backup netestat	Test de restaurare automatizat în CI la fiecare release. Niciun backup neverificat în producție	Livrat
mTLS în producție	Activabil prin configurație. Moduri audit (doar loguri) apoi enforcement disponibile	Livrat

4. Perimetru de protecție - limite asumate

Onestitate editorială : iată suprafețele pe care ARDNTECH nu le acoperă singur, și mitigarea recomandată.

Limită	De ce	Mitigare recomandată
Compromiterea completă a postului utilizatorului	Un malware care are acces la RAM-ul browserului poate citi cheia privată decriptată	Passkey hardware (YubiKey, TPM) care confină cheia într-un element securizat
Compromiterea serverului ARDNTECH (root)	Un atacator root poate citi sesiunile HTTP active	Secretele stocate rămân ilizibile (zero-knowledge). Doar sesiunile deschise în momentul compromiterii sunt la risc. Auto-lock scurt recomandat
Pierderea parolei master	Consecință directă a zero-knowledge strict : niciun mijloc pe partea de server de a recupera cheia	Coduri de recuperare imprimate la creare. În viitor : partajare Shamir M-din-N pentru planurile Enterprise
Adversar cuantic (orizont > 2030)	OpenPGP v6 + AES-256 sunt estimate ca sigure 5 până la 10 ani conform RGS ANSSI 2024	Migrare post-cuantică (ML-KEM, ML-DSA) în evaluare pe termen lung
Atac fizic asupra postului utilizatorului	ARDNTECH este un seif logic, nu un seif fizic	Auto-lock scurt al seifului + passkey WebAuthn hardware
Insider ARDNTECH (angajat viitor)	Limită asumată a modelului de încredere al unui editor SaaS	NDA, separarea responsabilităților, revizuire de cod obligatorie, lanț de audit tamper-evident, principiul celui mai mic privilegiu

5. Trade-off-uri asumate

5.1 Numele secretelor și ale folderelor în clar pe partea de server

Alegere : nume stocate în clar pe partea de server.

De ce : căutare pe partea de server instantanee, afișarea arborescenței fără decriptare la fiecare navigare, partajare ierarhică de foldere posibilă.

Impact : un atacator care exfiltrează baza de date vede că un secret numit « AWS Prod » există în folderul « DevOps / Cloud ». El NU vede conținutul (payload criptat E2E).

Alternativă avută în vedere : opțiune « anonymise me » care criptează și numele. Cost UX semnificativ : fără căutare pe partea de server, scan client complet la fiecare cerere.

5.2 Parolă în clar în DOM la momentul introducerii

Alegere : OpenPGP criptează payload-ul după ce utilizatorul și-a tastat parola.

De ce : nicio alternativă - browserul trebuie să vadă clarul pentru a permite utilizatorului să îl introducă.

Mitigări : Trusted Types CSP împiedică DOM XSS să injecteze JavaScript care exfiltrează. În viitor : passkeys WebAuthn care elimină total transmiterea parolelor.

5.3 Parola master = cheia unică a seifului

Alegere : fără recuperare dacă utilizatorul își pierde atât parola master CÂT ȘI codurile sale de recuperare.

De ce : zero-knowledge strict. Dacă am putea recupera, ar exista o cale de decriptare pe partea de server.

Mitigare în viitor : partajare Shamir a cheii private (M-din-N părți), o parte la ARDNTECH cu garanții procedurale (deblocare doar cu prezența a N-1 alte părți validată de utilizator). Rezervată planurilor Enterprise.

6. Plan de răspuns la incident

Nivel	Declanșator	Acțiune
L1 Suspiciune	Anomalie în jurnalul de audit, semnalare a utilizatorului	Investigație internă în mai puțin de 24 h, verificarea lanțului de audit
L2 Compromitere confirmată	Compromitere tehnică confirmată prin investigație	Notificarea utilizatorilor în mai puțin de 72 h (GDPR Art. 33), rotația cheilor impactate, instalarea de mitigări
L3 Compromitere majoră	Bază de date sau cod sursă compromis	Notificare CNIL și ANSSI, transparency report public, audit forensic extern

Divulgare responsabilă: În conformitate cu RFC 9116, un fișier /.well-known/security.txt la rădăcina site-ului indică adresa noastră de contact security@aegirex.eu. Termen de confirmare a primirii : 72 h.

Precizați documentul ?

Acest threat model este un document viu. Dacă sunteți CISO, auditor sau cercetător în securitate și o amenințare este prost modelată, contactați-ne direct.

Matrice claims/dovezi security@aegirex.eu

Threat model <em>public.</em>