Envoi du journal d'audit vers un SIEM

Vaks PM · Guide d'intégration · SIEM · Juillet 2026

Ce que vous obtiendrez. Chaque événement d'audit — connexions, changements de permissions, exports de données, actions d'agents — diffusé vers votre supervision de sécurité, soit poussé en temps réel via syslog, soit tiré par votre collecteur depuis une API à périmètre restreint. Le journal d'audit local reste complet quoi qu'il arrive ; ceci est une copie destinée à la corrélation et à la rétention longue durée.

Deux façons d'alimenter un SIEM

	Push (syslog)	Pull (API)
Direction	Vaks PM se connecte vers l'extérieur, jusqu'à votre collecteur.	Votre collecteur se connecte en entrée et lit.
Latence	Temps réel, événement par événement.	L'intervalle de sondage que vous définissez.
Idéal quand	Vous exploitez Splunk, Graylog, Wazuh, QRadar — tout ce qui a une entrée syslog.	Votre collecteur préfère récupérer, ou vous archivez selon votre propre cadence.
Format	syslog RFC 5424.	JSON Lines ou CEF.

Elles ne sont pas exclusives — vous pouvez pousser en temps réel et tout de même tirer pour réconciliation. Les deux puisent dans le même journal append-only, qui n'a qu'un seul chemin de suppression : la purge de rétention décrite à la fin.

Prérequis

Côté	Ce qu'il vous faut
Push	Un récepteur syslog joignable depuis l'instance, en TCP ou TLS. TLS est fortement conseillé — le journal transporte des adresses IP et des adresses email. Pour un collecteur interne ou auto-signé, son certificat CA.
Pull	Rien de votre côté au-delà d'un collecteur capable d'envoyer un jeton bearer et d'analyser du JSON Lines ou du CEF.
Vaks PM	`org:manage` pour configurer syslog et émettre un jeton de lecture. Les jetons de pull portent le scope `audit:read`.

Étape 1 — Configurer le collecteur (push)

Ouvrez Admin → Sécurité & Conformité et trouvez SIEM / Forwarding syslog. Renseignez :

Champ	Quoi renseigner
Hôte du collecteur	Nom DNS ou IP du récepteur. Un hôte nu — sans schéma, sans suffixe de port. `siem.internal`, pas `tls://siem.internal:6514`.
Port	`6514` pour syslog-TLS (par défaut), `514` pour le TCP brut usuel.
Transport	TLS ou TCP. Préférez TLS.
CA du collecteur (PEM)	Uniquement si le récepteur présente un certificat interne ou auto-signé. Laissez vide pour utiliser le magasin de confiance système. Sans lui, un collecteur auto-signé échoue au handshake TLS.
Sévérité minimale	INFO transmet tout, y compris chaque changement de routine. WARNING écarte le bruit de routine. CRITICAL n'envoie que les événements de sécurité. Le filtrage a lieu avant que quoi que ce soit ne quitte l'instance.
Forwarder vers un SIEM	Le kill switch. Désactivé signifie que le journal reste consultable dans l'app mais que rien n'est envoyé.

Le flux est en RFC 5424 sur le transport choisi, framing octet-counting, facility 13. La sévérité est mappée aux niveaux syslog : critical → crit, warning → warning, info → info. Chaque message se termine par l'entrée d'audit complète en JSON compact, et porte un champ id.

Dédupliquez sur le champ id. La livraison est « au moins une fois » avec des réessais automatiques : une même entrée peut donc atteindre votre collecteur plus d'une fois. L'id est stable ; utilisez-le comme clé de déduplication. Attendez-vous aussi à jusqu'à une minute de latence après l'enregistrement d'un changement de réglage — la configuration est mise en cache pendant 60 secondes.

Étape 2 — TLS mutuel (optionnel)

Si votre collecteur exige que le client s'authentifie lui aussi, le TLS mutuel se répartit à dessein sur deux emplacements — le certificat public dans un réglage, la clé privée jamais dans la base de données :

Certificat client mTLS (PEM), dans les réglages syslog — le certificat public uniquement.
La clé privée est montée sur le worker en tant que secret de déploiement nommé syslog_client_key. C'est une seule clé pour tout le déploiement, pas par organisation, et elle est installée par un opérateur ayant un accès shell, pas via le panneau d'administration.

Sur Docker Swarm, un opérateur installe la clé ainsi :

printf '<PEM private key>' | docker secret create syslog_client_key -
docker service update --force vaks-pm_worker

Sur Kubernetes, c'est l'entrée syslog_client_key du secret de la release, montée dans le worker.

Le mTLS se dégrade silencieusement si la clé manque. Configurez le certificat mais laissez le secret à sa valeur de remplacement, et la connexion se poursuit simplement sans authentification du client — aucune erreur nulle part. Si votre collecteur est censé exiger le certificat client et n'en voit aucun, vérifiez que le secret du worker contient une vraie clé et que le worker a été redémarré après sa modification.

Étape 3 — Tester

Enregistrez d'abord vos réglages — le test utilise la configuration enregistrée, pas ce qui figure actuellement dans le formulaire. Pressez ensuite Tester la connexion. Il envoie un unique message audit.test au collecteur et renvoie un résultat en une quinzaine de secondes :

Connexion SIEM OK — le message a atteint le collecteur.
Échec syslog avec un motif — le handshake ou l'envoi a échoué ; le motif indique lequel.
Pas de réponse du worker — le worker n'a pas rapporté de résultat ; vérifiez ses logs.

Le test fonctionne même lorsque le forwarding est désactivé : vous pouvez donc valider la connectivité avant d'actionner le kill switch. Le forwarding réel exige à la fois l'interrupteur activé et un hôte non vide.

Quand un lot ne peut pas être livré

Si un lot épuise ses réessais, le journal local n'est pas affecté — seule la copie SIEM de ces entrées est perdue. Vaks PM le signale plutôt que de le masquer : une bannière ambre apparaît en haut du journal d'audit du jour, comptant les lots non livrés et les entrées perdues, avec la dernière erreur. C'est un signal invitant à vérifier le collecteur, pas un événement de perte de données côté Vaks PM.

Lire le journal par API (pull)

Pour un collecteur qui préfère récupérer, deux points de terminaison sont exposés sous l'API publique :

GET /api/v1/audit-logs                 # JSON paginé par keyset
GET /api/v1/audit-logs/export          # streaming, format=jsonl (défaut) ou format=cef

Les deux acceptent les mêmes filtres en paramètres de requête : from, to (ISO 8601), action (correspondance de préfixe), actorId, actorType, severity, outcome, resourceType, resourceId, et q pour une recherche plein texte de type « contient ».

Émettez le jeton dans Admin → Intégrations → Clés API : créez une clé d'organisation et sélectionnez le scope audit:read. Appelez les points de terminaison sur le nom d'hôte propre à l'organisation avec Authorization: Bearer <secret>.

Deux notes pratiques. Le sélecteur de scopes n'étiquette audit:read que comme « Permission applicative » — c'est le bon scope, la description est simplement générique. Et un export lit par lots pouvant aller jusqu'à 100 000 lignes par appel : pour une large fenêtre, paginez donc avec from/to plutôt que de tout tirer d'un coup. Les lectures paginées renvoient un curseur ; renvoyez-le verbatim jusqu'à ce qu'il revienne vide.

Un jeton personnel ne suffit pas à lui seul. Un jeton utilisateur n'atteint audit:read que si cet utilisateur détient déjà la permission via son rôle — en pratique un administrateur de l'organisation. Une clé d'organisation est le choix propre pour un collecteur sans surveillance. Ni un agent ni ses capacités ne peuvent jamais porter audit:read.

Rétention & intégrité

Le journal d'audit est append-only. Son seul chemin de suppression est une purge de rétention quotidienne, et deux réglages gouvernent ce qui se passe avant que quoi que ce soit ne soit retiré :

Réglage	Effet
Rétention des entrées d'audit	Durée de conservation des entrées, en jours. Défaut 365, entre 30 et 3650. Les entrées plus anciennes sont purgées par la tâche quotidienne.
Archiver avant purge	Lorsqu'activé, les entrées sont exportées en JSON Lines gzip vers le stockage objet avant suppression — rétention froide illimitée pour la conformité. Fail-safe : si l'archivage échoue, la purge est sautée, de sorte que rien de non archivé n'est jamais détruit.

Indépendamment, une fois par jour, Vaks PM scelle les entrées de la veille dans une ancre d'intégrité chaînée — une empreinte du journal de ce jour, liée à celui de la veille. L'ancre est elle-même une entrée d'audit : elle est donc transmise à votre SIEM également, ce qui met l'empreinte hors de portée de quiconque tenterait d'altérer directement la base de données. Vous pouvez vérifier un jour à tout moment avec Vérifier l'intégrité dans le journal d'audit : cela recalcule l'empreinte et la compare à l'ancre scellée, signalant une correspondance ou une altération.

Pourquoi l'ancre compte dans une stratégie SIEM. Le forwarding prouve ce qui a quitté la machine ; l'ancre prouve que la copie propre de la machine n'a pas été altérée par la suite. Ensemble, elles font qu'une tentative d'altération est visible à la fois dans votre SIEM (l'ancre est arrivée, avec une empreinte) et dans Vaks PM (la vérification montre une divergence). Conservez les entrées audit.anchor quotidiennes dans votre SIEM ; ce sont la référence à laquelle comparer.

Dépannage

Les réglages sont validés à l'enregistrement ; les messages provenant du serveur reviennent en français quelle que soit la langue de l'interface, reproduits verbatim ci-dessous.

Symptôme	Cause & correctif
Hôte syslog invalide à l'enregistrement	L'hôte comporte un schéma ou un suffixe de port. Ce doit être un nom DNS ou une adresse IPv4 nu — le port va dans son propre champ.
CA invalide : un certificat PEM est attendu	Le champ CA ne contient pas de certificat PEM. Collez le bloc, y compris la ligne `-----BEGIN CERTIFICATE-----`.
Le test indique Pas de réponse du worker	Le worker n'a pas répondu. Vérifiez les logs `vaks-pm_worker` ; souvent Redis est injoignable, ce qui interrompt aussi le forwarding réel.
Le handshake TLS échoue vers un collecteur interne	La vérification de certificat est active par défaut. Fournissez la CA du collecteur dans CA du collecteur (PEM).
Rien n'est transmis, aucune erreur dans l'UI	Une panne de Redis arrête la file silencieusement — le journal local continue d'écrire. Vérifiez Redis. Confirmez aussi que le kill switch est activé et que l'hôte est renseigné.
Très peu de choses atteignent le SIEM	La sévérité minimale est probablement CRITICAL. L'essentiel de l'activité de routine est en INFO et est filtré avant l'envoi.
L'authentification du collecteur échoue malgré un certificat client	Le secret du worker est encore la valeur de remplacement : aucun certificat client n'est donc réellement présenté. Installez la vraie clé et redémarrez le worker.
Entrées en double dans le SIEM	Attendu — livraison « au moins une fois ». Dédupliquez sur le champ `id` (en CEF, l'extension `externalId`).

À lire aussi : chiffrement, clés & DORA pour le contexte de conformité · exploitation pour les sauvegardes · toutes les intégrations.