Das verschlüsselte Verzeichnis für Zugangsdaten

Wo Passwörter liegen, wie sie ein Formular erreichen, ohne je durch Ihre Shell zu laufen, und der eine Fehler, der sie unbemerkt im Klartext schreibt.

Ihre Zugangsdaten liegen in einem verschlüsselten Verzeichnis, das Sie einhängen – einem gocryptfs-Volume. Sie stehen darin in einer einfachen JSON-Datei, und diese Datei ist nur lesbar, solange das Volume eingehängt ist. Diwall liest sie im Prozess, der den Browser steuert, in dem Moment, in dem ein Feld ausgefüllt wird. Der Wert läuft nie durch Ihre Shell, Ihren Befehlsverlauf oder Diwalls eigene Protokolle.

Die Wortwahl zählt hier: Eine JSON-Datei ist kein Tresor, und wer sie so nennt, verspricht eine Garantie, die die Datei nicht bietet. Was die Zugangsdaten schützt, ist die Verschlüsselung des Verzeichnisses um sie herum – und dass Diwall den Wert nie aus dem Prozess herausgibt, der ihn braucht.

Das ist der ganze Mechanismus. Der Rest dieser Seite zeigt, wie man ihn einrichtet, und einen Weg, es falsch zu machen.

Einmal anlegen

diwall-monter-secrets              # ein bestehendes verschlüsseltes Verzeichnis einhängen

Zum Anlegen kennt das Einrichtungsskript des Repositorys beide Modi – standardmäßig mit gocryptfs verschlüsselt, oder ein Klartextverzeichnis mit --sans-chiffrement. Das Paket liefert es nicht mit: Führen Sie es aus einem Klon des Repositorys aus und geben Sie ihm die Konfiguration des Pakets an, wenn Sie Diwall so installiert haben.

git clone https://github.com/RonanDavalan/diwall.git
bash diwall/scripts/configurer-repertoire-chiffre.sh --config /etc/diwall/diwall.conf   # Paketkanal
bash diwall/scripts/configurer-repertoire-chiffre.sh                                     # Git-Klon-Kanal

Der verschlüsselte Modus legt den verschlüsselten Speicher und einen leeren Einhängepunkt an. Auf der Festplatte ist nichts lesbar, bis Sie ihn einhängen.

Zugangsdaten hineinlegen

Eine einfache JSON-Datei im eingehängten Verzeichnis:

{
  "username": "operator",
  "password": "…",
  "totp_cle": "BASE32SEED",
  "ntfy_topic": "…",
  "origines_autorisees": ["target.local"]
}

Nur die Schlüssel, die Ihr Szenario tatsächlich verwendet, müssen vorhanden sein – außer origines_autorisees, Pflicht seit dem 05.08.2026, ohne Ausnahme. Es listet die Hostnamen auf, für die diese Datei verwendet werden darf; ein Lesezugriff für eine andere Domain wird abgelehnt, bevor die Datei überhaupt geöffnet wird. totp_cle ist der Base32-Schlüssel für Zwei-Faktor-Codes; ntfy_topic dient für Codes, die Ihnen zugeschickt werden.

In einem Szenario verwenden

{"type": "remplir_som", "id": 2,
 "valeur": "depuis_secrets", "secret_cle": "username"},
{"type": "remplir_som", "id": 3,
 "valeur": "depuis_secrets", "secret_cle": "password"}

secret_cle ist der Schlüssel in der entschlüsselten Datei. Das Szenario kann committet werden – es nennt einen Schlüssel, nie ein Geheimnis. Deshalb kann ein Szenario in einem öffentlichen Repository liegen, ohne dass etwas geschwärzt werden muss.

Tun Sie das nie PASS=$(jq -r ‘.password’ ~/Vaults/…/creds.json) – Zugangsdaten in einer Shell-Variablen stehen in Ihrer Prozessumgebung, in /proc und womöglich in Ihrem Verlauf. Genau das soll das verschlüsselte Verzeichnis verhindern.

Ein Verzeichnis pro Projekt

Zwei Wege, je nachdem, ob es ein Einzelfall oder eine Gewohnheit ist.

# Einmalig
DIWALL_SECRETS_DIR=~/Vaults/MeinProjekt diwall-shot --url … --guide-version 1.3

# Dauerhaft – eine Konfigurationsdatei im Wurzelverzeichnis des Projekts
echo '{"secrets_dir": "../MeinProjekt-secrets"}' > ~/git/MeinProjekt/.diwall.conf
export DIWALL_CONF=~/git/MeinProjekt/.diwall.conf

Ein relatives secrets_dir wird relativ zum Ort der Konfigurationsdatei aufgelöst, sodass das Ganze mit dem Projekt umzieht.

--secrets <Datei> bestimmt für einen Lauf genau eine Zugangsdatendatei, ohne irgendeine Konfiguration anzufassen – nützlich, wenn dasselbe Szenario mehrere Mandanten bedient.

Wenn das Verzeichnis geschlossen ist

Diwall bricht mit einem ausdrücklichen Fehler ab, statt so zu tun, als ob:

SecretsFermesError — exit code 42

Wenn Sie ein Agent sind: Versuchen Sie nicht, es selbst einzuhängen. Fragen Sie den Betreiber.

Diwall schützt auch seine eigenen Schreibvorgänge. Sein Operationsjournal erkennt ein geschlossenes Verzeichnis und weicht auf einen lokalen Ersatzort aus, statt im Klartext dorthin zu schreiben, wo der verschlüsselte Speicher sein sollte; die Archivierung der Beweise wird übersprungen, statt authentifizierte Screenshots außerhalb davon zu verdoppeln.

Der Fehler, der am meisten kostet

Ein nicht eingehängtes Verzeichnis existiert weiterhin. Es ist lediglich leer – und unverschlüsselt.

Diwalls interne Schutzvorkehrung deckt Diwalls eigene Schreibvorgänge ab. Sie deckt nicht eine Zugangsdatendatei ab, die Sie selbst anlegen, mit einem Shell-Befehl oder einem Editor, während das Verzeichnis gerade nicht eingehängt ist. Dann schreiben Sie nicht hinein: Sie schreiben daneben, im Klartext, in ein Verzeichnis, das genau richtig aussieht.

Bevor Sie eine Zugangsdatendatei anlegen oder ändern, vergewissern Sie sich, dass das Verzeichnis eingehängt ist – es darf nicht leer sein. Im Zweifel anhalten und nachsehen. Das lässt sich nicht rückgängig machen.

Kurz gesagt

Die Datei wird im Browserprozess gelesen, nie über Ihre Shell.
Szenarien nennen einen Schlüssel, nie ein Geheimnis – so bleiben sie committbar.
DIWALL_CONF oder --secrets für Verzeichnisse pro Projekt und pro Mandant.
Exit-Code 42 heißt geschlossen: den Betreiber fragen, nicht selbst einhängen.
Ein nicht eingehängtes Verzeichnis ist ein leeres, unverschlüsseltes Verzeichnis. Vor dem Schreiben nachsehen.