Datenschutzorientierte Erläuterung pro Verbindung
1 — Screen Control ↔ Android Management API (AMAPI)
Screen Control sendet Gerätemanagement-Konfigurationen an Google AMAPI, einschließlich Richtlinien, Befehlen, Enrollment-Metadaten und Verweisen auf App-Richtlinien. Screen Control erhält Gerätemanagement-Daten aus AMAPI zurück, wie etwa Compliance-Status, angewendeten Richtlinienstatus, Geräteinventar und App-Berichte.
2 — AMAPI ↔ Device
Das Gerät erhält Provisionierungs- und Richtlinienanweisungen über Googles Android-Management-Komponenten und meldet den Managementstatus an AMAPI zurück. Über diesen Kanal werden Gerätemanagement-Daten ausgetauscht, wie etwa Gerätekennungen, Richtlinienstatus, Compliance-Status, Status installierter Apps und Update-/App-Management-Status.
3 — Play Store ↔ Device
Das Gerät verwendet managed Google Play / Play Store, um freigegebene Apps und App-Updates zu beziehen. Dies ist App-Distributionsverkehr. Für sich genommen bedeutet dies nicht, dass Google-Inhalte von Endnutzern, wie Gmail, Drive, Calendar, Contacts oder persönliche Kontodaten, ausgetauscht werden. Siehe den unten erläuterten Vorbehalt.
4 — Screen Control ↔ Device
Prowise kommuniziert außerdem direkt mit dem Gerät über Screen-Control-spezifische Mechanismen. Dadurch kann Prowise zusätzliche Konfigurationen über die standardmäßigen AMAPI-Möglichkeiten hinaus bereitstellen, den Live-Online-/Offline-Status des Geräts einsehen, Push-Benachrichtigungen senden, Fernzugriff ermöglichen und bestimmte Befehle oder Updates ausführen. Diese Verbindung sollte als separater, von Prowise kontrollierter Managementkanal betrachtet werden, getrennt vom AMAPI- und Play-Store-Verkehr.
5 — Screen Control ↔ Play Store
Screen Control kann in Google-Play-Store-Managementoberflächen integrieren, beispielsweise über Googles managed-Play-iframe-Ansatz, sodass Administratoren Apps über die Screen-Control-UI aufrufen, freigeben, konfigurieren und verwalten können. Dies ist ein administrativer App-Management-Flow, kein direkter Geräte-Telemetrieflow.
Enrollment
Für das EDLA-Enrollment erstellt Screen Control über die Verbindung 1 — Screen Control ↔ AMAPI ein Enrollment-Token. Dieses Token wird anschließend während der Firmware-Installation angewendet und vom Gerät über die Verbindung 2 — AMAPI ↔ Device verwendet, um das Enrollment abzuschließen. Das Token stellt sicher, dass das Gerät im vorgesehenen Modus enrolled wird, konkret als dedicated device und userless, und dass das Gerät der richtigen Organisation in Prowise / Screen Control zugeordnet wird.
Google Chrome
Google Chrome ist für bestimmte Kernfunktionen erforderlich und wird nach dem Enrollment eines Screens installiert. Um die Weitergabe von Nutzerdaten an Google zu begrenzen, empfehlen wir, die Browser-Anmeldung in Chrome über Screen-Control-App-Richtlinien zu deaktivieren.
Bitte beachten Sie, dass dies Nutzer nicht daran hindert, sich im Browser auf Google-Websites anzumelden, was weiterhin zu einer Weitergabe von Daten an Google führen kann. Dies ist selbstverständlich mit jedem Webbrowser möglich.
Administratoren können Chrome vollständig entfernen, dies wird jedoch nicht empfohlen, da dadurch die Anmeldung bei Central / Prowise-Diensten unterbrochen wird und auch die Anmeldung in anderen Apps beeinträchtigt werden kann.
Zusammenfassung
Der Enrollment-Modus ist dedicated device, userless. In diesem Modus ist zu Managementzwecken kein spezifisches Endnutzerprofil auf dem Gerät angemeldet. Google verwendet ein anonymes/userless Konto, um Android-Enterprise-Dienste wie Richtliniendurchsetzung und managed-Play-Zugriff zu ermöglichen.
Das bedeutet, dass die standardmäßige AMAPI-/managed-Play-Einrichtung standardmäßig keine Google-Inhalte von Endnutzern erhebt oder austauscht. Die relevanten Daten sind in erster Linie Geräte-Management- und App-Management-Daten: Gerätekennungen, Richtlinienstatus, Compliance-Status, Status installierter Apps, Update-Status und vergleichbare operative Metadaten.
Es gibt einen wichtigen Vorbehalt: Wenn Google-Apps in Screen Control freigegeben, auf dem Gerät installiert und anschließend von einer Person mit einem Google-Nutzerkonto verwendet werden, entsteht ein separater Datenfluss für dieses Nutzerkonto. Diese Anmeldung auf App-Ebene liegt außerhalb des grundlegenden userless dedicated-device Managementmodells. Dies kann von Administratoren einfach verhindert werden, indem keine zusätzlichen Google-Apps freigegeben werden.