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
- 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 und verteilte Spokes.Test phase
Ein verwaltetes Overlay, das Filialen, Cloud-Ausgänge und mobile Nutzer mit einer zentralen Richtlinien-Ebene verbindet. 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 Agenten
- Zentrale Verteilung von Richtlinien und Identität
- Kontinuierliches Failover unter 10 Sekunden zwischen Hubs
- Strukturierte Observability-Pipeline in das SIEM Ihrer Wahl
- Mehrmandantenfähiges Betriebsmodell verfügbar
- Failover-Probes gegen Endpunkte, die mit dem Hub gemeinsam ausfallen können
- Übermäßige Auslastung eines einzelnen Hubs jenseits der gemessenen Kapazität
- Spokes ohne Fallback auf den Backup-Hub belassen