© Saimen., photocase.com

Wer einsieht, dass mitgebrachte Smartphones und Tablets für die Firmen-IT eine zu üppige Kost sind, kann die mobilen Clients zumindest auf das Nötigste reduzieren. Heraus kommen Gebilde, die man vom Admin-freundlichen Server-based Computing kennt: Thin Clients mit Webbrowser und Remote-Desktops.

Die Rechnung sei einfach, meint Vijay Dheap, Produkt Manager und Master Inventor bei IBM Security Systems: “Sicherheit bei “Bring your own Device” ist einfach die Summe aus Mobile Device Security, Mobile App Security und Mobile Access Security.” Gerade weil Anwender und Admins bei den ersten beiden Komponenten nur schwer die Oberhand behalten, gelte es dabei vor allem, das potenziell unsichere Smartphone oder Tablet immer als eine Plattform zu betrachten, die sich dem Zugriff der Firmen-IT und dem Schutz der Firewall entziehe, selbst wenn der Anwender damit im internen WLAN arbeite.

Deshalb empfehlen Sicherheitsspezialisten die Rechenpower des smarten Device links liegen zu lassen. Stattdessen lohne es, auf die bewährten Konzepte des Server-based Computing auszuweichen und den mobilen Client mit einer Software auszustatten, die den Zugriff auf die Serverdienste so sicher wie eben möglich gestalte.

Anachronistisch: Web und Desktop auf dem Telefon

Webanwendungen und – für die Übergangszeit – Remote-Desktop-Protokolle erben damit überraschend ein neues Einsatzfeld über ihren angestammten Thin-Client-Bereich hinaus, auch wenn die Bedienkonzepte eines RDP-, VNC- oder Citrix-Desktops “gar nicht zu dem vom Anwender präferierten App-Kontext-Switching und den kleinen Touchscreens passen” (Dheap). Immerhin lassen sich so bestehende Infrastrukturen auf Smartphones und Tablets bringen.

Auf lange Sicht muss das auch nach Meinung von Security-Experten eines deutschen Dax-Unternehmens mit eigenen Apps geschehen, die natürlich nicht die Desktop-Metapher der Windows-, Linux- und Mac-PCs nachahmen, sondern die Business- von der Applikationslogik trennen und so echte Apps für die Büro- und Branchensoftware aufs mobile Gerät bringen. Dabei wittern viele Unternehmen – sowohl Consultants als auch Software-Entwickler – gute Geschäfte.

Unsicherer Speicher

Doch bis es so weit ist, wollen mobile Mitarbeiter “schnell etwas auf dem Windows-Server fertig stellen” oder einfach per Office-Software nachsehen, auch unterwegs. Die Unternehmensdaten auf dem Smartphone zu speichern oder dem Gerät mit fremden Apps (etwa mit einem der vielen kostenlosen Dokumenten-Viewer) Zugriff zu verschaffen scheidet aus Sicherheitsgründen aus. Zu groß ist das Risiko, bei einem Verlust oder Diebstahl einem interessierten Außenstehenden Zugriff auf die Firmen-IT oder deren Daten zu erlauben.

Die erste Pflicht muss es folglich sein, das Speichern von Firmendaten oder Zugangs-Credentials auf dem Smartphone zu unterbinden. Weil das aber der vom Anwender gewünschten Usability widerspricht und es für alle Standardprotokolle (Web oder Remote-Desktop) unzählige Apps gibt, die diese Vorgabe umgehen (Abbildung 1, [1]), ist das auf einem Gerät, das nicht dem Einflussbereich der Firma untersteht, nur schwer umsetzbar.

Abbildung 1: Android VNC und Remote RDP Lite stehen stellvertretend für eine Vielzahl von Apps, die zwar zufriedenstellenden Remote-Zugriff ermöglichen, die Credentials aber auf dem Endgerät speichern.

Hinzu kommt, dass Benutzer das mehrfache Eingeben einer Username-Passwort-Kombination (beim Einschalten, beim Entschlüsseln der Dateisysteme, beim Verbindungsaufbau) auf die Dauer als nervig empfinden und zu umgehen suchen. Hier stehen sich wieder einmal die klassischen Ansprüche an Usability und grundlegende Sicherheitsanforderungen scheinbar unauflösbar gegenüber.

Office-Software und der Touchscreen

Damit nicht genug: Die GUIs der Marktführer sind – mit Ausnahme des kurz vor Redaktionsschluss präsentierten Microsoft Office [2] – nicht für den Touchscreen vorbereitet. Auch die Videos auf der Webseite von Citrix Receiver [3], einer App, die Desktop-Anwendungen (aus der virtuellen Desktop-Cloud, [4]) auf Android-Telefone bringt, zeigen die Schwächen eindrucksvoll.

Das Office-Fenster reicht stets über den kleinen Bildschirm hinaus, eine Darstellung im übersichtlicheren Vollbild ist offenbar nicht möglich. Für das Popup-Menü (rechte Maustaste) muss der Anwender länger auf das Display tippen. Die Eingabe von Text über die Touchscreen-Tastatur eignet sich sicherlich für kleinere Korrekturen, nicht aber für längere Texte oder die typischen Arbeiten einer Bürokraft.

Bitte warten …

Ein weiteres Problem, das alle Remote-Desktop-Apps teilen und für das die wenigsten Protokolle eine Lösung bieten, ist die Latenz. Verbindungen mit hoher Bandbreite wie UMTS, HSPA oder LTE schaffen zwar Übertragungsraten im DSL-Bereich (vorausgesetzt die Funkzelle hat Ressourcen frei), doch behindern die vergleichsweise langen Laufzeiten über das GSM-Netz das Steuern eines Remote-Desktops. Funktioniert die Eingabe von Text noch einigermaßen flüssig, gerät das Verschieben oder Ziehen von Elementen mit der Maus zur Qual. Wer das nicht glaubt, der versuche testweise über UMTS auf die VNC-Konsole von Mac OS X zuzugreifen.

Besser machen das Protokolle mit intelligenter Komprimierung und angepassten Caches wie die NX-Libraries, Microsofts Remote Desktop Protokoll (RDP), Citrix’ proprietäres ICA-Protokoll oder vollständig proprietäre Lösungen wie die von Teamviewer (Abbildung 2, [5]). Doch für Nomachines NX gibt es mangels X-Window keinen passenden Client für Apple oder Android und die Kompression von RDP und Teamviewer reicht meist nicht aus, um auch über langsame Leitungen ansprechende Ergebnisse zu erreichen. Eine Wifi-Verbindung ist dann Pflicht, was aber die Mobilität des Roadwarriors wiederum einschränkt.

Abbildung 2: Teamviewer bringt entfernte Desktops auch auf Android-Geräte. Mangels Touch-Integration gestaltet sich deren Bedienung jedoch schwierig.

Hinzu kommt: Jeder Remote-Desktop-Client, der um der Bedienbarkeit oder Bandbreite willen einen lokalen Cache vorhält, verschafft damit einem Angreifer auf dem Smartphone ein verlockendes Ziel – auch hier kollidieren Usability und Sicherheitsanspruch.

HTML-5-Apps

Einen Ausweg aus dem Dilemma sehen viele Sicherheitsexperten in eigenen Apps, mit ihnen könnten Unternehmen den zweiten Faktor der oben genannten Gleichung adressieren: Mobile App Security. Die Apps müssen nicht zwingend als Standalone-Programme konzipiert sein, es reicht auch aus, einfach eine Art mit Sicherheitsfunktionen erweiterten Wrapper um einen angepassten Browser zu wickeln und die Inhalte mit HTML-5-Technologien bereitzustellen.

Da wäre es dann auch ein Leichtes, Features der Smartphones wie die Standortbestimmung per GPS oder GSM-Netz oder auch kommende Sicherheitsfunktionen (wie die Google Device Policy Apps, [6]) zu integrieren und so dafür zu sorgen, dass der Zugang zur Firmen-IT nur unter Bedingungen erfolgt (“Auf dem Firmengelände”, “Per UMTS eingewählt”, “Passort/PIN ist sicher”). Als Minimalvoraussetzung für eine derartige App nennen Security-Experten:

• Lokales Speichern von Credentials unterbinden
• Keinen Cache auf dem Smartphone/Tablet nutzen
• Die Authentisierung um One-time-Passwörter mit separaten Smartcards oder Tokens erweitern, nicht per Software auf dem mobilen Gerät.

Der Zugriff auf die Unternehmensanwendungen ließe sich dann exklusiv auf die Smartphone-App beschränken (etwa mit Client-side-Zertifikaten), alternative Browser blieben aus Sicherheitsgründen außen vor. Das gleiche Konzept könnte für Standardprotokolle des Remote-Desktops wie VNC und RDP oder für den Verbindungsaufbau via VPN-Software dienen – in der speziell angepassten App.

Simultanübersetzer

Fürs Erste könnten auch Tools helfen, die wie Broadway [7], Guacamole [8] oder Free RDP Webconnect (Abbildung 3, [9]) heutige Desktop-Umgebungen on the Fly in HTML 5 konvertieren. Doch selbst das ist, glaubt man Analysten wichtiger Beratungsunternehmen, nur die Übergangsphase. Admins und IT-Leiter müssten sich darauf einstellen, dass Desktop-Software mittelfristig Webapplikationen weichen wird, auch und gerade wegen unumkehrbarer Trends wie BYOD.

Abbildung 3: Free RDP Webconnect setzt die Bildschirmdarstellung eines Windows-Terminalservers live in HTML 5 um. Als Client reicht ein Browser.

Als Beispiel nennen sie dafür immer wieder die Stadt München, sie mache das vor und erwarte seit 2008 “Plattformunabhängigkeit bei allen Bewerbern in Software-Ausschreibungen” – übersetzt bedeutet das nichts weniger als “Browser-basiert, bitte!”

Kleinen Unternehmen, die zusätzlich Fachanwendungen oder andere ältere Programme auf dem Desktop einsetzen, bereitet das jedoch Probleme. Umso mehr, wenn sie die Programme auch auf absehbare Zeit nicht durch Browserfrontends ersetzen können, dennoch aber Smartphones oder Tablets einsetzen wollen. Lässt sich der Vendor-Lock-in nicht umgehen, bleibt nur der Griff zu den auf Touchscreens unhandlichen Remote-Desktop-Apps übrig.

Händewaschen hilft!

Peter Klee, IT Security Consultant bei IBM, rät IT-Strategen dementsprechend beim Design ihres BYOD-Konzepts die Augen für einfache Lösungen offen zu halten und Wert auf nachhaltige Investitionen zu legen.

Es gäbe einfache Konzepte, die dauerhafteren Erfolg brächten als der Einsatz von viel und teurer Technologie. Er fordert mehr Weitblick von den Admins: “Denken Sie mal an die Krankenhauskeime. All die Versuche, das mit medizinisch-pharmazeutischen Mitteln in den Griff zu kriegen, haben nicht funktioniert. Und was hilft am besten? Wenn sich die Ärzte und das Personal häufiger die Hände waschen!”

Wichtigster Ansatz dabei sei für viele Experten die “Webifizierung” der Business-Anwendungen sowie die Absicherung des Zugriffswegs. Klee spricht vom “A und O der ganzen BYOD-Debatte: Angesichts der Flut von mobilen Geräten und der schnellen Innovationszyklen müssen wir heute davon ausgehen, dass der HTML-5-fähige Browser der kleinste gemeinsame Nenner ist. Der Trend zu BYOD scheint nicht abwendbar”.

Mit dem Browser als Plattform scheinen Unternehmen auch in einigen Jahren noch ihre Mitarbeiter mit allen Anwendungen versorgen zu können, die sie für die Arbeit brauchen – egal was für vermeintlich smarte Geräte die dann ins Unternehmen schleppen.