Zedmos

SASE & sichere Anbindung

Alle Standorte und Remote-Nutzer unter einer Policy

Ein Overlay auf WireGuard-Basis, aus der Konsole orchestriert, in der Form, die der Bestand braucht — ein Hub, ein Hub-Paar, direkte Tunnel zwischen den Standorten, die sie brauchen, oder Full Mesh. Spokes wählen aus, Hubs inspizieren, und Zugriff gehört einer Person und einer Anwendung — nicht der Adresse, die ein Paket zufällig trägt.

SASE-Overlay · eine Policy am HubStand-by · nur Host-RoutenStandorteZentrale10.0.1.0/24Niederlassung10.0.2.0/24Lager10.0.3.0/24Remote-ArbeitsplatzSchlüssel je GerätPrimärer Hubterminiert · prüft · leitet weiterBackup-HubStand-byübernimmt die Spokes, sobald der primäre nicht mehr antwortetIdentität · Active Directory · Azure AD · SCIMJede Sitzung trifft aufAnwendungskontrolleIDS / IPSTLS-InspektionKI-Sicherheit & DLPInternet & SaaSeine Policy für allesTunnel stehtStand-byVerschlüsseltes Overlay · WireGuard, OpenVPN oder GRE
Standort 1Standort 2Standort 3Standort 4Hub

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.

BackupStandort 1Standort 2Standort 3Standort 4Hub

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.

Standort 1Standort 2Standort 3Standort 4Hub

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.

Standort 1Standort 2Standort 3Standort 4Hub

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.

Aufgebauter TunnelDirekter Pfad zwischen zwei StandortenStandby-Pfad — nur Host-Routen bis zum Failover

Das Netz zu bauen heißt, es zu zeichnen

Standorte setzen und verbinden. Die Konsole schreibt die Konfiguration für beide Tunnelenden und verteilt sie — niemand öffnet eine Firewall und tippt eine Regel. Minuten, kein Nachmittag.

Die SASE-Zeichenfläche der Konsole: Gateways links gelistet, Spokes und ein primärer Hub auf einer dunklen Karte mit grünen Tunneln dazwischen, und eine Werkzeugleiste mit Failover-Klasse, Layout, Verlauf und Re-Deploy-Button.
  1. Gateways, aus dem Bestand

    Die Firewalls, die ein Kunde bereits hat, nach Standort gelistet. Auf die Fläche ziehen — und sie wird Spoke oder Hub.

  2. In dieser Form terminiert ein Hub jeden Tunnel

    Alles, was am primären Hub ankommt, trifft auf dieselbe Policy: Anwendungskontrolle, IDS/IPS, TLS-Inspektion, DLP und AI Gateway. Zeichnen Sie stattdessen einen direkten Tunnel zwischen zwei Spokes, wird deren Verkehr an beiden Enden statt in der Mitte geprüft — die Konsole sagt das, bevor Sie sich festlegen.

  3. Jeder Tunnel berichtet über sich

    Auf oder ab, Latenz, Bytes je Richtung — am Link, wo Sie hinsehen, nicht in einem Log, das Sie erst öffnen müssten.

  4. Failover, je Topologie gewählt

    Ob Spokes automatisch auf einen Backup-Hub wechseln, wenn der primäre nicht mehr antwortet — und nach wie langer Stille —, ist eine Einstellung der Zeichnung, nicht jeder Firewall.

  5. Zeichnung ändern, dann verteilen

    Die Fläche weiß, wann sie von dem abweicht, was die Firewalls fahren. Ein Button schreibt die Konfiguration beider Tunnelenden und verteilt sie.

Niemand öffnet eine Firewall und tippt eine Regel. Beide Enden jedes Tunnels schreibt die Konsole und verteilt sie.console.zedmos.com · SASE Network

Tunnel-Transport

Einmal für die Topologie gewählt.

WireGuard
Empfohlen
OpenVPN
Remote-Geräte unterstützt
GRE
Nur Standort zu Standort

Menschen, nicht nur Standorte

Remote-Nutzer werden genauso angelegt, mit einem Einmal-Link. Der Zugang gilt je Gerät — ein verlorenes Notebook wird einzeln gesperrt.

Den Bestand aktuell halten

Zedmos veröffentlicht die Versionen. Sie entscheiden, welche Firewalls sie wann übernehmen.

  1. Zedmos

    Wir veröffentlichen eine Version

    Für Konsole und Firewall, jeweils eigenständig. Die Konsole meldet die Verfügbarkeit, statt darauf zu warten, dass Sie nachsehen.

  2. Sie

    Sie wählen, wer sie übernimmt

    Erst einige Firewalls, dann der Rest — oder alles auf einmal. Eine kleine Gruppe zuerst zu aktualisieren findet Probleme, solange sie klein sind.

  3. Sie

    Sie sehen, was wo läuft

    Die Version jeder Firewall in einer Liste. Ein zurückgefallenes Gerät hat einen Grund dafür — und ihm fehlt jeder Fix seither.

Wie ein Standort und eine Person angebunden werden

Vier Schritte, und nur die ersten beiden brauchen jemanden. Schlüssel entstehen auf dem jeweiligen Gerät und verlassen es nie; die Konsole verteilt nur den öffentlichen Teil.

  1. Sie

    Form und Hub festlegen

    Ein Standort wird zum Hub — meist der mit fester Adresse und Kapazität zur Inspektion. Alle anderen sind Spokes; nur der Hub braucht eine feste Adresse. Ein zweiter Hub, direkte Tunnel zwischen den Spokes, die sie brauchen, oder Full Mesh sind die drei anderen Formen, und jede Karte sagt, was ihre Wahl kostet.

  2. Sie

    Standorte hinzufügen

    Ein Standort im Topologie-Bild erzeugt die Konfiguration für beide Tunnelenden zugleich — Spoke und passende Änderung am Hub — damit beide nicht auseinanderlaufen.

  3. Zedmos

    Spokes wählen sich ein

    Jeder Spoke baut den Tunnel ausgehend zum Hub auf. Deshalb funktioniert eine Filiale an einem Consumer-Anschluss mit wechselnder Adresse, ohne dass jemand einen Port öffnet.

  4. Zedmos

    Personen melden ihre Geräte selbst an — an Ihrem Provider

    Eine Remote-Person öffnet einen Einmal-Link und meldet sich, wenn Sie es verlangen, zuvor an Ihrem eigenen OpenID-Connect-Provider an — ein Token ohne Multi-Faktor-Nachweis wird zurückgewiesen. Das Gerät erzeugt seinen eigenen Schlüssel und erhält die benannten Anwendungen, die ihre Verzeichnisgruppen zulassen, kein Netz. Eine Frist stellt sie erneut vor den Provider; ein verlorenes Notebook wird einzeln gesperrt.

Was die Konsole für Sie übernimmt

Tunnel, die die Konsole einrichtet

Schlüssel, Adressierung und Routen werden aus einer Topologie-Ansicht erzeugt und verteilt — in der Form, die Sie wählen: ein Hub, ein Hub-Paar, direkte Tunnel zwischen den Spokes, die sie brauchen, oder Full Mesh bis zu acht Standorten. Ein neuer Standort ist ein Knoten, keine Handarbeit auf zwei Firewalls. 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.

Ein zweiter Hub — und der Weg dorthin

Richten Sie einen Backup-Hub ein, dann kann die Konsole die Spokes darauf umziehen, sobald der primäre nicht mehr antwortet. Der Wechsel ist optional und dauert einige Minuten: Erst läuft eine Stille-Schwelle ab, dann bestätigt eine Zustandsprüfung — statt auf ein einzelnes fehlendes Paket zu reagieren. Sie können ihn auch selbst auslösen, mit Vorschau der Änderungen.

Remote-Personen, an Ihr eigenes Verzeichnis gebunden

Ein einmaliger Einladungslink erzeugt das Schlüsselpaar auf dem Gerät der Person — der private Schlüssel erreicht die Konsole nie — und die Registrierung kann zuvor eine Anmeldung bei Ihrem eigenen OpenID-Connect-Provider verlangen und ein Token ohne Multi-Faktor-Nachweis zurückweisen. Erreichbar ist danach eine Liste benannter Anwendungen samt Ports, kein Netz. Eine Frist stellt das Gerät erneut vor den Provider, und der Gerätezustand kommt aus dem Intune oder CrowdStrike, das Sie ohnehin betreiben.

Fragen und Antworten

Woraus besteht Zedmos SASE?

Ein Overlay über WireGuard, OpenVPN oder GRE aus der Konsole bereitgestellt, in der Form, die der Bestand braucht — Hub-Spoke, Dual-Hub, Spoke-Shortcuts oder Full Mesh — mit optionalem Backup-Hub und automatischem Failover sowie einem Relay für Paare hinter portumschreibendem NAT. Remote-Personen verbinden sich mit einem Standard-WireGuard-Client, bei der Registrierung an Ihren eigenen Provider gebunden, und alles, was sie senden, wird am Hub geprüft: Anwendungskontrolle, IDS/IPS, TLS-Inspektion, DLP und das AI Gateway.

Leitet Zedmos SASE meinen Verkehr durch eine Hersteller-Cloud?

Nein. Die Hubs sind Ihre eigenen Firewalls, auf Ihrer Hardware oder auf ZedmOS, und die Inspektion geschieht auf dem Hub, den Sie betreiben. Nichts läuft über Zedmos.

Brauchen Remote-Nutzer einen Zedmos-Client?

Nein. Remote-Nutzer verbinden sich mit einem Standard-WireGuard-Client. Ein einmaliger Einladungslink erzeugt das Schlüsselpaar auf dem Gerät des Nutzers und sendet nur den öffentlichen Teil; der private Schlüssel erreicht die Konsole nie. Es gibt keine Client-Lizenz pro Platz.

Was passiert, wenn ein Hub ausfällt?

Mit einem eingerichteten Backup-Hub zieht die Konsole jeden Spoke dorthin um, sobald der primäre nicht mehr antwortet: Sie wartet eine Stille-Schwelle ab, bestätigt mit einer Zustandsprüfung und wechselt dann. Automatisches Failover ist optional; Sie können es auch selbst auslösen, mit Vorschau der Änderungen. Die Spokes ziehen zurück, sobald der bevorzugte Hub stabil war.

Welche Tunnel-Transporte werden unterstützt?

WireGuard für die meisten Installationen, OpenVPN, wo eine zertifikatsbasierte Umgebung ohnehin Standard ist, und GRE, wo der Transport bereits privat ist und Sie Routing ohne zweite Verschlüsselungsschicht wollen. Alle drei sind in die Engine integriert.

Wie wird die Identität eines Remote-Nutzers in der Policy angewendet?

Nutzer und Gruppen kommen aus Active Directory, Azure AD oder SCIM, und Policies selektieren namentlich darauf. Ein Remote-Tunnelnutzer ist ab der ersten Verbindung identifiziert, weil seine Adresse bei der Anmeldung vergeben wird.