Dieselbe Inspektion — auch für alle, die nicht am Schreibtisch sitzen

Die Zugriffshälfte von SASE: Remote-Arbeitende bekommen einen Tunnel zum Hub, und der Verkehr darin trifft auf dieselbe Policy wie im Büro. Keine getrennte Cloud mit getrennten Regeln.

Demo anfragen

Eine Policy: IDS/IPS, DLP & AI Gateway, TLS und Routing in einem EditorOPNsense · os-zedmos

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.

Sie
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.
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.
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.
Zedmos
Personen melden ihre Geräte selbst an
Ein Remote-Nutzer öffnet einen Einmal-Link; das Gerät erzeugt seinen eigenen Schlüssel und erhält die zustehenden Routen. Ein verlorenes Notebook wird einzeln gesperrt.

0: Private Schlüssel, die wir je sehen
3: Verzeichnisquellen
Split: Standard-Tunnelumfang
Nein: Client-Lizenz pro Platz

Wie Zugriff erteilt und entzogen wird

Der private Schlüssel verlässt den Laptop nie

Die Anmeldung besteht aus einem einmaligen Link und einem separat übermittelten Passwort. Der Browser erzeugt das Schlüsselpaar auf dem Gerät des Nutzers und sendet nur den öffentlichen Teil. Es gibt im System kein Feld für einen privaten Schlüssel — weil nichts hineingehört.

Standardmäßig Split-Tunnel, Full-Tunnel richtig gemacht

Standardmäßig laufen nur Unternehmensbereiche durch den Tunnel. Full-Tunnel ist ein Schalter und wird als explizite Liste von Internet-Präfixen gebaut statt als pauschale Default-Route — der heimische Drucker funktioniert weiter, und der Handshake des Tunnels wird nie in ihn selbst zurückgeroutet.

Die Inspektion geschieht am Hub

Remote-Verkehr landet am Hub und trifft dort auf die vollständige Engine: Anwendungskontrolle, Kategorie- und URL-Filterung, IDS/IPS, TLS-Inspektion, Data Loss Prevention und das AI Gateway. Ein Spoke als Ausgangspunkt leitet weiter und übersetzt — er inspiziert nicht. Welche Appliance die Arbeit macht, ist für die Dimensionierung wichtig.

Wählen, wo der Verkehr eines Nutzers austritt

Über den Hub, über einen bestimmten Standort oder über den Standort, der dem Anmeldeort des Nutzers am nächsten liegt. Praktisch, wenn ein Dienst nur Adressen eines bestimmten Landes akzeptiert.

Identität — und was wirklich dazugehört

Nutzer und Gruppen kommen aus Active Directory, Azure AD oder SCIM, und Policies selektieren namentlich darauf. Remote-Tunnelnutzer sind ab der ersten Verbindung identifiziert — ihre Adresse wird bei der Anmeldung vergeben, die Person ist also ohne Zusatzaufwand bekannt. Im LAN liefert der Domänencontroller-Agent dieselbe Zuordnung für alle übrigen.

Geräte werden erkannt, nicht bewertet

Die Engine erkennt aus dem ohnehin sichtbaren Verkehr, was jedes Gerät ist — DHCP, mDNS, ARP, User-Agents, SSH-Banner — ohne Agent und ohne Installation beim Nutzer. Policies selektieren auf das Ergebnis: dieser Drucker, jene Geräteklasse, alles Unbekannte.

Demo & Preise: info@zedmos.com