Wazuh Logs & Indizes nach 60 Tagen automatisch nach Amazon S3 auslagern und lokal löschen: Snapshots (OpenSearch) vs. Datei-Archivierung und ISM-Retention richtig kombinieren

von

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh)

Wenn Wazuh produktiv läuft, wachsen zwei Datenwelten schnell: (1) indexierte Security-Daten im Wazuh Indexer (Alerts/Archives-Indizes) und (2) Datei-Logs auf dem Manager unter /var/ossec/logs/. Wer beides nach 60 Tagen kostengünstig nach Amazon S3 auslagern und anschließend lokal löschen möchte, muss sauber trennen: Backup-/Restore-fähige Snapshots sind etwas anderes als „nur Dateien wegspeichern“. Dieser Beitrag zeigt eine robuste Architektur, die in Wazuh-Umgebungen üblich ist: OpenSearch Snapshots nach S3 plus Index State Management (ISM) Retention – und als Alternative/Ergänzung ein dateibasiertes S3-Archiv für Compliance.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

Anforderung:

  • „Alle Wazuh Logs und Archives der letzten 60 Tage nach S3“
  • „Automatisch nach 60 Tagen nach S3 verschieben“
  • „Danach von Wazuh Server löschen“

Typische Unklarheiten:

  • Meint „Logs/Archives“ die Wazuh Indexer-Indizes (wazuh-alerts-/wazuh-archives-*) oder die Dateien auf dem Manager (alerts.json, archives.json, etc.)?
  • Soll die Ablage in S3 wiederherstellbar (Snapshot) oder nur billig archiviert (File dump) sein?
  • Soll die „Löschung nach 60 Tagen“ im Indexer passieren oder im S3-Bucket?

Technische Analyse (Ursachen, betroffene Komponenten, Architekturbezug, Stolpersteine)

1) Zwei Datenpfade, zwei Lösungen

  1. Indexer-Daten (OpenSearch/Wazuh Indexer):
    Alerts/Events liegen in Indizes, die Wazuh zeitbasiert verwaltet. Wazuh beschreibt die Index-Typen und verweist auf das Indizes-Kapitel.
  2. Manager-Dateien (/var/ossec/logs/):
    Dort liegen u. a. Logs und Archive-Dateien, die man klassisch per Dateisync nach S3 schieben kann. Das ist billig, aber nicht so „komfortabel“ für Restore/Query wie Index-Snapshots.

2) „Nach S3 verschieben und lokal löschen“ ist bei Indizes kein Kopieren, sondern: Snapshot + Retention

Für Indexdaten ist das richtige Modell:

  • Snapshot in Repository (S3) = Backup in einem Format, das sich in einen Indexer wiederherstellen lässt. OpenSearch beschreibt Snapshots und deren Eigenschaften (kein perfekter Point-in-Time, währenddessen läuft Indexing weiter).
  • Retention/Deletion der Indizes nach 60 Tagen = ISM/ILM Policy. Wazuh dokumentiert ISM (Index Lifecycle Management) inklusive Retention Policies.

So erreichen Sie „S3 enthält die letzten 60 Tage (als Snapshots), lokal wird nach 60 Tagen gelöscht“.

3) S3-Repositories: Self-managed OpenSearch vs. Amazon OpenSearch Service

  • In Self-managed OpenSearch/Wazuh Indexer registrieren Sie ein Snapshot-Repository vom Typ s3 über die OpenSearch Snapshot API. Beispiel und Parameter (bucket/base_path) sind in der OpenSearch-Doku gezeigt.
  • In Amazon OpenSearch Service gibt es automatisierte Snapshots (S3-managed) und die Option für manuelle Snapshots/Policies (je nach Version/Domain-Setup). AWS beschreibt Snapshots im Managed Service.

Lösung / Best Practices (konkrete Schritte, Konfigurationen, Reihenfolge, Side-Effects)

Option A (empfohlen): Indexer-Indizes per Snapshot nach S3 + ISM-Retention (60 Tage)

1) Snapshot-Repository in S3 anlegen (OpenSearch-Seite)
Repository registrieren (Beispiel aus OpenSearch-Doku):

  • Bucket: z. B. wazuh-index-snapshots
  • Prefix/Base path: z. B. prod/

Hinweis: Die IAM/Rollen-/Credential-Anbindung hängt stark davon ab, ob Sie self-managed oder Amazon OpenSearch Service nutzen. Für Amazon OpenSearch Service orientieren Sie sich an AWS’ Snapshot-Mechanik.

2) Snapshot-Strategie definieren

  • Frequenz: mindestens täglich (oft stündlich bei hohen RPO-Anforderungen)
  • Scope: wazuh-alerts-* und ggf. wazuh-archives-* (falls Archives indexiert werden)
  • Aufbewahrung der Snapshots: z. B. 90 Tage (im S3-Bucket via Lifecycle, siehe unten)

3) Indizes lokal automatisch nach 60 Tagen löschen (ISM Policy)
In Wazuh über ISM/Index lifecycle management eine Policy erstellen, die Indizes nach 60 Tagen löscht. Wazuh dokumentiert das Vorgehen (Retention Policy erstellen/anwenden).

Warum das sauber ist:

  • Performance bleibt stabil (alte Indizes werden entfernt)
  • Restore bleibt möglich (Snapshots in S3)

Option B: Manager-Dateien /var/ossec/logs/ nach S3 archivieren (Compliance/Low-Cost)

Wenn Ihr Ziel primär „Aufbewahrung“ ist (nicht schnelles Restore in OpenSearch), können Sie die rotierten Dateien aus /var/ossec/logs/ nach S3 hochladen und lokal löschen.

Empfehlung:

  • Upload per aws s3 sync oder aws s3 cp via Cron/Systemd Timer
  • Danach lokale Dateien löschen, die erfolgreich übertragen wurden (Achtung auf Logrotation und File-Locks)

Das ist günstiger, aber im Restore-Fall weniger komfortabel als Snapshots (weil Sie Rohfiles wieder zusammensuchen/parsen müssen).

Option C: S3 Lifecycle für Snapshots/Archive-Objekte (Aufbewahrung/Deletion in S3)

Unabhängig davon, ob Sie Snapshots oder File-Archive in S3 ablegen: Für „nach X Tagen löschen“ ist S3 Lifecycle der robuste Standardweg (kein eigenes Script nötig). Der allgemeine Ansatz wird breit empfohlen (Objekte nach N Tagen expirieren).

Lessons Learned / Best Practices (präventive Maßnahmen, Betrieb, Skalierung)

  • Snapshots sind der einzige Weg, Indexdaten wirklich restore-fähig zu sichern. Dateidumps sind okay für Compliance, aber im Incident/Recovery deutlich weniger wertvoll. (Das ist auch der Kern der Community-Einschätzung im Thread.)
  • Retention immer im Indexer lösen (ISM), nicht durch „manuelles rm -rf“. Wazuh beschreibt ISM als Standard für Rollover/Deletion anhand Alter/Größe/Dokumentzahl.
  • Snapshots und Retention müssen zusammen gedacht werden: Erst Snapshot/Repository stabil, dann aggressive 60-Tage-Löschung aktivieren.
  • Self-managed vs. AWS OpenSearch Service unterscheiden: Repository-Setup und Automatisierung unterscheiden sich (AWS-Doku beachten).
  • Dokumentieren, was „Logs & Archives“ bedeutet:
    • wazuh-alerts-*/wazuh-archives-* (Indexdaten) vs. /var/ossec/logs/ (Dateien). Wazuh erklärt die Indexarten und deren Zweck.

Fazit (knappe Zusammenfassung mit Mehrwert)

Wenn Sie „Wazuh-Daten nach 60 Tagen nach S3 und lokal löschen“ zuverlässig umsetzen wollen, ist der robuste Weg: OpenSearch Snapshots in ein S3-Repository und parallel eine ISM-Retention-Policy, die wazuh-alerts-* (und ggf. wazuh-archives-*) nach 60 Tagen automatisch löscht. Damit bleibt die Indexer-Performance stabil und Sie behalten die Fähigkeit, Daten bei Bedarf vollständig wiederherzustellen. Für reine Aufbewahrung können zusätzlich die Manager-Dateien unter /var/ossec/logs/ nach S3 archiviert werden – kostengünstig, aber mit geringerem Restore-Nutzen.

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/p1768451533314489