auditd tournait, onze regles etaient armees, et rien de tout cela ne servait a grand-chose. Quatre manques, mesures avant d etre combles. 1. Rien ne sortait. Alloy ne contenait aucune reference a l audit et les cinq greffons etaient inactifs. Il lit maintenant audit.log et le pousse vers Loki — sans toucher une permission, alloy etant deja dans le groupe adm. On ecarte le greffon syslog : journald limite le debit, et une rafale d evenements est exactement le moment qui compte. 2. Aucune sonde. Elle mesure la COLLECTE, pas l armement : le nombre de regles est precisement le chiffre qui restait bon pendant la panne du 2026-08-30. Il part en perfdata, jamais en verdict. 3. Retention non declaree. Mesuree a 4,6 Mo/jour au repos ; portee de 40 a 128 Mo. Depuis (1), le local n est plus l archive mais un tampon. 4. Les regles ignoraient la cle privee de l hote. -w /etc/step/ partout, et -w /etc/step-ca/ sur la seule autorite : auditctl refuse un watch vers un chemin absent et fait echouer le chargement entier. Verifie sur l autorite seule d abord, puis 14/14 : regles armees, auditd actif, sonde a 0, et les quatorze hotes presents dans Loki sous job=audit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
10 lines
494 B
YAML
10 lines
494 B
YAML
---
|
|
# Position de ce role dans la directive d'authentification (D-38..D-41).
|
|
# Voir docs/authentification.md. Gardee par la preuve P29 : un role sans cette
|
|
# declaration, ou dont la declaration contredit son code, fait echouer le harnais.
|
|
authentification:
|
|
portee: sans-auth-humaine
|
|
raison: >-
|
|
Role-categorie du durcissement : il ne porte aucune tache et n'expose aucune
|
|
interface. Le travail est fait par les roles que son playbook applique, chacun
|
|
avec sa propre declaration.
|