Dieselbe Plattform, dieselben Detections, dieselbe KI. Installiert auf Ihrem eigenen OpenShift, Kubernetes oder Ihren Red-Hat-Servern und vollständig air-gapped, wenn Ihre Richtlinien es verlangen.
Manche Daten dürfen das Gebäude nicht verlassen. Mit LogPulse On-Premises kommt die Plattform zu den Daten, nicht umgekehrt.
Logs, Detections, Cases und KI-Gespräche werden auf Ihrer eigenen Hardware gespeichert und verarbeitet. Nichts wird an uns gesendet, es sei denn, Sie entscheiden sich dafür.
Installation, Updates, Threat Intelligence und KI funktionieren in einem vollständig isolierten Netzwerk. Updates kommen als signierte Pakete, die Sie selbst einspielen.
On-Premises ist keine abgespeckte Edition. Sie erhalten dieselbe Suche, dasselbe SIEM, dieselbe Service Intelligence und dieselben Pipelines aus derselben Codebasis.
Ihr eigenes Team betreibt den Stack mit unserem Support, oder wir verwalten ihn aus der Ferne über eine rein ausgehende Verbindung, die Sie kontrollieren.
LogPulse wird als Container mit einem einzigen Installationspaket geliefert und landet so auf der Plattform, die Sie bereits betreiben.
Läuft unter dem standardmäßigen Restricted-Sicherheitsprofil, ohne privilegierte Container oder feste User-IDs. Nutzt die Operatoren und den Speicher, die OpenShift bereits bietet.
Jede konforme Kubernetes-Distribution, etwa Rancher, Tanzu oder Upstream-Kubernetes. Installiert mit einem Paket und einer Values-Datei.
Noch kein Kubernetes? Wir liefern eine skriptgesteuerte Installation eines gehärteten, schlanken Kubernetes auf Red Hat Enterprise Linux mit SELinux im Enforcing-Modus. Von einer einzelnen VM für ein Pilotprojekt bis zum Cluster für die Produktion.
Jedes Event nimmt denselben Weg und jede Schicht skaliert und fällt unabhängig um.
Ihr Netzwerk
Schlanke Agents auf Ihren Servern, dazu OpenTelemetry, Syslog und HTTP. Die Agents werden von Ihrem eigenen Stack installiert und aktualisiert.
Authentifiziert jede Quelle, wendet Kontingente an und nimmt Daten auch dann an, wenn der Rest des Stacks ausgelastet ist.
Ein replizierter Stream fängt Spitzen und Ausfälle ab. Rohe Events lassen sich erneut abspielen, wenn sich ein Parser oder eine Pipeline ändert.
Parsing, Anreicherung, Stream-Pipelines, Detections und Alerting laufen als horizontal skalierende Worker.
Ein replizierter spaltenorientierter Log-Speicher für schnelle Suche über Monate an Daten, daneben ein relationaler Speicher für Konfiguration, Cases und Benutzer.
Der KI-Investigator und die Agents laufen auf Open-Source-Modellen in Ihrem Netzwerk, auf Ihren eigenen GPUs.
Threat Intelligence, Detection-Regeln und Schwachstellendaten kommen als signierte Offline-Pakete oder werden automatisch abgerufen, wo eine Verbindung erlaubt ist.
Ältere Daten wandern automatisch von schnellem NVMe in S3-kompatiblen Objektspeicher und bleiben durchsuchbar. Auch die Backups liegen dort. Aus Ihrer Plattform oder mit dem Stack geliefert.
Alle Komponenten laufen in Ihrem eigenen Cluster. Der Zugriff erfolgt über Ihren eigenen Identity Provider und jede Aktion landet in einem manipulationssicheren Audit-Log.
Sie bestimmen, wie viel Kontakt der Stack zur Außenwelt hat. Der Funktionsumfang bleibt gleich.
Der Stack erhält Updates, Intelligence und optional Cloud-KI direkt von LogPulse. Der geringste Betriebsaufwand.
Keine eingehenden Ports. Der Stack ruft Updates und Intelligence nur über Ihren Proxy ab und die gesamte KI läuft lokal.
Überhaupt keine Netzwerkverbindung. Releases und Intelligence kommen als signierte Pakete, die Lizenz ist eine Offline-Datei und die KI läuft lokal.
Der KI-Investigator und die Agents arbeiten On-Premises mit Open-Weight-Modellen auf Ihren eigenen GPUs. Kein Prompt, keine Logzeile und keine Antwort verlässt Ihr Netzwerk.
Der Investigator arbeitet sich durch Ihre Logs, prüft Hypothesen und zeigt zu jeder Schlussfolgerung die Belege.
Stellen Sie eine Frage in Ihren eigenen Worten und erhalten Sie die Abfrage und die Antwort, bereit zum Speichern oder Verfeinern.
Agents entwerfen und testen Detection-Regeln mit Ihren Daten. Ein Mensch prüft und veröffentlicht immer.
Alerts und Cases kommen zusammengefasst an, mit der wahrscheinlichen Ursache und den nächsten Schritten.
Kompakt
Kleines Team oder Pilot
Team
Security- und Operations-Teams
SOC
Rund um die Uhr, mehrere Standorte
Open-Weight-Modelle werden schnell besser, sind bei langen Untersuchungen mit vielen Schritten aber noch nicht so stark wie die besten Cloud-Modelle. Wir testen jedes unterstützte Modell mit unserem eigenen Evaluationsset und empfehlen nur Modelle, die bestehen. Wo Ihre Richtlinien es erlauben, kann ein verbundener Stack auch unsere EU-Cloud-Modelle nutzen.
Drei Startprofile. Die Dimensionierung Ihres Stacks erarbeiten wir gemeinsam anhand von Volumen, Aufbewahrung und Suchlast.
| Profil | PilotProof of Concept und Test | StandardProduktion mit Hochverfügbarkeit | GroßTerabytes pro Tag, mehrere Standorte |
|---|---|---|---|
| Log-Volumen | Bis zu 50 GB pro Tag | Bis zu 500 GB pro Tag | Von 500 GB bis zu mehreren TB pro Tag |
| Nodes | 1 VM oder Node | 6 nodes | 9 Nodes oder mehr |
| Applikations-Nodes | Geteilt mit Daten: 16 vCPU, 64 GB RAM | 3 × 8 vCPU, 32 GB RAM | 3 oder mehr × 16 vCPU, 64 GB RAM |
| Daten-Nodes | Derselbe Node | 3 × 16 vCPU, 64 GB RAM | 4 oder mehr × 32 vCPU, 128 GB RAM |
| Speicher pro Daten-Node | 2 TB lokales NVMe | Lokales NVMe passend zur Aufbewahrung, zum Beispiel 4 TB für 90 Tage bei 250 GB pro Tag | Lokales NVMe für aktuelle Daten, Objektspeicher für ältere Daten |
| Verfügbarkeit | Ein Node, kein Failover | Übersteht den Ausfall eines Nodes ohne Datenverlust | Mehrere Replikate, optional auf zwei Rechenzentren verteilt |
Richtwerte, ohne lokale KI. Eventgröße, Aufbewahrung und Suchlast bestimmen die endgültige Dimensionierung, die wir gemeinsam mit Ihnen erarbeiten.
Plattform
Red Hat OpenShift 4.14 oder neuer, Kubernetes 1.29 oder neuer, oder virtuelle Maschinen mit Red Hat Enterprise Linux 9 für unsere skriptgesteuerte Installation.
Schneller Blockspeicher
Lokales NVMe für die Daten-Nodes. Netzwerkspeicher genügt für die übrigen Komponenten.
S3-kompatibler Objektspeicher
Für Backups und lange Aufbewahrung. Aus Ihrer Plattform oder mit dem Stack geliefert.
Netzwerk und Zertifikate
Ein Ingress oder Load Balancer, ein DNS-Name und ein TLS-Zertifikat Ihrer eigenen Zertifizierungsstelle.
Identität und E-Mail
Single Sign-on über Ihren OIDC- oder SAML-Identity-Provider und ein SMTP-Relay für Benachrichtigungen.
Container registry
Für Air-Gapped-Installationen: eine interne Registry wie Harbor oder Quay, in die Sie das Release-Paket laden.
GPU für lokale KI (optional)
Eine oder mehrere Rechenzentrums-GPUs für den KI-Investigator und die Agents. Modell und GPU-Speicher hängen von der Zahl der Benutzer ab.
Dies ist ein Beispiel, keine Blaupause. Es zeigt, wie sich der Stack auf zwei Rechenzentren und einen dritten Standort verteilt, damit der Ausfall eines ganzen Standorts weder Annahme noch Suche stoppt.
Agents und Quellen an allen Standorten
Load Balancer oder globales DNS
Leitet den Verkehr an beide Rechenzentren und verlagert ihn bei Ausfall automatisch
Rechenzentrum A
2 × Applikation
16 vCPU, 64 GB RAM
2 × Stream-Puffer
8 vCPU, 32 GB RAM, 2 TB NVMe
2 × Daten
32 vCPU, 128 GB RAM, 15 TB NVMe
1 × GPU-Node
2 × NVIDIA L40S oder 1 × H100, für lokale KI
1 × Koordination
4 vCPU, 16 GB RAM
S3-Objektspeicher
Langzeitspeicher für ältere Daten und Backups, repliziert in das andere Rechenzentrum
Jedes Event liegt in beiden Rechenzentren
Rechenzentrum B
2 × Applikation
16 vCPU, 64 GB RAM
2 × Stream-Puffer
8 vCPU, 32 GB RAM, 2 TB NVMe
2 × Daten
32 vCPU, 128 GB RAM, 15 TB NVMe
1 × GPU-Node
2 × NVIDIA L40S oder 1 × H100, für lokale KI
1 × Koordination
4 vCPU, 16 GB RAM
S3-Objektspeicher
Langzeitspeicher für ältere Daten und Backups, repliziert in das andere Rechenzentrum
Standort C: Witness
1 Koordinations-Node mit 4 vCPU und 16 GB RAM hält die Mehrheit, wenn ein Rechenzentrum ausfällt
Ein Rechenzentrum darf ausfallen
Annahme und Suche laufen im anderen Rechenzentrum weiter. Kommt es zurück, holt es den Rückstand selbst auf.
Zwischen den Standorten
Höchstens 5 ms Round-Trip-Zeit und mindestens 10 Gbit/s zwischen den Rechenzentren. Der Witness braucht nur eine bescheidene Verbindung.
Wächst in Schritten
Mehr Volumen bedeutet mehr Daten-Nodes, mehr Benutzer bedeuten mehr Applikations- und GPU-Kapazität. Jede Schicht skaliert für sich.
Planbare Releases, die Sie selbst prüfen können, bevor sie in Produktion gehen.
Jeden Monat ein getestetes Release, bei Bedarf mit Sicherheitsfixes dazwischen. Sie entscheiden, wann es installiert wird.
Jedes Image ist signiert und wird mit einer Software Bill of Materials geliefert, damit Ihr Security-Team prüfen kann, was läuft.
Eine signierte Lizenzdatei legt Volumen und Funktionen fest. Nutzungsberichte verlassen den Stack nur, wenn Sie sie senden.
Erzählen Sie uns von Ihrer Plattform, Ihrem Volumen und Ihren Netzwerkrichtlinien. Wir melden uns mit einer Architektur und einer Hardware-Spezifikation.
Kontakt aufnehmen