Datensouveränität und Passwortverwaltung: Volle Kontrolle

Datensouveränität und Passwortverwaltung: Anmeldedaten dort behalten, wo sie hingehören

Datensouveränität ist die Fähigkeit, physisch, rechtlich und kryptografisch zu bestimmen, wer auf bestimmte Daten zugreifen kann und unter welcher Gerichtsbarkeit. Ein Unternehmen kann auf dem Papier vollständig DSGVO-konform sein und dennoch keine echte Kontrolle darüber haben, wo seine Passwörter gespeichert sind. Bei Unternehmens-Zugangsdaten ist diese Lücke zwischen „konform" und „unter Kontrolle" der Punkt, an dem Sicherheitsverletzungen, behördliche Anfragen und fehlgeschlagene Audits ihren Ursprung haben.

Die Datenschutz-Grundverordnung (DSGVO) setzt die Grundlage, die die meisten Organisationen zur Beurteilung ihrer Datenpraktiken heranziehen: Sie regelt, wie personenbezogene Daten erhoben, gespeichert und übertragen werden. Gemäß Artikel 3 erstreckt sich ihr räumlicher Anwendungsbereich auf jedes Unternehmen, das Daten von EU-Bürgern verarbeitet — unabhängig davon, wo dieses Unternehmen seinen Hauptsitz hat.

Passwörter und Geheimnisse sind keine gewöhnlichen Daten, weshalb die Passwortverwaltung ein eigenes Souveränitätsmodell benötigt, das von der allgemeinen Dateispeicherung getrennt ist. Sie öffnen den Zugang zu allem anderen, werden ständig zwischen Mitarbeitern weitergegeben und durchlaufen selten die Data Loss Prevention (DLP)- oder Klassifizierungstools, die Verträge und Kundendaten überwachen. Zugangsdaten, die auf dem falschen Server, im falschen Land und unter fremden Verschlüsselungsschlüsseln gespeichert sind, stellen eine Haftung dar, die die meisten Compliance-Checklisten nicht erfassen.

Dieser Artikel erläutert, was Souveränität auf drei Ebenen bedeutet: physischer Standort, Verschlüsselung und Zugriffsgovernance. Er vergleicht On-Premise-, Air-Gapped- und EU-Cloud-Modelle und zeigt, wo ein selbstgehosteter Zero-Knowledge-Passwortmanager wie Passwork in diese Entscheidung passt.

Wichtigste Erkenntnisse

Souveränität erfordert drei Kontrollen: Standort, Verschlüsselung und Zugriffsgovernance. Eine Lücke in einer Komponente untergräbt die anderen.
Zugangsdaten benötigen ein eigenes Sicherheitsmodell. Sie sind hochwertig, bewegen sich ständig und entgehen Standard-DLP-Tools.
DSGVO-Konformität adressiert nicht, wer die Verschlüsselungsschlüssel hält. Ein konformer Anbieter kann dennoch über Unterauftragsverarbeiter oder rechtliche Anfragen auf Kundendaten zugreifen.
Zero-Knowledge-Architektur bestimmt, ob Cloud-Verschlüsselung Sie tatsächlich schützt. Wenn der Anbieter die Schlüssel hält, spielt der Serverstandort eine geringere Rolle.
On-Premise- und Air-Gapped-Bereitstellung maximieren die Kontrolle, erhöhen aber den Betriebsaufwand. Patching, Backups und Verfügbarkeit werden zur Verantwortung Ihres Teams.
EU-Cloud-Hosting schließt die Souveränitätslücke nur mit clientseitiger Verschlüsselung. Datenresidenz deckt die Gerichtsbarkeit ab; Verschlüsselung bestimmt, wer die Schlüssel hält.
Souveränitätsaussagen von Anbietern benötigen Verifizierung durch Dritte. ISO/IEC 27001, NIS2-Bereitschaft und öffentliche Penetrationstests bieten dem Einkauf einen Ausgangspunkt.
Die Wahl des Bereitstellungsmodells hängt von vier Faktoren ab: Air-Gap-Anforderungen, EU-Hosting-Anforderungen, Teamgröße und Self-Hosting-Richtlinien. Unterschiedliche Workflows können unterschiedliche Modelle nutzen.

Was Datensouveränität für Zugangsdaten wirklich bedeutet

Datensouveränität ist die Kombination aus drei separaten Kontrollen: wo sich Daten physisch befinden, wer die Verschlüsselungsschlüssel hält und wer den Zugriff darauf regelt. Der Verlust einer dieser drei Komponenten bricht die Souveränität, selbst wenn die anderen beiden solide sind. Die meisten Anbieter bewerben nur die erste.

Physischer Standort beantwortet, wo sich die Server befinden. Ein in Frankfurt gehosteter Passwortmanager unterliegt weiterhin dem räumlichen Anwendungsbereich der DSGVO — aber das gilt auch für einen in Virginia gehosteten, wenn er Daten von EU-Bürgern verarbeitet. Der Standort ist relevant für die Gerichtsbarkeit, nicht automatisch für die rechtliche Gefährdung.
Verschlüsselungskontrolle beantwortet, wer die Daten entschlüsseln kann. Wenn der Anbieter die Schlüssel hält, können behördliche Anfragen, Insider oder ein Sicherheitsvorfall in der Infrastruktur des Anbieters Ihre Zugangsdaten offenlegen — unabhängig vom Serverstandort.
Zugriffsgovernance beantwortet, wer innerhalb Ihrer Organisation was sehen kann. Rollenbasierte Zugriffskontrolle (RBAC) und Audit-Logs bestimmen, ob der Zugriff eines ausscheidenden Mitarbeiters innerhalb von Minuten widerrufen oder erst sechs Monate später entdeckt wird.

Echte Datensouveränität erfordert alle drei Elemente. Das Weglassen einer Komponente reduziert die Architektur auf eine formale Compliance-Checkliste.

Warum Zugangsdaten eine eigene Datenklasse sind

Zugangsdaten verdienen eine separate Behandlung, weil sie hochwertig, weit verbreitet und für Standard-Data-Governance-Tools weitgehend unsichtbar sind. Ein geleakter Kundendatensatz legt einen Datensatz offen. Ein geleaktes Admin-Passwort legt jedes System offen, auf das dieser Admin zugreifen kann — und es funktioniert weiter, bis jemand es rotiert.

Der Data Breach Investigations Report 2026 von Verizon ergab, dass gestohlene Zugangsdaten 13 % der initialen Zugriffsvektoren ausmachten. Diese Zahl verdreifachte sich jedoch (39 %) über den gesamten Verlauf der Sicherheitsverletzung. Passwörter bewegen sich auch ständig: Sie werden beim Onboarding geteilt, in Tickets kopiert, in Chat-Threads eingefügt und weitergeleitet, wenn ein Projekt den Besitzer wechselt. DLP-Tools, die für das Erkennen von Dokumenten-Exfiltration entwickelt wurden, erfassen selten ein Passwort, das in einer Slack-Nachricht gepostet wird.

Diese Kombination aus hoher Auswirkung und geringer Sichtbarkeit ist der Grund, warum die Speicherung von Zugangsdaten ein eigenes Souveränitätsmodell benötigt, anstatt die Richtlinien für allgemeine Dateispeicherung zu übernehmen.

Tauchen Sie tiefer in die Zahlen ein

Für eine vollständige Aufschlüsselung des Verizon 2026 DBIR (einschließlich Angriffsvektoren, Ransomware-Trends und Drittanbieter-Risiken) lesen Sie unsere Analyse des Berichts.

Wo Standard-Cloud-Speicherung rechtliche Reibungspunkte verursacht

Standard-Cloud-Passwortmanager verursachen rechtliche Gefährdung durch Unterauftragsverarbeiter-Ketten, grenzüberschreitende Datenübertragungen und Zugriff durch Anbieter-Mitarbeiter — selbst wenn der Anbieter vollständig DSGVO-konform ist. Verschlüsselung im Ruhezustand beseitigt diese Risiken nicht, wenn der Anbieter und nicht der Kunde die Entschlüsselungsschlüssel hält.

Drei spezifische Reibungspunkte treten bei Beschaffungsprüfungen wiederholt auf:

Unterauftragsverarbeiter. Die meisten Cloud-Anbieter nutzen unterbeauftragte Infrastruktur-, Monitoring- oder Support-Anbieter. Jeder Unterauftragsverarbeiter ist eine separate Einheit mit eigener Zugriffsoberfläche. Artikel 28(2) der DSGVO verlangt, dass der Auftragsverarbeiter ohne vorherige gesonderte oder allgemeine schriftliche Genehmigung des Verantwortlichen keinen weiteren Auftragsverarbeiter (Unterauftragsverarbeiter) hinzuziehen darf.
Drittstaaten-Übermittlungen. Kapitel V der DSGVO regelt die Übermittlung personenbezogener Daten außerhalb der EU/des EWR. Artikel 44 legt den Grundsatz fest, dass jede Übermittlung das durch die Verordnung garantierte Schutzniveau nicht untergraben darf. Artikel 46 verlangt geeignete Garantien, wie Standardvertragsklauseln, wenn kein Angemessenheitsbeschluss vorliegt. Zugangsdaten-Tresore, die in einem Drittland gehostet oder zu Backup-Zwecken dorthin repliziert werden, fallen direkt unter dieses Kapitel.
Anbieter-Mitarbeiterzugriff und rechtliche Anfragen. Wenn der Anbieter technisch in der Lage ist, Kundendaten zu entschlüsseln, unterliegen diese Daten rechtlichen Verfahren in der Gerichtsbarkeit des Anbieters. Eine Vorladung, ein Durchsuchungsbeschluss oder eine ausländische Offenlegungsanordnung kann den Zugriff erzwingen — unabhängig davon, wo Ihr Unternehmen registriert ist.

NIS2 fügt einen vierten Aspekt hinzu: Artikel 21(2)(d) verlangt von wesentlichen und wichtigen Einrichtungen, die Sicherheit der Lieferkette zu bewerten — einschließlich der Anbieter und Tools, die sie zur Verwaltung von Zugangsdaten verwenden. Ein Passwort-Tresor, der bei einem nicht geprüften Drittanbieter-Unterauftragsverarbeiter liegt, fällt genau unter diese Anforderung.

Nichts davon macht Cloud-Speicherung per se nicht-konform. Es bedeutet, dass „DSGVO-konform" eine notwendige, aber keine hinreichende Bedingung für die Souveränität über Zugangsdaten ist.

Ein konkretes Beispiel: Jurisdiktionelle Gefährdung

Ein Cloud-Passwortmanager, der in US-Rechenzentren gehostet wird, unterliegt amerikanischer Gesetzgebung. Gemäß dem CLOUD Act können US-Strafverfolgungsbehörden Dienstanbieter zur Herausgabe von Kundendaten zwingen. Darüber hinaus erlaubt FISA Section 702 Geheimdiensten, Daten von US-basierten Dienstanbietern anzufordern. Wenn der Anbieter die Entschlüsselungsschlüssel kontrolliert, muss er diesen bundesstaatlichen Anordnungen Folge leisten. Die EU-Registrierung oder interne Sicherheitsrichtlinien des Kunden können diese rechtliche Verpflichtung nicht außer Kraft setzen.

Die drei Ebenen auf Bereitstellungsmodelle abbilden

Eine Lücke in einer einzelnen Ebene öffnet erneut die Gefährdung, die die anderen beiden schließen sollten. Die folgende Tabelle wendet die drei Kontrollen aus dem ersten Abschnitt — Standort, Entschlüsselung und Zugriff — auf die Modelle an, zwischen denen Organisationen tatsächlich wählen.

Ebene	On-Premise	Air-Gapped	EU-Cloud-Region
Wo sich Daten befinden	Eigene Infrastruktur des Kunden	Isoliertes Netzwerk, kein Internetpfad	EU-basiertes Rechenzentrum des Anbieters
Wer entschlüsseln kann	Nur der Kunde, Zero-Knowledge-Architektur	Nur der Kunde, Zero-Knowledge-Architektur, keine externe Konnektivität	Hängt vom Verschlüsselungsmodell ab; nur mit clientseitiger Verschlüsselung sicher
Wer den Zugriff regelt	RBAC und Audit-Logs des Kunden	RBAC des Kunden, manuell gepflegt	RBAC des Kunden, Anbieter verwaltet die Infrastrukturebene

Air-Gapped beschreibt Infrastruktur ohne jeglichen Netzwerkpfad zum Internet — die strengste Form der physischen Isolation.
Zero-Knowledge bedeutet, dass der Anbieter Ihre Daten unter keinen Umständen lesen kann.
Clientseitige Verschlüsselung ist der Mechanismus, der diese Garantie erzeugt: Verschlüsselung und Entschlüsselung erfolgen auf dem Gerät des Benutzers unter Verwendung eines Masterpassworts, das der Anbieter niemals erhält oder speichert. Der Server hält und überträgt somit nur Chiffretext.

Ein schlecht implementiertes clientseitiges Verschlüsselungsschema — eines mit einem wiederherstellbaren Masterpasswort oder einer schwachen Schlüsselableitungsfunktion — liefert nicht automatisch eine echte Zero-Knowledge-Garantie. Diese Unterscheidung bestimmt, ob „in der Cloud verschlüsselt" tatsächlich etwas für die Souveränität bedeutet.

On-Premise und Air-Gapped: Vollständige Isolation auf Kosten des Betriebsaufwands

On-Premise-Bereitstellung gibt einer Organisation die vollständige physische und kryptografische Kontrolle über ihren Zugangsdaten-Tresor, da die Daten niemals die Infrastruktur verlassen, die die Organisation besitzt und verwaltet. Air-Gapping geht einen Schritt weiter: Die Infrastruktur hat überhaupt keinen Netzwerkpfad zum Internet — das einzige Setup, das externe Netzwerkabhängigkeit vollständig beseitigt.

Isolation vom Anbieter: Zero-Knowledge-Verschlüsselung

Passwork läuft vollständig innerhalb des Unternehmensperimeters, auf Infrastruktur, die die Organisation von Anfang bis Ende kontrolliert. Der Passwort- und Geheimnismanager verschlüsselt und entschlüsselt Daten vollständig auf der Clientseite unter Verwendung eines Schlüssels, der vom Masterpasswort des Benutzers abgeleitet wird. Der Server erhält oder speichert zu keinem Zeitpunkt Klartext — er hält nur verschlüsselte Blobs und verfügt über keinen Schlüssel, der sie entschlüsseln könnte. Für Organisationen mit Air-Gap-Anforderungen und strengen Segmentierungsrichtlinien ist dies oft die einzige Architektur, die interne Sicherheitsrichtlinien erfüllt.

Eine solche Behauptung sollte nicht auf Vertrauen basieren. Der Quellcode von Passwork ist für das eigene Sicherheitsteam der Organisation zur direkten Prüfung verfügbar — Zeile für Zeile — anstatt sich auf die Beschreibung des Anbieters zu verlassen, wie die Verschlüsselung implementiert ist.

Der operative Kompromiss

Dieses Maß an Isolation hat seinen Preis — bezahlt in operativem Aufwand. On-Premise verlagert Serverwartung, Patching, Backup-Management und Verfügbarkeitsverantwortung vom Anbieter auf Ihr eigenes IT-Team. Jemand muss Updates einspielen, Speicherplatz überwachen, TLS-Zertifikate verwalten und Disaster Recovery handhaben. Für ein kleines IT-Team, das bereits mit anderen Prioritäten ausgelastet ist, sind das echte Kosten. Organisationen, die Self-Hosting wählen, benötigen entweder eine dedizierte Systemadministrator-Ressource oder einen verwalteten internen Prozess, um die Bereitstellung aktuell zu halten.

Die Zero-Knowledge-Verschlüsselung von Passwork hält Ihre Daten für alle außer Ihren eigenen Benutzern unlesbar. Prüfen Sie die Architektur in den Benutzerhandbüchern, bevor Sie Infrastruktur bereitstellen, oder testen Sie die vollständige Bereitstellung kostenlos, um sie auf Ihren eigenen Servern laufen zu sehen.

EU-Cloud-Hosting: Tragfähig, aber nur mit clientseitiger Verschlüsselung

EU-Cloud-Hosting kann jurisdiktionelle Anforderungen für kleinere Teams ohne dediziertes Infrastrukturpersonal erfüllen — aber nur, wenn der Anbieter obligatorische clientseitige Verschlüsselung (CSE) implementiert. Ohne CSE lässt ein EU-gehosteter Tresor den Anbieter weiterhin in der Lage, Kundendaten zu entschlüsseln, was dieselbe Gefährdung wieder öffnet, die das Hosting in der EU schließen sollte.

Bei einem ordnungsgemäßen CSE-Modell verlässt das Masterpasswort niemals das Gerät des Benutzers, und die Server des Anbieters verarbeiten und speichern nur Chiffretext. Selbst mit vollem physischen Zugriff auf den Server kann der Anbieter den Inhalt des Tresors nicht lesen. Dies ist eine wesentlich andere Garantie als „unsere Rechenzentren befinden sich in der EU", was die Gerichtsbarkeit adressiert, aber nichts darüber aussagt, wer die Schlüssel hält.

EU-Cloud-Hosting mit CSE verringert die rechtliche Gefährdung und erfüllt Datenresidenz-Anforderungen für viele Compliance-Frameworks, aber es ist nicht dieselbe Garantie wie vollständige On-Premise-Souveränität. Die Infrastruktur, Netzwerkschicht und physische Hardware bleiben außerhalb der direkten Kontrolle des Kunden. Für Organisationen mit Air-Gap-Vorgaben oder strengen Self-Hosting-Richtlinien ist EU-Cloud kein Ersatz — unabhängig von der Verschlüsselungsstärke.

On-Premise ohne Zero-Knowledge vertraut lokalen Administratoren dennoch Klartextzugriff an. EU-Cloud ohne Zero-Knowledge vertraut dem Infrastrukturpersonal des Anbieters. In beiden Fällen gilt die Garantie nur, wenn das Masterpasswort niemals das Gerät des Benutzers verlässt.

Anbieteraussagen überprüfen: Was der Einkauf prüfen sollte

Souveränitätsaussagen sind nur so glaubwürdig wie die Nachweise Dritter dahinter. Diese Prüfung gilt unabhängig davon, welches Bereitstellungsmodell Sie wählen: Ein Zertifikat sagt Ihnen nicht, wo sich Daten befinden, aber es sagt Ihnen, ob die anderen Aussagen eines Anbieters standhalten. Einkaufsteams sollten eine Self-Hosting-Entscheidung auf interne Admin-Kapazitäten und Richtlinienanforderungen stützen und dann den in die engere Wahl gezogenen Anbieter durch unabhängige Zertifizierung, eigene Prüfung und öffentliche Sicherheitstests validieren.

Vier Prüfungen sind in der Praxis relevant:

ISO/IEC 27001-Zertifizierung bestätigt, dass ein Informationssicherheits-Managementsystem unabhängig nach dem internationalen Standard geprüft wurde. Passwork besitzt die ISO/IEC 27001:2022-Zertifizierung, ausgestellt von MSECB und überprüfbar über die IAF CertSearch-Datenbank.
NIS2- und DSGVO-Bereitschaft ist relevant für jede Organisation, die unter den Geltungsbereich einer der beiden Verordnungen fällt. Die Lieferketten-Anforderungen in Artikel 21 von NIS2 erstrecken sich auf die Tools, die wesentliche und wichtige Einrichtungen zur Verwaltung von Zugangsdaten verwenden, während Artikel 32 der DSGVO „geeignete technische und organisatorische Maßnahmen", einschließlich Verschlüsselung, für jedes System verlangt, das personenbezogene Daten verarbeitet. Organisationen, die Anbieter gegen diese Anforderungen bewerten, können den Ansatz von Passwork zur NIS2-Compliance als einen Referenzpunkt heranziehen.
Quellcode-Prüfrechte bestätigen, dass eine Zero-Knowledge-Behauptung tatsächlich wahr ist und keine Marketing-Sprache. Bei einem echten Zero-Knowledge-Design kann der Anbieter unter keinen Umständen das Masterpasswort eines einzelnen Benutzers wiederherstellen — nicht durch einen Backend-Reset, nicht durch ein Support-Ticket, nicht unter rechtlichem Druck. Wenn ein Benutzer es vergisst, sind die dahinter liegenden Daten absichtlich verloren, weil der Anbieter den Schlüssel nie besessen hat. Passwork öffnet seinen Quellcode für die eigenen Sicherheitsteams der Kunden genau aus diesem Grund: Es ist der Weg zu bestätigen, dass die Verschlüsselungsimplementierung der vom Anbieter beschriebenen Architektur entspricht.
Öffentliche Penetrationstests liefern Nachweise über die selbst gemeldete Sicherheitslage hinaus. Passwork hat einen unabhängigen Penetrationstest über HackerOne abgeschlossen, der sichere Datenverarbeitung, die OWASP Top 10 und SANS Top 25, Authentifizierung und API-Zugriffskontrolle abdeckt.

Ein Bereitstellungsmodell wählen: Ein Entscheidungsrahmen

Das richtige Bereitstellungsmodell hängt von fünf praktischen Faktoren ab:

Air-Gap-Anforderungen
Obligatorisches EU-Hosting
Größe des Admin-Teams
Interne Self-Hosting-Richtlinie
Anforderungen an die Infrastrukturkontrolle

Das Abgleichen dieser Faktoren mit den Bereitstellungsoptionen vermeidet den häufigen Fehler, allein auf Basis von Preis oder Markenbekanntheit zu wählen. Verwenden Sie diese Entscheidungsmatrix für die Datenresidenz von Zugangsdaten, um organisatorische Einschränkungen einem Bereitstellungsmodell zuzuordnen:

Anforderung	Empfohlenes Modell
Air-Gap-Vorgabe (ICS, klassifizierte Umgebungen)	On-Premise, vollständig isoliertes Netzwerk
Obligatorische EU-Datenresidenz, keine Air-Gap-Anforderung	On-Premise oder EU-Cloud mit clientseitiger Verschlüsselung (Wahl hängt von Anforderungen an die Infrastrukturkontrolle ab)
Kleines IT-/Admin-Team, begrenzte Infrastrukturkapazität	EU-Cloud mit clientseitiger Verschlüsselung
Strenge interne Self-Hosting-Richtlinie (regulatorisch oder vertraglich)	On-Premise, vom Kunden verwaltete Infrastruktur

Keine dieser Zeilen schließt sich in der Praxis gegenseitig aus. Ein Finanzinstitut könnte On-Premise für seinen Kern-Tresor betreiben und gleichzeitig Cloud-basierte Tools für Workflows mit geringerer Sensibilität akzeptieren. Die Matrix ist ein Ausgangspunkt für das Gespräch mit Sicherheits- und Compliance-Stakeholdern.

Wie die Architektur von Passwork auf diese Ebenen abgebildet wird

Die selbstgehostete Bereitstellung von Passwork adressiert die in diesem Artikel beschriebene Souveränitätslücke, indem sie physische Isolation, Zero-Knowledge-Verschlüsselung und vom Kunden kontrollierte Zugriffsgovernance in einer Architektur vereint. Der Tresor wird auf Infrastruktur bereitgestellt, die der Kunde besitzt — ob auf einem einzelnen Linux-Server, einer Windows Server-Umgebung oder einem Docker-Container in einem Air-Gapped-Netzwerk.

Die Verschlüsselung verwendet AES-256 mit einem Zero-Knowledge-Design, was bedeutet, dass die Infrastruktur — selbst wenn sie kompromittiert würde — nur Chiffretext enthält. Der Zugriff wird durch rollenbasierte Berechtigungen und ein vollständiges Audit-Log geregelt, sodass Administratoren sehen können, wer wann auf welche Zugangsdaten zugegriffen hat, und den Zugriff sofort widerrufen können, wenn jemand die Rolle wechselt oder das Unternehmen verlässt. Die Integration mit AD/LDAP und SAML SSO ermöglicht es, die Zugriffsgovernance an die bestehende Identitätsinfrastruktur anzubinden, anstatt als separates Silo zu laufen.

Dies ist bewusst keine Behauptung, dass Self-Hosting für jeden geeignet ist. Organisationen ohne Air-Gap-Anforderungen oder strenge Self-Hosting-Vorgaben können eine Cloud-Option mit ordnungsgemäßer clientseitiger Verschlüsselung als ausreichend erachten. Der Punkt ist, dass die Architektur strukturell dafür ausgelegt sein muss, wenn vollständige Souveränität die Anforderung ist.

Datensouveränität in der Passwortverwaltung: Wie Sie sie in Ihre Bewertung einbeziehen

Souveränität ist eine fortlaufende Abstimmung zwischen dem Ort, an dem sich Daten befinden, demjenigen, der die Schlüssel hält, und demjenigen, der den Zugriff regelt — und diese Abstimmung muss überprüft werden, wann immer sich Ihre Infrastruktur, Anbieterverträge oder der regulatorische Geltungsbereich ändern.

Beginnen Sie damit, Ihre eigene Organisation anhand der vier Faktoren in der Entscheidungsmatrix zu bewerten: Air-Gap-Anforderung, obligatorisches EU-Hosting, Größe des Admin-Teams und interne Self-Hosting-Richtlinie. Diese Zuordnung wird Ihnen mehr über das richtige Bereitstellungsmodell sagen als jede Marketingseite eines Anbieters.

Der einzige Weg zu bestätigen, dass eine selbstgehostete Architektur zu Ihrer Infrastruktur passt, ist sie dort auszuführen. Passwork bietet eine kostenlose Testversion, die Sie auf Ihren eigenen Servern bereitstellen können — mit vollem Funktionsumfang und ohne dass Daten jemals Ihre Umgebung verlassen.

Häufig gestellte Fragen

Was ist Datensouveränität im Kontext der Passwortverwaltung?

Datensouveränität in der Passwortverwaltung bedeutet, dass die Organisation — nicht ein Drittanbieter — kontrolliert, wo sich Zugangsdaten physisch befinden, wer die Verschlüsselungsschlüssel hält und wer darauf zugreifen kann. DSGVO-Konformität allein garantiert keine Souveränität, wenn der Anbieter die Daten technisch entschlüsseln kann oder der Gerichtsbarkeit eines fremden Landes unterliegt.

Reicht DSGVO-Konformität aus, um die Souveränität über Zugangsdaten zu garantieren?

Nein. DSGVO-Konformität adressiert allgemeine Datenverarbeitungspflichten, und Kapitel V regelt speziell grenzüberschreitende Übermittlungen — aber keines von beiden adressiert, wer die Verschlüsselungsschlüssel hält. Ein DSGVO-konformer Anbieter kann Kundendaten technisch dennoch entschlüsseln, es sei denn, die Architektur verwendet Zero-Knowledge- oder clientseitige Verschlüsselung.

Was ist der Unterschied zwischen On-Premise- und Air-Gapped-Bereitstellung?

On-Premise bedeutet, dass die Software auf Infrastruktur läuft, die die Organisation besitzt und die möglicherweise noch Internetkonnektivität hat. Air-Gapped bedeutet, dass diese Infrastruktur überhaupt keinen Netzwerkpfad zum Internet hat. Air-Gapping ist eine strengere Untermenge von On-Premise, die typischerweise in Verteidigungs-, Industriesteuerungs- oder klassifizierten Umgebungen erforderlich ist.

Erfüllt EU-Cloud-Hosting die Anforderungen an Datensouveränität?

EU-Cloud-Hosting erfüllt jurisdiktionelle und Datenresidenz-Anforderungen nur in Kombination mit clientseitiger Verschlüsselung, bei der der Anbieter niemals Entschlüsselungsschlüssel hält. Ohne diese adressiert EU-Hosting den Standort, aber nicht, wer auf die Daten zugreifen kann — was eine bedeutsame Souveränitätslücke für Organisationen mit strengen Anforderungen hinterlässt.

Wovor schützt Zero-Knowledge-Architektur tatsächlich?

Zero-Knowledge-Architektur schützt vor serverseitiger Kompromittierung, Insider-Zugriff beim Anbieter und rechtlichen Datenanfragen — weil der Server immer nur verschlüsselten Chiffretext speichert. Das Masterpasswort verbleibt auf dem Gerät des Benutzers und wird niemals an die Infrastruktur des Anbieters übertragen oder dort gespeichert.

Wie beeinflusst NIS2 die Auswahl von Passwortmanager-Anbietern?

NIS2 Artikel 21(2)(d) verlangt von wesentlichen und wichtigen Einrichtungen, das Sicherheitsrisiko der Lieferkette zu managen — was sich auf Anbieter erstreckt, die Zugangsdaten verarbeiten. Organisationen im Geltungsbereich von NIS2 sollten die Zertifizierungen und Sicherheitstests von Passwortmanager-Anbietern als Teil ihrer eigenen Compliance-Verpflichtungen bewerten.