Wazuh für MSSPs: Mandantenfähige Deployment-Architekturen mit RBAC und Cross-Cluster Search

Einleitung

Managed Security Service Provider stehen bei der Einführung von Wazuh vor einer grundlegenden Architekturentscheidung: Sollen alle Kunden über eine zentrale Wazuh-Umgebung überwacht werden, erhält jeder Kunde eine vollständig getrennte Installation oder werden dezentrale Kunden-Cluster über eine zentrale Oberfläche zusammengeführt?

Die Entscheidung betrifft nicht nur Betriebskosten und Skalierbarkeit. Sie bestimmt auch, wie zuverlässig Kundendaten voneinander getrennt werden, wo sicherheitsrelevante Ereignisse gespeichert werden, welche Auswirkungen ein Ausfall hat und wie Kunden einen kontrollierten Lesezugriff auf ihre eigenen Daten erhalten.

Eine universell beste Architektur gibt es nicht. Für MSSP-Umgebungen hat sich jedoch ein gestuftes Modell bewährt: Eine zentrale Installation eignet sich für kleinere und regulatorisch weniger kritische Mandanten. Kunden mit hohen Isolations-, Datenschutz- oder Datenresidenzanforderungen sollten dagegen einen eigenen Wazuh-Cluster erhalten. Cross-Cluster Search kann diese getrennten Umgebungen anschließend in einem zentralen Security Operations Center zusammenführen.

Ausgangslage / Problemstellung

Ein MSSP möchte mehrere Kunden mit Wazuh überwachen und ihnen bei Bedarf einen Read-only-Zugang zur Verfügung stellen. Dabei stehen typischerweise drei Betriebsmodelle zur Auswahl:

Eine zentrale Wazuh-Installation in der eigenen Infrastruktur oder einer selbst betriebenen Cloud.
Eine separate Wazuh-Installation innerhalb jeder Kundenumgebung.
Mehrere getrennte Kunden-Cluster mit zentralem Zugriff über Cross-Cluster Search.

Bei einer zentralen Installation verbinden sich die Wazuh-Agenten der Kunden über Site-to-Site-VPNs oder andere private Netzwerkverbindungen mit den Wazuh-Servern des MSSP. Dieses Modell reduziert die Anzahl der zu betreibenden Plattformen, führt aber alle Kundendaten in einer gemeinsamen Sicherheits- und Fehlerdomäne zusammen.

Separate Installationen bieten dagegen eine deutlich stärkere Mandantentrennung. Sie erhöhen jedoch den Aufwand für Updates, Zertifikate, Monitoring, Backup, Kapazitätsplanung und Incident Response.

Zusätzlich soll jeder Kunde ausschließlich die eigenen Agenten, Alerts, Schwachstelleninformationen und Dashboards sehen können. Eine einfache globale Read-only-Rolle reicht dafür nicht aus. Sie verhindert zwar Änderungen, beschränkt aber nicht automatisch den sichtbaren Datenbestand auf einen einzelnen Mandanten.

Technische Analyse

Die Wazuh-Komponenten und ihre Bedeutung für die Mandantentrennung

Eine Wazuh-Umgebung besteht aus vier wesentlichen Ebenen:

Wazuh-Agenten sammeln Ereignisse auf Endgeräten und Servern.
Wazuh-Server analysieren die eingehenden Daten und führen Regeln, Decoder, Active Response und weitere Sicherheitsfunktionen aus.
Wazuh-Indexer speichern und indexieren Alerts, Inventardaten und Zustandsinformationen.
Das Wazuh-Dashboard stellt die Daten dar und greift zusätzlich auf die Wazuh Server API zu.

Die Agentenkommunikation erfolgt standardmäßig über TCP-Port 1514. Für die Agentenregistrierung wird üblicherweise TCP-Port 1515 verwendet. Die Wazuh Server API lauscht standardmäßig auf TCP-Port 55000, der Indexer auf TCP-Port 9200 und das Dashboard auf TCP-Port 443. Die Wazuh-Indexer verwenden für ihre Clusterkommunikation Ports aus dem Bereich 9300 bis 9400.

Für einen MSSP bedeutet das: Mandantentrennung darf nicht nur im Dashboard umgesetzt werden. Sie muss alle Ebenen umfassen:

Netzwerkzugriff auf Wazuh-Server und Indexer
Trennung oder eindeutige Kennzeichnung der Agenten
Index- und Dokumentberechtigungen
Wazuh-API-Rollen und -Policies
Dashboard-Tenants und gespeicherte Objekte
Backup-, Snapshot- und Wiederherstellungsprozesse

Zentrale Wazuh-Installation beim MSSP

Bei diesem Modell befinden sich Wazuh-Server, Indexer und Dashboard in der Infrastruktur des Dienstleisters. Die Kundenstandorte werden über Site-to-Site-VPNs, private Cloud-Verbindungen oder vergleichbare verschlüsselte Netze angebunden.

Die Vorteile liegen vor allem im zentralen Betrieb:

Gemeinsame Update- und Wartungsprozesse
Zentrale Regelwerke und Decoder
Einfachere Kapazitätsplanung
Weniger Plattformen und Zertifikatsketten
Konsolidierte Überwachung des Wazuh-Betriebs

Dem stehen erhebliche Risiken gegenüber. Ein fehlerhaftes Rollenmodell kann Daten mehrerer Kunden offenlegen. Eine Störung des zentralen Clusters betrifft potenziell alle Mandanten. Auch Änderungen an Regeln, Decodern oder Indexvorlagen können unbeabsichtigte Auswirkungen auf sämtliche Kunden haben.

Darüber hinaus müssen die Netzwerkverbindungen ausreichend stabil sein. Zwar puffern Wazuh-Agenten Ereignisse bei kurzfristigen Verbindungsproblemen, dauerhaft instabile WAN-Verbindungen können jedoch zu verzögerter Erkennung, vollen Agentenpuffern oder Lücken in der Überwachung führen.

Eine zentrale Plattform ist deshalb vor allem dann geeignet, wenn:

die Kunden eine zentrale Speicherung vertraglich akzeptieren,
keine strikten Vorgaben zur Datenresidenz bestehen,
die Mandanten ähnliche Betriebs- und Aufbewahrungsanforderungen haben,
eine belastbare RBAC- und Datenklassifizierungsstrategie vorhanden ist,
der zentrale Cluster hochverfügbar und ausreichend dimensioniert wird.

Separate Wazuh-Installation pro Kunde

Eine vollständige Wazuh-Umgebung je Kunde stellt die stärkste technische Isolation bereit. Jeder Mandant erhält eigene Wazuh-Server, Indexer, Zertifikate, Benutzer, Rollen, Indizes und Aufbewahrungsrichtlinien.

Dieses Modell reduziert die Gefahr mandantenübergreifender Datenzugriffe erheblich. Auch kundenspezifische Anforderungen lassen sich leichter umsetzen, beispielsweise:

individuelle Aufbewahrungszeiten,
eigene Regelwerke und Integrationen,
kundenspezifische Wartungsfenster,
getrennte Verschlüsselungsschlüssel,
lokale Speicherung sensibler Ereignisdaten,
unabhängige Wiederherstellung und Notfallplanung.

Die höhere Sicherheit wird mit zusätzlichem Betriebsaufwand erkauft. Ohne Automatisierung entstehen schnell unterschiedliche Versionsstände und Konfigurationsabweichungen. Separate Umgebungen sollten deshalb möglichst über Infrastructure as Code, Konfigurationsmanagement und standardisierte CI/CD-Prozesse verwaltet werden.

Cross-Cluster Search als MSSP-Hybridmodell

Cross-Cluster Search verbindet getrennte Wazuh-Cluster mit einer zentralen Such- und Visualisierungsumgebung. Die Kundendaten verbleiben in den jeweiligen Kunden-Clustern. Das zentrale SOC kann sie über ein gemeinsames Dashboard abfragen.

Die von Wazuh beschriebene Referenzarchitektur besteht aus:

einer zentralen CCS-Umgebung mit Wazuh-Indexer und Wazuh-Dashboard,
einem separaten Wazuh-Server und Wazuh-Indexer je Kundenumgebung,
einer Vertrauensbeziehung zwischen der CCS-Umgebung und den Kunden-Indexern,
optionalen lokalen Dashboards beim Kunden.

Die zentrale CCS-Umgebung benötigt für die reine Suche weder Wazuh-Agenten noch einen eigenen Wazuh-Server. Die Analyse findet innerhalb des jeweiligen Kunden-Clusters statt, und die Ereignisdaten werden dort gespeichert.

Die Remote-Cluster werden über persistente Indexer-Einstellungen registriert. Im Wazuh-Beispiel erfolgt die Verbindung zu den Remote-Indexern über Port 9300:

PUT _cluster/settings
{
  "persistent": {
    "cluster.remote": {
      "customer-a": {
        "seeds": ["10.10.10.20:9300"]
      },
      "customer-b": {
        "seeds": ["10.20.10.20:9300"]
      }
    }
  }
}

Anschließend können Remote-Indizes mit einer Clusterpräfix-Syntax abgefragt werden:

GET customer-a:wazuh-alerts-*/_search

Für die zentrale Visualisierung werden Remote-Index-Patterns wie *:wazuh-alerts-* verwendet. Das Präfix vor dem Doppelpunkt bezeichnet den Remote-Cluster. Ein Wildcard-Präfix würde alle verbundenen Cluster einbeziehen.

Für MSSPs ist CCS häufig der beste Kompromiss zwischen zentralem SOC-Betrieb und technischer Kundentrennung. Es ist jedoch keine vollständige Sicherheitsgrenze. Die CCS-Umgebung erhält weitreichenden Suchzugriff auf die verbundenen Cluster und muss deshalb wie eine hochprivilegierte Managementplattform abgesichert werden.

Multi-Site-Architektur ist nicht automatisch Mandantenfähigkeit

Die Wazuh-Multi-Site-Architektur verteilt Wazuh-Komponenten über mehrere Standorte. Agenten verbinden sich mit lokalen Wazuh-Servern, während ein gemeinsames Dashboard Daten aus den verschiedenen Standorten darstellt. Standortbezogene Indexmuster können die Alerts logisch kennzeichnen.

Das veröffentlichte Wazuh-Beispiel verwendet getrennte Wazuh-Server-Cluster pro Standort, aber einen standortübergreifenden Indexer-Cluster. Dabei werden Shards zwischen den Standorten repliziert. Diese Architektur erhöht Verfügbarkeit und Skalierbarkeit und reduziert WAN-Verkehr der Agenten.

Für vollständig voneinander unabhängige MSSP-Kunden ist dieses Modell nur eingeschränkt geeignet. Durch die gemeinsame Indexer-Clusterstruktur und die standortübergreifende Replikation befinden sich die Daten weiterhin innerhalb einer gemeinsamen Vertrauens- und Administrationsdomäne. Multi-Site eignet sich daher eher für verschiedene Niederlassungen derselben Organisation oder für Kunden, bei denen eine gemeinsame Datenhaltung ausdrücklich akzeptiert wird.

Warum eine globale Read-only-Rolle nicht genügt

Wazuh unterscheidet zwischen den Berechtigungen im Indexer und den Wazuh-Rollen für API-Ressourcen. Ein Read-only-Benutzer benötigt daher Berechtigungen auf beiden Ebenen.

Die Wazuh-Dokumentation zeigt für einen allgemeinen Read-only-Benutzer unter anderem folgende Indexer-Rechte:

Cluster permission: cluster_composite_ops_ro
Index: *
Index permission: read
Tenant: global_tenant
Tenant permission: Read only

Zusätzlich wird der Benutzer in der Wazuh-Rollenverwaltung der Rolle readonly zugeordnet. Damit das Mapping wirksam wird, muss run_as in der Dashboard-Konfiguration aktiviert sein:

run_as: true

Die Datei befindet sich unter:

/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml

Anschließend ist das Dashboard neu zu starten:

systemctl restart wazuh-dashboard

Diese Konfiguration ist für Benutzer geeignet, die alle Daten lesen dürfen. In einer MSSP-Umgebung wäre insbesondere die Indexberechtigung auf * zu weitreichend, da sie keine Kundengrenze berücksichtigt.

Für Kundenzugänge sind stattdessen individuelle Rollen mit expliziten Indexmustern oder Document-Level Security erforderlich.

Lösung / Best Practices

Empfohlene Zielarchitektur

Für einen typischen MSSP empfiehlt sich ein abgestuftes Architekturmodell:

Kundentyp	Empfohlenes Modell
Kleine Kunden ohne strikte Datenresidenzanforderungen	Zentraler, hochverfügbarer Wazuh-Cluster
Kunden mit erhöhtem Schutzbedarf	Eigener logischer oder physischer Cluster
Regulierte oder besonders sensible Kunden	Vollständig separate Wazuh-Umgebung
Kunden mit lokaler Datenhaltung und zentralem SOC	Eigener Kunden-Cluster plus Cross-Cluster Search
Mehrere Standorte einer Organisation	Multi-Site-Architektur

Cross-Cluster Search sollte als bevorzugtes MSSP-Modell betrachtet werden, wenn Kunden ihre Daten lokal halten möchten, der Dienstleister aber dennoch eine zentrale Analystenoberfläche benötigt.

Netzwerkverbindungen absichern

Wazuh-Komponenten sollten nicht direkt über das öffentliche Internet erreichbar sein. Kundenanbindungen sollten über Site-to-Site-VPNs, private Peering-Verbindungen oder dedizierte Netzwerkanbindungen erfolgen.

Dabei gilt das Prinzip der minimalen Freigabe:

Agentennetze dürfen nur die erforderlichen Wazuh-Serverdienste erreichen.
Die Wazuh Server API sollte ausschließlich aus administrativen Netzen erreichbar sein.
Indexer-Ports 9200 sowie 9300 bis 9400 dürfen nur zwischen explizit autorisierten Komponenten freigegeben werden.
Cluster-Port 1516 gehört in ein separates Managementnetz und darf nicht öffentlich erreichbar sein.
Dashboard-Zugriffe sollten über Reverse Proxy, Web Application Firewall oder einen kontrollierten Identity-Aware Proxy erfolgen.

Wazuh empfiehlt für Cluster, die mehrere Rechenzentren umfassen, private Netzwerkverbindungen oder VPNs. Cluster-Schlüssel müssen wie privilegierte Zugangsdaten behandelt, sicher gespeichert und regelmäßig rotiert werden.

Kunden eindeutig kennzeichnen

In zentralen Umgebungen benötigt jedes Ereignis eine zuverlässige Mandantenkennung. Eine praktikable Methode ist ein Agentenlabel, das über die zentrale Gruppenkonfiguration verteilt wird:

<agent_config>
  <labels>
    <label key="tenant_id">customer-a</label>
  </labels>
</agent_config>

Neue Alerts enthalten anschließend beispielsweise das Feld:

agent.labels.tenant_id: customer-a

Die Kennzeichnung sollte nicht aus frei änderbaren Hostnamen oder IP-Adressen abgeleitet werden. Eine feste Mandanten-ID ist stabiler und kann unabhängig von Standort-, Netzwerk- oder Namensänderungen verwendet werden.

Zu beachten ist, dass Labels nur in neu erzeugten Alerts erscheinen. Bereits indexierte Dokumente werden durch eine spätere Label-Konfiguration nicht rückwirkend ergänzt.

Kundenspezifische Indexer-Rollen erstellen

Eine kundenspezifische Rolle kann den Lesezugriff über Document-Level Security einschränken:

{
  "bool": {
    "must": {
      "match": {
        "agent.labels.tenant_id": "customer-a"
      }
    }
  }
}

Die Rolle sollte ausschließlich die tatsächlich benötigten Indizes umfassen, beispielsweise:

wazuh-alerts-*
wazuh-monitoring-*
wazuh-states-vulnerabilities-*
wazuh-states-inventory-*

Für jeden Indextyp muss geprüft werden, welches Feld zuverlässig zur Mandantenzuordnung verwendet werden kann. Nicht alle Wazuh-Indizes besitzen dieselbe Dokumentstruktur. Eine Filterregel, die bei Alerts funktioniert, muss daher nicht automatisch für Schwachstellen-, Inventar- oder Monitoring-Indizes geeignet sein.

Alternativ können kundenspezifische Indexpräfixe eingesetzt werden. Diese bieten eine klarere Trennung, erfordern jedoch Anpassungen an Filebeat, Templates, Index-Patterns und gegebenenfalls Lifecycle- oder Snapshot-Richtlinien. Solche Anpassungen müssen bei Wazuh-Upgrades explizit getestet werden.

Wazuh-API-Zugriffe ebenfalls begrenzen

Indexer-Rechte schützen gespeicherte Dokumente. Sie begrenzen jedoch nicht automatisch alle Informationen, die über die Wazuh Server API abgefragt werden können.

Deshalb muss zusätzlich ein Wazuh-Rollenmapping eingerichtet werden. Der Kunde darf nur auf die eigenen Agentengruppen und die für ihn vorgesehenen API-Aktionen zugreifen. Globale Rollen wie administrator oder breit angelegte Standardrollen sind für externe Kundenzugänge ungeeignet.

Das Rollenmodell sollte mindestens folgende Tests bestehen:

Der Kunde sieht keine fremden Agenten.
Direkte API-Abfragen liefern keine fremden Agenteninformationen.
Suchabfragen gegen fremde Indizes werden abgewiesen.
Gespeicherte Dashboards anderer Kunden sind nicht sichtbar.
Export-, Discover- und Reporting-Funktionen respektieren dieselben Grenzen.
Schwachstellen- und Inventaransichten enthalten ausschließlich eigene Systeme.

Dashboard-Tenants konsequent trennen

Dashboard-Tenants trennen gespeicherte Objekte wie Visualisierungen, Suchabfragen und Dashboards. Sie ersetzen jedoch keine Indexberechtigungen.

Ein Kunde sollte einen eigenen Tenant erhalten und dort lediglich Leserechte besitzen. Der globale Tenant sollte für externe Benutzer nicht freigegeben werden, sofern er mandantenübergreifende Inhalte enthält.

Die drei Kontrollschichten müssen gemeinsam greifen:

Indexer-Rechte beschränken die lesbaren Dokumente.
Wazuh-RBAC beschränkt Agenten und API-Funktionen.
Dashboard-Tenants beschränken gespeicherte Oberflächenobjekte.

Hochverfügbarkeit und Skalierung einplanen

Produktive MSSP-Plattformen sollten nicht dauerhaft als All-in-one-Installation betrieben werden. Wazuh unterstützt verteilte Installationen, bei denen Server, Indexer und Dashboard auf getrennten Systemen betrieben und als Cluster skaliert werden können. Die verfügbaren Installationsvarianten umfassen unter anderem virtuelle Maschinen, AWS Machine Images, Docker, Kubernetes und Offline-Installationen.

Wichtige Skalierungsparameter sind:

Anzahl und Aktivität der Agenten
durchschnittliche Events pro Sekunde
aktivierte Module und Dateiintegritätsüberwachung
Aufbewahrungsdauer
Replikationsfaktor
Anzahl gleichzeitiger Dashboard-Abfragen
Schwachstellen- und Inventardaten
Anzahl kundenspezifischer Rollen und Dashboards

Wazuh-Agenten sollten bei einem Server-Cluster über einen Load Balancer angebunden werden. Dadurch lassen sich Verbindungen gleichmäßig verteilen und Agenten können bei Ausfall eines Worker-Nodes automatisch einen anderen Knoten erreichen.

Änderungen und Upgrades standardisieren

Für jeden Kunden sollten Konfigurationen versioniert und reproduzierbar sein. Dazu gehören:

ossec.conf und agent.conf
eigene Decoder und Regeln
Indexvorlagen
Rollen und Rollen-Mappings
Dashboard-Tenants und gespeicherte Objekte
Zertifikatskonfigurationen
Firewall- und VPN-Regeln
Snapshot- und Wiederherstellungsrichtlinien

Die Wazuh-Beispiele für Multi-Site und Cross-Cluster Search wurden für Wazuh 4.7.5 beziehungsweise 4.8.2 veröffentlicht. Paketpfade, Templates und einzelne Konfigurationsparameter müssen daher vor einer Übernahme mit der eingesetzten Wazuh-Version abgeglichen werden.

Lessons Learned / Best Practices

Mandantenfähigkeit entsteht nicht dadurch, dass mehrere Kunden dasselbe Dashboard verwenden. Sie entsteht durch eine durchgängige Trennung von Netzwerken, Daten, Identitäten, Rollen, Betriebsprozessen und Wiederherstellungspfaden.

Eine gemeinsame zentrale Installation ist wirtschaftlich attraktiv, erhöht aber den möglichen Schadensumfang von Fehlkonfigurationen und Ausfällen. Je höher die regulatorischen oder vertraglichen Anforderungen eines Kunden sind, desto stärker sollte die technische Isolation ausfallen.

Cross-Cluster Search ist besonders geeignet, wenn Ereignisdaten in der Kundenumgebung verbleiben müssen. Die zentrale CCS-Instanz wird dabei zu einem privilegierten Zugangspunkt und muss entsprechend gehärtet, überwacht und auf die notwendigen Remote-Cluster beschränkt werden.

Read-only ist nicht gleichbedeutend mit mandantenbezogenem Read-only. Eine Rolle mit Leserechten auf * verhindert Änderungen, erlaubt aber potenziell den Zugriff auf alle Kundendaten. Externe Benutzer benötigen deshalb individuelle Index-, Dokument-, API- und Tenant-Berechtigungen.

Agentenlabels und Agentengruppen sollten bereits beim Onboarding festgelegt werden. Eine nachträgliche Bereinigung uneinheitlicher Kundenzuordnungen ist aufwendig und kann zu falsch gefilterten Daten führen.

Schließlich sollten Berechtigungen nicht nur anhand der Benutzeroberfläche getestet werden. Direkte API-Abfragen, Discover-Suchen, Exporte, Reports und Schwachstellenansichten müssen Teil eines wiederholbaren Mandantentrennungstests sein.

Fazit

Für MSSPs ist eine zentrale Wazuh-Installation nicht automatisch die beste oder sicherste Lösung. Sie eignet sich für standardisierte Kunden mit vergleichbaren Anforderungen und akzeptierter zentraler Datenhaltung. Kunden mit strengen Compliance-, Datenschutz- oder Isolationsanforderungen sollten dagegen eine eigene Wazuh-Umgebung erhalten.

Als ausgewogener Ansatz bietet sich Cross-Cluster Search an: Jeder Kunde betreibt einen getrennten Wazuh-Cluster, während das SOC über eine zentrale Wazuh-Dashboard- und Indexer-Umgebung auf die freigegebenen Remote-Daten zugreift. Dadurch bleiben Analyse und Speicherung beim Kunden, ohne auf eine zentrale SOC-Sicht verzichten zu müssen.

Unabhängig vom gewählten Modell müssen Kundenzugänge über mehrere Ebenen abgesichert werden. Erst das Zusammenspiel aus Netzwerksegmentierung, Indexer-Rechten, Document-Level Security, Wazuh-RBAC und Dashboard-Tenants schafft eine belastbare Mandantentrennung.