Das verschlüsselte Credential-Verzeichnis

Wo Passwörter gespeichert werden, wie sie ein Formular erreichen, ohne jemals Ihren Shell-Prozess zu durchlaufen, und der eine Fehler, der sie stillschweigend im Klartext speichert.

Ihre Zugangsdaten befinden sich in einem verschlüsselten Verzeichnis, das Sie einbinden – einem gocryptfs Volume. Sie liegen in einer einfachen JSON-Datei innerhalb dieses Verzeichnisses, und diese Datei ist nur lesbar, während das Volume eingebunden ist. Dinoer liest sie innerhalb des Prozesses, der den Browser steuert, zum Zeitpunkt, wenn ein Feld ausgefüllt wird. Der Wert gelangt niemals über Ihre Shell, Ihren Befehlsverlauf oder die eigenen Protokolle von Dinoer.

Die Unterscheidung ist wichtig, und das Wort verursacht den Schaden: Eine JSON-Datei ist nicht sicher, und es zu bezeichnen als sicher verspricht eine Garantie, die die Datei nicht bietet. Was die Zugangsdaten schützt, ist die Verschlüsselung des Verzeichnisses um sie herum, und die Tatsache, dass Dinoer den Wert niemals aus dem Prozess entfernt, der ihn benötigt.

Das ist der gesamte Mechanismus. Der Rest dieser Seite erklärt, wie man ihn einrichtet, und eine Möglichkeit, wie man Fehler machen kann.

Erstellen Sie es einmal

bash /opt/dinoer/scripts/monter-repertoire-chiffre.sh    # mount an existing encrypted directory

Um eine solche zu erstellen, übernimmt das Setup-Skript beide Modi – entweder ein einfacher Ordner oder ein mit gocryptfs verschlüsselter Ordner:

bash ~/git/Dinoer/Dinoer/scripts/configurer-repertoire-chiffre.sh

Verschlüsselter Modus erstellt den verschlüsselten Speicher und einen leeren Mount-Punkt. Nichts ist auf der Festplatte lesbar, bis Sie es gemountet haben.

Fügen Sie die Anmeldedaten darin ein

Eine einfache JSON-Datei innerhalb des gemounteten Verzeichnisses:

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

Nur die Schlüssel, auf die Ihr Szenario tatsächlich verweist, müssen existieren, mit Ausnahme von origines_autorisees – verpflichtend, ohne Ausnahme. Es listet die Hostnamen auf, gegen die diese Datei verwendet werden darf; ein Zugriff auf jede andere Domain wird verweigert, noch bevor die Datei geöffnet wird. totp_cle ist die Base32-Seed für Zwei-Faktor-Codes; ntfy_topic dient für Codes, die Ihnen zugestellt werden.

Verwenden Sie es in einem Szenario

{"type": "remplir", "selecteur": "input[name=\"username\"]",
 "valeur": "depuis_secrets", "secret_cle": "username"},
{"type": "remplir", "selecteur": "input[name=\"password\"]",
 "valeur": "depuis_secrets", "secret_cle": "password"}

secret_cle ist der Schlüssel innerhalb der entschlüsselten Datei. Das Szenario bleibt veränderbar – es nennt einen Schlüssel, niemals ein Geheimnis. Deshalb kann ein Szenario in einem öffentlichen Repository existieren, ohne dass etwas zensiert werden muss.

Niemals das tun PASS=$(jq -r ‘.password’ ~/Vaults/…/creds.json) – ein Anmeldedaten in einer Shell-Variablen befinden sich in Ihrer Prozessumgebung, in /proc, und möglicherweise in Ihrem Verlauf. Das verschlüsselte Verzeichnis existiert genau, um dies zu vermeiden.

Ein Verzeichnis pro Projekt

Zwei Möglichkeiten, je nachdem, ob es sich um einen einmaligen Vorfall oder eine Gewohnheit handelt.

# One-shot
DINOER_SECRETS_DIR=~/Vaults/MyProject /opt/dinoer/venv/bin/python3 /opt/dinoer/shot.py \
  --url … --guide-version 1.6

# Recurring — a config file at the project root
echo '{"secrets_dir": "../MyProject-secrets"}' > ~/git/MyProject/.dinoer.conf
export DINOER_CONF=~/git/MyProject/.dinoer.conf

Ein relativer Pfad secrets_dir wird relativ zum Speicherort der Konfigurationsdatei aufgelöst, sodass das gesamte System mit dem Projekt mitgeliefert wird.

--secrets <file> designates one specific credential file for a run without touching any configuration – useful when the same scenario serves several tenants.

Wenn das Verzeichnis geschlossen wird

Dinoer stoppt mit einer expliziten Fehlermeldung anstatt zu versuchen, es zu verbergen:

SecretsFermesError — exit code 42
SecretsNonConfigureError — exit code 43 (no encrypted directory configured at all)

Wenn Sie ein Techniker sind: versuchen Sie nicht, es selbst zu installieren. Fragen Sie den Bediener.

Dinoer schützt auch eigene Schreibvorgänge. Sein Operationsjournal erkennt ein geschlossenes Verzeichnis und leitet stattdessen zu einem lokalen Ausweichmechanismus um, anstatt Klartext zu schreiben, wo der verschlüsselte Speicher gespeichert werden sollte.

Der Fehler, der am meisten kostet

Ein nicht eingebundenes Verzeichnis existiert weiterhin. Es ist lediglich leer – und unverschlüsselt.

Dinoer’s interner Schutzmechanismus deckt nur die eigenen Schreibvorgänge von Dinoer ab. Er schützt nicht eine Zugangsdatei, die Sie selbst mit einem Shell-Befehl oder einem Editor erstellen, während das Verzeichnis zufällig nicht eingehängt ist. In diesem Fall schreiben Sie nicht innerhalb des Verzeichnisses: Sie schreiben daneben, in Klartext, in einem Verzeichnis, das genau richtig aussieht.

Bevor Sie eine Anmeldedatei erstellen oder aktualisieren, stellen Sie sicher, dass das Verzeichnis gemountet ist – es muss nicht leer sein. Wenn Sie sich nicht sicher sind, stoppen Sie den Vorgang und überprüfen Sie dies. Bei diesem Vorgang gibt es keine Möglichkeit, ihn rückgängig zu machen.

Kurz gesagt

Die Datei wird innerhalb des Browserprozesses gelesen, niemals über Ihre Shell.
Szenarien benennen einen Schlüssel, niemals ein Geheimnis – dadurch bleiben sie committbar.
DINOER_CONF oder --secrets für projekt- und mandantenbezogene Verzeichnisse.
Ein Exit-Code von 42 bedeutet geschlossen, ein Exit-Code von 43 bedeutet nicht konfiguriert – fragen Sie den Administrator, versuchen Sie nicht, es selbst zu mounten.
Ein nicht gemountetes Verzeichnis ist ein leeres, unverschlüsseltes Verzeichnis. Überprüfen Sie dies vor dem Schreiben.