Les journaux d'audit des agents doivent se fermer en cas de pression disque

Une passerelle d'agents qui continue d'agir alors qu'elle ne peut plus enregistrer durablement ces actions a rompu sa propre limite de sécurité. La pression sur le disque n'est pas un simple problème d'observabilité. Elle détermine si la prochaine requête API ou commande SSH laissera une preuve que les opérateurs pourront examiner et vérifier.

La règle sûre est simple : refusez les nouveaux appels nécessitant des identifiants avant que le rédacteur d'audit ne manque d'espace. Alertez plus tôt. Laissez le travail déjà admis se terminer uniquement si la passerelle peut encore enregistrer sa réussite ou son échec. Lorsque les ajouts échouent, conservez le texte chiffré déjà présent sur le disque et ne traitez pas le journal comme un fichier pratique que l'on pourra nettoyer plus tard.

La journalisation d'audit doit faire partie de l'autorisation

Une passerelle ne peut pas considérer la journalisation d'audit comme une opération « au mieux » si son objectif est d'établir une limite contrôlée par l'humain autour des actions d'un agent. Dès qu'un agent peut demander une requête HTTP ou une commande SSH nécessitant des identifiants, l'enregistrement de cette requête fait partie de la décision d'autorisation. Si la passerelle exécute l'action mais perd l'enregistrement, l'opérateur ne peut plus distinguer une exécution légitime d'une exécution impossible à rendre des comptes.

Les équipes confondent souvent deux pannes différentes :

• Le tableau de bord ou la vue d'activité ne peut pas se mettre à jour parce qu'un index dérivé est indisponible.
• Le journal source chiffré ne peut pas accepter l'ajout durable d'un événement.

La première panne est gênante. La seconde change la réponse à la question de savoir si la passerelle peut effectuer une nouvelle action externe. Ne leur attribuez ni le même niveau de gravité ni le même parcours de récupération.

Le modèle de Sallyport donne une forme utile à cette distinction : les journaux Sessions et Activity sont des projections d'un journal d'audit chiffré et chaîné par hachage, au lieu d'être chacun une source de vérité distincte. Une projection peut prendre du retard ou devoir être reconstruite. La chaîne chiffrée, elle, doit rester intacte.

Avant de distribuer une action, la passerelle doit donc savoir qu'elle dispose de suffisamment d'espace et que le rédacteur est en bon état pour enregistrer au moins la tentative. Après la distribution, elle doit enregistrer le résultat. Si l'action peut avoir un effet irréversible, comme modifier un réglage de production distant, enregistrez un événement d'intention durable avant la distribution, puis un événement de résultat.

Ne promettez pas une chronologie exacte que la couche de stockage ne peut pas garantir. Promettez quelque chose de plus solide et plus utile : chaque action admise possède un enregistrement durable et ordonné de son identité, de son contexte d'autorisation et de son dernier résultat connu. Si la passerelle ne peut pas tenir cette promesse, elle ne doit pas admettre d'autre action.

Les alertes et le refus sont deux états différents

Alerter au même moment que le refus garantit une mauvaise décision opérationnelle. L'opérateur découvre le problème lorsque l'agent est déjà bloqué, puis doit décider sous pression s'il faut supprimer des données, arrêter le travail ou affaiblir la règle d'audit. Une politique de stockage doit définir des états distincts et des transitions explicites.

Utilisez quatre états :

1. Normal : l'espace libre dépasse la réserve opérationnelle et un récent contrôle de durabilité a réussi.
2. Avertissement : l'espace est passé sous le seuil d'avertissement, mais la passerelle conserve toute sa réserve. Les nouveaux appels continuent et les opérateurs reçoivent une alerte.
3. Restreint : l'espace est passé sous la réserve, ou le rédacteur a rencontré une panne temporaire qui n'a pas encore atteint le seuil critique. N'admettez pas les actions qui peuvent créer de gros enregistrements ou plusieurs événements. Laissez se terminer uniquement le travail déjà admis et continuez à tester le rédacteur.
4. Refusé : la passerelle ne peut plus ajouter durablement un événement d'audit, ou l'espace restant ne couvre plus le budget minimal d'un enregistrement. Refusez tout nouvel appel nécessitant des identifiants.

Un pourcentage seul ne définit aucun de ces états. Cinq pour cent libres sur un volume de 4 To peuvent suffire. Cinq pour cent sur un petit volume peuvent disparaître pendant une exécution d'agent, une mise à jour système ou une rafale de sorties de commandes distantes. Les politiques échouent lorsqu'elles reprennent leurs chiffres d'un modèle de supervision plutôt que du comportement d'écriture réel de la passerelle.

Le seuil d'avertissement donne du temps aux opérateurs. La réserve protège la piste de preuve. L'état refusé protège l'affirmation selon laquelle toute action admise est enregistrée. Ces états ont des fonctions différentes et ne doivent donc pas partager le même seuil.

Ajoutez une hystérésis pour éviter les oscillations. Entrez dans l'état Avertissement lorsque l'espace passe sous son seuil. N'en sortez qu'après un retour au-dessus d'un seuil de récupération plus élevé et après un ajout de test durable réussi. Appliquez la même règle à l'état Restreint. Sans elle, une exécution proche de la limite peut alterner entre appels autorisés et refusés à cause de quelques blocs du système de fichiers.

Une réserve est un budget d'enregistrements, pas un optimisme sur l'espace libre

Définissez la réserve critique en calculant les enregistrements qui peuvent encore devoir exister après l'arrêt des nouvelles admissions. Le calcul n'a pas besoin d'une fausse précision. Il doit reposer sur des hypothèses prudentes que vous pourrez expliquer pendant un incident.

Posez notamment ces questions :

• Quelle est la taille maximale d'un enregistrement d'action admis, avec le contenu chiffré, les en-têtes conservés, les métadonnées de résultat et les champs de la chaîne de hachage ?
• Combien d'actions peuvent être en cours lorsque la passerelle passe à l'état Restreint ?
• Une action peut-elle produire un enregistrement de fin, d'expiration ou de nouvelle tentative ?
• Quels fichiers locaux croissent à côté du journal source, comme les métadonnées de segments, les index, les fichiers temporaires ou les rapports de plantage ?
• De quel espace le système d'exploitation et l'application ont-ils besoin pour signaler proprement la situation ?

Supposons qu'une passerelle autorise 12 actions simultanées, que chacune puisse nécessiter un événement d'intention et un événement de résultat, et que le budget prudent d'un enregistrement chiffré soit de 128 KiB. Les seuls enregistrements d'action consomment 3 MiB. Ce n'est pas la réserve. Ajoutez le plus grand lot de projection attendu, la rotation des fichiers, un marqueur d'échec et une marge de sécurité importante, puis arrondissez à une valeur facile à superviser.

Le résultat utile est une politique écrite, pas un nombre magique :

seuil d'avertissement : 2 Gio libres sur le volume d'audit
réserve critique :      512 Mio réservés aux enregistrements de fin et de récupération
budget d'admission :    256 Kio minimum disponibles par nouvelle action
seuil de récupération : 3 Gio libres et un ajout de test durable réussi

Ces valeurs sont des exemples, pas des valeurs par défaut pour tous les Mac. Une machine de développement avec de courts appels API peut justifier une réserve plus petite qu'une machine de compilation partagée où des agents autonomes exécutent de longues tâches SSH. La politique doit refléter la sortie maximale crédible enregistrée par la passerelle, et non la taille moyenne des requêtes d'une semaine calme.

La documentation actuelle d'Apple sur APFS rappelle un point souvent oublié dans les alertes en pourcentage : il faut vérifier que l'espace nécessaire à une opération précise est disponible, plutôt que chercher à déduire un total fiable à partir de l'espace libre d'une partition. APFS utilise aussi le partage d'espace, les clones et les fichiers creux. L'espace apparent et l'espace immédiatement utilisable ne se comportent donc pas toujours comme sur un ancien disque à partition fixe.

Pour un rédacteur d'audit, le contrôle doit demander : « Puis-je financer sans risque ce budget d'enregistrement maintenant ? » Il ne doit pas demander : « La barre de menus affiche-t-elle encore une quantité non nulle d'espace libre ? »

Un ajout échoué doit modifier immédiatement le comportement de la passerelle

Traitez l'échec d'un ajout comme une transition d'état, pas comme une ligne dans un journal de débogage suivie d'une nouvelle tentative. Une nouvelle tentative peut être pertinente pour une interruption temporaire. Elle ne doit jamais autoriser l'envoi d'appels non enregistrés.

Imaginez une séquence plausible. Le volume d'audit est passé sous sa réserve parce qu'un outil de développement local a créé un cache volumineux. Un agent demande à la passerelle d'effectuer une action de déploiement HTTP. La passerelle écrit l'intention, distribue la requête, reçoit une réponse positive, puis ne peut pas ajouter l'événement de fin car le système de fichiers renvoie une erreur d'espace insuffisant.

La passerelle sait alors trois choses : elle a admis l'action, le système distant a peut-être changé et l'enregistrement normal de fin manque. Elle doit conserver l'événement d'intention durable, enregistrer un marqueur d'échec si un canal sûr reste disponible, arrêter les nouveaux appels et présenter à l'opérateur l'identifiant de l'action ainsi que la panne de stockage. Elle ne doit pas relancer silencieusement la requête, car cela pourrait dupliquer l'effet distant.

Si l'ajout de l'intention échoue avant la distribution, la passerelle doit refuser l'action. Elle ne dispose d'aucune base durable pour affirmer que l'action a été demandée, approuvée ou exécutée. Cette décision peut frustrer l'utilisateur lorsque la compilation attend, mais l'autre option crée une lacune d'audit impossible à reconstituer avec certitude.

La même règle s'applique aux pannes rencontrées pendant la synchronisation. Le manuel fsync d'Apple indique que fsync pousse les données et attributs modifiés vers le stockage permanent et qu'une opération d'E/S mise en file peut échouer avec une erreur de lecture ou d'écriture. Un simple vidage ne garantit pas à lui seul l'ordre physique sur le support après une coupure de courant. Le logiciel doit donc définir sa propre limite de durabilité et ne pas confondre un ajout en mémoire avec un événement validé.

Utilisez un petit classificateur d'échec :

ajout ou synchronisation réussit             -> l'action peut continuer normalement
ajout échoue avant la distribution            -> refuser l'action
ajout échoue après la distribution            -> refuser les nouvelles actions, conserver l'intention, ouvrir un incident
la synchronisation signale une erreur d'E/S   -> refuser les nouvelles actions, conserver les fichiers, examiner le stockage
espace inférieur au budget d'admission       -> refuser cette action avant la distribution

Ne supprimez pas les anciens segments pour faire réussir l'écriture actuelle. Vous transformeriez un incident de capacité en destruction de preuves.

Le rédacteur a besoin d'une limite de validation durable

Un rédacteur qui ajoute simplement des octets à un fichier ouvert n'a pas terminé le travail d'audit. Il lui faut une limite qui indique au reste de la passerelle à quel moment l'événement est devenu partie intégrante de la chaîne durable.

Gardez cette limite petite et explicite. Un modèle possible utilise des segments ajoutés uniquement en fin de fichier, chaque événement contenant le hachage de l'événement précédent, ainsi qu'un petit manifeste de segment. L'encodage exact peut varier. L'ordre des opérations, lui, ne doit pas varier.

1. Sérialiser l'événement chiffré suivant avec le numéro de séquence N et le hachage précédent H(N-1).
2. Ajouter le cadre complet de l'événement au segment actif.
3. Synchroniser le fichier de segment et vérifier le résultat.
4. Mettre à jour le manifeste avec la séquence maximale et le hachage du segment.
5. Synchroniser le manifeste et vérifier le résultat.
6. Marquer seulement maintenant l'événement N comme validé auprès du répartiteur.

Le manifeste est essentiel, car la récupération doit répondre à la question : « Quels cadres complets comptent ? » Un cadre partiel à la fin d'un fichier après un plantage ou un disque plein n'est pas un événement validé simplement parce que certains octets ont atteint le segment. La longueur du cadre, les données d'authentification, le numéro de séquence et la séquence maximale validée du manifeste permettent de rejeter l'ambiguïté au lieu de deviner.

Ne résolvez pas cela avec un fichier JSON réécrit sur place. Le modèle paraît simple jusqu'au moment où le système de fichiers possède assez d'espace pour le nouveau fichier mais pas pour le renommage, ou lorsqu'un plantage laisse un ancien index à côté d'un segment plus récent. Des segments ajoutés en fin de fichier et un petit manifeste rendent le comportement plus facile à comprendre et à vérifier hors ligne.

Le chiffrement protège le contenu des événements, tandis que la chaîne de hachage protège leur continuité ordonnée. Aucune de ces propriétés ne signifie qu'un ajout est durable. Le rédacteur doit établir la durabilité, puis le vérificateur peut confirmer que la séquence conservée n'a pas été modifiée.

sp audit verify de Sallyport peut vérifier hors ligne sa chaîne chiffrée et chaînée par hachage sur le texte chiffré, sans clé du coffre-fort. Cette vérification est utile après un incident de stockage, car l'opérateur peut examiner les preuves conservées avant de déverrouiller le coffre-fort ou de reprendre le travail des agents.

Exécuter le test sur un volume d'audit jetable

Un test de pression disque doit démontrer le comportement à chaque transition d'état, et pas seulement montrer qu'une écriture finit par échouer. Utilisez une image disque ou un volume isolé, configurez uniquement une instance hors production pour y stocker ses données d'audit et supprimez-le après l'exercice. Ne remplissez pas le volume normal de votre Mac.

Sur macOS, créez et montez une petite image disque APFS :

hdiutil create -size 2g -fs APFS -volname AuditDrill /tmp/audit-drill.dmg
hdiutil attach /tmp/audit-drill.dmg
df -h /Volumes/AuditDrill

Le chemin de montage peut différer si un volume portant déjà ce nom existe. Confirmez-le avec df avant de modifier la configuration de test. La sortie attendue doit identifier un système de fichiers monté et afficher une capacité proche de 2 Gio :

Filesystem        Size   Used  Avail Capacity  Mounted on
/dev/diskXsY      2.0G   ...   ...     ...%    /Volumes/AuditDrill

Dirigez le stockage d'audit de l'instance de test vers ce chemin. Générez d'abord quelques actions connues comme valides. Notez leurs identifiants et exécutez le vérificateur de chaîne. Cette base est importante : une vérification ultérieure peut échouer à cause de votre configuration et non de la pression disque.

Consommez ensuite l'espace uniquement dans l'image montée :

dd if=/dev/zero of=/Volumes/AuditDrill/fill.bin bs=1048576

dd s'arrête lorsque le volume ne peut plus allouer de blocs. Il est volontairement rudimentaire. N'utilisez pas de commande créant un fichier creux pour ce test, car un tel fichier peut sembler volumineux sans consommer les blocs nécessaires au déclenchement de la condition recherchée.

Exécutez le test par étapes :

1. Remplissez jusqu'au déclenchement du seuil d'avertissement. Vérifiez que les petites actions continuent de fonctionner et que l'opérateur reçoit une seule alerte.
2. Remplissez jusqu'au déclenchement de la réserve critique. Vérifiez que la passerelle refuse les nouvelles actions selon son budget d'admission.
3. Si votre scénario le permet, admettez une action contrôlée juste avant l'état Restreint et observez si son événement final est enregistré correctement.
4. Remplissez jusqu'à l'échec réel d'un ajout ou d'une synchronisation. Vérifiez que la passerelle passe à l'état Refusé et expose la cause.
5. Arrêtez le processus, remontez l'image si nécessaire et vérifiez la chaîne chiffrée avant de supprimer le fichier de remplissage.

Le but n'est pas d'admirer une erreur ENOSPC. Il faut déterminer si la passerelle se ferme au bon moment, si ses journaux disent ensuite la vérité et si l'opérateur dispose de suffisamment de preuves pour agir sans deviner.

Tester les fenêtres temporelles difficiles, pas seulement un volume plein

Un test superficiel remplit un volume, observe un refus, libère de l'espace et conclut à la réussite. Il ignore les fenêtres temporelles qui créent les lacunes d'audit.

Testez une action dont l'effet externe se termine rapidement alors que l'enregistrement de fin d'audit est retardé. La cible contrôlée peut être un point de terminaison HTTP de test qui renvoie un identifiant de requête unique. Démarrez l'action lorsqu'il reste assez d'espace pour l'événement d'intention, puis consommez l'espace restant avant la validation du résultat. Le résultat attendu n'est pas forcément un statut net de réussite ou d'échec. La passerelle peut devoir signaler que l'état final de l'action externe doit être réconcilié.

C'est un résultat honnête. La passerelle doit afficher l'intention durable, l'identifiant distant si elle en a reçu un et la panne de stockage. Elle doit refuser les appels suivants. L'opérateur peut examiner la cible de test pour décider si l'action distante a réussi. Il ne faut pas transformer l'incertitude en seconde requête.

Testez aussi une panne pendant la rotation d'un segment d'audit. La rotation consomme des métadonnées et peut impliquer un nouveau fichier, une mise à jour de répertoire et une mise à jour du manifeste. Une conception qui résiste à un ajout ordinaire mais échoue pendant la rotation ne résout pas la pression de stockage.

Testez le redémarrage. Après un échec d'ajout, fermez uniquement l'instance de test jetable, puis redémarrez-la avec le volume toujours plein. Elle doit rester dans un état de refus sûr au lieu de supposer qu'un processus neuf signifie que le stockage est sain. Libérez une quantité mesurée d'espace, redémarrez et confirmez qu'elle vérifie la dernière séquence validée avant d'ouvrir un nouveau segment.

Injectez enfin une panne de permissions ou d'E/S si votre environnement le permet. L'épuisement de capacité et une erreur d'E/S exigent la même réponse immédiate lorsqu'ils bloquent les écritures d'audit durables, mais l'enquête diffère. Libérer de l'espace peut résoudre ENOSPC. Cela ne répare ni un volume défaillant, ni une erreur du système de fichiers, ni un périphérique de stockage interrompu.

Conserver le texte chiffré avant toute réparation

Lorsqu'une écriture d'audit échoue, on cherche naturellement à nettoyer pour débloquer l'agent. C'est ainsi qu'un incident récupérable devient contesté. Préservez d'abord, réparez ensuite.

Gelez le répertoire d'audit concerné. Ne compactez pas les segments, ne régénérez pas le manifeste, ne tronquez pas le dernier fichier, ne faites pas pivoter le matériel de chiffrement et ne relancez pas une action pour rendre la vue d'activité complète. Si le périphérique semble défaillant, copiez le répertoire avec une méthode qui signale les erreurs de lecture, puis travaillez sur la copie. L'original peut être la seule preuve des enregistrements réellement écrits.

Votre liste de conservation doit répondre à cinq questions :

• Quel segment et quel manifeste étaient actifs lors du premier échec d'écriture ?
• Quelle est la dernière séquence acceptée par le vérificateur ?
• Quelles actions admises possèdent un enregistrement d'intention mais aucun résultat ?
• Quels systèmes externes peuvent confirmer ces actions indépendamment ?
• Un processus a-t-il modifié le répertoire d'audit après la panne ?

Un résultat de vérification de chaîne est une preuve, pas une instruction de réparation. Si la vérification s'arrête à la séquence 8 412, conservez ce fait. Ne tronquez pas automatiquement un cadre partiel ultérieur, sauf si votre procédure documentée le prévoit et que l'artefact original a été conservé. Un cadre chiffré partiel peut être attendu après un plantage, mais il peut aussi révéler un défaut du rédacteur. Les octets originaux sont nécessaires pour faire la différence.

C'est une autre raison de séparer le journal source du journal visible par l'utilisateur. Une projection peut afficher des lignes incomplètes jusqu'à sa reprise. Cela reste acceptable si elle indique à l'opérateur qu'elle rattrape son retard. La reconstruction ou la dissimulation des vues dérivées ne doit jamais réécrire les preuves sources pour rendre un écran plus propre.

Les alertes doivent indiquer la décision prise par la passerelle

« Disque presque plein » est une alerte faible pour une passerelle d'actions. Elle informe d'un état de la machine, mais pas de la permission d'activité des agents, du risque pour les preuves d'audit ni de ce qui a changé depuis la notification précédente.

Émettez une alerte lorsque la passerelle entre dans les états Avertissement, Restreint, Refusé et Récupération vérifiée. Incluez les informations utiles à l'action :

état : refusé
cause : ajout d'audit échoué avec ENOSPC
chemin d'audit : /configured/audit/path
octets libres observés : 41 943 040
réserve critique : 536 870 912
dernière séquence validée : 8412
actions admises non résolues : 1
nouveaux appels nécessitant des identifiants : refusés
traitement des actions existantes : l'enregistrement de fin n'a pas pu être validé
heure de la première panne : 2026-07-22T14:37:18Z

Ne placez pas de secrets, de corps de requêtes ou d'identifiants dans cette alerte. Elle a besoin d'identifiants permettant de faire le lien avec les preuves chiffrées, pas d'une seconde copie de données sensibles dispersée dans les systèmes de notification.

Évitez une alerte à chaque mesure de faible espace. Alertez lors de l'entrée dans l'état Restreint ou Refusé, puis envoyez un rappel uniquement si la condition persiste ou s'aggrave. Le passage de Normal à Avertissement peut produire un ticket ou une notification locale. Le passage à Refusé est un incident opérationnel, car la passerelle a délibérément arrêté les nouvelles actions externes.

L'alerte doit également indiquer si la passerelle protège les enregistrements déjà admis. Ce détail modifie la réponse. Si elle a assez d'espace pour terminer les enregistrements en cours, les opérateurs peuvent laisser ces exécutions se stabiliser tout en libérant de l'espace. Si un ajout a déjà échoué après la distribution, ils doivent examiner les actions non résolues avant de reprendre l'automatisation.

La récupération doit prouver que le rédacteur est de nouveau sain

Libérer de l'espace est nécessaire, mais cela ne prouve pas que le rédacteur d'audit peut revenir à l'état Normal. La procédure de récupération doit faire mériter cette transition à la passerelle.

Préservez d'abord les artefacts de l'incident et consignez la cause de la libération d'espace. Supprimer un cache de compilation sans rapport avec l'audit est différent de supprimer des fichiers d'audit, et le compte rendu doit le préciser. Vérifiez ensuite la chaîne conservée hors ligne. Si la vérification échoue, maintenez la passerelle dans l'état Refusé et examinez les preuves avant d'autoriser de nouvelles actions.

Exécutez ensuite un ajout de récupération limité. La passerelle doit écrire un événement identifiant l'état Refusé précédent, l'ajouter à un nouveau segment ou à un segment de récupération documenté, le synchroniser, mettre à jour son manifeste et vérifier la séquence obtenue. Elle ne doit pas reprendre silencieusement au milieu du segment qui a échoué.

Ce n'est qu'après la réussite de cet ajout qu'elle doit reconstruire ou rattraper ses journaux dérivés. Cette opération peut échouer indépendamment. Dans ce cas, conservez les preuves sources et signalez que la vue est incomplète. Ne niez pas qu'une action a eu lieu simplement parce qu'une ligne d'activité n'est pas encore apparue.

Appliquez ensuite le seuil de récupération. Si l'avertissement est configuré à 2 Gio, la réserve critique à 512 Mio et la récupération à 3 Gio, ne rouvrez pas les appels à 600 Mio simplement parce que le rédacteur a réussi un ajout. Le seuil supérieur évite une rechute immédiate et laisse le temps de trouver la source de la pression.

Un test de pression de stockage est utile lorsqu'il modifie une décision concrète : le point exact où votre passerelle cesse d'autoriser du nouveau travail. Écrivez ce point, testez-le sur un volume jetable et traitez chaque ajout échoué comme une preuve à préserver, jamais comme un encombrement à supprimer.