Journalisation depuis les scripts d'administration : logger et systemd-cat sous Linux, Write-EventLog/New-WinEvent et Start-Transcript sous Windows

Objectif

Envoyer la progression et le résultat d'un script d'administration vers un emplacement de journalisation durable et interrogeable, adapté à la plateforme, sans jamais y écrire d'identifiant, de jeton ou de mot de passe.

Prérequis

Sous Linux : logger (util-linux), ou systemd-cat sur un hôte systemd. Sous Windows : pour Write-EventLog, qui n'existe que dans Windows PowerShell 5.1 et a été supprimé à partir de PowerShell 6, une source de journal d'événements personnalisée déjà enregistrée (enregistrement unique, effectué au préalable dans une session élevée) ; ou New-WinEvent (5.1 et 7.x) avec un manifeste de fournisseur enregistré.

Étapes

1. Sous Linux, étiqueter chaque message afin de pouvoir le filtrer ensuite : logger -t my-admin-script "starting cleanup of /var/tmp". La page de manuel logger(1) décrit cet utilitaire comme un moyen d'ajouter des entrées au journal système, consultables ensuite avec journalctl -t my-admin-script ou dans /var/log/syslog, selon la configuration de journalisation du système.
2. Lorsque toute la sortie standard et la sortie d'erreur du script doivent aller dans le journal sans multiplier les appels à logger, lancer le script via systemd-cat -t my-admin-script ./script.sh. systemd-cat est décrit comme connectant « the standard input and » output d'un processus, ou filtrant un pipeline, au journal ; c'est pratique pour encapsuler un script existant sans le modifier.
3. Sous Windows PowerShell 5.1, si une source du journal d'événements est déjà enregistrée pour le script, utiliser Write-EventLog -LogName Application -Source MyAdminScript -EventId 1000 -Message "..." pour produire des entrées structurées sur lesquelles un outil de supervision peut déclencher des alertes. Write-EventLog exige que la source soit créée à l'avance (New-EventLog, exécuté une seule fois, en session élevée) ; ne pas créer la source dans le chemin d'exécution normal et non interactif du script. Sous PowerShell 7, utiliser plutôt New-WinEvent ou [System.Diagnostics.EventLog]::WriteEntry(...).
4. Pour une journalisation plus récente, basée sur les événements et liée à un fournisseur ETW et à son manifeste, utiliser New-WinEvent -ProviderName <name> -Id <id> -Payload <values>, qui écrit un événement structuré via le fournisseur enregistré, et non une entrée de journal classique reposant sur une source.
5. Pour obtenir une transcription complète et non filtrée de tout ce que la session PowerShell du script a affiché (utile pour le débogage a posteriori d'une exécution non interactive), encadrer le script avec Start-Transcript -Path $logPath; ...; Stop-Transcript. Comme une transcription capture littéralement tout ce qui est affiché dans l'hôte, appliquer à son fichier de sortie le même contrôle d'accès qu'aux autres journaux du script. La transcription et la journalisation des blocs de script peuvent aussi être activées sur toute la machine par stratégie de groupe : un secret écrit en dur dans le script ou renvoyé à l'hôte peut donc se retrouver dans une transcription ou un journal d'événements, même sans Start-Transcript.
6. Avant de journaliser une valeur, la comparer à une courte liste d'exclusion des noms de variables que le script utilise pour des secrets (password, token, key, connectionstring) ; remplacer ces valeurs par un marqueur fixe avant l'appel de journalisation, sans jamais compter sur le fait de penser à les omettre au cas par cas.

Résultat attendu

L'exécution d'un script peut être reconstituée après coup à partir de journalctl ou de l'Observateur d'événements sans le relancer, et l'examen du journal de n'importe quelle exécution ne montre aucun identifiant en clair, quoi que le script ait manipulé.

Limites et base de vérification

La destination exacte de logger (démon syslog, journal, ou les deux) dépend de la configuration de journalisation de l'hôte, et non de logger lui-même. Write-EventLog échoue si la source n'a jamais été enregistrée ou si elle l'a été sous un autre nom de journal ; après une exécution, vérifier avec Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MyAdminScript'} -MaxEvents 1, et ne pas se contenter de la valeur de retour de l'appel d'écriture. Start-Transcript ne masque rien : une commande qui affiche un secret pendant une session transcrite apparaît quand même dans le fichier de transcription.