Vaultwarden ist eine schlanke Open-Source-Neuimplementierung des Bitwarden-Servers, geschrieben in Rust. Er spricht dasselbe Protokoll wie die offiziellen Bitwarden-Clients (Browsererweiterung, Mobile-Apps, Desktop und CLI), läuft aber vollständig in Ihrer Infrastruktur, ohne Abhängigkeit von der Cloud eines Drittanbieters. Bei NexTool ist er der Baustein, mit welchem wir die Geheimnisse des Service-Desk-Betriebs verwahren: Serverpasswörter, API-Tokens, Zugangsdaten zu Kundenumgebungen und teamweit geteilte Tresore, immer neben dem GLPI, welches wir bereits betreiben.
Warum selbst gehostet für die Verwaltung von Betriebsgeheimnissen
Support- und Infrastrukturteams sammeln ein stilles Problem an: Dutzende kritische Zugangsdaten, verstreut in Tabellen, im persönlichen Bitwarden jedes Technikers, in Ticketnotizen oder, schlimmer noch, im Klartext im Ticket selbst. Vaultwarden löst dies mit einem zentralen Tresor, mit Verwaltung von Organisationen, Sammlungen und Freigabe pro Gruppe, wobei die Daten innerhalb Ihres Perimeters bleiben. Für einen B2B-Kunden, der Datensouveränität verlangt (LGPD, Verträge mit Klauseln zum Speicherort), ist Self-Hosting keine ästhetische Vorliebe, sondern eine Anforderung.
Der Ressourcenverbrauch ist bescheiden. Da er in Rust geschrieben ist und standardmäßig SQLite nutzt, läuft der Container für kleine und mittlere Teams meist mit ~128-256 MB RAM, sodass Sie ihn auf demselben Host betreiben können, der bereits GLPI beherbergt, hinter demselben Reverse Proxy, ohne eine neue Maschine bereitzustellen.
Artefakt: schlankes docker-compose mit Härtung
Folgendes Gerüst verwenden wir als Ausgangspunkt. Beachten Sie, dass Registrierungen deaktiviert sind (nur Einladung per SMTP), der Port nur auf 127.0.0.1 veröffentlicht wird (nach außen stellt ihn der Reverse Proxy mit TLS bereit) und ADMIN_TOKEN ein argon2-Hash ist, niemals ein rohes Passwort:
version: "3.8"
services:
vaultwarden: # Rust reimplementation of Bitwarden
image: vaultwarden/server:latest
container_name: vaultwarden
restart: unless-stopped
environment: # hardening variables
DOMAIN: "https://vault.suaempresa.com"
SIGNUPS_ALLOWED: "false"
INVITATIONS_ALLOWED: "true"
ADMIN_TOKEN: "$argon2id$v=19$m=65540,t=3,p=4$...hash..."
SMTP_HOST: "smtp.suaempresa.com"
SMTP_FROM: "[email protected]"
SMTP_PORT: "587"
SMTP_SECURITY: "starttls"
SMTP_USERNAME: "[email protected]"
SMTP_PASSWORD: "${SMTP_PASSWORD}"
volumes:
- ./vw-data:/data # persistent volume (SQLite + attachments)
ports:
- "127.0.0.1:8080:80"
Der Hash für das Admin-Panel wird mit dem Binary selbst erzeugt, und der Klartextwert berührt die Datei nie:
# generate the argon2 hash for ADMIN_TOKEN
docker run --rm -it vaultwarden/server /vaultwarden hash
# Cole o hash resultante em ADMIN_TOKEN (nunca a senha em texto plano)
Vaultwarden selbst gehostet vs. Bitwarden Cloud
Die Wahl ist keine ideologische. Sie hängt davon ab, wer den Betriebsaufwand trägt und wie sensibel die Daten sind:
| Kriterium | Vaultwarden selbst gehostet | Bitwarden Cloud (kostenpflichtige Pläne) |
|---|---|---|
| Direkte Kosten | Nur die Infrastruktur (teilt sich den Host mit GLPI) | Lizenz pro Benutzer/Monat |
| Datensouveränität | Vollständig - Daten in Ihrem Perimeter | Cloud des Anbieters (festgelegte Regionen) |
| Premium-Funktionen (2FA, Berichte, Organisation) | Enthalten, ohne Paywall | Abhängig vom gebuchten Plan |
| Betriebsaufwand | Ihrer (Patches, Backup, TLS, Monitoring) | Beim Anbieter (verwalteter SLA) |
| Rechtliche Verantwortung | Ihre (Verantwortlicher und Auftragsverarbeiter) | Mit dem Anbieter geteilt |
Für alle, die Patches, Backup und TLS nicht selbst tragen möchten, ist Bitwarden Cloud ehrlich gesagt die richtige Antwort. Für alle, die bereits ein Betriebsteam haben (etwa NexTool, wenn wir die Umgebung des Kunden übernehmen), rechnet sich Self-Hosting.
Sichere Bereitstellung Schritt für Schritt
Ablauf, den wir beim Aufsetzen eines produktiven Vaultwarden befolgen:
- Reverse Proxy mit HTTPS. Wir veröffentlichen den Dienst nur auf
127.0.0.1und setzen einen Reverse Proxy (denselben, der GLPI ausliefert) mit gültigem Zertifikat davor. Vaultwarden verlangt HTTPS, damit die Clients funktionieren. - Registrierungen deaktivieren.
SIGNUPS_ALLOWED=falseschließt die offene Registrierung; niemand legt selbst ein Konto an. Zugang gibt es immer nur per Einladung. - ADMIN_TOKEN als argon2-Hash. Wir erzeugen den Hash mit dem Binary und speichern nur ihn. Panel
/adminverlangt dann diesen Token, und ein Klartextpasswort steht nie in der Datei. - SMTP für Einladungen und Warnungen. Wir konfigurieren
SMTP_*, damit Einladungen zu Organisationen und Passwortrücksetzungen per authentifizierter E-Mail der Domain verschickt werden. - Getestetes Backup. Es genügt nicht, die laufende SQLite-Datei zu kopieren. Wir verwenden
sqlite3 .backup(konsistent mit der laufenden Datenbank) plus Anhänge und RSA-Schlüssel und stellen regelmäßig in einer separaten Umgebung wieder her. - Aktualisierung. Image
lateständert sich schnell; in Produktion fixieren wir eine Version und aktualisieren mit Wartungsfenster und frischem Backup vorab.
# consistent database backup (never cp the hot file)
sqlite3 /srv/vaultwarden/vw-data/db.sqlite3 \
".backup '/backup/vaultwarden-$(date +%F).sqlite3'"
# attachments + RSA key (without them the vault will not open)
tar czf /backup/vw-attachments-$(date +%F).tgz \
-C /srv/vaultwarden/vw-data attachments rsa_key config.json
Wie wir im Betrieb von GLPI-Kunden arbeiten
Im Betrieb von GLPI-Kundenumgebungen nutzen wir Vaultwarden als Betriebstresor: Jeder Kunde wird zu einer Organisation, mit nach Art getrennten Sammlungen (Serverzugänge, API-Zugangsdaten, Portalkonten), und ein Team erhält Zugriff pro Gruppe, nicht über einzelne Passwörter. Ein häufiger Fehler, den wir gesehen haben, auch bevor wir dies standardisiert hatten, war, ADMIN_TOKEN im Klartext in der Compose-Datei zu lassen und versehentlich zu committen; deshalb ist er heute immer ein argon2-Hash, und .env bleibt außerhalb der Versionsverwaltung. Eine weitere Entscheidung war, Vaultwarden hinter denselben Reverse Proxy wie GLPI zu stellen, auf demselben Host, und so TLS, Monitoring und Backup-Routine wiederzuverwenden. Und wie man Backups richtig macht, haben wir gelernt: cp einer laufenden db.sqlite3 kann die Datenbank mitten in einem Schreibvorgang erfassen und eine beschädigte Wiederherstellung erzeugen; sqlite3 .backup löst dies, und ohne den Schlüssel rsa_key dazu lässt sich ein Tresor später schlicht nicht öffnen. Solche Details zeigen sich erst im Betrieb, nicht beim Lesen der README.
Häufige Fragen
Wenn Sie eine GLPI-Umgebung betreiben und die Geheimnisse Ihres Betriebs mit Unterstützung von Leuten zentralisieren möchten, die genau dies bereits tun, sehen Sie sich unsere Services für Infrastruktur und Cloud an oder sprechen Sie mit unserem Team.
Geprüft vom Team von NexTool Solutions.
