Journalisation structurée et SIEM

La journalisation structurée centralise les événements pris en charge d’Opfield et des démons, avec des champs interrogeables et une politique de rétention. Dimensionnez le stockage selon l’ingestion et la rétention, surveillez la santé de ClickHouse et planifiez les mises à niveau du moteur avant que les anciennes images ne soient plus prises en charge.

La journalisation structurée donne aux applications un seul magasin de journaux interrogeable, avec des champs, des schémas, une rétention et des accès par environnement, au lieu de fichiers texte dispersés sur les serveurs. L’export SIEM envoie un flux d’audit réduit vers le collecteur externe de votre équipe de sécurité. Les deux remplissent des fonctions différentes : les journaux servent au diagnostic d’exploitation, et le SIEM transporte des événements d’audit réduits pour préserver la confidentialité, destinés à l’analyse de sécurité. Aucun n’est une sauvegarde de l’autre.

Le responsable de la plateforme fournit la capacité ClickHouse et les limites de rétention, les responsables des services définissent les champs utiles et la classification des données, et le responsable de la sécurité approuve les destinations SIEM et leur authentification. Le succès signifie qu’un événement connu peut être ingéré, retrouvé, conservé pendant la période prévue, corrélé sans secrets et — lorsque c’est requis — livré une seule fois en toute sécurité au collecteur externe.

Les destinations SIEM livrent des événements centrés sur l’audit via une file d’envoi durable (outbox). Désactiver le SIEM suspend les nouveaux envois sans supprimer la configuration des destinations ni les enregistrements finaux historiques. Testez les signatures, les nouvelles tentatives, l’idempotence et la capacité du récepteur.

Les journaux et les charges utiles SIEM ne doivent contenir ni mots de passe, ni jetons, ni clés privées, ni URI de connexion aux bases de données, ni prompts, ni sorties de modèles, ni identifiants bruts de liaisons. Utilisez des identifiants de requêtes et des identifiants de ressources stables pour la corrélation.

Décisions avant l’intégration des données

Définissez quels services peuvent écrire, quels champs sont autorisés, combien de temps les données sont conservées, qui peut les interroger et quels événements doivent être exportés à l’extérieur. Estimez le volume à partir du nombre d’événements par seconde, de la taille moyenne d’un événement et de la rétention plutôt que de choisir un TTL arbitraire. Une rétention plus longue augmente l’historique disponible lors des incidents, mais aussi le coût du stockage et l’impact de la collecte de données sensibles.

Choisissez un mode de schéma en connaissance de cause :

Mode	À utiliser lorsque	Compromis
reject	La qualité des champs doit être imposée à l’ingestion	Les producteurs doivent traiter correctement les événements refusés
strip	Les champs connus comptent et les données personnalisées inconnues doivent être écartées	Le contexte de diagnostic inattendu est supprimé
loose	Les équipes ont besoin de champs personnalisés assainis et flexibles	La gouvernance et la cohérence des recherches exigent davantage de discipline

Créez un environnement de journalisation par application ou par frontière de confiance significative. N’utilisez pas un même jeton d’ingestion partagé entre des équipes sans rapport ; les jetons sont des secrets en écriture seule et doivent pouvoir être révoqués indépendamment.

Processus de journalisation structurée

1. Activez la fonctionnalité et vérifiez la santé de ClickHouse.
2. Créez un environnement de journalisation pour une application ou une frontière de confiance.
3. Rattachez un schéma lorsque la validation des champs est nécessaire, ou utilisez délibérément le mode loose.
4. Définissez la rétention et les budgets de requêtes et d’événements adaptés au trafic attendu.
5. Créez un jeton d’ingestion en écriture seule et stockez-le dans le gestionnaire de secrets de l’application.
6. Envoyez un événement synthétique avec des champs et un identifiant de requête connus.
7. Recherchez l’événement et vérifiez l’horodatage, la gravité, les labels et l’état de rétention.

Les limites de requêtes et les limites d’événements sont distinctes. L’ingestion par lots peut accepter les événements valides tout en refusant les membres invalides ; les clients doivent donc examiner la réponse structurée plutôt que de supposer que tout le lot a réussi.

Le SDK TypeScript officiel peut regrouper par lots, réessayer, vider la mémoire tampon et transporter le contexte de trace ou de requête pour les services Node.js. Quel que soit le client, définissez un comportement de repli en cas d’indisponibilité temporaire d’Opfield et bornez la mise en mémoire tampon locale afin qu’un échec de journalisation ne puisse pas épuiser la mémoire ou le disque de l’application.

Rétention et capacité

Le TTL par environnement n’est qu’une des limites. Les tâches de maintenance d’Opfield appliquent aussi des budgets globaux de lignes et d’espace disque approximatif. Surveillez la disponibilité de ClickHouse, la pression des fusions (merges), la croissance du disque, les ingestions refusées et l’âge de l’événement le plus récent. Planifiez la rétention à partir des exigences d’incidents et de conformité plutôt que de la laisser illimitée.

Désactiver la journalisation structurée masque les surfaces normales du produit et refuse les nouvelles ingestions tout en préservant les données stockées et la configuration. Ne la réactivez qu’une fois comprise la condition de santé ou de droits sous-jacente.

Le succès en matière de capacité ne se limite pas à un processus ClickHouse sain. Vérifiez que l’horodatage de l’événement le plus récent avance, que les recherches renvoient les données récentes attendues, que la rétention supprime les anciennes partitions et que les refus d’ingestion sont compris. Opfield peut suspendre l’ingestion lorsque la capacité configurée est épuisée tout en laissant la recherche existante disponible ; déclenchez une alerte avant d’atteindre cette limite.

Envoi vers le SIEM

Configurez chaque collecteur HTTPS avec la méthode d’authentification prise en charge la plus restreinte. Validez la confiance dans les certificats, la signature des requêtes, l’idempotence du récepteur, la taille de lot acceptée, le comportement des nouvelles tentatives et l’historique d’envoi durable. La file d’envoi enregistre la progression des envois, de sorte qu’une panne temporaire du collecteur n’oblige pas les opérateurs à recréer les événements manuellement.

Si le SIEM est désactivé, la configuration des destinations et les enregistrements finaux historiques sont conservés. Après la fin d’une période de grâce de licence, la transmission vers le SIEM est suspendue : la configuration, l’historique des envois et les enregistrements déjà en file sont conservés, mais les événements d’audit qui surviennent pendant la suspension ne sont pas mis en file ; la transmission reprend au renouvellement sans reconfiguration. L’ingestion des journaux structurés continue de fonctionner après la période de grâce. Voir Rétrogradation et expiration. Vérifiez le dernier événement accepté par le récepteur et l’âge de la file dans Opfield avant de reprendre l’exploitation normale.

Détails pour l’opérateur : contrat d’envoi SIEM

Les destinations SIEM doivent utiliser HTTPS et peuvent s’authentifier avec un jeton bearer, HMAC-SHA256 ou un en-tête personnalisé validé. Les requêtes HMAC incluent un horodatage et une signature calculée sur le corps JSON brut exact ; les récepteurs doivent comparer les signatures en temps constant et refuser les horodatages périmés. Ne placez pas d’identifiants dans l’URL, la chaîne de requête, les journaux ou les tickets de test.

Opfield envoie via une file d’envoi durable et retente en cas d’erreurs réseau transitoires, de délais dépassés, de limitations de débit et de pannes serveur. Les autres erreurs client peuvent devenir des échecs définitifs. Utilisez Send test event pour valider une destination ; le test synthétique ne crée ni événement d’audit ni envoi en file. Supprimer une destination abandonne les lignes en attente, tandis que la désactiver suspend l’envoi pour une reprise ultérieure.

Règles de traitement des données

Définissez une liste d’autorisation des champs que les applications peuvent envoyer. Masquez à la source, car la rétention et l’export en aval multiplient l’impact d’un secret divulgué. Utilisez des identifiants de ressources, de requêtes et de traces, ainsi que des catégories d’erreurs bornées, plutôt que des identifiants bruts, des prompts, des dumps d’environnement ou des corps de requêtes arbitraires.

Si un secret atteint la journalisation, arrêtez toute nouvelle émission, révoquez le secret ou faites-le tourner à sa source, restreignez l’accès à l’environnement concerné et suivez le processus de suppression des données et de gestion des incidents de l’organisation. Masquer un résultat de recherche ne prouve pas que toutes les partitions conservées, tous les exports ou toutes les copies SIEM externes ont été traités.