Wazuh RBAC & OpenSearch: Warum eingeschränkte Agent-Sichtbarkeit derzeit nicht vollständig möglich ist
Die rollenbasierte Zugriffskontrolle (RBAC) in Wazuh ist ein wichtiges Werkzeug, wenn Organisationen sensible Sicherheitsdaten nur bestimmten Benutzergruppen zugänglich machen möchten. Doch während Wazuh selbst sehr feingranulare Agent-Berechtigungen bietet, zeigt die Kombination mit OpenSearch aktuell deutliche Schwachstellen.
Im Slack-Thread beschreibt Lennart Hagemann ein Problem, das viele Wazuh-Administratoren betreffen dürfte: Wie verhindert man, dass Benutzer*innen Daten über Agents einsehen können, die sie nicht sehen sollen – insbesondere in den OpenSearch-Indizes?
Ausgangsfrage: RBAC in Wazuh funktioniert – aber OpenSearch lässt zu viel durch
Lennart folgt der offiziellen Wazuh-Dokumentation zum RBAC-Konzept: Benutzer werden bestimmten Agent-Gruppen zugeordnet Wazuh selbst zeigt ihnen dann nur die entsprechenden Agents und Events
Soweit alles gut.
Doch beim Blick auf OpenSearch taucht ein kritischer Punkt auf:
Die Dokumentation zeigt nur, wie man DLS (Document Level Security) für die wazuh-alerts und wazuh-monitoring Indizes einrichtet
Für alle anderen Indizes werden Nutzer berechtigt, sobald man ihnen in Schritt 1 ein einfaches
read: ["*"]
gibt – also Lesezugriff auf die kompletten OpenSearch-Daten.
Das Problem: Viele weitere Indexbereiche enthalten agentenspezifische, hochsensible Informationen.
Beispiele:
- wazuh-states-vulnerabilities* → Liste aller Schwachstellen
- wazuh-states-system_inventory* → Software, Ports, Netzwerkdaten
- wazuh-states-packages* → Installierte Pakete
- wazuh-states-network* → Netzwerkkonfiguration
Ein Benutzer mit BZP-RBAC sollte nur „seine“ Agents sehen – erhält aber durch OpenSearch Einsicht in das gesamte Inventar der Infrastruktur.
Wie kritisch ist das Problem wirklich?
Sehr kritisch. Ein Nutzer mit eingeschränktem Wazuh-Zugriff könnte dennoch:
- Softwarestände anderer Systeme einsehen
- Schwachstellen anderer Teams/Abteilungen auslesen
- Netzwerkkonfigurationen fremder Server sehen
- Ports und Dienste auf anderen Hosts identifizieren
Damit lassen sich Angriffsvektoren geradezu herausfiltern.
Lennart zeigt außerdem:
Auch ohne Index-Listing sind Indizes leicht aufzuspüren
- Der Indexname kann aus Logfeldern wie
cluster.nameextrahiert werden - Im Dashboard lassen sich Indexpatterns erzeugen – und dabei tauchen die Indizes automatisch im Dropdown auf
- Man kann Indexnamen erraten, wenn die Default-Struktur übernommen wurde
Die Antwort aus der Community: „Ja, es ist ein reales Problem – und es wird erst in Wazuh 5 gelöst“
Kevin Branch („BlueWolfNinja“) bestätigt:
“This is a very real issue, and Wazuh is planning to fix it in Wazuh 5. It affects all of the wazuh-states-* indexes…”
Er verweist auf zwei offizielle Wazuh-Issues:
Die Kernaussage:
Aktuell lässt sich RBAC für die „states“-Indizes nur sehr eingeschränkt realisieren.
Wenn man keine extrem komplizierte DLS basierend auf langen Agent-ID-Listen pflegen möchte, gibt es faktisch nur zwei Optionen:
- Benutzer, die volle Sicht auf alle wazuh-states-* Indizes benötigen, dürfen diese Indizes komplett lesen
- Alle anderen Benutzer müssen vollständig blockiert werden→ kein Lesezugriff auf irgendeinen dieser Indizes
Workaround: DLS auf Basis einer Agent-ID-Liste
Lennart entscheidet sich für einen pragmatischen Ansatz:
“We’ll get by with a DLS on an array of Agent IDs. Not ideal, but will do for now.”
Dieser Ansatz funktioniert, ist aber:
- schwer wartbar
- fehleranfällig
- nicht skalierbar für große Umgebungen
Dennoch aktuell die einzige Möglichkeit, wenn man nicht alle vulnerabilitäts- und inventarbezogenen Daten offenlegen möchte.
Zusätzliche Baustelle: Zugriff auf .kibana_1 ist unbeschränkt
Auch das brachte Lennart zur Sprache:
“Users can read the .kibana_1 index and you can’t restrict their access.”
Damit können Benutzer u. a.:
- Visualisierungen
- Dashboards
- gespeicherte Suchabfragen
- Indexpatterns
von anderen Nutzern einsehen.
Nicht ideal – aber für sein Team „vertretbar“.
Ausblick: Wazuh 5 soll das Problem vollständig lösen
Wazuh plant, die komplette RBAC-Durchsetzung auf OpenSearch-Seite neu zu gestalten, sodass:
- alle wazuh-states-* Indizes RBAC-aware werden
- Filtering basierend auf Agent-Gruppen und Labels möglich wird
- DLS-Regeln nicht mehr händisch gepflegt werden müssen
Damit würde die Plattform endlich ein End-to-End-Zero-Trust-Modell unterstützen.
Wann Wazuh 5 erscheint? Noch offen – aber laut Community ist es „in der aktiven Entwicklung“.
Fazit
Der Slack-Thread zeigt: Wazuhs RBAC ist auf der API- und Dashboard-Schicht gut umgesetzt – aber OpenSearch ist derzeit ein blinder Fleck.
Bis Wazuh 5 verfügbar ist, gilt:
Wazuh-RBAC allein schützt nicht vor Einsicht in agentenspezifische Daten OpenSearch muss separat mit DLS abgesichert werden Für „states“-Indizes gibt es nur Workarounds, keine elegante Lösung Der Schutz muss über vollständige Index-Blockierung oder Agent-ID-basierte DLS erfolgen
Der Entwurf von Wazuh 5 lässt hoffen – aber bis dahin bleibt der Schutz sensibler Agentendaten eine Herausforderung, die Admins bewusst adressieren müssen.
https://wazuh.slack.com/archives/C0A933R8E/p1764169234719559
Mehr zum Wazuh Ambassador Program …
Quelle
Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 1. Dezember 2025).
Unterstützung von m.a.x. it
Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit SIEM-Services auf Open-Source-Basis.
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
