Den Passwortmanager selbst hosten oder nicht?

Ein Passwortmanager hat Zugriff auf Bankgeschäfte, E-Mails, Gesundheitsakten, Kundensysteme und Finanzplattformen. Die Übergabe an einen Drittanbieter-Cloud-Anbieter bedeutet, dessen technische Entscheidungen, deren Vorfallreaktion, Preismodell und Geschäftskontinuität auf unbestimmte Zeit zu vertrauen.

Self-Hosting entfernt Vertrauen nicht aus der Gleichung. Sie vertrauen weiterhin dem Anbieter, der die Software entwickelt hat. Der Unterschied ist jedoch die Kontrolle: Sie entscheiden, wann gepatcht wird, wie konfiguriert wird und wo die Daten gespeichert werden. Bei einem SaaS-Anbieter haben Sie keine Einsicht, wie Ihre Daten intern gespeichert werden, kein Mitspracherecht, wann eine Schwachstelle gepatcht wird, und keine Kontrolle, falls der Anbieter übernommen wird, seine Bedingungen ändert oder selbst einen Sicherheitsvorfall hat.

Wenn Ihr Unternehmen die Infrastruktur betreibt, kann Ihr Sicherheitsteam zusätzliche Schutzschichten hinzufügen und die Bereitstellung an die eigenen Anforderungen anpassen, anstatt ein breit gefächertes, einheitliches SaaS-Angebot zu akzeptieren.

Passwortanbieter hatten bereits Sicherheitsvorfälle. Darauf zu setzen, dass ein Anbieter dauerhaft frei von Sicherheitsverletzungen bleibt, ist keine Sicherheitsstrategie. Es ist eine Hoffnung und die einzige Option, sobald Sie einen reinen SaaS-Anbieter gewählt haben.

Die Möglichkeit zum Self-Hosting ändert die Ausgangslage. Ihre Organisation entscheidet, wo die Daten gespeichert werden, nicht der Anbieter. Teams können es vollständig vor Ort betreiben, in ihrer eigenen Cloud-Umgebung bereitstellen oder eine hybride Lösung wählen, die zu ihrer bestehenden Infrastruktur passt.

Das Ziel ist nicht, Self-Hosting verpflichtend zu machen, sondern sicherzustellen, dass die Wahl bei Ihnen bleibt – etwas, das ein Anbieter, der nur einen gehosteten SaaS-Vault anbietet, nicht leisten kann.

Dateibasierte Tresore vs. zentralisierte Server

Fragt man lange genug, findet man zwei Lager.

1. Ein lokales, dateibasiertes Vault, über Geräte synchronisiert, vollständig unter Ihrer Kontrolle, kein Server zur Wartung erforderlich.
2. Betreiben Sie einen echten Server: ein zentralisiertes Vault, das Multi-User-Zugriff, Freigaben und Synchronisationskonflikte für Sie verwaltet.

Beide Seiten haben Recht, da es bei der Meinungsverschiedenheit um Kompromisse und nicht um richtig oder falsch geht. Eine lokale Datei ist portabel und transparent, sodass Sie sie öffnen, prüfen, verschieben oder sichern können, wie Sie möchten. Sobald jedoch mehr als eine Person Zugriff auf dasselbe Geheimnis benötigt, stößt dieser Ansatz an seine Grenzen, da Bearbeitungskonflikte zu manuellen Zusammenführungen werden. Das Teilen einer einzigen Anmeldeinformation mit einem Teammitglied bedeutet, eine ganze Datei oder das Hauptpasswort weiterzugeben, was ihnen vollen Zugriff auf alles gibt, statt nur auf das, was sie brauchen. Ein zentrales System löst das Multi-User-Problem, aber nur, wenn es tatsächlich für mehrere Benutzer mit unterschiedlichen Vertrauensstufen gebaut ist. Ein gemeinsamer Login für ein Team ist kein Multi-User-Zugriff. Es ist nur ein größeres Geheimnis mit mehr Leuten, die es weitergeben können.

Passwortmanager vs. Identity-Anbieter

Ein Tresor speichert Geheimnisse. Ein Identity Provider regelt, wer sich überhaupt bei welchen Systemen authentifizieren darf, oft wird durch Single Sign-On sogar ganz auf Passwörter verzichtet. Ein Tresor ohne Verbindung zur Identitätsverwaltung an anderer Stelle wird zur eigenen Insel, losgelöst vom restlichen Zugriffsmanagement. Eine Identitätsschicht ohne Tresor benötigt dennoch einen Ort zur Speicherung von Anmeldedaten, Zertifikaten und Geheimnissen, die moderne Authentifizierung nicht unterstützen. Organisationen, die das richtig machen, betrachten Tresor und Identitätsschicht als verbundene Systeme, nicht als konkurrierende Optionen.

Was schiefgeht, wenn der Passwortmanager nicht für eine Organisation entwickelt wurde

Eine Organisation, die Hunderte oder Tausende von Geheimnissen verwaltet, verteilt auf Abteilungen, Auftragnehmer, Dienstkonten und administrative Anmeldeinformationen, die Produktionssysteme berühren. Wenn so viele Anmeldeinformationen ohne ein echtes System dahinter existieren, landen sie in gemeinsamen Dokumenten, gespeicherten Browserpasswörtern oder einem einzigen Login, das mehrere Personen auswendig kennen.

Keine dieser Methoden hat einen Eigentümer, eine Aufzeichnung darüber, wer wann was zugegriffen hat, oder einen Bereinigungsplan, wenn jemand geht. Ein scheidender Administrator könnte Zugang zu einem Dutzend gemeinsamer Konten hinterlassen, die niemand daran erinnert, zu rotieren, während ein Passwort eines gemeinsamen Dienstkontos in einem Skript leben könnte, das von drei verschiedenen Teams genutzt wird, ohne dass jemand genau weiß, wer es ändern darf. Wenn ein Prüfer fragt, wer im letzten Quartal auf ein privilegiertes Konto zugegriffen hat, ist die ehrliche Antwort oft Schweigen.

Letztlich handelt es sich um ein Governance-Versagen und nicht um ein Werkzeugversagen. Es passiert, wenn die Speicherung von Zugangsdaten als nachträglicher Gedanke behandelt wird, statt als ein System mit echter Eigentümerschaft.

Datenhoheit 

Datenhoheit erfordert, dass Organisationen die Verschlüsselungsschlüssel kontrollieren, anstatt sich auf einen Anbieter zu verlassen. So können Sie den genauen Datenstandort für Compliance-Prüfungen verifizieren, Wohnsitzerfordernisse erfüllen und das System persönlich inspizieren, statt sich auf öffentliche Anbietererklärungen zu verlassen.

Ihr Risikoprofil hängt vollständig von der Roadmap des Anbieters ab, wenn Sie SaaS verwenden. Ausfälle, Richtlinienaktualisierungen oder Sicherheitsverletzungen beim Anbieter werden zu einem Notfall für Ihre Organisation, ohne dass Sie Kontrolle darüber haben. Self-Hosting beseitigt diese Abhängigkeit durch On-Premises-Bereitstellung, private Cloud-Mandanten oder hybride Setups. So bleiben Verfügbarkeit, Patch-Zeitpläne und Incident Response unter Ihrer direkten Kontrolle.

Unternehmensberechtigungen

Eigentum zeigt, wo Daten gespeichert sind, aber Berechtigungen bestimmen, wer tatsächlich darauf zugreifen darf und unter welchen Regeln. Ein guter Workforce-Vault benötigt rollenbasierte Zugriffskontrolle, die widerspiegelt, wie Ihr Unternehmen wirklich arbeitet. Einzelpersonen erhalten ihren eigenen privaten Speicher, Teams arbeiten in gemeinsamen, auf ihre Arbeit zugeschnittenen Bereichen zusammen, und Ihre sensibelsten oder privilegierten Konten sind durch eine zusätzliche Schutzschicht gesichert.

Diese zusätzliche Ebene ist zugriffsbasierte Genehmigung. Anstatt dass ein privilegiertes Anmeldecredential für jeden offenliegt, der weiß, wo es zu finden ist, erfordert der Zugang eine Freigabe, bevor er gewährt wird, und jede Nutzung wird protokolliert. Dadurch wird der Zugriff auf privilegierte Konten von einem Ehrenkodex zu einem prüfbaren, kontrollierten Prozess – mit dem gleichen Überwachungsniveau, das Sie für Konten erwarten, die bei Missbrauch den größten Schaden anrichten können.

Ohne Verbindung zu Active Directory oder Entra ID driftet der Tresorzugang von der Identitätsverwaltung ab. Eine im Verzeichnis deaktivierte Person kann immer noch Zugriff auf den Tresor haben, den niemand entfernt hat. Die Verzeichnisintegration entfernt den Tresorzugang, wenn eine Person im Verzeichnis deaktiviert wird, wobei der Automatisierungsgrad vom gewählten Modus abhängt und Bequemlichkeit gegen die bestmögliche Sicherheitslage abwägt.

Bereitstellungsflexibilität macht die Wahl wirklich

Die Möglichkeit zum Self-Hosting ist nur dann relevant, wenn sie echte Flexibilität bietet. Die Infrastrukturentscheidung, ob vor Ort, in der Cloud oder hybrid, sollte den Compliance-Anforderungen und der bestehenden Umgebung der Organisation folgen, nicht dem Hosting-Modell eines Anbieters. Eine regulierte Branche mit strengen Anforderungen an den Datenstandort hat andere Bedürfnisse als ein Unternehmen, das den Großteil seiner Infrastruktur bereits in der Cloud betreibt.

Diese Eigentümerschaft erstreckt sich auch auf Sicherheitskontrollen. Eine Organisation kann zusätzliche Authentifizierungsmaßnahmen wie Multi-Faktor-Authentifizierung, Smartcard-Anmeldung oder Hardware Security Module-Schutz für Verschlüsselungsschlüssel basierend auf ihrem eigenen Risikoprofil hinzufügen, anstatt das zu akzeptieren, was ein Anbieter mitliefert. Eigentümerschaft bedeutet, dass diese Entscheidungen bei der Organisation bleiben und nicht bei dem, der den Tresor verkauft.

Besitzen Sie die Wahl, nicht nur die Daten

Netwrix Password Secure basiert auf dieser Wahl. Es bietet Organisationen die Möglichkeit zur Selbstverwaltung, lokal, in der Cloud oder hybrid, sodass Ihre Organisation die volle Kontrolle über die Verschlüsselung und die Umgebung behält, anstatt an den SaaS-Tresor eines Anbieters gebunden zu sein. Jeder Mitarbeiter erhält einen persönlichen Tresor, auf den sonst niemand zugreifen kann. Rollenbasierte Zugriffskontrollen bestimmen, wer welche Anmeldedaten sieht, und privilegierte Konten sind hinter genehmigungsbasierten Workflows statt offenem Zugriff geschützt. Jeder Zugriff und jede Aktion werden protokolliert, sodass Audits Minuten statt Untersuchungen dauern. Die Verzeichnisintegration mit Active Directory und Entra ID sorgt dafür, dass der Tresorzugang mit der Identitätsverwaltung überall konsistent bleibt.

Die Frage war nie, ob Sie selbst hosten müssen. Sondern ob Ihr Anbieter Ihnen diese Option überhaupt anbietet. Password Secure tut das.