SSL-VPNs stellen einen Weg für einfache und sichere Remote-Zugriffe auf Unternehmensressourcen dar. Bei ihrer Implementierung gilt es aber, eine Reihe von Maßnahmen zu berücksichtigen.

SSL-VPN kommen einer idealen Remote-Access-Lösung recht nahe, stellen aber auch neue – lösbare – Herausforderungen dar.

Die Einsatzgebiete des Remote-Zugriffs auf Unternehmens-IT-Ressouren sind vielfältig: Außendienstmitarbeiter und Consultants greifen direkt vom Kunden aus auf Unternehmensdaten zu. Angestellte prüfen ihre E-Mail von zu Hause aus. Partnerunternehmen und Kunden nutzen Extranets, Mitarbeiter im Home-Office arbeiten auf der gleichen Datenbasis wie ihre Kollegen in der Unternehmenszentrale. Für den Zugriff auf Unternehmensressourcen über virtuelle private Netzwerke (VPN) nutzen viele Anwender IP-Security (IPSec)-Verbindungen. Diese Lösung hat aber Nachteile, denn sie erfordert spezielle Software auf dem Gerät, über das auf das VPN zugegriffen wird. Ferner ist Software für die Herstellung der Wähl- oder Breitbandverbindung notwendig. Diese Art des Zugriffs verwenden bislang die Benutzer mobiler Computer oder anderer Remote-Client-Geräte.

Erstrebenswert wäre der Zugriff von jedem beliebigen Standort aus auf jede beliebige Applikation im Unternehmen, ohne dafür irgendeinen mobilen Computer verwenden zu müssen. Vertriebsmitarbeiter könnten dann beispielsweise nach Abschluss eines Geschäfts einfach das nächste Internet-Café aufsuchen, um sofort die Unternehmensdaten zu aktualisieren, die sich immer noch sicher hinter der Unternehmens-Firewall befinden.

Dies ist inzwischen mit VPNs via Secure-Socket-Layer (SSL)-Verbindung möglich. SSL-VPNs erlauben den Zugriff auf Unternehmensressourcen über jeden Web-Browser, egal, wo dieser installiert ist, sei es auf einem Home-PC, auf einer Konsole in der Flughafen-Lounge, auf einem PDA oder sonstigem Gerät. Die SSL-VPN-Technik verspricht eine Steigerung der Produktivität und macht mobilen Nutzern das Leben ein wenig leichter. Denn sie müssen keine Laptops mehr mit sich herumschleppen, weil ein Zugriff ja über jeden Internet-fähigen Computer möglich ist. Der Einsatz dieser Technik kann deshalb verglichen mit klassischem IPSec-VPN auch zu enormen Einsparungen führen, denn es ist nicht mehr notwendig, Remote-Client-Maschinen zu kaufen und zu pflegen.

Damit wären die Probleme gelöst: Zugriff von überall, keine besonders vorkonfigurierten PCs notwendig, keine endlos langen Versuche, eine Verbindung herzustellen. Aber gibt es da nicht neue Probleme? Wie es bei innovativen Technologien häufig der Fall ist, kommen auch mit SSL-VPN Herausforderungen, wenn es um die Sicherheit geht. Sollen Remote-Benutzer wirklich so einfach auf alle im Unternehmensnetzwerk gespeicherten Daten zugreifen dürfen, oder vielleicht doch besser nur auf ihre E-Mail und nicht gleich auch noch auf den Unternehmensfinanzplan? Was geschieht, wenn ein Benutzer über ein öffentliches Terminal zugreift und vergisst, sich nach dem Update des Verkaufsberichts wieder abzumelden?

Zwei Risiko-Kategorien

SSL-VPN-Sicherheitssorgen oder -risiken lassen sich in zwei Kategorien einordnen: solche, die dadurch erzeugt werden, dass ein Zugriff auf das interne Netzwerk erlaubt werden muss (Serverseite), und solche, welche auf die Tatsache zurückzuführen sind, dass SSL-VPN allen Browsern den Zugriff erlauben muss (Browserseite) – das schließt auch die Browser ein, die das Unternehmen nicht kontrollieren kann.

Es lässt sich aber eine Menge tun, und dies ist einer der Hauptvorteile von SSL-VPN. Während IPSec-Verbindungen nach dem Motto »alles oder nichts« funktionieren, entscheiden SSL-Verbindungen sehr genau, was sie den Benutzern erlauben. Der Benutzer und das Gerät, über das er zuzugreifen wünscht, werden authentifiziert. Das SSL-VPN besitzt einen Richtlinienmechanismus, der unter Verwendung von Diensten wie LDAP oder Active-Directory prüft, welche Applikationen der Benutzer verwenden darf. Abhängig vom jeweiligen Gerät lässt sich der Zugriff dann noch weiter einschränken. Der Vertriebsmitarbeiter darf so vielleicht seine Ergebnisse aktualisieren, nicht aber auf sensible Finanzinformationen zugreifen. Um die Sache noch weiter abzusichern, lassen sich Verbindungstimeouts konfigurieren.

Damit eine Kommunikation zwischen dem Benutzer und dem SSL-VPN sowie dem SLL-VPN und den internen Systemen stattfinden kann, muss eine TCP/IP-Kommunikation möglich sein, die normalerweise geöffnete Firewall-Ports erfordert. Um dies sicherer zu machen, lässt sich der Zugriff aus dem Internet auf eine einzige Maschine beschränken, nämlich auf einen gründlich verstärkten Reverse-Proxy, der als Applikationsgateway Anfragen ans SSL-VPN überträgt.

Einen weniger komplizierten Ansatz stellen sichere Architekturen wie Air-Gap dar, welche die für die SSL-VPN-Zugriffe notwendige Kommunikation ermöglichen, ohne dass dazu Firewall-Ports geöffnet werden müssen. Air-Gap isoliert das Internet von den internen Systemen und erlaubt ausschließlich die Übertragung von Applikationsdaten.

Die meisten SSL-VPNs stützen sich auf Web-Server als Teil ihrer Architektur. Dies bedeutet, dass jede Schwachstelle des Web-Servers (oder sonst irgendwo in der SSL-VPN-Software, das Betriebssystem eingeschlossen) zu Sicherheitseinbrüchen führen könnte. Eine Verstärkung der SSL-VPN-Appliance allein schützt hier nicht genug, aber die Filterung aller ans SSL-VPN gesandten Nachrichten kann dafür sorgen, dass ge- oder verfälschte Anfragen das SSL-VPN oder die System dahinter nicht gefährden.

Natürlich muss sichergestellt werden, dass die Benutzer tatsächlich die sind, die sie zu sein vorgeben. Das ist umso wichtiger, weil das Unternehmen keine Kontrolle über die Computer hat, die für die Zugriffe auf das SSL-VPN benutzt werden (deshalb funktioniert auch eine IP-Adressfilterung nicht). Wann immer ein SSL-VPN benutzt wird, sollte eine starke Zwei-Faktoren-Authentifikation implementiert werden, beispielsweise RSA SecureID. Dies ist bei SSL-VPNs sogar noch wichtiger als bei IPSec-VPNs, denn die Benutzer befinden sich häufig an Standorten, an denen Unbekannte ihnen beim Eingeben ihrer Benutzerinformationen über die Schulter schauen können.

Selbstverständlich sollte sein, dass bei der Einrichtung eines SSL-VPNs die SSL-Verschlüsselung eingeschaltet wird, dennoch gibt es Installationen, bei denen dies einfach vergessen wurde.

Die Browserseite

Der Browser ist der Teil eines SSL-VPNs, den Administratoren am wenigsten im Griff haben. Ein großes Problem ist, dass sensible Daten möglicherweise auf einem öffentlichen Computer zurückbleiben, nachdem sie Sitzung beendet ist. Ein Beispiel: Ein Benutzer, prüft an einem Internet-Kiosk seine E-Mail öffnet und dabei ein Textdokument mit vertraulichen Informationen. Dadurch wird auf dem Internet-Kiosk eine temporäre Datei mit dem Inhalt des Textdokuments erzeugt, auf die jeder nachfolgende Benutzer zugreifen könnte.

Die Angelegenheit ist aber noch viel komplexer, denn sensible Daten werden nicht nur in temporären Dateien »gecached« sondern auch in anderen Browser-Cacheeinträgen, die während der Benutzersitzung erzeugt werden, in URL-Einträgen und Absenderfeldern, die sich das System für die automatische Vervollständigung merkt, in temporären Dateien, die während Dateidownloads erzeugt werden, in Cookies, in History- oder Verlaufsinformationen und als Anmeldeinformationen des Benutzers.

Dagegen setzt man sich durch Implementation eines »virtuellen Shredders« als Teil des SSL-VPNs zur Wehr. Diese häufig als Java- oder ActiveX-Download implementierte Technologie erfüllt zwei Zwecke:

• Sie löscht von den Zugriffsgeräten alle Formen temporärer Dateien, Browser-Caches, Cookies, heruntergeladene Dateien und Webseiten, Verlaufs-, Benutzeranmelde- und andere empfindliche Informationen.

• Sie erzwingt Sicherheitsrichtlinien in Fällen, in denen sie nicht ausgeführt werden kann. So könnte ein Internet-Kiosk den Download ausführbarer Dateien und damit auch den Download der Virtual-Shredder-Appliktion verweigern. Falls der Benutzer sich den Computer für den Zugriff auf das SSL-VPN nur geliehen hat, möchte er vielleicht selbst das Herunterladen von Dateien vermeiden. Dummerweise sind es genau Internet-Kioske und geliehene Computer, die das größte Sicherheitsrisiko darstellen. Darum muss ein SSL-VPN in der Lage sein, mit solchen Situationen richtig umzugehen. Lassen sich beispielsweise temporäre Dateien nicht durch einen virtuellen Shredder löschen, dann sollte das SSL-VPN vielleicht den Download von E-Mail-Dateianhängen verweigern, aber den Abruf von Mail ohne Anhang trotzdem zulassen.

Ein virtueller Shredder kann natürlich nicht davor schützen, dass sensible Informationen durch Benutzerfehler verbreitet werden. Die Applikation kann beispielsweise nicht verhindern, dass ein Benutzer eine vertrauliche Datei auf der Festplatte eines geliehenen Computers speichert oder dass er oder sie die Liste mit den Passwörtern neben dem Internet-Kiosk liegen lässt. Aber dies sind keine speziellen SSL-VPN-Probleme.

Wie temporäre Dateien könnten auch Benutzeranmeldeinformationen nach Ende der Sitzung auf öffentlichen Computern verbleiben. Der Benutzer hat sich vielleicht ordentlich abgemeldet, trotzdem könnte ein neugieriger nachfolgender Benutzer selbst ohne Kenntnis des Passworts die Sitzung des Originalbenutzers wiederbeleben. Das ist möglich, weil viele Applikationen auf HTTP-Basic-Authentication antworten. HTTP-Baisc-Authentication speichert die Anmeldeinformationen des Benutzers nach der erstmaligen Anmeldung in einem Cache, damit der Benutzer nicht bei jeder Anforderung neuer Webseiten erneut zur Eingabe aufgefordert wird. Leider löscht die Abmeldung vom SSL-VPN diese Anmeldeinformationen nicht immer aus dem Cache. Die Lösung dieses Problems ist die Nutzung einer auf Formular basierenden Authentifikation. Das SSL-VPN sollte auf HTTP-Basic-Authentication-Anfragen interner Server antworten, so dass diese Anfragen niemals die Browser erreichen.

Und wenn der Benutzer einfach nur den Web-Browser schließt, ohne sich abzumelden? Oder wenn der Benutzer nach dem Zugriff auf Unternehmensressourcen einfach eine andere Web-Site aufruft und vergisst, dass die SSL-VPN-Sitzung noch immer aktiv ist? Wie dem auch sein, keine Organisation kann sich darauf verlassen, dass sich jeder immer ordnungsgemäß abmeldet.

Für diesen Fall sind Timeouts zu konfigurieren, die gewährleisten, dass Sitzungen nicht endlos lange aktiv bleiben, wenn Teilnehmer sich nicht abmelden. Einfache Timeouts könnten aber dazu führen, dass legitime Benutzer Arbeit verlieren, wenn sie lange E-Mail-Nachrichten eintippen oder große Webformulare ausfüllen, denn weder das SSL-VPN noch die internen Server entdecken Aktivitäten, die ausschließlich im Browser stattfinden. Hierfür existieren aber Timeout-Systeme, die ein oder zwei Minuten vor dem Timeout eine Warnung senden und damit die Gelegenheit geben, die Sitzung zu erhalten. Aufgegebene Sessions werden hingegen abgebrochen. Empfehlenswert ist außerdem, die Benutzer unabhängig von der Aktivität regelmäßig zur erneuten Eingabe ihrer Anmeldeinformationen aufzufordern. Dadurch bleibt das System geschützt, falls sich ein fremder Benutzer der Maschine nähert, bevor die aufgegebene Sitzung abgebrochen wird.

Viren und Würmer könnten von Home-Computern und geliehenen Maschinen via SSL-VPN ins interne Netzwerk transportiert werden. In diesem Fall hilft wieder die Filterung auf Applikationsebene. So, wie diese Filter Hacker an Angriffen auf Backend-Systeme hindern, hindern auch sie Viren und Würmer daran, dies zu tun.

Es ist möglich, dass interne Applikationen Referenzen auf interne, nicht im DNS aufgelistete Systeme oder IP-Adressen enthalten, die nur im internen Netzwerk gültig sind. Hier muss das SSL-VPN alle Referenzen zu internen Servern innerhalb interner Applikationen in ein Format konvertieren, das den Zugriff aufs Internet möglich macht. Diese Konvertierung führt eine als Host-Address-Translation (HAT) bekannte Technik durch, deren Implementation von Produkt zu Produkt variiert. Mit der HAT-Engine gibt es ein Problem: Nicht korrekt implementiert, könnte sie Informationen über das interne Netzwerk enthüllen. Beispielsweise, indem sie jedem Benutzer (und nachfolgenden Benutzern, falls solche Daten in der History des Browsers verbleiben), der auf das SSL-VPN zugreift, die Namen der internen Systeme und die Ports, auf die diese Systeme hören, zeigt. Die Lösung? Das SSL-VPN ist so zu konfigurieren, dass es bei jeder Kommunikation mit Benutzern die Hostnamen, IP-Adressen und alle anderen Informationen über die interne Infrastruktur verschlüsselt.

Die Veröffentlichung von Informationen über die interne Infrastruktur ist nicht notwendig, damit SSL-VPN funktioniert. Einige SSL-VPN-Produkte verschlüsseln Hostnamen und IP-Adressen »out of the box«, andere verlangen die manuelle Konfiguration, und wieder andere bieten überhaupt kein solches Feature – von der zuletzt genannten Variante sollten sicherheitsbewusste Organisationen die Finger lassen.

Fazit

SSL-VPNs gibt es zwar schon eine Weile, aber richtig in Schwung kommt die Sache erst jetzt. Bei den angebotenen Produkten handelt es sich in der Regel um Appliances, also Systeme, bei denen die Software auf dezidierter Hardware vorinstalliert und -konfiguriert ist. Der Markt entwickelt sich schnell. Ursprünglich boten nur einige Spezialisten wie Aventail, Netilla und Whale SSL-VPN-Lösungen an, aber die großen Hersteller haben Interesse bekundet. Am Geschäft beteiligt sind unter anderem große Netzwerk- und Firewall-Anbieter wie Netscreen und F5 Networks, die eignes für die SSL-VPN-Entwicklung Spezialisten eingekauft haben, und Unternehmen wie Check Point, Cisco oder Nokia, die selbst entwickeln. Gegenwärtig sieht es so aus, dass die im eigenen Haus entwickelten Systeme weniger funktionell sind, trotzdem ist Nokias NSAS eine der fortgeschrittensten Lösungen. Preislich startet eine SSL-VPN-Lösung für fünf Benutzer bei rund 4500 Euro; für etwa 25000 Euro erhält man eine Lösung für 30 Benutzer. Diese Preise mögen hoch erscheinen, wenn man aber berücksichtigt, dass durch den Einsatz einer SSL-VPN-Lösung möglicherweise viel teure Hardware, beispielsweise Notebooks, eingespart wird, sieht es schon ein bisschen besser aus.

SSL-VPNs bieten einige Vorteile gegenüber anderen Remote-Access-Technologien und lassen sich sicher implementieren. Allerdings kann ein SSL-VPN die Funktionalität eines IPSec-VPNs nicht vollständig ersetzen. Für die Masse der Anwender sind SSL-VPNs zweifellos bequemer als IPSec-VPNs, aber in den meisten Organisationen arbeiten einige technische Benutzer, beispielsweise Systemadministratoren und andere IT-Profis, die den vollständigen Zugriff auf Netzwerkebene benötigen, den IPSec-VPNs bieten. Für Site-zu-Site-Connectivity bleibt IPSec-VPN ohnehin erste Wahl. [ dj ]