Sujet : logging
-
Journaux d'audit : quoi consigner, comment les garder intacts et qui peut les lire
Un journal d'audit indique qui a fait quoi, sur quel objet, quand et avec quel résultat ; l'application l'alimente pour chaque action pertinente pour la sécurité, le sépare des journaux de débogage, le protège contre les altérations en transférant rapidement ses entrées vers un stockage en ajout seul ou à écriture unique, et n'en autorise la lecture que dans le cadre d'accès restreints et consignés.
-
Politique sudo en fichiers drop-in dans /etc/sudoers.d, vérifiée avec visudo -c
Ajouter une règle ciblée sous forme de fichier distinct dans /etc/sudoers.d, validé par visudo avant prise d'effet, rend la politique sudo auditable et évite qu'une erreur de syntaxe ne prive tout le monde d'accès. Cette méthodologie traite aussi du risque des règles NOPASSWD trop larges et de l'endroit où sudo journalise ses décisions.
-
Journalisation depuis les scripts d'administration : logger et systemd-cat sous Linux, Write-EventLog/New-WinEvent et Start-Transcript sous Windows
Chaque plateforme permet d'envoyer la sortie d'un script d'administration à un emplacement où une personne ou un autre outil la retrouvera plus tard, ce qui est distinct d'une simple écriture sur stdout : logger(1) ou systemd-cat vers le journal système sous Linux, le journal d'événements Windows via Write-EventLog (Windows PowerShell 5.1 uniquement) ou New-WinEvent, et Start-Transcript pour une capture brute de session. Aucun de ces mécanismes ne doit jamais recevoir de secret.
-
Échantillonnage des journaux pour les événements à fort volume : conserver toutes les erreurs, échantillonner les lignes répétitives
L'échantillonnage rejette volontairement une fraction d'événements de journal similaires ; les formes utiles sont le un-sur-N, la rafale-puis-taux par période, les règles par niveau qui laissent intactes les alertes et les erreurs, et l'échantillonnage en pipeline indexé sur un identifiant de requête afin qu'une requête entière soit conservée ou rejetée en bloc, le taux appliqué étant inscrit dans les événements conservés.
-
Transfert et collecte distante avec journald : ForwardToSyslog, systemd-journal-upload/-remote et limitation de débit
journald peut transmettre ses entrées à un démon syslog local avec ForwardToSyslog=, ou les envoyer directement en HTTPS avec systemd-journal-upload vers un récepteur systemd-journal-remote, qui écrit ses propres fichiers de journal. Les deux voies sont soumises à la limitation de débit par service de journald : au-delà d'un seuil de rafale, les messages excédentaires sont abandonnés et seul leur nombre est consigné.
-
Séquences d'échappement de terminal dans une sortie non fiable : pourquoi les octets bruts ne devraient pas atteindre un terminal ou un visualiseur de journaux
Le texte affiché dans un terminal peut contenir des séquences de contrôle qui déplacent le curseur, masquent des lignes, changent le titre de la fenêtre ou, dans certains terminaux, créent des liens cliquables. La sortie non fiable provenant d'outils, de journaux ou de fichiers devrait être neutralisée avant affichage, tant pour les personnes qui opèrent le système que pour les agents qui lisent des captures de terminal.
-
Windows Event Forwarding : abonnement initié par la source, wecutil et groupe EventLog Readers
Dans un abonnement WEF initié par la source, chaque ordinateur source récupère sa configuration auprès d'un collecteur via une stratégie de groupe et lui envoie les événements correspondants. wecutil gère l'abonnement sur le collecteur, et le transfert du journal Security exige d'ajouter le compte NETWORK SERVICE au groupe EventLog Readers sur chaque source.
-
Atténuer les attaques par force brute avec fail2ban : jails, backends, état et débannissement de sa propre adresse
fail2ban surveille les journaux à la recherche d'échecs d'authentification répétés et bannit la source par une action de pare-feu ; la configuration doit se placer dans des surcharges jail.local plutôt que dans le jail.conf fourni par le paquet, et ignoreip évite qu'une adresse d'administration ne se bannisse elle-même.
-
Où Solaris conserve ses journaux, et utilisation de fmadm/fmdump pour les pannes matérielles et logicielles
Les messages système généraux s'accumulent dans /var/adm/messages (ce que restitue dmesg), chaque instance SMF consigne la sortie de sa méthode de démarrage sous /var/svc/log/, et la Fault Management Architecture (fmadm, fmdump) diagnostique séparément les pannes matérielles et certaines pannes logicielles dans un enregistrement corrélé identifié par un UUID.
-
Incident LiteLLM d’octobre 2026 : exposition confirmée d’un jeton et précautions pour les journaux de passerelle
Le bilan ultérieur de LiteLLM a remplacé l’hypothèse initiale d’un vol dans les journaux par des preuves d’exposition d’un jeton via une API d’Agent Platform. L’incident illustre néanmoins pourquoi les identifiants d’agents, les corps de réponse et les automatisations privilégiées doivent avoir des périmètres d’accès distincts.
-
Transférer syslog avec rsyslog en TCP via une file d'attente assistée par disque
Un fichier drop-in dans /etc/rsyslog.d/ permet de transférer tous les messages vers un collecteur central en TCP, tandis qu'une file d'attente d'action assistée par disque les met en tampon localement : une panne du collecteur ou une coupure réseau n'entraîne donc pas de perte de logs. rsyslogd -N1 valide la syntaxe avant l'application de la modification.
-
Où les systèmes d'exploitation stockent leurs journaux et comment les interroger
Un agent qui diagnostique un service doit savoir quel sous-système contient le journal avant de pouvoir le lire. Cette référence présente le stockage des journaux et la commande d'interrogation pour Linux (journald/rsyslog), le journal unifié de macOS, l'Event Log de Windows, le rapport d'erreurs d'AIX et les fichiers syslog de FreeBSD.
-
Journaux d'accès aux données personnelles : enregistrer qui a lu quel enregistrement
Un journal d'accès aux données personnelles enregistre les lectures, pas seulement les écritures : acteur, sujet, objet, motif et horodatage, émis au niveau du chemin de lecture applicatif et rapproché de la journalisation des instructions au niveau de la base de données pour les chemins qui la contournent ; il doit répondre à des questions centrées sur le sujet, comme qui a consulté l'enregistrement de cette personne au cours de l'année écoulée.
-
Minimiser les données personnelles dans les preuves
Conserver l'enregistrement de preuve le plus restreint possible pour reproduire une décision, en excluant les données d'identité et de charge utile sans rapport.
-
La minimisation des données comme discipline de schéma et de journalisation
Ne stocker que les données personnelles dont une fonctionnalité a besoin, à la précision la plus grossière qui la satisfait, et tenir les identifiants hors des journaux en n'autorisant explicitement que certains champs ; chaque colonne, chaque champ de journal et chaque magasin dérivé qui porte des données personnelles est une décision de conception dotée d'une finalité, d'un responsable et d'une échéance, et non un choix par défaut.
-
Rétention des journaux et budget disque sur un hôte : journald, logrotate et dimensionnement du journal d'événements Windows
`SystemMaxUse` de journald plafonne l'espace disque occupé par le journal lui-même, les paramètres `maxage` et `rotate` de logrotate limitent les fichiers archivés ailleurs, et `wevtutil sl` fixe la taille maximale d'un journal d'événements Windows. Ces trois réglages relèvent du budget disque, choisi par l'opérateur ou par un agent ; la durée de conservation imposée par des obligations légales ou organisationnelles est une décision de politique que cet article ne tranche pas.
-
Interroger le journal systemd avec journalctl : unité, démarrage, priorité, plage horaire et sortie JSON
journalctl permet de filtrer le journal systemd par unité, démarrage, priorité et plage horaire, et de produire une sortie exploitable par un script, à condition que le journal soit conservé après un redémarrage. Cette méthodologie décrit les requêtes précises, le stockage persistant et les limites de taille dans journald.conf.
-
Caviarder les secrets avant l'écriture des journaux
Journaliser un enregistrement de diagnostic construit à partir d'une liste blanche de champs plutôt que les requêtes brutes de l'outil, et vérifier le caviardage à chaque point de sortie.
-
JSON Lines : une valeur par ligne pour les journaux, les jeux de données et les réponses en flux
JSON Lines (aussi appelé NDJSON) place une valeur JSON complète par ligne, en UTF-8 sans marque d'ordre des octets et terminée par un saut de ligne ; les fichiers peuvent être complétés par ajout, découpés, parcourus avec grep et compressés, et un flux tronqué ne perd que sa dernière ligne. Les séquences de texte JSON de la RFC 7464 ajoutent un octet séparateur d'enregistrement pour la récupération. Utiliser l'un ou l'autre plutôt qu'un grand tableau JSON unique chaque fois que des enregistrements sont produits ou consommés un par un.
-
Le framework d'audit Linux : écrire des règles auditd, surveiller des fichiers et relire les résultats
Les règles auditd se placent dans /etc/audit/rules.d et sont fusionnées par augenrules --load ; les règles d'appel système et de surveillance alimentent ausearch et aureport, et le passage de l'indicateur enabled à 2 rend la configuration en cours immuable jusqu'au prochain redémarrage.
Lisible par machine : JSON