Produktionsreife Wazuh-SIEM-Architektur im Gesundheitswesen: Rollen, Konfigurationen und Rollout-Reihenfolge für Hot/Warm + Dedicated Masters + Ingest

von

Einleitung

In großen Healthcare-Umgebungen (HIPAA/JCIA/ISO) ist Wazuh nicht nur „ein weiteres SIEM“, sondern ein Betriebs- und Compliance-System: hohe EPS, lange Retention, Auditierbarkeit, HA und vorhersagbare Performance sind entscheidend. Technisch steht und fällt das Design mit einer sauberen Trennung der Verantwortlichkeiten zwischen Wazuh Manager-Cluster (Analyse/Regeln/API), Wazuh Indexer (OpenSearch-Fork) für Storage/Suche und einem Dashboard für Visualisierung. Die Wazuh-Architektur ist dabei klar: Filebeat liest Manager-Ausgaben und sendet sie an den Indexer; das Dashboard visualisiert die Daten und nutzt zusätzlich die Manager-API. Wazuh Dokumentation+2Wazuh Dokumentation+2

Dieser Beitrag verdichtet die Diskussion zu einem praxistauglichen „Blueprint“ inkl. Node-Rollen, opensearch.yml, filebeat.yml, ossec.conf (Manager-Cluster) und einer sinnvollen Deployment-Reihenfolge.

Ausgangslage / Problemstellung

Gegeben ist ein Ziel-Setup:

  • ~2.500 Endpoints + ~100 Server, heterogen (Windows/Linux)
  • 90 Tage Retention, Hot 0–30d, Warm 31–90d
  • Sustained ~3.000 EPS, Peak ~5.000 EPS
  • Geplante Rollen/Nodes:
    • Wazuh Manager: 3 (Cluster)
    • Indexer Hot: 5
    • Indexer Warm: 3
    • Ingest Nodes: 3 (separat)
    • Dashboard: 1
    • NGINX/LB: 1
  • Offene Fragen:
    • Hot/Warm vs. Ingest: darf Hot auch ingest?
    • Wie „Dedicated Masters“ (cluster manager) statt Hot als master-eligible?
    • Welche IPs/Namen in cluster.initial_master_nodes und discovery.seed_hosts?
    • Was kommt in Manager ossec.conf vs. Indexer opensearch.yml vs. filebeat.yml?
    • Welche Module zuerst und in welcher Reihenfolge?

Technische Analyse

1) Indexer-Rollen: Dedicated Cluster Manager vs. Data Hot/Warm vs. Ingest

Der Wazuh Indexer basiert auf OpenSearch, daher gelten OpenSearch-Rollen- und Cluster-Prinzipien. Wazuh verweist explizit darauf, für Rollen/Details OpenSearch-Doku heranzuziehen. Wazuh Dokumentation+1

Für Produktionsumgebungen sind dedizierte Cluster-Manager-Nodes (früher „master“) Best Practice: Sie halten den Cluster stabil, verwalten State/Elections und sollten keine Daten halten. OpenSearch empfiehlt dafür typischerweise drei dedizierte Cluster-Manager-Nodes. docs.opensearch.org+1

Hot/Warm ist dagegen eine Data-Tiering-Strategie: Hot nimmt neue Writes/hohe IOPS, Warm hält ältere Daten günstiger und wird weniger abgefragt. Wazuh beschreibt Hot/Warm explizit als Architektur für selten abgefragte ältere Daten und verweist auf ISM/Index Lifecycle Management. Wazuh Dokumentation+1

Ingest-Nodes entkoppeln Pipeline/Enrichment vom Data-Layer. Wenn separate Ingest-Nodes vorhanden sind, ist es sinnvoll, Hot-Nodes „data-only“ zu halten; fehlen Ingest-Nodes, können Hot-Nodes zusätzlich ingest übernehmen (Trade-off: mehr CPU/Heap-Last auf Hot). Wazuh Dokumentation+1

2) cluster.initial_master_nodes und discovery.seed_hosts

OpenSearch/Wazuh nutzen beim ersten Cluster-Bootstrap:

  • cluster.initial_master_nodes: nur die Namen der master-/cluster-manager-eligible Nodes, die beim initialen Voting teilnehmen.
  • discovery.seed_hosts: Hosts/IPs zum Peer-Finden (üblich: cluster-manager-eligible Nodes).

In Wazuh/Community-Kontext wird das genauso beschrieben: master-eligible Nodes stehen in cluster.initial_master_nodes, der Indexer wählt über Election den Cluster Manager. Google Gruppen+1

3) Manager-Cluster-Konfiguration ist getrennt vom Indexer-Cluster

Wazuh Manager-HA (Master/Worker) wird in ossec.conf über den <cluster>-Block konfiguriert (Manager-Nodes/IPs, node_type master/worker, key, port). Das ist unabhängig vom Indexer. Wazuh Dokumentation+1

4) Filebeat-Ausgabeziele: besser Ingest/LB statt Data-Nodes (wenn vorhanden)

Wazuh beschreibt Filebeat als Forwarder vom Manager zum Indexer. Wazuh Dokumentation+1
In großen Clustern ist es operativ sinnvoll, Filebeat nicht „querbeet“ auf alle Data-Nodes zu zeigen, sondern auf:

  • Ingest Nodes (wenn dediziert vorhanden) oder
  • einen LB/VIP vor ingest/coordinating Nodes.

Wazuh-Doku zeigt das Prinzip „Output zu Indexer“, die konkrete Ziel-Topologie ist eure Designentscheidung. Wazuh Dokumentation+1

Lösung / Best Practices

A) Zielrollen im Indexer (dein Wunsch: Hot/Warm ohne Master-Rolle)

Empfohlenes Rollenmodell (gesundheitswesen-tauglich, stabil):

  • 3× Dedicated Cluster Manager (keine Daten, keine Ingest)
  • 5× Hot Data (nur data_hot / data)
  • 3× Warm Data (nur data_warm / data)
  • 3× Ingest/Coordinating (ingest, optional keine Daten)

OpenSearch empfiehlt drei dedizierte Cluster Manager Nodes als Standard-Pattern für Produktion. docs.opensearch.org+1
Wazuh erklärt Hot/Warm + node.attr/ISM als Tiering-Mechanismus. Wazuh Dokumentation+1

B) Beispiel opensearch.yml (Wazuh Indexer) pro Node-Typ

Datei: /etc/wazuh-indexer/opensearch.yml (Node-spezifisch)

1) Dedicated Cluster Manager Node (3 Stück)

cluster.name: wazuh-cluster
node.name: cm-1

node.roles: [ cluster_manager ]

network.host: 0.0.0.0
http.port: 9200

discovery.seed_hosts: ["cm-1-ip","cm-2-ip","cm-3-ip"]
cluster.initial_master_nodes: ["cm-1","cm-2","cm-3"]   # nur beim initialen Bootstrap

# Optional: als „coordinating-only“ NICHT, da cluster_manager hier bewusst gesetzt ist.

Warum: Dedicated cluster manager nodes erhöhen Stabilität/Quorum. docs.opensearch.org+1

2) Hot Data Node (5 Stück)

cluster.name: wazuh-cluster
node.name: hot-1

node.roles: [ data, data_hot ]
node.attr.temp: hot

network.host: 0.0.0.0
http.port: 9200

discovery.seed_hosts: ["cm-1-ip","cm-2-ip","cm-3-ip"]

Wazuh nutzt für Hot/Warm Attribute (Beispiel node.attr.temp) in Verbindung mit Lifecycle/ISM. Wazuh Dokumentation+1

3) Warm Data Node (3 Stück)

cluster.name: wazuh-cluster
node.name: warm-1

node.roles: [ data, data_warm ]
node.attr.temp: warm

network.host: 0.0.0.0
http.port: 9200

discovery.seed_hosts: ["cm-1-ip","cm-2-ip","cm-3-ip"]

4) Ingest Node (3 Stück)

cluster.name: wazuh-cluster
node.name: ingest-1

node.roles: [ ingest ]
# optional: coordinating-only zusätzlich, indem man KEINE data-Rolle setzt
# und die Node als Entry-Point für Filebeat nutzt.

network.host: 0.0.0.0
http.port: 9200

discovery.seed_hosts: ["cm-1-ip","cm-2-ip","cm-3-ip"]

Wazuh-Indexer-Cluster-Tuning erwähnt explizit: Jeder Node ist coordinating per Default; als „dedicated coordinating“ setzt man node.roles: []. Das ist ein weiteres Muster, wenn man reine Query-Knoten möchte. Wazuh Dokumentation+1

C) Shards & Replicas für 5 Hot + 3 Warm (Startwert, nicht Dogma)

Wazuh dokumentiert Shards/Replicas-Tuning als zentrale Stellschraube. Wazuh Dokumentation+1

Pragmatischer Startpunkt für Daily Indices (Alerts/Archives):

  • Primaries: 5 (align mit Hot-Nodes für Write-Parallelität)
  • Replicas: 1 (HA/Read-Performance)

Warum: Primaries sollten Writes gut verteilen; Replica=1 liefert Redundanz, ohne Shard-Explosion zu riskieren. Shard-Overhead ist real – deshalb später anhand von Heap/Segments/Indexing-Latenz feinjustieren. Wazuh Dokumentation+1

D) Filebeat auf dem Manager: Output auf Ingest (oder LB/VIP)

Wazuh erklärt Filebeat als Forwarder vom Manager zum Indexer. Wazuh Dokumentation+1

Wenn du dedizierte Ingest Nodes hast, setze Filebeat auf diese (oder einen VIP davor), nicht auf Hot/Warm:

output.elasticsearch:
  hosts:
    - "https://ingest-1-ip:9200"
    - "https://ingest-2-ip:9200"
    - "https://ingest-3-ip:9200"
  # plus TLS/credentials gemäß Wazuh Indexer Integration Doku

Das hält Hot/Warm frei von Pipeline-Overhead und skaliert bei EPS-Peaks sauberer.

E) Wazuh Manager Cluster: ossec.conf (3 Manager: 1 Master + 2 Worker)

Wazuh dokumentiert die Cluster-Nodes-Konfiguration über <cluster> inkl. node_type und nodes (Peer-Liste). Wazuh Dokumentation+1

Master Manager (node_type=master)

<cluster>
  <name>wazuh-manager-cluster</name>
  <node_name>mgr-1</node_name>
  <node_type>master</node_type>
  <key>CHANGE_ME_TO_A_STRONG_KEY</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>mgr-1-ip</node>
    <node>mgr-2-ip</node>
    <node>mgr-3-ip</node>
  </nodes>
  <disabled>no</disabled>
</cluster>

Worker Manager (node_type=worker)

<cluster>
  <name>wazuh-manager-cluster</name>
  <node_name>mgr-2</node_name>
  <node_type>worker</node_type>
  <key>CHANGE_ME_TO_A_STRONG_KEY</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>mgr-1-ip</node>
    <node>mgr-2-ip</node>
    <node>mgr-3-ip</node>
  </nodes>
  <disabled>no</disabled>
</cluster>

Wichtig: In ossec.conf definierst du damit Manager-zu-Manager-Cluster-Peers – nicht Indexer-IP-Listen. Das ist eine häufige Verwechslung. Wazuh Dokumentation+1

F) Deployment-Flow für Produktion (robust und auditierbar)

Ein bewährter Ablauf – konsistent mit Wazuh-Komponentenabhängigkeiten: Wazuh Dokumentation+2Wazuh Dokumentation+2

  1. Zertifikate/PKI planen und erstellen (Indexer/Manager/Dashboard sauber getrennt, Rotation/Ownership dokumentieren)
  2. Indexer-Cluster bootstrappen
    • zuerst Dedicated Cluster Manager Nodes (cm-1..3),
    • dann Hot/Warm,
    • dann Ingest/Coordinating
  3. Wazuh Manager-Cluster installieren
    • mgr-1 als Master, mgr-2/3 als Worker
  4. Filebeat auf Managern konfigurieren (Output auf Ingest/VIP)
  5. Dashboard installieren und anbinden (Indexer + Manager API)
  6. Load Balancer (NGINX) vor Dashboard/API/Ingest (je nach Design)
  7. Agent Rollout in Wellen + Baseline-Policies

G) Welche Module zuerst – Reihenfolge für Healthcare-Compliance

Ohne „Noise-Explosion“ ist entscheidend, schrittweise zu aktivieren:

  1. Baselines:
    • Log-Collection (Windows Event Channels, Syslog, App-Logs)
    • Grundlegende Regeln/Decoders stabilisieren
  2. FIM (File Integrity Monitoring) für kritische Pfade (HIPAA-relevant: Konfigs, EHR-Komponenten)
  3. Vulnerability Detection (nur wenn Patch-/Inventory-Qualität stimmt)
  4. Syscollector / Inventory (für Asset-Transparenz; Voraussetzung für saubere Hygiene-Ansichten)
  5. Active Response (erst nach Alert-Qualität + Change-Management)
  6. Threat Intel/Enrichment selektiv (hochwertige Feeds, klare Use-Cases)

Diese Reihenfolge minimiert Fehlalarme, hält EPS kalkulierbar und erleichtert Audit-Nachweise.

Lessons Learned / Best Practices

  • Dedicated Cluster Manager Nodes sind in Produktion fast immer richtig (Stabilität/Quorum). docs.opensearch.org+1
  • Hot/Warm ist Tiering für Datenalter, kein Ersatz für Master/Cluster-Manager-Rollen. Wazuh Dokumentation+1
  • Separate Ingest Nodes lohnen sich bei Burst-EPS und schützen Hot-Tier; ohne Ingest können Hot-Nodes ingest übernehmen – aber das ist ein bewusster Trade-off. Wazuh Dokumentation+1
  • Shards/Replicas sind ein zentrales Tuning-Thema: zu viele Shards erzeugen Overhead; starte konservativ und messe Heap/Indexing/Search. Wazuh Dokumentation+1
  • Manager-Cluster (ossec.conf) und Indexer-Cluster (opensearch.yml) strikt trennen – unterschiedliche Ziele, unterschiedliche Peer-Listen. Wazuh Dokumentation+1

Fazit

Für ein compliance-ready Wazuh in Healthcare ist dein Grunddesign tragfähig – entscheidend ist die saubere Rollentrennung im Indexer: 3 Dedicated Cluster Manager, Hot/Warm als reine Data-Tiers, Ingest separat (oder alternativ Hot+Ingest, wenn nötig). Manager-HA wird ausschließlich über den <cluster>-Block in ossec.conf gebaut; Indexer-Bootstrap über cluster.initial_master_nodes/discovery.seed_hosts nur für cluster-manager-eligible Nodes. Mit einem konservativen Shard/Replica-Start (z. B. 5 Primaries, 1 Replica) und einem stufenweisen Modul-Rollout bleibt das System performant, auditierbar und skalierbar.

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C0A933R8E/p1766731267970039