Qui a changé quoi : une piste d'audit pour l'hôte
Sur un hôte partagé, la question la plus dure après un incident n'est pas ce qui a cassé ; c'est qui a changé quoi avant la casse. Atlas écrit une piste d'audit des opérations critiques : l'acteur, l'action, l'heure et le résultat, gardée sur l'hôte à deux endroits.
Pourquoi qui a fait quoi reste souvent sans réponse
L'outillage de base disperse les preuves. Le journal de tâches PVE connaît certaines opérations, l'historique shell d'autres, et les modifications de configuration souvent rien du tout. Reconstituer une soirée, c'est recoudre des horodatages entre les trois.
L'accès root partagé aggrave tout. Quand plusieurs personnes peuvent agir en root, les actions n'ont plus d'auteur ; les fichiers d'historique peuvent être édités par le même pouvoir qui a fait le changement.
Et la plupart des audits arrivent au pire moment : après un incident, sous pression, quand la personne qui connaît la réponse est peut-être celle qui l'a causé.
Reconstituer un incident à la main
Sans piste, l'enquête habituelle ressemble à ceci :
Lire le journal de tâches PVE autour de la fenêtre de l'incident et noter ce qu'il a vu.
Fouiller les historiques shell de l'hôte en espérant que personne n'a utilisé un compte partagé.
Parcourir journalctl sur la même fenêtre et tenter de faire coïncider les horodatages.
Comparer les configurations actuelles à la dernière sauvegarde pour trouver les modifications silencieuses.
Demander dans le chat d'équipe qui a touché l'hôte ce jour-là.
Écrire une note d'incident bâtie sur probablement, et passer à autre chose.
Ce qu'Atlas consigne
Les opérations critiques laissent une piste au moment où elles se produisent, pas un mystère après coup.
Les actions critiques, consignées
Les opérations qui changent ou mettent en danger le système, travaux destructifs de stockage et de réseau, arrêts de processus, actions sensibles aux privilèges, s'écrivent dans la piste pendant qu'elles tournent.
Acteur, action, heure, résultat
Chaque entrée répond d'un coup aux quatre questions de l'incident : qui l'a déclenchée, ce qui a exactement tourné, quand, et si cela a réussi.
Deux copies, résistantes à la falsification
Les entrées vont dans le journal système, que les utilisateurs non root ne peuvent pas réécrire, et dans un fichier séparé. Effacer ses traces suppose de vaincre les deux.
Les rôles Proxmox, respectés
Atlas n'invente pas son propre monde de permissions. Qui peut faire quoi vient des utilisateurs et rôles Proxmox, et la piste correspond à de vraies identités.
Aucun secret dans le journal
Mots de passe et jetons ne sont jamais écrits. La piste consigne qu'une action a eu lieu, pas les identifiants qui la portaient.
Les constats sont remontés
La sentinelle Watch signale les constats critiques par mail au moment où ils surviennent ; la piste se lit avant l'incident, pas seulement après.
Questions fréquentes
- Qu'est-ce qui est exactement consigné ?
- Les opérations critiques et sensibles aux privilèges : changements destructifs de stockage et de réseau, signaux de processus, actions au niveau des services et autres du même ordre. Les lectures de routine ne font pas de bruit dans la piste.
- Un admin peut-il effacer ses traces ?
- La piste est tenue en double : dans le journal système, qu'on ne réécrit pas sans falsification au niveau root, et dans un fichier séparé. Éditer l'histoire en silence cesse d'être trivial.
- Les mots de passe ou corps de requêtes sont-ils stockés ?
- Non. Les secrets ne sont jamais écrits dans la piste ; les entrées portent l'acteur, l'action, l'heure et le résultat.
- Où vit le journal ?
- Sur l'hôte, dans le journal système plus un fichier séparé. Rien n'est expédié vers un service externe.
- Utilise-t-il les comptes Proxmox ?
- Oui. Atlas reflète les utilisateurs, groupes et rôles Proxmox au lieu d'inventer les siens ; les entrées d'audit correspondent aux identités déjà gérées dans Proxmox.
- La journalisation ralentit-elle l'hôte ?
- Non. Seules les opérations critiques sont consignées, pas chaque clic ; la piste tient en quelques lignes par action risquée.
Fiches liées
- J'ai retiré l'accès et la personne est toujours dedans : une session n'est pas une permission Vous avez retiré la permission, vous avez même désactivé le compte, et la personne peut encore agir. Rien n'est cassé : retirer un accès et mettre fin à une session sont deux actions distinctes.
- Quitter root : la décision que personne n’impose et qui rapporte le plus Travailler en root n’explose pas un jour. Cela casse discrètement deux choses : ce que le journal désigne, et l’endroit où s’arrête un mauvais clic. Le remède n’est pas de désactiver root, mais de lui retirer le travail quotidien.
- Le journal d’audit : la réponse à « qui l’a fait », pas à « que s’est-il passé » La supervision dit ce qui s’est passé, le journal d’audit dit qui l’a fait. Sa valeur apparaît les jours qu’on n’espère jamais, et si vous ne l’avez pas ce jour-là, il n’a jamais existé.