Vergleiche & Entscheidungen
BSCP und Dynamics auf dem iPhone: Welcher Weg passt zu deiner Arbeit?
Vergleiche BSCP, den Dynamics-Proxy-Weg und Direct Connect nach Schutzgrenze, Verwaltungsbedarf und tatsächlicher Arbeit auf dem iPhone.
Dein iPhone soll auf Unternehmensdienste zugreifen: auf E-Mails, das Intranet oder eine interne Fachanwendung. Dafür genügt es nicht, dass die Verbindung irgendwie zustande kommt. Der gewählte Weg muss im mobilen Alltag funktionieren, zu euren Sicherheitsanforderungen passen und sich vernünftig betreiben lassen.
Dabei stellen sich sehr konkrete Fragen: Wie schnell reagiert die App, und was bedeutet die Verbindung für den Akku? Wo beginnt die Verschlüsselung, wo endet sie, und an welcher Stelle dockt der Weg am Unternehmensnetz an? Muss die Administration das iPhone verwalten, oder genügt die Verwaltung der geschäftlichen App? Diese Fragen gehören zusammen. Ein Dienst-iPhone ist möglicherweise schon passend verwaltet. Bei einem privaten iPhone kann dagegen die zusätzliche Aufnahme in die Geräteverwaltung genau der Punkt sein, an dem eine andere Lösung sinnvoll wird.
Mit BlackBerry Secure Connect Plus, kurz BSCP, und BlackBerry Dynamics stehen unterschiedliche Modelle zur Verfügung. Wir schauen uns an, welcher Verkehr welchen Weg nimmt, welche Schutzgrenze dabei entsteht und was sich dadurch für Nutzer und Administration ändert. So kannst du eine Verbindung passend zur Aufgabe auswählen, statt einer Technik pauschal den Vorzug zu geben. Für die Geschwindigkeit vergleichen wir drei Kandidaten: BSCP, Dynamics über den regulären BlackBerry-Proxy-Weg und Dynamics mit Direct Connect. Auch die Akkufrage bleibt dabei auf dem Tisch: Die Architektur erklärt die Unterschiede der Wege; welcher davon in eurer Umgebung wie viel Energie benötigt, lässt sich daraus allein noch nicht ablesen.
Für den Überblick brauchen wir zunächst nur zwei Ausgangspunkte. BSCP stellt auf dem iPhone eine VPN-Verbindung bereit, also einen geschützten Netzweg zu Unternehmensressourcen. iOS wählt anhand der Verwaltungskonfiguration aus, welche Apps oder Konten ihn nutzen. Bei BlackBerry Dynamics steckt die Schutzfunktion bereits in der jeweiligen App. Beispiele sind BlackBerry Work für geschäftliche Kommunikation und BlackBerry Access als verwalteter Browser. Für die hier gezeigte Dynamics-Proxy-Route beginnt der geschützte Kanal in der App und führt zu BlackBerry Proxy im Unternehmen.
Die erste Übersichtsgrafik zeigt, wo die beiden Wege auf dem iPhone beginnen. Die zweite Übersicht verfolgt sie bis zu ihrer Gegenstelle und weiter zum eigentlichen Dienst. Wichtig ist dabei die Unterscheidung zwischen dem Ende einer Verschlüsselung und dem Netzwerkperimeter: dem Übergang, über den Verbindungen in die Unternehmensinfrastruktur gelangen. Beides kann in einer konkreten Bereitstellung zusammenfallen, muss aber nicht.
Managed Apps und native Konten
Ein Tunnel, der den falschen Verkehr erfasst, hilft weder dem Nutzer noch der Sicherheitsplanung. Deshalb beginnen wir bei der Auswahl: Welche App oder welches Konto soll den internen Dienst erreichen? In Abbildung 1 findest du die verwalteten Apps in der grünen Mitte. Direkt darunter liegt der violette Bereich „Native Apps / Konten“. Der obere blaue MDM-Kasten zeigt, woher ihre Konfiguration kommt. MDM steht für Mobile Device Management, also die Geräteverwaltung.
Wie kommt eine App in den BSCP-Tunnel?
Nehmen wir eine CRM-App, die auf einen internen Server zugreifen soll. Die Administration stellt sie per MDM als verwaltete App bereit. „Managed“ bezeichnet diesen Verwaltungsstatus der App-Installation. Anschließend ordnet die Administration ihr den passenden VPN-Weg zu. Das sind zwei getrennte Schritte: Die App wird verwaltet, und ihr Netzwerkverkehr bekommt eine Zuordnung.
Wenn die App die Verbindung aufbaut, führt iOS ihren Verkehr zu BlackBerry Connectivity. Dieser Client übernimmt auf dem iPhone die BSCP-Seite des VPN. In Abbildung 1 zeigen die dünnen grünen Pfeile von CRM und ERP über „iOS: App-Zuordnung“ dorthin. Der breite, verschlüsselte BSCP-Kanal beginnt bei BlackBerry Connectivity.
„Per-App“ bedeutet hier: Wir wählen Apps aus. CRM und ERP bekommen dadurch nicht jeweils einen eigenen BSCP-Tunnel. Mehrere zugewiesene Apps nutzen den gemeinsamen Tunnel des Geräts. Für den Anwender soll der interne Dienst aus seiner Arbeitsapp erreichbar sein. Die Administration muss dafür die richtige App zuordnen; bei der Sicherheitsbetrachtung zählt, welcher Verkehr damit erfasst wird und bis wohin der Tunnel schützt.
Warum reicht bei Mail der Appname nicht?
Die native Mail-App kann ein geschäftliches und ein privates Konto enthalten. „Mail soll den Tunnel nehmen“ wäre deshalb noch keine genaue Beschreibung unseres Ziels.
Beim entsprechend konfigurierten Per-Account VPN wird das verwaltete Konto dem VPN zugeordnet. So kann dessen Verkehr BSCP nutzen, ohne dass das private Konto durch diese Zuordnung automatisch mitgenommen wird. In der Grafik führt der Pfeil vom Geschäftskonto über „iOS: Konto-Zuordnung“ zum selben BlackBerry-Connectivity-Client.
Ändern wir die Voraussetzung und konfigurieren BSCP für alle Apps, wird die Auswahl weiter. Dann können auch nicht verwaltete Apps unter das aktive VPN-Routing fallen. Der genaue Umfang folgt der VPN-Konfiguration und dem Routing. Eine private App wird dadurch nicht zur Managed App; ihr Netzwerkweg kann sich trotzdem ändern.
Ich würde deshalb zuerst die benötigte Verbindung beschreiben: diese App oder dieses Konto zu diesem Dienst. Daraus lässt sich die passende Auswahl ableiten. Das ist genauer als „VPN für das iPhone“ und vermeidet, dass private Nutzung allein wegen einer zu weit gefassten Beschreibung unbeabsichtigt in den Unternehmensweg gerät.
BlackBerry Dynamics
Für den Zugriff mit Access ist entscheidend, ob wir eine Geräte-VPN-Verbindung brauchen oder den in der App vorgesehenen Weg nutzen können. Davon hängen Bereitstellung, Fehlersuche und die Frage nach zusätzlicher Geräteverwaltung ab. Unten in Abbildung 1 findest du deshalb einen eigenen blauen Bereich: Work und Access enthalten jeweils die „Dynamics Runtime“. Ihre breiten blauen Kanäle beginnen bereits dort.
Was übernimmt die Runtime in der App?
Die Runtime ist der in jede Dynamics-App integrierte Teil der Plattform. Sie stellt unter anderem geschützte lokale Datenhaltung, Richtliniendurchsetzung und verwaltete Kommunikation bereit.
Stell dir vor, du öffnest einen Intranet-Link in Access. Für die dargestellte Proxy-Route übernimmt die Runtime den geschützten Kanal bis BlackBerry Proxy. Von dort geht die Verbindung zum internen Webserver weiter. Auch Work besitzt eine eigene Runtime und einen eigenen Schutzkanal. BSCP ist für diesen gezeigten Weg nicht erforderlich.
Damit wird der Unterschied greifbar: Bei BSCP wählt iOS Verkehr aus und übergibt ihn an den VPN-Client. Bei Dynamics beginnt der eigene Schutzkanal innerhalb der App. Für die Sicherheitsentscheidung müssen wir deshalb unterschiedliche Komponenten und Endpunkte betrachten. Der Sicherheitszustand des Geräts bleibt dabei relevant; Appschutz macht Betriebssystemschwachstellen nicht bedeutungslos.
Nimmt Access für jede Webseite denselben Weg?
Nein. Die Administration legt im Dynamics-Connectivity-Profil fest, wie Ziele erreicht werden dürfen. Eine passende Regel kann eine Verbindung über BlackBerry Proxy führen, eine direkte Verbindung erlauben oder das Ziel sperren. Diese Möglichkeiten heißen „Proxy“, „Direct“ und „Deny“.
Für unseren Intranet-Link brauchen wir also zwei Antworten: Darf Access das Ziel ansprechen, und welcher Weg ist dafür vorgesehen? Dass eine andere Webseite funktioniert, beantwortet diese Fragen noch nicht. Wie sich Access an einem solchen internen Ziel ohne erneute Eingabe des AD-Passworts anmeldet, beschreibt KCD für BlackBerry Access einrichten und prüfen.
Ändern wir für das betrachtete Ziel die Route von Proxy auf Direct, gehört seine Verbindung nicht mehr zum dargestellten App-zu-BlackBerry-Proxy-Kanal. Dann müssen wir den direkten Netzweg und seine Absicherung betrachten. Gerade hier darf „Die App ist geschützt“ nicht die genauere Frage ersetzen: Welchen Schutz hat diese konkrete Verbindung?
Wie passt Access über BSCP dazu?
Die dokumentierte direkte Zielroute und die iOS-VPN-Auswahl lassen sich zu einem bedingten Modell verbinden: Wenn Access das konkrete Ziel nach seinen wirksamen Regeln direkt anspricht und iOS genau diesen Verkehr dem BSCP-VPN zuordnet, übernimmt BSCP den Netzweg ins Unternehmen. Der geschützte Kanal dieses Wegs endet beim BSCP-Dienst. Die Dynamics-Funktionen der App, etwa ihre geschützte lokale Datenhaltung, sind davon zu unterscheiden.
Wir verändern damit den Weg zu einem bestimmten Ziel, statt BSCP und Dynamics zu einer seriellen Tunnelkette zu verbinden. Ob die Kombination mit eurer Access-Version und den wirksamen App-, Connectivity- und VPN-Regeln so greift, muss die konkrete Konfiguration bestätigen. Das Modell ist keine universelle Einstellanleitung.
Für den Nutzer bleibt die Aufgabe dieselbe: die Intranetseite öffnen. Für Administration und Security ändern sich dagegen die zuständige Zuordnung und der Endpunkt des verwendeten Kanals. Genau deshalb lohnt sich der Blick hinter das sichtbare Ergebnis „Seite geladen“.
Transport Tunnelende und Unternehmensperimeter
Ein Schloss am Verbindungspfeil sagt noch nicht, dass die Daten bis zum eigentlichen Dienst geschützt sind. Für eine belastbare Sicherheitsentscheidung müssen wir den Weg bis zum Zielserver fertigzeichnen. Abbildung 2 trennt dafür Quelle und Tunnelstart, Transport, Tunnelende und Ziel. Die Zeilen zeigen Alternativen; sie sind keine Kette aus hintereinanderliegenden Tunneln.
Wo endet der Schutz und wo beginnt der nächste Abschnitt?
Die Zeilen A, B und C zeigen die BSCP-Auswahlen Per-App, Per-Account und Alle Apps. Auf dem iPhone führt der Weg über BlackBerry Connectivity in den geschützten IP-Tunnel. Seine Gegenstelle ist der BSCP-Dienst auf UEM beziehungsweise einem Connectivity Node. Dort endet die BSCP-Verschlüsselung. Anschließend werden die Daten zum eigentlichen Unternehmensdienst weitergeleitet.
In Zeile D beginnen die Dynamics-Kanäle in Work und Access. Ihre hier gezeigte Gegenstelle ist BlackBerry Proxy. Die BlackBerry-Infrastruktur vermittelt den Transport; bei diesem geschützten App-zu-Proxy-Kanal ist sie nicht die Stelle, die dessen Nutzdaten entschlüsselt.
Für unseren Intranet-Link reicht es daher nicht, nur den geschützten Kanal abzunehmen. Wir betrachten auch die anschließende Weiterleitung zum Webserver.
Sicherheit
Verwendet die Anwendung zusätzlich HTTPS, kann dieser Schutz über das Ende des BSCP- oder Dynamics-Kanals hinaus bis zum Backend reichen. Ohne eine solche zusätzliche Absicherung dürfen wir den Schutz des äußeren Kanals nicht einfach bis zum Zielserver verlängern.
Ist der Tunnelendpunkt automatisch der Unternehmensperimeter?
Der Tunnelendpunkt ist zunächst eine kryptografische Grenze: Hier endet der betrachtete Schutzkanal. Der Netzwerkperimeter beschreibt dagegen den Übergang zwischen Netzen und die dort eingesetzten Kontrollen, beispielsweise eine Firewall und einen vorgesehenen Proxy-Eingang. Die Grafik zeigt logische Endpunkte, keinen fertigen DMZ- oder Firewallplan.
Für die konkrete Anbindung würde ich deshalb drei Punkte aufzeichnen: Wo kommt die Verbindung in der Unternehmensinfrastruktur an? Welche Komponente beendet welchen verschlüsselten Abschnitt? Wie erreicht diese Komponente anschließend den Webserver? So können Netzwerkadministration und Security über denselben Weg sprechen, statt mit „geht über den Proxy“ unterschiedliche Dinge zu meinen.
Kommt ein vorgeschalteter Proxy hinzu, der TLS beendet und eine neue TLS-Verbindung aufbaut, verändert sich diese Betrachtung. Dann gibt es einen zusätzlichen Endpunkt für diese TLS-Schicht. Ob dort auch der eigentliche Appinhalt lesbar wird, hängt von zusätzlicher innerer Verschlüsselung ab. Ob die eingesetzte Lösung dieses Modell unterstützt und welche Zertifikate und Regeln nötig sind, gehört in die konkrete Planung. Mehr Komponenten ergeben nicht von selbst die passendere Schutzgrenze.
Was ändert Direct Connect?
Direct Connect verändert den Transportweg einer Dynamics-Verbindung zu BlackBerry Proxy. Für die so angebundenen Appdaten entfällt der Umweg über die BlackBerry-Cloud-Relay-Verbindung. Die Gegenstelle bleibt BlackBerry Proxy. Darum steht der Hinweis in Zeile D beim Transport.
Das kann bei ungünstigen Laufzeiten über die Cloud den Verbindungsaufbau und den Datendurchsatz verbessern. Dafür muss die Administration einen geeigneten, erreichbaren Eingang zum Proxy bereitstellen und betreiben. Security muss dessen Schutz und die tatsächlichen TLS-Grenzen beurteilen. Ein kürzerer Weg ist für den Nutzer nur dann ein Gewinn, wenn dieser Eingang auch zuverlässig verfügbar ist.
Betrieb
Direct umgeht BlackBerry Proxy; Direct Connect führt zu BlackBerry Proxy.
Auch mit Direct Connect können für andere Funktionen, etwa Bereitstellung und Richtlinienbenachrichtigungen, weiterhin BlackBerry-Cloud-Dienste benötigt werden.
Fällt der Direct-Connect-Eingang aus, dürfen wir für die darüber angebundenen Unternehmens-Appserver keinen automatischen Cloud-Rückweg einplanen. BlackBerry dokumentiert für diese Verbindungen keinen solchen Verbindungsversuch. Verbindungen zur UEM-Verwaltung sind getrennt zu betrachten. Für die Betriebsplanung heißt das: Der vorgesehene Appdatenweg muss die erforderliche Verfügbarkeit liefern; die bloße Existenz eines anderen Transportmodells übernimmt diese Aufgabe nicht.
Geschwindigkeit und Akku im mobilen Alltag
Welcher der drei Wege ist schneller?
Eine Intranetseite soll nicht nur erreichbar sein, sondern auch zügig reagieren. Für die Auswahl müssen wir drei Wege auseinanderhalten: BSCP, den Dynamics-Standardweg über BlackBerry Proxy und Dynamics mit Direct Connect. Wer nur „BSCP gegen Dynamics“ vergleicht, übersieht bereits eine wichtige Variante.
Die Tabelle stellt dieselben Merkmale nebeneinander. „Gegenstelle“ meint jeweils das Ende des betrachteten Schutzkanals, nicht automatisch den Zielserver oder eine feste Netzwerkgrenze.
| Netzweg | Schutzbeginn | Gegenstelle | Voraussetzungen auf dem iPhone und im Betrieb | Performance und Beleggrenze |
|---|---|---|---|---|
| BSCP | BlackBerry Connectivity auf dem iPhone | BSCP-Dienst auf UEM oder Connectivity Node | Passende Geräteverwaltung und VPN-Zuordnung; bei Access zusätzlich wirksame Ziel- und Appregeln | Möglicher Vorteil gegenüber dem Dynamics-Standardweg ist eine fachliche Ausgangserwartung, kein Messbefund. Keine feste Rangfolge gegenüber Direct Connect. |
| Dynamics-Standardweg | Dynamics Runtime in der App | BlackBerry Proxy über die BlackBerry-Infrastruktur | Aktivierte Dynamics-App und passende Connectivity-Regeln; für diese Route kein BSCP nötig | Hohe Cloud-Laufzeiten können Aufbau und Durchsatz beeinträchtigen. Daraus folgt nicht, dass dieser Weg überall langsamer ist. |
| Dynamics mit Direct Connect | Dynamics Runtime in der App | Weiterhin BlackBerry Proxy, für diese Appdaten ohne Cloud-Relay-Weg | Zusätzlich ein geeigneter, erreichbarer und abgesicherter Direct-Connect-Eingang | Bei ungünstigen Cloud-Laufzeiten ist ein Vorteil bei Aufbau und Durchsatz dokumentiert. Kein allgemeiner Geschwindigkeits- oder Akku-Sieger. |
Beim Dynamics-Standardweg laufen die Appdaten über die BlackBerry-Infrastruktur zu BlackBerry Proxy und von dort zum Ziel. Sind die Laufzeiten auf diesem Weg ungünstig, kann sich das beim Verbindungsaufbau und beim Datendurchsatz bemerkbar machen. „Proxy ist langsam“ wäre trotzdem zu ungenau: Wir müssen wissen, welcher Abschnitt Zeit kostet.
Dynamics mit Direct Connect behält BlackBerry Proxy als Gegenstelle, lässt aber den Cloud-Relay-Weg für diese Appdaten aus. Für Umgebungen mit großen Laufzeiten zu oder von der Cloud beschreibt BlackBerry ausdrücklich einen Nutzen bei Verbindungsaufbau und Durchsatz. Das ist der Grund, warum ich diesen Weg zuerst betrachten würde, wenn Dynamics zur Aufgabe passt und der Cloud-Umweg stört.
Access über BSCP ist für ein passend verwaltetes iPhone ein weiterer Vergleichskandidat, sofern die wirksamen Regeln diese Anbindung wie oben beschrieben herstellen. Meine Erwartung für diesen Vergleich: BSCP kann gegenüber dem Dynamics-Standardweg einen Geschwindigkeitsvorteil bieten. Diese fachliche Ausgangsbewertung ersetzt aber keinen Vergleich der konkreten Konfiguration. Zwischen BSCP und Dynamics mit Direct Connect folgt daraus keine feste Reihenfolge. Lässt sich der erforderliche Direct-Connect-Eingang organisatorisch nicht bereitstellen, ist der BSCP-Vergleich auf einem bereits passend verwalteten iPhone besonders interessant.
Für die Entscheidung würde ich Verbindungsaufbau und eigentliche Datenübertragung getrennt betrachten: Wie lange dauert es, bis die Intranetseite reagiert? Und wie lange dauert eine größere Übertragung danach? Wir lassen Ziel, Gerät, App-Version und Netzbedingungen möglichst gleich und prüfen, ob tatsächlich der vorgesehene Weg genutzt wurde.
Ändert sich die Voraussetzung und liegt die Verzögerung hinter der Gegenstelle, etwa beim eigentlichen Webdienst, verkürzt ein anderer Transportweg nicht automatisch diesen Teil der Wartezeit. Deshalb entscheidet die Strecke, die wirklich bremst, darüber, ob Direct Connect, BSCP oder zunächst die Arbeit am Zielsystem sinnvoll ist.
Was bedeutet das für den Akku?
Eine Verbindung muss sich auch unterwegs bewähren. Wenn die Arbeitsapp zwar den Dienst erreicht, der gewählte Weg aber im Alltag störende Wartezeiten oder einen ungünstigen Akkuverbrauch mit sich bringt, ist die Auswahl noch nicht abgeschlossen. Die Akkufrage gehört genauso zur Entscheidung wie die Schutzgrenze. Ein schnellerer Seitenaufruf allein beweist dabei noch keinen niedrigeren Energieverbrauch.
Aus den Architekturgrafiken lässt sich kein verlässlicher Verbrauchswert ablesen. Sie zeigen, welche Komponenten beteiligt sind und wo die Kanäle beginnen und enden. Wie viel Energie die konkrete Nutzung benötigt, ist eine andere Frage. Weder „VPN“ noch „Verbindung aus der App“ ist dafür schon ein Messergebnis.
Ich würde den Verbrauch mit derselben Arbeitsaufgabe vergleichen: derselbe Intranet-Aufruf auf demselben iPhone, mit derselben App-Version und möglichst gleichen Netzbedingungen. Dabei betrachten wir nicht nur, ob die Seite einmal aufgeht. Wir vergleichen auch den Verbindungsaufbau, die Wiederaufnahme nach einer Unterbrechung und den Verbrauch während eines vergleichbaren Nutzungszeitraums. Die Messmethode und ihre Grenzen müssen für alle drei Varianten gleich sein.
So bekommt die Administration eine Grundlage für die Auswahl, der Nutzer eine Aussage zu seiner tatsächlichen Arbeit und Security einen Vergleich, bei dem der erwartete Schutzweg mitgeprüft wird. Ein niedrigerer gemessener Verbrauch würde wenig helfen, wenn der vermeintlich verglichene Verkehr in Wirklichkeit an der vorgesehenen Route vorbeiläuft.
Ändern sich Netz oder Nutzung, kann der Vergleich anders ausfallen. Ein Ergebnis aus einem kurzen Aufruf im WLAN beantwortet nicht automatisch die Frage nach einem mobilen Arbeitstag. Ohne passende Messung bleibt die Verbrauchsrangfolge offen. Die Architektur hilft uns aber bereits, die richtigen Varianten und Verantwortlichkeiten für diesen Vergleich festzulegen.
Welcher Weg passt zu welchem iPhone?
Jetzt lässt sich die Frage beantworten, warum wir nicht generell BSCP oder generell Dynamics vorgeben sollten. Die gleiche Intranetseite kann auf einem bereits verwalteten Dienst-iPhone und auf einem privaten iPhone gebraucht werden. Der gewünschte Zugriff bleibt gleich; der akzeptierte Verwaltungsumfang kann sich deutlich unterscheiden.
Was ändert sich ohne Geräteverwaltung?
Für den hier beschriebenen BSCP-Einsatz auf iOS brauchen wir die passende Geräteverwaltung und VPN-Konfiguration. Dynamics kann dagegen auch mit einer auf die geschäftlichen Apps begrenzten Aktivierung betrieben werden. Die App wird weiterhin aktiviert und verwaltet; das Gerät benötigt dafür nicht allein wegen dieses Dynamics-Modells eine MDM-Aufnahme.
Für ein privates iPhone, auf dem nur die geschäftlichen Apps verwaltet werden sollen, würde ich deshalb zuerst Dynamics betrachten. Damit lässt sich der benötigte Zugriff in diesen Apps bereitstellen, ohne für diesen Verbindungsweg zusätzliche Geräteverwaltung zu verlangen. Der Nutzer behält dieses gewünschte Bereitstellungsmodell, die Administration betreibt App-Aktivierung und Richtlinien, und Security bewertet den Appschutz mit seinen Voraussetzungen und Grenzen.
„Privat“ bedeutet nicht automatisch „ohne MDM“. Auch ein privates Gerät kann in eine Geräteverwaltung aufgenommen sein. Ist das iPhone bereits passend verwaltet, müssen wir diesen Schritt für BSCP nicht erst zusätzlich einführen. Damit wird BSCP zu einer möglichen Option für die geeigneten Apps und Konten. Die konkrete Zielroute und Schutzanforderung bleiben trotzdem zu klären.
Dass eine Verwaltungsebene entfällt, ist weder ein pauschaler Sicherheitsmangel noch ein Beweis für identische Sicherheit. Wir müssen wissen, welche Anforderung wir mit welcher Funktion erfüllen. Sonst vergleichen wir am Ende nur die Anzahl der Schutzschichten.
Womit würde ich die Entscheidung beginnen?
Ich würde zuerst die benötigte Arbeit und die akzeptierte Verwaltung festlegen. Danach zeichnen wir ihren Weg: App oder Konto, Auswahl, Kanalbeginn, Unternehmenseingang, Schutzende und Zielserver. Die beiden Übersichten liefern dafür das Grundmodell; die tatsächlichen Netzwerkgrenzen ergänzt ihr für eure Umgebung.
Passt Dynamics zur Aufgabe und stört der Cloud-Umweg, würde ich prüfen, ob Direct Connect ihn sinnvoll verkürzt. Dafür muss sich der zusätzliche Betrieb des erreichbaren Eingangs lohnen. Bei einem passend verwalteten iPhone kann auch eine geeignete BSCP-Anbindung in den Vergleich gehören. Die bedingte Access-Variante verlangt dabei eine Prüfung ihrer tatsächlich wirksamen Regeln.
Zum Schluss vergleichen wir Reaktionszeit, Datenübertragung, Akku und Wiederaufnahme unter passenden Bedingungen. Der erlaubte Arbeitsweg muss funktionieren und der Schutz muss dort greifen, wo wir ihn eingezeichnet haben. So wählen wir eine Verbindung, die zum iPhone, zur Aufgabe und zur Unternehmensinfrastruktur passt. Einen universellen Gewinner brauchen wir dafür nicht.
Stand und Quellen
Technischer Abgleich: 5. Oktober 2026. Die Darstellung behandelt iPhone/iOS; für andere Plattformen sind die jeweiligen Verwaltungs- und Verbindungsmodelle gesondert zu betrachten.
- BlackBerry UEM 12.24: BSCP und die iOS-Verbindungsvarianten, Voraussetzungen für Server und Geräte und Datenfluss des BSCP-Tunnels.
- BlackBerry: Dynamics SDK für iOS und Dynamics-Connectivity-Regeln in UEM 12.24.
- BlackBerry Access 3.21: App-Konfiguration und direkte Zielverbindungen. Das bedingte Access-BSCP-Modell verbindet dokumentierte Mechanismen; es ist keine universelle Hersteller-Schrittfolge.
- BlackBerry Dynamics: Direct Connect, Bereitstellungsvarianten und TLS-Grenzen und Security Whitepaper 2.4, insbesondere Seiten 6–8 und 31–33.
- BlackBerry UEM 12.24: Planungsmodelle einschließlich Dynamics-only ohne MDM.