daniilvolkov - stock.adobe.com

Ratgeber

SDP als VPN-Alternative zur Absicherung von Remote-Arbeit

Software-defined Perimeter (SDP) wird als VPN-Alternative für den sicheren Fernzugriff angepriesen. Aber ist SDP oder doch ein herkömmliches VPN für Ihr Unternehmen das Richtige?

Dave Shackleford
von
Zuletzt aktualisiert:18 Dez. 2020

Herkömmliche standortinterne VPNs können teuer und schwierig zu betreiben sowie zu warten sein. Daher suchen viele Organisationen, die mit der Wartung oder dem Übergang zu einer neuen Remote-Belegschaft beschäftigt sind, Alternativen zur Netzwerksicherheit.

Einige erwägen Software-defined Perimeter (SDP) als VPN-Alternative. Zum Beispiel können SDP-Dienste von Palo Alto Networks und Zscaler den Fernzugriff auf breiter Ebene vereinfachen, sofern ein gewisses Maß an finanziellen und betrieblichen Investitionen getätigt wird.

Viele VPN-Alternativen sind einfacher einzurichten und zu verwalten als herkömmliche VPNs, aber jede bringt möglicherweise zusätzliche Risiken mit sich. So kann SDP beispielsweise erfordern, dass Unternehmen für das Hosting oder die Erleichterung des Zugriffs auf Drittanbieter-Broker und Service-Umgebungen zurückgreifen, was eine Reihe von Sicherheitsproblemen zur Folge haben kann.

Klassische VPN- vs. SDP-Technologie

Mit SDP-Tools und -Services vermittelt eine CSP-Umgebung (Cloud Service Provider) Konnektivität anstatt eines herkömmlichen VPNs. In einer SDP-Architektur wird der SDP-Client auf jedem Endpunkt installiert.

Die Endanwender verbinden sich manuell oder automatisch mit dem Point Of Presence (POP) eines SDP-Dienstanbieters in der Cloud. Von dort aus können die Anwender eine Verbindung zu lokalen Ressourcen, Cloud-Diensten oder beidem herstellen. Alle Nutzer, Endpunkte und Richtlinien werden von einer einzigen Konsole aus verwaltet.

Es besteht eine gewisse Verwirrung über die Hauptunterschiede zwischen einer SDP- und einer herkömmlichen VPN-Architektur und -Kontrollen. Netzwerk- und Sicherheitsteams sollten die Abbildung 1 konsultieren, um zu entschlüsseln, wie sich klassische VPN- und SDP-Funktionen unterscheiden.

Abbildung 1: Vergleichen Sie die Funktionen und Kontrollmöglichkeiten klassischer VPN- und SDP-Technologie für die Netzwerksicherheit.
Abbildung 1: Vergleichen Sie die Funktionen und Kontrollmöglichkeiten klassischer VPN- und SDP-Technologie für die Netzwerksicherheit.

Organisationen, die SDP als VPN-Alternative auf der Grundlage von Netzwerk- und Sicherheitsfunktionen in Betracht ziehen, sollten zwei Bereiche berücksichtigen:

  • Leistungsanforderungen: Stellen Sie sicher, dass Sie die Service-Level-Vereinbarungen (SLA) zur Betriebszeit und Verfügbarkeit sowie den Umfang der PoPs für die Konnektivität prüfen.

  • Sicherheitsanforderungen: Prüfen Sie die Netzwerk- und Netzwerksicherheitsfunktionen sorgfältig. Nicht alle Anbieter haben in jedem Bereich den gleichen Reifegrad. Zscaler verfügt beispielsweise über einen starken Content-Filter- und Proxy-Dienst in seinem Zscaler Internet Access Gateway und eine breite Palette von PoPs weltweit. Palo Alto Networks hat weniger PoPs, aber stärkere Sicherheitskontrollen für Network Intrusion Prevention Systems (IPS) und Next-Generation Firewalls (NGFW).

Die SDP-Services werden regelmäßig aktualisiert, daher sollten sich Unternehmen vor einer Kaufentscheidung über die neuesten Funktionen und Verbesserungen auf dem Laufenden halten.

Einschränkungen von SDP als VPN-Alternative

Auch wenn sie ihre Vorteile hat, sollten Netzwerk- und Sicherheitsteams verstehen, dass eine SDP-VPN-Alternative nicht ohne Fallstricke ist. Zu den möglichen Nachteilen gehören:

  • Herausforderungen bei der Benutzerfreundlichkeit: Einige Angebote von SDP-Anbietern sind eine Kombination aus Übernahmen und zusätzlichen Kontrollen und Services.

  • Untergeordnete Sicherheitskontrollen in verschiedenen Bereichen: Einige Dienste sind zum Beispiel beim IPS oder beim Malware-Sandboxing möglicherweise nicht herausragend.

  • Begrenzte Anwendungsunterstützung: Nicht alle Cloud-Anwendungen werden zur einfachen Integration nativ unterstützt, und einige erfordern möglicherweise zusätzliche Konfiguration und Abstimmung.

  • Anzahl der verfügbaren globalen PoPs: Dies wirkt sich direkt auf die Latenzzeit und Konnektivität der Endanwender aus.

Die meisten Implementierungen beinhalten Tests mit vorkonfigurierten Clients, die so eingestellt sind, dass sie auf der Grundlage des aktuellen Standorts eine Verbindung zu PoPs lokaler Anbieter herstellen.

Sobald das System und der Benutzer identifiziert sind, werden Sicherheits- und Konnektivitätsrichtlinien angewendet sowie durchgesetzt. So lassen sich der Zugriff auf Anwendungen und Dienste in der Cloud oder vor Ort erlauben oder verbieten.

Je nach Art des bereitgestellten Zugriffs kann eine gewisse Abstimmung der Kontrollen und der Bandbreitennutzung erforderlich sein, um die Benutzerfreundlichkeit zu verbessern. Außerdem sollten Organisationen mit einer großen Vielfalt an Endnutzergeräten, Anwendungen und Anwendungsfällen mit längeren Implementierungszyklen rechnen, möglicherweise zwischen zwölf und 18 Monaten.

Die meisten Implementierungen bei führenden Anbietern haben weder bei Mac- noch bei Windows-Clients zu größeren Problemen mit der Systemleistung geführt. Es gab jedoch Fälle von lokalen Client-Konflikten mit anderer installierter Software, daher sollten Sie sorgfältig testen.

Erfahren Sie mehr über Netzwerkhardware