Drei Referenzarchitekturen. Eine Engine im Zentrum jeder davon.
Ein Betriebsleitfaden für die gängigen Topologien. Zu jedem Szenario finden Sie Plattform-Anforderungen, Betriebseigenschaften und die Anti-Muster, die in der Praxis am häufigsten Reibung verursachen.
Ein Standort, eine Plattform, Inline oder Routed.
Der kürzeste Weg von der Evaluierung bis in die Produktion. Eine einzelne gehärtete Appliance beherbergt den gesamten Zedmos-Stack — Engine, Richtlinien, Identitätszuordnung und Verwaltungsoberfläche.
- OPNsense 24.x oder neuer oder pfSense CE 2.8.x
- Multi-Queue-fähige 1-GbE- oder 10-GbE-Schnittstelle
- Vier CPU-Kerne und 8 GB RAM für Inspektion in der Gigabit-Klasse
- Acht CPU-Kerne und 16 GB RAM für Inspektion in der 10-Gbit-Klasse
- Ein Fast-Path-fähiger Schnittstellen-Treiber — bei der Installation validiert
- Lokale Verwaltungsoberfläche direkt auf der Appliance
- Lokaler Ereignis-Speicher mit optionaler SIEM-Weiterleitung
- Hot-Reload für Richtlinien und Threat Intelligence
- Reversible, nicht-destruktive Installation
- Direkter Start in der Durchsetzung ohne vorherige Monitor-Baseline
- Vermengen von Alt-Filterstacks im selben Datenpfad
- Betrieb auf nicht unterstützten Treibergenerationen ohne Preflight-Validierung
Zwei Appliances mit synchronisiertem Zustand.
Ein redundantes Paar im Active-Standby-Betrieb. Richtlinien, Identität und Laufzeitzustand bleiben synchron, sodass ein Ausfall des Primärsystems für Nutzer unsichtbar bleibt.
- Zwei identische Appliances
- Dedizierte Synchronisationsschnittstelle
- Virtuelle IP auf LAN- und WAN-Seite
- Identischer Engine-Build und identische Richtlinien-Generation auf beiden Knoten
- Richtlinien- und Identitätszustand in Echtzeit gespiegelt
- Health-bewusste Übernahme mit Operator-Override
- Eine einzige Verwaltungsoberfläche für beide Knoten
- Wiederherstellung nach Split-Brain per Klick
- Unterschiedliche Engine-Builds auf den beiden Knoten
- Synchronisation über ein überlastetes LAN-Segment
- Preempt aktiv lassen, während der Synchronisationslink degradiert ist
Hub-Paar, Orchestrator, verteilte Spokes — in einer von vier Formen.GA
Ein verwaltetes Overlay, das Filialen, Cloud-Ausgänge und Remote-Personen mit einer zentralen Richtlinien-Ebene verbindet — in der Form, die der Bestand braucht: ein Hub, ein Hub-Paar, direkte Tunnel zwischen den Spokes, die sie brauchen, oder Full Mesh. Die Durchsetzung ist verteilt; Richtlinien, Identität und Observability sind zentralisiert.
- Zwei Hub-Knoten (Bare-Metal oder virtualisiert) mit jeweils acht Kernen und 16 GB
- Gehärteter Orchestrator mit repliziertem Datenspeicher
- Erreichbare öffentliche Endpunkte für beide Hubs
- Spokes: Filial-Appliances, kompakte Linux-Gateways oder mobile Nutzer mit Standard-WireGuard-Clients
- Zentrale Verteilung von Richtlinien und Identität
- Automatisches Hub-Failover und -Failback, orchestriert von der Konsole
- Strukturierte Observability-Pipeline in das SIEM Ihrer Wahl
- Mehrmandantenfähiges Betriebsmodell verfügbar
- Die Konsole am selben Standort wie den Primär-Hub betreiben — die Konsole ist es, die die Spokes verschiebt
- Übermäßige Auslastung eines einzelnen Hubs jenseits der gemessenen Kapazität
- Spokes ohne Fallback auf den Backup-Hub belassen