Was ist ein SSE-Gateway?

Ein SSE-Gateway ist der Durchsetzungspunkt des Security Service Edge v Versa, der als von Versa gehostetes Cloud-Gateway oder als lokale Appliance bereitgestellt wird. Es beendet Client-Tunnel v SASE sowie Site-to-Site-Verbindungen und sorgt für die Authentifizierung, Entschlüsselung sowie die Durchsetzung von Bedrohungs- und Zugriffsrichtlinien für den durchgeleiteten Datenverkehr.

Die wichtigsten Erkenntnisse

• Ein SSE-Gateway ist der Durchsetzungspunkt v Versafür den Datenverkehr unter SASE .
• Es beendet sowohl „ SASE “-Client-Tunnel als auch Site-to-Site-Tunnel.
• Über Director bereitgestellt, anschließend in Concerto erkannt und integriert.
• Es ist ein Zertifikat einer öffentlichen Zertifizierungsstelle erforderlich, das alle verwendeten FQDNs der Gateways abdeckt.
• Mit der Funktion „Trusted Network Detection“ können Tunnel in vertrauenswürdigen Netzwerken umgangen werden.

Auf dieser Seite: Warum das wichtig ist · So funktioniert es · Bereitstellungsmodelle für SSE Gateway · SSE-Gateways & Versa · Häufig gestellte Fragen

Warum ist ein SSE-Gateway wichtig?

Security Service Edge funktioniert nur, wenn der Datenverkehr tatsächlich durch den Sicherheitsstack fließt – jede ZTNA-Prüfung, jede TLS-Überprüfung, jede Entscheidung zum Schutz vor Bedrohungen muss irgendwo, auf einem Gerät, stattfinden, bevor der Datenverkehr das Internet oder eine private Anwendung erreicht. Ein SSE-Gateway ist dieser Ort: der einzige Durchsetzungspunkt, an dem der Client-Tunnel eines Remote-Benutzers oder der Site-to-Site-Tunnel einer Zweigstelle ankommt, bevor der Datenverkehr weitergeleitet wird. Ohne ihn ist die „ SASE “-Richtlinie nur ein Dokument; mit ihm wird die Richtlinie tatsächlich auf den Datenverkehr angewendet.

Die Zentralisierung der Durchsetzung am Gateway ist auch der Grund dafür, dass „ SASE “ über sehr unterschiedliche Verbindungstypen hinweg konsistent ist. Ein Benutzer, der von einem Laptop aus über das Internet arbeitet, eine Niederlassung, die über ein SD-WAN-Overlay auf dieselbe private Anwendung zugreift, und eine Terminalserver-Sitzung, die von Dutzenden von Benutzern gemeinsam genutzt wird – für alle muss dieselbe identitäts- und sicherheitsstatusbezogene Richtlinie angewendet werden. Und das ist möglich, da am Gateway Authentifizierung, Entschlüsselung und Zugriffskontrolle zusammenlaufen, unabhängig davon, wie der Datenverkehr angekommen ist.

Was ist ein SSE-Gateway?

Ein SSE-Gateway beendet zwei Arten von Verbindungen. Versa SASE Clients bauen direkt IPsec-, TLS- oder DTLS-Tunnel zu ihm auf, registrieren sich unter einem Portal-FQDN und authentifizieren sich benutzerspezifisch. Standorte erreichen es über Site-to-Site-IPsec- oder SD-WAN-Overlay-Tunnel, sodass der gesamte Datenverkehr einer Niederlassung – nicht nur der einzelner Clients – über denselben Kontrollpunkt geleitet werden kann. In beiden Fällen durchläuft der Datenverkehr, sobald er am Gateway ankommt, dieselben Schritte: Authentifizierung, TLS-Entschlüsselung, Schutz vor Bedrohungen und Überprüfung der Zugriffsrichtlinien.

Da Clients ein Gateway anhand des FQDN auflösen, ist die Abdeckung durch TLS-Zertifikate ebenso wichtig wie die Netzwerkverfügbarkeit: Das von einer öffentlichen Zertifizierungsstelle signierte Gerätezertifikat des Gateways muss alle FQDN-Varianten abdecken, die von Clients und Browsern verwendet werden – die Stammdomäne für den sicheren Zugriff sowie, für den clientlosen Reverse-Proxy-Zugriff, eine separate myapps Platzhalter. Für die Hochverfügbarkeit eingesetzte redundante Gateways benötigen eigene Zertifikate mit versetzten Ablaufdaten, damit die Verlängerung eines Zertifikats auf einem Gateway niemals mit dem Ablauf des Zertifikats auf dem anderen Gateway zusammenfällt.

Bereitstellungsmodelle für SSE Gateway

Gateways werden auf Director als Gerätetyp „Cloud-Security“ unter Verwendung der Hub-Controller-Rolle bereitgestellt, wobei pro Gateway ein eigener Vorlagen-Workflow und eine eigene Gerätegruppe verwendet werden – Vorlagen werden nicht zwischen Gateways gemeinsam genutzt. Die WAN-Schnittstellen des Gateways sind mit Leitungs-Tags versehen, die den Verwendungszweck der jeweiligen Leitung festlegen: NO_DIA deaktiviert den direkten Internetzugang auf einer Leitung, NO_S2S schließt es aus Site-to-Site-Tunneln aus, NO_RAC_RAS verhindert, dass Client-Verbindungen von SASE hergestellt werden, und DIA_ON_PROVIDER Aktiviert Source-NAT für den Internetverkehr von Untermietern auf Anbieterebene – wenn eine Verbindung nicht gekennzeichnet wird, steht sie für alle drei Verkehrstypen zur Verfügung.

Nach der Bereitstellung werden Gateways über „ Versa “ in Concerto erkannt: Ein Administrator fügt den zuständigen Director-Knoten zu Concerto hinzu, führt die Mandantenerkennung durch, und die unter dem Provider-Mandanten dieses Directors bereitgestellten Gateways werden für die Einbindung in Regionen und Mandanten angezeigt. Ein Gateway kann auch im „Trusted-Network-Assisted“-Modus betrieben werden. In diesem Modus erkennt es Clients, die sich über eine private IP-Adresse hinter einem bestehenden SD-WAN- oder IPsec-Tunnel verbinden, und verzichtet auf den Aufbau eines redundanten „ SASE “-Tunnels, während Identität und Sicherheitsstatus weiterhin über einen schlanken Kontrollkanal überwacht werden.

SSE-Gateways & Versa

Die Bereitstellung eines SSE-Gateways und die Einbindung von Mandanten umfasst den gesamten Prozess: Erstellung von Vorlagen und Gerätegruppen auf der Director-Seite, Installation von Zertifikaten, DNS- und Zeitkonfiguration sowie die Erkennung auf der Concerto-Seite und die Konfiguration der Stammdomäne für die FQDNs der Gateways. Mithilfe der „Trusted Network Detection“ (gatewaygestützt) kann ein SSE-Gateway anhand der Quell-IP des Clients vertrauenswürdige von nicht vertrauenswürdigen Verbindungen unterscheiden und die Tunnelbildung für Clients überspringen, die sich bereits in einem gesicherten Netzwerk befinden, während weiterhin benutzerspezifische Richtlinien über den Kontrollkanal durchgesetzt werden.

Das Gateway sorgt zudem für die Identitätsabklärung in Szenarien, die ein Client nicht eigenständig abdecken kann. Hinter einem gemeinsam genutzten Windows-Terminalserver, wo die VOS-Appliance andernfalls für jeden angemeldeten Benutzer nur eine IP-Adresse erkennen würde, registriert der Terminalserver-Agent jede Sitzung über das SD-WAN-Overlay oder einen IPsec-Tunnel zur Portal-URL beim SSE-Gateway. Dadurch erhält das Gateway eine benutzerspezifische Transparenz und die Möglichkeit zur Durchsetzung von Richtlinien, die es allein anhand des Netzwerkverkehrs nicht erreichen könnte.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem SSE-Gateway und einem „ SASE “-Client?

Der Client ist eine Endpunkt-Software, die einen Tunnel aufbaut; das SSE-Gateway ist der Kontrollpunkt, an dem der Tunnel endet. Der Client authentifiziert den Benutzer und leitet den Datenverkehr weiter; das Gateway überprüft diesen Datenverkehr, entschlüsselt ihn und wendet die entsprechenden Richtlinien an, sobald er eintrifft.

Kann ein SSE-Gateway sowohl Client-Tunnel als auch Site-to-Site-Tunnel verarbeiten?

Ja. Dasselbe Gateway wickelt sowohl „ SASE “-Client-Verbindungen einzelner Benutzer als auch IPsec- oder SD-WAN-Site-to-Site-Tunnel ganzer Niederlassungen ab und wendet dabei für beide denselben Authentifizierungs-, Entschlüsselungs- und Zugriffsrichtlinien-Stack an, sodass ein einziges Gateway-Design sowohl Remote-Benutzer als auch verbundene Standorte abdeckt, ohne dass für jeden eine separate Infrastruktur erforderlich ist.

Warum benötigt ein SSE-Gateway ein öffentliches, von einer Zertifizierungsstelle signiertes Zertifikat?

Clients stellen über HTTPS eine Verbindung zu den vom Gateway bereitgestellten FQDNs her, und dank eines von einer öffentlichen Zertifizierungsstelle signierten Zertifikats können sowohl clientbasierte als auch clientlose Verbindungen dem Gateway vertrauen, ohne dass auf jedem Gerät zusätzliche Stammzertifikate installiert werden müssen – dies gilt sowohl für die Variante mit sicherem Zugriff als auch für die Reverse-Proxy-FQDN-Variante.

Was ist die Erkennung vertrauenswürdiger Netzwerke an einem SSE-Gateway?

Dadurch kann das Gateway anhand der Quell-IP-Adresse des Clients erkennen, ob sich ein Benutzer bereits in einem Netzwerk mit einer bestehenden sicheren Verbindung befindet – beispielsweise in einem Büro hinter einem SD-WAN-Overlay –, und den Aufbau eines redundanten Client-Tunnels überspringen, während die Richtlinien zur Identitäts- und Sicherheitsüberprüfung weiterhin durchgesetzt werden.

Wie geht ein SSE-Gateway mit gemeinsam genutzten Terminalserver-Sitzungen um?

Standardmäßig kann das System Benutzer nicht unterscheiden, die sich eine Terminal-Server-IP-Adresse teilen. Der Terminal-Server-Agent registriert jede Benutzersitzung separat über den bestehenden SD-WAN- oder IPsec-Tunnel beim Gateway, sodass das Gateway eine benutzerspezifische Zugriffskontrolle anstelle einer gemeinsamen Richtlinie anwenden kann.

Mehr zu SSE-Gateways

Wenn Sie mehr erfahren möchten, finden Sie hier Quellen, denen wir vertrauen.

Verwandte Begriffe

Wenn Sie sich gerade über SSE-Gateways informieren, sollten Sie sich diese als Nächstes einmal ansehen.