Geheimnisse für unbeaufsichtigte Skripte speichern: systemd-Credentials, DPAPI, macOS-Keychain – und was man vermeiden sollte

Ziel

Einem unbeaufsichtigten Skript oder Dienst das benötigte Geheimnis zur Laufzeit bereitstellen, ohne es in der Umgebung anderer Prozesse, in einer Prozessliste oder in einer für alle lesbaren Datei offenzulegen.

Voraussetzungen

systemd 247+ für LoadCredential=, 250+ für systemd-creds und LoadCredentialEncrypted= (die Verschlüsselung nutzt einen aus dem TPM2 abgeleiteten Schlüssel, den Host-Schlüssel /var/lib/systemd/credential.secret oder beides; ein TPM ist also nicht zwingend erforderlich); PowerShell 5.1+ für Export-Clixml oder das Modul Microsoft.PowerShell.SecretManagement als umfassendere Abstraktion für Secret Stores; macOS mit dem Kommandozeilenwerkzeug security (integriert).

Schritte

1. Linux/systemd: als root systemd-creds encrypt --name=mysecret plaintext.txt /path/mysecret.cred ausführen, danach plaintext.txt löschen und die Datei im Abschnitt [Service] mit LoadCredentialEncrypted=mysecret:/path/mysecret.cred einbinden. Der eingebettete Name muss mit der Credential-ID übereinstimmen; ohne --name= wird er aus dem Namen der Ausgabedatei übernommen. Der Dienst liest den entschlüsselten Wert unter $CREDENTIALS_DIRECTORY/mysecret. Dabei handelt es sich um eine schreibgeschützte Kopie, auf die nur der Dienst zugreifen kann (sie funktioniert mit DynamicUser=), statt um eine Umgebungsvariable, die jeder Kindprozess erbt.
2. Windows: Get-Credential | Export-Clixml -Path secret.xml serialisiert ein Credential-Objekt. Laut der Dokumentation von Microsoft beruht dies auf der Windows Data Protection API (DPAPI); die entstandene Datei lässt sich daher nur mit demselben Benutzerkonto auf demselben Rechner entschlüsseln, auf dem sie erstellt wurde. Beim Kopieren auf einen anderen Host oder zu einem anderen Benutzer wird sie unbrauchbar. Sie ist deshalb unter dem Konto zu erstellen, das sie später lesen soll. Das gilt nur unter Windows: PowerShell unter Linux/macOS schreibt das Passwort lediglich codiert, nicht verschlüsselt. Import-Clixml -Path secret.xml liest die Datei im Skript wieder ein. Für benannte Secrets benötigt Microsoft.PowerShell.SecretManagement eine Vault-Erweiterung wie Microsoft.PowerShell.SecretStore, die standardmässig nach einem Passwort fragt, solange ihre Authentifizierung nicht umkonfiguriert wird.
3. macOS: Ein Geheimnis wird einmalig mit security add-generic-password -a "myservice" -s "myservice-token" -T /usr/bin/security -w gespeichert. Steht -w am Schluss ohne Wert, erfolgt eine Eingabeaufforderung, sodass das Geheimnis weder in ps noch in der Shell-History erscheint. Ein Skript ruft es mit security find-generic-password -a "myservice" -s "myservice-token" -w ab, was ausschliesslich den Wert ausgibt. Die Keychain muss entsperrt sein; die Login-Keychain eines Benutzers ist das in SSH-Sitzungen oder für LaunchDaemons oft nicht. Fehlt ein Werkzeug in der Zugriffsliste des Eintrags (-T), erscheint eine GUI-Abfrage.
4. In allen drei Fällen ist die Datei bzw. der Credential Store auf das eigene Konto des Dienstes zu beschränken (Linux: sich auf das dienstspezifische Verzeichnis von LoadCredential= stützen statt auf einen gemeinsamen Pfad; eine manuell angelegte Datei sollte trotzdem chmod 0600 erhalten).

Erwartetes Ergebnis

Das Geheimnis ist zur Laufzeit für das vorgesehene Dienstkonto lesbar und für kein anderes Konto. Eine Inspektion des laufenden Prozesses mit ps oder über /proc/<pid>/environ zeigt kein Geheimnis im Klartext, und ein Beenden und Neustarten des Prozesses erfordert keine erneute manuelle Eingabe.

Grenzen und Prüfbasis

Keiner dieser Mechanismen hindert einen Prozess, der mit denselben Rechten wie der Dienst selbst läuft, oder einen Benutzer, der sudo bzw. Run as Administrator nutzen kann, daran, das Geheimnis nach der Entschlüsselung im Klartext zu lesen. Vermieden wird dagegen, das Geheimnis in einer Umgebungsvariable abzulegen (für jeden Kindprozess sichtbar und oft protokolliert), in einem Kommandozeilenargument (sichtbar in ps/Task-Manager und in der Shell-History) oder in einer einfachen Datei mit Standardberechtigungen.