Wazuh Indexer Backups richtig umsetzen: Snapshot Policies, ISM und Index-Typen korrekt verstehen

von

Einleitung

Backups von Security-Daten sind kein Nice-to-have, sondern ein zwingender Bestandteil jeder SIEM-Architektur. Mit dem Wazuh Indexer (basierend auf OpenSearch) stehen dafür leistungsfähige Mechanismen zur Verfügung – allerdings nicht immer dort, wo man sie intuitiv erwartet. Besonders häufig entsteht Verwirrung rund um Index State Management (ISM), Snapshot Policies und die unterschiedlichen Wazuh-Index-Typen. Dieser Artikel erklärt, warum es in ISM keine „Backup“-Action gibt, wie Snapshots korrekt erstellt werden und wie zeitbasierte Backups in der Praxis wirklich funktionieren.

Ausgangslage / Problemstellung

Eine Wazuh-Umgebung nutzt den Indexer-Cluster mit aktivierter Index Lifecycle/State Management Funktionalität. Ziel ist es:

  • alle relevanten Indizes regelmäßig in ein lokales Repository (z. B. backup2025) zu sichern
  • alte Indizes nach erfolgreichem Backup zu löschen
  • Backups ggf. auf einen bestimmten Zeitraum zu begrenzen

Beim Erstellen einer State Management Policy fällt jedoch auf:

  • Es gibt keine Action namens „backup“
  • Snapshot-Funktionen scheinen nur eingeschränkt konfigurierbar
  • Zeiträume lassen sich nicht frei definieren (z. B. „01.01.2025–31.03.2025“)

Technische Analyse

Der entscheidende Punkt ist die strikte Trennung zweier Konzepte in OpenSearch – und damit auch in Wazuh:

1. Snapshot Management ≠ Index State Management (ISM)

  • Snapshot Policies sind zuständig für Backups
  • ISM Policies sind zuständig für den Lebenszyklus von Indizes (z. B. Warm, Cold, Delete)

Das ist der Grund, warum es in ISM keine Backup-Action gibt. Backups sind bewusst entkoppelt vom Index-Lifecycle, um Datenverlust durch Fehlkonfigurationen zu vermeiden.

2. Snapshot Policies arbeiten indexbasiert – nicht zeitbasiert

Snapshots sichern Indizes, keine Zeiträume.
Zeitliche Einschränkungen ergeben sich ausschließlich aus:

  • dem Index-Naming-Schema (z. B. tägliche oder monatliche Indizes)
  • der Index-Auswahl in der Snapshot Policy

Ein Zeitraum wie „01.01.2025–31.03.2025“ existiert für OpenSearch nicht als Metadatum, sondern nur indirekt über die Namen der Indizes.

3. Unterschiede der Wazuh-Index-Typen

Typischerweise finden sich u. a. folgende Index-Familien:

  • wazuh-alerts-*
    Enthält die eigentlichen Security-Alerts (HIDS, FIM, Vulnerabilities etc.).
    → Hochkritisch, unbedingt backupwürdig
  • wazuh-monitoring-*
    Enthält interne Monitoring-Daten (Agent-Status, Health, Heartbeats).
    → Oft weniger kritisch, meist kurze Retention
  • wazuh-statistics-*
    Aggregierte Statistikdaten, häufig wöchentlich oder täglich rotiert.
    → Wird oft für Dashboards genutzt, weniger für Forensik

Die Snapshot-GUI erlaubt bei manchen Index-Typen nur eingeschränkte Auswahl, weil diese Indizes bereits stark standardisiert und kurzlebig sind.

Lösung / Best Practices

Schritt 1: Snapshot Policy für Backups erstellen

Da das Repository (backup2025) bereits existiert:

  1. Im Dashboard zu Indexer management → Snapshot management → Snapshot policies
  2. Create snapshot policy
  3. Repository auswählen (backup2025)
  4. Index Pattern definieren, z. B.:
    • wazuh-alerts-*
    • optional zusätzlich wazuh-monitoring-*
  5. Zeitplan festlegen (z. B. täglich oder wöchentlich)
  6. Retention konfigurieren (z. B. Snapshots nach 90 Tagen löschen)

Damit werden regelmäßig alle passenden Indizes gesichert, die zum Zeitpunkt der Snapshot-Ausführung existieren.

Schritt 2: ISM Policy zum Löschen alter Indizes

Separat dazu wird eine Index State Management Policy erstellt:

  • Hot → Delete nach z. B. 90 oder 180 Tagen
  • Kein Backup-Schritt hier – das Backup passiert bereits über Snapshot Policies
  • ISM greift indexweise, sobald Altersbedingungen erfüllt sind

So entsteht eine saubere Kette:
Index entsteht → wird regelmäßig gesnapshottet → wird nach Retention gelöscht

Schritt 3: Backups für einen konkreten Zeitraum (z. B. Jan–März 2025)

Ein direkter Zeitraum ist nicht möglich. Stattdessen:

  1. Identifiziere die Indizes über das Namensschema, z. B.:
    • wazuh-alerts-2025.01.*
    • wazuh-alerts-2025.02.*
    • wazuh-alerts-2025.03.*
  2. Erstelle entweder:
    • eine temporäre Snapshot Policy mit genau diesen Indexmustern
    • oder einen manuellen Snapshot, der explizit diese Indizes enthält
  3. Nach erfolgreichem Backup kann die temporäre Policy wieder entfernt werden

Das ist der einzige saubere Weg, einen „Zeitraum“ abzubilden.

Lessons Learned / Best Practices

  • ISM ist nicht für Backups zuständig – Snapshots sind ein eigenes Subsystem
  • Snapshots sichern Indizes, keine Zeiträume
  • Zeitliche Auswahl erfolgt immer indirekt über Index-Namen
  • wazuh-alerts-* sollte immer priorisiert gesichert werden
  • Backup- und Löschlogik strikt trennen, um Datenverlust zu vermeiden
  • Für Sonderanforderungen (Forensik, Legal Hold) temporäre Snapshot Policies nutzen

Diese Trennung wirkt zunächst umständlich, erhöht aber massiv die Betriebssicherheit.

Fazit

In Wazuh gibt es bewusst keine „Backup“-Action in Index State Management Policies. Backups werden ausschließlich über Snapshot Policies realisiert, während ISM den Lebenszyklus der Indizes steuert. Wer dieses Zusammenspiel versteht und Index-Namensschemata konsequent nutzt, kann zuverlässige, revisionssichere Backups aufbauen – inklusive gezielter Sicherungen für definierte Zeiträume.

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/C07BZJY86G3/p1770232948452049