Tipps zum Umgang mit BYOD, Teil 2 Authentifizierung beim Remote-Zugriff per Smartphone
Erlaubt ein Unternehmen private Mobilgeräte im Netzwerk, dann ist die Begeisterung der Mitarbeiter in der Regel groß. Doch selbst technisch einfach umsetzbare Dinge wie der E-Mail-Empfang auf dem Smartphone sind aus Compliance-Sicht risikobehaftet und komplex.
Anbieter zum Thema

Der Empfang geschäftlicher E-Mails auf Privatgeräten kann sich zu einer ernsthaften Bedrohung für die Datensicherheit auswachsen; und natürlich stehen letztlich auch immer private Daten auf dem Spiel. Was könnte ein Angreifer damit anstellen? Die Wahrscheinlichkeit ist groß, dass er Adresse, Geburtsdatum und Informationen ausspionieren kann, mit denen er Sicherheitsfragen beantworten könnten.
Vielleicht stößt er sogar auf Passwörter, die im Klartext von Kollegen oder schlecht abgesicherte Webseiten per E-Mail versendet wurden (nebenbei bemerkt: Ihren eigenen Posteingang nach solchen Daten zu durchsuchen, kann eine interessante Übung sein). Mit all diesen Daten bewaffnet, kann ein gewiefter Eindringling eine ziemlich überzeugende Social Engineering-Attacke starten.
Es ist ein kleines Trostpflaster, dass sich der Angreifer auch bei einem größeren Problem mit dem E-Mail-Server zunächst einen Zugriff auf einem Posteingang verschaffen muss, um Schlimmeres anzurichten. Anschließende Angriffe hängen nicht selten vom persönlichen Glück ab, weil der Angreifer immer Gefahr läuft, in die Falle zu tappen.
Mobiles Arbeiten mag für IT-Angestellte wichtig sein – es ist aber weitaus geschäftskritischer, Kundendaten vor der Weltöffentlichkeit zu bewahren. Ein durchgesickertes oder gehacktes Passwort könnte genügen, damit sich ein Angreifer einloggen, den Export-Knopf drücken und sich mit einem Großteil der vertraulichen Daten aus dem Staub machen kann.
Die meisten der heute verfügbaren Sicherheitslösungen konzentrieren sich darauf, Geräte zu schützen. Aber Maßnahmen, die zu jeder Zeit und an jedem Ort einen Zugriff auf Geschäftsanwendungen einräumen, können zusätzliche Probleme auf den Plan rufen.
Ein gutes Beispiel hierfür sind Standard-Apps in der Cloud. Für mobile Benutzer ist es einfach, sich damit zu verbinden: Einfach die App downloaden und einloggen. Das Unternehmen muss keine eigenen, remote erreichbaren Systeme mit komplizierten statischen IPs, Domains, SSL-Zertifikaten, virtuellen Netzwerken usw. hosten.
Sicherheitsaspekte bei Cloud-Anwendungen
Das SaaS-Modell hat auf den ersten Blick sein Versprechen von maximaler Benutzerfreundlichkeit eingelöst. Schaut man aber genauer hin, entdeckt man schnell Probleme. Wenn jeder x-beliebige User eine App downloaden und sich anmelden kann, was hält dann einen Angreifer davon ab?
Benutzer über den richtigen Umgang mit Passwörtern aufzuklären, ist vor diesem Hintergrund natürlich wichtig. Bei der Absicherung von Systemen aber allein auf die Gewissenhaftigkeit der Benutzer zu vertrauen, wäre grob fahrlässig. Denn hinter den Kulissen kommunizieren die meisten Anwendungen über das althergebrachte HTTP.
Für einen durchschnittlich begabten Cyberkriminellen ist es ein Leichtes, die zugrundeliegenden Webdienste, mit der die App kommuniziert, auszuspionieren. Sobald er herausgefunden hat, wie Benutzerlogins verarbeitet werden, kann er ohne großen Aufwand ein Skript schreiben, das Passwörter für ihn errät.
Schon seit Jahren ist klar, dass Passwörter allein nicht der Schlüssel zu mehr Sicherheit sind – deshalb haben wir VPNs mit Zertifikaten, Smartcards und Schlüsselanhänger erfunden, die den Zugriff sicherer gestalten sollen. Aber im Eifer, neue Geräte auf den Markt zu bringen, vernachlässigen wir gerne mal die Grundlagen. Wie also können wir es Angreifern schwieriger machen, ohne die Benutzer zu beeinträchtigen? Leider ist das nicht einfach, aber es gibt einige Ideen.
Den Anwendungsanbieter um Hilfe bitten
Die einfachste Methode besteht darin, zu prüfen, ob die Anwendung selbst für einen größeren Zugriffsschutz sorgen kann. Je größer und sicherheitsbedachter der Anbieter, desto höher ist die Wahrscheinlichkeit, dass er bei der Implementierung eines zusätzlichen Authentifizierungsfaktors behilflich sein kann.
Bei diesen zusätzlichen Faktoren handelt es sich meist um eine E-Mail-Bestätigung für unbekannte Geräte, SMS-Codes bzw. separate Apps, die Authentifizierungscodes generieren. Solche Methoden sind zwar besser als gar nichts, haben jedoch nach wie vor ihre Schwachstellen.
Unterschiedliche Benutzernamen und Passwörter für verschiedene Accounts zu haben, ist schon verwirrend genug. Wenn die eine App einen speziellen SMS-Code, die nächste eine E-Mail-Bestätigung und die Dritte eine Softtoken-App benötigt, kann sich der Helpdesk auf eine Flut von Anfragen gefasst machen. Und natürlich ist eine E-Mail-Bestätigung ziemlich zwecklos, wenn die E-Mails nicht vernünftig gesichert sind.
Remote-Terminal-Zugriff
Remote-Terminal-Technologien haben sich gemausert und können mittlerweile einen unkomplizierten, mobilen Zugriff auf bewerkstelligen. Sie haben den großen Vorteil, dass sie mit ziemlicher Wahrscheinlichkeit mit bestehenden Apps funktionieren – zumindest, wenn diese nicht zu grafikintensiv sind.
Die Absicherung ist ebenfalls verhältnismäßig einfach, schließlich bleiben die Daten immer auf dem Server. Man muss sich also nicht zu viele Gedanken über Datenverlust auf verloren gegangenen oder gestohlenen Geräten machen.
Die meisten Lösungen unterstützen eine Vielzahl zweistufiger Authentifizierungsformen. Die Anmeldemethode für alle Anwendungen ist die gleiche und sollte demzufolge nicht allzu viel Verwirrung stiften. Aber natürlich gibt es einen Haken: In vielen Fällen leidet die Benutzerfreundlichkeit. Das Ganze wird nie so professionell wie eine native App mit all ihren originellen Benachrichtigungsfeatures und der nahtlosen Integration von Handykameras, Adressbüchern usw. sein.
Eine klobige Anwendung ist und bleibt eine klobige Anwendung. Sie über einen Hochglanz-Touchscreen-Gerät einsehbar zu machen, ändert daran rein gar nichts – insbesondere dann, wenn die App für Maus, Tastatur und einen großen Bildschirm entwickelt wurde.
Trotzdem: Wenn ein Unternehmen bereit ist, bei der Benutzerfreundlichkeit Kompromisse einzugehen und nicht umhinkommt, einen Remote-Zugriff auf besonders sensible Anwendungen einzuräumen, ist das wahrscheinlich die beste Variante. Eine gute Authentifizierung und Verschlüsselung sollte allerdings gewährleistet sein.
Verbindung via Virtual Private Network
Eine weitere Option sind Virtual Private Networks (VPNs). Verfügt ein bestehendes Firmen-VPN über eine sichere Authentifizierung verfügt, ist es durchaus sinnvoll, den gesamten Datenverkehr über das VPN zu senden. Erstens bilden sie ein zentrales Nadelöhr für Webscans, IDS usw. Zweitens kommen Verbindungen aus dem statischen IP-Bereich – auch dann, wenn die Anwendung ausgelagert wird.
Zusätzlich von Vorteil: weil VPNs wohl die älteste Form der Netzwerkauthentifizierung sind, wird eine Zugriffsbeschränkung mit IP ACLs so ziemlich überall unterstützt. VPNs sind demzufolge eine zuverlässige, wenn auch schwerfällige Form der zweistufigen Authentifizierung.
Leider stößt der VPN-Ansatz bei den Benutzern wahrscheinlich nicht auf besondere Begeisterung. Denn in den meisten Fällen müssen Benutzer das VPN manuell starten und sich zunächst mehr oder weniger aufwendig authentifizieren, um sich für den Zugriff auf eine Anwendung dann erneut authentifizieren zu müssen.
Wenn wir davon ausgehen, dass Sie eine gewisse Passwortlänge vorschreiben, kann die wiederholte Eingabe auf einem Smartphone schnell lästig werden. Bei unzuverlässigen Verbindungen wird das Ganze noch unerfreulicher. Insbesondere iPhones scheinen sich bei der Aufrechterhaltung von VPN-Verbindungen nicht besonders geschickt anzustellen, so dass ständig Verbindungswiederherstellungen erforderlich sind.
x509-Zertifikate
Die letzte Option, die der Autor hier behandeln möchte, sind x509-Zertifikate. Bei Zertifikatauthentifizierungen handelt es sich um einen gängigen (wenn auch oft missverstandenen) Standard, der von den meisten Smartphone-Webbrowsern und Webservern gut unterstützt wird.
Eine wichtige Einschränkung: Im Gegensatz zu VPNs und Remote-Terminal-Clients ist diese Technologie nicht transparent zur Anwendung. Sie muss vom Client oder dem Server unterstützt werden. Diese Einschränkung muss jedoch kein Ausschlusskriterium sein.
Zunächst einmal handelt es sich bei einigen mobilen Apps wirklich nur um Web-Apps, die auf den dem System zugrunde liegenden Browser vertrauen. Wenn dies der Fall ist, unterstützt die App vermutlich Client-Zertifikate, ohne dass der Anbieter der App hierüber Bescheid weiß. Wie bereits erwähnt, wird die Authentifizierung per x509-Client-Zertifikat oft missverstanden.
Zweitens muss man nicht alle Webserver direkt mit Client-Zertifikatsauthentifizierung konfigurieren. Es gibt einige sehr nützliche, unterstützende Technologien. Bei internen Systemen kann ein HTTP-Reverseproxy am Gateway zur Abwicklung konfiguriert werden. So lassen sich bestimmte Anwendungen extern verfügbar machen, ohne die interne Konfiguration zu ändern.
Der Schutz von extern gehosteten Systemen wird wahrscheinlich am besten mit einer Verbundauthentifizierung erreicht. Mit Technologien wie OAuth und SAML behalten Sie die zentrale Kontrolle über die Authentifizierung in einer verteilten Architektur.
Es lohnt, sich mit den Funktionsmechanismen der Verbundauthentifizierung auseinanderzusetzen, weil diese schnell zum Eckpfeiler der unternehmensseitigen Identitätsverwaltung werden. Ganz einfach formuliert erlaubt dieses Verfahren dem „ Identitätsanbieter“, einen signierten Token auszugeben, der beispielsweise sagt: „Ich, Sophos, versichere, dass es sich bei dieser Person um Ross handelt.“
Der Client überträgt diesen Token an den Serviceanbieter, d.h. die Webanwendung. Der Serviceanbieter prüft, ob der Token tatsächlich von Sophos ausgegeben wurde (über PKI), und erteilt Zugriff, wenn ross@sophos befugt ist, auf die Anwendung zuzugreifen.
Die Anwender zufriedenstellen
Der Trick für eine erfolgreiche zweistufige Authentifizierung in einer verbundenen Umgebung besteht darin, den Benutzer vor Ausgabe des Tokens hinreichend zu authentifizieren. Im Klartext bedeutet das: Zertifikat und Passwort, um auf den Verbunddienst zugreifen zu können.
Gelingt das, dann ist das Unternehmen ziemlich nah dran, alle zufrieden zu stellen. Denn die Benutzerfreundlichkeit ist hoch. Solange sich das Zertifikat auf dem Gerät befindet, muss das Passwort nur einmal eingegeben werden. Bei richtiger Konfiguration muss der Benutzer nur die gewünschte Webseite besuchen oder eine App aufrufen. Er muss nicht daran denken, erst mal ein VPN zu starten.
Die Anwender erwartet ein einheitlicher Vorgang, weil alle Dienste das gleiche Authentifizierungs-Gateway verwenden – intern und extern. Kontinuität kann auch die Sicherheit erhöhen. Wenn die Benutzer daran gewöhnt sind, sich immer über das gleiche System anzumelden, fallen sie mit geringerer Wahrscheinlichkeit auf eine Phishing-Seite herein.
Leider ist man vor Zertifikatdiebstahl nie gefeit. Eine Geräteverschlüsselung kann helfen – aber um das Ganze wirklich sicher zu machen, sollte das Zertifikat in einem TPM (Trusted Platform Module) gespeichert werden. So kann selbst Schadsoftware nicht den privaten Schlüssel stehlen. Allerdings wird TPM nur sehr sporadisch unterstützt. Letztlich ist es aber trotzdem schwieriger, ein Gerät zu manipulieren und ein Zertifikat zu stehlen, als ein schwaches Passwort zu erraten.
Fazit
Hinsichtlich der Remote-Zugriffe bieten Smartphones gegenüber dem PC einige sicherheitstechnische Verbesserungen. Sicheres Sandboxing, Codesignaturen und eine Reihe weiterer vom Betriebssystem durchgesetzter Sicherheitsbegrenzungen machen viele Angriffe auf diese Plattformen weit schwieriger, als Angriffe auf Client-Rechner.
Das ist ein überzeugender Vorteil, verlagert den Fokus jedoch zurück auf die Dienste. Die bösen Buben suchen sich das schwächste Glied in der Kette. Und das ist nicht immer der Client.
Über den Autor
Ross McKerchar ist IT Network & Security Manager bei Sophos.
(ID:42237442)