Ein eigenes Wazuh-SOC bauen oder eines einsetzen, das bereits fertig ist

Was Sie bauen müssen

Wazuh ab Werk liefert einen Manager, einen Indexer und einen Agent. Alles darüber ist das eigentliche Projekt: Manager und Indexer pro Kunde, eine Control Plane für deren Provisionierung, Mandantenisolation auf Datenbankebene, Netzwerk-Policies, die Verkabelung für das Agent-Enrollment, ein Triage-Workflow und Upgrade-Tooling. Jedes Teil ist für sich machbar; die Integration aller Teile, und sie integriert zu halten, während Kunden dazukommen, ist der Punkt, an dem die Engineering-Monate anfallen. Kommt eine AI-Triage-Schicht dazu, gehören Ihnen außerdem Prompts, die Tool-Orchestrierung gegen Wazuh und Ihre Anreicherungsquellen, Guardrails, damit das Modell nichts schließt, was es nicht schließen sollte, Token-Budgets und ein Review-Workflow um all das herum.

SocTalk liefert diese Teile fertig montiert: eine Control Plane, die Wazuh-Stacks pro Kunde in isolierten Kubernetes-Namespaces betreibt, Triage-Pipeline und Review-Queue inklusive. Ein deterministischer Trichter aus Deduplizierung, Zusammenführung und Korrelation löst viele Alerts vor jedem Modellaufruf, jede Eskalation durchläuft menschliche Prüfung ohne Auto-Approve-Modus, und das LLM wählen Sie pro Mandant, einschließlich eines vollständig lokalen Ollama. Alles ist Apache 2.0, das Chart zielt auf Standard-Kubernetes 1.30+, und eine Produktionsinstallation dauert auf einem vorbereiteten Cluster ungefähr eine Stunde.

Mandantenisolation

Mandantenfähigkeit ist die Designentscheidung, die früh richtig getroffen werden muss, und auf dem DIY-Weg müssen Sie sie selbst nachweisen. Das bedeutet Row-Level-Security-Policies auf jeder mandantenbezogenen Tabelle, Mandantenidentität durch jede Query und jedes Dashboard gezogen, Netzwerk-Policies und Ressourcen-Quotas pro Mandant sowie eine Testsuite, die zeigt, dass mandantenübergreifende Queries tatsächlich fehlschlagen. Die Provisionierungsskripte, die Sie für Kunde drei schreiben, müssen auch für Kunde dreißig noch funktionieren.

SocTalk erzwingt FORCE ROW LEVEL SECURITY auf jeder mandantenbezogenen Postgres-Tabelle, abgesichert durch sieben Isolationstests, die in der CI bestehen müssen. Jeder Kunde erhält einen dedizierten Wazuh-Manager und -Indexer im eigenen Namespace, mit Cilium NetworkPolicy, ResourceQuota und mandantenbezogenen Agent-Enrollment-Secrets. Der Stack ist bis ~50 Mandanten auf einem 3-Node-Cluster getestet; rechnen Sie mit ungefähr 6 bis 8 GB RAM und 1.5 vCPU pro persistentem Mandanten.

Onboarding und Upgrades

In einem selbst gebauten Stack ist jeder neue Kunde ein Runbook: die Wazuh-Instanz hochziehen, DNS und Enrollment-Secrets verdrahten, Dashboards bauen und alles wieder an das zentrale Tooling anschließen, das Sie geschrieben haben. Upgrades multiplizieren sich auf dieselbe Weise. Wazuh-Versionssprünge mal Kundenzahl, Schema-Migrationen, Zertifikatsrotation und der Kubernetes-Lebenszyklus summieren sich zu wiederkehrender Engineering-Zeit, die mit jedem Mandanten wächst.

SocTalk onboardet aus der Control Plane. Die Provisionierung durchläuft neun geordnete Phasen mit idempotentem Retry und erstellt Namespace, Quotas, Wazuh-Stack und Enrollment-Endpunkt; Agents enrollen über hostnamen-geroutetes Ingress mit mandantenbezogenen Secrets. Die DNS- und Load-Balancer-Verdrahtung pro Mandant ist in V1 noch manuell, und ein 'provided'-Profil bindet ein Wazuh an, das Sie bereits betreiben. Beide Charts aktualisieren sich per helm upgrade mit automatisch angewendeten Datenbankmigrationen; flottenweite Upgrades sind heute allerdings eine dokumentierte manuelle Schleife über die Mandanten-Namespaces, eine Fleet-Upgrade-API steht auf der Roadmap und ist nicht ausgeliefert.

Was es kostet

Lizenzgebühren liegen auf beiden Wegen bei null. Wazuh ist Open Source, und SocTalk ist Apache 2.0 ohne Community/Enterprise-Aufteilung und ohne Feature-Gates. Der Unterschied liegt darin, wo die Ausgaben anfallen. Ein DIY-Aufbau kostet vorab Engineering-Monate plus die laufende Zeit für den Betrieb, ein fairer Tausch, wenn die Plattform der Ort ist, an dem Ihr Team arbeiten soll. Mit SocTalk zahlen Sie für Ihre eigene Infrastruktur und LLM-Tokens, in der Größenordnung von $9 pro Tag und Mandant bei 30 Alerts pro Tag in einem Budget-Setup, stark variabel, oder null Kosten pro Token mit einem lokalen Ollama.

Wann der Eigenbau sinnvoll ist

SocTalk setzt eine Wazuh-Datenebene voraus. Die Datenebene von SocTalk ist heute ausschließlich Wazuh; andere SIEMs sind machbare Ergänzungen der Tool-Oberfläche, aber keine wird ausgeliefert. Eine auf Splunk oder Elastic ausgerichtete Praxis ist mit eigener Integrationsarbeit besser bedient.

Bauen Sie auch dann selbst, wenn die SOC-Plattform selbst Ihr Produktdifferenzierer ist. Eigene Korrelationslogik, eine proprietäre Analystenerfahrung und Workflows, die Ihre Wettbewerber nicht kopieren können, sprechen alle dafür, jede Schicht selbst zu besitzen, und eine fertige Plattform stünde Ihnen dabei überwiegend im Weg.

Wenn Sie wirklich unsicher sind: Der Quellcode liegt unter Apache 2.0 auf github.com/soctalk/soctalk. Lesen Sie die RLS-Policies, das Netzwerkmodell und die Triage-Pipeline, bevor Sie entscheiden. Im schlechtesten Fall gehen Sie mit einer funktionierenden Referenzarchitektur für Ihren eigenen Aufbau heraus.

Was Sie in beiden Fällen behalten

SocTalk läuft auf Ihrem eigenen Kubernetes, von der Bare-Metal-Maschine bis zu EKS, AKS oder GKE, bei Bedarf air-gapped, mit frei wählbarem LLM pro Mandant, einschließlich eines vollständig lokalen. Selbsthosting ist auf beiden Wegen die Konstante. Sie behalten Ihre Infrastruktur und Ihre Daten, und die Kundenbeziehung läuft nie über einen Anbieter.

Es ist der DIY-Stack mit bereits erledigter Montage, und die Lizenz bedeutet, dass die Obergrenze dieselbe ist wie beim Eigenbau: Alles im Repo ist Apache 2.0, es gibt keine zurückgehaltene Enterprise-Stufe, und wenn Sie mit der Richtung des Projekts irgendwann nicht einverstanden sind, können Sie es forken und weiter betreiben.