Sophos Mobile Tenant einrichten und Administration übergeben

Sophos Mobile wird in einem vorhandenen Sophos-Fusion-Tenant eingerichtet. Dieser Ablauf endet bei der Vorbereitung und Freigabeentscheidung für eine begrenzte Pilotierung, nicht bei einem durchgeführten Enrollment oder produktiven Massen-Rollout. Mobile Device Management (MDM) und Mobile Threat Defense sind unterschiedliche Lizenz- und Funktionsumfänge. Vor Änderungen Tenant, Edition, Rolle, Geräteplattform, Eigentumsmodell und Rückweg festhalten. Die allgemeine Tenant-Aktivierung und übergreifende Administratorabsicherung stehen in Sophos Fusion Tenant sicher in Betrieb nehmen.

1. Lizenz und Berechtigung vorab klären

Über das Profile icon > Licensing im richtigen Fusion-Tenant Produkt, Edition und verfügbaren Umfang gegen den Auftrag prüfen. Sophos Mobile Device Management (früher Central Mobile Standard) deckt MDM für Android, iPhone/iPad, Mac und Windows ab; Sophos Mobile Threat Defense (früher Intercept X for Mobile) betrifft die Verwaltung von Intercept X for Mobile sowie Sophos Chrome Security. Sophos Mobile (früher Central Mobile Advanced) umfasst beide. Eine sichtbare Mobile-Oberfläche beweist keine bestimmte MDM-Berechtigung. Lizenz nicht auf Verdacht einlösen: Aktivierung, Verlängerung und Lizenzfolgen gehören zum Fusion-Lizenzablauf; dort erst Tenant und Auftrag abgleichen.

Region gesondert nachweisen: Im betreffenden Fusion-Konto My Products > Mobile öffnen und die Region aus der Browser-URL nach smc-user-if-cloudstation- ablesen und für die Infrastruktur-/Netzwerkfreigabe festhalten. Die Sophos-Mobile-Serverziele sind regionsabhängig; die zuständige Netzwerkperson gleicht die für die tatsächliche Region und Plattform erforderlichen Verbindungen mit der aktuellen Sophos-Netzwerkdokumentation ab. Region weder aus Unternehmensstandort oder Sprache noch aus der persönlichen Admin-Zeitzone ableiten. Ohne belegte Region und erforderliche Netzwerkfreigabe kein Go für den betroffenen Pilotweg.

Für die Ersteinrichtung einen berechtigten Admin oder Super Admin verwenden. Die Fusion-Rollen werden in Mobile so abgebildet:

In Fusion die verantwortlichen Personen und Rollen gemäss Administrationsrollen richtig zuweisen festlegen, dann mit einem separaten Help-Desk- und Read-only-Konto in Mobile prüfen, welche Menüs und Aktionen tatsächlich zugänglich sind. Nicht das einzige funktionsfähige Administrator-Konto herabstufen. In der MDM-Dokumentation darf Helpdesk auch Geräte registrieren und Apps installieren. Kritische Funktionen wie das Festlegen von Einstellungen sowie das Erstellen, Bearbeiten und Löschen von Geräten, Gerätegruppen und Paketen sind für diese Mobile-Rolle ausgeschlossen. Die Threat-Defense-Rollenbeschreibung nennt als erlaubte Helpdesk-Aktionen nur allgemeine Supportaktionen; die genannten kritischen Funktionen sind dort ebenfalls ausdrücklich ausgeschlossen. Daraus keine universelle Helpdesk-Enrollment-Berechtigung für jede Edition ableiten. Verzeichnis-/LDAP-Anbindung und Identitätssynchronisierung sind ein eigener Freigabe- und Rückwegprozess, nicht eine Nebenwirkung der Rollenzuweisung.

2. Basiseinstellungen ohne Geräteänderung setzen

Persönliche Anzeigeeinstellungen in Sophos Mobile Admin gelten nur für das angemeldete Admin-Konto. Sophos nennt dazu auch die konfigurierbare Sprache der Benutzeroberfläche, beschreibt auf der Seite zu persönlichen Einstellungen aber weder einen Sprachselektor noch dessen Position oder Bedienung. Die UI-Sprache ist von der unten beschriebenen Sprache ausgehender E-Mails zu unterscheiden; eine automatische Übernahme der Fusion-Sprache ist damit nicht belegt.

In Sophos Mobile Admin > Setup > General die Zuständigkeit je Einstellung trennen:

1. Personal: Zeitzone, Masseinheiten, Tabellenzeilen, Expert mode und angezeigte Geräteplattformen für das angemeldete Admin-Konto einstellen und Save wählen. Die einzelnen Einstellungen wirken wie folgt:

   • Time zone legt fest, in welcher Zeitzone Datums- und Zeitwerte angezeigt werden.
   • Unit system bestimmt das Masssystem für Längenwerte: Metric oder Imperial.
   • Lines per page in tables legt die maximale Anzahl angezeigter Einträge pro Tabellenseite fest.
   • Wenn Expert mode aktiviert ist, enthält die Seite Show device die Registerkarte Custom properties mit benutzerdefinierten Geräteeigenschaften und die Registerkarte Internal properties mit zusätzlichen, vom Gerät gemeldeten Eigenschaften. Mehrere Konfigurationsseiten für Richtlinien zeigen dann ausserdem den Abschnitt Extra settings, in dem man optionale Einstellungen konfigurieren kann.

   Aktivierte Plattformen steuern die Sichtbarkeit einschlägiger Seiten und Einstellungen; sie aktivieren weder eine Lizenz noch enrollen sie Geräte. Nach dem Speichern prüfen, ob die erwartete Plattform in der Navigation angezeigt wird. Fehlende Ansichten zuerst mit dem persönlichen Plattformfilter und der Rolle abgleichen; bei Bedarf frühere Auswahl wiederherstellen.

2. IT contact: eine überwachte Supportadresse und einen erreichbaren Kontakt hinterlegen, Save wählen und den Text erst nach gesonderter Pilot-Freigabe auf einem dafür vorgesehenen Testgerät kontrollieren. Diese Angaben erscheinen auf Benutzergeräten. Keine private Nummer oder nicht freigegebene personenbezogene Information eintragen. Korrekturen wieder in derselben Registerkarte speichern und am Testgerät erneut prüfen.

3. Email configuration: Sprache der von Sophos Mobile versandten E-Mails festlegen und Save wählen. Das ist nicht die Konfiguration eines SMTP-Relays, Exchange-Postfachs oder EAS-Proxys. Einen tatsächlichen Mobile-Nachrichtenanlass im Pilot prüfen; allein Save bestätigt keine Zustellung. Bei falscher Sprache vorherigen Wert wiederherstellen und eine weitere Testnachricht beurteilen.

Der Setup-Bereich enthält ausserdem Plattform-, Datenschutz- und Integrationsoptionen. Nicht pauschal APNs-Zertifikate, Android Enterprise, Geräte-Synchronisierung, Datenschutzfreigaben oder EAS einschalten. Die persönliche Zeitzone ist keine globale Tenant-Zeitzone; der IT-Kontakt und die E-Mail-Sprache sind dagegen Teil der allgemeinen Mobile-Konfiguration. Die Startanleitung nennt zusätzlich das Fusion Self Service Portal als eigene Einrichtungsetappe.

3. Geräte und Enrollment nur vorbereiten

Für MDM zunächst Eigentum (Organisation oder privat), Zielplattform, Managementmodus, betroffene Benutzergruppe, Gerätezahl und Einwilligungs-/Datenschutztext klären. Bei Android den Android-Enterprise-Modus und dessen Voraussetzungen gesondert abnehmen; für iPhone, iPad und Mac das in Sophos Mobile benötigte APNs-Zertifikat samt Zuständigkeit, einjähriger Gültigkeit und Erneuerung vor einem Enrollment freigeben. Für eine spätere Erneuerung muss der Apple-Owner den ursprünglichen Apple Account und das richtige Zertifikat anhand des APNs-Topic nachweisen: Ein neues oder falsches Zertifikat mit anderem Topic kann die Verwaltung bereits eingeschriebener Geräte unterbrechen und erneutes Enrollment erfordern. APNs-Zertifikat nicht als Rückweg für bestehende Geräte entfernen.

Fehlt das Zertifikat und wurde in diesem Mandanten noch nie eines hochgeladen, die erstmalige APNs-Erstellung an den APNs-Owner übergeben; Erstellung und Upload benötigen eine gesonderte Freigabe und werden nicht beiläufig in diesem Vorbereitungsablauf ausgeführt. Bei einem vorhandenen Zertifikat übernimmt der APNs-Owner den Identitätsabgleich und die Erneuerung. Für die Übergabe die angezeigten Zertifikatsdetails, Ablaufdatum, zuständigen Apple Account und Erneuerungsverantwortung nachweisen lassen; keine Zugangsdaten ins Prüfprotokoll kopieren und einen Upload nicht mit Pilot-Abnahme gleichsetzen. Das Apple-Business-Service-Token ist davon getrennt. Das Threat-Defense-Handbuch führt nicht denselben Apple-/EAS-Setup-Baum wie die MDM-Ausgabe: gemeinsame Basiseinstellungen sind keine Zusage identischer Gerätefunktionen.

Nur wenn automatisiertes Enrollment über Apple Business gewählt wird: Der Apple-/Enrollment-Owner weist eine in Apple Business (früher Apple Business Manager) registrierte Organisation und ein berechtigtes Apple-Business-Konto, ein in Sophos Mobile hinterlegtes APNs-Zertifikat sowie die separate Verbindung mittels Apple-Business-Service-Token nach. Die einjährige Token-Gültigkeit und Verlängerungsverantwortung festhalten; beim Erneuern muss derselbe Apple Account wie für den ursprünglichen Token verwendet werden. Ein Reset der Integration löscht in Sophos Mobile Token, Apple-Business-Geräte und -Profile und ist kein harmloser Rückweg. Ohne diese Nachweise kein Go für diesen Weg; Apple Business ist keine pauschale Voraussetzung für jeden Apple-Enrollment-Weg. In diesem Tenant-Basisablauf weder Token noch Profile anlegen oder zurücksetzen.

Nur wenn Android Enterprise gewählt wird: Der Android-/Google-Owner belegt vor dem ersten Android-Pilot die passende MDM-Lizenz, den Android-Enterprise-Managementmodus, die Registrierung der Organisation und die Verbindung des richtigen Google-Unternehmenskontos mit Sophos Mobile. Die Moduswahl allein ändert verfügbare Richtlinientypen, sie registriert keine Organisation. Den tatsächlich vorhandenen Registrierungs- und Enrollment-Modus sowie die Herkunft und Bereitschaft der verwalteten Google-Konten für die Testbenutzer prüfen: je nach Konfiguration verwaltet Sophos Mobile Konten, oder die Benutzer müssen vorab in Google Workspace/Cloud Identity vorhanden sein; nur bei einer Registrierung der Organisation im Modus managed Google domain vor dem 9. April 2024 und deaktivierter Option Use managed Google domain device enrollment prüft Sophos Mobile beim SSP-Enrollment, ob ein verwaltetes Google-Konto aus dem Teil vor @ der E-Mail-Adresse des Benutzers in Sophos Fusion und der verwalteten Google-Domäne der Organisation bereits existiert, und erstellt es andernfalls, ohne dessen weiteren Lebenszyklus zu verwalten. Dieses verwaltete Benutzerkonto ist weder das Google-Unternehmenskonto für die Android-Enterprise-Registrierung noch automatisch ein FRP-Entsperrkonto; die Identitätszuordnung und den Kontowiederherstellungsweg vor dem Pilot unabhängig prüfen. Für den gewählten Gerätetyp passende Richtlinie prüfen; bei SSP-Enrollment das zugewiesene Enrollment-Paket mit Android-Enterprise-Task-Bundle (Enroll und Assign policy) sowie die Managed-Google-Play-Freigabe der Sophos Mobile Control App für automatische Updates abnehmen. Den konkreten Enrollment-Weg auf Eignung für den Modus prüfen; vollständig verwaltete Android-Geräte dürfen nur unkonfiguriert oder nach freigegebenem Werksreset eingeschrieben werden. Falls dafür ein bereits genutztes Gerät zurückgesetzt werden soll, muss der Geräte-Owner vorher den tatsächlichen Factory-Reset-Protection-(FRP)-Status, den vorgesehenen Reset-Weg und den freigegebenen Entsperr-/Kontowiederherstellungsweg prüfen. Dabei Zugang zu den für FRP auf diesem Gerät berechtigten Google-Konten organisatorisch sicherstellen; das Konto für die Android-Enterprise-Registrierung oder das Benutzerkonto ist nicht automatisch ein FRP-Entsperrkonto. Je nach Reset-Weg kann FRP nach dem Zurücksetzen eine Kontoanmeldung verlangen. Zugangsdaten nicht in der Pilotdokumentation festhalten. Diese Prüfung betrifft geplante Resets vollständig verwalteter Android-Geräte, nicht pauschal Arbeitsprofile oder Apple-Geräte. Keine Google-Enterprise-Registrierung, Kontenumstellung oder Geräterücksetzung beiläufig in diesem Basisablauf ausführen.

Vor einer Einladung im Setup > Self Service Portal die geplante Pilotkonfiguration erfassen: zulässige Gerätetypen, Eigentumsmodus, passende Gerätegruppe und Enrollment-Paket sowie erlaubte Selbstbedienungsaktionen. Die maximale Gerätezahl begrenzt Geräte pro Benutzer, nicht die Zahl der Pilotbenutzer oder die Reichweite der Konfiguration. Die Pilotgruppe ist separat über die tatsächliche Benutzer-/Gruppenzuordnung einzugrenzen. Vor jeder Änderung an einer gemeinsam genutzten SSP-Konfiguration die wirksame Default-Konfiguration (Fallback ohne passendere Zuordnung), alle für Pilot- und Nichtpilotbenutzer passenden Gruppen und deren Prioritäten sowie erlaubte Aktionen und Auswirkungen auf bereits eingeschriebene Geräte prüfen und dokumentieren. Vor jedem Schreiben an gemeinsam genutzte SSP-Einstellungen die konkrete Änderung samt Reichweite von einer unabhängig berechtigten Person gesondert autorisieren lassen und die bisherigen Einstellungen einschliesslich Default, Gruppen, Prioritäten, Aktionen und Plattformzuordnung sowie den Rückweg festhalten; ohne diese Freigabe die Konfiguration unverändert lassen. Nach Save, noch vor Einladungen oder Enrollment, die tatsächlich wirksame Zuordnung für Pilot- und Nichtpilotidentitäten einschliesslich Default und Mehrfachgruppen sowie die Auswirkungen auf bereits eingeschriebene Geräte und deren SSP-Aktionen prüfen und dokumentieren. Bei unerwarteter Reichweite weitere Änderungen und Einladungen stoppen, die vorherigen Einstellungen wiederherstellen und die wirksame Zuordnung und Geräteauswirkungen erneut prüfen; falls die Wirkung nicht sicher zurückgenommen werden kann, kein Go und an die zuständigen Owner eskalieren. Diese Schreibfreigabe ist vom späteren Go für das Pilot-Enrollment getrennt. Eine scheinbar enge Pilotkonfiguration kann durch Default oder Mehrfachgruppenzugehörigkeit andere Benutzer treffen. Nur wenn der freigegebene Pilotweg eine Zustimmung zu SSP-Nutzungsbedingungen verlangt: Der SSP-/Enrollment-Owner prüft für die Testidentität und gewählte Plattform die wirksamen Enrollment texts und das plattformspezifische Feld Terms of use auf freigegebenen Inhalt. Ist Terms of use leer, wird vor dem Enrollment kein solcher Text angezeigt und keine Zustimmung dazu eingeholt; dann kein Go für diesen SSP-Zustimmungsweg. Erfolgt die Einwilligung stattdessen über einen separaten freigegebenen Prozess, diesen Weg dokumentieren; SSP-Nutzungsbedingungen sind keine pauschale Voraussetzung für andere Enrollment-Wege. Richtlinien, Compliance und Enrollment-Pakete sind getrennte Voraussetzungen, keine automatische Folge der Basiseinstellungen.

Freigabe-Gate vor jedem Pilot-Enrollment: Eine zweite berechtigte Person prüft im tatsächlichen Tenant Edition/Lizenz und den verfügbaren Mobile-Lizenzumfang für die benannten Pilotbenutzer beziehungsweise benutzerlosen Geräte, Rollen, belegte Region und Netzfreigabe; bei SSP-Wegen die effektive SSP-Zuordnung für Testidentität und Nichtpilotidentität einschliesslich Default/Priorität und Gruppenreichweite statt pro-Benutzer-Gerätelimit; bei benutzerlosen Dedicated Devices stattdessen den separat freigegebenen voll verwalteten Android-Enrollment-Weg und die Gerätezuordnung; ausserdem Plattform/Managementmodus, Einwilligung, Richtlinien/Paket sowie Backup-, Reset- und Offboarding-Zuständigkeit. Verlangt der freigegebene Weg SSP-Zustimmung, umfasst das Go/No-go die wirksamen Enrollment texts, ein mit freigegebenem Text befülltes plattformspezifisches Feld Terms of use und die Testidentität; andernfalls ist der separate freigegebene Einwilligungsprozess zu dokumentieren. Für gewählte Apple-MDM-Wege gehört der APNs-Owner-Nachweis dazu; bei gewähltem Apple-Business- oder Android-Enterprise-Weg fordert sie zusätzlich die oben genannten wegspezifischen Owner-Nachweise an. Falls ein Werksreset eines vollständig verwalteten Android-Geräts geplant ist, gehören der vorab belegte FRP-Status samt vorgesehenem Reset-Weg und der freigegebene Entsperr-/Kontowiederherstellungsweg für die tatsächlich berechtigten FRP-Konten ausdrücklich dazu. Nicht gewählte Wege sind keine pauschalen Sperren. Sie dokumentiert ein ausdrückliches Go/No-go für die benannten Testkonten und Geräte. Bei fehlendem Nachweis oder No-go: keine Einladung, kein Enrollment, keine Geräteänderung; an die zuständigen Owner zurückgeben. Diese Dokumentationsanleitung selbst erteilt keine Freigabe und belegt keinen Tenant- oder Gerätetest.

Erst nach gesondertem Go führt der zuständige Enrollment-Owner für benutzergebundene Wege mit einem eigens angelegten, benannten Testbenutzer je freigegebener Plattform den begrenzten Pilotversuch aus und hält Enrollment-Identität, Registrierung, zugewiesene Gruppe, Zielrichtlinie, Aufgabenstatus, IT-Kontakt und Nachrichtenempfang auf diesem Gerät sowie den Rückweg fest. Nur bei separat freigegebenem benutzerlosem Dedicated-Device-Pilot prüft der zuständige Geräte-/Enrollment-Owner stattdessen am benannten Testgerät den gewählten Management- und Enrollment-Weg ohne Benutzerzuweisung, die Enrollment-Identität beziehungsweise Gerätezuordnung, die Zielrichtlinie samt Kiosk-Konfiguration, den Aufgabenstatus und den belegten Wiederherstellungs-/Offboarding-Weg; dafür keinen Testbenutzer oder SSP-Gruppentreffer unterstellen. Nur wenn die freigegebene Route SSP-Zustimmung verlangt, zusätzlich die Anzeige der freigegebenen Terms of use vor dem Enrollment und deren Annahme durch die Testidentität beobachten und dokumentieren; bei separatem Einwilligungsprozess dessen freigegebenen Nachweisweg verwenden. Sophos empfiehlt den Test vor Einladungen an echte Benutzer; eine Freigabe hier ersetzt weder diese Beobachtung noch die spätere Rollout-Entscheidung. Einschreibungswege sind je nach Modus der Add-device-Assistent, manuelles Enrollment, Self Service Portal oder plattformspezifisch automatisiertes Enrollment; hier wird kein universeller Klickpfad für alle Geräte behauptet.

4. Rückweg und Übergabe

Vor dem Pilot die ursprünglichen Werte und Berechtigungen dokumentieren. Personal, IT contact und Email configuration lassen sich durch Wiederherstellen des vorherigen Werts und erneutes Save zurücksetzen; danach im betreffenden Konto beziehungsweise am Testgerät oder mit einer neuen Testnachricht verifizieren. Eine irrtümlich zu weit vergebene Rolle in Fusion mit einem weiterhin verfügbaren Administrator korrigieren und mit dem betroffenen Konto erneut anmelden. Pilotgruppen- und SSP-Konfigurationen erst nach Prüfung der tatsächlichen Zuordnung zurücknehmen; blosses Entfernen einer Konfiguration ist kein Nachweis, dass bereits enrollte Geräte abgemeldet sind oder weitere Einschreibungen gestoppt wurden.

Geräte-Offboarding ausdrücklich an den Geräte-/Enrollment-Owner übergeben: Bei einem benutzerlosen Dedicated-Device-Pilot muss der Owner zusätzlich den dafür freigegebenen Enrollment-Weg stoppen, prüfen, dass kein weiteres Gerät darüber eingeschrieben werden kann, und bereits eingeschriebene Testgeräte erfassen; das Sperren von Einladungen für Benutzer oder Gruppen genügt dafür nicht. Bei Abbruch oder Pilotende zuerst neue Einladungen und Enrollment-Wege im tatsächlich betroffenen Benutzer-/Gruppenumfang durch den verantwortlichen Owner stoppen lassen und die Wirksamkeit prüfen; dann Inventar der bereits eingeschriebenen Testgeräte mit Plattform, Modus, Eigentum und Zuordnung übergeben. Der Geräte-Owner entscheidet pro Gerät über Abmeldung, Benutzer-/Gerätezuordnung und Nachkontrolle und hält die Ergebnisse fest. Unenroll ist kein Einstellungs-Rollback: Je nach Plattform werden verwaltete Profile, Apps, Zertifikate, Konten und Daten entfernt; vollständig verwaltete Android-Enterprise-Geräte müssen zum Unenrollment auf Werkseinstellungen zurückgesetzt werden. Vor einem Werksreset eines vollständig verwalteten Android-Geräts auch den FRP-Status, den vorgesehenen Reset-Weg und den freigegebenen Entsperr-/Kontowiederherstellungsweg für die tatsächlich berechtigten FRP-Konten durch den Geräte-Owner nachweisen lassen; ohne diesen Nachweis nicht zurücksetzen. Vor einem tatsächlichen Unenrollment Gerätemodus, Backup, Eigentum, Freigabe und offizielle plattformspezifische Folgen prüfen. Löschen ist keine harmlose Inventarbereinigung: Erst plattformspezifisch abmelden und das Ergebnis prüfen, dann einen nicht mehr verwalteten Eintrag löschen. Wird stattdessen ein noch eingeschriebenes Gerät gelöscht, meldet es sich bei der nächsten Synchronisierung ab; das Löschen eines vollständig verwalteten Android-Enterprise-Geräts löst einen Werksreset aus und kann Daten vernichten. Vor dem Löschen prüfen, welche Geräteinformationen und gespeicherten Daten benötigt werden; die gelöschte Konsolenzeile belegt weder eine erfolgreiche Geräteabmeldung noch einen Daten-Rückweg. Das Löschen eines eingeschriebenen Windows-Geräteeintrags meldet das Gerät dagegen nicht automatisch ab; tatsächlichen Status geräteseitig prüfen. Für Apple-Geräte vor Reset, Abmeldung oder Freigabe auch den Activation-Lock-Status und den zuständigen Wiederaktivierungsweg vom Apple-/Geräte-Owner prüfen lassen; ein APNs-Zertifikat oder eine Apple-Business-Integration nicht zum vermeintlichen Offboarding zurücksetzen oder entfernen. App-Option Unenroll und SSP-Aktion Unenroll device sind getrennte Schalter; ein Ausblenden der einen Option sperrt nicht automatisch die andere. Weder Geräte-Löschung noch Lizenzentzug noch Rücknahme von Tenant-Einstellungen als reversiblen Abschaltweg ausgeben.

Für die Betriebsübergabe lässt eine zweite berechtigte Person Tenant und Mobile-Lizenz, Funktionsumfang der delegierten Rollen, gespeicherte Basiseinstellungen, effektive SSP-Reichweite und Freigabe-/Stopp- sowie Geräte-Offboarding-Übergabe nachprüfen. EAS-Proxy und Exchange-Mailfluss bleiben beim separaten EAS-Owner; LDAP-/Verzeichnissynchronisierung beim Identitäts-Owner. Ohne vorhandene freigegebene Geräte-/Enrollment- und EAS-/LDAP-Runbooks keine implizite Freigabe dieser Workflows oder tote Verweise setzen. Diese Informationsanleitung bescheinigt weder einen getesteten Tenant noch ein erfolgreich geprüftes Pilotgerät; die tatsächliche Freigabe für Geräteänderungen bleibt gesondert erforderlich.