Früher waren in der Regel nur Außendienstler und Vertriebsmitarbeiter gezwungen, von außen auf Unternehmensdaten und programme zuzugreifen. In einer globalisierten Wirtschaft, in der viele Beschäftigte oft unterwegs sind, steigt die Zahl der Mitarbeiter, die einen Fernzugriff benötigen, ständig. Faktoren wie der Wunsch nach einer akzeptablen Work-Life-Balance (etwa die Baby-Pause oder das Teleworking im Home Office) steigern die Nachfrage nach remoten Zugangsmöglichkeiten weiter. Die laufend wachsende Zahl an intelligenten Endgeräten, die etwa aus der Ferne dem Wartungstechniker Supportbedarf signalisieren, vermehrt ebenfalls den Bedarf an Remote-Access-Lösungen.

Und in den Ballungsräumen werden die Unternehmen aufgrund der immer schärferen Umweltbestimmungen bereits in naher Zukunft nicht umhinkommen, mehr Mitarbeiter von zu Hause arbeiten zu lassen. Wer hat schließlich gerne das Image eines CO2-Sünders nur weil er seine Belegschaft jeden Tag im Office antreten lässt.

Drei Ansätze zum Fernzugriff

Technisch betrachtet, ist das Arbeiten per Fernzugriff kein Problem, versprechen doch VPN-Lösungen den effizienten Einsatz von zentralen IT-Systemen in Niederlassungen, unterwegs oder im Home Office. Gleich drei verschiedene Ansätze bieten sich an. Noch aus dem Modem-Zeitalter stammt der RAS-Ansatz (Remote Access Services). Jünger ist dagegen das IP-basierende VPN, das lange Zeit als modernste Technik geschätzt wurde. Als der letzte Schrei gelten seit ein bis zwei Jahren so genannte Web-basierende SSL-VPNs. Dies bedeutet allerdings nicht, dass damit die Vorgängertechnologien automatisch zum alten Eisen gehören, denn alle drei Verfahren haben ihre spezifischen Stärken und Schwächen.

Protokolltalent RAS

So hat selbst im Internet- und Breitband-Zeitalter RAS in bestimmten Anwendungsszenarien durchaus noch seine Berechtigung. Thomas Hruby, Geschäftsführer der Sysob IT Distribution, rät, "möglichst viele Aspekte der verschiedenen Technologien und der damit verbundenen Kosten zu prüfen, denn keine der Lösungen ist besser oder schlechter als die andere".

Zu einer Zeit entwickelt, als Web-Browser, Java-Applets etc. noch unbekannt waren, hat RAS auch heute noch seinen Sinn. Das besondere Plus dieser Technik sind für Stefan Heinz, Vice President Emea bei TK-Spezialist Dialogic, die vielen kompatiblen Übertragungsprotokolle: "Von analog über ISDN bis hin zu X.31 kann der Anwender RAS ohne großen Aufwand einsetzen." Letzt-lich handelt es sich dabei in der Regel um Punkt-zu-Punkt-Verbindungen, die nicht mit den hohen Übertragungsraten wie etwa xDSL aufwarten. Was aber auch kein Problem darstellt, da RAS heute meist dazu genutzt wird, um wenige Daten sicher zu übermitteln, wie etwa bei den Fahrkartenautomaten der Bahn oder bei Röntgengeräten, die dem Hersteller selbständig von Zeit zu Zeit ihren Wartungsbedarf melden. "Zudem findet RAS noch immer dann Verwendung", so Manager Heinz weiter, "wenn aufgrund schlechter Infrastruktur andere Technologien nicht einsetzbar sind." Als Übertragungsmedium kommen dabei laut Fred Behrens, verantwortlicher Produkt- und Solutions-Manager beim Netzbetreiber Lambdanet, auch moderne Mobilfunktechniken wie GPRS oder UMTS zum Einsatz, um beispielsweise Geldautomaten oder andere Geräte fernab von einer Backbone-Infrastruktur zu vernetzen. Zudem erlebt RAS nach den Beobachtungen von Behrens in anderen Szenarien ein Revival: "Viele Unternehmen setzen RAS heute wieder als Backup-Lösung bei der standortübergreifenden Vernetzung ein."

Im Gegensatz zum direkten Zugriff über Punkt-zu-Punkt-Verbindungen nutzen IP-basierende VPNs zur Übertragung in der Regel Teile eines öffentlichen Net-zes. Über dieses wird dann quasi eine Art virtuelles Netzwerk gelegt, das noch gegen Lauscher geschützt werden muss. Im Gegensatz zu RAS, das auf den unteren Netz-Layern greift, sind diese Ver-fahren meist auf der Netzebene zwei beziehungsweise drei des OSI-Modells angesiedelt. Entsprechende VPNs können mit Protokollen wie L2TP, PPTP, ViPNet und anderen realisiert werden. In der Praxis kommt jedoch sehr häufig IPsec zum Einsatz, weshalb sich für diese Gattung allgemein der Begriff "IPsec-basierende VPNs" eingebürgert hat.

Für diese Art der remoten Koppelung spricht unter anderem, dass günstige und breitbandige Übertragungsarten wie WLAN-Hotspots oder DSL-Verbindungen sowie das Internet als physikali-sches Transportnetz genutzt werden können. Über diese wird ein virtuelles Overlay-Netz gelegt, um etwa das heimische LAN eines Teleworkers transparent mit dem Corporate Network zu koppeln, wobei die Daten verschlüsselt durch einen Tunnel transportiert werden. "Es entsteht letztlich eine Site-to-site-Verbindung", erklärt Manager Hruby, "so dass der Anwender zu Hause wie von der Firma gewohnt mit seinen Client-Server-Anwendungen weiterarbeitet." Alle LAN-Applikationen sind also ohne Modifikation remote nutzbar, und für die Anwendungen fällt kein Integrationsaufwand an. Selbst auf File-Ebene, so ergänzt Thomas Boele, Manager Field Market Development bei Cisco, hat der Anwender transparenten Zugriff auf seine Daten. Voice over IP (VoIP) ist über ein IPsec-VPN ebenfalls kein Problem, so dass das IP-Telefon im Home Office zur Nebenstelle der Unternehmenstelekommunikation wird. Diese transparente Unterstützung von VoIP dürfte zudem an Bedeutung gewinnen, wenn sich der Konvergenzgedanke, also das Zusammenwachsen von Sprach- und Datenwelt, in der Praxis endgültig durchsetzt. Einen weiteren Vorteil sieht Andreas Baehre, Leiter Entwicklung und Forschung bei NCP, einem auf VPN-Lösungen spezialisierten Hersteller in Nürnberg, darin, dass solche VPNs quasi als Festverbindungen betrachtet werden können und damit feste IP-Adressen den Betrieb und die Konfiguration von Anwendungen vereinfachen. Ferner seien im Gegensatz zu anderen Methoden keine Network-Layer-Applets wie Active X oder Java/JRE notwendig.

Hoher Konfigurationsaufwand

Diesen Pluspunkten steht jedoch auch eine Reihe von Nachteilen entgegen. So ist zur Realisierung des VPN in der Zentrale Equipment in Form von VPN-Gateways oder Access-Routern mit integrierter VPN-Funktionalität erforderlich. Gleiches gilt für die Gegenseite. Handelt es sich bei dieser nur um einen einfachen Rechner oder ein anderes Endgerät, so ist keine separate Hardware notwendig. Die Funktionalität kann auch über einen VPN-Client hergestellt werden. Soll ein VPN-Projekt in einem größeren Unternehmen mit heterogener Endgerätelandschaft realisiert werden, so ist darauf zu achten, ob wirklich für alle Endgeräte ein entsprechender Client erhältlich ist. Bei mobilen Endgeräten ist neben der Client-Verfügbarkeit zudem noch die Rechenleistung ein Thema, denn nicht selten sind die Prozessoren der Kleinstcomputer mit dem Rechenaufwand für die Verschlüsselung überfordert.

Die Verschlüsselung zum Auf-bau sicherer Kommunikationstunnel bringt noch ein weiteres Problem mit sich: Das Einrichten der entsprechenden Kommunikationsparameter also wie etwa die beiden VPN-Seiten die Verschlüsselung aushandeln, sich gegenseitig authentifizieren etc. ist alles andere als trivial und von einem normalen PC-Anwender kaum alleine zu stemmen. Diese komplexen Vorgänge führen des Weiteren dazu, dass es häufig mit der Interoperabilität zwischen dem Equipment verschiedener Anbieter hapert. Zwar versuchen die Mitglieder des VPN Consortiums (VPNC) ein Zusammenschluss von VPN-Herstellern , das reibungslose Zusammenspiel ihrer Produkte sicherzustellen, doch in der Praxis bleibt dies häufig nur ein frommer Wunsch.

Problemfall NAT

Die Absicherung der Verbindung selbst ist jedoch nur einer der Security-Aspekte, die bei IPsec-VPNs zu beachten ist. Da wie oben dargestellt das LAN eines Teleworkers zu einem Bestandteil des Corporate Network wird, muss sichergestellt sein, dass auch dieses von Viren, Trojanern und anderem digitalen Ungeziefer frei ist. Denn die beste Security Policy im Unternehmen nutzt wenig, wenn über das VPN neue Würmer eingeschleppt werden, die sich etwa der Sohnemann des Mitarbeiters zu Hause bei seiner letzten Filesharing-Session eingefangen hat.

Ein anderes Problem mit IPsec-VPNs sieht Sysop-Geschäftsführer Hruby im Zusammenhang mit NAT (Network Adress Translation), Firewall-Traversal und Breitbandanbindungen. So komme es beispielsweise des Öfteren vor, dass ein Notebook-Benutzer über den Internet-Access-Point keine Tunnel durch die Firewall und Router des Kunden aufbauen kann. Ein Problem, das häufig auch bei öffentlichen Hotspots auftritt, die in vielen Fällen NAT verwenden. Zudem unterstützen teilweise die im Soho-Bereich verwendeten Router kein IPsec-Tunnelling. Für NCP-Entwicklungsleiter Baehre sind diese Schwierigkeiten jedoch keine typischen IPsec-Probleme, sondern Ergebnisse einer missbräuchlichen Portierung. Mit dem entsprechenden VPN-Client, so der Nürnberger, sei auch NAT kein Hindernis. Selbst dem mobilen Einsatz eines VPN-Clients stehe nichts im Wege, denn eine intelligente Software könne die komplexen Konfigurationsvorgänge vom Anwender unbemerkt weitgehend automatisch im Hintergrund erledigen.

Doch egal, wo die Ursache für die Probleme liegt, letztlich gilt für IPsec-basierende VPNs, wie Cisco-Manager Boele feststellt:"Dem Vorteil der großen Flexibilität steht ein entsprechender Administrationsaufwand entgegen, und unter Sicherheitsaspekten sollten die remoten Rechner wie beispielsweise Home-Office-Desktops oder Notebooks von der Unternehmens-IT gemanagt werden." Für größere Unternehmen, die etwa Filialen und Außenstellen per VPN anbinden wollen, sind deshalb in den Augen von Lambdanet-Manager Behrens MPLS-VPNs eine interessante Alternative: "Hier kann der Anwender ebenfalls günstige Infrastrukturprodukte wie DSL nutzen, muss sich aber nicht selbst um die Administration und Konfiguration kümmern." Das VPNC bezeichnet diese Spielart auch als trusted VPNs im Gegensatz zu den secure VPNs, zu denen es IPsec- und SSL-VPNs zählt.

Einfache SSL-Administration

Weniger Verwaltungsaufwand für Systembetreuer und Benutzer versprechen die noch relativ jungen SSL-VPNs, die im Zuge der allgemeinen Web-Euphorie aufkamen. Diese auch als Web-basierende VPNs bezeichnete Form des virtuellen Netzes setzt nicht auf den unteren Netzschichten des OSI-Modells an, sondern auf der Applikationsschicht. Vereinfacht ausgedrückt ist das Ziel eines SSL-VPN der möglichst einfache und sichere Zugriff auf Web-Anwendungen von unterwegs, ohne dass der Anwender einen direkten Zugriff auf das Unternehmensnetz erhält. Gerade der letzte Teilaspekt, so Cisco-Manager Boele, ist für Unternehmen interessant, "die viel mit freien Mitarbeitern arbeiten und diesen nur einen begrenzten Zugriff auf die IT-Anwendungen und Ressourcen einräumen wollen". Andere Einsatzgebiete sieht NCP-Manager Baehre noch in der Anbindung externer Partner wie Kunden und Lieferanten oder in sporadischen Remote-Usern wie beispielsweise Messebesuchern. Zudem eigne sich die Technik als alternativer Zugang für die eigenen Mitarbeiter, wenn diese aufgrund der Firmen-Policy bei einem Kunden keinen IPsec-Tunnel aufbauen könnten.

Browser als Client

Für die Installation einer solchen Lösung ist in der einfachsten Variante, wie Sysob-Geschäftsführer Hruby erklärt, "nur ein SSL-fähiger Web-Server mit den nötigen Inhalten erforderlich, und als Client genügt der zur Verfügung stehende Browser, um eine gesicherte Verbindung zu der gewünschten Anwendung herzustellen". Die Beschränkung auf einen Browser als Client offenbart einen weiteren Vorteil dieses Ansatzes: Fast jedes Endgerät also auch Handys mit Browser und proprietärem Betriebssystem kann so für den remoten Zugriff verwendet werden, denn anders als bei IPsec-VPNs ist keine spezielle Client-Software erforderlich, die dann womöglich für die eine oder andere Plattform nicht erhältlich ist.

Allerdings funktioniert diese einfache Variante nur, wenn die Unternehmensanwendungen als HTTP Applikationen ausgelegt sind. Ist dies nicht der Fall, benötigt der Anwender einen SSL-VPN-Server beziehungsweise Proxy als Bindeglied zu den anderen Anwendungen. Mit einem entsprechenden Server lässt sich zudem gleich ein weiteres Manko der SSL-VPNs umschiffen. Da die Technik per se auf der Anwendungsebene aufsetzt, erlaubt sie keinen direkten Zugriff auf Dateiebene. Diesen remoten File Access kann der Anwender wiederum mit Hilfe des VPN-Servers ermöglichen. Der Einsatz entsprechender dedizierter Server empfiehlt sich laut NCP noch aus einem anderen Grund: Sie können etwa Client-Parameter wie verwendetes Betriebssystem, Service Packs und Hotfixes prüfen oder die gestarteten Dienste und Anwendungen auf dem remoten Rechner abfragen sowie checken, ob zum Beispiel die Virenscanner auf dem aktuellen Stand sind.

Sicherheitsaspekt im SSL-VPN

Mit Hilfe dieser Daten lässt sich dann ein sehr fein graduierter Zugriff einstellen: Wird der Status des Endgerätes als unsicher eingestuft, so erhält der Anwender beispielsweise lediglich Zugriff auf den Speiseplan der Kantine, während ihm die Verwendung der ERP-Software nur dann erlaubt ist, wenn sein Endgerät alle Sicherheitschecks besteht. Ein Vorgehen, das laut Hruby auch eine Anpassung an die Sicherheits-Level, verschiedener Lokalitäten erlaubt: "Ein Zugriff aus einem Internet-Cafe braucht eine wesentlich restriktivere Sicherheitsrichtlinie als der Zugriff von einem Firmen-Laptop, das in der Regel über Antivirus-Programm und Desktop-Firewall verfügen sollte."

Der Sicherheitscheck ist nicht nur beim Aufbau der Verbindung wichtig. Vielmehr sollte er auch beim Verbindungsabbau erfolgen. Denn die beste verschlüsselte Verbindung nützt wenig, wenn hinterher unternehmens-kritische Daten ungeschützt im Cache des Browsers zurückbleiben. Ein Fehler, der vor allem bei der Benutzung fremder Rechner auf einer Konferenz oder im Internet-Cafe fatale Folgen haben könnte.

Um oben genannte Funktionen zu realisieren, müssen die Hersteller teilweise den Funktionsumfang des Browsers über die reine SSL-Funktionalität hinaus durch den Einsatz von Active X oder Java Applets erweitern. Geschäftsführer Hruby unterscheidet deshalb zwischen drei verschiedenen Zugriffsmethoden:

Client-less: Der Benutzer greift lediglich mit seinem Browser auf die Web-Seiten eines Servers zu. Das Spektrum der unterstützten Applikationen ist relativ klein, da normalerweise nur Web-Applikationen genutzt werden können. Allerdings gibt es so genannte Webifier als Web-Schnittstelle zu nicht Web-basierenden Anwendungen.

Thin Client: Bei dieser Methode lädt der Browser zusätzlich ein Plugin herunter. Das geladene Plugin dient meist als generischer TCP/UDP-Proxy und ermöglicht auf Basis eines Portforwardings den Zugang zu allen TCP- und UDP-fähigen Applikationen.

Fat Client: Soll über SSL ein vollwertiges VPN aufgebaut werden, so muss die Lösung in der Lage sein, den kompletten IP-Verkehr über eine verschlüsselte Verbindung zu übertragen. Hierzu wird ein Treiber installiert, der ein virtuelles Netzwerk-Device erstellt. Dieses Device ermöglicht die Umleitung des Verkehrs über eine statische Route in den SSL-VPN-Tunnel.

Fazit

Unter dem Strich haben also sowohl IPsec- als auch SSL-VPNs ihre spezifischen Vor- und Nachteile, so dass sich keine Lösung eindeutig bevorzugen lässt. Zumal es auf das jeweilige Anwendungsszenario ankommt. Eine Zwickmühle, auf die zahlreiche Hersteller bereits reagiert haben: Sie offerieren Router und VPN-Gateways, die sowohl IPsec als auch SSL unterstützen, und zahlreiche VPN-Clients sind ebenfalls als Kombilösung ausgelegt.

Für Unternehmen, die den Aufwand einer eigenen Implementierung scheuen, gibt es zudem noch einen dritten Weg: Sie können das Ganze an Dienstleister wie Ipass outsourcen und das gesamte VPN-Konzept als Dienstleistung beziehen.