9
SSL-VPNs im Enterprise Umfeld
Information und Erfahrungsbericht zu SSL-VPNs
Jeder Admin einer Enterprise Umgebung wird bei der Auswahl einer aktuellen Remote Access Lösung (z. B. für Homeoffice oder auch Aussendienstmitarbeiter) über SSL-VPNs stolpern.
Bis vor wenigen Jahren war der de facto Standard in Sachen Remote Access IPSEC VPN.
Bei IPSEC VPN ist der Zugang so gestaltet, dass der Client PC eine VPN Client Software benötigt, um einen IPSEC Tunnel zum Firmen-VPN Server herstellen zu können, über den dann verschlüsselt auf Firmendaten und Systeme zugegriffen werden kann.
Mittlerweile verdrängen SSL-VPN Lösungen nach und nach die IPSEC Variante.
Warum ist das so?
SSL-VPN Lösungen versprechen den clientlosen Zugriff auf Firmenressourcen.
Da jeder PC einen Web-Browser enthält, der schon SSL unterstützt, muss (angeblich) keine zusätzliche Software installiert werden.
Das klingt schonmal super - verringert es doch den Support massiv, da es erfahrungsgemäss viel Arbeit bedeutet, tausende von Client PCs zu administrieren, einen VPN Client bereitzustellen und zu installieren, und bei Bedarf upzudaten.
Tatsächlich ist es so dass bei den gängigen SSL-VPN Lösungen (Cisco ASA, Juniper Secure Access, Avantail EX1600) kein VPN Client auf dem Client installiert werden muss. Versprechen eingelöst!
Die Realität sieht leider ein wenig anders aus.
Für den Zugriff auf Dateien und Intranet Webseiten benötigt man tatsächlich überhaupt keine Clientsoftware auf dem User-PC.
Der User greift mit seinem Web-Browser auf eine URL zu, authentisiert sich, und schon hat er Zugriff auf Netzlaufwerke und Intranet Webseiten.
Will der User jedoch - wie von IPSEC VPN gewohnt - einen vollen VPN Tunnel zum Firmennetzwerk aufbauen, nützt ihm der Web-Browser recht wenig. Die SSL-VPN Lösungen mogeln in diesem Fall einen VPN Client auf den User PC, mit dem er dann einen vollwertigen VPN Tunnel aufbauen kann.
Zusätzlich bieten die SSL-VPN Lösungen weitere Zugriffsmöglichkeiten auf Firmenressourcen an, beispielsweise RDP, SSH, Telnet, VNC Clients, mit denen externe Mitarbeiter auf Firmeninterne Systeme zugreifen können. Auch in diesem Fall muss ein entsprechender Client auf dem User-PC installiert werden (was in der Regel über ActiveX oder JAVA-Applet erledigt wird).
Dies ist ein weiterer Client zusätzlich zum VPN-Client.
Haben die VPN-SSL Lösungen auch echte Vorteile?
Man mag es kaum glauben, doch sie haben auch Vorteile zu verbuchen.
Nachteile von SSL-VPNs
Empfehlenswerte Produkte
Juniper bietet mit der Secure Access Produktserie die auf einem Unix System basiert (wohl FreeBSD) ein äusserst stabiles und einfach zu administrierendes SSL-VPN an, das dennoch extrem flexible Möglichkeiten bietet.
Juniper hat hier das verblüffend liebevoll und alltagsgerecht gestaltete SSL-VPN Produkt von Netscreen (vormals Neoteris) aufgekauft und entwickelt es kontinuierlich weiter.
Es werden Windows, Linux und Mac unterstützt, auch 64bit Systeme.
Auch mit PDAs / MDAs kann man zugreifen - jedoch nur auf Daten und Intranetwebseiten. Ein voller VPN Connect ist mit PDAs mit der Juniper nicht machbar, ausser das MDA hat eine Java Runtime Engine, dann lässt sich auch der Network Connect Client Java Version installieren.
Der Network Connect VPN Client erscheint wie ein vollwertiger VPN Client für Windows, greift in Wahrheit jedoch auf DLLs vom Internet Explorer zu was die Abhängigkeit von einem kompatiblen Browser (der jedoch in aller Regel vorhanden ist) erhöht.
Dafür glänzt sie mit einem hervorragend stabilen und schnellen Hostcheck für Windows, Linux als auch Macintosh Clientsysteme.
Ein weiteres Highlight ist die VLAN Fähigkeit - der exteren VPN User kann direkt in sein Abteilungs-VLAN gesteckt werden, gesteuert über Radius-Attribute. Zudem ist dies recht einfach konfigurierbar.
Nervig ist die Web-Browserabhängigkeit. Internet Explorer, Firefox oder Safari müssen es sein, wenn man alle Funktionen nutzen möchte.
Des weiteren wird optional eine Secure Meeting Funktion angeboten, mit der man Online Konferenzen durchführen kann, vergleichbar mit TeamViewer kann man sich damit den Desktop eines Remote PCs anschauen um Support zu leisten, zu chatten oder eine Videokonferenz durchzuführen, wobei Audio jedoch nicht übertragen wird.
Auch die Authentisierungsmöglichkeiten lassen keine Wünsche offen - es gibt nichts was nicht unterstützt wird.
So kann die Juniper Lösung als Windows Domänenmitglied agieren und User direkt über das Active Directory authentisieren als auch autorisieren, auch über komplexe AD-Gesamtstrukturen hinweg. Ferner gibt es Radius, ACE (RSA SecurID), LDAP, Zertifikatsauthentisierung und einige weitere Möglichkeiten der Authentisierung von Benutzern, wobei auch beliebige Varianten parallel betrieben werden können - äusserst flexibel und praxisgerecht.
Die Rollenzuordnung (welcher User darf anhand welcher Merkmale auf was zugreifen) ist dermaßen flexibel und dennoch einfach zu handeln dass man sich frägt warum das bei der Konkurenz so kompliziert sein muss wenn es doch auch deutlich übesichtlicher und einfacher zu machen ist. Über Custom Expressions kann man hier bei Bedarf sehr komplexe Richtlinien schreiben und den Zugang sehr granular steuern.
Der Juniper Support reagiert auf Cases sehr schnell und engagiert. Das hervorragende deutsche Admin-Handbuch und die sehr einfach handhabbare Update Funktionalität eines Clusters mit Rollback-Funktion sind weitere Features zu denen man Juniper nur gratulieren kann.
Cisco bietet mit der ASA eine SSL-VPN Lösung an, die einen vollwertigen VPN Client (AnyConnect) mitbringt. Dies ist derzeit der einzige Cisco VPN Client der auch Windows 64bit Systeme unterstützt.
Mit der Cisco Secure Desktop Funktion ist auch eine umfangreiche Client-Überprüfungsoption dabei, die jedoch extra lizensiert werden muss.
Im Vergleich zu Juniper hat Cisco den SSL-VPN Markt etwas "verschlafen". Die ASA mit ASDM als Admin-Schnittstelle erinnert etwas an die Juniperlösung, erreicht jedoch nicht deren Möglichkeiten sowie einfache Administrierbarkeit.
Vorteil der Cisco Lösung wäre der "echte" VPN Client AnyConnect, sowie ein spezieller VPNClient für PDAs / MDAs, den Juniper nicht anbietet.
Ausserdem kann Cisco ASA zusätzlich noch ganz normal IPsEC VPN anbieten, was auch nicht pro User lizensiert wird.
Man kann also auch "gemischt" fahren und nen Teil der Clients mit IPSEC Software versorgen, und nur für die 64bit-Spezialisten (teure) SSL-VPN Lizenzen zusätzlich kaufen wenn man mag.
Dann hat man allerdings auch den doppelten Aufwand - IPSEC VPN Client & AnyConnect werden beide ihre Tücken haben und man muss ich dann mit beidem auskennen u. Support leisten können.
Auf dem deutschen Markt recht unterbelichtet, in Amerika jedoch angeblich verbreitet ist Avantail ein Pionier der SSL-VPN Lösungen und ist schon recht lange auf dem Markt, wurde letztes Jahr jedoch von Soniqwall geschluckt.
Eine ausgereifte Lösung, die mit Juniper mithalten kann, bei der Administration jedoch weniger flexibel und komplizierter zu konfigureren sein soll. Vorteil von Avantail wäre ein onboard Loadbalancing, sowie ein vollwertiger Fat VPN Client sowie eine ausgereifte Hostcheck Funktion.
Citrix ist vor allem durch seine Terminaldienste ein weit verbreiteter Hersteller. Will man Citrix Anwendungen optimal mit einer SSL-VPN Lösung verbinden und hat nur Windows Clients könnte dies das Produkt der Wahl sein.
Fazit
Was soll man nun vom SSL-VPN Trend halten?
Die Preise für entsprechende Lösungen sind eine Frechheit. Für 1000 gleichzeitige VPN Verbindungen kann man gut und gerne 100.000 € für einen hochverfügbaren Cluster (2 Knoten) veranschlagen, da pro gleichzeitig angemeldetem Benutzer lizensiert wird. Wenn nach 3-5 Jahren ein aktuelleres Modell gekauft wird, kann man die Lizenzen nicht mitnehmen - es sind wieder 100.000 € fällig.
Dieses Geschäftsmodell betreiben wohl alle grossen SSL-VPN Anbieter.
Ist man auf grosse Flexibilität beim Remote Access angewiesen kommt man mit herkömmlichen Lösunen jedoch nicht ohne grösserem Aufwand weiter. Ob Funktionen wie Hostüberprüfung wirklich Sinn machen und der Preis die erhöhte Sicherheit rechtfertigt - das muss jeder selbst abwägen. Eine Hostüberprüfung egal mit welchem System (Network Admission Control) ist eine komplexe Angelegenheit die bei standardisierten Desktops gut funktioniert, jedoch prinzipbedingt die Verfügbarkeit aus User-Sicht einschränkt, da jede zusätzliche Komponente den Zugriff weiter verkompliziert und damit anfälliger für Inkompatibilitäten und Konfigurationsfehler macht.
Die SSL-VPNs werben ja mit der Verringerung der Managementkosten, da kein VPN Client benötigt wird und damit der Support deutlich geringer wird. Das ist glatt gelogen - ausser man billigt den Usern nur den Zugriff mit dem Web-Browser zu, auf Netzlaufwerke und Intranet-Webseiten.
Will der User jedoch einen vollen VPN Tunnel aufbauen, zm beispielsweise per Outlook direkt mit dem internen Exchange Server kommunizieren oder per Arbeitsplatz auf interne Netzlaufwerke zugreifen oder um sich direkt in der Windows Domäne anmelden zu können dann kommt man ohne VPN Client eben nicht aus und damit steigt wieder der Managementaufwand, auch wenn die SSL-VPNs den VPN Client mehr oder weniger elegant auf den Client PC "mogeln" per Java Applet oder ActiveX.
Die viel gepriesene "Einfachheit" der VPN-SSL Lösungen geht völlig flöten wenn man die (zugegebener Weise) tollen Zusatzfeatures nutzen möchte, wie Hostchecker, Cache Cleaner, Virtual Workspace, Secure Meeting, RDP, SSH, Telnet Clients. Jede zusätzliche Funktion die man dem User zur Verfügung stellt erhöht exponential die Anzahl möglicher Fehlerquellen, vor allem wenn es keine standardisierten Desktops gibt sondern jeder Client PC nach Gutdünken konfiguriert ist.
Auch bei jedem Upgrade stellt sich die Frage ob nach dem Upgrade auch alles so funktioniert wie vor dem Upgrade - die Abhängigkeiten sind recht komplex und man kommt um intensive Tests nicht herum, bevor man einen SSL-VPN Cluster upgradet auf den tausende von Benutzern zugreifen sollen.
Spielt Geld keine Rolle und ist eine stabile und flexible Hostüberprüfung sowie äusserst flexible Möglichkeiten der Zugriffssteuerung bei verhältnismässig übersichtlicher & leicht erlernbarer Administrierbarkeit notwendig ist die Juniper Lösung wohl das Produkt der Wahl.
Will man Citrix Terminaldienste mit einer vollwertigen VPN Lösung koppeln und hat nur Windows Clients wäre das Citrix Access Gateway das Produkt der Wahl, da es Citrix Applikationen nahtlos in ein Webportal einbindet. Juniper kann zwar auch mit Citrix - jedoch prinzipbedingt nicht so elegant wie das Citrix Access Gateway.
Will man einfach den Usern eine stabile VPN Lösung bieten und legt keinen Wert auf 64bit Unterstützung und Hostüberprüfung kann man getrost zu einer Cisco ASA Lösung greifen und nur die IPSEC Funktionalität nutzen, die nicht pro User lizensiert ist.
Um die Erreichbarkeit mit dem IPSEC Client auf SSL-VPN Niveau zu bringen kann man sich eines Tricks bedienen - Cisco unterstützt "IPSEC-over-TCP" wobei standardmässig Port TCP 10.000 benutzt wird um IKE Phase 1 und 2 in TCP zu packen.
Diesen Port kann man mit einem Befehl jedoch leicht auf 443 umbiegen - und voila hat man die Erreichbarkeitsvorteile von SSL-VPN auch mit IPSEC.
Wie erwähnt bietet Cisco jedoch derzeit wohl aus (unverschämten) Marketinggründen keinen IPSEC Client für 64bit Systeme an.
Mit SSL-VPNs hat man zwar viel mehr Möglichkeiten - aber auch viel mehr Arbeit als mit herkömmlichen VPN Lösungen, wenn man die Möglichkeiten auch einsetzen will.
Alternative wären Citrix Terminaldienste, die Zugriff auf weitaus mehr Anwendungen bieten und andere Vorteile bieten (zentrale Verwaltung von Softwarelizensen u. Softwareupgrades, Sicherheit vor Angriffen auf Layer3 Ebene), jedoch vom User eine recht starke Umgewöhnung im Vergleich zu einer VPN Verbindung erfordern, was nicht jedermanns Sache ist.
Hier eine Einschätzung von SSL-VPNs durch GARTNER:
http://mediaproducts.gartner.com/reprints/sonicwall/article1/article1.h ...
Jeder Admin einer Enterprise Umgebung wird bei der Auswahl einer aktuellen Remote Access Lösung (z. B. für Homeoffice oder auch Aussendienstmitarbeiter) über SSL-VPNs stolpern.
Bis vor wenigen Jahren war der de facto Standard in Sachen Remote Access IPSEC VPN.
Bei IPSEC VPN ist der Zugang so gestaltet, dass der Client PC eine VPN Client Software benötigt, um einen IPSEC Tunnel zum Firmen-VPN Server herstellen zu können, über den dann verschlüsselt auf Firmendaten und Systeme zugegriffen werden kann.
Mittlerweile verdrängen SSL-VPN Lösungen nach und nach die IPSEC Variante.
Warum ist das so?
SSL-VPN Lösungen versprechen den clientlosen Zugriff auf Firmenressourcen.
Da jeder PC einen Web-Browser enthält, der schon SSL unterstützt, muss (angeblich) keine zusätzliche Software installiert werden.
Das klingt schonmal super - verringert es doch den Support massiv, da es erfahrungsgemäss viel Arbeit bedeutet, tausende von Client PCs zu administrieren, einen VPN Client bereitzustellen und zu installieren, und bei Bedarf upzudaten.
Tatsächlich ist es so dass bei den gängigen SSL-VPN Lösungen (Cisco ASA, Juniper Secure Access, Avantail EX1600) kein VPN Client auf dem Client installiert werden muss. Versprechen eingelöst!
Die Realität sieht leider ein wenig anders aus.
Für den Zugriff auf Dateien und Intranet Webseiten benötigt man tatsächlich überhaupt keine Clientsoftware auf dem User-PC.
Der User greift mit seinem Web-Browser auf eine URL zu, authentisiert sich, und schon hat er Zugriff auf Netzlaufwerke und Intranet Webseiten.
Will der User jedoch - wie von IPSEC VPN gewohnt - einen vollen VPN Tunnel zum Firmennetzwerk aufbauen, nützt ihm der Web-Browser recht wenig. Die SSL-VPN Lösungen mogeln in diesem Fall einen VPN Client auf den User PC, mit dem er dann einen vollwertigen VPN Tunnel aufbauen kann.
Zusätzlich bieten die SSL-VPN Lösungen weitere Zugriffsmöglichkeiten auf Firmenressourcen an, beispielsweise RDP, SSH, Telnet, VNC Clients, mit denen externe Mitarbeiter auf Firmeninterne Systeme zugreifen können. Auch in diesem Fall muss ein entsprechender Client auf dem User-PC installiert werden (was in der Regel über ActiveX oder JAVA-Applet erledigt wird).
Dies ist ein weiterer Client zusätzlich zum VPN-Client.
Haben die VPN-SSL Lösungen auch echte Vorteile?
Man mag es kaum glauben, doch sie haben auch Vorteile zu verbuchen.
- Es wird nur Port TCP 443 benötigt, im Gegensatz zu IPSEC welches UDP 500, UDP4500 und je nach Konfiguration TCP 10.000 benötigt. Damit ist eine verbesserte Erreichbarkeit gewährleistet, da Port TCP443 stets offen ist, wenn man eine Internetverbindung hat.
- SSL-VPNs sind einfacher einzurichten. Der Admin muss nicht für jeden VPN Client (Windows, Linux, Mac) spezielle Profile einrichten, und diesen Vorgang bei jedem VPN-Client Update wiederholen.
- Der VPN Client wird automatisch upgedatet wenn eine neuere Version verfügbar ist. Das ist wohl eines der Key-Features von SSL-VPNs und funktioniert wunderbar.
- Der Zugang kann sehr flexibel konfiguriert werden. So kann man beispielsweise eine URL einrichten für Mitarbeiter wie https://vpn.firma.de und zusätzlich Zugänge mit eingeschränktem Zugriff bereitstellen, z. B. https://support.firma.de wobei bei zweiter URL nur Zugriff auf einen bestimmten Intranetserver erlaubt werden kann, und nicht Zugriff auf ALLE Intranet Ressourcen.
- Wenn nur Zugriff auf Daten und Intranetwebseiten benötigt wird kommt der Client PC tatsächlich ohne zusätzliche Client Software aus.
- Es werden bei allen führenden Anbietern Sicherheitsüberprüfungs-Techniken onboard angeboten, die zugreifende PCs auf Merkmale untersuchen können (z. B. Antivirussoftware, Updatestand, laufende Prozesse, Registryeinträge usw) und entsprechend der Prüfung dem Benutzer vollen oder auch nur eingeschränkten Zugriff ermöglichen können, was äusserst granular konfigurierbar ist.
Nachteile von SSL-VPNs
- Wie alle Webanwendungen sind auch SSL-VPN Lösungen eher anfällig für Web-Angriffe wie Cross-Site-Scripting, Cookie Klau und Webserverangriffe
- Die Lizensierung erfolgt pro gleichzeitig angemeldetem User, was bei hunderten gleichzeitiger Sessions schon ganz schön ins Geld gehen kann.
- Hohe Browserabhängigkeit wenn man alle Funktionen nutzen möchte
- Der Zugriff funktioniert nicht auf alle Intranet Webanwendungen. Die Rewrite-Engine hat mit komplexen Webanwendungen unter Umständen Probleme - das muss man im Einzelfall testen und gegebenenfalls umständlich anpassen!
- Bei Dateizugriff per Webbrowser ist prinzipbedingt kein Drag & Drop möglich - ein .doc File beispielsweise muss heruntergeladen, bearbeitet und wieder hochgeladen werden. Man kann Firmen-Netzlaufwerke in seinem Arbeitsplatz nur mit einer vollwertigen VPN Verbindung einbinden um wie gewohnt auf Dateien zugreifen zu können.
Empfehlenswerte Produkte
- Juniper Secure Access (vormals Netscreen / vormals Neoteris)
Juniper bietet mit der Secure Access Produktserie die auf einem Unix System basiert (wohl FreeBSD) ein äusserst stabiles und einfach zu administrierendes SSL-VPN an, das dennoch extrem flexible Möglichkeiten bietet.
Juniper hat hier das verblüffend liebevoll und alltagsgerecht gestaltete SSL-VPN Produkt von Netscreen (vormals Neoteris) aufgekauft und entwickelt es kontinuierlich weiter.
Es werden Windows, Linux und Mac unterstützt, auch 64bit Systeme.
Auch mit PDAs / MDAs kann man zugreifen - jedoch nur auf Daten und Intranetwebseiten. Ein voller VPN Connect ist mit PDAs mit der Juniper nicht machbar, ausser das MDA hat eine Java Runtime Engine, dann lässt sich auch der Network Connect Client Java Version installieren.
Der Network Connect VPN Client erscheint wie ein vollwertiger VPN Client für Windows, greift in Wahrheit jedoch auf DLLs vom Internet Explorer zu was die Abhängigkeit von einem kompatiblen Browser (der jedoch in aller Regel vorhanden ist) erhöht.
Dafür glänzt sie mit einem hervorragend stabilen und schnellen Hostcheck für Windows, Linux als auch Macintosh Clientsysteme.
Ein weiteres Highlight ist die VLAN Fähigkeit - der exteren VPN User kann direkt in sein Abteilungs-VLAN gesteckt werden, gesteuert über Radius-Attribute. Zudem ist dies recht einfach konfigurierbar.
Nervig ist die Web-Browserabhängigkeit. Internet Explorer, Firefox oder Safari müssen es sein, wenn man alle Funktionen nutzen möchte.
Des weiteren wird optional eine Secure Meeting Funktion angeboten, mit der man Online Konferenzen durchführen kann, vergleichbar mit TeamViewer kann man sich damit den Desktop eines Remote PCs anschauen um Support zu leisten, zu chatten oder eine Videokonferenz durchzuführen, wobei Audio jedoch nicht übertragen wird.
Auch die Authentisierungsmöglichkeiten lassen keine Wünsche offen - es gibt nichts was nicht unterstützt wird.
So kann die Juniper Lösung als Windows Domänenmitglied agieren und User direkt über das Active Directory authentisieren als auch autorisieren, auch über komplexe AD-Gesamtstrukturen hinweg. Ferner gibt es Radius, ACE (RSA SecurID), LDAP, Zertifikatsauthentisierung und einige weitere Möglichkeiten der Authentisierung von Benutzern, wobei auch beliebige Varianten parallel betrieben werden können - äusserst flexibel und praxisgerecht.
Die Rollenzuordnung (welcher User darf anhand welcher Merkmale auf was zugreifen) ist dermaßen flexibel und dennoch einfach zu handeln dass man sich frägt warum das bei der Konkurenz so kompliziert sein muss wenn es doch auch deutlich übesichtlicher und einfacher zu machen ist. Über Custom Expressions kann man hier bei Bedarf sehr komplexe Richtlinien schreiben und den Zugang sehr granular steuern.
Der Juniper Support reagiert auf Cases sehr schnell und engagiert. Das hervorragende deutsche Admin-Handbuch und die sehr einfach handhabbare Update Funktionalität eines Clusters mit Rollback-Funktion sind weitere Features zu denen man Juniper nur gratulieren kann.
- Cisco ASA
Cisco bietet mit der ASA eine SSL-VPN Lösung an, die einen vollwertigen VPN Client (AnyConnect) mitbringt. Dies ist derzeit der einzige Cisco VPN Client der auch Windows 64bit Systeme unterstützt.
Mit der Cisco Secure Desktop Funktion ist auch eine umfangreiche Client-Überprüfungsoption dabei, die jedoch extra lizensiert werden muss.
Im Vergleich zu Juniper hat Cisco den SSL-VPN Markt etwas "verschlafen". Die ASA mit ASDM als Admin-Schnittstelle erinnert etwas an die Juniperlösung, erreicht jedoch nicht deren Möglichkeiten sowie einfache Administrierbarkeit.
Vorteil der Cisco Lösung wäre der "echte" VPN Client AnyConnect, sowie ein spezieller VPNClient für PDAs / MDAs, den Juniper nicht anbietet.
Ausserdem kann Cisco ASA zusätzlich noch ganz normal IPsEC VPN anbieten, was auch nicht pro User lizensiert wird.
Man kann also auch "gemischt" fahren und nen Teil der Clients mit IPSEC Software versorgen, und nur für die 64bit-Spezialisten (teure) SSL-VPN Lizenzen zusätzlich kaufen wenn man mag.
Dann hat man allerdings auch den doppelten Aufwand - IPSEC VPN Client & AnyConnect werden beide ihre Tücken haben und man muss ich dann mit beidem auskennen u. Support leisten können.
- Soniqwall / Aventail EX1600
Auf dem deutschen Markt recht unterbelichtet, in Amerika jedoch angeblich verbreitet ist Avantail ein Pionier der SSL-VPN Lösungen und ist schon recht lange auf dem Markt, wurde letztes Jahr jedoch von Soniqwall geschluckt.
Eine ausgereifte Lösung, die mit Juniper mithalten kann, bei der Administration jedoch weniger flexibel und komplizierter zu konfigureren sein soll. Vorteil von Avantail wäre ein onboard Loadbalancing, sowie ein vollwertiger Fat VPN Client sowie eine ausgereifte Hostcheck Funktion.
- Citrix Access Gateway
Citrix ist vor allem durch seine Terminaldienste ein weit verbreiteter Hersteller. Will man Citrix Anwendungen optimal mit einer SSL-VPN Lösung verbinden und hat nur Windows Clients könnte dies das Produkt der Wahl sein.
Fazit
Was soll man nun vom SSL-VPN Trend halten?
Die Preise für entsprechende Lösungen sind eine Frechheit. Für 1000 gleichzeitige VPN Verbindungen kann man gut und gerne 100.000 € für einen hochverfügbaren Cluster (2 Knoten) veranschlagen, da pro gleichzeitig angemeldetem Benutzer lizensiert wird. Wenn nach 3-5 Jahren ein aktuelleres Modell gekauft wird, kann man die Lizenzen nicht mitnehmen - es sind wieder 100.000 € fällig.
Dieses Geschäftsmodell betreiben wohl alle grossen SSL-VPN Anbieter.
Ist man auf grosse Flexibilität beim Remote Access angewiesen kommt man mit herkömmlichen Lösunen jedoch nicht ohne grösserem Aufwand weiter. Ob Funktionen wie Hostüberprüfung wirklich Sinn machen und der Preis die erhöhte Sicherheit rechtfertigt - das muss jeder selbst abwägen. Eine Hostüberprüfung egal mit welchem System (Network Admission Control) ist eine komplexe Angelegenheit die bei standardisierten Desktops gut funktioniert, jedoch prinzipbedingt die Verfügbarkeit aus User-Sicht einschränkt, da jede zusätzliche Komponente den Zugriff weiter verkompliziert und damit anfälliger für Inkompatibilitäten und Konfigurationsfehler macht.
Die SSL-VPNs werben ja mit der Verringerung der Managementkosten, da kein VPN Client benötigt wird und damit der Support deutlich geringer wird. Das ist glatt gelogen - ausser man billigt den Usern nur den Zugriff mit dem Web-Browser zu, auf Netzlaufwerke und Intranet-Webseiten.
Will der User jedoch einen vollen VPN Tunnel aufbauen, zm beispielsweise per Outlook direkt mit dem internen Exchange Server kommunizieren oder per Arbeitsplatz auf interne Netzlaufwerke zugreifen oder um sich direkt in der Windows Domäne anmelden zu können dann kommt man ohne VPN Client eben nicht aus und damit steigt wieder der Managementaufwand, auch wenn die SSL-VPNs den VPN Client mehr oder weniger elegant auf den Client PC "mogeln" per Java Applet oder ActiveX.
Die viel gepriesene "Einfachheit" der VPN-SSL Lösungen geht völlig flöten wenn man die (zugegebener Weise) tollen Zusatzfeatures nutzen möchte, wie Hostchecker, Cache Cleaner, Virtual Workspace, Secure Meeting, RDP, SSH, Telnet Clients. Jede zusätzliche Funktion die man dem User zur Verfügung stellt erhöht exponential die Anzahl möglicher Fehlerquellen, vor allem wenn es keine standardisierten Desktops gibt sondern jeder Client PC nach Gutdünken konfiguriert ist.
Auch bei jedem Upgrade stellt sich die Frage ob nach dem Upgrade auch alles so funktioniert wie vor dem Upgrade - die Abhängigkeiten sind recht komplex und man kommt um intensive Tests nicht herum, bevor man einen SSL-VPN Cluster upgradet auf den tausende von Benutzern zugreifen sollen.
Spielt Geld keine Rolle und ist eine stabile und flexible Hostüberprüfung sowie äusserst flexible Möglichkeiten der Zugriffssteuerung bei verhältnismässig übersichtlicher & leicht erlernbarer Administrierbarkeit notwendig ist die Juniper Lösung wohl das Produkt der Wahl.
Will man Citrix Terminaldienste mit einer vollwertigen VPN Lösung koppeln und hat nur Windows Clients wäre das Citrix Access Gateway das Produkt der Wahl, da es Citrix Applikationen nahtlos in ein Webportal einbindet. Juniper kann zwar auch mit Citrix - jedoch prinzipbedingt nicht so elegant wie das Citrix Access Gateway.
Will man einfach den Usern eine stabile VPN Lösung bieten und legt keinen Wert auf 64bit Unterstützung und Hostüberprüfung kann man getrost zu einer Cisco ASA Lösung greifen und nur die IPSEC Funktionalität nutzen, die nicht pro User lizensiert ist.
Um die Erreichbarkeit mit dem IPSEC Client auf SSL-VPN Niveau zu bringen kann man sich eines Tricks bedienen - Cisco unterstützt "IPSEC-over-TCP" wobei standardmässig Port TCP 10.000 benutzt wird um IKE Phase 1 und 2 in TCP zu packen.
Diesen Port kann man mit einem Befehl jedoch leicht auf 443 umbiegen - und voila hat man die Erreichbarkeitsvorteile von SSL-VPN auch mit IPSEC.
Wie erwähnt bietet Cisco jedoch derzeit wohl aus (unverschämten) Marketinggründen keinen IPSEC Client für 64bit Systeme an.
Mit SSL-VPNs hat man zwar viel mehr Möglichkeiten - aber auch viel mehr Arbeit als mit herkömmlichen VPN Lösungen, wenn man die Möglichkeiten auch einsetzen will.
Alternative wären Citrix Terminaldienste, die Zugriff auf weitaus mehr Anwendungen bieten und andere Vorteile bieten (zentrale Verwaltung von Softwarelizensen u. Softwareupgrades, Sicherheit vor Angriffen auf Layer3 Ebene), jedoch vom User eine recht starke Umgewöhnung im Vergleich zu einer VPN Verbindung erfordern, was nicht jedermanns Sache ist.
Hier eine Einschätzung von SSL-VPNs durch GARTNER:
http://mediaproducts.gartner.com/reprints/sonicwall/article1/article1.h ...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 87895
Url: https://administrator.de/tutorial/ssl-vpns-im-enterprise-umfeld-87895.html
Ausgedruckt am: 31.12.2024 um 09:12 Uhr
9 Kommentare
Neuester Kommentar
Es ist schade das du in dieser sonst sehr guten Anleitung ausschließlich den High End Profi Bereich ansprichst mit Appliances die im sehr hohen Euro Bereich liegen. Das ist in sofern schade da die Masse der Forumsuser hier wohl eher aus dem Consumer oder Klein- und Mittelstandsbereich kommen die aber natürlich somit auch in den Enterprise Bereich fallen.
Im Bezug auf SSL-VPNs gibt es aber dort auch durchaus gute Produkte die es ebenfalls wert gewesen wären sie zu erwähnen:
Für Bastler bietet sich sogar eine kleine, sehr preiswerte und effiziente VPN Lösung mit OpenVPN auf einem Edimax Router wie es auch hier beschrieben ist:
P.S.: IPsec nutzt ausser den o.a. Protokollen noch das Protokoll ESP (Nummer 50) und je nach Variante AH (Nummer 51) für den eigentlichen Datenlink wie du es ja in
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
auch sehr gut erklärst !
Im Bezug auf SSL-VPNs gibt es aber dort auch durchaus gute Produkte die es ebenfalls wert gewesen wären sie zu erwähnen:
Für Bastler bietet sich sogar eine kleine, sehr preiswerte und effiziente VPN Lösung mit OpenVPN auf einem Edimax Router wie es auch hier beschrieben ist:
P.S.: IPsec nutzt ausser den o.a. Protokollen noch das Protokoll ESP (Nummer 50) und je nach Variante AH (Nummer 51) für den eigentlichen Datenlink wie du es ja in
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
auch sehr gut erklärst !
Danke fuer die Infos aqui.
Hallo,
hier ist noch eine kurze Info bzgl. der folgenden Aussage:
Die Preise für entsprechende Lösungen sind eine Frechheit. Für 1000 gleichzeitige VPN Verbindungen kann man gut und gerne 100.000 € für einen hochverfügbaren Cluster (2 Knoten) veranschlagen, da pro gleichzeitig angemeldetem Benutzer lizensiert wird. Wenn nach 3-5 Jahren ein aktuelleres Modell gekauft wird, kann man die Lizenzen nicht mitnehmen - es sind wieder 100.000 € fällig.
Dieses Geschäftsmodell betreiben wohl alle grossen SSL-VPN Anbieter.
Zumindest bei Fortinet wird die Benutzeranzahl nicht lizensiert/limitiert, SSL-VPN's sind dabei auch schon bei den Einstiegsmodellen möglich (natürlich nicht mit 1000 Usern). Bei Fortinet kommen also nur Kosten für die Hardware und für die Support Services zusammen.
mfg
Harald
hier ist noch eine kurze Info bzgl. der folgenden Aussage:
Die Preise für entsprechende Lösungen sind eine Frechheit. Für 1000 gleichzeitige VPN Verbindungen kann man gut und gerne 100.000 € für einen hochverfügbaren Cluster (2 Knoten) veranschlagen, da pro gleichzeitig angemeldetem Benutzer lizensiert wird. Wenn nach 3-5 Jahren ein aktuelleres Modell gekauft wird, kann man die Lizenzen nicht mitnehmen - es sind wieder 100.000 € fällig.
Dieses Geschäftsmodell betreiben wohl alle grossen SSL-VPN Anbieter.
Zumindest bei Fortinet wird die Benutzeranzahl nicht lizensiert/limitiert, SSL-VPN's sind dabei auch schon bei den Einstiegsmodellen möglich (natürlich nicht mit 1000 Usern). Bei Fortinet kommen also nur Kosten für die Hardware und für die Support Services zusammen.
mfg
Harald
wie ist das mit CheckPoint ?
kann da jemand etwas dazu sagen und wie ist das im Vergleich zu Juniper ?
Vielen Dank schon mal im Vorraus
Blueslocke
kann da jemand etwas dazu sagen und wie ist das im Vergleich zu Juniper ?
Vielen Dank schon mal im Vorraus
Blueslocke
Ich kenne keinen der Checkpoint als SSL-VPN Gateway nutzt.
Was aber nix heissen muss.
Ist auch viel Geschmackssache dabei - ich denke mit Juniper SA oder Citrix AG kanin man wenig falsch machen, wobei ich voll auf Juniper schwöre. Das Teil ist easy einzurichten und dermassen flexibel dass es kaum was gibt was es nicht kann.
Das Citrix AG fand ich von der Bedienung recht bescheiden - doch das ist vielleicht auch Geschmackssache.
Nervig ist auch Adminkonsole per JAVA - Juniper kommt auch ohne aus, warum werden Admins ständig Webkonsolen die auf JAVA basieren aufgebürdet? DAs macht doch echt kein Spass sich täglich mit JAVA-Grauen herumzuärgern!
Was aber nix heissen muss.
Ist auch viel Geschmackssache dabei - ich denke mit Juniper SA oder Citrix AG kanin man wenig falsch machen, wobei ich voll auf Juniper schwöre. Das Teil ist easy einzurichten und dermassen flexibel dass es kaum was gibt was es nicht kann.
Das Citrix AG fand ich von der Bedienung recht bescheiden - doch das ist vielleicht auch Geschmackssache.
Nervig ist auch Adminkonsole per JAVA - Juniper kommt auch ohne aus, warum werden Admins ständig Webkonsolen die auf JAVA basieren aufgebürdet? DAs macht doch echt kein Spass sich täglich mit JAVA-Grauen herumzuärgern!
Ich kann hier jedermann noch die FortiGate Geräte empfehlen mal anzusehen. Laufen gut, sind einfach zu administrieren, können im Prinzip alles nötige und werden NICHT nach Usern lizenziert sondern pauschal nach Hardware.
Im Interprise Umfeld sehen wir daneben noch sehr häufig die Cisco ASA als Cluster hinter Loadbalancern.
Die Juniper kann in der Tag mega viel... aber da muß man sich erstma mit beschäftigen :o)... sehr mächtiges Gerät. So tief geht glaub ich kein anderes Gerät zu konfigurieren.
Im Interprise Umfeld sehen wir daneben noch sehr häufig die Cisco ASA als Cluster hinter Loadbalancern.
Die Juniper kann in der Tag mega viel... aber da muß man sich erstma mit beschäftigen :o)... sehr mächtiges Gerät. So tief geht glaub ich kein anderes Gerät zu konfigurieren.
Hi,
und F5 wird auch glatt unterschlagen ....
Gruß
und F5 wird auch glatt unterschlagen ....
Gruß
Zitat von @FlashOver:
Die Juniper kann in der Tag mega viel... aber da muß man sich erstma mit beschäftigen :o)... sehr mächtiges
Gerät. So tief geht glaub ich kein anderes Gerät zu konfigurieren.
Die Juniper kann in der Tag mega viel... aber da muß man sich erstma mit beschäftigen :o)... sehr mächtiges
Gerät. So tief geht glaub ich kein anderes Gerät zu konfigurieren.
Ich geb Brief und (Ralf) Siegel, dass die Juniper SA Geräte sehr einfach zu administrieren sind!
Man muss eigentlich nur einmalig das Konzept verstehen, dann ist alles klar.
Eigentlich in paar Schritten erklärt
1. Userrolle konfigurieren (einer Userrolle wird eine Zugriffsmethode zugewiesen, z. b. Clientless Access, VPN, RDP... sowie die Ressourcen definiert, z. B. Server-IP)
2. Userrealm konfigurieren (auf Realm Ebene wählt man den Authentisierungsserver sowie via "Rolemapping" unter welchen Bedingungen dem Anwender welche Userrolle zugewiesen wird)
3. Sign-in Policy konfigurieren (unter welcher URL z. b. access.firma.de/vertrieb ) man welchen Realm zugewiesen bekommt
4. Ressource Policies oder Ressource Profile konfigurieren (Berechtigungen - welche Rolle darf auf welche IPs/Ports zugreifen)
Im Verhältnis zur "Mächtigkeit" ist die Bedienung optimal gelöst, auf jeder adm. Webseite bekommt man "Sprungpunkte" die einem ungemein helfen, den "nächsten Konfigurationsschritt" zu machen.
Sehr schön sind auch spezialitäten wie Single Sign-on, VLAN fähigkeiten (genial!), und auch die allgemeine Stabilität und Zuverlässigkeit ist erste Sahne. Kenne kein problemloseres Gerät! Und ich kenne einige...
Im Enterprise Umfeld mit tausenden von Usern sind die Lizenzkosten ziemlich egal - der Support macht viel mehr bei den Kosten aus.
Daher ist es hier langfristig viel günstiger, auf das beste zu setzen was der markt bietet - zufriedene Anwender und wenig Tickets sind der Lohn!
Wie gesagt - ich bin weder Juniper Mitarbeiter noch bekomme ich Geld für meine Meinung. Erfahrungswerte.
Ähh ja, man muss sich halt auf das wesentliche konzentrieren.
