Mit der als Mobile Application Management (MAM) bezeichneten Technik lassen sich Enterprise-Mobility-Management-Capabilities (EMM-Fähigkeiten) nicht auf ein Gerät als Ganzes, sondern auf einzelne Apps oder Gruppen von Apps anwenden. Historisch gesehen kam es zur Entwicklung von MAM-Produkten, um den Mängeln von Mobile Device Management (MDM) bei der Erfüllung von Anforderungen im Bereich Bring-your-own-device zu begegnen.

Anfänglich war auf allen mobilen Plattformen das Absichern von Apps nur durch die Verwaltung des gesamten Geräts inklusive dessen kompletter Löschung möglich. Dies sorgt bis heute für eine geringe Akzeptanz bei den Mitarbeitern. Aber auch Partner waren ausgeschlossen. Standen ihre Devices unter der Verwaltung ihres eigenen MDM, ließen sich keine abgesicherten Apps unter den Vorgaben anderer Firmen ausrollen und betreiben. Die einfache, aber abgesicherte Versorgung von Kunden, Partnern oder anderen Anwendern mit Daten wie E-Mail, Kontakte und Kalender brachte so große Herausforderungen mit sich.

Um hier ein technisches Werkzeug zu bieten, das die Anforderungen des Unternehmens an Datenschutz und -sicherheit alleinig auf App-Ebene durchsetzen kann, wurde das Mobile Application Management erfunden. Mithilfe von MAM konfiguriert der Administrator nicht das Gerät, sondern legt vielmehr Richtlinien auf der Anwendungsebene fest. Zu den häufigsten Richtlinien in diesem Umfeld zählen das

- Erzwingen einer PIN-Richtlinie.

- Überprüfen der Geräteintegrität und

-konformität (etwa Routing / Jailbreak-Detection).

- Steuern des Umgangs mit Unternehmensdaten, zum Beispiel Öffnen bestimmter URL-Adressen nur in einem MAM-Browser.

- Konfigurieren von Einschränkungen für die Zwischenablage.

- Erzwingen der Verschlüsselung von gespeicherten Daten (auf iOS zum Beispiel AES-256 und auf Android OpenSSL-AES-128).

- Erzwingen einer verschlüsselten Datenkommunikation (etwa TLS 1.3).

- Remote-Zurücksetzen von sämtlichen Unternehmensdaten.

- Deaktivieren einer App.

Auf diese Weise ermöglichen MAM-Techniken, eine App und damit die darin enthaltenen Daten auf nahezu jedem Gerät eines Unternehmens zu verwalten und zu schützen. Auch die sichere Datenfreigabe zwischen MAM-Apps und die Abschottung der Daten von beziehungsweise zu privaten Apps sind möglich.

Dabei sind MAM-Anwendungen trotzdem auch auf per Mobile Device Management verwalteten Geräten nutzbar. Hier bietet die Konfiguration von App-Einstellungen einen enormen Akzeptanzvorteil gegenüber den Mitarbeitern und reduziert die Fehleranfälligkeit und somit das Supportaufkommen. IT-Verantwortliche können Apps so mit Serveradressen, Authentifizierungsvorgaben und Single-Sign-on für Backend-Ressourcen, Benutzernamen, anpassbares Branding und vielem mehr vorkonfigurieren – der Anwender muss dies nicht mehr selbst tun.

Die MAM-Technologie bringt daher dort Flexibilität, wo sie auch benötigt wird. Je nachdem, ob die Endgeräte per Mobile Device Management verwaltet oder nicht verwaltetet sind, gibt es jedoch einige Besonderheiten zu beachten.

Diese Herangehensweise stellt ein Maximum an Privatsphäre für den Anwender dar und erlaubt Unternehmen zugleich, ihre Daten und die Art, wie mit ihnen interagiert wird, zu schützen.

Kommt Mobile Application Management auf einem nicht per MDM verwalteten Endgerät zum Einsatz, ist auch von einem App-Level-MAM die Rede. Diese MAM-Apps stammen meistens von EMM-Anbietern. Hier ist beispielsweise der E-Mail-Client Outlook von Microsoft zu erwähnen. Diese App lässt sich auf nicht verwalteten Endgeräten installieren und trotzdem über das MDM-System Microsoft Intune verwalten, steuern und konfigurieren. Es gibt aber auch Nischenlösungen wie etwa SecureContact X [1] für das datenschutzkonforme Anbinden von Konzernkontakten, etwa zur Rufnummernauflösung bei eingehenden Anrufen. Derartige Produkte bringen eine eigene Steuerungskomponente mit, die auf die einzelne App speziell abgestimmt ist.

Egal für welches Werkzeug Sie sich hier entscheiden, alle greifen auf Backend-Systeme zu, um Konfigurationen zu verwalten und zu verteilen. Bei EMM-Herstellern sind es die MDM-Systeme, bei freien Produkten eigene Cloudangebote. Viele EMM-Anbieter stellen aber auch Software Development Kits (SDKs) zur Verfügung. Damit können App-Entwickler ihre Anwendungen entsprechend anpassen, um diese für Unternehmen interessant zu machen.

Der große Vorteil dieser Herangehensweise ist, dass die zugrundeliegenden Sicherheits- und Verwaltungsfunktionen direkt in der jeweiligen App integriert sind. Gerade auf Android-Geräten spielt diese Technik einen weiteren, nicht zu verachtenden Vorteil aus, indem sie die je nach Gerät unterschiedliche Ausprägung von Android beherrschbar macht. Sie können diesen Weg theoretisch auch auf Geräten gehen, die sich laut MDM-Regeln nicht mehr im Unternehmen verwalten lassen.

Aber wo viel Licht ist, ist auch viel Schatten und so bietet das Arbeiten mit nicht verwalteten Geräten auch einige Nachteile. Einer ist die Beschränkung auf Apps. Als Administrator können Sie das Gerät weder patchen noch einen Zugriffsschutz auf Device-Ebene hinterlegen noch Konfigurationen für die VPN-Kommunikation vornehmen. Nicht zuletzt kann der Admin den Rollout einer App nicht automatisieren, genau wie bei einem Software-Update muss der Anwender selbst aktiv werden. Zudem dauert es länger, maßgeschneiderte Apps zu erstellen. Softwarehersteller müssen ein eigenes oder das vom EMM-Anbieter angebotene SDK sehr ausführlich mit neuen Betriebssystemversionen testen, damit es nicht zu unvorhergesehenen Ausfällen kommt.

Die integrierten Frameworks der Android- und iOS-Systeme bieten mittlerweile eigenständig die Fähigkeit, kompatiblen Apps eine MAM-Konfiguration mitzugeben. Die hier implementierten Schnittstellen stehen aber nur auf per Mobile Device Management verwalteten Endgeräten zur Verfügung. Die AppConfig-Community [2] wird von branchenführenden EMM-Anbietern gesponsert und hat sich zur Aufgabe gemacht, Tools und Best Practices rund um die nativen Fähigkeiten mobiler Betriebssysteme im MAM-Umfeld aufzuzeigen.

Die Anforderungen an die mobilen Betriebssysteme stellen in der Praxis nur geringe Hürden dar. So reicht für Apple-Devices ein Gerät mit iOS 7 für das Einschreiben und Verwalten an/mit einem MDM-System. Für Android müssen es Mobilgeräte mit mindestens Version 5.0 sein.

Ob eine App für die API der Betriebssysteme entwickelt wurde, ist leider nicht immer einsehbar. Hier helfen Rückfragen beim Hersteller. Aber auch ein Blick in die Informationen der EMM-Anbieter kann eine Recherche unterstützen. So bietet zum Beispiel Jamf unter [3] ein Interface, das die Konfigurationsoptionen von Apps anzeigt, die MAM unterstützten (Bild 2). Aber auch EMM-Hersteller wie MobileIron bieten mithilfe des MarketPlace [4] entsprechende Hinweise.

Ein klarer Vorteil dieses Vorgehens ist es, dass die MAM-Funktionen für alle (kompatiblen) Apps zur Verfügung stehen. Ein Mischbetrieb von Apps verschiedenster Hersteller mit einem MDM-System ist so problemfrei möglich. Zusätzlich können Administratoren allgemeine (Device Channel) und anwenderspezifische (User Channel) Richtlinien auf einem Gerät durchsetzen. Die Funktionen aller Apps, egal ob MAM-kompatibel oder nicht, bleiben so konsistent.

Die Konfiguration von Gerät und Apps erfolgt bei den EMM-Anbietern auch über eine einheitliche Oberfläche. Dies erleichtert nicht nur die Konfiguration, sondern auch das Reporten und die Prüfung auf Compliance.

Das Einsetzen von MAM-Apps auf verwalteten Geräten bringt dem Administrator entscheidende Vorteile gegenüber einem nur per Mobile Device Management verwalteten Betrieb. Das liegt daran, dass die Konfiguration auf einem rein verwalteten Endgerät beschränkt ist. Das Abschalten der Zwischenablage ist beispielsweise per MDM nicht möglich. In MAM-Apps ist dies jedoch übliche Praxis. Daraus ergibt sich, dass ein Mischbetrieb (Bild 3) durchaus hilfreich sein kann.

Der Nachteil von MAM-Werkzeugen, die auf eine Verzahnung mit MDM angewiesen sind: Die IT muss die Devices zwingend am MDM-System der Firma registrieren, was die Privatsphäre der Nutzer beeinträchtigt und den Einsatz auf Geräten von Dienstleistern meist technisch unmöglich macht.

Diverse MDM-Hersteller wie Microsoft (Intune), VMware (Airwatch), MobileIron, Blackberry und andere bieten Werkzeuge an, um durch Patches fehlende Sicherheitsfunktionen in bestehenden Apps in deren eigener Hülle nachzurüsten. Hierbei handelt es sich nicht um eine App-Entwicklung unter MAM-Gesichtspunkten, bei der EMM-SDKs bei der App-Erstellung die entsprechenden MAM-Funktionalitäten mitbringen. Es geht hier vielmehr um den Versuch, einer App, die bereits voll entwickelt ist, im Nachhinein eine Logik einzuimpfen, die Sicherheit und Konfigurierbarkeit mitbringen soll.

App-Wrapping setzt dabei allerdings auf Methoden, mit denen sich Apps auch angreifen und manipulieren lassen. Dies hat zur Folge, dass derart veränderte Apps bei zukünftigen Updates der mobilen Betriebssysteme nicht mehr funktionieren könnten. Aus unserer Sicht ist ein derartig implementierter Schutz allenfalls oberflächlich und temporär. Zwar werden API-Aufrufe abgefangen, aber Angriffe von außen nicht wirkungsvoll unterbunden. Gerade unsicher entwickelter Java-Code im Android-Umfeld ist für einen Angreifer beispielsweise einsehbar, da Themen wie Obfuscation (Verschleierung) hier keinerlei Anwendung finden.

So einfach, wie EMM-Anbieter den Wrapping-Prozess auch gestalten, so leicht scheint Wrappig sich bei einigen Anbietern auch wieder ausbauen zu lassen. Auf dem 34. Chaos Communication Congress zeigten Sicherheitsforscher, wie sie in wenigen Minuten die Apps namhafter Hersteller von ihren MAM-Schutzfunktionen befreiten. Auch wenn dies sicher einige Recherche im Vorhinein benötigt, ist die erfolgreiche Massendurchführung ein Zeichen für das Katz- und Mausspiel, bei dem die Sicherheit einer App stets nur von der Geduld und Sachkenntnis eines potenziellen Angreifers abhängt.

Die Welt der MAM-Techniken hat viele Facetten. Unabhängig vom technisch Möglichen spielen auch die Besitzverhältnisse der Geräte eine große Rolle. Auch die Datenschutzklassen der zu verarbeitenden Daten bringen eigene Anforderungen mit sich. So bietet es sich an, je nach Besitzverhältnis und Datenschutzklasse ein Konzept aufzusetzen, das die Mitarbeiter am besten schon vor der technischen Implementierung miteinbezieht. Nicht zuletzt kann auch die vom Unternehmen genutzte Infrastruktur zum Schutz der Daten wertvolle Techniken bereithalten. Setzen Sie beispielsweise Microsoft 365 ein, könnte Azure Information Protection eine Möglichkeit sein, Ihre Daten auch ohne MAM-Techniken zu schützen.