Sicherheitsfunktionen von Passwortmanagern bewerten

Sicherheitsfunktionen von Passwort-Managern: So bewerten Sie sie richtig

Jeder Anbieter von Passwort-Managern behauptet, hohe Sicherheit zu bieten. Nur wenige legen Ihnen die Architekturdokumentation oder die Pentest-Zusammenfassung vor, die eine Überprüfung ermöglichen würden. Die Lücke zwischen einer Sicherheitsseite und einer verifizierten Aussage ist der Punkt, an dem die Sorgfaltsprüfung beginnen muss.

Die Bewertung der Sicherheitsfunktionen eines Passwort-Managers bedeutet, Verschlüsselungsarchitektur, Authentifizierungsstärke, Zugriffssteuerung, unabhängige Verifizierung, Compliance-Ausrichtung und betriebliche Resilienz anhand von Nachweisen zu prüfen — nicht anhand von Marketingtexten.

Dies ist ein Leitfaden zur Sicherheitsverifizierung, kein Einkaufsratgeber, und Teil unseres umfassenderen Leitfadens für Enterprise-Passwort-Management. Wenn Sie noch Anbieter nach Kosten, Deployment und DevOps-Eignung vergleichen, beginnen Sie mit dem vollständigen 10-Kriterien-Bewertungsrahmen; kehren Sie hierher zurück, sobald Sie eine Auswahlliste haben und die Sicherheitsaussagen überprüfen müssen.

Wichtige Erkenntnisse

Verifizieren, nicht blind vertrauen: Prüfen Sie jede Sicherheitsseite eines Anbieters anhand von Nachweisen, bevor Sie unterzeichnen.
Zero-Knowledge und Verschlüsselung im Ruhezustand sind nicht dasselbe. Fragen Sie, wo Schlüssel generiert und gespeichert werden.
MFA-Stärke und Session-Timeout-Verhalten sind wichtiger als eine Feature-Liste — testen Sie selbst.
RBAC-Granularität und echte Offboarding-Widerrufung, über ein SSO-Deaktivieren hinaus, definieren das Prinzip der minimalen Rechte in der Praxis.
Ein aktuelles ISO/IEC 27001-Zertifikat und eine Pentest-Zusammenfassung sind der Basisnachweis, keine Extras.
Ordnen Sie Anbieteraussagen konkreten DSGVO-, NIS2- und NIST-Klauseln zu, nicht vagen „compliant"-Formulierungen.

Warum „es hat Verschlüsselung" keine Sicherheitsantwort ist

„Wir verwenden militärische Verschlüsselung" sagt nichts darüber aus, wer Ihren Tresor entschlüsseln kann, wie sich ein Sicherheitsvorfall auswirken würde oder ob jemals ein externer Prüfer die Behauptung getestet hat. Verschlüsselung ist Grundvoraussetzung, kein Alleinstellungsmerkmal. Was Ihr tatsächliches Risiko bestimmt, liegt eine Ebene unter dem Marketingtext.

Die Konsequenzen falscher Entscheidungen steigen weiter. Die globalen Durchschnittskosten einer Datenschutzverletzung erreichten 4,99 Millionen US-Dollar im Jahr 2026, ein Anstieg um 12 % und ein neuer Rekord, laut IBMs Cost of a Data Breach Report 2026. Das Risiko durch Anmeldedaten ist ebenfalls nicht verschwunden: Verizons Data Breach Investigations Report 2026 ergab, dass die Ausnutzung von Schwachstellen auf 31 % der Sicherheitsverletzungen als ersten erfassten Einstiegspunkt im Jahr 2026 anstieg und damit den Missbrauch von Anmeldedaten übertraf, der in dieser ersten Erfassung auf 13 % fiel. Betrachtet man den gesamten Angriffsverlauf und nicht nur den ersten Schritt, taucht der Missbrauch von Anmeldedaten immer noch in 39 % der Sicherheitsverletzungen auf — der häufigste Engpass im Bericht.

Eine verifizierte Aussage und eine nicht verifizierte können auf einer Website identisch aussehen. „Ihre Daten werden mit AES-256 verschlüsselt" trifft sowohl auf einen Passwort-Manager mit echter Zero-Knowledge-Architektur zu als auch auf einen, bei dem der Anbieter jeden Schlüssel besitzt und Datensätze auf Anfrage entschlüsseln kann. Die Formulierung allein gibt keinen Hinweis darauf, welchen Sie kaufen. Diese Lücke schließt dieses Framework, Säule für Säule.

Jede Aussage auf der Sicherheitsseite eines Anbieters ist überprüfbar. Die sechs folgenden Säulen geben Ihnen eine feste Liste dessen, was und wie zu prüfen ist.

Weiterführende Lektüre

Das Framework zur Sicherheitsverifizierung von Passwort-Managern

Das Framework zur Sicherheitsverifizierung von Passwort-Managern unterteilt die Anbieter-Sorgfaltsprüfung in sechs Säulen: Verschlüsselungsarchitektur, Authentifizierungs- und Sitzungssicherheit, Zugriffssteuerung, unabhängige Verifizierung, Compliance-Ausrichtung und betriebliche Resilienz. Wenden Sie die folgende Scorecard auf jeden Anbieter an — aktuellen oder potenziellen — bevor Sie einer Aussage vertrauen, die Sie nicht selbst überprüft haben.

Säule	Was zu prüfen ist	Wie verifizieren	Bestanden/Nicht bestanden
1. Verschlüsselungsarchitektur	Zero-Knowledge vs. Verschlüsselung im Ruhezustand, Schlüsselstandort	Architekturdokumentation anfordern; fragen, wo Schlüssel generiert werden	Nicht bestanden: Anbieter kann Ihre Daten auf Anfrage entschlüsseln
2. Authentifizierung & Sitzungssicherheit	MFA-Methodenstärke, Passkey-Unterstützung, Sitzungs-Timeout	Auto-Lock und Re-Authentifizierung selbst testen	Nicht bestanden: Nur SMS-MFA, kein konfigurierbares Timeout
3. Zugriffssteuerung	RBAC-Granularität, Offboarding-Widerrufung	Offboarding simulieren; prüfen, was nach SSO-Deaktivierung bestehen bleibt	Nicht bestanden: Geteilte Passwörter, die niemand zentral rotieren kann
4. Unabhängige Verifizierung	ISO/IEC 27001, Pentest-Häufigkeit	Aktuellen Bericht und Zertifikatsdaten anfordern	Nicht bestanden: Kein Bericht oder abgelaufenes Zertifikat
5. Compliance-Ausrichtung	Zuordnung zu DSGVO-, NIS2-, NIST-Klauseln	Fragen, welchem Artikel oder Abschnitt eine Aussage zugeordnet ist	Nicht bestanden: Nur „wir sind compliant", keine Klausel genannt
6. Betriebliche Resilienz	Offline-Zugriff, Backups, Deployment-Modell	Fragen, was bei Ausfall oder verlorenem Gerät passiert	Nicht bestanden: Kein dokumentierter Wiederherstellungsprozess

Behandeln Sie die vierte Spalte als aktives Arbeitsblatt, nicht als Beschreibung. Tragen Sie für jede Säule ein tatsächliches Bestanden oder Nicht bestanden ein, während Sie Nachweise sammeln, und bewerten Sie alles, was Sie nicht innerhalb eines angemessenen Zeitrahmens verifizieren können, standardmäßig als Nicht bestanden. Ein Anbieter, der drei Nachfass-E-Mails für eine Dokumentationsanfrage benötigt, sagt Ihnen auch etwas darüber, wie er mit einem Sicherheitsvorfall umgehen wird.

Jede Säule erhält unten einen eigenen Abschnitt mit den konkreten Fragen, die zu stellen sind, und was ein Bestanden oder Nicht bestanden in der Praxis bedeutet.

Säule 1: Verschlüsselungsarchitektur und Zero-Knowledge-Design

Zero-Knowledge-Architektur bedeutet, dass der Anbieter Ihre Daten auch unter rechtlichem Zwang nicht lesen kann — nicht, dass er einfach beschließt, nicht hinzusehen. Verschlüsselung im Ruhezustand ist eine viel schwächere Aussage: Der Anbieter besitzt die Schlüssel und kann im Prinzip Ihren Tresor entschlüsseln. Die Verwechslung dieser beiden Konzepte ist die häufigste Lücke auf Sicherheitsseiten von Anbietern.

Verschlüsselung im Ruhezustand vs. Zero-Knowledge

Verschlüsselung im Ruhezustand schützt Daten vor einem Außenstehenden, der die Datenbank stiehlt. Sie schützt Daten nicht vor dem Anbieter selbst, vor einer Vorladung oder vor einem Insider mit Datenbankzugriff. Zero-Knowledge, auch als Ende-zu-Ende-Verschlüsselung bezeichnet, wenn sie über synchronisierte Geräte hinweg angewendet wird, schließt diese Lücke: Verschlüsselung und Entschlüsselung finden ausschließlich auf dem Client statt, und der Server speichert nur Chiffretext und verschlüsseltes Schlüsselmaterial, das er allein nicht entschlüsseln kann. Zero-Knowledge-Architektur ist der Begriff, nach dem Sie namentlich suchen sollten, nicht „starke Verschlüsselung".

So testen Sie die Aussage

Die Mechanik ist wichtiger als das Etikett. Schlüssel sollten clientseitig mit einem kryptografisch sicheren Zufallszahlengenerator generiert, durch eine Schlüsselableitungsfunktion (KDF) wie PBKDF2 oder Argon2 mit hoher Iterationszahl abgeleitet und zur Verschlüsselung von Tresor- und Datensatzdaten mit AES-256 verwendet werden. Separate Schlüssel pro Tresor oder pro Datensatz, statt eines einzigen Master-Schlüssels für die gesamte Organisation, begrenzen den Schadensradius, falls ein einzelner Schlüssel jemals kompromittiert wird.

Ein nützlicher Test, ob die Erklärung eines Anbieters stimmt: Bitten Sie ihn, die Kette vom Masterpasswort bis zum Klartext-Datensatz durchzugehen. In einem echten Zero-Knowledge-Design verläuft diese Kette durchgehend clientseitig. Das Masterpasswort leitet einen Master-Schlüssel ab, der Master-Schlüssel entschlüsselt einen privaten Schlüssel, der verschlüsselt auf dem Server liegt, der private Schlüssel entsperrt die Tresor-Schlüssel, und die Tresor-Schlüssel entsperren die einzelnen Datensatz-Schlüssel, die jedes Passwort oder Geheimnis entschlüsseln. Wenn die Erklärung einen Schritt auslässt oder der Server an der Entschlüsselung teilnehmen muss, ist die Architektur nicht Zero-Knowledge — unabhängig davon, was die Broschüre sagt.

Verifizierungs-Checkliste

Architektur- oder Kryptografie-Dokumentation anfordern.
Bestätigen, wo Verschlüsselungsschlüssel generiert werden: Client-Gerät oder Server.
Fragen, ob Schlüssel pro Tresor eindeutig sind oder organisationsweit geteilt werden.
Bestätigen, welche KDF verwendet wird und deren Iterationszahl oder Speicherkosten.

Weiterführende Lektüre

Passwork vs. Bitwarden: Wie sich die Tresor-Verschlüsselungsarchitektur unterscheidet. Die beiden Produkte veranschaulichen diese Säule von entgegengesetzten Enden. Passwork generiert einen unabhängigen AES-256-Schlüssel für jeden Tresor, sodass ein geleakter Schlüssel nur diesen einen Tresor exponiert, nicht den Rest der Organisation. Bitwarden leitet einen einzigen Organisations-Symmetrischen-Schlüssel ab, der den Cipher-Schlüssel jedes Unternehmens-Elements umschließt, sodass ein kompromittierter Organisationsschlüssel alles exponiert, was der Organisation gehört. Beide sind legitime Zero-Knowledge-Designs — der Unterschied liegt im Schadensradius, nachdem ein einzelner Schlüssel kompromittiert wurde.

Säule 2: Authentifizierung und Sitzungssicherheit

NIST SP 800-63B-4 weist Verifizierer an, die Nutzung von Passwort-Managern und Autofill-Funktionalität zu erlauben (Abschnitt 3.1.1.2). Ein Anbieter, dessen Produkt Browser-Autofill bekämpft oder dessen Standardrichtlinie immer noch eine 90-Tage-Passwortrotation erzwingt, arbeitet gegen den aktuellen Standard, nicht für Ihre Sicherheit.

MFA- und Passkey-Stärke

Multi-Faktor-Authentifizierung (MFA) ist nicht verhandelbar, aber nicht alle MFA ist gleich. SMS-Codes sind die schwächste Option und anfällig für SIM-Swap-Angriffe. Zeitbasierte Einmalpasswörter (TOTP) sind stärker und funktionieren offline. Push-Benachrichtigungen bieten Komfort, sind aber anfällig für Prompt-Bombing, es sei denn, sie werden mit Nummernabgleich kombiniert. Hardware-Sicherheitsschlüssel und Passkeys, basierend auf dem FIDO2-Standard, widerstehen Phishing durch Design, da die Anmeldedaten an den Ursprung gebunden sind, für den sie erstellt wurden. Passkey-Unterstützung signalisiert einen Anbieter, der mit aktuellen Standards Schritt hält.

Biometrische Entsperrung verdient ebenfalls einen genaueren Blick. Face ID oder ein Fingerabdruckleser ist normalerweise eine Komfortschicht über der eigentlichen Anmeldeinformation und entsperrt einen auf dem Gerät gespeicherten Schlüssel, anstatt MFA vollständig zu ersetzen. Das ist ein vernünftiger Kompromiss auf einem persönlichen Gerät, aber bestätigen Sie, was auf einem gemeinsam genutzten oder nicht verwalteten Gerät passiert: Gewährt biometrische Entsperrung allein Tresor-Zugriff, oder erfordert sie immer noch den zugrunde liegenden Authentifizierungsschritt?

Masterpasswort- und Sitzungsregeln

Masterpasswort-Anforderungen verdienen die gleiche Prüfung. NIST SP 800-63B-4 setzt eine konkrete Messlatte: mindestens 15 Zeichen für Einzelfaktor-Passwörter und keine periodische Rotationsanforderung ohne Nachweis einer Kompromittierung. Wenn die Standardrichtlinie eines Anbieters immer noch eine Masterpasswort-Änderung alle 90 Tage erzwingt, ist diese Richtlinie veraltet.

Sitzungs-Timeout und Auto-Lock-Verhalten bestimmen, wie lange ein gestohlenes oder unbeaufsichtigtes Gerät ausnutzbar bleibt. Verlassen Sie sich nicht auf das Datenblatt. Öffnen Sie die App, lassen Sie sie für das angegebene Timeout-Fenster im Leerlauf und bestätigen Sie, dass sie tatsächlich sperrt. Testen Sie auch, was nach einem Passwort-Reset passiert: Werden alle anderen aktiven Sitzungen sofort widerrufen, oder funktioniert eine veraltete Sitzung auf einem zweiten Gerät weiter?

Checkliste

Angebotene MFA-Optionen: TOTP, Push mit Nummernabgleich, Hardware-Schlüssel, Passkey/FIDO2.
Masterpasswort-Richtlinie: längenbasiert, keine Rotation in festen Intervallen.
Sitzungs-Timeout und Auto-Lock: selbst testen, nicht nur die Spezifikation lesen.
Behandlung gleichzeitiger Sitzungen nach erzwungenem Passwort-Reset oder Abmeldung.

Säule 3: Zugriffssteuerung und minimale Rechte

Rollenbasierte Zugriffssteuerung (RBAC) klingt wie ein Kontrollkästchen, bis Sie testen, was passiert, wenn jemand das Unternehmen verlässt. Das Deaktivieren eines Single-Sign-On-Accounts (SSO) widerruft verzeichnisbasierten Zugriff. Es ändert nichts an einem geteilten Passwort, das vier Personen bereits kennen, einem API-Schlüssel, der in einer CI-Pipeline zwischengespeichert ist, oder einem lokal gespeicherten Token.

Wie granular RBAC tatsächlich wird

Fragen Sie, wie granular RBAC tatsächlich wird. Zugriff auf Rollenebene („Administrator" versus „Mitglied") ist die gröbste Option. Gruppenbasierter Zugriff, bei dem Berechtigungen an ein Team oder eine Abteilung angehängt werden und Personen sie durch Mitgliedschaft erben, skaliert besser und entspricht der beabsichtigten Funktionsweise von rollenbasierter Zugriffssteuerung: Gewähren Sie der Gruppe einmal Zugriff, dann fügen Sie Personen hinzu oder entfernen sie. Zugriff pro Ordner oder pro Element, über Gruppen hinaus geschichtet, ermöglicht es einem Administrator, die Anmeldedaten eines Lieferanten an einen Auftragnehmer weiterzugeben, ohne den gesamten Tresor zu öffnen.

SSO-Deaktivierung ist keine Widerrufung

SSO- oder AD-Deaktivierung ist keine Zugriffswiderrufung. Es ist eine Verzeichnis-Deaktivierung. Ein ausscheidender Mitarbeiter, der ein Login für ein Lieferantenportal, ein Netzwerkgerät oder eine Legacy-Anwendung geteilt hat, kennt dieses Passwort immer noch, bis jemand es ändert. Die Verifizierung der Zugriffssteuerung bedeutet zu fragen, wie der Anbieter diese Lücke handhabt: Wird eine geteilte Anmeldeinformation beim Offboarding zur Rotation markiert, oder bleibt sie einfach unverändert und nicht widerrufen?

Die Dringlichkeit hier ist nicht theoretisch. Die durchschnittliche eCrime-Breakout-Zeit — die Zeit vom Erstzugriff bis zur lateralen Bewegung — sank 2025 auf 29 Minuten, 65 % schneller als 2024, laut CrowdStrikes Global Threat Report 2026. Eine jährliche Zugriffsüberprüfung erfasst keine Anmeldeinformation, die im April hätte widerrufen werden sollen. Echtzeitige, ereignisgesteuerte Widerrufung schon.

Maschinenidentitäten brauchen die gleiche Disziplin

Das Prinzip der minimalen Rechte muss auf Maschinenidentitäten ausgedehnt werden, nicht nur auf Personen. API-Schlüssel, Dienstkonten und CI/CD-Anmeldedaten liegen oft vollständig außerhalb des RBAC-Modells, einmal bereitgestellt und nie wieder überprüft. Fragen Sie, ob Dienstkonten ihre eigenen begrenzten Rollen und Rotationsrichtlinien erhalten, getrennt von interaktiven Benutzerkonten, oder ob sie ein Nachgedanke sind, der an dasselbe für Menschen gebaute Berechtigungssystem angeflanscht wurde.

Stellen Sie noch eine weitere Frage: Kann der Anbieter beantworten „Wer hatte letzten Monat Zugriff auf diese Anmeldeinformation", nachträglich, aus einem Audit-Log, ohne ein Support-Ticket? Wenn nicht, ist das Prinzip der minimalen Rechte eine Richtlinienaussage, keine durchgesetzte Kontrolle.

Säule 4: Unabhängige Verifizierung: Audits, Zertifizierungen und Vorfallhistorie

Jeder kann „Enterprise-Grade-Sicherheit" auf eine Landingpage schreiben. Ein aktuelles, namentlich genanntes Sicherheitszertifikat mit gültigem Datumsbereich, eine aktuelle Penetrationstest-Zusammenfassung und eine dokumentierte Vorfallhistorie sind der Unterschied zwischen einer Aussage und einer Aussage, die Sie überprüfen können. Wenn ein Anbieter keines der drei vorlegt, behandeln Sie das als Antwort.

Was ein Zertifikat tatsächlich beweist

Eine ISO/IEC 27001-Zertifizierung bestätigt, dass ein Anbieter ein zertifiziertes Informationssicherheits-Managementsystem betreibt, das von einem akkreditierten externen Prüfer gegen einen anerkannten internationalen Standard bewertet wurde — keine selbst bewertete Checkliste. Überprüfen Sie das Ausstellungs- und Ablaufdatum des Zertifikats direkt, anstatt einem Badge auf einer Website zu vertrauen: Zertifizierungen werden typischerweise jährlich erneuert, und ein Badge ohne sichtbares Datum könnte Jahre veraltet sein.

Eine Penetrationstest-Zusammenfassung, idealerweise von einem unabhängigen Dritten oder koordiniert durch ein Programm wie HackerOne, zeigt, ob jemand außerhalb des eigenen Teams des Anbieters kürzlich versucht hat einzubrechen und was gefunden wurde.

Fragen Sie auch, was das Zertifikat tatsächlich abdeckt. Eine Scope-Aussage, die auf „Unternehmens-IT" oder eine einzelne Produktlinie beschränkt ist, ist ein schwächerer Nachweis als eine, die die gesamte Produktionsumgebung abdeckt, die Ihre Anmeldedaten speichert. Einige Anbieter öffnen ihren Quellcode auch für Audits durch Kunden oder unabhängige Forscher. Das ist ein stärkeres Signal als ein Zertifikat allein, obwohl es ungewöhnlich genug ist, dass sein Fehlen nicht automatisch disqualifiziert.

Vorfallhistorie ist selbst ein Sicherheitsmerkmal

Wie ein Anbieter seinen letzten Sicherheitsvorfall gehandhabt hat, falls es einen gab, ist selbst ein Sicherheitsmerkmal. Keine dokumentierte Vorfallhistorie ist für jeden Anbieter, der im großen Maßstab operiert, unplausibel. Die nützlichere Frage ist, ob der Anbieter einen Überwachungs- und Offenlegungsprozess betreibt oder ob „wir hatten nie einen Vorfall" die gesamte Antwort ist.

Was vom Anbieter anzufordern ist

Aktuelles Sicherheitszertifikat (wie ISO/IEC 27001), mit Ausstellungs- und Ablaufdatum.
Aktuellste Penetrationstest-Zusammenfassung und Testhäufigkeit (mindestens jährlich).

Säule 5: Compliance-Ausrichtung (NIST, DSGVO, NIS2 und Branchenvorschriften)

Ein Anbieter, der „DSGVO-konform" oder „NIS2-bereit" behauptet, ohne einen konkreten Artikel zu nennen, macht eine Marketingaussage, keine rechtliche. DSGVO Artikel 32 und NIS2 Artikel 21 nennen jeweils konkrete technische Maßnahmen. Ordnen Sie die Aussagen eines Anbieters direkt diesen Klauseln zu und lassen Sie Ihre Rechtsabteilung bestätigen, was „konform" für Ihre spezifischen Verpflichtungen bedeutet.

DSGVO Artikel 32

DSGVO Artikel 32(1)(a)-(b) verlangt von Verantwortlichen und Auftragsverarbeitern, „die Pseudonymisierung und Verschlüsselung personenbezogener Daten" und „die Fähigkeit, die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste im Zusammenhang mit der Verarbeitung auf Dauer sicherzustellen" zu implementieren (DSGVO, Art. 32). Für einen Passwort-Manager wird dies direkt auf Säule 1 (Verschlüsselungsarchitektur) und Säule 6 (Resilienz) oben abgebildet, nicht auf eine allgemeine Datenschutzrichtlinie.

NIS2 Artikel 21

NIS2 Artikel 21(2) wird noch spezifischer. Artikel 21(2)(h) verlangt „Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung". Artikel 21(2)(j) verlangt „die Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung... wo angemessen" (NIS2-Richtlinie (EU) 2022/2555, Art. 21). Wesentliche und wichtige Einrichtungen unter NIS2 benötigen einen Anbieter, der auf beide Klauseln namentlich verweisen kann, nicht einen, der sagt „ja, wir unterstützen MFA", ohne zu sagen, wo es durchgesetzt wird. NIS2-Zugriffs- und Kryptografieanforderungen gehen tiefer auf das ein, was für europäische Organisationen speziell als konform gilt.

NIST und branchenspezifische Vorschriften

NIST SP 800-63B-4, behandelt unter Säule 2, ist der authentifizierungsspezifische Standard hinter der MFA-Sprache beider Frameworks. Es lohnt sich zu bestätigen, dass die Standardrichtlinie eines Anbieters ihn tatsächlich widerspiegelt, nicht eine ältere, strengere Rotationsregel, die von einem früheren Standard übrig geblieben ist.

Branchenspezifische Vorschriften schichten sich über diese drei. Gesundheitsorganisationen fügen die HIPAA-Sicherheitsregel hinzu, Finanzunternehmen in der EU fügen DORA hinzu, und öffentliche Auftraggeber haben oft Datenhaltungsanforderungen, die keine der oben genannten direkt benennt. Nichts davon ändert die grundlegende Frage an einen Passwort-Manager-Anbieter: Welchen Artikel oder welche Klausel erfüllt seine Architektur, und ist diese Zuordnung dokumentiert oder nur behauptet?

Säule 6: Betriebliche Resilienz, Offline-Zugriff, Backups und Deployment-Modell

Sicherheitsgarantien überstehen keinen Netzwerkausfall, ein verlorenes Gerät oder einen Cloud-Vorfall des Anbieters, es sei denn, der Anbieter hat dafür gebaut. Offline-Zugriff, ein getesteter Backup- und Wiederherstellungsprozess und ein Deployment-Modell, das nicht alle Schlüssel der Infrastruktur eines Unternehmens übergibt, halten einen Passwort-Manager nutzbar — und sicher — wenn etwas kaputt geht.

Netzwerkausfälle und Offline-Zugriff

Fragen Sie, was passiert, wenn das Netzwerk mitten in einer Sitzung ausfällt. Einige Produkte schließen fehlerhaft, sperren Benutzer von allen Anmeldedaten aus, bis die Verbindung wiederhergestellt ist. Andere bieten einen begrenzten, schreibgeschützten Offline-Modus für Datensätze, die ein Benutzer explizit für lokales, verschlüsseltes Caching markiert hat, und synchronisieren alles zurück, sobald die Verbindung wiederhergestellt ist. Schreibgeschützt ist der sicherere Standard: Erstellen, Bearbeiten und Löschen sollten eine aktive, authentifizierte Verbindung erfordern.

Backup und Wiederherstellung

Backup und Wiederherstellung ist die zweite Hälfte der Resilienz. Fragen Sie, wie Backups verschlüsselt werden, wer die Backup-Infrastruktur kontrolliert und wie eine vollständige Wiederherstellung tatsächlich getestet wird — nicht geplant. Ein Backup, das nie in einer Übung wiederhergestellt wurde, ist eine Hoffnung, kein Plan.

Deployment-Modell und Infrastruktur-Resilienz

Das Deployment-Modell entscheidet, wer die Schlüssel kontrolliert. Ein vollständig Cloud-gehosteter Anbieter hält die Infrastruktur, selbst unter einem Zero-Knowledge-Design, was bedeutet, dass Verfügbarkeit und Jurisdiktion von der Cloud-Region und der Vorfallreaktion dieses Anbieters abhängen. Self-Hosted- und Hybrid-Deployment legen die Infrastruktur und die Wahl, wo Daten physisch liegen, in die Hände des Kunden, was am wichtigsten für Organisationen mit Datenhaltungs-, Air-Gap- oder branchenspezifischen Anforderungen im Gesundheitswesen, Finanzwesen, in Behörden oder kritischer Infrastruktur ist.

Fragen Sie auch nach Ausfallmodi auf Infrastrukturebene. Redundante Anwendungsserver und ein ordnungsgemäß konfigurierter Datenbankcluster verhindern, dass ein einzelner Hardwareausfall den Zugriff vollständig lahmlegt. Für Organisationen, die vollständig isolierte oder Air-Gapped-Netzwerke betreiben, bestätigen Sie, dass das Deployment ohne ausgehende Internetverbindung dauerhaft funktioniert; ein Offline-Installer allein garantiert das nicht.

Wie Passwork diese sechs Säulen angeht

Dieses Framework gilt für jeden Anbieter, einschließlich Passwork. Passwork ist ein Self-Hosted Zero-Knowledge Passwort- und Secrets-Manager, entwickelt für Enterprise- und DevOps-Teams. So beantwortet es jede der sechs oben genannten Säulen, mit Links zur gleichen Dokumentation, die ein externer Prüfer anfordern würde.

Verschlüsselungsarchitektur: Passwork verwendet ein Zero-Knowledge, clientseitiges Verschlüsselungsmodell. Schlüssel werden auf dem Client generiert und verwendet. Der Server speichert nur Chiffretext und verschlüsseltes Schlüsselmaterial, das zusätzlich mit einer unabhängigen serverseitigen AES-256-Schicht verschlüsselt ist. Master-Schlüssel werden durch PBKDF2 mit hoher Iterationszahl abgeleitet, und Tresor- und Datensatzdaten verwenden AES-256 mit eindeutigen Schlüsseln pro Tresor und pro Datensatz, nicht einem organisationsweiten Schlüssel.
Authentifizierung und Zugriffssteuerung: Passwork unterstützt TOTP, WebAuthn/Passkeys, biometrische Entsperrung, SAML SSO und LDAP/AD-Synchronisierung, zusammen mit konfigurierbaren Sitzungs-Timeouts und Fehlversuchs-Sperrschwellen. RBAC läuft über unbegrenzte benutzerdefinierte Rollen und Gruppen, mit AD-Gruppenabbildung, sodass Verzeichnisänderungen automatisch in den Tresor-Zugriff einfließen, anstatt auf ein Ticket zu warten. Tresortyp-Richtlinien binden Unternehmensadministratoren an eine Tresor-Kategorie selbst, nicht an denjenigen, der ihn zufällig erstellt hat, und schließen die Lücke durch Rogue-Personal-Tresore, die Zugriff auf Rollenebene allein übersieht.
Audit-Logging und unabhängige Verifizierung: Jede Tresor-, Ordner-, Passwort- und Admin-Aktion landet in einem exportierbaren Aktivitätsprotokoll, filterbar nach Benutzer, Datum und Aktionstyp, und kann direkt in ein SIEM eingespeist werden. Passwork ist ISO 27001 zertifiziert und unterzieht sich jährlichen externen Penetrationstests durch HackerOne; Passworks eigene Audit- und Zertifizierungsunterlagen sind die gleiche Art von Dokumentation, die dieses Framework von jedem Anbieter verlangt, keine Aussage, der man blind vertrauen muss.
Compliance-Ausrichtung: Passworks Self-Hosted-Deployment hält Daten auf der Kundeninfrastruktur, was Datenhaltungsanforderungen unter DSGVO und Branchenvorschriften vereinfacht, und sein richtliniengebundenes RBAC plus exportierbare Audit-Logs entsprechen den Risikomanagementmaßnahmen von NIS2 Artikel 21(2) und den ISO/IEC 27001 Anhang A-Kontrollen zu Zugriffsmanagement und Protokollierung.
Betriebliche Resilienz: Da Passwork auf der eigenen Infrastruktur des Kunden läuft, einschließlich Air-Gapped-Netzwerken, bleiben Verfügbarkeit und Backup-Strategie unter der Kontrolle des Kunden statt der Cloud-Vorfall-Timeline eines Anbieters. Der sichere Offline-Modus ermöglicht es Benutzern, speziell markierte Datensätze ohne Live-Verbindung anzuzeigen, schreibgeschützt, mit automatischem Cache-Ablauf und vollständiger Aktivitätsprotokoll-Synchronisierung bei Wiederverbindung.

Fazit

Keine der sechs oben genannten Säulen ist exotisch. Sie sind die spezifischen Dokumente, Fragen und Tests, die die Sicherheitsseite eines Anbieters von einer Aussage in etwas verwandeln, das Sie tatsächlich überprüft haben: wo die Schlüssel liegen, wie sich MFA und Sitzungen wirklich verhalten, ob Offboarding geteilte Anmeldedaten erreicht und ob ein ISO 27001-Zertifikat aktuell ist statt angestrebt.

Wählen Sie die Säule, bei der die Antwort Ihres aktuellen Anbieters am schwächsten ist, und beginnen Sie dort Ihr nächstes Verlängerungsgespräch.

Wenn Sie einen Passwort-Manager evaluieren oder den vorhandenen auditieren, testen Sie Passwork kostenlos und wenden Sie dieses Framework auf einen Zero-Knowledge Self-Hosted Tresor an, der darauf ausgelegt ist, jede dieser Fragen mit Nachweisen zu beantworten.

Häufig gestellte Fragen

Was ist der Unterschied zwischen „verschlüsselt" und „Zero-Knowledge" bei einem Passwort-Manager?

Verschlüsselung im Ruhezustand bedeutet nur, dass Daten auf den Servern des Anbieters verschlüsselt sind; der Anbieter kann dennoch die Schlüssel besitzen. Zero-Knowledge bedeutet, dass der Anbieter niemals den Klartext oder die Schlüssel zur Entschlüsselung hat. Nur der clientseitige Schlüssel des Benutzers kann den Tresor entsperren, selbst wenn die Infrastruktur des Anbieters vollständig kompromittiert wird.

Muss ein Passwort-Manager Passkeys unterstützen, um als sicher zu gelten?

Nicht zwingend, aber Passkey- und FIDO2-Unterstützung signalisiert, dass der Anbieter mit aktuellen Authentifizierungsstandards Schritt hält. MFA, idealerweise nicht nur SMS, ist die nicht verhandelbare Grundlage. Passkeys werden zunehmend darüber hinaus erwartet, insbesondere für phishing-resistente Anmeldung am Tresor selbst.

Was passiert mit der Sicherheit des Passwort-Managers, wenn der Cloud-Dienst des Anbieters ausfällt?

Wenn der Anbieter nur Online-Zugriff unterstützt, kann ein Ausfall Sie von allen Anmeldedaten aussperren, bis der Dienst wiederhergestellt ist. Achten Sie auf einen dokumentierten Offline- oder schreibgeschützten lokalen Modus, einen getesteten Backup- und Wiederherstellungsprozess und eine Deployment-Option — Self-Hosted oder Hybrid — die Sie die Kontrolle behält, falls die Infrastruktur des Anbieters ausfällt.

Wie oft sollten die Sicherheitszertifizierungen eines Passwort-Managers erneut verifiziert werden?

Zertifizierungen wie ISO/IEC 27001 werden typischerweise jährlich erneuert. Fordern Sie das Ausstellungs- und Ablaufdatum des aktuellen Zertifikats an, anstatt anzunehmen, dass ein auf der Website eines Anbieters erwähntes Badge noch gültig ist; ein abgelaufenes Zertifikat ist ohne direkte Prüfung leicht zu übersehen.

Was verlangt DSGVO oder NIS2 tatsächlich von der Architektur eines Passwort-Managers?

DSGVO Artikel 32(1)(a)-(b) verlangt „die Pseudonymisierung und Verschlüsselung personenbezogener Daten" und die Fähigkeit, die fortlaufende Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit von Verarbeitungssystemen sicherzustellen. NIS2 Artikel 21(2)(h) und (j) verlangen dokumentierte Kryptografie-Richtlinien und Multi-Faktor- oder kontinuierliche Authentifizierung. Bitten Sie einen Anbieter, seine Architektur diesen spezifischen Klauseln zuzuordnen, nicht mit einem allgemeinen „ja, wir sind konform" zu antworten.

Ist ein Self-Hosted Passwort-Manager sicherer als ein Cloud-gehosteter?

Nicht automatisch, aber es ändert, wer Verfügbarkeit, Datenhaltung und Vorfallreaktion kontrolliert. Ein Cloud-gehosteter Anbieter hält die Infrastruktur selbst unter einem Zero-Knowledge-Design, sodass ein Ausfall oder eine Sicherheitsverletzung auf deren Seite Sie direkt betrifft. Self-Hosted- und Hybrid-Deployment halten die Infrastruktur und den physischen Standort der Daten in den Händen des Kunden, was am wichtigsten für regulierte, Air-Gapped- oder datenhaltungssensible Umgebungen ist.

Sicherheitsfunktionen von Passwortmanagern: So bewerten Sie sie