20071112d HOB Secure Remote Access
|
|
|
»manage
it«
als
|
Secure Remote Access im Vergleich: Ist IPSec VPN kompliziert, SSL-VPN unzureichend und RD-VPN gerade richtig? Der sichere Zugriff Mobile Mitarbeiter, Geschäftspartner und Kunden benötigen heute Zugriff auf verschiedene Unternehmensressourcen und Anwendungen, jeder von einem anderen Client und von den verschiedensten Orten. Mit IPSec und SSL stehen zwei Protokolle für den sicheren Remote Access zur Verfügung. IPSec sei zu kompliziert und teuer, der Implementierungsaufwand sei riesig. Angeblich lösen SSL-VPNs alle Schwierigkeiten. Die Realität sieht doch etwas anders aus, auch SSL-VPNs haben mit allerlei Problemen zu kämpfen. Liegen die richtigen Entscheidungen für oder gegen eine der Lösungen in der Technik, den Security-Features, dem Einsatzszenario oder den Anwendungen?
nternehmen suchen heute VPN-Lösungen die einfach, bei langfristiger Betrachtung preiswert und sicher sind. Zwei Technologien haben sich dabei am Markt etabliert: IPSec und SSL. IPSec verbindet einen IPSec-Client mit dem Gateway bzw. Gateways untereinander über das Internet durch einen IP-Tunnel auf Layer 3 des OSI-Models. Dazu installieren Administratoren auf beiden Seiten Software. Tauschen zwei Kommunikationspartner nun Daten aus, einigen sie sich zunächst über das Verschlüsselungsverfahren und den Schlüsselaustausch zur Authentifizierung. Nach einem Verbindungsaufbau können alle TCP/IP-Pakete über IPSec verschlüsselt verschickt werden. Die Firma Netscape, Internet Pionier bei der Browser- und Webservertechnologie, führte in ihrer Version 2 des Netscape Navigators die SSL Verschlüsselung zur sicheren Kommunikation zwischen Browser und Webserver auf Layer 4 ein. Heutige Standardbrowser haben SSL integriert, deshalb kann der Zugriff von jedem Client mit Standardbrowser erfolgen, egal an welchem Ort der Client sich befindet. Grundsätzlich werden drei SSL-VPNs unterschieden. SSL-VPNs die mit dem Browser über https auf Applikationen zugreifen und SSL-VPNs die Zugriffe auf Server mit anderen Protokollen über Proxys erlauben. Diese Client-Site-Proxy-SSL-VPNs benötigen in den meisten Fällen Administratorrechte auf dem Client, um ihre volle Funktionalität auszuspielen. Die dritte Möglichkeit sind Access-SSL-VPNs, welche die Applikationen mitbringen.
IPSec und SSL-VPN: Vorteile, Nachteile, Probleme Häufig wird die Konfiguration von IPSec-Clients als großer Nachteil gegenüber SSL-VPNs dargestellt. Grundsätzlich muss bei IPSec VPNs am Client eine Konfiguration vorgenommen werden. Der Umfang differiert aber von Hersteller zu Hersteller gewaltig. Bei manchen Lösungen muss die komplette Konfiguration am Client erfolgen, hier setzt SSL-VPN das Argument der »einfachen Administration« ein. Bei einigen Lösungen (z. B. Cisco, HOB) müssen nur Anmeldedaten für die zentrale Plattform eingetragen werden und können von dort dann auch komplett administriert und konfiguriert werden. Eine Installation am Client stellt dann wirklich keine Anforderungen an den Anwender. Das oft erwähnte NAT-Problem wurde von den IPSec-Herstellern schön längst durch UDP-Encapsulation gelöst. Vorbehalte dagegen resultieren noch aus früherer Zeit, als dieses Problem noch aktuell war. Lösbar sind auch Probleme, wenn der IP-Datenverkehr durch Firewalls, Heim-Router oder ISPs blockiert wird. Schädlinge wehren IPSec VPNs mit Firewalls ab. In allen Fällen müssen aber das Endgerät angefasst und Software installiert werden. Und genau dies wird bei Geräten, die nicht den Unternehmen gehören zum Problem. Beim SSL-VPN wird die Kommunikation zwischen Client und Unternehmensserver mit SSL gesichert. Jedoch stellt eine SSL Verbindung an sich noch kein Firmen-Netzwerk zur Verfügung. Hierfür ist die, durch einen Administrator vorzunehmende, zusätzliche Installation einer Client-Software notwendig. Sämtliche ausgehende Verbindungen werden dadurch in SSL getunnelt und an die entsprechende Gegenstelle gesendet. Sobald SSL-VPNs andere Protokolle wie beispielsweise RDP, ICA, FTP, POP oder IMAP transportieren, erhöht sich bei vielen SSL-VPNs der Datenverkehr zwischen Client und »SSL-VPN Server« um bis zu 70 Prozent gegenüber anderen Lösungen. Dies rührt daher, dass eine Protokollumsetzung in http durchgeführt wird. Gerade bei Windows Terminal Server-Verbindungen kann das zu erheblichen Engpässen führen. Clientless Als Hauptargumente führen SSL-VPN-Hersteller an, dass für den Aufbau der Verbindung kein eigener Client mehr benötigt wird und der eigentliche Zugriff auf interne Ressourcen sicherer ist. Doch gerade hierbei muss zusätzlich unterschieden werden, ob der verantwortliche Administrator uneingeschränkt Zugriff über das eingesetzte Device hat oder nicht. Für native Webanwendungen genügt lediglich ein Browser, mehr Funktionalität kann erst mit einer Java- oder ActiveX-Umgebung erreicht werden. Je tiefer das Applet dabei ins Betriebssystem eingreift, desto mehr Rechte benötigt die SSL-VPN-Lösung. Diese Rechte gehen über normale User-Rechte meist hinaus. Ob bei Geschäftspartnern und Lieferanten alle Anwender diese Adminrechte besitzen sollen, ist in der heutigen Zeit fraglich. End-Point-Security Viele SSL-VPN-Hersteller ergreifen Maßnahmen zur Bereinigung von Spuren auf den Client-Geräten oder scannen die Endgeräte in gewisser Weise, um Sicherheitslevel aufgrund gefundener Anti-Viren-Software und Firewalls festzulegen. Solche Maßnahmen sind vor allem für Zugriffe von öffentlichen Geräten sinnvoll. Abhängig vom jeweiligen Gerät lässt sich der Zugriff dann einschränken. Die größten Gefahren bestehen hier bei Zugriffen auf Terminal Server und im Ausspionieren von Passwörter. Beim Zugriff auf Terminal Server sollte man die Rechte stark einschränken, der Anwender kann dann allerdings nur rudimentär arbeiten. Andere Lösungen schalten in dieser Konstellation einen Virenscanner zwischen Client und Terminal Server. Das Risiko des Ausspionierens von Passwörtern lässt sich nur durch Timecode Tokens minimieren. Fast alle Hersteller offerieren hierfür Lösungen. Eine weitere Gefahr stellen die transferierten Daten auf solche öffentliche Geräte dar. Auch hier können die installierten Clients der SSL-VPN-Hersteller helfen. Die Clients versuchen von den Zugriffsgeräten alle Formen temporärer Dateien, Browser-Caches, Cookies, heruntergeladene Dateien und Webseiten, Verlaufs-, Benutzeranmelde- und andere empfindliche Informationen zu löschen. Gegen vom Anwender abgespeicherte Dateien sind allerdings sämtliche Hersteller machtlos. Access-SSL-VPNs Ein Beispiel für Access-SSL-VPNs ist RD VPN von HOB. Die Problematik der Connectoren für viele Anwendungen entfällt, da die Lösung eine webbasierte RDP-Anwendung integriert hat und zum Zugriff auf andere Unternehmensserver die entsprechenden Emulationen bereitstellt. Dadurch erfolgt die Verschlüsselung auf SSL-Basis auch direkt aus der Anwendung heraus. Die Lösung konzipierten die Entwickler so, dass auf den zugreifenden Client wirklich nichts installiert werden muss und somit auch keine Administatorrechte nötig sind. Alternativ zu Windows Terminal Server, z-Series, i-Series und Unix/Linux-Hosts können Applikationen auf Blade-Systemen mit Windows XP Professional Betriebssystem angesprochen werden. Auch hier übernimmt die HOB Lösung die korrekte Verteilung auf die Blade-Server. Des weiteren können Anwender auch auf firmeninterne Windows XP Professional Arbeitsplätze zugreifen. Dabei spielt es keine Rolle, ob der betreffende Rechner ausgeschaltet ist. Der Proxy in der DMZ nutzt die in modernen Rechnern implementierte Wake-on-LAN-Funktionalität auch über die interne Firewall hinweg, so dass der Zielrechner auch über das Internet ein- und ausgeschaltet werden kann. Weitere Zugriffmöglichkeiten sind – wie bei fast allen SSL-VPNs – der Zugriff auf interne Webserver oder der Zugriff auf PDAs und mobile Devices mit Windows Mobile. Eine besondere Schnittstelle ermöglicht es anderen Herstellern eigene, neue Funktionen hinzuzufügen. Für die Verbindung zwischen Client und Proxy braucht nur ein Port in der Firmen-Firewall freigeschaltet werden, beispielsweise der https-Standard-Port 443. Ebenso ist im Proxy ein Web-Server integriert. Dieser wird dazu verwendet, HOB-Software vorzuhalten, so dass dazu kein separater Web-Server eingerichtet werden muss. Ein weiterer Vorteil: Erhöhte Sicherheit, weil die Authentifizierung bereits vor dem Laden des Applets erfolgt. Unternehmen können beim Proxy zwischen Windows, Unix und Linux Versionen wählen. Resümee
Jürgen Hönig _____________________________________________________________________ Jürgen Hönig, Leiter Marketing HOB GmbH
Vergleich von IPSec (links) und SSL (rechts).
|
|
