Verschlüsselungsüberprüfung

Dieser Abschnitt dokumentiert die kryptografische Architektur von Passwork zu Compliance- und Audit-Zwecken und bietet spezifische Überprüfungsschritte für On-Premise-Deployments.

---

1. Überblick über die Verschlüsselungsarchitektur

Passwork verwendet ein geschichtetes Verschlüsselungsmodell. Das Verständnis der Architektur ist erforderlich, um die Sicherheitslage korrekt bewerten zu können.

Zweistufiger Schutz

Ebene	Algorithmus	Wann aktiv	Was geschützt wird
Serverseitig	AES-256-CFB	Immer	Alle ruhenden Daten in der Datenbank
Clientseitig (CSE)	AES-256-CBC	Wenn CSE aktiviert ist	Passwörter, benutzerdefinierte Felder, TOTP-Secrets, Anhänge

Bei deaktiviertem CSE: Alle Daten werden durch den Serverschlüssel verschlüsselt. Ein Datenbankadministrator mit Zugriff auf sowohl die Datenbank als auch den Serverschlüssel kann Daten entschlüsseln. Die serverseitige Verschlüsselung schützt vor dem Diebstahl von Datenbankdateien.

Bei aktiviertem CSE: Kritische Felder (Passwörter, Secrets) werden auf dem Gerät des Benutzers verschlüsselt, bevor sie an den Server gesendet werden. Der Server hält niemals unverschlüsselte Passwörter. Die serverseitige Verschlüsselung fügt eine zweite Schicht darüber hinzu.

Schlüsselhierarchie (CSE aktiviert)

Master password (user-known, never transmitted)
    ↓ PBKDF2 (SHA-256, 300,000 iterations)
Master key (512 bits, in memory only)
    ↓ AES-256-CBC
Private RSA key (2048 bits, stored encrypted on server)
    ↓ RSA-OAEP (SHA-256)
Vault key (256 bits, stored RSA-encrypted per user on server)
    ↓ AES-256-CBC
Record key (256 bits, per record, stored encrypted on server)
    ↓ AES-256-CBC
Password field, custom fields, TOTP secret, attachment keys

Jeder Tresor und jeder Datensatz hat einen eindeutigen Schlüssel. Die Kompromittierung eines Schlüssels legt keine anderen Datensätze oder Tresore offen. Der Master-Schlüssel existiert nur im Browser-Speicher und wird niemals dauerhaft auf dem Server gespeichert.

Vollständige Spezifikation der Schlüsselhierarchie: Schlüsselhierarchie

---

2. CSE-Status und Begründung überprüfen

2.1 Aktuellen CSE-Status ermitteln

Navigieren Sie zu Einstellungen → Systemeinstellungen → Registrierung (oder prüfen Sie config.env):

CSE-Status	Indikator
Aktiviert	Benutzer werden bei der Anmeldung zur Eingabe eines Masterpassworts aufgefordert
Deaktiviert	Benutzer melden sich ohne Abfrage eines Masterpassworts an

Sie können auch config.env prüfen (On-Premise):

grep -i "client_side_encryption\|CSE\|ENCRYPTION" /var/www/init/config.env

2.2 Überprüfen, dass die Entscheidung beabsichtigt und dokumentiert ist

Die CSE-Entscheidung sollte in der Informationssicherheitsrichtlinie der Organisation oder im Entscheidungsprotokoll des Passwork-Deployments dokumentiert sein.

Deployment-Szenario	Erwarteter CSE-Status
Cloud-gehostetes Passwork (passwork.pro)	Immer aktiviert — kann nicht deaktiviert werden
On-Premise, aus dem Internet erreichbar	Aktiviert dringend empfohlen
On-Premise, air-gapped / privater Perimeter, strenge physische Sicherheit	Deaktiviert akzeptabel mit dokumentierter Begründung

Feststellung: Wenn CSE auf einer aus dem Internet erreichbaren On-Premise-Instanz ohne dokumentierte Begründung deaktiviert ist, handelt es sich um eine Feststellung mit hohem Schweregrad.

2.3 Bei aktiviertem CSE — operative Kontrollen überprüfen

• Die Komplexitätsrichtlinie für das Masterpasswort ist konfiguriert (≥ 14 Zeichen)
• Das Helpdesk verfügt über eine dokumentierte Vorgehensweise zum Zurücksetzen des Masterpassworts (mit Auswirkung auf den Benutzer: Verlust der privaten Tresordaten)
• Die Benutzer sind geschult, Masterpasswörter sicher offline zu speichern
• Die Tresoradministratoren wissen, wie sie nach dem Zurücksetzen eines Masterpassworts erneute Tresorzugriffsanfragen genehmigen

---

3. Server-Verschlüsselungsschlüssel

Der Server-Verschlüsselungsschlüssel (encryption_key-Datei) wird für die AES-256-CFB-Verschlüsselung aller ruhenden Daten verwendet. Er ist das sensibelste Secret in einem On-Premise-Passwork-Deployment.

3.1 Speicherort und Berechtigungen der Schlüsseldatei

# Linux
ls -la /var/www/init/
# Look for the encryption_key file
# Expected: -rw------- 1 www-data www-data

# Docker
ls -la /<passwork>/conf/keys/

Überprüfen Sie:

• Die Schlüsseldatei ist nicht für den Datenbankbenutzer, andere Webanwendungen oder für alle lesbar zugänglich
• Die Schlüsseldatei wird nicht innerhalb des Datenbankverzeichnisses gespeichert
• Dateiberechtigungen: 600 (nur Lesen/Schreiben für den Besitzer)
• Dateibesitzer: der Prozessbenutzer des Webservers (z. B. www-data)

Feststellung: Wenn die Dateiberechtigungen 644 oder weiter gefasst sind, handelt es sich um eine Feststellung mit hohem Schweregrad. Der Schlüssel schützt alle serverseitig verschlüsselten Daten.

3.2 Speicherung des Schlüssel-Backups

Der Verschlüsselungsschlüssel muss separat vom Datenbank-Backup gesichert werden. Wenn beide zusammen gespeichert werden, kompromittiert eine einzige Sicherheitsverletzung sowohl den Chiffretext als auch den Schlüssel.

Überprüfen Sie:

• Der Verschlüsselungsschlüssel wird unabhängig von der Datenbank gesichert
• Das Schlüssel-Backup wird an einem anderen physischen oder logischen Ort als das Datenbank-Backup gespeichert
• Das Schlüssel-Backup selbst ist verschlüsselt (z. B. mit GPG und einer separaten Passphrase)

3.3 Schlüsselrotation

Passwork unterstützt derzeit keine automatisierte Rotation des Serverschlüssels. Der Schlüssel bleibt nach dem ersten Deployment statisch. Dokumentieren Sie das aktuelle Alter des Schlüssels und vermerken Sie dies im Sicherheitsregister.

---

4. Überprüfung der Algorithmus-Compliance

Die kryptografischen Algorithmen von Passwork im Vergleich zu aktuellen Standards:

Algorithmus	Passwork-Implementierung	NIST SP 800-131A Rev. 2 (2019)	Status
AES	256-Bit, CBC/CFB	AES-128/192/256 zugelassen	✓ Konform
RSA	2048-Bit, OAEP/SHA-256	RSA ≥ 2048 Bit zugelassen	✓ Konform
PBKDF2	SHA-256, 300.000 Iterationen	≥ 310.000 Iterationen für SHA-256 (NIST 2024)	⚠ Eine Iteration unter dem NIST-Update 2024
SHA-2	SHA-256 / SHA-512	Zugelassen	✓ Konform
CSPRNG	WebCrypto (Browser) / OpenSSL (Server)	Zugelassen	✓ Konform
TLS	1.2+ (1.3 bevorzugt)	Mindestens TLS 1.2	✓ Konform

PBKDF2-Iterationsanzahl

NIST SP 800-132 (Update 2024) empfiehlt ≥ 310.000 Iterationen für PBKDF2-HMAC-SHA-256. Passwork verwendet 300.000 (clientseitig) und 600.000 (serverseitige Verifizierung). Die clientseitige Anzahl liegt geringfügig unter der Empfehlung von 2024; sie erfüllt vollständig die NIST-Vorgaben vor 2024 (10.000 Iterationen). Dies ist ein informativer Hinweis mit geringem Schweregrad, keine kritische Feststellung.

---

5. Verschlüsselungsumfang — was der Server sehen kann

Für die Compliance-Dokumentation ist es wichtig zu wissen, welche Datenfelder dem Serveradministrator in jedem Verschlüsselungsmodus zugänglich sind.

Bei aktiviertem CSE (Zero-Knowledge-Modell)

Der Server kann lesen (unverschlüsselt oder nur serverseitig verschlüsselt gespeichert):

• Tresornamen, Ordnernamen
• Datensatznamen (Titel)
• Login-/Benutzername-Feld
• URL-Feld
• Tags und Farbkennzeichnungen
• Beschreibungs-/Notizfeld
• Dateinamen (nicht Dateiinhalte)
• Benutzer-E-Mails und Benutzernamen
• Gruppenmitgliedschaften, Tresorzugriffsrechte, Zeitstempel

Der Server kann NICHT lesen (clientseitig verschlüsselt, Zero-Knowledge):

• Passwort-Feld
• Namen und Werte benutzerdefinierter Felder
• TOTP-Secrets
• Dateiinhalte
• Revisionsverlauf von Datensätzen (frühere Passwörter)

Bei deaktiviertem CSE

Der serverseitige Verschlüsselungsschlüssel schützt alle ruhenden Daten, aber eine Partei mit Zugriff auf sowohl die Datenbank als auch die encryption_key-Datei kann alle Felder entschlüsseln, einschließlich der Passwörter.

Dies ist für Organisationen akzeptabel, bei denen das Bedrohungsmodell keine Insider-Bedrohungen durch Infrastrukturadministratoren umfasst und Passwork in einem vertrauenswürdigen, isolierten Netzwerk läuft.

In den Compliance-Aufzeichnungen dokumentieren: Ob Zero-Knowledge durch Ihre Sicherheitsrichtlinie oder Ihren regulatorischen Rahmen erforderlich ist.

Vollständiger feldweiser Verschlüsselungsumfang: Verschlüsselungsumfang

---

6. Backup-Verschlüsselung

Datenbank-Backups enthalten alle Passwork-Daten. Unverschlüsselte Backups, die auf zugänglichen Medien gespeichert sind, entsprechen einer unverschlüsselten Datenbank.

Was zu überprüfen ist

• Datenbank-Backups (MongoDB) sind am Backup-Speicherort ruhend verschlüsselt
• Der Zugriff auf den Backup-Speicher ist auf autorisiertes Personal beschränkt
• Backup-Verschlüsselungsschlüssel werden getrennt von den Backup-Daten gespeichert
• Die Wiederherstellung des Backups wurde innerhalb der letzten 6 Monate getestet
• Backups werden für die von Ihrer Datenaufbewahrungsrichtlinie geforderte Dauer aufbewahrt

Zur Konfiguration von MongoDB-Backups siehe Beispiele zur Erstellung und Wiederherstellung von Backups.

---

Zusammenfassende Checkliste

#	Kontrolle	Status
2.1	CSE-Status ist bekannt und verifiziert
2.2	CSE-Entscheidung ist mit Begründung dokumentiert
2.3	Falls CSE aktiviert: Masterpasswort-Richtlinie ≥ 14 Zeichen
3.1	Server-Verschlüsselungsschlüssel-Datei: Berechtigungen 600, korrekter Besitzer
3.2	Verschlüsselungsschlüssel getrennt von der Datenbank gesichert
3.3	Schlüsselalter dokumentiert
4	Algorithmus-Compliance dokumentiert (NIST); PBKDF2-Hinweis vermerkt
5	Verschlüsselungsumfang in den Compliance-Aufzeichnungen dokumentiert
6.1	Backups ruhend verschlüsselt
6.2	Backup-Wiederherstellung innerhalb der letzten 6 Monate getestet

LLM version