Verteilte Durchsetzung, zentrale Richtlinien, automatisches Failover und Failback.
Dieselbe Engine, die auf einer einzelnen Box im Standalone-Modus läuft, arbeitet im SASE-Modus an Ihren Hubs. Spokes wählen sich über ein verschlüsseltes Overlay ein. Richtlinien werden am Eingang durchgesetzt. Die Identität reist mit dem Nutzer. Failover ist automatisch: Die Konsole wartet eine konfigurierbare Stille-Schwelle ab, bestätigt mit einem Health-Check und verschiebt dann jeden Spoke in einem Vorgang.
Vier Formen, ein Overlay. Der Bestand entscheidet, welche.
Keine neuen Protokolle zu lernen: die Zedmos-Engine, die Sie bereits kennen, eingebettet in ein verwaltetes Overlay, das Filialen, Cloud-Ausgänge und Remote-Personen mit einer gemeinsamen Richtlinien-Ebene verbindet. Welche Form es annimmt, ist eine Entscheidung auf der Canvas — ein Hub, ein Hub-Paar, direkte Tunnel zwischen den Spokes, die sie brauchen, oder jeder Standort mit jedem. Sitzen beide Enden eines Paares hinter einem NAT, das Ports umschreibt, trägt ein Relay im Stack der Konsole die Pakete, ohne je einen Schlüssel zu halten.
Hub and Spoke
Alles erreicht eine Stelle. Beginnen Sie hier, wenn nichts dagegen spricht.
Verkehr zwischen zwei Standorten nimmt den Umweg — und wird dabei geprüft.
Dual-Hub
Ein Ausfall am Hub-Standort darf die anderen Standorte nicht mitnehmen.
Ein zweiter lauschender Hub. Er hält nur Host-Routen, bis er gebraucht wird.
Spoke-Shortcut
Zwei Standorte sprechen so viel miteinander, dass der Umweg echte Zeit kostet.
Dieser Verkehr passiert den Hub nicht mehr und wird dort auch nicht mehr geprüft.
Full Mesh
Jedes Paar spricht mit jedem. Auf acht Standorte begrenzt.
Jeder Standort trägt einen Peer für jeden anderen, und ein Knoten vermittelt weiterhin.
Wenn der Primär-Hub nicht mehr antwortet, verschiebt die Konsole die Standorte — und holt sie zurück.
Der Monitor der Konsole beobachtet die Agent-Verbindung jedes Primär-Hubs. Nach der Stille-Schwelle der Topologie verschiebt er jeden Spoke in einem Vorgang auf den Backup-Hub und holt ihn zurück, sobald der Primär-Hub über ein stabiles Zeitfenster gesund war. Sie können den Wechsel auch selbst auslösen — mit einer Vorschau dessen, was sich genau ändert.
Vier Fragen zu jeder Verbindung, nicht eine.
Ein Schlüssel weist ein Gerät nach, mehr nicht. Der Fernzugriff beantwortet hier stattdessen vier Fragen: wer die Person ist, worauf sie zugreifen darf, ob das heute noch gilt und in welchem Zustand die Maschine ist. Das sind vier der fünf Aussagen, die die Branche unter ZTNA 2.0 führt — die fünfte, eine Datenrichtlinie bis in SaaS-Mandanten hinein, erheben wir nicht: die Prüfung erfolgt inline, geprüft wird also, was den Hub passiert, nicht was bereits in einem SaaS-Mandanten liegt.
Wer die Person ist
Die Registrierung kann eine Anmeldung bei Ihrem eigenen Provider verlangen, bevor überhaupt ein Schlüssel entsteht, mit Mehrfaktor-Anforderung über den amr-Claim des Tokens. Das Gerät trägt diese Identität danach mit sich, und der Hub kann die Person hinter einem Paket benennen.
Worauf sie zugreifen darf
Eine Zugriffsgruppe gewährt benannte Anwendungen — eine Adresse und die Ports, auf denen der Dienst antwortet — statt des Netzes, in dem der Dienst steht. Der Hub schreibt je Anwendung und Person eine Regel und verwirft den Rest; der Client routet nur, was er erreichen darf.
Ob das noch gilt
Eine Frist versetzt das Gerät in die erneute Anmeldung, eine Erinnerung geht raus, und nach Ablauf wird das Gerät am Hub abgeschaltet, bis sich die Person erneut anmeldet. Meldet das Verzeichnis das Konto als deaktiviert, geschieht dasselbe, ohne die Frist abzuwarten.
Auf welcher Maschine
Der Gerätezustand wird aus dem Managementsystem gelesen, das Sie ohnehin betreiben — Microsoft Intune oder CrowdStrike Falcon — und nie von einem Agenten von uns. Eine als nicht konform gemeldete Maschine wird abgeschaltet und kommt von selbst zurück, sobald sie gesund ist; eine Maschine, für die niemand sprechen kann, behält ihren Zugriff, sofern Sie nicht die strenge Lesart verlangen.
Was es nicht ist: Es gibt keinen Reverse-Proxy und keinen reinen Browser-Zugriff, jede Person verbindet sich also mit einem gewöhnlichen WireGuard-Client, und Berechtigungen gelten je Anwendung, nicht je URL. Verhalten wird nicht bewertet. Zugelassener Verkehr wird weiterhin am Hub geprüft — Angriffserkennung, URL-Filter, TLS-Prüfung, Data-Loss-Prevention — genau der Teil, den die meisten Zugriffs-Broker auslassen.
Fünf Schritte zu einem aktiven SASE-Overlay
Ein gehärteter Orchestrator verwaltet Topologie, Richtlinien-Verteilung, Identitätszuordnung und Failover. Er läuft auf einem Knoten für kleinere Bereitstellungen oder als redundantes Paar im Produktivbetrieb.
- Mehrmandantenfähiges Topologie-Modell
- Gehärteter Datenspeicher mit rollenbasiertem Zugriff
- Zentrale Quelle der Wahrheit für Richtlinien und Identitäten
Hub-Knoten betreiben die Zedmos-Engine im Routed-Modus mit einer dedizierten verschlüsselten Schnittstelle. Jeder Spoke-Flow durchläuft am Hub DPI, Richtlinien-Auswertung, TLS-Inspektion und Protokollierung.
- Dieselbe Engine wie in der Konsole — ein Binary, ein Verhalten
- Inline-DPI und Richtlinien-Durchsetzung am Eingang
- Primär- und Backup-Hub als Active-Standby-Paar
Ein Spoke kann eine OPNsense- oder pfSense-Appliance in der Filiale, ein kompaktes Linux-Gateway oder ein mobiler Nutzer mit einem Standard-WireGuard-Client sein. Appliances registrieren sich mit einem Token; mobile Nutzer melden sich mit einem Einmal-Link an.
- Tokenbasierte Registrierung für Filial-Appliances
- Standard-WireGuard-Clients für mobile Nutzer
- Automatische Wiederverbindung und Schlüsselwechsel
Verzeichnisdienste liefern Nutzer, Gruppen und Geräteerkennung an den Hub. Jeder Flow wird bei der Inspektion markiert, sodass Richtlinien Menschen unterscheiden — nicht nur Adressen. Eine getrennte Verbindung bindet eine Remote-Person bei der Registrierung: Ihr eigener OpenID-Connect-Provider, mit verlangtem Multi-Faktor-Nachweis, bevor ein Schlüssel entsteht.
- Active Directory über Domänencontroller-Agent
- Entra / Azure AD über Microsoft Graph
- SCIM-Integration mit Okta und kompatiblen IDPs
- Ihr eigener OpenID-Connect-Provider für die Registrierung, MFA verlangt
- Gerätezustand aus Microsoft Intune oder CrowdStrike Falcon
Je Topologie aktivierbar: Die Konsole beobachtet die Agent-Verbindung des Primär-Hubs und verschiebt nach Stille-Schwelle und Health-Check jeden Spoke auf den Backup-Hub. Das Failback erfolgt automatisch, sobald der Primär-Hub stabil ist.
- Stille-Schwelle und Cooldown je Topologie
- Vorschau vor einem manuellen Wechsel
- Automatisches Failback auf den bevorzugten Hub