Das richtige VPN-Verfahren für jeden Kunden

Wenn Mitarbeiter an entfernten Standorten auf Daten im Unternehmen zugreifen und sicher kommunizieren wollen, ist VPN das Mittel der Wahl, um die Verbindung abzusichern. Unser Schwesterpublikation Computerwoche wägt die beiden Techniken zum Aufbau eines sichern Tunnels, IPsec-VPN und SSL-VPN, gegeneinander ab.

Vor ein paar Jahren waren die Anwender von Fernzugriffslösungen klar umrissen: Außendienstler und Vertriebsmitarbeiter brauchten unterwegs Zugang zu Daten und Unternehmens-Software. Heute lässt sich der Nutzerkreis nicht mehr so einfach festmachen. Die globalisierte Wirtschaft macht alle Mitarbeiter eines Unternehmens mehr und mehr mobil. Dazu kommt der Wunsch vieler Kollegen, ihre Arbeitszeiten flexibler zu gestalten und Home-Office-Tage einzuschieben. Damit steigt auch die Nachfrage nach Remote-Zugängen ins Firmennetzwerk. Doch nicht nur Mitarbeiter benötigen sichere Verbindungen, auch immer mehr mobile Endgeräte verlangen nach gewissenhafter Fernwartung oder signalisieren selbst gelegentlich Aktualisierungbedarf, der nur über eine gesicherte Verbindung erledigt werden kann.

In wirtschaftschwachen Zeiten werden immer mehr Unternehmen ihre Mitarbeiter anhalten, im Home-Office zu arbeiten, um IT-Ressourcen zu sparen. Auch mit Blick auf das Umwelt-Image einer Firma wird sich dieser Trend weiter fortsetzen. Denn wer Green IT konsequent umsetzen will, muss seine Belegschaft nicht jeden Tag im Büro antreten lassen.

Die technische Seite des Fernzugriffs stellt dabei kein Hindernis dar, wie dieser Artikel unserer Schwesterpublikation Computerwoche detailliert zeigt. VPN-Lösungen erlauben den Zugriff auf zentrale Ressourcen und Daten bei der Arbeit in Filialen oder im heimischen Büro. Dabei sind die Daten jederzeit geschützt. Für den Aufbau eines VPN-Tunnels gibt es gleich drei unterschiedliche Ansätze. Schon etwas in die Jahre gekommen ist RAS (Remote Access Services), das noch aus der Zeit der analogen Modems stammt. Aktueller sind das IP-basierte Verfahren VPN und das webbasierende SSL-VPN. Letztere Technik hat in den vergangenen Jahren der IP-Version etwas den Rank abgelaufen. Trotzdem gehört diese VPN-Technik noch nicht zum alten Eisen, und auch RAS hat seine Stärken und Einsatzgebiete. Thomas Hruby, Geschäftsführer der Sysob IT Distribution, empfiehlt, "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".

Multi-Protokolltalent RAS

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 beim auf TK-Lösungen spezialisierten Hersteller Dialogic, die vielen kompatiblen Übertragungsprotokolle: "Von analog über ISDN bis hin zu X.31 kann der Anwender RAS ohne großen Aufwand einsetzen." Letztlich 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."

Virtuell über öffentliche Netze

Im Gegensatz zum direkten Zugriff über Punkt-zu-Punkt-Verbindungen nutzen IP-basierende VPNs zur Übertragung in der Regel Teile eines öffentlichen Netzes. Ü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 Verfahren 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 physikalisches 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.

Diesen Pluspunkten stehen 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.

Schwierige Konfiguration

Die Verschlüsselung zum Aufbau 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.

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.

IPsec-VPNs - flexibel und transparent

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.

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.

Per Browser ins SSL-VPN

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. 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 unternehmenskritische 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.

Drei Client-Ansätze für SSL-VPNs

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.

Unter dem Strich haben also sowohl IPsec- als auch SSL-VPNs ihre spezifischen Vor- und Nachteile, so dass sich ein eindeutiges Pro zugunsten einer Lösung nicht angeben lässt. Zumal es auf das jeweilige Anwendungsszenario ankommt, wie Cisco-Manager Boele aus der eigenen Berufspraxis weiß: "Will ich unterwegs schnell im Internet-Cafe oder an einem Internet-Terminal auf Unternehmensanwendungen zugreifen, dann ist ein SSL-VPN die erste Wahl. Geht es mir aber zu Hause um einen transparenten Zugriff auf das Corporate Network womöglich in Verbindung mit einer VoIP?Installation, dann ist ein IPsec-VPN das probate Mittel." 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. (Computerwoche / wl)