Mit Wazuh 5.0 verändert sich die Verwaltung von Sicherheitsereignissen und deren Aufbewahrung grundlegend. Statt täglich neue Indizes zu erstellen, setzt Wazuh auf Data Streams mit volumenbasierter Rotation. Das hat direkte Auswirkungen auf Storage-Planung, Datenaufbewahrung und den Aufbau einer Hot/Warm/Cold-Architektur.

Besonders für Administratoren, die von Wazuh 4.x auf Wazuh 5.0 migrieren oder eine neue Produktionsumgebung planen, ist es wichtig, die neuen Mechanismen zu verstehen. Denn die standardmäßig konfigurierten Aufbewahrungszeiten garantieren nicht automatisch, dass Daten nach Ablauf dieser Zeit tatsächlich gelöscht werden.

Dieser Artikel erklärt die Architekturänderungen, analysiert die Auswirkungen auf die Datenaufbewahrung und zeigt, wie sich mit eigenen Index State Management Policies eine kontrollierte Index-Rotation und ein mehrstufiges Storage-Konzept umsetzen lassen.

Ausgangslage / Problemstellung

In Wazuh 4.x werden Sicherheitsereignisse und Betriebsmetriken typischerweise in zeitbasierten Indizes gespeichert.

Dazu gehören beispielsweise:

wazuh-alerts-* für Sicherheitsalarme
wazuh-monitoring-* für Agent-Monitoring
wazuh-statistics-* für statistische Informationen

Eine typische Installation verwendet tägliche Indizes, die anschließend über Index State Management (ISM) verwaltet werden.

Für größere Umgebungen bietet sich eine Hot/Warm/Cold-Architektur an:

Storage-Tier	Aufgabe	Typischer Einsatzzweck
Hot	Schnelle Schreib- und Lesezugriffe	Aktuelle Sicherheitsereignisse und Analysen
Warm	Kostengünstigere Speicherung	Ältere, weiterhin durchsuchbare Ereignisse
Cold	Langfristige Aufbewahrung	Historische Daten und Compliance-Anforderungen

Beim Wechsel auf Wazuh 5.0 stellt sich daher eine zentrale Frage:

Wie lassen sich Hot/Warm/Cold-Strategien umsetzen, wenn Wazuh keine täglichen Indizes mehr erzeugt?

Die Antwort liegt im Zusammenspiel aus Data Streams, Rollover-Bedingungen und benutzerdefinierten ISM Policies.

Technische Analyse

1. Wazuh 5.0 verwendet Data Streams statt täglicher Indizes

Wazuh 5.0 organisiert zeitbasierte Daten über Data Streams.

Ein Data Stream besteht aus einem logischen Namen und einem oder mehreren sogenannten Backing Indices. Neue Dokumente werden immer in den aktuellen Write Index geschrieben.

Vereinfachter Aufbau eines Data Streams

wazuh-findings-v5-securityLogischer Data Stream

000001

Älterer Backing Index

000002

Älterer Backing Index

000003

Aktueller Write Index

Die Backing Indices erhalten fortlaufende Generationsnummern. Ein neuer Index entsteht beim Rollover, nicht automatisch um Mitternacht.

Die Zuordnung zwischen bisherigen Indizes und den neuen Data Streams sieht vereinfacht folgendermaßen aus:

Wazuh 4.x	Wazuh 5.0
`wazuh-alerts-*`	`wazuh-findings-v5-<category>`
Archivierte Ereignisse	`wazuh-events-v5-<category>`
Rohe Ereignisse	`wazuh-events-raw-v5`
`wazuh-monitoring-*`	`wazuh-metrics-*`
`wazuh-statistics-*`	`wazuh-metrics-*`

Die Zuordnung beschreibt die funktionalen Nachfolger und ist keine automatische Eins-zu-eins-Migration vorhandener Dokumente.

2. Wann erzeugt Wazuh 5.0 einen neuen Index?

Die Standardkonfiguration verwendet für die wesentlichen Event-, Findings- und Metrics-Streams zwei Rollover-Kriterien:

20 GB pro Primary Shard
200 Millionen Dokumente

Sobald eine der Bedingungen erfüllt ist, kann ISM einen Rollover ausführen.

Dabei wird ein neuer Backing Index zum Write Index. Der bisherige Index bleibt zunächst für Suchabfragen verfügbar.

Das bedeutet:

Ein neuer Index entsteht nicht mehr automatisch jeden Tag, sondern abhängig vom Datenvolumen.

Bei hohem Event-Aufkommen kann ein Index mehrfach täglich rotieren. In kleinen Umgebungen kann derselbe Write Index dagegen über Wochen oder Monate bestehen bleiben.

Einige weitere Data Streams, etwa für AI-Assistant-Sessions und Security-Audit-Logs, besitzen bereits zusätzliche zeitbasierte Rollover-Bedingungen.

3. Standardmäßige Aufbewahrungszeiten

Wazuh 5.0 liefert für seine Data Streams eigene ISM Policies aus.

Die folgenden Werte entsprechen der Dokumentation für Version 5.0.0:

ISM Policy	Löschalter nach Indexerstellung
`stream-findings-policy`	90 Tage
`stream-events-policy`	1 Stunde
`stream-raw-events-policy`	10 Minuten
`stream-metrics-policy`	30 Tage
`stream-active-responses-policy`	3 Tage
`ai-assistant-sessions-policy`	7 Tage
`security-auditlogs-policy`	90 Tage

Wichtig ist die Unterscheidung zwischen dem konfigurierten Löschalter und der tatsächlich erreichten Aufbewahrungsdauer.

Die Löschung erfolgt erst, nachdem der betreffende Index seinen Rollover erfolgreich abgeschlossen hat. GitHub

4. Das Retention-Problem bei geringem Datenvolumen

Ein besonders wichtiger Unterschied zu einer rein zeitbasierten Index-Rotation ist die Abhängigkeit zwischen Rollover und Löschung.

Eine ISM Policy kann beispielsweise vorsehen, dass ein Index nach 30 Tagen gelöscht wird.

Wenn der Write Index jedoch niemals die Rollover-Bedingung erreicht, bleibt er weiterhin aktiv. Die Löschaktion wird nicht ausgeführt.

Die effektive Aufbewahrungsdauer lässt sich für die volumenbasierten Standard-Policies näherungsweise so beschreiben:

\[ T_{\text{Retention}}\approx\max(T_{\text{Delete}},T_{\text{Rollover}}) \]

Dabei ist:

\(T_{\text{Delete}}\): konfiguriertes Mindestalter für die Löschung
\(T_{\text{Rollover}}\): Zeit bis zum Erreichen der Rollover-Bedingung

Beispiel: Ein wenig genutzter Findings-Stream

Angenommen, ein Data Stream verarbeitet durchschnittlich 100 MB pro Tag und besitzt einen Primary Shard mit einer Rollover-Grenze von 20 GB.

Konfiguriertes Löschalter

90 Tage

Geschätzte Zeit bis Rollover

200 Tage

Vereinfachte Rechnung mit 20.000 MB / 100 MB pro Tag, ohne zusätzliche Rollover-Auslöser.

Der Index kann somit erst nach ungefähr 200 Tagen für die Löschung infrage kommen, obwohl die Policy 90 Tage vorsieht.

Für produktive SIEM-Umgebungen hat dies mehrere Konsequenzen.

Compliance: Eine definierte Retention von beispielsweise 90 Tagen ist nicht automatisch eine garantierte maximale Aufbewahrungsdauer.

Datenschutz: Rohereignisse können deutlich länger gespeichert bleiben, als die nominellen Löschalter vermuten lassen.

Storage: Das Volumen bleibt zwar durch die Rollover-Grenze eines einzelnen Write Index begrenzt, die tatsächliche Datenhistorie kann jedoch erheblich älter sein als vorgesehen.

5. Was bedeutet das für Hot/Warm/Cold?

Die Standard-Policies der zentralen Wazuh-Data-Streams bestehen im Wesentlichen aus zwei Zuständen:

HotSchreiben und Rollover

DeleteIndex löschen

Vereinfachter Ablauf der Standard-Policies

Warm- und Cold-Phasen sind damit nicht automatisch Bestandteil der standardmäßigen Lebenszyklusverwaltung dieser Streams.

Allerdings bedeutet der ISM-Zustand hot nicht zwingend, dass jeder Shard physisch auf einem Hot-Node liegt. Die tatsächliche Platzierung wird durch Shard Allocation und Cluster-Konfiguration bestimmt.

Für eine kontrollierte mehrstufige Speicherarchitektur müssen deshalb zusätzliche Zustände und passende Allocation-Regeln konfiguriert werden.

Eine Ausnahme bilden die wazuh-states-*-Indizes. Diese speichern beispielsweise aktuelle Zustandsinformationen zu Inventory, File Integrity Monitoring, Security Configuration Assessment und Schwachstellen.

Da sie keinen fortlaufenden historischen Ereignisstrom darstellen, sollten sie separat betrachtet werden. Eine dauerhafte Platzierung auf Hot-Storage ist häufig sinnvoll.

Lösung / Best Practices

1. Eigene ISM Policies statt Änderungen an Standard-Policies

Die mit Wazuh ausgelieferten ISM Policies sollten nicht direkt verändert werden.

Der Grund: Das Setup-Plugin schreibt die Standard-Policies bei entsprechenden Neustarts beziehungsweise Upgrades erneut in den Indexer.

Dadurch können lokale Änderungen überschrieben werden.

Zusätzlich arbeiten bereits verwaltete Indizes mit ihrer zuvor übernommenen Policy-Version weiter. Neue Indizes können daher andere Regeln verwenden als bestehende.

Die empfohlene Vorgehensweise ist:

Vorhandene Standard-Policy auslesen.
Eine Kopie mit eigener policy_id erstellen.
Rollover- und Retention-Bedingungen anpassen.
Die Priorität des ISM Templates erhöhen.
Bestehende Indizes auf die neue Policy umstellen.
Die erfolgreiche Umstellung kontrollieren.

2. Bestehende Policy auslesen

Zunächst wird die aktuelle Findings-Policy über die Indexer-API abgefragt.

curl -sk \
  -u "admin:$WAZUH_INDEXER_ADMIN_PASSWORD" \
  "https://localhost:9200/_plugins/_ism/policies/stream-findings-policy"

Die Ausgabe enthält unter anderem die Zustände, Aktionen, Transition-Bedingungen und zugehörigen Indexmuster.

Für die folgende Konfiguration wird die Policy kopiert und angepasst.

3. Tägliche Rotation und 30 Tage Retention konfigurieren

Ein praktikabler Ansatz besteht darin, den volumenbasierten Rollover um eine zeitbasierte Bedingung zu ergänzen.

Damit wird ein Index beispielsweise nach einem Tag oder bei Erreichen der Volumengrenze rotiert.

Das folgende Beispiel erzeugt eine eigene Policy-Datei auf Grundlage der ausgelieferten Findings-Policy.

Voraussetzung ist die Installation von jq.

curl -sk \
  -u "admin:$WAZUH_INDEXER_ADMIN_PASSWORD" \
  "https://localhost:9200/_plugins/_ism/policies/stream-findings-policy" \
| jq '{
    policy: (
      .policy
      | del(
          .policy_id,
          .last_updated_time,
          .schema_version,
          .error_notification
        )
      | .description =
          "Custom findings retention: 30 days"
      | .states[0].actions[0].rollover.min_index_age = "1d"
      | .states[0].transitions[0].conditions.min_index_age = "30d"
      | .ism_template[].priority = 1
    )
  }' > custom-findings-policy.json

Die erzeugte Datei sollte vor dem Import überprüft werden.

Die beiden entscheidenden Einstellungen sind:

rollover.min_index_age = "1d"

Damit erhält der Rollover zusätzlich eine zeitbasierte Auslösebedingung. Die bestehende Größen- beziehungsweise Dokumentgrenze bleibt erhalten.

transitions[].conditions.min_index_age = "30d"

Damit wird die Löschung frühestens 30 Tage nach Erstellung des jeweiligen Backing Index möglich.

Die Template-Priorität 1 sorgt dafür, dass die eigene ISM Policy gegenüber der Standard-Policy mit Priorität 0 bevorzugt wird.

4. Eigene Policy registrieren

Anschließend wird die Konfiguration unter einer neuen Policy-ID gespeichert.

curl -sk \
  -u "admin:$WAZUH_INDEXER_ADMIN_PASSWORD" \
  -X PUT \
  "https://localhost:9200/_plugins/_ism/policies/custom-findings-policy" \
  -H "Content-Type: application/json" \
  -d @custom-findings-policy.json

Neue passende Backing Indices können nun automatisch der benutzerdefinierten Policy zugeordnet werden.

Wichtig: Das ISM Template beeinflusst nur die automatische Policy-Zuordnung bei neu erzeugten Indizes.

Bereits bestehende Backing Indices werden dadurch nicht rückwirkend umgestellt.

5. Bestehende Backing Indices migrieren

Für vorhandene Findings-Indizes wird die ISM-API change_policy verwendet.

curl -sk \
  -u "admin:$WAZUH_INDEXER_ADMIN_PASSWORD" \
  -X POST \
  "https://localhost:9200/_plugins/_ism/change_policy/.ds-wazuh-findings-v5-*" \
  -H "Content-Type: application/json" \
  -d '{"policy_id":"custom-findings-policy"}'

Diese Operation erfolgt asynchron.

Die Antwort der API bestätigt zunächst nur, dass die betroffenen Indizes für den Policy-Wechsel vorgesehen wurden.

Der tatsächliche Wechsel erfolgt während der nächsten ISM-Ausführungszyklen.

6. Policy-Wechsel überprüfen

Mit der Explain-API lässt sich kontrollieren, welche Policy tatsächlich für jeden Backing Index ausgeführt wird.

curl -sk \
  -u "admin:$WAZUH_INDEXER_ADMIN_PASSWORD" \
  "https://localhost:9200/_plugins/_ism/explain/.ds-wazuh-findings-v5-*" \
| jq -r '
  to_entries[]
  | select(.value | type == "object")
  | [
      .key,
      .value.policy_id,
      (.value.step.name // "pending")
    ]
  | @tsv
'

Die Ausgabe sollte für alle betroffenen Indizes die neue policy_id und einen gültigen Ausführungsschritt anzeigen.

Betriebshinweis: Während eines laufenden Policy-Wechsels sollte kein geplanter Cluster-Neustart durchgeführt werden.

Wird die Umstellung in einem ungünstigen Zustand unterbrochen, kann ein Index aufgrund eines Versionskonflikts aus der ISM-Verwaltung fallen. In diesem Fall greifen die vorgesehenen Retention-Regeln nicht mehr.

Die offizielle Dokumentation beschreibt sowohl die Fehlererkennung als auch die Wiederherstellung durch Entfernen und erneutes Zuweisen der Policy. GitHub

7. Hot/Warm/Cold mit zusätzlichen ISM-Zuständen

Für eine mehrstufige Speicherarchitektur wird die Policy um weitere Zustände ergänzt.

Ein mögliches Betriebskonzept könnte folgendermaßen aussehen:

Beispiel einer 90-Tage-Storage-Strategie

Hot

Tag 0–7

Aktive Indizes, Ingestion und häufige Abfragen

Nach 7 Tagen

Warm

Tag 7–30

Ältere, weiterhin durchsuchbare Daten

Nach 30 Tagen

Cold

Tag 30–90

Selten abgefragte historische Sicherheitsereignisse

Nach 90 Tagen

DeleteAutomatische Entfernung des Backing Index

Beispielwerte, keine Wazuh-Standardeinstellungen. Die Zeitgrenzen beziehen sich auf das Alter des jeweiligen Index.

Die Zustandswechsel können über min_index_age definiert werden.

Die physische Zuordnung der Shards erfolgt über Allocation-Aktionen.

Dafür müssen die Indexer-Nodes entsprechend gekennzeichnet sein, beispielsweise mit einem Node-Attribut tier und den Werten hot, warm oder cold.

Ein schematischer Allocation-Ausschnitt lautet:

{
  "allocation": {
    "require": {
      "tier": "warm"
    },
    "wait_for": false
  }
}

Für Cold-Storage wird entsprechend cold verwendet.

Die Konfiguration ist ein Ausschnitt einer ISM-Aktion und keine vollständige Policy. Für den produktiven Einsatz müssen die Zustände, ihre Transitionen und die Rollover-Aktion korrekt zusammengesetzt werden.

Dabei gelten drei wichtige Regeln:

Der aktive Write Index muss auf geeigneten Ingest-Nodes verbleiben.
Die Warm- und Cold-Zuweisungen dürfen erst erfolgen, wenn ein Index nicht mehr als Write Index verwendet wird.
Die Ziel-Nodes müssen ausreichend Kapazität besitzen und die erforderlichen Shard-Allocation-Regeln erfüllen.

Insbesondere die zweite Regel ist entscheidend. Ein zeitbasierter Wechsel in einen Warm-Zustand darf nicht dazu führen, dass ein noch aktiver Write Index auf ungeeigneten Storage verschoben wird.

Für ein solches Design muss der Rollover daher vor der Warm-Migration erfolgreich abgeschlossen sein.

Lessons Learned / Best Practices

1. Retention immer mit Rollover gemeinsam betrachten

Eine ISM Policy mit einer Löschbedingung allein garantiert keine zeitlich begrenzte Aufbewahrung.

Bei volumenbasierten Data Streams muss geprüft werden, ob der Rollover regelmäßig stattfindet.

Wenn feste Aufbewahrungsgrenzen benötigt werden, ist eine zusätzliche zeitbasierte Rollover-Bedingung sinnvoll.

2. Kleine Umgebungen benötigen andere Einstellungen als große Cluster

Ein kleines Wazuh-Deployment kann sehr lange benötigen, um einen 20-GB-Shard zu füllen.

Bei einem großen SIEM-Cluster kann dieselbe Grenze dagegen mehrfach pro Stunde erreicht werden.

Deshalb sollte die ISM-Konfiguration auf Basis realer Ingestion-Daten erfolgen.

Wichtige Messgrößen sind:

Tägliches Ingestion-Volumen pro Data Stream
Durchschnittliche Dokumentgröße
Anzahl aktiver Kategorien
Primary- und Replica-Shards
Erwartete Datenaufbewahrung
Verfügbare Speicherkapazität je Storage-Tier

3. Tägliche Rotation erhöht die Anzahl der Shards

Eine tägliche Index-Rotation hat Vorteile für die Planbarkeit.

Allerdings entstehen dadurch auch bei geringer Datenmenge regelmäßig neue Backing Indices.

Jeder zusätzliche Index verursacht Metadaten- und Shard-Overhead.

Bei vielen Data Streams kann dies zu einer unnötig hohen Shard-Anzahl führen.

Die Wahl der Rollover-Intervalle sollte deshalb einen Kompromiss zwischen Retention, Storage-Effizienz und Cluster-Verwaltungsaufwand darstellen.

4. Storage-Kapazität inklusive Replikation berechnen

Bei der Kapazitätsplanung dürfen Replica-Shards nicht vergessen werden.

Ein einfaches Beispiel:

Größe	Wert
Ingestion	100 GB/Tag
Retention	90 Tage
Primärdaten	9 TB
Eine Replica	9 TB
Gesamtdatenvolumen	18 TB

Das Beispiel berücksichtigt noch keine zusätzlichen Reserven für aktive Write Indices, Segment-Merges, Translogs, Betriebssystem, Recovery und Cluster-Wachstum.

Für den produktiven Betrieb muss deshalb ausreichend freie Kapazität eingeplant werden.

Außerdem sollten Replica-Shards auf unterschiedlichen Nodes beziehungsweise geeigneten Failure Domains verteilt werden.

5. Retention ist auch ein Security-Thema

Unkontrolliert lange gespeicherte Ereignisse können sicherheitsrelevante und personenbezogene Informationen enthalten.

Dazu gehören unter anderem:

Benutzernamen und Hostinformationen
IP-Adressen und Netzwerkverbindungen
Authentifizierungsereignisse
Prozess- und Dateipfade
Inhalte aus Logquellen

Daher sollten Retention-Policies regelmäßig überprüft und ihre tatsächliche Wirkung dokumentiert werden.

Gerade bei Compliance-Vorgaben ist nicht nur die konfigurierte Aufbewahrungsdauer relevant, sondern auch der Nachweis, dass Daten nach Ablauf der vorgesehenen Frist tatsächlich entfernt werden.

6. Änderungen zunächst in einer Testumgebung validieren

Eine Anpassung der ISM Policy kann dazu führen, dass bereits vorhandene Daten früher gelöscht werden als bisher.

Vor der produktiven Aktivierung empfiehlt es sich deshalb, die Policy mit repräsentativen Testdaten zu prüfen.

Besonders wichtig sind die Übergänge zwischen Hot, Warm und Cold sowie die abschließende Löschung.

Auch Neustarts, Upgrades und fehlgeschlagene ISM-Aktionen sollten in das Betriebskonzept aufgenommen werden.

7. ISM-Status aktiv überwachen

Die Explain-API sollte nicht nur während der Migration verwendet werden.

Sie eignet sich auch für regelmäßige Kontrollen im laufenden Betrieb.

Dabei sollten insbesondere folgende Situationen erkannt werden:

Rollover-Bedingungen werden dauerhaft nicht erreicht.
Indizes verbleiben unerwartet lange in einem Zustand.
Policy-Wechsel sind noch ausstehend.
ISM-Aktionen schlagen fehl.
Shards können nicht auf das vorgesehene Storage-Tier verschoben werden.

Eine funktionierende ISM-Konfiguration ist ein wesentlicher Bestandteil eines zuverlässig betriebenen Wazuh-Clusters.

Fazit

Wazuh 5.0 verändert die Indexverwaltung grundlegend: Data Streams mit volumenbasierter Rotation ersetzen für die wesentlichen Ereignis- und Metrikdaten die bisher üblichen täglichen Indizes.

Dadurch wird die Verwaltung bei hohem Datenaufkommen flexibler. Gleichzeitig entsteht eine wichtige Abhängigkeit zwischen Rollover und Retention.

Insbesondere in kleinen und mittelgroßen Umgebungen können Daten wesentlich länger gespeichert bleiben als durch die standardmäßigen Löschalter vorgesehen.

Für produktive Installationen empfiehlt sich daher ein bewusst geplantes ISM-Konzept.

Benutzerdefinierte Policies ermöglichen eine Kombination aus volumen- und zeitbasierter Rotation. Ergänzt um geeignete Allocation-Regeln lassen sich damit auch Hot/Warm/Cold-Architekturen aufbauen.

Entscheidend ist, die ausgelieferten Standard-Policies nicht direkt zu verändern, bestehende Backing Indices kontrolliert umzustellen und die tatsächliche Ausführung der Policies regelmäßig zu überprüfen.

Wer Wazuh 5.0 produktiv betreibt, sollte Index-Rotation, Retention und Storage-Tiering als zusammenhängenden Prozess planen – nicht als voneinander unabhängige Einstellungen.