Verwendet man für die Kommunikation mit dem Unternehmensnetzwerk ein VPN, dann ist sichergestellt, dass alle im Unternehmen verwendeten Netzwerkregeln auch für die mobilen Geräte gelten. Und genau hier entsteht die Problematik, denn je nachdem, ob es sich bei dem Smartphone oder Tablet um ein von dem Unternehmen gestelltes Gerät handelt, oder ob es Eigentum der Mitarbeiter ist, können die Anforderungen, wie ein solches VPN zu nutzen ist, stark schwanken.
Dementsprechend ist die Geschichte der Entwicklung des VPNs im iOS-Kontext auch schon eine recht lange. Gestartet mit iOS 3, wo noch wesentliche Enterprise-Standards fehlten, entwickelte Apple neben der Unterstützung weiterer Standards vor allem verschiedene Ausprägungsformen des VPNs. Mittlerweile unterscheidet man folgende VPN-Konfigurationen:
-
Standard: Manuell startbares VPN auf Basis der eingebauten VPN-Clients
-
Third-Party-VPN-Clients
-
On-Demand-VPN
-
Always-On-VPN
-
Per-App-VPN
Mittels On-Demand-VPN können Domains so gemanagt werden, dass immer, wenn der Safari Browser oder eine App auf diese zugreifen möchte, eine VPN-Verbindung aufgebaut wird. Mit Always-On-VPN, das in der Version iOS 8 hinzukam und das iPhone quasi wie einen Blackberry betreibt, wird beim Einschalten des Gerätes ein VPN gestartet, das userseitig nicht deaktiviert werden kann. Diese Form, die sicherlich nur bei unternehmenseigenen Geräte ihre Anwendung findet, stellt sicher, dass die gesamte Kommunikation über das Unternehmensnetzwerk geroutet wird und dort entsprechend überwacht und kontrolliert werden kann.
VPN und ByoD?
Dass dies im ByoD-Kontext nicht akzeptabel ist, ist selbstverständlich. Deshalb führte Apple bereits mit der Version 8 das sogenannte Per-App-VPN ein. Dieses VPN wird nur von gemanagten Apps verwendet und direkt über die MDM-Lösung ausgerollt. Klassische Consumer-Anwendungen wie YouTube und WhatsApp bleiben außen vor. Dies führt nicht nur dazu, dass Anwender sich bei der Benutzung dieser App nicht überwacht fühlen, sondern auch dazu, dass das Unternehmensnetzwerk von privatem Traffic verschont bleibt.
Ein Beispiel, dass den Nutzen von Per-App-VPN schnell verständlich macht, ist das Unterbinden des Dropbox-Zugriffs von Microsoft Office. Verwendet man das Per-App-VPN für Microsoft Office, so kann der IT Administrator im Netzwerk einfach über entsprechende DNS-Einträge den Zugriff auf Dropbox unterbinden. Da das Per-App-VPN aber nur für Microsoft Office greift, ist es auf dem iPhone selbst dann noch möglich, Dropbox im privaten Kontext zu benutzen.
Das Per-App-VPN ist auch zentraler Bestandteil des nativen Business-Containers. Dieser lässt sich vollständig auf Basis des Betriebssystems erstellen und benötigt lediglich ein Enterprise-Mobility-Management- (EMM-)System, das diese Funktionen nutzen kann, wie beispielsweise der Cortado Corporate Server oder die auf Apple fokussierte Management Lösung Caspar Suite von JAMF. Third-Party-Container, wie der von Good Technology oder App-Wrapping, wie beispielsweise von Citrix, Airwatch oder MobileIron angeboten, verlieren an Bedeutung.
Interessant ist dabei, das es Apple durch die native Unterstützung nicht nur ermöglicht, Anwendungen mit dem Per-App-VPN zu verbinden. Über das Konzept der gemanagten Domain stellt Apple außerdem sicher, dass auch der Emailverkehr sowie der Zugriff auf bestimmte Websites, meist Intranet-Sites, nur über dieses Per-App-VPN erfolgt.
Mit dieser Technologie entsteht folglich ein vollständig abgeschlossener Container, inklusive Mail-App und Secure Browser, der über ein gesichertes VPN mit dem Unternehmen verbunden ist, ohne dabei den Anwender bei dem Gebrauch privater Anwendungen einzuschränken.
Mit iOS 8 setzte Per-App-VPN noch ein spezielles VPN voraus, das nur von wenigen klassischen VPN-Anbietern unterstützt wurde. Den breitesten Support bot hier wohl F5. Airwatch und MobileIron entwickelten ihre eigenen Lösungen. Diese Anforderung und die etwas komplexe Umsetzung verhinderten bislang den Durchbruch dieses Konzeptes. Mit iOS 9 kann sich dies wesentlich verändern. Denn mit iOS 9 ermöglicht es Apple nun, das Per-App-VPN mit jedem VPN zu erstellen, das von dem eingebauten VPN-Client unterstützt wird. Da dieser sich über die Jahre stark weiterentwickelt hat, kann davon ausgegangen werden, das sich Per-App-VPN in nahezu jedem Unternehmensnetzwerk einsetzen lässt.
Wenige Schritte zum Per-App-VPN
Und so erstellen Sie ein per-App VPN für iOS Geräte: Die VPN-Konfiguration wird als Profil über ein EMM-System auf Ihrem Gerät installiert. Neben den grundsätzlichen Verbindungsdaten wird dabei angegeben, dass dieses VPN als Per-App-VPN eingerichtet werden soll. Durch Angabe spezifischer Domains kann dieses VPN auch gleichzeitig als On-Demand-VPN verwendet werden. Solche Domains werden auch als Managed Domains bezeichnet.
Im nächsten Schritt verteilen Sie das soeben erstellte VPN-Profil auf die Applikationen Ihrer Wahl. Per-App-VPN ist dabei ausschließlich auf gemanagte Applikationen anwendbar. Wichtig dabei ist zu bemerken, dass dies für alle Anwendungen im App Store möglich ist und keinerlei Anpassung der Anwendung erfordert. Auf dem Gerät selbst kann das Profil dann nach der Übertragung jederzeit überprüft werden. Wie auf dem Bild deutlich zu erkennen ist, gilt dies sowohl für Managed-Apps wie auch Managed-Domains.
Foto: Cortado Mobile Solutions GmbH
Wird nun eine der im Profil hinterlegten Anwendungen geöffnet, öffnet sich geräteseitig automatisch das VPN. Je nachdem, ob Sie die Zugangsdaten über das Profil verteilt haben, werden diese abgefragt. Die Zugangsdaten können dabei als Teil des Profils auf das Gerät gebracht werden. Alternativ kann der Nutzer auch zur Eingabe aufgefordert werden. Analog verhält es sich beim Öffnen einer im Profil hinterlegten Domain (VPN on-demand).
Fazit
Per App-VPN ist die mobile VPN-Variante der Wahl. Mit iOS 9 ist diese letztendlich nun recht einfach für nahezu jede Netzinfrastruktur umzusetzen und erfordert neben einem EMM-System keine weitere Investition. Während Apple mit dem Per-App-VPN und den Managed-Apps, Managed-Email-Accounts und Managed Domains einen fast unsichtbaren Business-Container ermöglicht, geht Google mit Android for Work den Weg, dass der Anwender explizit in den Business-Bereich wechseln muss. Beide Ansätze haben ihre Vorzüge, letztendlich beweisen beide, dass die Bildung sicherer nativer Business-Container nun ohne Einschränkungen und ohne aufwändige Anpassungen von Apps möglich ist. (mb)