In fast jedem gewachsenen Betrieb existiert eine Passwort-Sammlung, die niemand so geplant hat: eine Tabelle auf dem Laufwerk, ein Notizbuch in der Schublade, ein geteiltes Konto, dessen Kennwort seit Jahren dasselbe ist. Das ist kein Vorwurf — es ist der Normalfall, und es funktioniert erstaunlich lange. Es fällt erst auf, wenn jemand den Betrieb verlässt, wenn ein Zugang gebraucht wird und der Kollege im Urlaub ist, oder wenn ein Kunde einen Sicherheitsfragebogen schickt. Wie solche Zustände entstehen und in welcher Reihenfolge man sie aufräumt, habe ich in IT-Sicherheit im Kleinbetrieb beschrieben.

Dass ein Passwort-Manager die Antwort darauf ist, steht außer Frage und ist schnell erklärt. Die Frage, an der es im Betrieb tatsächlich hängt, ist eine andere: gehostet mieten oder selbst betreiben. Darum geht es hier.

Die drei Wege

Es gibt nicht zwei Möglichkeiten, sondern drei — und der mittlere wird regelmäßig übersehen.

Erstens: gehostet mieten. Sie legen ein Organisationskonto beim Anbieter an, zahlen pro Nutzer und Monat und haben mit Servern nichts zu tun. Bitwarden verlangt dafür nach eigener Preisliste 4 US-Dollar pro Nutzer und Monat im Teams-Plan und 6 US-Dollar im Enterprise-Plan, jeweils bei jährlicher Zahlung. Ich nenne die US-Listenpreise, weil sie die Primärquelle sind; die Europreise weichen je nach Vertrag ab.

Zweitens: den offiziellen Server selbst betreiben. Bitwarden lässt sich auf eigener Hardware installieren. Der Anbieter nennt dafür als Mindestausstattung einen x64-Prozessor mit 1,4 GHz, 2 GB Arbeitsspeicher und 12 GB Speicherplatz, empfohlen werden 4 GB und 25 GB; Grundlage ist Docker. Für die Installation braucht es eine kostenlos angeforderte Installations-ID mit Schlüssel. Die Organisationsfunktionen — also alles, was den Einsatz im Betrieb ausmacht — sind allerdings lizenzpflichtig; Self-Hosting führt Bitwarden auf der Preisseite als Enterprise-Merkmal. Sie hosten also selbst und zahlen trotzdem pro Nutzer.

Drittens: Vaultwarden. Eine eigenständige Server-Implementierung der Bitwarden-Schnittstelle, geschrieben in Rust, quelloffen unter AGPL-3.0. Die offiziellen Clients — Handy-App, Browser-Erweiterung, Desktop — funktionieren damit. Kosten für Lizenzen entstehen keine.

Was Vaultwarden ist — und was es ausdrücklich nicht ist

Das Projekt beschreibt sich selbst als alternative Server-Implementierung der Bitwarden-Client-Schnittstelle, gedacht für den Eigenbetrieb dort, wo der offizielle, ressourcenhungrigere Dienst nicht ideal ist. Als Zielgruppe nennt es ausdrücklich Einzelpersonen, Familien und kleine Organisationen.

Ebenso ausdrücklich hält das Projekt fest: Es steht in keiner Verbindung zu Bitwarden, Inc. Und es schließt die Haftung für Datenverlust aus, verbunden mit der Aufforderung, regelmäßig Sicherungen anzulegen. Beides ist kein Kleingedrucktes, sondern der Kern der Entscheidung: Sie übernehmen die Rolle des Betreibers vollständig.

Zwei technische Vorgaben nennt das Projekt selbst und sie sind nicht verhandelbar: Die Web-Oberfläche funktioniert nur über HTTPS, weil sie einen sicheren Kontext für die Verschlüsselung im Browser braucht. Und es wird empfohlen, einen Reverse Proxy davorzusetzen. Wer eines von beidem überspringt, betreibt keinen Passwort-Tresor, sondern ein Risiko.

Was der Eigenbetrieb wirklich kostet

Der Vergleich, der überall zuerst gezogen wird, geht so: Lizenzkosten gegen Serverkosten. Bei fünfzehn Personen im Teams-Plan sind das 720 US-Dollar im Jahr; ein kleiner virtueller Server, auf dem Vaultwarden läuft, kostet einen Bruchteil davon. Auf dem Papier ist die Sache damit entschieden.

Die Rechnung ist trotzdem falsch, weil auf der einen Seite ein Preis steht und auf der anderen eine Aufgabe. Was beim Eigenbetrieb dazukommt, taucht in keinem Angebot auf:

• Aktualisierungen, und zwar zeitnah. Ein Passwort-Tresor ist kein System, das man ein halbes Jahr liegen lassen kann.
• Sicherungen, die zurückspielbar sind. Nicht die Sicherung ist der Nachweis, sondern der Wiederherstellungsversuch.
• Erreichbarkeit. Wenn der Dienst steht, kommt niemand mehr an seine Zugänge — auch nicht an die, die er zur Reparatur bräuchte.
• Die Zuständigkeit selbst. Jemand muss das dauerhaft machen, auch im Urlaub und nach einem Personalwechsel.

Rechnet man eine Stunde Betreuung im Monat zu einem realistischen Satz, ist der Kostenvorteil bei fünfzehn Personen bereits aufgezehrt. Der Eigenbetrieb rechnet sich also nicht über die Lizenz. Er rechnet sich, wenn diese Stunde ohnehin anfällt, weil im Haus schon Linux-Systeme betreut werden — dann ist der Tresor eine weitere Anwendung auf einer bestehenden Landschaft und kostet real wenig zusätzlich.

Was ich bei der Einführung gelernt habe

Die Installation selbst ist unspektakulär und an einem Vormittag erledigt. Sie steht in der Dokumentation und ist nicht der Grund, warum solche Vorhaben scheitern. Der Teil, den man nicht nachlesen kann, beginnt danach.

Die Technik war nie das Problem, die Gewohnheit schon. Ein Passwort-Manager ändert einen Handgriff, den Menschen zwanzigmal am Tag machen. Wer daneben seine alte Liste behält, hat am Ende zwei Wahrheiten — und die schlechtere gewinnt, weil sie schneller ist. Die Einführung ist deshalb erst abgeschlossen, wenn die alten Sammlungen weg sind, nicht wenn der Server läuft.

Zuerst die geteilten Zugänge, dann die persönlichen. Der Nutzen zeigt sich dort, wo heute Schmerz ist: bei den Konten, die mehrere Leute brauchen und die niemandem gehören. Wer umgekehrt anfängt und die Leute zuerst ihre persönlichen Kennwörter einpflegen lässt, verlangt Aufwand, bevor er einen Vorteil liefert.

Die Wiederherstellung muss geklärt sein, bevor sie gebraucht wird. Ein Passwort-Manager ist so gebaut, dass der Betreiber die Inhalte nicht lesen kann — das ist der Sinn der Sache. Es bedeutet aber auch: Wer sein Hauptkennwort verliert, kommt ohne vorbereiteten Weg nicht mehr an seine Daten. Diese Frage einmal vorab zu klären, kostet zehn Minuten. Sie im Ernstfall zu klären, ist zu spät.

Der häufigste Einwand war keine Frage, sondern eine Abwehr. Er lautet: „Ich habe gar keine Passwörter, ich brauche den Zugang nicht.“ Das kann nicht stimmen — wer Mails abruft, im Lieferantenportal bestellt oder sich in der Warenwirtschaft anmeldet, hat Zugangsdaten. Was der Satz tatsächlich bedeutet, ist meistens eines von drei Dingen: Die Kennwörter stehen im Browser und werden nie eingegeben. Oder es ist überall dasselbe. Oder sie liegen auf einem Zettel, den man ungern erwähnt.

Der Einwand ist deshalb selbst ein Befund: Wer glaubt, keine Zugänge zu haben, hat sie nie zusammengeschrieben. Genau diese Leute sind es, bei denen später niemand weiterweiß — wenn sie den Betrieb verlassen oder länger ausfallen. Ich nehme den Satz inzwischen nicht mehr als Ablehnung, sondern als Hinweis, wo ich zuerst hinschauen sollte.

Für eine einzelne Person mag der Einwand sogar tragen: Wer eine Handvoll Zugänge hat, kommt damit irgendwie zurecht. Im Betrieb entscheidet aber nicht der Einzelfall, sondern die Summe. Zwanzig Leute mit je einer Handvoll Zugängen ergeben mehrere hundert Anmeldungen, dazu die geteilten Konten, die niemandem gehören. Ein Passwort-Manager löst deshalb kein persönliches Problem, sondern ein organisatorisches — und genau deshalb lässt er sich auch nicht der Belegschaft freistellen. Ein Tresor, den die Hälfte benutzt, ist kein halber Tresor, sondern keiner.

Wann ich davon abrate

Es gibt Konstellationen, in denen ich vom Eigenbetrieb abrate, auch wenn technisch nichts dagegen spricht:

• Es gibt niemanden im Haus, der Linux betreut. Dann ist jede Störung ein Notruf nach außen — bei ausgerechnet dem System, das Sie brauchen, um sich irgendwo anmelden zu können.
• Die Zuständigkeit hängt an einer Person ohne Vertretung. Dasselbe Risiko wie bei jedem gewachsenen Einzelwissen: Es fällt genau dann aus, wenn es gebraucht wird.
• Es soll bei einem Kunden oder Prüfer als Nachweis dienen. Sicherheitsfragebögen fragen zunehmend nach Herstellersupport und Verantwortlichkeiten. Ein Community-Projekt ohne Vertragspartner ist dort erklärungsbedürftig — nicht unmöglich, aber Sie schreiben mehr.
• Der Auslöser ist reine Kostenersparnis. Die Ersparnis ist selten das, wonach sie aussieht.

Wenn Datenhoheit der Grund ist, gibt es einen kürzeren Weg

Häufig ist das eigentliche Motiv nicht Geld, sondern die Frage, wo die Daten liegen — die größere Fassung davon habe ich unter digitale Souveränität beschrieben. Dafür muss man nicht zwingend selbst betreiben: Bitwarden führt zwei getrennte Cloud-Regionen, eine in den Vereinigten Staaten und eine in der Europäischen Union, mit nach eigener Aussage identischen Sicherheitsmaßnahmen. Wer die europäische Region wählt, bekommt einen erheblichen Teil dessen, wofür sonst der Eigenbetrieb herhalten muss — ohne die Betreiberrolle zu übernehmen.

Ein Detail lohnt die Aufmerksamkeit: Ein späterer Wechsel zwischen den Regionen ist möglich, aber nicht automatisiert. Der Anbieter beschreibt sie als getrennte Umgebungen; migriert wird per Skript oder von Hand über Export und Import. Die Region ist also eine Entscheidung, die man besser am Anfang trifft als in zwei Jahren.

Der Vollständigkeit halber: Der Eigenbetrieb bleibt der einzige Weg, bei dem die Daten das eigene Haus nie verlassen. Wenn das die Anforderung ist, ist er richtig — dann aber aus diesem Grund und nicht wegen der Lizenzkosten.

Woran Sie merken, ob der Eigenbetrieb zu Ihnen passt

Ob Sie das Vorhaben stemmen, entscheidet sich nicht an der Installation. Es entscheidet sich an vier Fragen, die Sie ohne Nachdenken beantworten können sollten:

• Wer bringt den Dienst zurück, wenn er an einem Freitagabend ausfällt — und wer, wenn diese Person im Urlaub ist?
• Wann haben Sie zuletzt eine Sicherung nicht nur angelegt, sondern zurückgespielt? Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung.
• Wie erfahren Sie von einer Sicherheitsaktualisierung, und wie lange dauert es bei Ihnen, bis sie eingespielt ist?
• Wer kommt an den Tresor, wenn der Verantwortliche nicht erreichbar ist?

Wer hier viermal eine klare Antwort hat, betreibt vermutlich schon andere Systeme und wird auch mit diesem zurechtkommen. Wer zögert, sollte mieten. Das ist keine Schwäche, sondern eine Ressourcenfrage — und die gehostete Variante ist ein gutes Produkt, kein Kompromiss.

Die technischen Grundvoraussetzungen nennt das Projekt in seiner Dokumentation selbst und sie sind knapp: verschlüsselte Verbindung, ein vorgelagerter Reverse Proxy, ein abgesicherter Administrationsbereich und eine geschlossene Registrierung. Wie man das im eigenen Netz sauber zusammensetzt, hängt allerdings von der vorhandenen Umgebung ab — das ist der Teil, den ich mit Kunden im Einzelfall durchgehe.