Technik & Architektur
Ein iPhone, vier Ebenen: Welche Regel greift?
Warum du vor der nächsten Richtlinienänderung Gerät, App, Konto und Dynamics auseinanderhalten solltest und wie du die passende Schutzgrenze findest.
Bevor du die nächste Richtlinie verschärfst oder lockerst: Bist du überhaupt an der richtigen Stelle? Auf dem iPhone kann die entscheidende Kontrolle am Gerät, an der App, am Konto oder in Dynamics liegen. Verwechselst du diese Ebenen, kannst du eine Lücke übersehen oder den falschen Arbeitsweg sperren. Die Grafik hilft dir, die zuständige Kontrolle zu finden, bevor du an ihren Einstellungen drehst.
Die Grafik lesen wir von oben nach unten: zuerst den blauen Profilkasten, dann die drei Spalten in der helltürkis hinterlegten geschäftlichen Fläche. Links daneben stehen private Apps und Konten im roten Bereich. Die folgenden Hauptabschnitte führen dich durch diese Bildbereiche. Die Flächen zeigen logische Zuordnungen, keine zusätzlichen iOS-Benutzer. Der rote Stop steht für eine gewählte Sperre im Beispiel; er entsteht nicht automatisch durch Geräteverwaltung.
Managed Profiles und MDM-Konfigurationsprofile
Ein neues iPhone soll die Firmenverbindungen kennen, ohne dass du jede Einstellung von Hand eintippst. Dafür beginnen wir ganz oben im iPhone, im blauen Kasten Managed Profiles / MDM-Konfigurationsprofile. Er enthält die vier Kacheln Konten, Zertifikate, VPN und WLAN. Damit legt die Administration fest, wie das Gerät seine geschäftlichen Verbindungen aufbaut.
Was sagen die Profile dem Betriebssystem?
Vereinfacht schickt UEM dem Betriebssystem eine Konfiguration: Dieses WLAN sollst du verwenden, so erreichst du den Mailserver, dieses Zertifikat brauchst du dafür.
Technisch stößt UEM eine Benachrichtigung an. Der MDM-Dienst auf dem iPhone holt die ausstehenden Aufträge ab, verarbeitet sie und meldet den Status zurück. Das ist die obere Ebene der Grafik. Das Profil ist dabei eine Anweisung an iOS. Es baut keinen zweiten Arbeitsplatz im Gerät.
Kommt die Firmenverbindung nicht zustande, würde ich deshalb zuerst schauen, ob die vorgesehene Konfiguration auf dem iPhone verarbeitet wurde. Ist sie noch nicht angekommen, hilft eine andere Freigaberegel für Dokumente nicht weiter. Ist sie verarbeitet, ist das ein erledigter Konfigurationsschritt, aber noch kein Beweis für eine funktionierende Verbindung.
Damit wissen wir, wie Einstellungen auf das Gerät kommen. Ob eine geschäftliche Datei an eine private App weitergegeben werden darf, müssen wir an einer anderen Stelle klären: bei der App, aus der sie kommt.
Managed Apps
Beruflich genutzt heißt noch nicht verwaltet. Wenn du das übersiehst, verlässt du dich auf Regeln, die diese Installation möglicherweise gar nicht erfassen.
Stell dir vor, deine gewohnte PDF-App soll künftig auch Firmenberichte bearbeiten. Wird sie durch die berufliche Nutzung schon zur verwalteten App?
Gehen wir unter den Profilkasten in die helltürkis hinterlegte Fläche Geschäftliche Schutzbereiche. Ihre linke Spalte heißt Managed Apps und enthält CRM und ERP. Hier wird wichtig, wie die App auf das Gerät gekommen ist.
Wie wird eine App zur Managed App?
Eine Managed App ist eine App, deren Installation unter Geräteverwaltung steht.
Das Kennzeichen setzt iOS: Das iPhone ist per MDM bei UEM angemeldet, die Administration weist die App zu, und UEM gibt dem Gerät den Installationsauftrag. Nach erfolgreicher Installation führt iOS die App als verwaltet.
Der Status beschreibt also die Zuordnung dieser Installation zur Verwaltung. Auch eine gewöhnliche App aus dem App Store kann auf diesem Weg managed werden; eine besondere „Firmenversion“ ist dafür nicht nötig.
An diesem Status hängen Regeln. Zum Beispiel lässt sich über Managed Open In steuern, ob ein Dokument aus einer verwalteten Quelle in einer nicht verwalteten App geöffnet werden darf. Wir können also bestimmte Übergänge begrenzen. Wir bekommen damit aber nicht automatisch Zugriff auf jede beliebige Funktion innerhalb der App.
Merksatz: Für einen Dokumentweg brauchen wir die Zuordnung beider Seiten: Ist die Quellapp verwaltet, und ist die Zielapp es ebenfalls? Ein Firmenlogo auf dem Bericht genügt dafür nicht.
Was passiert mit einer schon privat installierten App?
Kehren wir zu der PDF-App zurück, die schon auf dem iPhone ist. Die eine Installation hat in der hier beschriebenen iOS-Verwaltung einen Status: managed oder unmanaged. Du kannst derselben Installation hier nicht gleichzeitig beide Verwaltungszustände geben. Soll sie künftig unter UEM-Verwaltung stehen, geht es daher um die Übernahme dieser vorhandenen Installation. UEM erzeugt dabei keine zweite Appinstallation.
In UEM heißt die passende Auswahl Convert beziehungsweise Do not convert. Ob eine Übernahme möglich ist, hängt vom Enrollment ab. Apple schließt sie bei account-driven User Enrollment aus. Wir müssen also klären, ob die vorhandene App übernommen werden kann, bevor wir ihre geschäftlichen Regeln planen.
Was macht ein Android-Arbeitsprofil anders?
In einem Android-Arbeitsprofil kann dieselbe App zusätzlich zur privaten Instanz vorhanden sein. Die beiden Instanzen haben getrennte App-Daten. Du kannst also eine private und eine geschäftliche Instanz derselben App benutzen.
Das ist ein anderer Ausgangspunkt als bei der gerade beschriebenen iOS-Installation. Der Vergleich erklärt, warum wir erst die konkrete Bereitstellung klären müssen, statt von einer gewohnten Plattform auf die andere zu schließen.
Native Apps und Konten
Zwei Postfächer, ein Mail-Symbol. Wenn du nur nach der App fragst, übersiehst du genau die Unterscheidung, an der eine Freigabe hängen kann.
Die nächste Spalte rechts von Managed Apps ist der violette Kasten Native Apps / Konten. Darin siehst du Mail/Kalender und zwei Kontozeilen: geschäftlich und privat. Genau diese Aufteilung erklärt, warum der Appname allein manchmal nicht reicht.
Aus welchem Konto stammt der Anhang?
Manche nativen Apps können geschäftliche und private Konten in derselben Oberfläche zeigen. Apple Mail ist dafür das anschauliche Beispiel: eine App, darin das per MDM eingerichtete Geschäftskonto und daneben dein privates Konto.
Hier müssen wir also genauer hinschauen. Ein PDF-Anhang kann aus dem geschäftlichen oder aus dem privaten Postfach stammen. Anhänge eines verwalteten Kontos folgen den dafür konfigurierten Managed-Open-In-Regeln. Das private Konto wird durch die gemeinsame Mail-App nicht mitverwaltet.
Das ist mit Managed Accounts gemeint. Die Trennung sitzt in diesem Fall am Konto. Wir haben weder eine zweite Mail-App installiert noch pauschal die ganze Oberfläche für geschäftlich erklärt. Für eine Supportmeldung ist „Geht aus Mail nicht“ deshalb etwas dünn. Aus welchem Konto? Diese Rückfrage bringt uns weiter.
Bleiben wir bei der privaten PDF-App als Ziel: Ein Anhang aus dem verwalteten Geschäftskonto fällt unter die dafür gesetzte Open-In-Regel. Stammt der Anhang stattdessen aus dem privaten Konto, lässt sich dieselbe Sperre nicht allein mit dem gemeinsamen Mail-Symbol begründen. Für die Zuordnung brauchen wir also Herkunftskonto, Zielapp und geltende Regel. Ein funktionierender privater Weg beweist noch keine Lücke im geschäftlichen.
| Für die Weitergabe entscheidend | Managed App | Verwaltetes Konto in einer nativen App |
|---|---|---|
| Wo sitzt die Zuordnung? | An der Appinstallation | Am jeweiligen Konto |
| Was ordnen wir im Beispiel zu? | Die verwaltete CRM-App als Quelle | Das verwaltete Geschäftskonto als Herkunft des Anhangs |
| Welche private Nutzung bleibt getrennt zu betrachten? | Eine nicht verwaltete Zielapp | Das private Konto in derselben Mail-Oberfläche |
| Was entscheidet über den betrachteten Dokumentweg? | Quellenstatus, Zielstatus und geltende Open-In-Regel | Herkunftskonto, Zielstatus und geltende Open-In-Regel |
BlackBerry Dynamics
Wenn du für eine App eigene Zugangs- und Datenschutzregeln brauchst, führt die nächste Frage über ihren bloßen MDM-Status hinaus.
Ganz rechts in der geschäftlichen Fläche liegt der blaue Kasten BlackBerry Dynamics mit Work und Access. Der Pfeil zwischen beiden Apps und die Beschriftung „Eigene App-Verschlüsselung und Richtlinien“ zeigen, was hier hinzukommt.
Was schützt Dynamics innerhalb der App?
Hier kommen eigene App-Verschlüsselung und eigene Richtlinien hinzu. Das SDK stellt verschlüsselten Speicher und geschützten Datenaustausch zwischen Dynamics-Apps bereit. Work und Access sind Beispiele dafür.
Damit können wir genauer auf die Frage schauen: Was darf diese App? Darf sie Daten kopieren? An welche anderen Apps darf sie Dateien weitergeben? Diese Kontrollen gehören zur Dynamics-Ebene. Sie sind nicht einfach ein anderer Name für Apples Managed Open In.
Ob Dynamics zusätzlich ein MDM-verwaltetes Gerät voraussetzt, lässt sich im Dynamics-Profil festlegen. Die Grafik zeigt eine solche verwaltete Umgebung. Geräteverwaltung und Dynamics-App-Schutz bleiben dabei getrennte Entscheidungen. Wer aus Ivanti EPMM kommt, trifft beide beim Wechsel neu; welche Kriterien dabei zählen, steht unter Ivanti EPMM ablösen.
Was passiert, wenn eine Datei Dynamics verlässt?
Wichtig wird die Grenze, sobald eine Datei Dynamics verlässt. UEM beschreibt eine Option, Dateien unverschlüsselt in ausgewählten Nicht-Dynamics-Apps zu öffnen. Das muss die eingesetzte App-Version unterstützen. Die Verschlüsselung innerhalb von Dynamics reist also nicht automatisch mit jedem freigegebenen Export mit.
Soll der Bericht aus Work in einer Nicht-Dynamics-PDF-App bearbeitet werden, würde ich zuerst genau diesen Export betrachten: Unterstützt die eingesetzte Work-Version den Weg, ist die Zielapp dafür ausgewählt, und darf dort eine unverschlüsselt übergebene Datei liegen?
Reicht der Schutz am Ziel für die Aufgabe nicht aus, hilft es nicht, dass der Bericht zuvor in Dynamics verschlüsselt war. Dann brauchen wir einen anderen geeigneten Bearbeitungsweg. Die Freigabe ist damit eine Entscheidung über den nächsten Speicherort, nicht bloß über einen bequemeren Öffnen-Dialog.
Der Pfeil zwischen Work und Access steht dagegen für den geschützten Austausch innerhalb dieser Ebene. Für den konkreten Weg müssen beide Apps die passende Austauschfunktion unterstützen und die Regeln sie erlauben.
Managed Open In und App-Regeln
Eine Schutzregel hilft erst dann, wenn klar ist, welche Weitergabe sie verhindern soll. Sonst sperrst du leicht einen Arbeitsweg, der gebraucht wird.
Unten innerhalb der geschäftlichen Fläche liegt das Feld Managed Open In / App-Regeln. Dort laufen die Pfeile der drei Spalten zusammen. Der rote Pfeil führt nach links zum Bereich Privat / unmanaged. Das Bild bündelt hier unterschiedliche Kontrollen; unser PDF zeigt, welche davon wir für einen konkreten Weg brauchen.
Darf der Bericht in die private PDF-App?
Nehmen wir nun an, die PDF-App bleibt privat. Ein geschäftlicher Bericht liegt in der verwalteten CRM-App, und du möchtest ihn in dieser privaten PDF-App bearbeiten. Jetzt können wir den Vorgang einordnen: verwaltete Quelle, nicht verwaltetes Ziel, Dokument in einer anderen App öffnen. Für diesen Weg suchen wir zuerst bei den iOS-Regeln.
Die UEM-Einstellung heißt Allow documents from managed sources in unmanaged destinations. In der UEM-12.24-Referenz ist sie standardmäßig ausgewählt. Die Weitergabe ist für diesen erfassten Weg also zunächst erlaubt. Soll unser Bericht im geschäftlichen Bereich bleiben, muss die passende IT-Policy diese Erlaubnis entziehen. Der rote Stop in der Grafik steht für diese bewusst gesetzte Grenze.
Das ist auch der Grund, warum ich mit der gewünschten Handlung anfange. „Das iPhone ist verwaltet“ sagt uns zu wenig. „Diese Datei darf aus dieser App nicht in jene App“ führt uns zur zuständigen Regel.
Wie bleibt die Arbeit trotzdem möglich?
Eine Frage bleibt dabei leicht liegen: Wo soll die Person den Bericht stattdessen bearbeiten? Wenn wir die Übergabe an die private PDF-App sperren, brauchen wir einen passenden geschäftlichen Weg. Sonst haben wir eine erfolgreiche Sperre und eine unerledigte Aufgabe. Beides gehört in denselben Test.
Wie prüfst du genau diese Grenze?
Wenn du die Grenze in deiner Umgebung prüfen willst, würde ich den Test klein halten. Eine unkritische PDF-Datei, eine bekannte Quellapp, eine private Zielapp und eine vorgesehene geschäftliche Zielapp reichen für den ersten Durchgang.
Die Administration prüft zunächst den tatsächlichen Appstatus, die Aktivierungsart und die zugewiesene Regel. Dann schaut sie, ob das Gerät die Konfiguration verarbeitet hat. Erst danach probieren wir beide Wege aus: Die private Übergabe soll scheitern, die geschäftliche Bearbeitung soll funktionieren. Wie sich eine Sperre im Dialog zeigt, hängt von den beteiligten Apps ab. Ein fehlender Menüeintrag allein ist noch kein Beweis, dass genau unsere Regel gegriffen hat.
Und Copy/Paste? Das gehört in einen eigenen Test. UEM kann die Zwischenablage mit einer separaten Regel an die beiden Managed-Open-In-Richtungen binden. Prüfe dabei, ob die Regel für deine Aktivierungsart und iOS-Version verfügbar ist.
Stolperfalle: Eine blockierte Dokumentöffnung beweist weder eine Copy/Paste-Sperre noch einen Schutz sämtlicher anderer Exportwege.
Notiere deshalb den geprüften Ablauf samt Apps, Versionen und Regelstand. Dann weiß der nächste Administrator, welche Grenze tatsächlich geprüft wurde, und die Person am iPhone kennt ihren funktionierenden Arbeitsweg.
Geräte-VPN Per-App VPN und Dynamics
Erreichen und Weitergeben sind zwei verschiedene Probleme. Wenn wir sie vermischen, suchen wir womöglich eine fehlende Verbindung in einer Exportregel.
Jetzt verlassen wir den iPhone-Rahmen. Darunter stehen drei Kacheln: links Geräte-VPN, in der Mitte Per-App VPN, rechts Dynamics. Sie ergänzen die Schutzbereiche um den Weg ins Netzwerk.
Kommt die App nicht ans Ziel oder die Datei nicht aus der App?
Diese Kacheln beantworten die Frage, wie die App ihr Ziel im Netzwerk erreicht. Bei Per-App VPN wird der Verkehr zugewiesener Apps über den Tunnel geführt; der gezeigte Dynamics-Weg führt für entsprechend konfigurierte Ziele über BlackBerry Proxy.
Bleiben wir beim Bericht: Kann die App ihn vom geschäftlichen Server gar nicht laden, beginnen wir bei der Erreichbarkeit; auch Anmeldung oder Berechtigungen können den Abruf verhindern. Soll dafür Per-App VPN greifen, muss die App dem vorgesehenen Tunnel zugewiesen sein. Die Zuweisung allein beweist noch nicht, dass die Verbindung funktioniert.
Kann sie denselben Bericht dagegen frisch vom Server laden und anzeigen, scheitert aber beim anschließenden Öffnen in der privaten PDF-App, untersuchen wir zuerst diesen Übergang und die beteiligten App-Regeln. Das Laden belegt den gerade benutzten Verbindungsweg, nicht automatisch alle Netzwerkfunktionen.
Der Netzweg bringt unseren Bericht zur App. Die Übergangsregel entscheidet anschließend, ob er von dort in eine andere App darf. Wenn du diese beiden Fragen auseinanderhältst, wird aus der großen bunten Grafik eine ziemlich brauchbare Landkarte.
Fang mit einem echten Arbeitsablauf an. Geh die beteiligten Apps und Konten durch. Dann lässt sich die passende Grenze setzen, ohne unterwegs die eigentliche Aufgabe zu verlieren.
Dokumentstand: BlackBerry UEM 12.24 als Dokumentbasis; Apple-, Android- und Dynamics-Primärquellen geprüft am 5. Oktober 2026. Der PDF-Bericht ist ein gedachtes Beispiel.
Weiter zu BSCP und Dynamics auf dem iPhone
Die passende Freigaberegel erklärt noch nicht, wo der geschützte Transportweg beginnt. Was schützt bereits die App, was übernimmt der Tunnel? Im nächsten Artikel „BSCP und Dynamics auf dem iPhone: Welcher Weg passt zu deiner Arbeit?“ vergleichen wir beide Wege aus Administrator-, Sicherheits- und Anwendersicht.
Stand und Quellen
- Apple Platform Deployment – Managed Apps: Bereitstellung, Verwaltungsübernahme und deren Grenzen.
- Apple Platform Deployment – Organisationsdaten: verwaltete Konten, Managed Open In und Zwischenablage.
- Android Open Source Project – Arbeitsprofile: getrennte Appinstanzen und App-Daten im privaten und im Arbeitsprofil.
- BlackBerry Dynamics SDK für iOS: verschlüsselter Speicher und geschützter Austausch zwischen Apps.
- BlackBerry UEM 12.24 – Managing apps, S.9, 37–38 und 43–44: vorhandene Apps übernehmen, Dynamics-Voraussetzungen und Datenaustausch.
- BlackBerry UEM 12.24 – IT policy rules, S.38–39: beide Open-In-Richtungen und Copy/Paste.
- BlackBerry UEM 12.24 – Overview and Architecture, S.56–57 und 66: Dynamics-Netzweg und Konfigurationsfluss.
- BlackBerry UEM 12.24 – Managing secure connections, S.40–41: Geräte- und Per-App-Verbindungen.