Ein eigener Server für den Passworttresor
Für technische Zugangsdaten nutze ich in meinem Homelab einen eigenen Vaultwarden-Server. Der Dienst läuft als Docker-Anwendung und lässt sich mit kompatiblen Bitwarden-Apps und Browser-Erweiterungen verwenden. Zugangsdaten müssen dadurch nicht in Konfigurationsnotizen oder Chatverläufen verteilt werden.
Vaultwarden ist ein eigenständiges Community-Projekt und kein offizieller Bitwarden-Server. Welche Funktionen mit einer bestimmten App-Version zusammenarbeiten, sollte man vor einer Umstellung prüfen. Wer selbst hostet, übernimmt außerdem die Verantwortung für Updates, Erreichbarkeit und Sicherungen.
HTTPS und Erreichbarkeit bewusst planen
Mein Tresor wird über einen Reverse Proxy mit gültigem HTTPS-Zertifikat erreicht. Der direkte Anwendungsport ist dafür nicht zusätzlich im Heimnetz veröffentlicht. Der Name ist bequem; die eigentliche Zugriffsbeschränkung wird gesondert eingerichtet und getestet.
In meinem Aufbau dürfen nur ausgewählte Geräte im Heimnetz synchronisieren. Eine neue Synchronisation unterwegs bleibt bewusst gesperrt. Bereits lokal verfügbare Einträge können in einer entsprechend eingerichteten, entsperrten App weiterhin nutzbar sein. Das ersetzt keine erreichbare Serververbindung für Änderungen und Abgleich. Ein internes Angebot kann ein gültiges Zertifikat besitzen, ohne öffentlich freigegeben zu sein.
Masterpasswort, zweiter Faktor und Rückweg
Die Bitwarden-Clients verschlüsseln die Tresorinhalte. Ein langes, ausschließlich für diesen Tresor verwendetes Masterpasswort bleibt deshalb zentral. Einen zweiten Anmeldefaktor würde ich zusätzlich einrichten und anschließend die Anmeldung auf den tatsächlich genutzten Geräten prüfen.
Wichtig ist der Notfallweg: Wiederherstellungscodes gehören geschützt an einen Ort, der auch ohne Zugriff auf denselben Tresor erreichbar ist. Ein Code für den verlorenen zweiten Faktor ersetzt kein vergessenes Masterpasswort. Auch die Erreichbarkeit des Servers, die Kontoanmeldung und das lokale Entsperren der App sind unterschiedliche Dinge.
Die Daten bleiben außerhalb des Containers
Das Image enthält das Programm. Die dauerhafte Ablage enthält den eigentlichen Zustand des Dienstes. Bei einer Neuerstellung des Containers müssen deshalb die richtigen Datenverzeichnisse wieder eingebunden werden. Die Compose-Definition dokumentiert diesen Zusammenhang.
Zur Sicherung gehören ein konsistenter Datenbankstand und die benötigten zusätzlichen Dateien, beispielsweise Anhänge und Konfiguration. Bei laufendem SQLite-Betrieb ist ein vorgesehenes Datenbank-Backup sinnvoller als das blinde Kopieren einer einzelnen Datenbankdatei. Welche Dateien benötigt werden, beschreibt die Vaultwarden-Dokumentation für das jeweilige Datenbankverfahren.
Diese Sicherung behandle ich als vertraulich und bewahre sie getrennt vom laufenden Dienst auf. Verschlüsselte Tresorinhalte machen nicht automatisch jede enthaltene Konfigurationsdatei oder jeden Betriebsschlüssel unkritisch. Eine Wiederherstellung sollte in einer getrennten Umgebung geprüft werden, bevor man sie im Notfall braucht.
Nach einem Update die Anwendung prüfen
Vor einem Update stehen Sicherung und Rückweg fest. Nach dem Start prüfe ich neben dem Containerzustand den tatsächlichen Ablauf: Ist die richtige Serveradresse erreichbar, funktioniert die Anmeldung und lässt sich ein unkritischer Testeintrag synchronisieren? Die Versionshinweise gehören dabei zur Vorbereitung.
Ein grüner Containerstatus beweist weder die korrekte Proxy-Freigabe noch die Funktion jeder verwendeten App. Gerade beim Passworttresor lohnt sich eine kurze, gezielte Prüfung der Geräte, auf die man im Alltag angewiesen ist.
Für wen sich der Eigenbetrieb lohnt
Vaultwarden passt für mich zu einer Umgebung, in der Serverpflege und Sicherungen bereits verlässlich organisiert sind. Der Nutzen entsteht durch einen klaren Ablageort, passende Apps und bewusst begrenzte Zugänge. Wer diese Betriebsaufgaben nicht übernehmen möchte, sollte auch einen betreuten Passwortdienst in Betracht ziehen.