Im Folgenden wird beschrieben, wie man in einem Szenario mit vier Agentengruppen in Wazuh die Zugriffsrechte so einrichtet, dass jeder Administrator nur die Agenten seiner Gruppe sieht und je nach Rolle vollen Administrationszugriff oder nur Leserechte erhält. Dieses Vorgehen orientiert sich an der offiziellen Wazuh-Dokumentation zum Thema Role-Based Access Control (RBAC).
Ein solches Szenario gewinnt in der Praxis vor allem deshalb an Bedeutung, weil moderne IT-Umgebungen stark unterschiedliche Verantwortungsbereiche aufweisen. Während sich Server-Administratoren gewöhnlich um die Infrastruktur kümmern, sind eigene Teams für die Client-Systeme zuständig. Wenn man in Wazuh Agentengruppen definiert und diese strikt verantwortlichen Personen zuordnet, schafft man eine klare Trennung zwischen diesen Bereichen. Nach der Anmeldung sehen Administratoren nur die für sie relevanten Systeme und arbeiten dadurch konzentrierter und sicherer. Gleichzeitig sinkt die Gefahr unbeabsichtigter Eingriffe in fremde Systeme, da Wazuh nur Aktionen zulässt, die der Rolle des jeweiligen Nutzers entsprechen. Diese Trennung wertet nicht nur die Sicherheit einer Umgebung auf, sondern verbessert auch die Übersichtlichkeit und Nachvollziehbarkeit im täglichen Betrieb. Jede Handlung lässt sich einem klar abgegrenzten Verantwortungsbereich zuordnen. Das erleichtert die Analyse von Vorfällen und die Überprüfung organisatorischer Vorgaben. Besonders in Unternehmen mit Compliance-Anforderungen oder klar definierten Zuständigkeiten unterstützt diese Struktur eine saubere und auditierbare Arbeitsweise.
Damit ein solches Rechte- und Rollenkonzept umgesetzt werden kann, müssen zunächst einige Voraussetzungen erfüllt sein. Zunächst müssen die Agentengruppen bereits existieren, damit Wazuh die später definierten Richtlinien auf diese Gruppen anwenden kann. Wie Agentengruppen angelegt werden, kann man im Kapitel 5.1.1 im Buch nachlesen. Außerdem sollte jeder Gruppe mindestens ein Agent zugewiesen sein, um die Funktionsweise unmittelbar testen zu können. Für die Einrichtung wird ein Konto mit umfassenden Rechten benötigt, da sowohl Benutzer als auch Rollen, Policies und Mappings erstellt werden müssen. Wichtig ist zudem, dass die Agentengruppen mit eindeutigen Labels versehen werden, da Wazuh diese nutzt, um eingehende Daten den entsprechenden Gruppen zuzuordnen und die Dokumenten- und Ressourcenfilter korrekt anzuwenden. Sind alle Voraussetzungen erfüllt, kann man sofort beginnen, die gewünschten Rollen zu definieren und interne Benutzer so zu konfigurieren, dass sie ausschließlich die Agenten ihrer jeweiligen Gruppe sehen und verwalten oder lediglich lesen können.

Die folgende Tabelle soll die Struktur wiedergeben:
| Administrator | Gruppe | Berechtigungen |
| Windows-Admin | Windows-Server | Vollzugriff |
| Linux-Admin | Linux-Server | Vollzugriff |
| ClientViewer | WindowsClients, LinuxClients | Leserechte |
Einrichtung für die Gruppe „Windows-Server“
Angenommen, eine Agentengruppe mit dem Namen „Windows-Server“ wurde bereits eingerichtet und enthält mindestens einen Agenten. Nun soll eine Administratorrolle geschaffen werden, die vollen Zugriff auf diese Gruppe hat. Dazu geht man Schritt für Schritt vor:
Schritt 1: Label für die Agentengruppe setzen
- Im Wazuh Dashboard anmelden mit einem übergeordneten Administrator-Konto.
- Menü ☰ > Agents management → Endpoint Groups.
- Gruppe „Windows-Server“ auswählen, „Files“ anklicken und „Edit group configuration“.
- Im Dialog ein Label eintragen (Beispiel siehe unten). Damit werden alle neuen Alerts aus dieser Gruppe mit diesem Label versehen.
- Änderungen speichern.
<agent_config>
<labels>
<label key="group">Windows-Server</label>
</labels>
</agent_config>
Wichtig: Achten Sie darauf, dass diese Labels auch für die Gruppen „WindowsClients“ und LinuxClients eingerichtet werden.
Schritt 2: Interner Nutzer anlegen
- Menü ☰ > Indexer management → Security → Internal users.
- „Create internal user“ anklicken, z. B. Benutzername
WinServerAdmin, Passwort vergeben, auf Create klicken. - Nun existiert der interne Nutzer
WinServerAdmin.

Schritt 3: Indexer-Rolle erstellen
Dafür öffnet man wieder über das Menü ☰ den Punkt Indexer management → Security → Roles und wechselt auf die Rollenübersicht. Dort klickt man auf „Create role“ und vergibt zunächst einen sprechenden Namen, zum Beispiel WinServerAdmin_index_read. Als Cluster-Berechtigungen wird der Wert cluster_composite_ops_ro gesetzt, womit der Nutzer die notwendigen Leseoperationen im Cluster ausführen kann. Im Feld „Index“ wird zunächst ein Platzhalter * eingetragen und bei den „Index permissions“ das Recht read vergeben.
Jetzt werden zusätzliche, feinere Index-Berechtigungen ergänzt, damit der Nutzer nur noch die Dokumente der gewünschten Agentengruppe sieht. Dazu klickt man auf „Add another index permission“ und klappt den neuen Abschnitt „Add index permission“ auf. In das Feld „Index“ trägt man wazuh-alerts* ein, als „Index permissions“ wieder read. Im Feld für Document level security wird eine Abfrage hinterlegt, die auf das zuvor gesetzte Gruppen-Label filtert. Für die Gruppe „Windows-Server“ sieht diese Abfrage zum Beispiel so aus:
{
"bool": {
"must": {
"match": {
"agent.labels.group": "Windows-Server"
}
}
}
}
Damit liest der Benutzer nur Alerts, deren Agent das Label Windows-Server trägt. Danach wird noch einmal auf „Add another index permission“ geklickt, um den Zugriff auf die Monitoring-Indizes einzugrenzen. Im Feld „Index“ wird wazuh-monitoring* eingetragen, bei „Index permissions“ wieder read. In der Document-Level-Security-Abfrage wird erneut nach der Gruppe gefiltert, zum Beispiel:
{
"bool": {
"must": {
"match": {
"group": "Windows-Server"
}
}
}
}
Unter Tenant permissions wählt man anschließend den Tenant global_tenant aus und setzt die Option auf Read only. Damit ist sichergestellt, dass der Nutzer im Indexer-Kontext nur lesen, aber nichts verändern kann. Nachdem alle Felder ausgefüllt sind, wird die Rolle mit „Create“ angelegt.

Zum Schluss wird die Rolle mit dem internen Benutzer verknüpft. Dazu öffnet man in der soeben erstellten Rolle den Reiter „Mapped users“, klickt auf „Manage mapping“ und fügt den zuvor angelegten Benutzer, zum Beispiel WinServerAdmin, hinzu. Nach dem Bestätigen der Zuordnung ist der Schritt „Creating and mapping an internal user“ abgeschlossen: Der interne Nutzer ist im Wazuh-Indexer mit einer maßgeschneiderten Rolle hinterlegt und sieht nur noch Alerts und Monitoring-Daten der Agentengruppe „Windows-Server“.

Schritt 4: Berechtigungen auf dem Server vergeben
- Menü ☰ > Server management → Security → Policies.
- „Create policy“ wählen.
- Name vergeben, z. B.
Policy_WindowsServer_Admin. - Aktion(en) auswählen, z. B.
agent:read,agent:upgrade,agent:restart,agent:deleteje nachdem, was Sie als „voller Administrationszugriff“ verstehen. (Die genaue Aktion-Liste nach Bedarf.) - Resource:
agent:group. - Resource identifier:
Windows-Server. - Effect:
Allow. - Speichern.

Schritt 5: Custom Rolle erstellen
- Menü ☰ > Server management → Security → Roles.
- „Create Role“ wählen.
- Name vergeben, z. B.
Role_WindowsServer_Admin. - Policies auswählen und hinzufügen:
Policy_WindowsServer_Admin. - (Optional) Weitere Policies für Alerts oder Agent-Monitoring hinzufügen, je nach Bedarf.
- Speichern.

Schritt 6: Role Mapping durchführen
- Menü ☰ > Server management → Security → Roles mapping.
- „Create Role mapping“ wählen.
- Role mapping name: z. B.
RM_WindowsServer_Admin. - Roles:
Role_WindowsServer_Adminsowie ggf. die Standardrollecluster_readonly(wie empfohlen) hinzufügen. - Internal users:
WinServerAdmin. - Speichern.

Wichtig: Damit die Rollenzuordnung wirksam wird, stellen Sie sicher, dass run_as in der Konfigurationsdatei /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml auf true gesetzt ist. Starten Sie den Wazuh-Dashboard-Dienst neu und löschen Sie den Cache und die Cookies Ihres Browsers.
Wenn man sich nun mit dem Administrator „WinServerAdmin” im Wazuh-Dashboard anmeldet, wird nur der Windows-Server angezeigt.

Einrichtung für die Gruppe „Linux-Server“
Für die Gruppe „Linux-Server“ wird analog vorgegangen:
- Zuerst wird für die Agentengruppe „Linux-Server“ ein entsprechendes Gruppen-Label gesetzt, damit die späteren Document-Level-Security-Filter eindeutig greifen.
- Danach legt man im Bereich Indexer management → Security → Internal users den internen Benutzer
LinuxAdminan, indem man Benutzername und Passwort definiert und die Erstellung abschließt. - Im Anschluss erstellt man unter Indexer management → Security → Roles eine eigene Indexer-Rolle, die analog zur zuvor erstellten Rolle für die Windows-Server-Gruppe aufgebaut ist. Die Rolle erhält das Cluster-Recht
cluster_composite_ops_ro, grundlegende Leserechte auf alle Indizes sowie zusätzliche, gruppenspezifische Index-Berechtigungen fürwazuh-alerts*undwazuh-monitoring*, jeweils mit einem Document-Level-Filter, der ausschließlich auf die Gruppe „Linux-Server“ verweist. - Unter den Tenant-Rechten wird wie zuvor der Tenant
global_tenantauf „Read only“ gesetzt. - Sobald die Rolle gespeichert ist, wird sie über den Reiter „Mapped users“ in der Rollenansicht mit dem Benutzer
LinuxAdminverknüpft, sodass die für die Gruppe „Linux-Server“ definierten Sicht- und Leserechte für diesen Benutzer wirksam werden.
Einrichtung einer Berechtigung „ClientViewer“ für „WindowsClients“ und „LinuxClients“ mit Leseberechtigung
Nun soll ein dritter Administrator angelegt werden, der sowohl die Gruppe „WindowsClients“ als auch „LinuxClients“ betreut – jedoch nur Leserechte erhält (kein administrativer Zugriff).
Schritt 1: Internen Nutzer anlegen
- Nutzername z. B.
ClientViewer. - Menü ☰ > Indexer management → Security → Internal users.
- „Create internal user“ →
ClientViewer+ Passwort.
Schritt 2: Dem Nutzer eine Rolle zuordnen
Unmittelbar nach dem Anlegen des Benutzers muss diesem Nutzer eine geeignete Indexer-Rolle zugeordnet werden, da er sich sonst nicht am Dashboard anmelden kann.
Man öffnet dafür erneut über das Menü den Bereich
Indexer management → Security → Roles und erstellt eine neue Rolle:
- Menü ☰ > Indexer management → Security → Roles → Create role.
- Name: ClientViewer_index_read
- Cluster permissions:
cluster_composite_ops_ro - Index:
* - Index permissions:
read - Tenant permissions:
global_tenantand select the Read onlyoption.

Über „Mapped users“ wird der Benutzer ClientViewer hinzugefügt.
Erst damit besitzt dieser Nutzer die grundsätzlichen Leserechte auf Index-Ebene, die jede Anmeldung am Dashboard voraussetzt.

Schritt 3: Custom Policy für „WindowsClients“ erstellen
- Menü ☰ > Server management → Security → Policies.
- Name z. B.
Policy_WindowsClients_Read. - Aktionen auswählen: z. B.
agent:read. - Resource:
agent:group. - Resource identifier:
WindowsClients. - Effect:
Allow. - Speichern.
Schritt 4: Custom Policy für „LinuxClients“ erstellen
- Menü ☰ > Policies.
- Name z. B.
Policy_LinuxClients_Read. - Aktionen:
agent:read. - Resource:
agent:group. - Resource identifier:
LinuxClients. - Effect:
Allow. - Speichern.
Schritt 5: Rolle für Viewer erstellen
- Menü ☰ > Roles.
- Name z. B.
Role_ClientViewer_Read. - Policies auswählen:
Policy_WindowsClients_ReadundPolicy_LinuxClients_Read. - Speichern.

Schritt 6: Role Mapping durchführen
- Menü ☰ > Roles mapping.
- Name z. B.
RM_ClientViewer_Read. - Roles:
Role_ClientViewer_Readsowie – falls sinnvoll – die Standardrollecluster_readonly. - Internal users:
ClientViewer. - Speichern.

Nach Abschluss kann sich der Nutzer ClientViewer am Dashboard anmelden und nur die Agenten der Gruppen „WindowsClients“ und „LinuxClients“ sehen – und dort nur im Lesemodus arbeiten (keine Admin-Aktionen wie Löschen, Neustarten oder Upgraden). Alle anderen Agentengruppen bleiben diesem Nutzer verborgen.

Zusammenfassung
In diesem Beitrag wurde gezeigt, wie man in Wazuh eine Umgebung mit vier Agentengruppen so konfiguriert, dass jede Gruppe von einem dedizierten Administrator betreut wird – mit möglichst restriktiven Zugriffsrechten. Konkret wurden die Gruppen „Windows-Server“, „Linux-Server“, „WindowsClients“ und „LinuxClients“ betrachtet. Für die Servergruppen wurden Administratoren mit vollen Rechten eingerichtet. Für die Clientgruppen wurde ein Administrator mit reinen Leserechten eingerichtet.
Dieses Vorgehen erhöht Sicherheit, Transparenz und Klarheit in der Verwaltung von Agenten-Gruppen. Die wesentlichen Schritte – Label setzen, internen Nutzer anlegen, Policies erstellen, Rolle erstellen, Role Mapping – orientieren sich an der offiziellen Wazuh-Dokumentation.
Abschließend lässt sich sagen, dass die Einrichtung von Rechten, Rollen und den zugehörigen Mappings in Wazuh auf den ersten Blick durchaus umständlich wirkt. Die Vielzahl an Schritten – vom Anlegen interner Benutzer über die Definition von Richtlinien bis hin zum feingranularen Rollen- und Index-Mapping – erschließt sich nicht sofort intuitiv. Erst nach mehrmaligem Durchlaufen dieses Prozesses wird deutlich, wie konsequent und logisch Wazuh die Trennung von Verantwortlichkeiten strukturiert. Gerade durch das wiederholte Einrichten zeigt sich, dass das Modell nicht nur flexibel, sondern auch äußerst robust ist und in komplexen Umgebungen klare und belastbare Zuständigkeiten schafft.