Logging aus Admin-Skripten: logger und systemd-cat unter Linux, Write-EventLog/New-WinEvent und Start-Transcript unter Windows

Ziel

Fortschritt und Ergebnis eines Admin-Skripts an einen dauerhaften, abfragbaren und zur Plattform passenden Log-Speicherort senden, ohne dass je ein Zugangsdatum, Token oder Passwort in dieses Log geschrieben wird.

Voraussetzungen

Unter Linux logger (util-linux) oder auf einem systemd-Host systemd-cat. Unter Windows eine bereits vorhandene benutzerdefinierte Ereignisprotokoll-Quelle (einmalig im Voraus in einer Sitzung mit erhöhten Rechten registriert) für Write-EventLog, das nur in Windows PowerShell 5.1 existiert und ab PowerShell 6 entfernt wurde, oder New-WinEvent (5.1 und 7.x) mit einem registrierten Provider-Manifest.

Schritte

1. Unter Linux jede Meldung mit einem Tag versehen, damit sie später gefiltert werden kann: logger -t my-admin-script "starting cleanup of /var/tmp". Laut logger(1) legt das Werkzeug Einträge im Systemlog an. Diese lassen sich anschliessend mit journalctl -t my-admin-script oder, je nach Logging-Konfiguration des Systems, aus /var/log/syslog lesen.
2. Soll die gesamte stdout-/stderr-Ausgabe eines Skripts ins Journal gelangen, ohne überall logger-Aufrufe einzufügen, das Skript mit systemd-cat -t my-admin-script ./script.sh ausführen. systemd-cat verbindet laut Beschreibung Standardeingabe und -ausgabe ("the standard input and" output) eines Prozesses mit dem Journal oder filtert eine Pipeline dorthin. Das eignet sich, um ein bestehendes Skript ohne Änderung einzubinden.
3. Unter Windows PowerShell 5.1, sofern für das Skript bereits eine registrierte Ereignisprotokoll-Quelle existiert, mit Write-EventLog -LogName Application -Source MyAdminScript -EventId 1000 -Message "..." strukturierte Einträge schreiben, auf die ein Monitoring-Werkzeug alarmieren kann. Write-EventLog setzt voraus, dass die Quelle vorab angelegt wurde (New-EventLog, einmalig mit erhöhten Rechten). Die Quelle darf nicht im normalen, unbeaufsichtigten Ablauf des Skripts erstellt werden. Unter PowerShell 7 stattdessen New-WinEvent oder [System.Diagnostics.EventLog]::WriteEntry(...) verwenden.
4. Für neueres, ereignisbasiertes Logging mit ETW-Provider und Manifest New-WinEvent -ProviderName <name> -Id <id> -Payload <values> verwenden. Dies schreibt ein strukturiertes Ereignis über den registrierten Provider statt eines klassischen, quellenbasierten Logeintrags.
5. Für ein vollständiges, ungefiltertes Transkript von allem, was die PowerShell-Sitzung eines Skripts ausgegeben hat (nützlich für die nachträgliche Fehlersuche bei einem unbeaufsichtigten Lauf), den Ablauf in Start-Transcript -Path $logPath; ...; Stop-Transcript einfassen. Da ein Transkript buchstäblich alles erfasst, was an den Host ausgegeben wird, die Ausgabedatei mit derselben Zugriffskontrolle schützen wie die übrigen Logs des Skripts. Transkription und Script-Block-Logging lassen sich zudem per Gruppenrichtlinie rechnerweit aktivieren. Ein Geheimnis, das als Literal im Skript steht oder an den Host ausgegeben wird, kann deshalb auch ohne Start-Transcript in einem Transkript oder Ereignisprotokoll landen.
6. Vor dem Loggen jeden Wert gegen eine kurze Sperrliste der Variablennamen prüfen, die das Skript für Geheimnisse verwendet (password, token, key, connectionstring). Diese Werte vor dem Log-Aufruf durch einen festen Platzhalter ersetzen. Sich nie darauf verlassen, im Einzelfall daran zu denken, sie wegzulassen.

Erwartetes Ergebnis

Der Ablauf eines Skriptlaufs lässt sich nachträglich aus journalctl bzw. der Ereignisanzeige rekonstruieren, ohne das Skript erneut auszuführen. Eine Durchsicht des Logs eines beliebigen Laufs zeigt kein Zugangsdatum im Klartext, unabhängig davon, womit das Skript gearbeitet hat.

Grenzen und Prüfbasis

Das genaue Ziel von logger (Syslog-Daemon, Journal oder beides) hängt von der Logging-Konfiguration des Hosts ab, nicht von logger selbst. Write-EventLog schlägt fehl, wenn die Quelle nie registriert oder unter einem anderen Lognamen registriert wurde. Nach einem Lauf mit Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MyAdminScript'} -MaxEvents 1 prüfen und sich nicht nur auf den Rückgabewert des Schreibaufrufs verlassen. Start-Transcript schwärzt nichts: Ein Befehl, der in einer aufgezeichneten Sitzung ein Geheimnis ausgibt, erscheint trotzdem in der Transkriptdatei.