BEACON — la diffusion de la piste d'audit

01Transporter la piste d'audit sans en créer une seconde #sec_699483b6

BEACON est le canal de diffusion des événements d'audit REVIEWIT vers les outils du client : SIEM, stockage objet ou consommateur d'API. Il ne produit pas la preuve et ne possède pas les événements. Audit Trail prouve ; BEACON transporte.

La piste d'audit ordonnée constitue directement son journal de diffusion. BEACON conserve uniquement les destinations, leur position de lecture et les manifestes des lots livrés. Si son état devait être reconstruit, aucun événement métier ne serait perdu : la source reste la piste.

Cette séparation protège le socle d'audit des cycles de version propres à Splunk, Sentinel, Elastic ou aux autres connecteurs. Un nouveau dialecte SIEM se traduit en périphérie ; il ne modifie ni la forme canonique ni la chaîne d'intégrité.

02Un format canonique, plusieurs destinations #sec_a182be39

Tous les modes de livraison racontent la même histoire. BEACON émet une enveloppe canonique, alignée sur les standards de sécurité, qui transporte l'événement d'audit sous sa forme vérifiable et des attributs normalisés faciles à exploiter.

Les adaptations vers CIM, ASIM, ECS, UDM, CEF ou LEEF appartiennent aux packages connecteurs. La chaîne serveur conserve ainsi un seul contrat versionné et une politique d'évolution additive.

Deux familles de transport couvrent les usages principaux :

• le push HTTP, incluant les profils compatibles avec un collecteur tel que Splunk HEC ;
• le dépôt de lots compressés et de leurs manifestes dans un stockage objet du client.

Le pull expose la même enveloppe, paginée par curseur. Il peut servir de mode nominal ou de rattrapage. Passer du pull au push ne change ni le dictionnaire, ni l'outil de vérification, ni le sens des événements.

03Aucun trou silencieux #sec_39c1a83b

La livraison est au moins une fois : après une incertitude réseau, un même lot peut être présenté de nouveau. Son identifiant déterministe et l'identifiant stable de chaque événement permettent au consommateur de le dédupliquer.

BEACON ne saute jamais un événement difficile à livrer. Après épuisement des tentatives, la destination est mise en pause et un incident est levé. La reprise repart du dernier checkpoint acquitté. La panne d'une destination n'affecte ni les autres destinations, ni l'écriture de la piste, ni l'acte métier à l'origine de l'événement.

Si l'interruption dépasse la fenêtre chaude de la piste, la destination passe dans un état explicite de récupération requise. Une opération tracée reconstitue alors la plage depuis l'archive avant de reprendre le flux courant. L'absence de trou reste vraie même dans le cas dégradé ; elle ne repose pas sur l'espoir que la destination revienne assez vite.

Un filtre ne crée pas davantage de rupture. Les événements hors périmètre sont remplacés par des jalons minimaux qui conservent la continuité cryptographique sans révéler leur contenu. Le client peut donc limiter les données reçues tout en vérifiant que la séquence n'a pas été amputée.

04Un manifeste pour exercer la preuve #sec_0b739556

Chaque lot est accompagné d'un manifeste qui décrit sa plage de séquences, ses empreintes d'entrée et de sortie, le nombre d'événements et de jalons, ainsi que les règles d'intégrité utilisées. Lorsque la plage est couverte par un sceau, sa référence est incluse.

L'outil de vérification BEACON recalcule la chaîne, contrôle la continuité entre plusieurs lots et produit un rapport daté. Il annonce le niveau réellement démontré : continuité par chaînage, couverture par un sceau, ou ancrage externe lorsqu'il existe. La présence d'une signature de transport n'est jamais présentée comme une preuve plus forte que la piste elle-même.

L'acquittement d'un lot, la persistance de son manifeste et l'avancement du checkpoint forment une opération cohérente. Un redémarrage peut provoquer une nouvelle livraison identique, jamais une plage déclarée livrée sans le manifeste qui la documente.

05Résidence et frontière de sécurité #sec_0a77479b

Les workers BEACON s'exécutent dans la région de la souscription et poussent vers la destination déclarée par le client. Le flux ne transite pas par une région mère. Lorsque la région réelle d'un endpoint ne peut pas être vérifiée techniquement, le choix interrégional fait l'objet d'une reconnaissance explicite et auditée.

Les transports utilisent HTTPS, le mTLS lorsque la destination le permet, et une signature anti-rejeu par lot. Les secrets de destination sont conservés dans un coffre, référencés par la configuration, jamais placés en clair dans les paramètres ou les journaux.

La gouvernance du canal est elle-même auditée : création, modification, pause, reprise et désactivation d'une destination deviennent des événements. Le système qui exporte la piste reste donc soumis à la piste.

06En résumé #sec_1d392ef5

BEACON livre la preuve sans la dupliquer. Son format unique, ses checkpoints, ses manifestes et ses jalons garantissent un flux ordonné, reprenable et vérifiable vers les outils de sécurité du client, sans mettre le SIEM sur le chemin des opérations métier.