Wazuh-Mandantentrennung für Syslog: Relays, Agent-Labels und getrennte Indizes

Einleitung

Die Migration einer bestehenden Wazuh-Umgebung von einem zentralen Betriebsmodell zu einer mandantenfähigen Architektur betrifft nicht nur Benutzer, Rollen und Dashboards. Eine der größten Herausforderungen ist die eindeutige Zuordnung von Syslog-Ereignissen, die von Firewalls, Routern, Switches und anderen agentenlosen Geräten stammen.

Werden diese Geräte direkt an den Syslog-Eingang des Wazuh Managers angebunden, fehlt eine belastbare Agentenidentität pro Mandant. Dadurch lassen sich die Ereignisse zwar anhand von Quelladressen, Hostnamen oder Logfeldern unterscheiden, aber nicht ohne Weiteres über ein konsistentes Mandantenmerkmal filtern und autorisieren.

Eine praxistaugliche Lösung besteht darin, pro Mandant beziehungsweise pro organisatorischer Sicherheitszone einen Linux-basierten Syslog-Relay mit installiertem Wazuh Agent einzusetzen. Der Relay sammelt die Syslog-Nachrichten lokal, schreibt sie möglichst unverändert in eine Datei und übergibt sie über den Wazuh Agent an den Manager. Dadurch bleiben vorhandene Decoder und Regeln weitgehend nutzbar, während gleichzeitig eine eindeutige Agenten- und Mandantenzuordnung entsteht.

Ausgangslage / Problemstellung

In einer klassischen Single-Tenant-Umgebung senden Netzwerkgeräte ihre Ereignisse häufig direkt an den Wazuh Manager:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
  <allowed-ips>10.20.0.0/16</allowed-ips>
  <local_ip>10.10.10.20</local_ip>
</remote>

Wazuh unterstützt diesen Betriebsmodus offiziell für Geräte, auf denen kein Agent installiert werden kann. Dazu gehören insbesondere Firewalls, Router und Switches. Die Konfiguration benötigt zwingend eine Einschränkung über allowed-ips.

Der Nachteil: Direkt über den Syslog-Eingang empfangene Ereignisse werden nicht einem individuellen Wazuh Agent des sendenden Geräts zugeordnet. Sie erscheinen üblicherweise mit der Identität des Managers und der Agent-ID 000. Dieses Verhalten ist für die Ereignisanalyse grundsätzlich funktionsfähig, erschwert aber eine saubere Mandantentrennung erheblich.

Eine Trennung ausschließlich über folgende Felder ist möglich, aber langfristig fehleranfällig:

Quell-IP beziehungsweise location
Syslog-Hostname
Hersteller- oder Gerätefelder wie devid, devname oder serial
Namenskonventionen in Dashboards
individuell angepasste Regeln und Decoder

Insbesondere bei Adressüberschneidungen, NAT, Gerätewechseln, mehreren Standorten oder wechselnden Hostnamen entsteht schnell eine schwer wartbare Sonderlogik. Werden Mandanten später über Rollen oder Document-Level Security getrennt, fehlt außerdem ein einheitliches Feld, das in allen relevanten Alerts zuverlässig vorhanden ist.

Das Ziel sollte deshalb sein:

Die vorhandenen Syslog-Nachrichten möglichst unverändert weiterzuverarbeiten.
Bestehende Wazuh-Decoder und -Regeln weiterzuverwenden.
Jedem Mandanten eine eindeutige Agentenidentität zuzuordnen.
Alerts mit einem expliziten Mandantenfeld anzureichern.
Zugriffe sowohl auf Indexer- als auch auf Wazuh-API-Ebene einzuschränken.
Optional eigene Indizes pro Mandant zu erzeugen.

Technische Analyse

Warum ein Syslog-Relay die Agentenidentität verbessert

Bei einem Relay-Modell sendet das Netzwerkgerät seine Syslog-Nachrichten nicht mehr direkt an den Wazuh Manager. Stattdessen nimmt ein lokaler Linux-Server die Nachrichten mit rsyslog entgegen:

[Geräte Mandant A]
        |
        | Syslog TCP/UDP
        v
[Linux-Relay + Wazuh Agent]
        |
        | verschlüsselte Wazuh-Agent-Kommunikation
        v
[Wazuh Manager]
        |
        v
[Wazuh Indexer]

Der Wazuh Agent überwacht eine lokale Logdatei auf dem Relay. Dadurch erreichen die Ereignisse den Manager im Kontext der eindeutigen Agenten-ID des Relay-Systems und nicht mehr ausschließlich unter der Manager-ID 000.

Wazuh dokumentiert genau dieses Verfahren: rsyslog nimmt die Nachrichten entgegen, schreibt sie in eine Datei und der lokal installierte Wazuh Agent liest diese Datei mit log_format auf syslog.

Der Relay kann ein dediziertes System oder ein bereits vorhandener Linux-Server sein. Aus Gründen der Verfügbarkeit, Nachvollziehbarkeit und Sicherheitszonierung ist ein dedizierter oder klar abgegrenzter Relay pro Mandant beziehungsweise Standort jedoch meist vorzuziehen.

Ein Agent darf nicht mehrere Mandanten vermischen

Agent-Labels gelten für alle Ereignisse, die von einem Agent übertragen werden. Sammelt ein einzelner Wazuh Agent gleichzeitig Syslog-Nachrichten mehrerer Mandanten, würden alle Ereignisse dasselbe Mandantenlabel erhalten.

Deshalb sollte die Vertrauensgrenze eindeutig sein:

Mandant A → Relay-Agent A → tenant_a
Mandant B → Relay-Agent B → tenant_b

Ein Relay kann mehrere Geräte desselben Mandanten bedienen. Er sollte jedoch nicht gleichzeitig Geräte verschiedener Mandanten verarbeiten, wenn die spätere Trennung über die Agentenidentität oder ein Agent-Label erfolgen soll.

Bleibt das ursprüngliche Syslog-Format erhalten?

Grundsätzlich ja – vorausgesetzt, rsyslog wird so konfiguriert, dass es die Nachricht nicht unnötig umformatiert.

Wazuh verarbeitet Syslog-Nachrichten zunächst in einer Pre-Decoding-Phase. Dabei werden, sofern vorhanden, allgemeine Informationen wie Zeitstempel, Hostname und Programmname aus dem Syslog-Header extrahiert. Anschließend verarbeiten die eigentlichen Decoder den verbleibenden Nachrichteninhalt.

rsyslog kann Nachrichten beim Schreiben in eine Datei mit eigenen Templates versehen. Eine ungeeignete Vorlage kann Zeitstempel, Hostnamen oder Header verändern und dadurch das Decoder-Verhalten beeinflussen. Für eine möglichst originalgetreue Speicherung stellt rsyslog unter anderem die Eigenschaften rawmsg und rawmsg-after-pri bereit. rawmsg-after-pri enthält die empfangene Nachricht ohne das optionale numerische PRI-Präfix.

Für FortiGate-Logs und andere herstellerspezifische Formate bedeutet das:

Der eigentliche Key-Value-Inhalt wie date=, devname=, srcip= oder action= muss unverändert bleiben.
Ein vorhandener Syslog-Header darf erhalten bleiben.
Zusätzliche Präfixe des Relay-Systems sollten vermieden werden.
Das Ergebnis muss mit wazuh-logtest gegen die verwendete Wazuh-Version getestet werden.

Ob die eingebauten Regeln vollständig greifen, hängt nicht nur vom Transportweg ab. Entscheidend ist auch, ob die installierte Wazuh-Version einen passenden Decoder und ausreichende Regeln für den jeweiligen Gerätetyp und dessen Firmware- beziehungsweise Logformat enthält. Ein technisch korrekt weitergeleitetes Ereignis kann daher sauber ankommen, aber trotzdem keinen Alert erzeugen, wenn keine passende Regel mit ausreichendem Level existiert.

Agent-Labels stehen nicht im Regelkontext zur Verfügung

Agent-Labels eignen sich gut, um erzeugte Alerts mit Metadaten anzureichern:

"agent": {
  "id": "017",
  "name": "relay-tenant-a",
  "labels": {
    "tenant": "tenant_a"
  }
}

Wazuh unterstützt die zentrale Konfiguration solcher Labels über die gruppenspezifische agent.conf. Die Labels werden den Alerts des betreffenden Agenten hinzugefügt.

Sie können in Wazuh 4.x jedoch nicht als Bedingung innerhalb einer normalen Wazuh-Regel verwendet werden:

<!-- Funktioniert nicht zuverlässig als Regelbedingung -->
<field name="agent.labels.tenant">tenant_a</field>

Der Grund ist die Verarbeitungsreihenfolge: Die Regelanalyse findet statt, bevor die vollständige Alert-Metadatenstruktur für die spätere Indexierung vorliegt. Der Analyseprozess besitzt daher keinen nutzbaren Kontext über Agent-Labels oder Agentengruppen. Diese Einschränkung ist auch in den zugehörigen Wazuh-Entwicklungsdiskussionen dokumentiert.

Labels sind deshalb geeignet für:

Dashboards und Filter
Index-Routing
Indexer-Rollen
Document-Level Security
externe Integrationen
nachgelagerte Korrelation

Sie sind nicht geeignet, um im klassischen Wazuh-Regelwerk die Ausführung einer Regel auf einen Mandanten zu beschränken.

Dashboard-Tenants sind keine vollständige Datentrennung

Die Multi-Tenancy-Funktion des Wazuh Dashboards trennt gespeicherte Objekte wie:

Index Patterns beziehungsweise Data Views
Visualisierungen
Dashboards
Suchabfragen
weitere Dashboard-Objekte

Administratoren können globale, private und benutzerdefinierte Tenants bereitstellen und Rollen mit Lese- oder Schreibrechten zuweisen.

Ein Dashboard-Tenant allein verhindert jedoch nicht automatisch, dass ein Benutzer auf Indizes eines anderen Mandanten zugreift. Für eine tatsächliche Datenisolation werden zusätzlich Indexer-Rollen mit eingeschränkten Index Patterns oder Document-Level Security benötigt.

OpenSearch DLS beschränkt, welche Dokumente eine Rolle bei Leseoperationen abrufen darf. DLS ist jedoch keine Schreibsperre. Benutzer mit DLS-beschränktem Zugriff sollten daher keine Schreib-, Änderungs- oder Löschrechte auf den betreffenden Datenindizes erhalten.

Lösung / Best Practices

1. Einen Syslog-Relay pro Mandant oder Sicherheitszone bereitstellen

Pro Mandant wird mindestens ein Linux-System mit folgenden Komponenten eingerichtet:

rsyslog
Wazuh Agent
ausreichend lokaler Speicher für temporäre Logdateien und Warteschlangen
eingeschränkte Firewallregeln für Syslog
synchronisierte Systemzeit
Monitoring für Dienststatus, Festplattenplatz und Ereignisrate

Bei mehreren geografischen Standorten kann je Mandant und Standort ein eigener Relay sinnvoll sein. Syslog über unverschlüsseltes UDP sollte möglichst nicht über unzuverlässige WAN-Strecken transportiert werden. Ein lokaler Relay kann Nachrichten zwischenspeichern, filtern und anschließend über die abgesicherte Wazuh-Agent-Kommunikation an den zentralen Manager übertragen.

2. rsyslog für den Empfang konfigurieren

Beispiel für /etc/rsyslog.d/10-wazuh-tenant-a.conf:

module(load="imudp")
input(type="imudp" port="514")

module(load="imtcp")
input(type="imtcp" port="514")

template(
  name="WazuhSyslogFormat"
  type="string"
  string="%rawmsg-after-pri%\n"
)

if $fromhost-ip startswith "10.20.10." then {
  action(
    type="omfile"
    file="/var/log/wazuh-relay/tenant_a.log"
    template="WazuhSyslogFormat"
  )
  stop
}

Die Eigenschaft fromhost-ip enthält die IP-Adresse des Systems, von dem rsyslog die Nachricht empfangen hat. Sie eignet sich deshalb für eine vorgelagerte Filterung nach Geräten oder Netzen.

Anschließend muss das Verzeichnis erstellt und der Zugriff so gesetzt werden, dass der Wazuh Agent die Datei lesen kann:

sudo mkdir -p /var/log/wazuh-relay
sudo touch /var/log/wazuh-relay/tenant_a.log
sudo chmod 0750 /var/log/wazuh-relay
sudo chmod 0640 /var/log/wazuh-relay/tenant_a.log

Besitzer und Gruppe sind an die verwendete Distribution und das Prozessmodell des Wazuh Agent anzupassen.

Die Konfiguration sollte vor dem Neustart geprüft werden:

sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo systemctl status rsyslog

Die Firewall sollte den Syslog-Port ausschließlich für bekannte Quellnetze freigeben. Für produktive Umgebungen ist TCP gegenüber UDP vorzuziehen, sofern das sendende Gerät dies unterstützt. Unterstützt das Gerät Syslog over TLS, sollte diese Variante geprüft werden.

3. Logrotation einrichten

Die Relay-Datei darf nicht unbegrenzt wachsen. Eine passende logrotate-Konfiguration könnte folgendermaßen aussehen:

/var/log/wazuh-relay/tenant_a.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
    create 0640 root adm
}

copytruncate verhindert, dass rsyslog nach der Rotation weiterhin in einen umbenannten Dateideskriptor schreibt. Bei hohen Ereignisraten ist eine kontrollierte Rotation über ein rsyslog-HUP oder eine dedizierte Queue-Konfiguration robuster.

Der verfügbare Speicher sollte so dimensioniert sein, dass der Relay auch während einer vorübergehenden Unterbrechung der Verbindung zum Wazuh Manager weiterarbeiten kann.

4. Den Wazuh Agent zentral konfigurieren

Für den Mandanten wird eine eigene Wazuh-Agentengruppe angelegt, beispielsweise tenant_a.

Die gruppenspezifische Datei befindet sich bei einer klassischen Wazuh-Installation unter:

/var/ossec/etc/shared/tenant_a/agent.conf

Beispiel:

<agent_config>
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/wazuh-relay/tenant_a.log</location>
  </localfile>

  <labels>
    <label key="tenant">tenant_a</label>
  </labels>
</agent_config>

Der Relay-Agent wird anschließend der Gruppe zugeordnet:

sudo /var/ossec/bin/agent_groups -a -i 017 -g tenant_a

Agentengruppen ermöglichen eine zentral verwaltete, gruppenspezifische Konfiguration. Änderungen in der agent.conf werden an die zugeordneten Agenten verteilt.

Nach der Synchronisation sollten neue Alerts folgende Felder enthalten:

{
  "agent": {
    "id": "017",
    "name": "relay-tenant-a",
    "labels": {
      "tenant": "tenant_a"
    }
  },
  "location": "/var/log/wazuh-relay/tenant_a.log"
}

5. Decoder und Regeln mit echten Logbeispielen testen

Vor der Umschaltung eines produktiven Geräts muss ein Originalereignis aus der Relay-Datei getestet werden:

sudo tail -n 20 /var/log/wazuh-relay/tenant_a.log
sudo /var/ossec/bin/wazuh-logtest

Anschließend wird eine vollständige Zeile aus der Datei in wazuh-logtest eingefügt.

Zu kontrollieren sind:

Phase 1:
- timestamp
- hostname
- program_name

Phase 2:
- decoder.name
- extrahierte Felder

Phase 3:
- rule.id
- rule.level
- rule.description

Das offizielle Verfahren für eigene und vorhandene Decoder sieht ebenfalls den Test mit wazuh-logtest vor.

Bleibt der Decoder gegenüber der direkten Syslog-Anbindung unverändert, sind normalerweise keine Anpassungen an bestehenden Regeln oder Dashboards erforderlich. Ändert sich dagegen der Header oder wird nur der reine Nachrichtenteil gespeichert, muss geprüft werden, ob vorhandene Decoder auf program_name, hostname oder eine bestimmte Headerstruktur angewiesen sind.

6. Alerts optional in mandantenspezifische Indizes routen

Für eine stärkere Trennung können Alerts anhand des Labels agent.labels.tenant in eigene Indexmuster geschrieben werden:

wazuh-alerts-tenant-a-*
wazuh-alerts-tenant-b-*

Das Routing erfolgt nach der Wazuh-Regelanalyse in der Filebeat-/OpenSearch-Ingest-Stufe. Deshalb kann das Label hier verwendet werden, obwohl es im Wazuh-Regelwerk nicht als Bedingung verfügbar ist.

Bei einer paketbasierten Wazuh-Installation befinden sich die relevanten Dateien typischerweise unter:

/usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json
/etc/filebeat/wazuh-template.json

Vor jeder Änderung müssen Sicherungskopien erstellt werden:

sudo cp \
  /usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json \
  /usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json.bak

sudo cp \
  /etc/filebeat/wazuh-template.json \
  /etc/filebeat/wazuh-template.json.bak

Zunächst werden die neuen Indexmuster in das Wazuh-Template aufgenommen:

"index_patterns": [
  "wazuh-alerts-4.x-*",
  "wazuh-archives-4.x-*",
  "wazuh-alerts-tenant-a-*",
  "wazuh-alerts-tenant-b-*"
]

Danach kann die Ingest-Pipeline um mandantenspezifische date_index_name-Prozessoren ergänzt werden:

{
  "date_index_name": {
    "description": "Route tenant_a alerts",
    "field": "timestamp",
    "date_rounding": "d",
    "index_name_prefix": "wazuh-alerts-tenant-a-",
    "index_name_format": "yyyy.MM.dd",
    "if": "ctx.agent?.labels?.tenant == 'tenant_a'",
    "ignore_failure": false
  }
},
{
  "date_index_name": {
    "description": "Route tenant_b alerts",
    "field": "timestamp",
    "date_rounding": "d",
    "index_name_prefix": "wazuh-alerts-tenant-b-",
    "index_name_format": "yyyy.MM.dd",
    "if": "ctx.agent?.labels?.tenant == 'tenant_b'",
    "ignore_failure": false
  }
}

Anschließend werden Template und Pipeline neu geladen:

sudo filebeat setup \
  --index-management \
  -E setup.template.overwrite=true

sudo filebeat setup \
  --pipelines \
  --modules wazuh

Ein entsprechendes Split-Routing über die Wazuh-Ingest-Pipeline ist technisch möglich. Dabei müssen das Wazuh-Template, die Pipeline-Reihenfolge und die zusätzlichen Shards berücksichtigt werden.

Wichtige Nebenwirkungen:

Das Routing gilt nur für neu eingehende Alerts.
Bestehende Dokumente werden nicht automatisch verschoben.
Zusätzliche Indizes erzeugen zusätzliche Shards.
Eigene ISM- beziehungsweise Aufbewahrungsrichtlinien müssen angepasst werden.
Änderungen an Dateien unter /usr/share/filebeat können bei Updates überschrieben werden.
Docker- und Kubernetes-Installationen besitzen andere Pfade und Deployment-Mechanismen.
Pipeline und Template müssen nach jedem Wazuh-Upgrade kontrolliert werden.

7. Indexer-Rollen pro Mandant erstellen

Für getrennte Indizes kann jede Mandantenrolle ausschließlich Leserechte auf ihr eigenes Muster erhalten:

Mandantenrolle A:
  wazuh-alerts-tenant-a-*

Mandantenrolle B:
  wazuh-alerts-tenant-b-*

Indexer-Rollen steuern unter anderem Indexrechte, Document-Level Security, Field-Level Security und Tenant-Berechtigungen. Benutzer werden diesen Rollen anschließend über Role Mappings zugeordnet.

Mandantenbenutzer sollten grundsätzlich nur Leserechte erhalten. Administrative Rechte auf Pipelines, Templates, Rollen, Indexverwaltung oder Wazuh-Konfigurationen gehören nicht in eine Mandantenrolle.

Alternativ können alle Alerts weiterhin in wazuh-alerts-* gespeichert und über DLS gefiltert werden:

{
  "term": {
    "agent.labels.tenant": "tenant_a"
  }
}

Getrennte Indizes bieten eine klarere Sicherheitsgrenze, vereinfachen unterschiedliche Aufbewahrungsrichtlinien und reduzieren die Abhängigkeit von einer korrekten DLS-Abfrage. DLS vermeidet dagegen eine große Anzahl kleiner Indizes und zusätzlicher Shards.

8. Wazuh-API-Rechte separat einschränken

Die Indexer-Rolle schützt den Zugriff auf indexierte Dokumente. Sie beschränkt jedoch nicht automatisch alle Abfragen an die Wazuh Server API.

Für Benutzer, die sich direkt am Wazuh Dashboard anmelden, müssen daher zwei Berechtigungsebenen berücksichtigt werden:

Wazuh-Indexer-Rollen für Alerts und Indexdaten
Wazuh-Server-RBAC für Agenten, Gruppen und Managementfunktionen

Wazuh unterstützt RBAC-Ressourcen wie einzelne Agenten und Agentengruppen. Damit kann beispielsweise ein Benutzer auf die Agenten seiner zugewiesenen Gruppe beschränkt werden.

Eine Mandantentrennung ist erst dann vollständig, wenn beide Ebenen konsistent konfiguriert sind.

9. Stateful-Indizes besonders behandeln

Neben den klassischen Alert-Indizes verwendet Wazuh verschiedene zustandsorientierte Indizes, unter anderem für:

Vulnerability Detection
Hardware- und Betriebssysteminventar
installierte Pakete
Prozesse und Ports
Benutzer und Gruppen
Dienste
Browser-Erweiterungen
Windows-Hotfixes

Diese Daten befinden sich in Indexmustern wie:

wazuh-states-vulnerabilities-*
wazuh-states-inventory-*

Wazuh dokumentiert diese Muster getrennt von wazuh-alerts-*.

Es darf nicht vorausgesetzt werden, dass jedes Dokument in diesen Indizes dasselbe benutzerdefinierte Mandantenlabel wie ein Alert enthält. Vor der Freigabe an Mandanten müssen deshalb für jedes verwendete wazuh-states-*-Muster die tatsächlichen Dokumentfelder und Mappings geprüft werden.

Beispiel:

GET wazuh-states-vulnerabilities-*/_search
{
  "size": 1,
  "_source": [
    "agent.id",
    "agent.name",
    "agent.labels",
    "tenant"
  ]
}

Fehlt ein verlässliches Mandantenmerkmal, kann eine DLS-Regel auf agent.labels.tenant diese Dokumente nicht sicher trennen.

Die konservative Vorgehensweise lautet daher:

Mandanten standardmäßig keinen Zugriff auf wazuh-states-* geben.
Zugriff erst nach einer Prüfung jedes relevanten Indextyps freischalten.
Alternativ getrennte Wazuh-Umgebungen einsetzen, wenn Vulnerability- und Inventardaten zwingend vollständig mandantenfähig bereitgestellt werden müssen.
Keine zukünftige Produktfunktion als Grundlage einer heutigen Sicherheitsarchitektur einplanen.

Lessons Learned / Best Practices

Mandantentrennung beginnt bei der Datenerfassung

Je früher ein Ereignis einer eindeutigen Sicherheitsdomäne zugeordnet wird, desto geringer ist der spätere Aufwand. Eine Trennung erst im Dashboard ist deutlich schwächer als eine Zuordnung bereits am Relay und am Agenten.

Ein Relay-Agent sollte genau einer Vertrauensdomäne entsprechen

Mehrere Geräte desselben Mandanten können einen Relay gemeinsam nutzen. Mehrere Mandanten sollten dagegen nicht über denselben Agenten laufen, wenn Agent-Labels oder die Agentenidentität zur Autorisierung verwendet werden.

Labels als unveränderliche Stammdaten behandeln

Mandantenlabels sollten:

zentral verwaltet werden,
einem festen Namensschema folgen,
keine Leerzeichen oder wechselnden Anzeigenamen enthalten,
nicht lokal durch Mandantenadministratoren änderbar sein,
vor der Indexierung validiert werden.

Geeignete Werte sind beispielsweise:

tenant_a
customer_0127
business_unit_north

Anzeigenamen können später im Dashboard gepflegt werden. Das technische Label sollte stabil bleiben.

Formatänderungen immer mit Originalereignissen testen

Auch kleine Änderungen am Syslog-Header können Auswirkungen auf Pre-Decoder, Decoder und Regeln haben. Deshalb sollte jede Gerätekategorie mit realen Ereignissen getestet werden:

Firewall
VPN-Gateway
Router
Switch
Wireless Controller
Proxy
Load Balancer
IDS/IPS

Ein erfolgreicher Transport allein beweist noch nicht, dass die gewünschte Regel ausgelöst wird.

Updates als Teil des Designs berücksichtigen

Anpassungen an Filebeat-Templates oder der Wazuh-Ingest-Pipeline sind upgrade-relevant. Folgende Artefakte gehören deshalb in eine Versionsverwaltung:

rsyslog-Konfiguration
Wazuh-Gruppenkonfiguration
Agent-Labels
Ingest-Pipeline-Erweiterungen
Index-Templates
ISM-Richtlinien
Indexer-Rollen
Wazuh-RBAC-Rollen
automatisierte Funktionstests

Nach jedem Update sollte ein Testereignis pro Mandant gesendet und kontrolliert werden.

Getrennte Indizes nicht unkontrolliert skalieren

Ein Index pro Mandant und Tag kann bei vielen kleinen Mandanten eine sehr große Anzahl kleiner Shards erzeugen. Das belastet Clusterzustand, Arbeitsspeicher und Verwaltung.

Je nach Anzahl und Datenvolumen sind folgende Varianten abzuwägen:

Wenige große Mandanten:
  getrennte Indizes pro Mandant

Viele kleine Mandanten:
  gemeinsamer Index mit DLS

Besonders hohe Schutzanforderungen:
  getrennte Wazuh-Umgebungen

Dashboard-Tenants, Indexrechte und API-RBAC gemeinsam testen

Ein aussagekräftiger Berechtigungstest sollte mindestens prüfen:

Kann Mandant A Alerts von Mandant B suchen?
Kann Mandant A einen fremden Index direkt abfragen?
Kann Mandant A fremde Agenten über die Wazuh API auflisten?
Kann Mandant A Vulnerability-Daten fremder Agenten sehen?
Kann Mandant A globale Dashboards oder Data Views verändern?
Kann Mandant A über eine zusätzliche Rolle die Einschränkung umgehen?
Enthalten Dokumente ohne Mandantenlabel möglicherweise sensible Daten?

Erst wenn alle Ebenen erfolgreich geprüft wurden, sollte ein Mandantenzugang produktiv freigeschaltet werden.

Fazit

Für die Trennung von Syslog-Daten in einer mandantenfähigen Wazuh-Umgebung ist ein Wazuh Agent auf einem vorgelagerten Linux-Syslog-Relay die stabilste Lösung mit den geringsten Auswirkungen auf vorhandene Decoder und Regeln.

Der Relay nimmt die ursprünglichen Syslog-Nachrichten entgegen, schreibt sie möglichst unverändert in eine lokale Datei und überträgt sie anschließend im Kontext einer eindeutigen Wazuh-Agentenidentität. Ein zentral konfiguriertes Agent-Label ergänzt jedes erzeugte Alert-Dokument um ein belastbares Mandantenmerkmal.

Dieses Label kann zwar nicht als Bedingung im klassischen Wazuh-Regelwerk verwendet werden, steht aber für Dashboards, Indexer-Rollen, Document-Level Security und nachgelagertes Index-Routing zur Verfügung.

Für eine vollständige Mandantentrennung müssen vier Ebenen gemeinsam betrachtet werden:

Syslog-Relay und Agentenidentität
              +
Mandantenlabel im Alert
              +
Indexrechte oder getrennte Indizes
              +
Wazuh-API-RBAC

Besondere Vorsicht ist bei wazuh-states-*-Indizes erforderlich. Dashboard-Multi-Tenancy isoliert gespeicherte Dashboard-Objekte, ersetzt aber keine Datenzugriffskontrolle. Solange zustandsorientierte Daten nicht anhand eines verlässlichen Mandantenmerkmals getrennt werden können, sollten Mandanten keinen direkten Zugriff auf diese Indizes erhalten.