ARDNTECH | Öffentliches Threat-Model

Methodik: STRIDE (Spoofing / Tampering / Repudiation / Information disclosure / Denial of service / Elevation of privilege) angewendet auf fünf Angriffsflächen des Produkts. Jede Zeile: Bedrohung - Mitigation durch ARDNTECH - bewusst eingegangener Trade-off.

Dieses Dokument richtet sich an CISOs, Auditoren und Sicherheitsforscher. Der AGPL-Quellcode ist öffentlich verfügbar unter github.com/aegirex/server. Die detaillierten operativen Runbooks bleiben den Design Partnern unter NDA vorbehalten.

1. Modellierte Akteure

Die neun Angreiferprofile, die im Modell berücksichtigt werden.

Akteur	Beschreibung	Fähigkeiten
Externer Angreifer	Internet, kein initialer Zugriff	Brute Force, Phishing, Web-Exploits, Netzwerk-MITM
Gephishter Benutzer	Benutzer als Ziel einer Klon-Website	Übermittelt seine Anmeldedaten an eine Angreiferdomain
Böswilliger Mitnutzer	Benutzer einer anderen ARDNTECH-Organisation	Versucht, die Secrets benachbarter Organisationen zu lesen
Kompromittierter Browser	Durch Malware oder bösartige Erweiterung infizierter Browser	Zugriff auf das DOM, kann Eingabefelder lesen
Serveradministrator	Infrastrukturbetreiber mit SSH-Zugriff auf den Server	Liest die Datenbank, liest den Speicher, ändert den Code
Exfiltration der Datenbank	Gestohlenes Backup, geleakter SQL-Dump	Vollständiger Snapshot der Datenbank
Justizbehörde	Gerichtliche Anordnung, behördlicher Beschluss	Zwingt den Hoster zur Herausgabe der gespeicherten Daten
ARDNTECH-Insider	Künftiger Mitarbeiter oder Dienstleister der ARDNTECH	Code-Review, Deployment-Zugriff, Lesen der Logs
Quantenangreifer	Einsatzbereiter Quantencomputer (Horizont > 2030)	Bricht RSA / ECC in polynomieller Zeit (Shor)

2. Geschützte Daten

Klassifizierung der Daten und Schutzniveau im Ruhezustand.

Daten	Sensibilität	Speicherung
Master-Passwort des Benutzers	Kritisch	Ausschließlich Argon2id-Hash (RFC 9106)
Inhalt der Secrets (Payload)	Kritisch	Ende-zu-Ende-verschlüsselt (OpenPGP), der Server speichert einen opaken Blob
Privater OpenPGP-Schlüssel des Benutzers	Kritisch	Niemals auf dem Server. Lokal gespeichert, durch eine Passphrase des Benutzers geschützt
TOTP-Secrets im Ruhezustand	Kritisch	Verschlüsselt mit XChaCha20-Poly1305 (Schlüssel außerhalb der Datenbank)
Webhook-Secrets im Ruhezustand	Kritisch	Verschlüsselt mit XChaCha20-Poly1305 (Schlüssel außerhalb der Datenbank)
Namen von Secrets und Ordnern	Moderat	Im Klartext auf Serverseite. Trade-off dokumentiert in 5.1
Audit-Protokoll	Hoch	HMAC-SHA-256-Kette, Tamper-Evidence in O(1)

3. Bedrohungen und Mitigationen je Angriffsfläche

3.1 Web-SaaS-Anwendung

Bedrohung	Mitigation	Status
Brute Force auf das Passwort	Rate-Limiter 5 Versuche / 15 Min. pro IP + Argon2id (256 MiB, 5 Durchläufe) - 1 s pro lokalem Versuch	Geliefert
Credential Stuffing	Derselbe Rate-Limiter + HIBP-Scan opt-in nach dem Login (ausdrückliche DSGVO-Einwilligung)	Geliefert
Umgehung der 2FA	TOTP RFC 6238 mit Issuer-Pinning + Wiederherstellungscodes zur einmaligen Verwendung + WebAuthn PRF	Geliefert
Gespeichertes oder reflektiertes XSS	Strikte CSP (script-src 'self' 'wasm-unsafe-eval'), Trusted Types aktiviert, automatisches Escaping durch Twig	Geliefert
Kompromittierung der Abhängigkeit OpenPGP.js	Vendored Bibliothek mit beim Build überprüftem SHA-256-Fingerabdruck (SRI-Integritätsmanifest)	Geliefert
Phishing des Master-Passworts	Starke Mitigation demnächst: WebAuthn-PRF-Passkeys, die die Übertragung des Passworts überflüssig machen und vom Browser an die Ursprungsdomain gebunden werden. In der Zwischenzeit: Benutzerschulung + UI-Indikatoren.	Demnächst

3.2 Verschlüsselte Speicherung

Bedrohung	Mitigation	Status
Gestohlener Dump der Datenbank	OpenPGP-E2E-verschlüsselte Payload ohne den privaten Schlüssel des Benutzers unlesbar. Passwörter als Argon2id-Hash nicht wiederherstellbar	Geliefert
Gestohlenes Backup	Verschlüsselte Backups (Argon2id + ChaCha20-Poly1305), mehrere Empfänger. Automatisierter Wiederherstellungstest in der CI	Geliefert
Serveradministrator liest den Inhalt eines Secrets	Ohne den privaten Schlüssel des Benutzers unmöglich. Der Server speichert nur opake Blobs	Geliefert
Manipulation des Audit-Protokolls (Tampering)	HMAC-SHA-256-Kette, Erkennung in O(1) bei der Überprüfung. Details zur Kette	Geliefert

3.3 REST-API

Bedrohung	Mitigation	Status
Organisationsübergreifendes Datenleck	Jedes API-Token ist an eine eindeutige Organisation gebunden. Systematische Filterung an jedem Endpoint. Explizite Isolationstests in der CI bei jedem Commit	Geliefert
Diebstahl eines API-Tokens	Token als Argon2id-Hash in der Datenbank. Freie Rotation durch den Benutzer. Minimaler Scope (Lesen / Schreiben) konfigurierbar	Geliefert
Denial-of-Service auf Anwendungsebene	Rate-Limiter pro Token und pro IP (Symfony-Framework)	Geliefert

3.4 Browser-Erweiterungen

Bedrohung	Gegenmaßnahme	Status
Kompromittierung der Build-Pipeline	SHA-256-Prüfsummenverifizierung der Abhängigkeiten, in den Build eingebunden. Signiertes SBOM geplant	Geliefert
Schließen des Popups = vorübergehender Zugriffsverlust	Trade-off der ersten Version: Der private Schlüssel wird nicht persistiert, um die Angriffsfläche zu begrenzen. Demnächst: konfigurierbares Auto-Lock + Persistenz über einen kontrollierten Service Worker.	Demnächst
Erfassung von Anmeldedaten auf einer Phishing-Website	Der Benutzer sieht den echten Domainnamen im Popup der Erweiterung, bevor er auf „Speichern“ klickt	Geliefert

3.5 Selbstgehostete Infrastruktur

Bedrohung	Gegenmaßnahme	Status
Kompromittiertes Docker-Image	Automatisierter Schwachstellenscan in der CI. Sigstore-Signatur für die benutzerseitige Verifizierung beim Deployment geplant	In Bearbeitung
Ungetestetes Backup	Automatisierter Wiederherstellungstest in der CI bei jedem Release. Kein ungeprüftes Backup in der Produktion	Geliefert
mTLS in der Produktion	Per Konfiguration aktivierbar. Audit-Modus (nur Logs) sowie anschließender Enforcement-Modus verfügbar	Geliefert

4. Schutzumfang - bewusst akzeptierte Grenzen

Redaktionelle Ehrlichkeit: Hier sind die Angriffsflächen, die ARDNTECH nicht allein abdeckt, sowie die empfohlene Gegenmaßnahme.

Grenze	Warum	Empfohlene Gegenmaßnahme
Vollständige Kompromittierung des Endgeräts des Benutzers	Eine Malware mit Zugriff auf den RAM des Browsers kann den entschlüsselten privaten Schlüssel auslesen	Hardware-Passkey (YubiKey, TPM), der den Schlüssel in einem Secure Element einschließt
Kompromittierung des ARDNTECH-Servers (root)	Ein Angreifer mit Root-Rechten kann aktive HTTP-Sitzungen auslesen	Die gespeicherten Secrets bleiben unlesbar (zero-knowledge). Nur die zum Zeitpunkt der Kompromittierung geöffneten Sitzungen sind gefährdet. Ein kurzes Auto-Lock wird empfohlen
Verlust des Master-Passworts	Direkte Folge des strikten zero-knowledge-Ansatzes: keine serverseitige Möglichkeit, den Schlüssel wiederherzustellen	Bei der Erstellung ausgedruckte Wiederherstellungscodes. Demnächst: Shamir-Teilung M-von-N für Enterprise-Pläne
Quantencomputer-Gegner (Horizont > 2030)	OpenPGP v6 + AES-256 gelten laut RGS ANSSI 2024 für 5 bis 10 Jahre als sicher	Post-Quanten-Migration (ML-KEM, ML-DSA) wird langfristig evaluiert
Physischer Angriff auf das Endgerät des Benutzers	ARDNTECH ist ein logischer Tresor, kein physischer Tresor	Kurzes Auto-Lock des Tresors + Hardware-WebAuthn-Passkey
ARDNTECH-Insider (künftiger Mitarbeiter)	Bewusst akzeptierte Grenze des Vertrauensmodells eines SaaS-Herstellers	NDA, Aufgabentrennung, verpflichtende Code-Reviews, manipulationssichere Audit-Kette, Prinzip der geringsten Rechte

5. Bewusst akzeptierte Trade-offs

5.1 Secret- und Ordnernamen serverseitig im Klartext

Entscheidung: Namen werden serverseitig im Klartext gespeichert.

Warum: sofortige serverseitige Suche, Anzeige der Baumstruktur ohne Entschlüsselung bei jeder Navigation, hierarchische Ordnerfreigabe möglich.

Auswirkung: Ein Angreifer, der die Datenbank exfiltriert, sieht, dass ein Secret mit dem Namen „AWS Prod“ im Ordner „DevOps / Cloud“ existiert. Er sieht NICHT den Inhalt (E2E-verschlüsseltes Payload).

Erwogene Alternative: eine Option „anonymise me“, die auch die Namen verschlüsselt. Erhebliche UX-Kosten: keine serverseitige Suche, vollständiger clientseitiger Scan bei jeder Anfrage.

5.2 Passwort im Klartext im DOM während der Eingabe

Entscheidung: OpenPGP verschlüsselt das Payload, nachdem der Benutzer sein Passwort eingegeben hat.

Warum: keine Alternative - der Browser muss den Klartext sehen, damit der Benutzer ihn eingeben kann.

Gegenmaßnahmen: Trusted Types CSP verhindert, dass DOM-XSS exfiltrierendes JavaScript einschleust. Demnächst: WebAuthn-Passkeys, die die Übertragung von Passwörtern vollständig eliminieren.

5.3 Master-Passwort = einziger Schlüssel des Tresors

Entscheidung: keine Wiederherstellung, wenn der Benutzer sowohl sein Master-Passwort ALS AUCH seine Wiederherstellungscodes verliert.

Warum: striktes zero-knowledge. Könnten wir eine Wiederherstellung anbieten, gäbe es einen serverseitigen Entschlüsselungspfad.

Künftige Gegenmaßnahme: Shamir-Teilung des privaten Schlüssels (M-von-N-Teile), ein Teil bei ARDNTECH mit prozeduralen Sicherheitsvorkehrungen (Entsperrung nur bei Vorliegen von N-1 weiteren, vom Benutzer validierten Teilen). Vorbehalten den Enterprise-Plänen.

6. Incident-Response-Plan

Stufe	Auslöser	Maßnahme
L1 Verdacht	Anomalie im Audit-Protokoll, Meldung durch einen Benutzer	Interne Untersuchung innerhalb von 24 h, Überprüfung der Audit-Kette
L2 Bestätigte Kompromittierung	Durch die Untersuchung bestätigte technische Kompromittierung	Benutzerbenachrichtigung innerhalb von 72 h (DSGVO Art. 33), Rotation der betroffenen Schlüssel, Einrichtung von Gegenmaßnahmen
L3 Schwerwiegende Kompromittierung	Datenbank oder Quellcode kompromittiert	Benachrichtigung von CNIL und ANSSI, öffentlicher Transparency Report, externes forensisches Audit

Responsible Disclosure: Gemäß RFC 9116 weist eine Datei /.well-known/security.txt im Stammverzeichnis der Website unsere Kontaktadresse security@aegirex.eu aus. Eingangsbestätigungsfrist: 72 h.

Das Dokument präzisieren?

Dieses Threat model ist ein lebendiges Dokument. Wenn Sie CISO, Auditor oder Sicherheitsforscher sind und eine Bedrohung schlecht modelliert ist, kontaktieren Sie uns direkt.

Matrix Claims/Beweise security@aegirex.eu

Öffentliches <em>Threat-Model.</em>