Les journaux d'audit doivent enregistrer avant l'exécution, pas après
Oubliez ce que vous croyez savoir sur les journaux d'audit. Si votre couche de gouvernance écrit son journal après le retour de l'appel, l'enregistrement est déjà à moitié fictif. La ligne manquante pourrait signifier « jamais autorisé », ou « autorisé, puis le processus est mort avant que le journal n'atteigne le disque ». Impossible de trancher. C'est cette ambiguïté qui a poussé Marcin Marzeta à concevoir obstat, une petite bibliothèque Python qui inverse cet ordre : les décisions sont écrites sur disque—via un fsync—avant l'exécution du corps de la fonction.
Un seul fsync qui change tout
La plupart des piles de journalisation regroupent, différent ou laissent le framework décider du moment du vidage. obstat fait le contraire. Lorsque @guard(resource="doc:{doc_id}") enveloppe delete_document, la bibliothèque écrit l'enregistrement de la décision, appelle fsync, puis n'exécute le corps de la fonction qu'ensuite. Si le processus s'interrompt en cours d'appel, le journal indique toujours ce qui a été autorisé, par qui et pour quelle ressource—rien ne peut prétendre que « rien n'a été consigné ». Le reste de la bibliothèque est une commodité ; cette garantie unique est ce sur quoi les examinateurs s'appuieront.
Le test qui prouve la promesse
L'affirmation ne se limite pas à un paragraphe : c'est un test unitaire qui échoue lorsque la garantie n'est plus respectée. À l'intérieur de la fonction protégée, record.read() récupère le journal directement depuis le disque. Si quoi que ce soit était en mémoire tampon, différé ou écrit après coup, le test afficherait une liste vide. Si l'écriture est déplacée d'une ligne plus tard, l'assertion assert len(decisions) == 1 s'effondre. Cette fragilité est le point clé : la propriété est exprimée dans un code qui échoue dès qu'elle n'est plus vraie.
Pourquoi les règles au niveau des ressources comptent
Les niveaux traditionnels comme LIRE/ÉCRIRE/DÉTRUIRE ne peuvent pas capturer des nuances telles que « peut modifier son propre ticket, mais pas le vôtre ». obstat résout un identifiant de ressource à partir des arguments de l'appel et applique des règles comme :
[[rule]] subject = "human:ana" resource = "jira_issue:ACME-*" effect = "allow"
Chaque autorisation est liée à un seul appel, contient une empreinte des arguments et n'est utilisable qu'une seule fois—garantie par une transaction BEGIN IMMEDIATE pour empêcher deux tentatives concurrentes d'utiliser la même autorisation.
Pourquoi cela compte
Les examinateurs et les répondants aux incidents ont besoin de journaux auditables, pas seulement collectés. En forçant l'enregistrement des décisions sur un stockage stable avant l'exécution de l'action, obstat transforme les journaux de simples récits a posteriori en preuves vérifiables. Il fait également passer la gouvernance de niveaux grossiers à des politiques au niveau des ressources, rendant plus difficile l'extension abusive d'une autorisation au-delà de son périmètre initial. Pour les équipes sérieuses sur la responsabilité, le coût d'un fsync supplémentaire est minime comparé à celui d'un journal incapable de distinguer « jamais autorisé » de « autorisé et perdu ».
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.