Mobile Geräte sicher im Business nutzen

Die schnelle Entwicklung mobiler Geräte und wechselnde Technologien zwingen IT-Leiter in den Spagat zwischen Sicherheit und Benutzerfreundlichkeit. Spezialisten-Tipps schützen vor Schäden. (Ausgabe 6+7/2013)

Einen Wildwuchs an unterschiedlichen Betriebssystemen und Software-Versionen weisen gerade Unternehmen auf, deren mobile Infrastruktur sich in der Umstellung befindet oder deren Geräte nach und nach eingeführt wurden. Die für Business-Laptops und deren Anwender als selbstverständlich angesehenen Sicherheitsforderungen werden bei Mobile Devices nicht immer genau so umgesetzt: Einerseits, weil die dafür nötigen Schnittstellen nicht immer ausreichend vorhanden sind. Andererseits schätzt der Benutzer aber auch den einfachen Zugriff auf die Daten. Sicherheitsfeatures wie Datenverschlüsselung dürfen den Anwender nicht in seinem täglichen Gebrauch stören, komplexe Passwörter sind auf einem kleinen Touchscreen nur sehr unkomfortabel einzutippen. Deshalb sollte der Administrator dem Benutzer so wenig Rechte wie möglich einräumen, da die meisten User das Mobile Device so komfortabel wie möglich, also auch so unsicher wie möglich, haben wollen.

Konfigurationsfehler vermeiden

Ein Mobile Device Management (MDM) schafft die Möglichkeit, mobile Geräte, die eigentlich für den Privatgebrauch geschaffen wurden, auch für das Unternehmen zu nutzen. Da ein MDM grundlegende Sicherheitseinstellungen einschränkt, muss es tief in das System eingreifen. Die dafür notwendigen Schnittstellen schaffen die Hersteller des jeweiligen Betriebssystems. Der Großteil der bereitgestellten Funktionen ist also nicht auf den Hersteller der Mobile-Device-Management-Lösung zurückzuführen, sondern auf das Betriebssystem selbst. Nachdem BlackBerry als reines Business-Gerät in Hinblick auf die Sicherheitseinstellungen viele Jahre die Referenz in Sachen Konfigurationsmöglichkeiten war, gewinnen Apples iOS und Googles Android in den letzten Jahren jedoch an Fahrt.
IT-Administratoren müssen einen Kompromiss zwischen Be­dienkomfort und dem hohen Schutzbedarf der Daten finden. Ziel eines MDM sollte es sein, die Hürde für einen Angreifer auf mindestens dieselbe Höhe zu setzen wie beispielsweise für ein Notebook. Dies macht durchaus Sinn in Anbetracht dessen, dass Mobile Devices einem viel höheren Gefahrenpotential ausgesetzt sind, insbesondere da sie als Statusobjekt angesehen werden können.
Um die auf dem Mobile Device gespeicherten Daten vor nicht autorisiertem Zugriff zu schützen, lassen sich verschiedene Sicherheitsmaßnahmen treffen. Eine davon ist der Passcode, der zum Entsperren des Geräts eingegeben werden muss. Diese erste Hürde stellt Benutzer und Administratoren vor folgendes Problem: Der Anwender will den schnellstmöglichen Zugriff auf seine Daten, der Administrator fordert jedoch die Umsetzung der unternehmensweiten Passwortrichtlinie.
Hier bieten Mobile-Device-Management-Lösungen die Möglichkeit, das Endgerät so weit einzuschränken, dass ein Benutzer gar nicht erst die Möglichkeit hat, einen kapitalen Fehler in der Konfiguration vorzunehmen und ein kurzes Trivialpasswort, wie 1234 oder 8520 (ein Blick auf den Ziffernblock zeigt, weshalb dieser Passcode häufig verwendet wird), zu wählen.
Diese Maßnahmen schränken die Nutzerrechte jedes Einzelnen zu einem gewissen Grad ein und sorgen natürlich auch dafür, dass die private Nutzung beschnitten werden kann. Somit können Nutzer IT-Sicherheit negativ wahrnehmen.
Wegen der in Frage stellbaren Sicherheit von Android Sperrmustern ist eine Verwendung der Muster bei aktivierter Verschlüsselung nicht möglich. Intern werden Sperrmuster als Zahlen-Kombinationen gespeichert. Da Zahlen nur einfach vorkommen dürfen und nicht alle Kombinationen möglich sind, gibt es nur unter 400 000 Möglichkeiten. Die Repräsentation des Sperrmusters wird auf dem Gerät in Form eines einfachen Hash-Werts abgelegt. Ein Angreifer mit Zugriff auf das Dateisystem, ausreichendem Know-how und Ressourcen könnte so in kurzer Zeit alle Kombinationen durchprobieren, um Zugriff auf die Daten zu bekommen.
Ein als mindestens genauso störend angesehener Punkt ist die Zeitspanne, nach welcher sich ein unbenutztes Mobile Device selbst sperrt. Aus Bequemlichkeit wird dieser Wert oft auf mehrere Minuten gestellt, meist mit der Begründung, dass dies für Präsentationen benötigt wird. Ein Setzen der Grace Period auf wenige Minuten erhöht die Sicherheit von Mobile Devices signifikant, da die meisten Angriffe nur auf einem entsperrten Gerät erfolgen können. Die Härtung eines Mobile Device erfolgt auf mehreren Kanälen: Die Kommunikation, die auch in nicht vertrauenswürdigen Umgebungen erfolgen muss, darf ausschließlich verschlüsselt erfolgen. Ein VPN-Tunnel in das unternehmenseigene Netzwerk mit einem fest eingetragenen Proxy-Server, welcher die Content-Filterung übernimmt, hat sich als bewährtes Mittel etabliert. Durch die Verwendung eines On-Demand-Proxy kann der Akkuverbrauch sogar in einem annehmbaren Rahmen gehalten werden.
Angriffe auf Mobile Devices über das Internet beziehungsweise die Netzwerkschnittstellen sind bei ordnungsgemäßer Benutzung nahezu zu vernachlässigen. In Deutschland sorgen die Mobilfunkprovider durch Network Address Translation (NAT) dafür, dass auf Mobile Devices nicht direkt über das Internet zugegriffen werden kann. Da Mobile Devices von sich aus keine Dienste über das Netzwerk bereitstellen müssen, ist die Anzahl an offenen Ports, über die sie erreichbar sind, stark begrenzt. Einzig die sogenannten Man-in-the-Middle-Angriffe, bei denen ein Angreifer den Datenverkehr über seinen Angriffscomputer leitet und modifizieren kann, sind in öffentlichen WLANs realistisch.
Zu guter Letzt dürfen die auf dem Mobile Device abgelegten Daten für einen Angreifer mit physischem Zugriff nicht extrahierbar sein. Einige Mobile-Device-Lösungen bieten als Zusatzdienst eigene Apps, die die darin abgelegten Daten gesondert verschlüsseln. Die Hürde, welche ein Angreifer durch den Einsatz einer solchen Kapsellösung zu überwinden hat, wird deutlich erhöht, da zwei Verschlüsselungen entschlüsselt werden müssen. Sollte die Systemsicherheit beispielsweise durch einen Boot-Level-Exploit, der Zugriff auf das Gerät auf Systemebene ermöglicht, gefährdet sein, verhindert eine Kapsellösung einen Abfluss der Daten.

Eingeschränkter Zugriff auf App-Stores erhöht die Sicherheit
Um einen Abfluss von Unternehmensdaten wie Kontakte und Adressen zu erschweren, können Administratoren die Verwendung von App-Stores einschränken. Dabei werden mehrere Ansätze verfolgt, die verschiedenen organisatorischen Aufwand erfordern:
• Komplette Sperrung des App-Store:
Ausgewählte, freigegebene Apps werden über  das MDM direkt auf das Mobile Device geladen. Dem Nutzer kann die Möglichkeit  eingeräumt werden, die App zu löschen. Je nach MDM-Lösung kann auch eine spezielle Software-Version einer App gefordert werden, beispielsweise für  Kompatibilitätsanforderungen. Durch die häufigen Updates der meisten Apps kann es zu nicht zu vernachlässigendem organisatorischen Aufwand  kommen, wenn die Apps mittels des Push-Dienstes aktuell gehalten werden sollen. Bei korrekter Administration kann durch die Sperrung des App-Store das höchste Sicherheitsniveau erreicht werden.
• White-Listing von Apps:
Ausgewählte Apps dürfen über den App-Store bezogen werden. Für die Aktualisierung der App auf die neuste Version ist der Benutzer zuständig. Dieser Ansatz bietet ebenfalls ein vergleichsweise hohes Sicherheitsniveau. Da der Anwender aber die Möglichkeit der Installation von Apps über den App-Store wahrnimmt, können zahlreiche Service-Anfragen nach neuen Apps von Benutzern auftreten.
• Black-Listing von Apps:
Apps, welche auf Unternehmensgeräten keine „Daseinsberechtigung“ haben, werden nicht zugelassen. Der Benutzer hat ansonsten  freie Handhabe bei der Installation von Apps. Da Android und iOS jeweils mehr als 700 000 Apps in ihren Stores bereitstellen, gibt es für die meisten  Bedürfnisse zahlreiche Alternativen, welche eventuell ähnliche Sicherheitsrisiken bergen, wie die auf der Black-List stehenden Apps. Eine durch weniger Benutzer geringer verbreitete App und aus diesem Grund auch weniger getestete App hat potentiell ein geringeres Sicherheitsniveau als eine kommerzielle App mit hoher Verbreitung. Deshalb sollte von einem Black-List-Ansatz abgesehen werden, da er unter Umständen ein größeres Sicherheitsrisiko birgt, als wenn gar keine Einschränkungen forciert werden.

Sicherheitsrisiken umfassen die gesamte IT-Infrastruktur

Nicht nur das Mobile Device selbst kann Ziel von Angriffen werden, die gesamte Infrastruktur ist ebenso betroffen: Die Kommunikation mit dem MDM-Server und dem Mobile Device erfolgt über das Internet. Da der MDM-Server auch Zugriff auf Unternehmensdaten haben muss, befindet er sich entweder im Rechenzentrum des Unternehmens oder wird als Cloud-Lösung bereitgestellt. In beiden Fällen befinden sich jedoch unternehmenskritische Daten auf dem Server, weshalb die Absicherung und Härtung eine hohe Priorität haben sollte. Gerade wenn MDM-Hersteller ihre eigene Appliance liefern und nur durch Wartungsverträge ein aktuelles Patchlevel bereitstellen, sollte der Server regelmäßig überprüft werden. Eine Möglichkeit, einen bekannte Schwachstellen aufweisenden Dienst sicherer zu machen, ist, einen Reverse-Proxy zwischenzuschalten, der nur mit Geräten mit einem gültigen Client-Zertifikat kommuniziert.
Mit dem Einzug der Mobile Devices werden Unternehmens-WLANs eingeführt. Einerseits um Mobilfunkkosten zu sparen, andererseits, da sonst nicht überall ausreichende Konnektivität gewährleistet werden kann. Durch den Einsatz einer Mobile-Device-Management-Lösung ist es ohne großen Aufwand möglich, eine WPA2 Enterprise Authentifizierung auf Basis von Radius mit Client-Zertifikaten auf den Geräten einzurichten. Von vermeintlichen Schutzmaßnahmen wie versteckten WLANs (Hidden SSID) ist ebenso abzusehen wie von einem MAC-Adressen-Filter. Hidden SSIDs führen dazu, dass alle Geräte, welche sich jemals eingebucht haben, in regelmäßigen Abständen nach der gesuchten SSID fragen (Probe Requests). Durch die Analyse des WLAN-Verkehrs können so also Rückschlüsse auf den Benutzer gezogen werden. MAC-Filter lassen sich innerhalb weniger Sekunden umgehen, indem der Angreifer die MAC-Adresse eines angemeldeten Geräts übernimmt.
Auch wenn nur vertrauenswürdige Geräte Zugriff auf dieses Netzwerk erhalten, empfiehlt es sich nicht, eine einfache Brücke ins kabelgebundene Unternehmensnetzwerk zu schlagen. Multicast-Nachrichten und Konfigurationsdienste beider Netzwerke belasten sich unnötig gegenseitig. Ebenfalls sollten hinsichtlich der Sicherheit nur ausgewählte Dienste für Mobile Devices erreichbar sein. Um sich vor Netzwerk-basierten Angriffen zu schützen, hat sich folgender Ansatz bewährt: Auch das Firmen-WLAN dient lediglich als Zugangspunkt zum Firmen-VPN über das Internet. Mit dieser Maßnahme lässt sich organisatorischer Aufwand einsparen, ohne aus Versehen als Nebeneffekt neue Sicherheitslücken zu schaffen. Insbesondere schult es den Anwender dahingehend, dass zwischen Unternehmensnetzwerk (VPN) und anderen nicht vertrauenswürdigen Netzwerken unterschieden werden kann.
Zahlreiche Mobile-Device-Management-Lösungen bieten die Möglichkeit, über ein Virtual Private Network (VPN) Zugriff auf das interne Unternehmensnetzwerk zu erlangen. Dies schafft zwar dieselben Arbeitsbedingungen, wie mit einem Notebook erreicht werden, führt aber auch zu demselben Schaden beim Verlust. Bei richtiger Konfiguration ist es mit einem MDM möglich, einem als kompromittiert angesehenen Gerät den Zugriff auf das Unternehmensnetzwerk komplett zu verweigern, indem die Client-Zertifikate gesperrt werden. Um die auf dem Gerät abgelegten Daten zu entfernen, kann mittels Remote Wipe das komplette Gerät gelöscht werden. Dies ist durch den Einsatz einer Grundverschlüsselung durch das Löschen der Schlüssel innerhalb weniger Sekunden möglich.
Im Falle eines gezielten Angriffs, eines sogenannten Targeted Attack, führt der Versuch, das Gerät einem Remote Wipe zu unterziehen, zu keinem Erfolg. Ein vorbereiteter Angreifer kann mittels spezieller Hüllen einen Faradayschen-Käfig um das Gerät aufbauen und hat durch aus dem Käfig führende Kabel dennoch Zugriff auf das Gerät. Da nicht davon ausgegangen werden kann, dass das Gerät verlässlich gelöscht wurde, muss schon die Grundsicherheit des Geräts die Hürde für einen Angreifer sehr hoch setzen.

Guidelines sichern den Einsatz mobiler Endgeräte ab
Für Mobile Devices gibt es im Hinblick auf Data Loss Prevention mehrere Faktoren:
• Eingabe des Kennworts nur in vertrauenswürdigen Umgebungen.
Arbeiten im Zug nur mit Displayschutzfolie
• Aktives Sperren des Mobile Device, Hüllen mit Magnet-Lock
• Keine Weitergabe des Passcodes, auch nicht an Familienmitglieder
• Nutzung von WLANs ausschließlich als VPN-Zugangspunkt
• Einsatz von verschlüsselten Protokollen
• Apps: „Wenn du die Ware nicht siehst, bist du selbst die Ware“
• Keine eigenen Work-Arounds schaffen. Beispiel: Weiterleitung von
Business-Mails an Free-Mail-Provider.
• Keinen physischen Zugriff Dritter zulassen: Ladestationen vermeiden
• Surfen: Selbe Inhalte wie auf Unternehmenscomputer
• Verschiedene Dienste, verschiedene Kennwörter

Verhaltensschulungen für Anwender durchführen

Die einzig wirksame Schutzmaßnahme gegen einen solchen Angriff ist der Einsatz von Kryptographie, da auch durch Schwachstellen im Betriebssystem oder Sperrbildschirm keine Informationen extrahiert werden können. Mit Hinblick darauf unterscheiden sich Googles Android und Apples iOS grundlegend: Während bei Android nach Eingabe des Boot-Kennworts das Gerät Zugriff auf alle auf dem Gerät abgelegten Daten hat, besteht bei iOS die Möglichkeit, Daten mit einem Sicherheitsattribut zu versehen, welches diese Daten nur im angemeldeten Zustand –  nach Eingabe des Passcodes – entschlüsselt. Um den Benutzer nicht zu verwirren, verwendet Google Android dasselbe Kennwort für die Entschlüsselung der Daten wie für den Sperrbildschirm. Bezogen auf die Sicherheit ist diese unnötige Einschränkung nicht optimal, da sie den Nutzer dazu motiviert, ein möglichst kurzes Kennwort festzulegen.
Ein korrekt eingerichtetes MDM mit aktuellen Geräten, für die keine Schwachstellen öffentlich bekannt sind, kann ein hohes Sicherheitsniveau erreichen. Diese Gegebenheit führt dazu, dass nicht mehr die Mobile Devices oder die dazugehörige Infrastruktur, sondern die Benutzer angegriffen werden. Neben dem Einsatz einer Mobile-Device-Management-Lösung sollten Schulungsmaßnahmen – auch wenn sie teuer sind – in den Einführungsprozess integriert werden. Die regelmäßige Auffrischung der Verhaltensregeln trägt aktiv zum Schutz der Unternehmensdaten bei.

Mobile Betriebssysteme für den Unternehmenseinsatz

Die Zeiten, als BlackBerry der Inbegriff des Unternehmenshandys war, sind vorbei. Apple und Google liefern sich mit iOS und Android ein Wettrennen. Als Dritter ist Microsoft mit dem Windows Phone dabei. Auch wenn Android im privaten Umfeld in Bezug auf die Masse weit die Nase vorne hat, zeigt sich im Unternehmensumfeld ein anderes Bild: Apple iOS bietet durch definierte Schnittstellen die Möglichkeit, Mobile Devices zu administrieren, ohne dem Benutzer zwingend alle Features des Geräts zu verwehren. Auch wenn Google in den letzten Monaten Android signifikant weiterentwickelt hat, ist der Einsatz des nativen Mail-Clients beispielsweise für Firmendaten aufgrund nicht hinreichender Verschlüsselung noch in weiter Ferne.

Jailbreak öffnet Schwachstellen

Ein nicht zu vernachlässigender Anteil der Benutzer hat aus verschiedenen Gründen das Bedürfnis, einen sogenannten Jailbreak durchzuführen. Mit einem Jailbreak ist es möglich, aus Apples gesicherter Umgebung auszubrechen und über einen alternativen App-Store Programme zu installieren, die weder von Apple signiert, noch überprüft wurden. Applikationen, welche über den alternativen Cydia-Store installiert wurden, können auch als Dienste im Hintergrund laufen, ohne Apples Qualitätsanforderungen zu entsprechen. Des Weiteren ist es durch einen Jailbreak möglich, zahlreiche Schwachstellen auf dem Gerät zu öffnen. Ein Anwender mit nicht ausreichendem technischen Hintergrund kann so – ohne es zu merken – den Fernzugriff auf sein Gerät aktivieren oder auf dem Gerät abgelegte Daten im Netzwerk freigeben.
Natürlich ist nach der Durchführung eines Jailbreak beziehungsweise Rootings dieser sichere Zustand nicht mehr gegeben, da beispielsweise direkt auf den Arbeitsspeicher, in dem Daten im Klartext vorliegen, zugegriffen werden kann. Die Art der Feststellung, ob bei einem Mobile Device Schutzmaßnahmen umgangen wurden, ist abhängig vom Betriebssystem. Die einfachste Prüfung für den Root-Zugriff einer Applikation unter Android ist, zu prüfen, ob die Applikation Zugriff auf den Ordner /data/data hat. Nur der Benutzer root hat, auf dem auf Unix basierenden Betriebssystem, Zugriff auf diesen Ordner. Normale Applikationen haben nur Zugriff auf einen eigens für die Applikation angelegten Ordner. Die meisten Jailbreak-Erkennungen für Apples iOS hingegen überprüfen, ob der alternative App-Store Cydia installiert ist. Da es jedoch auch zahlreiche andere Möglichkeiten zur Überprüfung und deren Verhinderung gibt, liefern sich App-Entwickler und Cracker ein Wettrennen, dessen Ausgang bisher noch nicht abzusehen ist. Auch wenn einige Mobile-Device-Management-Lösungen die Hürde für einen Jailbreaker sehr hoch setzen, kann keine absolute Sicherheit versprochen werden. Da jedoch auch andere Applikationen – insbesondere aus dem Consumer-Bereich, wie mit DRM versehene Mediatheken – diese Überprüfungen durchführen, gibt es auch für die breite Masse verfügbare Gegenmaßnahmen.
Genauso wichtig wie die korrekte Erkennung eines Jailbreak für den sicheren Betrieb ist der Einrichtungsprozess: Theoretisch kann die Jailbreak-Erkennung nur verlässlich funktionieren, wenn der Zustand des nicht kompromittierten Geräts korrekt erkannt wurde. Bei Android bedeutet das beispielsweise, dass der Boot-Loader bei dem Einrichtungsprozess des MDM gesperrt sein muss. Nur so ist es möglich, keinen Vollzugriff auf die gespeicherten Daten zu erlangen, da zum Entsperren des Boot-Loader nach Googles Richtlinien alle auf dem Gerät gespeicherten Daten gelöscht werden müssen.
Weil auch Apple keine Schnittstelle zur Erkennung von Jailbreaks bereitstellt, müssen MDM-Hersteller diese Funktionalität durch eigene Apps ergänzen. Mittels Reverse Code Engineering der ausführbaren Binärdatei kann die App jedoch auch so verändert werden, dass sie einen Jailbreak nicht bemerkt. Solche Angriffe können nicht gänzlich abgewehrt werden. Eine signifikante Erschwerung ist beispielsweise die Obfuskierung des Codes, damit keine verwendeten Methodennamen extrahiert werden können. Insbesondere bei Android ist durch die auf Java basierenden Apps die Sourcecode-Analyse einer extrahierten und dekompilierten Applikation mit kostenlosen Tools, wie JD-Gui und dex2jar, möglich. Bei iOS Apps besteht zwar ebenfalls die Möglichkeit des Reverse-Code-Engineering. Da bei Objective-C jedoch nicht die Zwischenschicht einer virtuellen Maschine besteht, wie sie bei Android durch die Dalvik Virtual Machine gegeben ist, bestehen weit weniger Möglichkeiten, menschenlesbaren Code zu generieren. Insbesondere das Dekompilieren in eine Hochsprache ist nicht mehr möglich.
Um die höchst mögliche Sicherheit zu gewährleisten, sollten die Geräte von der zuständigen IT-Abteilung aktualisiert, installiert und gesichert werden. Erst ein vollständig eingerichtetes Mobile Device sollte an den Nutzer übergeben werden. Aufgrund der eben genannten Problematik empfiehlt es sich nicht, für Unternehmensdaten mit sehr hohem Schutzbedarf, private Geräte – Stichwort Bring Your Own Device (BYOD) – zu erlauben. Neben den rechtlichen Herausforderungen, welche die Handhabung von privaten Geräten mit sich bringen, sollte eine BYOD-Strategie unter Einbeziehung des Betriebsrats geplant werden. Bei BYOD sollte besonders darauf geachtet werden, welche Mobile Devices zugelassen und welche Applikationen unterstützt werden. Damit kann einerseits der organisatorische Aufwand reduziert werden, andererseits wird so eine Aufweichung der Sicherheitsrichtlinien verhindert.

Durch die Hardware bedingte Schwachstellen

In den letzten Jahren wurden einige Schwachstellen bekannt, die auf Fehler der Hardware beruhen, wie der Boot-Level-Exploit bei Apples iPad 1 oder der Root-Exploit bei einigen Samsung Mobile Devices mit Exynos-Prozessoren. Teilweise besteht keine Möglichkeit zur Behebung dieser Schwachstelle, lediglich eine Abschwächung ist möglich. Bei Apples iPad 1 können durch einen langen Passcode dennoch Daten, die via Exchange synchronisiert wurden, verlässlich geschützt werden. Mobile Devices wie Samsungs Galaxy Note 2 oder Galaxy S3 können durch einen Sicherheits-Patch, der teilweise die Kamera deaktiviert, gehärtet werden. Um Mobile Devices im Sicherheitsbereich einzusetzen empfiehlt es sich, eine überschaubare Anzahl an verschiedenen Geräten und Plattformen zu unterstützen, damit der MDM-Administrator schnell auf neu bekannt werdende Schwachstellen reagieren kann.
Gerade bei Privatgeräten, aber auch bei Firmengeräten sollte sich der Benutzer im Klaren darüber sein, welche Möglichkeiten der Fernadministration – und dementsprechend auch der Überwachung – ein MDM bietet. Neben der Funktion, einen Remote Wipe auf dem Mobile Device durchzuführen, kann es auch geortet werden. Je nach Einstellungen kann bei aktiviertem GPS und WLAN die Position auf wenige Meter genau bestimmt werden. Ein Benutzer kann bei dem Erstellen eines Bewegungsprofils lediglich durch den erhöhten Akkuverbrauch feststellen, ob der MDM-Administrator die Koordinaten des Geräts abfragt. Ebenso kann über das Internet abgefragt werden, welche Applikationen installiert wurden, anhand des Akkuverbrauchs kann die Nutzungsintensität des Geräts bestimmt werden.
Der Einsatz eines Mobile Device Management ist bei einer breiten Einführung von mobilen Endgeräten im Unternehmensumfeld sehr zu empfehlen, da somit eine Basis im Hinblick auf Sicherheit geschaffen wird. Der Verwaltungsaufwand einer Vielzahl von Geräten kann ebenfalls stark verringert werden. Durch die Schaffung von klar definierten und getesteten Prozessen können zukunftsorientierte Unternehmen einen ähnlichen Übergang von üblichen Computern zu Mobile Devices schaffen, wie es vor einigen Jahren vom Desktop-Computer zum Notebook möglich war. Philipp Buchegger/hei

Der Autor: