Sollte dein Vaultwarden-Tresor nur per VPN erreichbar sein? Drei Bedingungen

Der erste Login auf einem Ersatztelefon ist der Moment, in dem ein nur per VPN erreichbarer Tresor seine Kosten zeigt: Die App hat keinen Cache, der Server steht hinter einem Tunnel, und die Tunnel-Zugangsdaten können in dem Tresor liegen, den du nicht öffnen kannst. Das ist eine Designfrage und kein Ausfall, und sie ist vor dem Rollout billiger zu beantworten als danach. Drei Bedingungen entscheiden, ob ein privater Tresor für deine Nutzer praktikabel ist. Wenn eine davon scheitert, ist die richtige Antwort meist eine engere Exposition statt einer VPN-Mauer.

Bedingung 1: Deine Nutzer erreichen den Server am ersten Tag

Ein neues Gerät hat keinen Cache, keine Sitzung und kein Vertrauen. Es braucht den aufgelösten Hostnamen des Servers, die Route dorthin und ein VPN-Profil, das bereits installiert ist, bevor der Nutzer sich anzumelden versucht. Kommt eines dieser drei erst nach dem ersten Login, scheitert der Rollout im schlechtesten möglichen Moment. Zähle, wie viele Schritte eine neue Mitarbeiterin gehen muss, bevor sie ihren Tresor öffnen kann.

Ein Split-Tunnel passt hier oft besser: Übertrage nur den Tresor-Endpunkt und den DNS-Pfad, den er braucht, und lass den übrigen Verkehr der Nutzer in Ruhe. Das ist eine Routing-Entscheidung, die man mit dem Eigentümer des VPN trifft, keine Annahme, dass jeder mobile Client dieselbe Richtlinie befolgt. Beide Adressfamilien und der Hostname des Dienstes müssen zu dieser Wahl passen.

Wenn Nutzer den Server nicht erreichen, bevor sie funktionierende Zugangsdaten haben, scheitert diese Bedingung, und die VPN-Mauer hat die falsche Form.

Bedingung 2: Zwischengespeicherter Zugriff ist schreibgeschützt, und das genügt

Bitwarden-Clients können einen bereits entsperrten Tresor anzeigen, ohne den Server zu erreichen, und diese Offline-Kopie ist schreibgeschützt. Sie ist nützlich, um während eines Ausfalls ein Passwort zu lesen; sie ist kein neuer Login und keine Bearbeitung. Entscheide, ob Schreibschutz für deine Nutzer akzeptabel ist, bevor du darum herum planst.

curl -sI https://vault.example.com/alive
openssl s_client -connect vault.example.com:443 -servername vault.example.com </dev/null

Sperren und Abmelden sind verschiedene Zustände, und der Unterschied ist hier wichtig. Ein gesperrter Client hält den lokalen Tresor verschlüsselt und kann ihn mit dem Hauptpasswort oder biometrisch wieder entsperren; Abmelden entfernt diese lokale Kopie und verlangt den Server. Wenn ein Support-Skript den Nutzern sagt, sie sollen sich ab- und wieder anmelden, um ein Synchronisationsproblem zu beheben, entfernt es auch ihren Offline-Zugang. Prüfe die Timeout-Aktion auf jedem Client, statt die Voreinstellung anzunehmen.

Eine zwischengespeicherte Kopie ist keine Sicherung. Sie lebt auf einem Gerät, ist an ein Konto gebunden und verschwindet mit einer Abmeldung oder einem Löschen.

Bedingung 3: Die Wiederherstellung läuft nicht über den Tresor selbst

Der Zirkelfall ist leicht versehentlich gebaut: Die VPN-Zugangsdaten liegen im Tresor, der Tresor liegt hinter dem VPN, und das einzige Gerät mit einem Cache ist das verlorene. Dann hängt die Wiederherstellung von einem Dokument oder einer Person außerhalb des Systems ab. Schreib diesen Bootstrap-Pfad auf und teste ihn mit einem wiederherstellbaren Konto, bevor ihn jemand braucht. Ein Notfallverfahren, das niemand geübt hat, ist eine Hoffnung.

Teste die Reihenfolge kontrolliert: Stelle fest, welche vorhandenen Einträge offline lesbar bleiben, stelle dann den Netzwerkpfad wieder her und prüfe, ob ein frischer Login und eine Synchronisation beide funktionieren. Melde dich nicht versuchsweise von der einzigen zwischengespeicherten Kopie ab, es sei denn, es gibt einen anderen Weg zurück. Halte fest, was du beobachtet hast, einschließlich der Client-Version.

Wenn die Wiederherstellung den Tresor braucht, scheitert diese Bedingung. Die Lösung ist ein dokumentierter Out-of-Band-Pfad, keine schärfere Warnung im Onboarding-Dokument.

Was du in jedem Fall behältst: HTTPS, Sicherungen und Updates

HTTPS bleibt auch hinter dem VPN bestehen. Es gibt dem Webdienst eine Identität, die der Browser prüfen kann, und hält die Anwendungsverbindung geschützt, unabhängig davon, wo der Tunnel endet. Ein privater Endpunkt sollte Nutzern nicht beibringen, Zertifikatswarnungen wegzuklicken, denn diese Gewohnheit folgt ihnen auf öffentliche Seiten.

Sicherungen sind eine eigene Disziplin, getrennt von der Verfügbarkeit. Vaultwarden speichert seine Daten in einer Datenbank, und eine konsistente Kopie, die bei gestopptem Dienst entsteht, oder eine Sicherung auf Datenbankebene ist mehr wert als eine Datei, die aus einem laufenden Prozess kopiert wurde. Halte die Kopie außerhalb des Tresor-Hosts und teste eine Wiederherstellung. Exportiertes Tresormaterial braucht denselben Schutz wie das Original, weil ein Export nicht so verschlüsselt ist wie der Speicher des Servers.

sqlite3 /data/db.sqlite3 ".backup '/backup/vault-2026-11-03.sqlite3'"
docker compose ps

Halte danach Server und Clients aktuell. Zugang nur per VPN verringert die Exposition; er macht eine verwundbare Implementierung nicht harmlos und schützt keinen kompromittierten Endpunkt. Die drei Bedingungen entscheiden das Zugangsmodell, und die Wartung entscheidet, ob dieses Modell das Jahr übersteht.