Wazuh RBAC: Fehler bei benutzerdefinierten Dashboards und fehlenden Index-Rechten sauber beheben
Einleitung
Role-Based Access Control (RBAC) ist in Wazuh essenziell, um Mandantentrennung, Least-Privilege-Prinzip und organisatorische Zuständigkeiten sauber abzubilden. Besonders in Umgebungen mit mehreren Teams oder Kunden wird häufig ein separates Dashboard mit eingeschränkten Rechten benötigt – etwa für das Lesen und Verwalten bestimmter Agent-Gruppen.
In der Praxis treten dabei jedoch regelmäßig Fehler auf, die auf unvollständige Rollen-Zuweisungen oder eine fehlerhafte Dashboard-Konfiguration zurückzuführen sind. Dieser Artikel beleuchtet einen typischen Fall: Ein Benutzer erhält beim Zugriff auf das Dashboard eine Fehlermeldung bezüglich fehlender Berechtigungen auf Indizes – obwohl die Schritte aus der offiziellen RBAC-Dokumentation befolgt wurden.
Ausgangslage / Problemstellung
Ein Administrator erstellt gemäß Wazuh-Dokumentation einen internen Benutzer mit eingeschränkten Rechten, konkret gemäß Use Case:
„Give a user permissions to read and manage a group of agents“
Dabei werden:
- eine benutzerdefinierte Rolle,
- entsprechende Policies,
- sowie Role-Mappings für den internen Benutzer
konfiguriert.
Trotzdem erscheint beim Login im Wazuh Dashboard eine Fehlermeldung, die darauf hinweist, dass keine ausreichenden Berechtigungen zum Lesen der Index-Daten bestehen.
Die Konfiguration enthält bereits:
run_as: true
in der Datei:
/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml
Dennoch bleibt das Problem bestehen.
Technische Analyse
Die Ursache solcher Fehler liegt typischerweise in einem der folgenden Punkte:
1. RBAC wirkt nur mit aktiviertem run_as
Das Wazuh Dashboard nutzt für die Kommunikation mit der Wazuh API standardmäßig den technischen Benutzer wazuh-wui. Damit Benutzerrollen korrekt greifen, muss:
run_as: true
gesetzt sein.
Ist run_as deaktiviert, werden die Benutzerrechte nicht korrekt angewendet – selbst wenn die Rolle technisch korrekt definiert wurde.
Die RBAC-Dokumentation beschreibt diesen Mechanismus explizit. Quelle: https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html
2. Unterschied zwischen „Read-only“, „Internal User“ und „Custom Role“
Die Dokumentation unterscheidet mehrere Szenarien:
- Read-only Benutzer
- Interne Benutzer
- Benutzer mit benutzerdefinierten Rollen
- Admin-Benutzer
Ein häufiger Fehler besteht darin, einen Benutzer nur mit minimalen Leserechten auszustatten, jedoch:
- keine Index- oder Alert-Permissions korrekt zuzuweisen
- oder keine passenden Resource-Filter zu definieren
Gerade beim Use Case „Read and manage a group of agents“ müssen neben Agentenrechten auch entsprechende Rechte auf die zugehörigen Indizes (z. B. wazuh-alerts-*) vorhanden sein. Fehlt diese Verknüpfung, entsteht der Eindruck eines „Index-Permission-Fehlers“.
3. Inkonsistente oder unvollständige Role-Mappings
RBAC in Wazuh basiert auf:
- Policies
- Roles
- Role Mappings
- Internal Users
Wird einer dieser Schritte ausgelassen oder falsch referenziert (z. B. falscher Rollenname im Mapping), greift die Policy nicht – obwohl sie technisch existiert.
In der Praxis passiert häufig:
- Policy korrekt erstellt
- Rolle korrekt erstellt
- Mapping verweist jedoch auf falsche Rolle
- oder Benutzer wurde vor der finalen Konfiguration erstellt und nicht neu zugeordnet
Die Folge: Rechte greifen nicht wie erwartet.
4. Cache- und Session-Probleme im Dashboard
Nach Änderungen an RBAC-Konfigurationen sollten immer:
sudo systemctl restart wazuh-dashboard
durchgeführt werden.
Zusätzlich:
- Browser-Cache leeren
- Cookies löschen
- ggf. in privatem Fenster testen
Alte Sessions können sonst weiterhin mit veralteten Token-Claims arbeiten.
Lösung / Best Practices
Der nachhaltigste Lösungsweg besteht darin, die RBAC-Konfiguration vollständig neu und strikt nach Dokumentation aufzubauen – ohne alte Artefakte weiterzuverwenden.
Offizielle Anleitung: https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html#use-case-give-a-user-permissions-to-read-and-manage-a-group-of-agents
Empfohlene Vorgehensweise:
Schritt 1 – Bestehende Konfiguration entfernen
- Testbenutzer löschen
- Custom Roles löschen
- Role Mappings löschen
- Policies löschen
So wird verhindert, dass alte Konfigurationen weiterwirken.
Schritt 2 – Use Case exakt nach Dokumentation neu umsetzen
In dieser Reihenfolge:
- Policy erstellen
- Rolle erstellen (mit Referenz auf Policy)
- Role Mapping erstellen
- Internen Benutzer erstellen
- Benutzer der Rolle zuordnen
Wichtig:
- Rollennamen exakt übernehmen
- Resource-Filter korrekt setzen
- Index- und Agent-Permissions nicht vermischen
Schritt 3 – run_as: true verifizieren
Datei prüfen:
/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml
Konfiguration:
run_as: true
Dashboard neu starten.
Schritt 4 – Dashboard-Service neu starten
sudo systemctl restart wazuh-dashboard
Danach:
- Browser-Cache leeren
- Neu anmelden
Lessons Learned / Best Practices
1. RBAC ist strikt hierarchisch aufgebaut. Fehlt nur eine Verknüpfung, greifen die Rechte nicht.
2. run_as ist kein optionaler Parameter.
Ohne aktiviertes run_as funktionieren benutzerbezogene Rollen nicht wie erwartet.
3. Änderungen immer mit Neustart validieren. RBAC-Claims werden in Tokens verarbeitet – alte Sessions können veraltete Berechtigungen enthalten.
4. Konfiguration lieber neu aufsetzen als patchen. Gerade bei RBAC spart ein sauberes Redesign oft mehr Zeit als Fehlersuche in bestehenden Artefakten.
5. Index-Rechte nicht vergessen.
Agent-Rechte allein reichen nicht – Alerts und Events liegen in Indizes (wazuh-alerts-*), die ebenfalls gelesen werden müssen.
Fazit
RBAC in Wazuh funktioniert zuverlässig, wenn die Konfiguration konsistent und vollständig umgesetzt wird. Die häufigsten Fehler entstehen durch unvollständige Role-Mappings, fehlende Index-Permissions oder ein nicht aktiviertes run_as.
Die sauberste Lösung bei unerklärlichen Berechtigungsfehlern ist meist: Konfiguration entfernen und strikt nach Dokumentation neu implementieren. In den meisten Fällen führt dieser Ansatz unmittelbar zum Erfolg.
Quellenverweis
https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html#use-case-give-a-user-permissions-to-read-and-manage-a-group-of-agents
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/p1770117352953909
Quelle
Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 19. März 2026).
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?
