Vue d'ensemble SOC / SIEM¶

Rôle¶

Le périmètre SOC (Security Operations Center) regroupe la collecte, le transport, le stockage et l'analyse des logs et événements de sécurité de toute l'infrastructure Indio. Il est hébergé sur le segment réseau seg-soc (zone NSX SOC, DFW deny-all scopée par défaut — voir NSX), à l'exception de la source des logs elle-même (toute la flotte, tous segments confondus).

Cette page décrit l'architecture cible du pipeline de logs telle que clarifiée par l'exploitant, et surtout l'état réel de sa construction au 2026-07-19 — plusieurs briques restent partielles ou non construites, documentées comme telles plutôt que présentées comme terminées.

Architecture¶

Composants¶

Composant	Rôle	VM (IP)	Page
syslog-ng	Collecte centrale, stockage brut à froid, rangement par application	INDSOC001 (10.100.20.130)	syslog-ng
Kafka	Bus d'ingestion central — cluster réel construit manuellement, à ne jamais reconfigurer via l'IaC local	INDSOC002-004 (10.100.20.131-133)	Kafka
Elasticsearch	Stockage/indexation « à chaud », cluster soc-indio (3 master + 3 data)	INDSOC005-010 (10.100.20.134-139)	ELK
Logstash	Traitement/enrichissement, ponts Kafka → Elasticsearch	INDSOC014-015 (10.100.20.143-144)	ELK
Kibana + Fleet Server	Visualisation SIEM, point d'enrôlement Elastic Agent	INDSOC017 (10.100.20.146)	ELK
MISP	Threat intelligence (partage d'IOC) — VM nue, install manuelle prévue	INDSOC018 (10.100.20.147)	MISP
TheHive	Gestion de cas / réponse à incident — VM nue, install manuelle prévue	INDSOC020 (10.100.20.149)	TheHive
Cortex	Enrichissement/analyse pour TheHive — VM nue, install manuelle prévue	INDSOC021 (10.100.20.150)	Cortex
Aria Operations for Logs	Outil VMware complémentaire, déployé manuellement hors IaC	hors Terraform (IP historique 10.100.20.254, connectivité à reclarifier)	—

Schéma du pipeline de logs (architecture cible)¶

L'exploitant a explicitement clarifié le modèle cible (2026-07-16) : ce n'est pas une chaîne séquentielle Kafka → syslog-ng → Elastic. Kafka est le point central où transitent les événements, et pousse vers deux consommateurs indépendants en aval — syslog-ng (stockage brut, terminal, ne relaie rien plus loin) d'un côté, Elastic (pipeline « à chaud », via un pont Logstash) de l'autre.

Dans les faits, au 2026-07-19, la mise en œuvre n'a pas encore rejoint ce modèle cible sur toute la ligne : un flux direct flotte → syslog-ng (hors Kafka) a été construit le 2026-07-17 pour ne pas attendre le pont Logstash manquant, et seul le topic logs-audit dispose aujourd'hui d'un pont Kafka → Elasticsearch fonctionnel. Le schéma ci-dessous distingue les deux avec des traits pleins (construit, vérifié) et pointillés (cible, pas encore construit) :

flowchart LR
    Fleet["Flotte Indio<br/>53 VM"]
    NSXFG["NSX Manager / FortiGate<br/>hors baseline"]
    ExtSrc["Source externe<br/>non documentée dans l'IaC"]
    Kafka[("Kafka KRaft<br/>INDSOC002-004")]
    SNG["syslog-ng<br/>INDSOC001"]
    LSA["Logstash audit-kafka<br/>INDSOC014-015"]
    Bridge["Pont Logstash<br/>Kafka -> syslog-ng/ES<br/>NON CONSTRUIT"]
    ES[("Elasticsearch soc-indio<br/>INDSOC005-010")]
    KIB["Kibana<br/>INDSOC017"]
    NFS[("vSAN File Service<br/>file-node01:Log")]

    Fleet -->|"rsyslog omfwd TCP 514<br/>tout le trafic, direct"| SNG
    Fleet -->|"audisp-syslog seul<br/>omkafka -> topic logs-audit"| Kafka
    NSXFG -->|"export syslog UDP 514"| SNG
    ExtSrc -->|"5 topics historiques"| Kafka

    Kafka -->|"topic logs-audit"| LSA
    LSA -->|"data stream logs-audit<br/>action=create"| ES

    Kafka -.->|"5 topics historiques<br/>cloud/firewall/identity/infra/windows"| Bridge
    Bridge -.->|"réémission syslog<br/>prévue"| SNG
    Bridge -.->|"indexation prévue<br/>destination déjà prête (Terraform)"| ES

    ES --> KIB
    SNG -->|"rsync périodique<br/>.gz déjà compressés uniquement"| NFS

L'archivage .gz vers le vSAN File Service (file-node01.infra.indio:/Log) est un export complémentaire de secours, pas une écriture directe et continue — voir vSAN File Service et le détail des incidents NFS sur la page syslog-ng.

Ce qui est réellement construit aujourd'hui¶

Flux	État
Flotte (53 VM) → syslog-ng, tout le trafic	Construit et vérifié (2026-07-17)
Flotte → Kafka (logs-audit, événements auditd uniquement)	Construit et vérifié
Kafka logs-audit → Logstash → Elasticsearch	Construit et vérifié, bout en bout
syslog-ng → vSAN File Service (rsync .gz périodique)	Construit et vérifié le 2026-07-17 — statut au 2026-07-19 incertain (export /Log non reconfirmé en direct, voir vSAN File Service)
Kafka (5 topics historiques logs-cloud/firewall/identity/infra/windows) → Logstash → syslog-ng	Non construit — pont Logstash à écrire
Kafka (5 topics historiques) → Logstash → Elasticsearch	Non construit — destination (rôle logstash_writer, index template, ILM) déjà prête côté Terraform, pipeline lui-même manquant
Production des 5 topics historiques Kafka	Source non documentée dans le périmètre IaC — les données existent (mesurées à ~737 000 messages sur une partition lors d'un audit du 2026-07-16) mais rien dans les dépôts Indio ne les produit

Flux de données — détail¶

1. Collecte fleet-wide directe vers syslog-ng : un drop-in rsyslog (omfwd, TCP, format RSYSLOG_SyslogProtocol23Format/RFC5424) envoie l'intégralité des logs locaux de chaque VM vers indsoc001.infra.indio:514. Déployé sur les 53 VM (49 + 4 proxies DMZ via leur IP admin dédiée). syslog-ng range chaque message par application (${PROGRAM}) — voir syslog-ng.
2. Relais spécifique auditd : en plus du flux générique ci-dessus, les événements auditd (relayés par audisp-syslog) partent aussi, séparément, vers Kafka (omkafka, topic logs-audit) — un second flux indépendant, pas un remplacement du premier. Kafka alimente ensuite un pipeline Logstash réel (INDSOC014/015) qui parse et indexe dans Elasticsearch (data stream logs-audit, ILM soc-logs).
3. 5 topics Kafka historiques (logs-cloud, logs-firewall, logs-identity, logs-infra, logs-windows) : alimentés par une source distincte, non documentée dans les dépôts Indio — probablement des équipements/outils envoyant directement au cluster Kafka sans passer par le mécanisme fleet-wide décrit ci-dessus. Aucun consommateur (Logstash ou autre) ne lit encore ces 5 topics.
4. Export syslog NSX/FortiGate : le NSX Manager (hors flotte /root/baseline) exporte ses événements DFW/IDS-IPS directement vers syslog-ng en UDP/514, configuré hors Terraform via l'API node NSX — voir NSX.

Réseau¶

La zone SOC applique une politique DFW deny-all scopée : chaque nouveau flux doit faire l'objet d'une règle explicite dans /root/nsx/dfw_soc.tf. Règles notables pour le pipeline de logs :

• infra-to-syslog — toute la zone admin + DMZ + SOC → syslog-ng (514, svc-Monitoring), scope volontairement large (« l'ensemble de l'infra »).
• infra-to-kafka — même scope large → Kafka (9092, svc-Kafka).
• mgmt-to-soc-elasticsearch — poste de contrôle (IP SNAT FortiGate) → cluster Elasticsearch (9200), nécessaire pour piloter la config logique via Terraform (provider elastic/elasticstack).
• mgmt-to-soc-kibana / mgmt-to-soc-ssh — accès direct administration.

Voir NSX pour le détail complet des zones, le piège des règles unidirectionnelles (ex. zabbix-to-soc/soc-to-zabbix, deux règles distinctes pour un même besoin de supervision) et l'ordre d'évaluation des security policies.

Historique¶

Ce périmètre a connu plusieurs vagues de décommissionnement et de reconstruction complètes depuis sa création — voir Historique des décommissionnements pour le détail chronologique complet. En résumé : décommissionnement complet le 2026-07-06 puis reconstruction (Kafka migré vers seg-soc et vers un paquet RPM Confluent le jour même), second décommissionnement le 2026-07-07 puis rebuild en VM nues + 10 dépôts Nexus, réduction chirurgicale du dimensionnement ELK le 2026-07-14 (9→6 nœuds Elasticsearch, 3→2 Logstash), et redéploiement de MISP/TheHive/Cortex en VM nues ce même jour suite à une session de débogage infructueuse.

Points d'attention¶

• Source des 5 topics Kafka historiques non documentée : les données existent et sont volumineuses, mais aucun dépôt IaC Indio ne décrit ce qui les produit — à clarifier si un jour ce point devient bloquant.
• Supervision Kafka incomplète : la collecte Zabbix par JMX bute sur le second port RMI aléatoire de Kafka (le port fixe 9999 fonctionne, le reste de la négociation JMX non) — voir Kafka et Zabbix. Jugé non critique par l'exploitant, non traité.
• Fleet Server (Kibana/INDSOC017) : l'enrôlement automatisé a provoqué deux incidents de disponibilité de Kibana en 2026-07-15 ; l'exploitant a repris ce chantier en direct, elastic-agent reste masqué (systemctl mask) sur ce nœud — voir ELK.
• Aria Operations for Logs : IP historique 10.100.20.254 injoignable au dernier contrôle réseau (2026-07-11), VM renommée INDSOC019 côté vCenter mais pas rangée dans le dossier seg-soc — état à reclarifier avec l'exploitant avant de documenter davantage ce composant.
• MISP/TheHive/Cortex : VM provisionnées nues (Terraform + baseline uniquement), installation applicative volontairement hors IaC — installation manuelle prévue par l'exploitant lui-même. Le code Ansible existe et est conservé sur GitLab à titre de référence, mais ne décrit pas l'état actuellement installé (probablement rien) sur ces VM — voir les pages dédiées.
• Bastion Guacamole, point d'accès à plusieurs outils SOC : un compte administrateur par défaut reste actif, non corrigé — voir Bastion Guacamole.