Wazuh Multi-Tenancy: Sichere Mandantentrennung für Syslog-Quellen und Netzwerkgeräte

Die mandantenfähige Nutzung von Wazuh stellt besondere Anforderungen an die Trennung sicherheitsrelevanter Ereignisse. Während sich Endgeräte mit installierten Wazuh-Agenten über Agent-Gruppen und Labels relativ einfach einzelnen Mandanten zuordnen lassen, ist die Situation bei agentenlosen Syslog-Quellen deutlich komplexer.

Insbesondere Firewalls, Switches, Router und andere Netzwerkgeräte, die ihre Logs direkt an den Wazuh Manager senden, können zu Problemen bei der Mandantentrennung führen.

In Wazuh 4.14.x besteht dabei eine wichtige technische Einschränkung: Direkt empfangene Syslog-Ereignisse werden dem internen Agenten 000 zugeordnet. Eine Unterscheidung über mandantenspezifische Agent-Gruppen ist deshalb nicht möglich.

Dieser Artikel erläutert die technischen Hintergründe, untersucht zwei Routing-Ansätze und zeigt, wie sich eine zuverlässige Mandantentrennung über einen vorgeschalteten Syslog-Relay und getrennte Logdateien realisieren lässt.

1. Ausgangslage / Problemstellung

Mandantentrennung bei Wazuh-Agenten

In einer Multi-Tenant-Umgebung betreibt eine zentrale Wazuh-Instanz die Sicherheitsüberwachung mehrerer Kunden oder organisatorisch getrennter Bereiche.

Eine typische Architektur besteht aus:

• Einem zentralen Wazuh Manager
• Einem gemeinsamen Wazuh Indexer
• Einem Wazuh Dashboard mit mandantenspezifischen Rollen
• Separaten Agent-Gruppen pro Mandant
• Individuellen Alert- und Archive-Indizes

Für Endgeräte mit Wazuh-Agenten kann die Zuordnung über Labels erfolgen.

Beispielsweise erhält Mandant 1 in seiner Agent-Gruppe folgende Konfiguration:

<agent_config>
  <labels>
    <label key="target_index">tenant1-label</label>
  </labels>
</agent_config>

Mandant 2 verwendet entsprechend:

<agent_config>
  <labels>
    <label key="target_index">tenant2-label</label>
  </labels>
</agent_config>

Die Labels erscheinen in den erzeugten Ereignissen und können anschließend für das Index-Routing verwendet werden.

Ein angepasster Filebeat-Prozessor erkennt das Mandantenlabel und setzt beispielsweise:

fields.index_prefix: wazuh-alerts-tenant1-4.x

Daraus ergeben sich getrennte Indexfamilien:

wazuh-alerts-tenant1-4.x-*
wazuh-alerts-tenant2-4.x-*

wazuh-archives-tenant1-*
wazuh-archives-tenant2-*

Für archivierte Ereignisse wird die entsprechende Zuordnung über die Ingest-Pipeline filebeat-7.10.2-wazuh-archives-pipeline vorgenommen.

Die Pipeline setzt vor dem Prozessor date_index_name den passenden Indexpräfix.

Zusätzlich müssen die Index-Templates die dynamischen Indexnamen abdecken:

{
  "index_patterns": [
    "wazuh-alerts-*"
  ]
}

Für Archive-Indizes wird entsprechend wazuh-archives-* verwendet.

Die Berechtigungen im Wazuh Dashboard beziehungsweise im Wazuh Indexer werden anschließend so eingeschränkt, dass jeder Mandant ausschließlich seine eigenen Indizes lesen darf.

Diese Architektur funktioniert grundsätzlich für agentenbasierte Ereignisse.

Das Problem bei Syslog-Quellen

Netzwerkgeräte verwenden häufig keinen Wazuh-Agenten. Stattdessen übertragen sie ihre Ereignisse direkt über Syslog an den Manager.

Eine vereinfachte Konfiguration sieht folgendermaßen aus:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.168.0.0/16</allowed-ips>
</remote>

In einer Multi-Tenant-Umgebung könnten beispielsweise folgende Geräte Logs übertragen:

Mandant	Gerät	IP-Adresse
Tenant 1	Firewall	192.168.10.1
Tenant 1	Switch	192.168.10.2
Tenant 2	Firewall	192.168.20.1
Tenant 2	Switch	192.168.20.2

Obwohl die Geräte unterschiedlichen Mandanten gehören, verarbeitet Wazuh die direkt empfangenen Syslog-Ereignisse unter dem internen Manager-Agenten 000.

Dadurch fehlt die mandantenspezifische Kennzeichnung, die bei normalen Agenten durch die jeweilige Agent-Gruppe bereitgestellt wird.

Die Folgen können erheblich sein:

1. Ereignisse landen im gemeinsamen Standardindex.
2. Ein auf dem Manager gesetztes Label könnte alle Syslog-Ereignisse demselben Mandanten zuordnen.
3. Die Mandantentrennung wird bei fehlerhafter Index- oder Rollen-Konfiguration unterlaufen.
4. Kunden könnten auf sicherheitsrelevante Ereignisse anderer Kunden zugreifen.

Das Problem ist damit nicht nur organisatorischer Natur, sondern betrifft unmittelbar die Vertraulichkeit der SIEM-Daten.

2. Technische Analyse

Warum der Wazuh Manager keine automatische Mandantenzuordnung vornimmt

Bei einem normalen Wazuh-Agenten existiert eine eindeutige Agentenidentität.

Der Manager kann diese Identität einer Gruppe zuordnen und die passenden Konfigurationsinformationen anwenden.

Bei direkt empfangenen Syslog-Nachrichten fehlt diese Identität.

Die Ereignisse werden unter Agent 000 verarbeitet, während das Feld location Informationen über die Syslog-Quelle enthält.

Ein vereinfachtes Ereignis kann folgendermaßen aussehen:

{
  "agent": {
    "id": "000",
    "name": "wazuh-manager"
  },
  "location": "172.25.0.3",
  "full_log": "firewall: connection denied"
}

Das Feld location enthält bei direkt empfangenen Remote-Syslog-Nachrichten die Quell-IP-Adresse.

Diese Eigenschaft lässt sich grundsätzlich für das Routing verwenden.

Allerdings entstehen dadurch Einschränkungen.

Ansatz 1: Mandantenzuordnung über die Quell-IP

Die einfachste Möglichkeit besteht darin, den Mandanten anhand des Feldes location zu bestimmen.

Beispielsweise:

192.168.10.1 -> tenant1
192.168.10.2 -> tenant1

192.168.20.1 -> tenant2
192.168.20.2 -> tenant2

Ein entsprechender Filebeat-Prozessor könnte die Quell-IP auswerten und den Indexpräfix setzen.

Vereinfacht:

processors:
  - if:
      equals:
        location: "192.168.10.1"
    then:
      - add_fields:
          target: fields
          fields:
            index_prefix: "wazuh-alerts-tenant1-4.x"

Die konkrete Einbindung hängt von der bestehenden Filebeat-Konfiguration und dem Zeitpunkt der Verarbeitung ab, an dem location verfügbar ist.

Für Archive-Ereignisse müsste dieselbe Zuordnung zusätzlich in der Ingest-Pipeline umgesetzt werden.

Einschränkung: Überlappende private IP-Adressen

In Multi-Tenant-Umgebungen verwenden unterschiedliche Kunden häufig dieselben privaten IP-Adressbereiche.

Beispielsweise:

Tenant 1:
Firewall -> 192.168.1.1

Tenant 2:
Firewall -> 192.168.1.1

Eine eindeutige Mandantenzuordnung anhand der IP-Adresse ist dann nicht möglich.

Noch problematischer ist, dass auch unterschiedliche Syslog-Ports dieses Problem nicht automatisch lösen.

Unterschiedliche Listener-Ports ändern location nicht

In einem Test mit einem Wazuh-Manager-Container der Version 4.14.9 wurde dasselbe Gerät über drei unterschiedliche Syslog-Listener angesprochen:

Protokoll	Port	Wert von location
UDP	10514	172.25.0.3
UDP	10515	172.25.0.3
TCP	10516	172.25.0.3

Alle Ereignisse wurden Agent 000 zugeordnet.

Das Feld location enthielt jeweils ausschließlich die Quell-IP-Adresse.

Weder der verwendete Port noch der jeweilige Listener wurden darin abgebildet.

Damit ist eine wichtige Schlussfolgerung verbunden:

Mehrere <remote>-Listener mit unterschiedlichen Ports erzeugen keine ausreichende Mandantenidentität für ein Routing über location.

Ein IP-basiertes Routing eignet sich deshalb nur dann, wenn die Quelladressen aus Sicht des Managers eindeutig und zuverlässig einem Mandanten zugeordnet werden können.

Auch bei eindeutigen IP-Adressen sollte berücksichtigt werden, dass die Quelladresse allein keine kryptografisch gesicherte Geräteidentität darstellt.

3. Lösung / Best Practices

Ansatz 2: Vorgeschalteter Syslog-Relay mit mandantenspezifischen Logdateien

Eine robustere Lösung besteht darin, den direkten Syslog-Empfang vom Wazuh Manager zu entkoppeln.

Statt sämtliche Netzwerkgeräte unmittelbar an den Manager senden zu lassen, wird ein vorgeschalteter Syslog-Dienst verwendet.

Dafür eignen sich beispielsweise:

• rsyslog
• syslog-ng

Dieser Dienst nimmt die Netzwerkereignisse entgegen, ordnet sie einem Mandanten zu und schreibt sie in getrennte Dateien.

Der Wazuh Manager liest anschließend die Dateien über <localfile> ein.

Referenzarchitektur: Mandantenspezifische Syslog-VerarbeitungDie Mandantenzuordnung erfolgt vor der Übergabe an Wazuh. Der Dateipfad dient anschließend als Routing-Merkmal.

Der entscheidende Vorteil besteht darin, dass die Mandantenidentität nicht mehr ausschließlich von der im Syslog-Ereignis enthaltenen Geräteadresse abhängt.

Stattdessen kann der Syslog-Relay zusätzliche Informationen wie den Empfangsport, die Netzwerkzone oder eine dedizierte Verbindung berücksichtigen.

Schritt 1: Separate Empfangsports für die Mandanten einrichten

Eine beispielhafte rsyslog-Konfiguration könnte folgendermaßen aussehen:

module(load="imudp")

# Tenant 1
ruleset(name="tenant1") {
    action(
        type="omfile"
        file="/var/log/tenants/t1/net.log"
        createDirs="on"
    )
}

# Tenant 2
ruleset(name="tenant2") {
    action(
        type="omfile"
        file="/var/log/tenants/t2/net.log"
        createDirs="on"
    )
}

input(
    type="imudp"
    port="10514"
    ruleset="tenant1"
)

input(
    type="imudp"
    port="10515"
    ruleset="tenant2"
)

In diesem Beispiel werden die Ereignisse anhand des Empfangsports getrennt.

UDP 10514 -> Tenant 1
UDP 10515 -> Tenant 2

Die Netzwerkgeräte müssen entsprechend konfiguriert werden.

Wichtig ist, dass diese Trennung nicht allein auf einer organisatorischen Portvereinbarung beruhen darf.

Ein Gerät von Tenant 1 darf nicht unkontrolliert an den Empfangsport von Tenant 2 senden können.

Dafür sind beispielsweise getrennte Netzwerksegmente, Firewall-Regeln, dedizierte Listener-Adressen oder authentifizierte Syslog-Verbindungen erforderlich.

Die gezeigte rsyslog-Konfiguration ist ein Implementierungsbeispiel. Der ursprüngliche technische Test bestätigte die Wazuh-seitige Dateiverarbeitung, nicht den vollständigen Betrieb des vorgeschalteten Relays.

Schritt 2: Mandantenspezifische Logdateien in Wazuh einlesen

Anschließend werden die erzeugten Logdateien über die Konfigurationsdatei ossec.conf eingebunden.

Für Tenant 1:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/tenants/t1/net.log</location>
</localfile>

Für Tenant 2:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/tenants/t2/net.log</location>
</localfile>

Bei dieser Methode ändert sich die Bedeutung des Feldes location.

Während bei direkt empfangenen Syslog-Ereignissen die Quell-IP-Adresse enthalten ist, wird bei lokal eingelesenen Dateien der Dateipfad verwendet.

Beispiel Tenant 1:

{
  "agent": {
    "id": "000"
  },
  "location": "/var/log/tenants/t1/net.log"
}

Beispiel Tenant 2:

{
  "agent": {
    "id": "000"
  },
  "location": "/var/log/tenants/t2/net.log"
}

Diese Eigenschaft wurde in einem Test mit Wazuh 4.14.9 bestätigt.

Die Syslog-Nachrichten wurden dabei direkt in die jeweiligen Dateien geschrieben. Der vollständige Weg über einen vorgeschalteten Syslog-Relay wurde nicht getestet.

Dennoch zeigt das Ergebnis, dass sich der Dateipfad als eindeutiges Routing-Merkmal für Wazuh verwenden lässt.

Schritt 3: Routing anhand des Dateipfads konfigurieren

Für die mandantenspezifische Indizierung kann nun das Feld location ausgewertet werden.

Beispielsweise lässt sich der Alert-Indexpräfix mit Filebeat-Prozessoren bestimmen.

Ein vereinfachter Konfigurationsausschnitt:

processors:
  - if:
      regexp:
        location: '^/var/log/tenants/t1/'
    then:
      - add_fields:
          target: fields
          fields:
            index_prefix: "wazuh-alerts-tenant1-4.x"

  - if:
      regexp:
        location: '^/var/log/tenants/t2/'
    then:
      - add_fields:
          target: fields
          fields:
            index_prefix: "wazuh-alerts-tenant2-4.x"

Diese Regeln setzen den Indexpräfix. Damit das Routing tatsächlich funktioniert, muss die bestehende Filebeat-Ausgabe diesen Präfix auch für die Indexauswahl verwenden.

Das Beispiel setzt außerdem voraus, dass location an dieser Stelle bereits als entsprechendes Feld verfügbar ist. Bei Konfigurationen, die das Ereignis zunächst als JSON-Zeichenkette verarbeiten, muss die Feldextraktion oder Bedingung angepasst werden.

Für Archive-Ereignisse wird eine entsprechende Zuordnung in der Ingest-Pipeline benötigt.

Eine mögliche Erweiterung ist ein set-Prozessor mit einer Painless-Bedingung:

{
  "set": {
    "if": "ctx.location != null && ctx.location.startsWith('/var/log/tenants/t1/')",
    "field": "index_prefix",
    "value": "wazuh-archives-tenant1"
  }
}

Für Tenant 2 wird ein entsprechender Prozessor ergänzt.

Diese Prozessoren müssen vor dem bestehenden date_index_name-Prozessor ausgeführt werden, sofern dieser index_prefix zur Bildung des Zielindex verwendet.

Wichtig ist dabei die Unterscheidung zwischen Alert- und Archive-Verarbeitung:

• Das Alert-Routing erfolgt in der beschriebenen Architektur über Filebeat und die Indexausgabe.
• Das Archive-Routing verwendet die angepasste Ingest-Pipeline.
• Beide Wege benötigen dieselbe verlässliche Mandantenzuordnung.

Eine nur teilweise implementierte Trennung kann dazu führen, dass Alerts korrekt separiert werden, während Archive-Ereignisse weiterhin in gemeinsamen Indizes landen.

Schritt 4: Keine alleinige Abhängigkeit von <label> bei <localfile>

Eine naheliegende Alternative wäre, den <localfile>-Einträgen direkt Mandantenlabels hinzuzufügen.

Im beschriebenen Test erschien ein auf dem <localfile> gesetztes Label jedoch weder in alerts.json noch in archives.json.

Daher konnte es nicht als zuverlässiges Routing-Merkmal verwendet werden.

Für diese Konstellation empfiehlt es sich, den Dateipfad als Mandantenkennung zu nutzen.

Die Zuordnung bleibt damit unabhängig davon, ob ein zusätzliches Label in der jeweiligen Verarbeitungskette erhalten bleibt.

Schritt 5: Indexberechtigungen und Fallback-Verhalten absichern

Die Trennung der Indexnamen allein stellt noch keine vollständige Mandantenisolierung dar.

Zusätzlich müssen die Berechtigungen des Wazuh Indexers entsprechend eingeschränkt werden.

Beispielsweise:

Rolle	Erlaubte Indexmuster
tenant1-reader	wazuh-alerts-tenant1-*, wazuh-archives-tenant1-*
tenant2-reader	wazuh-alerts-tenant2-*, wazuh-archives-tenant2-*

Die Rollen dürfen keine übergreifenden Leserechte auf wazuh-alerts-* oder wazuh-archives-* besitzen.

Besonders wichtig ist außerdem das Verhalten bei unbekannten Quellen.

Ein Standardindex wie

wazuh-archives-4.x-*

kann zwar als technischer Fallback dienen, sollte aber ausschließlich administrativ berechtigten Personen zugänglich sein.

Für sicherheitskritische Multi-Tenant-Umgebungen ist eine Quarantäne für nicht zugeordnete Ereignisse häufig sinnvoller als eine automatische Zuordnung zu einem beliebigen Mandanten.

4. Lessons Learned / Best Practices

4.1 Mandantenzuordnung möglichst früh durchführen

Je früher ein Ereignis einem Mandanten zugeordnet wird, desto geringer ist das Risiko einer Vermischung.

Ein vorgeschalteter Syslog-Relay schafft dafür eine geeignete Stelle innerhalb der Architektur.

Dort können unterschiedliche Kriterien kombiniert werden:

• Empfangsport
• Dedizierte Listener-IP
• Quellnetz oder VPN-Zugehörigkeit
• Authentifizierte Syslog-Verbindung
• Separater Relay pro Mandant

Für besonders hohe Sicherheitsanforderungen können getrennte Relays oder dedizierte Wazuh-Instanzen sinnvoll sein.

4.2 Dateipfade als stabile Routing-Merkmale nutzen

Bei über <localfile> eingelesenen Syslog-Ereignissen ist der Dateipfad ein geeignetes technisches Zuordnungsmerkmal.

Beispielsweise:

/var/log/tenants/
├── t1/
│   └── net.log
├── t2/
│   └── net.log
└── t3/
    └── net.log

Dieses Schema lässt sich für zusätzliche Mandanten erweitern.

Dabei sollte eine einheitliche Namenskonvention verwendet werden.

Auch die Dateirechte müssen berücksichtigt werden. Der Wazuh Manager benötigt Leserechte, während unberechtigte Prozesse keine Ereignisse in fremde Mandantenverzeichnisse schreiben dürfen.

4.3 Anpassungen an Filebeat upgradefähig gestalten

Ein weiterer wichtiger Punkt betrifft die Aktualisierung der Wazuh-Komponenten.

In einem Test mit einem Wazuh-Manager-Container der Version 4.14.9 wurde die Datei

/usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json

untersucht.

Dabei ergaben sich folgende Beobachtungen:

• Die Datei war keinem RPM-Paket zugeordnet.
• Die MD5-Prüfsumme war in den untersuchten Versionen 4.14.7, 4.14.8 und 4.14.9 identisch.
• Die Datei war Bestandteil des Container-Images.
• Beim Austausch des Images gingen nicht persistent gespeicherte Änderungen verloren.
• Auch eine erneute Extraktion des Filebeat-Moduls kann Anpassungen überschreiben.

Daraus folgt eine klare Betriebsempfehlung:

Eigene Anpassungen sollten nicht ausschließlich als manuelle Änderungen innerhalb eines laufenden Containers gespeichert werden.

Stattdessen sollten Konfigurationen versioniert und über einen reproduzierbaren Deployment-Prozess bereitgestellt werden.

Geeignete Verfahren sind beispielsweise:

• Versionierte Konfigurationsdateien in Git
• Container-Mounts für angepasste Dateien
• Automatisierte Konfigurationsverwaltung
• Deployment-Skripte zur erneuten Anwendung der Änderungen
• Validierung der Ingest-Pipelines nach jedem Upgrade

Dabei ist zu beachten, dass die lokal vorhandene Pipeline-Datei nicht zwangsläufig mit der aktuell im Indexer installierten Pipeline identisch ist.

Der ursprüngliche Test prüfte ausdrücklich nicht die im Indexer gespeicherte Kopie.

Deshalb sollte nach Änderungen zusätzlich die tatsächlich aktive Pipeline über die Indexer-API kontrolliert werden, beispielsweise:

GET /_ingest/pipeline/filebeat-7.10.2-wazuh-archives-pipeline

Der konkrete Pipeline-Name kann je nach Installation und Modulkonfiguration abweichen.

4.4 Alert- und Archive-Indizes gemeinsam testen

Ein erfolgreicher Test des Alert-Routings reicht nicht aus.

In einer Multi-Tenant-Architektur sollten mindestens folgende Szenarien überprüft werden:

Testszenario	Erwartetes Ergebnis
Syslog von Tenant 1	Nur Tenant-1-Indizes
Syslog von Tenant 2	Nur Tenant-2-Indizes
Identische Geräte-IP bei beiden Mandanten	Korrekte Trennung über Relay und Dateipfad
Unbekannte Syslog-Quelle	Keine Zuordnung zu einem fremden Mandanten
Fehlender Routing-Präfix	Administrativ geschützter Fallback oder Quarantäne
Filebeat-Neustart	Routing bleibt erhalten
Wazuh-Upgrade	Anpassungen bleiben wirksam oder werden reproduzierbar eingespielt
Zugriff mit Tenant-1-Rolle	Kein Zugriff auf Tenant-2-Indizes

Insbesondere negative Berechtigungstests sind wichtig.

Es genügt nicht, dass Tenant 1 seine eigenen Logs sehen kann. Zusätzlich muss nachgewiesen werden, dass Tenant 1 keine Ereignisse von Tenant 2 lesen kann.

4.5 Betriebsaspekte bei der Dateiverarbeitung berücksichtigen

Die Verwendung mandantenspezifischer Logdateien bringt zusätzliche Anforderungen mit sich.

Dazu gehören insbesondere die Logrotation, Speicherplatzüberwachung und Bereinigung alter Dateien.

Wird eine Datei rotiert oder ersetzt, muss sichergestellt sein, dass der Syslog-Dienst weiterhin korrekt schreibt und Wazuh neue Ereignisse zuverlässig einliest.

Auch die Pufferung ist wichtig.

Bei einem Neustart des Wazuh Managers sollte der Syslog-Relay eingehende Ereignisse möglichst zwischenspeichern können, damit keine sicherheitsrelevanten Informationen verloren gehen.

Bei größeren Installationen sollten außerdem die Auswirkungen zusätzlicher Dateien, Dateideskriptoren und hoher Ereignisraten berücksichtigt werden.

4.6 Indextrennung ist nicht gleich vollständige Infrastruktur-Isolation

Die beschriebene Architektur ermöglicht eine logische Trennung der Ereignisdaten.

Sie ersetzt jedoch keine vollständige Trennung der Wazuh-Infrastruktur.

Ein gemeinsamer Manager und Indexer bleiben gemeinsame Vertrauens- und Administrationsbereiche.

Für Umgebungen mit besonders strengen regulatorischen Anforderungen oder voneinander unabhängigen Administratoren können deshalb dedizierte Wazuh-Instanzen pro Mandant erforderlich sein.

Die Entscheidung hängt vom jeweiligen Bedrohungsmodell und den geforderten Isolationsgrenzen ab.

5. Fazit

Die Mandantentrennung agentenloser Syslog-Quellen in Wazuh 4.14.x erfordert eine andere Vorgehensweise als bei klassischen Wazuh-Agenten.

Da direkt empfangene Syslog-Ereignisse dem internen Agenten 000 zugeordnet werden, können mandantenspezifische Agent-Gruppen nicht als zuverlässiges Unterscheidungsmerkmal verwendet werden.

Ein Routing anhand der Quell-IP im Feld location ist technisch möglich, funktioniert jedoch nur bei eindeutig zuordenbaren Quelladressen. Unterschiedliche Syslog-Listener-Ports lösen das Problem überlappender IP-Adressbereiche nicht, da diese Informationen im untersuchten Verhalten nicht Bestandteil des Feldes location sind.

Die praktikablere Lösung besteht darin, einen vorgeschalteten Syslog-Relay einzusetzen, der Ereignisse mandantenspezifisch in getrennte Dateien schreibt.

Diese Dateien werden anschließend über <localfile> in Wazuh eingelesen. Der jeweilige Dateipfad dient als stabiles Routing-Merkmal für die Zuordnung zu getrennten Alert- und Archive-Indizes.

Für einen sicheren Produktivbetrieb sind darüber hinaus restriktive Indexberechtigungen, ein geschütztes Fallback-Verhalten, reproduzierbare Pipeline-Anpassungen und regelmäßige Isolationstests erforderlich.

Die zentrale Erkenntnis: Eine zuverlässige Multi-Tenant-Architektur muss die Mandantenidentität bereits bei der Logannahme sicherstellen und diese Identität bis zur Speicherung und Zugriffskontrolle konsequent erhalten.

Weiterführende Informationen

Die folgenden offiziellen Dokumentationen bieten zusätzliche Informationen zur Umsetzung und Absicherung der beschriebenen Architektur:

• Wazuh – Konfiguration von Syslog-Quellen
• Wazuh – Log Data Collection
• Wazuh – Filebeat-Konfiguration
• Wazuh – Indexer Security und Zugriffskontrolle
• rsyslog – Offizielle Dokumentation
• OpenSearch – Ingest Pipelines

Die dargestellten Testergebnisse beziehen sich auf Wazuh 4.14.9 und die beschriebene Konfiguration. Die vollständige Relay-Implementierung sowie das Verhalten der im Indexer installierten Pipeline müssen in der jeweiligen Zielumgebung separat validiert werden.

Mehr zu Wazuh …

Mehr zum Wazuh Ambassador Program …

https://wazuh.slack.com/archives/C0A933R8E/p1793925700121479