Konfigurera Sophos Mobile-tenanten och lämna över administrationen

Sophos Mobile konfigureras i en befintlig Sophos Fusion-tenant. Den här processen slutar vid förberedelserna och beslutet om godkännande av en begränsad pilot, inte vid genomförd registrering eller produktionsutrullning i stor skala. Mobile Device Management (MDM) och Mobile Threat Defense har olika licens- och funktionsomfattning. Dokumentera tenant, utgåva, roll, enhetsplattform, ägandeform och återställningsväg innan du ändrar något. Allmän tenantaktivering och övergripande skydd av administratörskonton beskrivs i Driftsätt en Sophos Fusion-tenant säkert.

1. Klargör licens och behörighet först

Kontrollera produkt, utgåva och tillgänglig omfattning mot uppdraget via Profile icon > Licensing i rätt Fusion-tenant. Sophos Mobile Device Management (tidigare Central Mobile Standard) omfattar MDM för Android, iPhone/iPad, Mac och Windows; Sophos Mobile Threat Defense (tidigare Intercept X for Mobile) avser hantering av Intercept X for Mobile och Sophos Chrome Security. Sophos Mobile (tidigare Central Mobile Advanced) omfattar båda. Att Mobile-gränssnittet visas bevisar inte att en viss MDM-behörighet finns. Lös inte in en licens på chans: aktivering, förnyelse och licenskonsekvenser hör till processen för Fusion-licenser; stäm först av tenant och uppdrag där.

Verifiera regionen separat: Öppna My Products > Mobile i det aktuella Fusion-kontot, läs av regionen i webbläsarens URL efter smc-user-if-cloudstation- och dokumentera den inför godkännande av infrastruktur och nätverk. Serverdestinationerna för Sophos Mobile beror på region; nätverksansvarig jämför de anslutningar som behövs för den faktiska regionen och plattformen med aktuell nätverksdokumentation från Sophos. Härled inte regionen från företagets geografiska läge, språk eller administratörens personliga tidszon. Utan verifierad region och nödvändigt nätverksgodkännande ges inget klartecken för den berörda pilotvägen.

Använd en behörig Admin eller Super Admin för den första konfigurationen. Fusion-rollerna mappas till Mobile enligt följande:

Utse ansvariga personer och roller i Fusion enligt Tilldela administrationsroller korrekt. Kontrollera sedan med separata Help Desk- och Read-only-konton vilka menyer och åtgärder som faktiskt är tillgängliga i Mobile. Nedgradera inte det enda fungerande administratörskontot. Enligt MDM-dokumentationen får Helpdesk även registrera enheter och installera appar. Kritiska funktioner som att ange inställningar samt skapa, redigera och ta bort enheter, enhetsgrupper och paket är inte tillåtna för denna Mobile-roll. Rollbeskrivningen för Threat Defense anger bara allmänna supportåtgärder som tillåtna Helpdesk-åtgärder; de nämnda kritiska funktionerna är uttryckligen uteslutna även där. Dra inte slutsatsen att Helpdesk alltid får registrera enheter i alla utgåvor. Katalog-/LDAP-anslutning och identitetssynkronisering kräver en egen process för godkännande och återställning; de följer inte automatiskt av rolltilldelningen.

2. Ange grundinställningar utan att ändra enheter

Personliga visningsinställningar i Sophos Mobile Admin gäller bara det inloggade administratörskontot. Sophos nämner även att språket i användargränssnittet kan konfigureras, men sidan om personliga inställningar beskriver varken någon språkväljare, var den finns eller hur den används. Gränssnittsspråket ska skiljas från språket för utgående e-postmeddelanden som beskrivs nedan; detta belägger inte att språket automatiskt hämtas från Fusion.

Skilj på ansvaret för varje inställning under Sophos Mobile Admin > Setup > General:

1. Personal: Ange tidszon, måttenheter, tabellrader, Expert mode och visade enhetsplattformar för det inloggade administratörskontot och välj Save. De olika inställningarna fungerar så här:

   • Time zone anger i vilken tidszon datum och tider visas.
   • Unit system anger måttsystemet för längdvärden: Metric eller Imperial.
   • Lines per page in tables anger det maximala antalet poster som visas per tabellsida.
   • När Expert mode är aktiverat innehåller sidan Show device fliken Custom properties med anpassade enhetsegenskaper och fliken Internal properties med ytterligare egenskaper som enheten rapporterar. Flera konfigurationssidor för policyer visar då också avsnittet Extra settings, där du kan konfigurera valfria inställningar.

   Aktiverade plattformar styr vilka relevanta sidor och inställningar som visas; de aktiverar ingen licens och registrerar inga enheter. Kontrollera efter att du sparat att den förväntade plattformen syns i navigeringen. Om en vy saknas, kontrollera först kontots personliga plattformsfilter och roll; återställ vid behov det tidigare valet.

2. IT contact: Ange en bevakad supportadress och en kontakt som går att nå, välj Save och kontrollera texten på en avsedd testenhet först efter separat pilotgodkännande. Uppgifterna visas på användarnas enheter. Ange inte ett privat telefonnummer eller personuppgifter som inte har godkänts. Spara rättelser på samma flik och kontrollera dem igen på testenheten.

3. Email configuration: Välj språk för e-postmeddelanden som skickas av Sophos Mobile och välj Save. Det här konfigurerar inte ett SMTP-relä, en Exchange-postlåda eller en EAS-proxy. Kontrollera leverans och språk för ett meddelande som Sophos Mobile faktiskt skickar under piloten; enbart Save bekräftar inte att det levererats. Återställ det tidigare värdet om språket är fel och granska ett nytt testmeddelande.

Setup-området innehåller även alternativ för plattformar, dataskydd och integrationer. Aktivera inte generellt APNs-certifikat, Android Enterprise, enhetssynkronisering, dataskyddsgodkännanden eller EAS. Den personliga tidszonen är inte en global tidszon för tenanten; IT-kontakt och e-postspråk ingår däremot i den allmänna Mobile-konfigurationen. Startguiden anger dessutom Fusion Self Service Portal som ett separat konfigurationssteg.

3. Förbered bara enheter och registrering

För MDM: klargör först ägande (organisationen eller privatperson), målplattform, hanteringsläge, berörd användargrupp, antal enheter och text för samtycke/dataskydd. Godkänn Android Enterprise-läget och dess förutsättningar separat för Android. För iPhone, iPad och Mac ska det APNs-certifikat som Sophos Mobile behöver, certifikatansvarig, giltighetstiden på ett år och förnyelsen godkännas före registrering. Inför en senare förnyelse måste Apple-ansvarig styrka det ursprungliga Apple Account och rätt certifikat utifrån certifikatets APNs-Topic: ett nytt eller felaktigt certifikat med ett annat Topic kan avbryta hanteringen av redan registrerade enheter och kräva ny registrering. Ta inte bort APNs-certifikatet som en återställningsåtgärd för befintliga enheter.

Om certifikatet saknas och inget någonsin har laddats upp i den här tenanten, lämna över uppgiften att skapa ett APNs-certifikat för första gången till APNs-ansvarig; skapande och uppladdning kräver separat godkännande och ska inte utföras som ett sidosteg i denna förberedelseprocess. Om ett certifikat redan finns sköter APNs-ansvarig identitetskontrollen och förnyelsen. Låt ansvarig styrka de visade certifikatuppgifterna, utgångsdatumet, ansvarigt Apple Account och ansvaret för förnyelsen inför överlämningen; kopiera inga inloggningsuppgifter till kontrollprotokollet och likställ inte uppladdning med godkänd pilot. Apple-Business-Service-Token är en separat sak. Handboken för Threat Defense har inte samma konfigurationsträd för Apple/EAS som MDM-utgåvan: gemensamma grundinställningar innebär inte att enhetsfunktionerna är identiska.

Endast om automatiserad registrering via Apple Business väljs: Apple-/registreringsansvarig ska styrka att organisationen är registrerad i Apple Business (tidigare Apple Business Manager), att ett behörigt Apple Business-konto finns, att APNs-certifikatet har lagts in i Sophos Mobile och att den separata anslutningen med Apple-Business-Service-Token finns. Dokumentera att token gäller i ett år och vem som ansvarar för förnyelsen; samma Apple Account som användes för den ursprungliga token måste användas vid förnyelsen. Att återställa integrationen tar bort token, Apple Business-enheter och -profiler i Sophos Mobile och är ingen ofarlig återställningsväg. Utan dessa underlag ges inget klartecken för denna väg; Apple Business är inte ett generellt krav för alla sätt att registrera Apple-enheter. Skapa eller återställ varken token eller profiler i denna grundläggande tenantprocess.

Endast om Android Enterprise väljs: Android-/Google-ansvarig ska före den första Android-piloten styrka rätt MDM-licens, Android Enterprise-hanteringsläge, organisationsregistrering och anslutning av rätt Google-företagskonto till Sophos Mobile. Valet av läge ändrar vilka policytyper som är tillgängliga, men registrerar inte organisationen. Kontrollera faktiskt registrerings- och enrollmentläge samt varifrån de hanterade Google-kontona för testanvändarna kommer och om de är klara: beroende på konfiguration hanterar Sophos Mobile kontona, eller så måste användarna redan finnas i Google Workspace/Cloud Identity. Endast om organisationen registrerades i läget managed Google domain före den 9 april 2024 och alternativet Use managed Google domain device enrollment är avaktiverat kontrollerar Sophos Mobile vid SSP-registrering om det redan finns ett hanterat Google-konto vars adress består av delen före @ i användarens e-postadress i Sophos Fusion, följt av @ och organisationens hanterade Google-domän. Om kontot saknas skapar Sophos Mobile det, men hanterar inte dess fortsatta livscykel. Det hanterade användarkontot är varken Google-företagskontot som används för Android Enterprise-registreringen eller automatiskt ett konto med behörighet att låsa upp FRP; kontrollera identitetskopplingen och vägen för kontoåterställning separat före piloten. Kontrollera att policyn passar vald enhetstyp; vid SSP-registrering ska det tilldelade registreringspaketet med Android Enterprise-uppgiftsbunt (Enroll och Assign policy) samt godkännande i Managed Google Play av appen Sophos Mobile Control App för automatiska uppdateringar granskas. Kontrollera att den konkreta registreringsvägen passar läget; fullständigt hanterade Android-enheter får registreras endast i okonfigurerat skick eller efter godkänd fabriksåterställning. Om en redan använd enhet ska återställas för detta måste enhetsansvarig i förväg kontrollera faktisk status för Factory Reset Protection (FRP), avsedd återställningsmetod och godkänd väg för upplåsning eller kontoåterställning. Säkerställ att organisationen har åtkomst till de Google-konton som har behörighet att låsa upp FRP på just den enheten; kontot för Android Enterprise-registrering eller användarkontot är inte automatiskt ett FRP-upplåsningskonto. Beroende på återställningsmetod kan FRP kräva kontoinloggning efter återställningen. Skriv inte inloggningsuppgifter i pilotdokumentationen. Denna kontroll gäller planerade återställningar av fullständigt hanterade Android-enheter, inte arbetsprofiler eller Apple-enheter generellt. Utför inte Google Enterprise-registrering, kontomigrering eller enhetsåterställning som ett sidosteg i denna grundprocess.

Dokumentera den planerade pilotkonfigurationen under Setup > Self Service Portal före en inbjudan: tillåtna enhetstyper, ägandeform, lämplig enhetsgrupp och registreringspaket samt tillåtna självbetjäningsåtgärder. Det maximala antalet enheter begränsar antalet enheter per användare, inte antalet pilotanvändare eller konfigurationens räckvidd. Avgränsa pilotgruppen separat genom den faktiska användar-/grupptilldelningen. Före varje ändring i en delad SSP-konfiguration: kontrollera och dokumentera den gällande Default-konfigurationen (reservvalet när ingen mer specifik tilldelning finns), alla grupper som matchar pilot- och andra användare och gruppernas prioritet, samt tillåtna åtgärder och följderna för redan registrerade enheter. Innan något skrivs till delade SSP-inställningar ska en oberoende behörig person separat godkänna den konkreta ändringen och dess räckvidd; dokumentera de tidigare inställningarna inklusive Default, grupper, prioritet, åtgärder och plattformstilldelning samt återställningsvägen. Utan detta godkännande ska konfigurationen lämnas oförändrad. Efter Save, men före inbjudningar eller registrering, ska den faktiskt gällande tilldelningen för identiteter inom och utanför piloten, inklusive Default och medlemskap i flera grupper, samt följderna för redan registrerade enheter och deras SSP-åtgärder kontrolleras och dokumenteras. Vid oväntad räckvidd ska ytterligare ändringar och inbjudningar stoppas, tidigare inställningar återställas och den gällande tilldelningen och enhetsföljderna kontrolleras på nytt. Om effekten inte säkert kan återtas ges inget Go; eskalera till ansvariga. Detta godkännande för att skriva är skilt från det senare Go-beslutet för pilotregistrering. En pilotkonfiguration som verkar snäv kan via Default eller medlemskap i flera grupper påverka andra användare. Endast om den godkända pilotvägen kräver samtycke till SSP-användarvillkor: SSP-/registreringsansvarig kontrollerar för testidentiteten och vald plattform att gällande Enrollment texts och det plattformsspecifika fältet Terms of use har godkänt innehåll. Om Terms of use är tomt visas ingen sådan text före registreringen och inget samtycke till den inhämtas; då ges inget klartecken för denna SSP-samtyckesväg. Om samtycke i stället inhämtas genom en separat godkänd process ska den vägen dokumenteras; SSP-villkor är inte ett generellt krav för andra registreringsvägar. Policyer, regelefterlevnad och registreringspaket är separata förutsättningar, inte automatiska följder av grundinställningarna.

Godkännandekontroll före varje pilotregistrering: En andra behörig person kontrollerar i den faktiska tenanten utgåva/licens och tillgänglig Mobile-licensomfattning för namngivna pilotanvändare respektive enheter utan användarkoppling, roller, verifierad region och nätverksgodkännande; för SSP-vägar den faktiskt gällande SSP-tilldelningen för både testidentiteten och en identitet utanför piloten inklusive Default/prioritet och gruppräckvidd i stället för enhetsgräns per användare; för användarlösa Dedicated Devices i stället den separat godkända registreringsvägen för fullständigt hanterade Android-enheter och enhetstilldelningen; dessutom plattform/hanteringsläge, samtycke, policy/paket och ansvar för backup, återställning och avregistrering. Kräver den godkända vägen SSP-samtycke ingår gällande Enrollment texts, ett plattformsspecifikt Terms of use-fält med godkänd text och testidentiteten i Go/No-go-beslutet; annars ska den separata godkända samtyckesprocessen dokumenteras. För valda Apple-MDM-vägar krävs underlag från APNs-ansvarig; om Apple Business eller Android Enterprise väljs begärs dessutom ovanstående vägspecifika underlag från respektive ansvarig. Om fabriksåterställning av en fullständigt hanterad Android-enhet planeras krävs uttryckligen förhandsverifierad FRP-status, avsedd återställningsmetod och godkänd upplåsnings-/kontoåterställningsväg för de FRP-konton som faktiskt har behörighet. Vägar som inte valts får inte bli generella hinder. Den andra personen dokumenterar ett uttryckligt Go/No-go för namngivna testkonton och enheter. Saknas underlag eller ges No-go: ingen inbjudan, ingen registrering, ingen enhetsändring; återför ärendet till ansvariga. Denna dokumentationsguide ger inte i sig ett godkännande och bevisar inte att någon tenant eller enhet har testats.

Först efter separat Go genomför registreringsansvarig för användaranknutna vägar ett begränsat pilotförsök med en särskilt skapad, namngiven testanvändare per godkänd plattform och dokumenterar registreringsidentitet, registrering, tilldelad grupp, målpolicy, uppgiftsstatus, IT-kontakt och mottagna meddelanden på den enheten samt återställningsvägen. Endast vid separat godkänd pilot med användarlös Dedicated Device kontrollerar ansvarig för enheten/registreringen i stället på den namngivna testenheten vald hanterings- och registreringsväg utan användartilldelning, registreringsidentitet respektive enhetstilldelning, målpolicy inklusive kioskkonfiguration, uppgiftsstatus och dokumenterad återställnings-/avregistreringsväg; förutsätt inte en testanvändare eller träff i SSP-grupper för den vägen. Endast om den godkända vägen kräver SSP-samtycke ska visningen av godkända Terms of use före registreringen och testidentitetens godkännande också observeras och dokumenteras; vid separat samtyckesprocess används dess godkända bevisväg. Sophos rekommenderar testet före inbjudningar till riktiga användare; godkännandet här ersätter varken dessa observationer eller ett senare utrullningsbeslut. Beroende på läge kan registrering ske via Add-device-guiden, manuell registrering, Self Service Portal eller plattformsspecifik automatiserad registrering; här påstås inte att en enda klickväg gäller alla enheter.

4. Återställning och överlämning

Dokumentera ursprungliga värden och behörigheter före piloten. Personal, IT contact och Email configuration kan återställas genom att ange tidigare värde och välja Save igen; verifiera därefter med berört konto, på testenheten eller med ett nytt testmeddelande. Rätta en alltför omfattande roll i Fusion med hjälp av ett administratörskonto som fortfarande fungerar och logga in igen med det berörda kontot. Återställ pilotgrupps- och SSP-konfigurationer först efter att faktisk tilldelning kontrollerats; att bara ta bort en konfiguration är inget bevis för att redan registrerade enheter har avregistrerats eller att ytterligare registreringar har stoppats.

Lämna uttryckligen över enhetsavregistrering till enhets-/registreringsansvarig: Vid en pilot med dedikerade enheter utan användare ska ansvarig även stoppa den godkända registreringsvägen, kontrollera att inga fler enheter kan registreras där och inventera redan registrerade testenheter; det räcker inte att spärra inbjudningar till användare eller grupper. Vid avbrott eller efter piloten ska ansvarig först stoppa nya inbjudningar och registreringsvägar för de användare och grupper som faktiskt berörs och verifiera att stoppet fungerar. Lämna sedan över en inventering av redan registrerade testenheter med plattform, läge, ägandeform och tilldelning. Enhetsansvarig beslutar för varje enhet om avregistrering, användar-/enhetstilldelning och uppföljningskontroll och dokumenterar resultatet. Unenroll är inte en återställning av inställningar: beroende på plattform tas hanterade profiler, appar, certifikat, konton och data bort; fullständigt hanterade Android Enterprise-enheter måste fabriksåterställas vid avregistrering. Före fabriksåterställning av en fullständigt hanterad Android-enhet ska enhetsansvarig även styrka FRP-status, avsedd återställningsmetod och godkänd upplåsnings-/kontoåterställningsväg för de FRP-konton som faktiskt har behörighet; återställ inte utan dessa underlag. Kontrollera enhetsläge, backup, ägandeform, godkännande och officiellt dokumenterade plattformsspecifika följder före faktisk avregistrering. Radering är inte en ofarlig inventariestädning: Avregistrera först enligt plattformens krav och verifiera resultatet; radera därefter en post som inte längre är hanterad. Om en fortfarande registrerad enhet i stället raderas, avregistreras den vid nästa synkronisering; radering av en fullständigt hanterad Android Enterprise-enhet utlöser en fabriksåterställning och kan förstöra data. Kontrollera före radering vilka enhetsuppgifter och lagrade data som behövs; en borttagen konsolrad bevisar varken att enheten har avregistrerats eller att data kan återställas. Radering av posten för en registrerad Windows-enhet avregistrerar däremot inte enheten automatiskt; kontrollera verklig status på enheten. För Apple-enheter ska Apple-/enhetsansvarig kontrollera status för Activation Lock och ansvarig väg för återaktivering före återställning, avregistrering eller frigivning; återställ eller ta inte bort APNs-certifikat eller Apple Business-integrationen som en påstådd avregistreringsåtgärd. Appalternativet Unenroll och SSP-åtgärden Unenroll device är skilda reglage; att dölja det ena blockerar inte automatiskt det andra. Beskriv varken enhetsradering, återkallad licens eller återställda tenantinställningar som en reversibel avstängningsmetod.

Vid driftöverlämningen ska en andra behörig person kontrollera tenant och Mobile-licens, delegerade rollers faktiska behörigheter, sparade grundinställningar, faktisk SSP-räckvidd samt överlämningen av godkännande-/stopprocess och enhetsavregistrering. EAS-proxy och Exchange-e-postflöde förblir den separata EAS-ansvariges område; LDAP-/katalogsynkronisering tillhör identitetsansvarig. Utan befintliga godkända rutiner för enheter/registrering och EAS/LDAP får dessa arbetsflöden varken implicit godkännas eller förses med döda hänvisningar. Den här informationsvägledningen intygar inte att någon tenant eller pilotenhet har testats; faktiska enhetsändringar kräver fortfarande separat godkännande.