#Vaultwarden

Ob ein Fehler am Server liegt oder am Rechner davor, verrät das Protokoll des Servers. Bei Vaultwarden scheiterte jede Einladung mit einer Meldung, die nach Server klang, also nach Ablauf, Zugang oder Mailversand. Im Protokoll stand zu den Klickversuchen jedoch kein einziger Aufruf: Die Oberfläche im Browser brach ab, bevor sie überhaupt fragte. Wo nichts ankommt, kann auch nichts falsch beantwortet werden, dann liegt die Ursache davor.

Eine Software, an der der Betrieb hängt, sollte sich nicht selbst auf die neueste Version aktualisieren. Unser Passwort-Tresor Vaultwarden lief auf dem Automatik-Kanal, zog Ende Juli die Version 1.37.0, und seitdem konnte niemand mehr eine Einladung in die Firmen-Organisation annehmen. Die letzte, die funktioniert hatte, war sechs Wochen alt; der Fehler war beim Hersteller gemeldet, die Korrektur noch nicht fertig. Wer immer die neueste Version nimmt, testet sie für alle anderen mit.

Dass dasselbe Programm im einen Browser alles zeigt und im anderen nichts, liegt fast immer am Rechner davor, nicht am Server. Bei unserem Passwort-Tresor Vaultwarden hatte sich die Erweiterung im einen Browser still auf die Juli-Fassung aktualisiert, im anderen lief noch die vom Juni. Die neuere stolperte über ein altes Feld: leere Liste, kein Fehler, Anmeldung ganz normal. Deshalb führte die Suche im Protokoll ins Leere, es gab dort nichts zu finden. Wenn zwei gleiche Arbeitsplätze sich verschieden verhalten, steckt die Ursache in dem, was sie unterscheidet.

Aktuell ist ein Programm nicht, nur weil irgendwo automatisch danebensteht. Unser Vaultwarden lief unter der Kennzeichnung neueste Version und war trotzdem sechs Wochen hinterher, weil die neue Fassung nie geholt wurde. Das nachgezogene Update schloss neun Sicherheitslücken auf einmal, darunter eine, die Zugriff über Mandantengrenzen hinweg erlaubte. Seitdem schaue ich nicht in die Einstellung, sondern in die laufende Version. Automatisch heißt nur, dass es jemand einmal so eingerichtet hat, nicht, dass es geschieht.

Ein Datenbank-Backup, dessen Schlüssel fehlt, nützt im Ernstfall gar nichts. Beim Härten unserer Sicherungen fiel auf, dass unser Skript zwar jede Datenbank zog, die Service-Schlüssel aber nicht mitsicherte, den Vaultwarden-Schlüssel, die n8n-Verschlüsselung, die Matrix-Signaturen. Ohne die wären die Daten nur unlesbarer Zeichensalat gewesen. Jetzt wandern rund neun Megabyte Schlüssel bei jedem Lauf mit ins Archiv. Ein Backup, das man nicht wieder aufschließen kann, ist ein Schrank ohne Schlüssel.

Ein vergessenes Master-Passwort kann man nirgends nachschlagen, auch nicht als Administrator. Bei Vaultwarden liegt es nie im Klartext, der Server kennt nur einen Hash mit sechshunderttausend Iterationen, aus dem erst auf dem Gerät der Schlüssel abgeleitet wird. Ich habe lange auf dem Server gesucht und musste am Ende einsehen, dass es schlicht nicht abrufbar ist, weil es so gebaut wurde. Genau das ist der Sinn: Was niemand auslesen kann, kann auch niemand stehlen.

Ein Zugang, den man oft benutzt, aber nie ablegt, ist verloren, sobald das Gedächtnis aussetzt. Wir hatten die Zugangsdaten für die Loco-Soft SOAP-Schnittstelle im April einmal ermittelt und seither immer wieder verwendet, doch die Notiz, sie in den Passwort-Tresor Vaultwarden zu legen, blieb liegen. Als ich sie jetzt brauchte, fand ich sie nirgends, weder im Tresor noch auf einem Server, und das war mein Fehler. Etwas oft zu benutzen ist nicht dasselbe wie es zu besitzen, erst das Ablegen macht aus Wissen einen Bestand.