Configurare il tenant Sophos Mobile e affidarne la gestione

Sophos Mobile viene configurato in un tenant Sophos Fusion esistente. Questa procedura si conclude con la preparazione e la decisione sull’autorizzazione di un progetto pilota limitato, non con un enrollment già eseguito né con una distribuzione di massa in produzione. Mobile Device Management (MDM) e Mobile Threat Defense hanno licenze e funzionalità distinte. Prima di apportare modifiche, annotare tenant, edizione, ruolo, piattaforma dei dispositivi, modello di proprietà e procedura di ripristino. L’attivazione generale del tenant e la protezione degli amministratori a livello trasversale sono trattate in Attivare in sicurezza il tenant Sophos Fusion.

1. Chiarire prima licenza e autorizzazioni

Nel tenant Fusion corretto, aprire Profile icon > Licensing e confrontare prodotto, edizione e disponibilità con l’incarico ricevuto. Sophos Mobile Device Management (in precedenza Central Mobile Standard) include l’MDM per Android, iPhone/iPad, Mac e Windows; Sophos Mobile Threat Defense (in precedenza Intercept X for Mobile) riguarda la gestione di Intercept X for Mobile e Sophos Chrome Security. Sophos Mobile (in precedenza Central Mobile Advanced) comprende entrambi. La presenza dell’interfaccia Mobile non dimostra che sia disponibile una specifica licenza MDM. Non riscattare una licenza sulla base di supposizioni: attivazione, rinnovo e conseguenze sulle licenze rientrano nella procedura di gestione delle licenze Fusion; verificare prima lì tenant e incarico.

Documentare separatamente la regione: Nell’account Fusion interessato, aprire My Products > Mobile, leggere la regione nell’URL del browser dopo smc-user-if-cloudstation- e annotarla per l’approvazione dell’infrastruttura e della rete. Gli endpoint dei server Sophos Mobile dipendono dalla regione; il referente di rete confronta le connessioni necessarie per la regione e la piattaforma effettive con la documentazione di rete Sophos aggiornata. Non dedurre la regione dalla sede o dalla lingua dell’azienda, né dal fuso orario personale dell’amministratore. Senza una regione documentata e le necessarie autorizzazioni di rete, nessun Go per il percorso pilota interessato.

Per la configurazione iniziale usare un Admin o Super Admin autorizzato. I ruoli Fusion vengono mappati in Mobile come segue:

Definire in Fusion persone responsabili e ruoli secondo Assegnare correttamente i ruoli amministrativi, poi verificare in Mobile, con account separati Help Desk e Read-only, quali menu e azioni siano effettivamente accessibili. Non declassare l’unico account amministrativo funzionante. Nella documentazione MDM Helpdesk può anche registrare dispositivi e installare app. Le funzioni critiche, come la configurazione delle impostazioni e la creazione, modifica ed eliminazione di dispositivi, gruppi di dispositivi e pacchetti, sono escluse per questo ruolo Mobile. La descrizione dei ruoli Threat Defense indica come azioni consentite per Helpdesk soltanto attività di supporto generali; anche in questa edizione le funzioni critiche citate sono espressamente escluse. Non dedurne alcuna autorizzazione universale dell’Helpdesk all’enrollment per tutte le edizioni. Il collegamento a directory/LDAP e la sincronizzazione delle identità richiedono un processo separato di approvazione e ripristino: non sono un effetto collaterale dell’assegnazione dei ruoli.

2. Configurare le impostazioni di base senza modificare i dispositivi

Le impostazioni personali di visualizzazione in Sophos Mobile Admin si applicano solo all’account amministrativo con cui si è effettuato l’accesso. Sophos include tra queste anche la lingua dell’interfaccia utente, che è configurabile, ma nella pagina dedicata alle impostazioni personali non descrive un selettore della lingua, né la sua posizione o il suo utilizzo. La lingua dell’interfaccia va distinta dalla lingua delle e-mail in uscita descritta di seguito; ciò non dimostra che la lingua di Fusion venga adottata automaticamente.

In Sophos Mobile Admin > Setup > General, distinguere l’ambito di ciascuna impostazione:

1. Personal: impostare fuso orario, unità di misura, righe delle tabelle, Expert mode e piattaforme visualizzate per l’account amministrativo connesso, quindi selezionare Save. Le singole impostazioni hanno questi effetti:

   • Time zone definisce il fuso orario in cui vengono visualizzate date e ore.
   • Unit system determina il sistema di misura per i valori di lunghezza: Metric oppure Imperial.
   • Lines per page in tables definisce il numero massimo di voci visualizzate per pagina nelle tabelle.
   • Se Expert mode è attivo, la pagina Show device include la scheda Custom properties, con le proprietà personalizzate del dispositivo, e la scheda Internal properties, con ulteriori proprietà comunicate dal dispositivo. Diverse pagine di configurazione dei criteri mostrano inoltre la sezione Extra settings, in cui è possibile configurare impostazioni facoltative.

   Le piattaforme abilitate determinano la visibilità delle pagine e impostazioni pertinenti; non attivano una licenza e non registrano dispositivi. Dopo il salvataggio, verificare che la piattaforma prevista compaia nella navigazione. Se mancano delle viste, controllare prima il filtro personale delle piattaforme e il ruolo; se necessario, ripristinare la selezione precedente.

2. IT contact: inserire un indirizzo di assistenza monitorato e un contatto reperibile, selezionare Save e verificare il testo su un dispositivo di test destinato allo scopo solo dopo un’approvazione separata del pilot. Questi dati compaiono sui dispositivi degli utenti. Non inserire numeri privati o dati personali non autorizzati. Salvare eventuali correzioni nella stessa scheda e ricontrollarle sul dispositivo di test.

3. Email configuration: scegliere la lingua delle e-mail inviate da Sophos Mobile e selezionare Save. Non si tratta della configurazione di un relay SMTP, di una casella Exchange o di un proxy EAS. Verificare durante il pilot un evento che produca effettivamente un messaggio Mobile: Save da solo non conferma l’avvenuta consegna. Se la lingua è errata, ripristinare il valore precedente e valutare un ulteriore messaggio di prova.

L’area Setup contiene anche opzioni relative a piattaforme, protezione dei dati e integrazioni. Non attivare indiscriminatamente certificati APNs, Android Enterprise, sincronizzazione dei dispositivi, autorizzazioni per i dati personali o EAS. Il fuso orario personale non è il fuso orario globale del tenant; il contatto IT e la lingua delle e-mail fanno invece parte della configurazione generale di Mobile. La guida introduttiva indica inoltre il Fusion Self Service Portal come fase di configurazione distinta.

3. Preparare soltanto dispositivi ed enrollment

Per MDM, chiarire innanzitutto proprietà (aziendale o privata), piattaforma di destinazione, modalità di gestione, gruppo di utenti interessato, numero di dispositivi e testo relativo a consenso e protezione dei dati. Per Android, approvare separatamente la modalità Android Enterprise e i relativi prerequisiti; per iPhone, iPad e Mac, approvare prima dell’enrollment il certificato APNs necessario a Sophos Mobile, con relativo responsabile, validità annuale e rinnovo. Per un rinnovo successivo, il responsabile Apple deve dimostrare di usare l’Apple Account originale e il certificato corretto in base al Topic APNs: un certificato nuovo o errato con un Topic diverso può interrompere la gestione di dispositivi già registrati e richiedere un nuovo enrollment. Non rimuovere il certificato APNs come procedura di ripristino per dispositivi esistenti.

Se manca il certificato e in questo tenant non ne è mai stato caricato uno, affidare la prima creazione del certificato APNs al responsabile APNs; creazione e caricamento richiedono un’approvazione separata e non vanno eseguiti incidentalmente durante questa preparazione. Se esiste già un certificato, il responsabile APNs si occupa della verifica dell’identità e del rinnovo. Per il passaggio di consegne, richiedere riscontri dei dettagli visualizzati del certificato, della data di scadenza, dell’Apple Account responsabile e della responsabilità del rinnovo; non copiare credenziali nel verbale di verifica e non equiparare un caricamento al collaudo del pilot. L’Apple-Business-Service-Token è separato. Il manuale Threat Defense non presenta lo stesso albero di configurazione Apple/EAS dell’edizione MDM: impostazioni di base comuni non garantiscono funzioni identiche per i dispositivi.

Solo se si sceglie l’enrollment automatizzato tramite Apple Business: Il responsabile Apple/enrollment deve documentare un’organizzazione registrata in Apple Business (in precedenza Apple Business Manager), un account Apple Business autorizzato, un certificato APNs configurato in Sophos Mobile e la connessione separata mediante Apple-Business-Service-Token. Annotare la validità annuale del token e il responsabile del rinnovo; per rinnovarlo occorre usare lo stesso Apple Account utilizzato per il token originale. Il reset dell’integrazione elimina in Sophos Mobile token, dispositivi Apple Business e profili e non costituisce una procedura di ripristino innocua. Senza queste prove, nessun Go per questo percorso; Apple Business non è un requisito generale di tutti i percorsi di enrollment Apple. In questa procedura di base del tenant non creare né reimpostare token o profili.

Solo se si sceglie Android Enterprise: Prima del primo pilot Android, il responsabile Android/Google deve documentare la licenza MDM appropriata, la modalità di gestione Android Enterprise, la registrazione dell’organizzazione e il collegamento dell’account Google aziendale corretto a Sophos Mobile. La sola scelta della modalità cambia i tipi di criteri disponibili, ma non registra alcuna organizzazione. Verificare la modalità di registrazione e di enrollment effettivamente disponibile, nonché la provenienza e la disponibilità degli account Google gestiti per gli utenti di test: a seconda della configurazione, Sophos Mobile gestisce gli account oppure gli utenti devono già esistere in Google Workspace/Cloud Identity; solo per le organizzazioni registrate in modalità managed Google domain prima del 9 aprile 2024 e con l’opzione Use managed Google domain device enrollment disattivata, durante l’enrollment SSP Sophos Mobile verifica se esiste già un account Google gestito derivato dalla parte prima di @ dell’indirizzo e-mail dell’utente in Sophos Fusion e dal dominio Google gestito dell’organizzazione e, in caso contrario, lo crea senza gestirne il ciclo di vita successivo. Questo account utente gestito non coincide con l’account Google aziendale per la registrazione Android Enterprise né è automaticamente un account di sblocco FRP; verificare separatamente la corrispondenza delle identità e la procedura di recupero dell’account prima del pilot. Verificare un criterio adatto al tipo di dispositivo scelto; per l’enrollment SSP, approvare il pacchetto di enrollment assegnato con l’Android-Enterprise-Task-Bundle (Enroll e Assign policy) e l’autorizzazione della Sophos Mobile Control App in Managed Google Play per gli aggiornamenti automatici. Verificare che il percorso concreto di enrollment sia compatibile con la modalità: i dispositivi Android completamente gestiti possono essere registrati solo se non configurati o dopo un ripristino delle impostazioni di fabbrica approvato. Se occorre ripristinare un dispositivo già in uso, il responsabile del dispositivo deve verificare prima lo stato effettivo della Factory Reset Protection (FRP), la procedura di reset prevista e il percorso approvato per lo sblocco o il recupero dell’account. Assicurare a livello organizzativo l’accesso agli account Google autorizzati per FRP su quel dispositivo: l’account usato per registrare Android Enterprise o l’account dell’utente non è automaticamente un account di sblocco FRP. In base alla procedura di reset, FRP può richiedere l’accesso a un account dopo il ripristino. Non annotare le credenziali nella documentazione del pilot. Questo controllo riguarda i reset pianificati dei dispositivi Android completamente gestiti, non indiscriminatamente i profili di lavoro o i dispositivi Apple. Non eseguire incidentalmente in questa procedura di base la registrazione Google Enterprise, la migrazione di account o il reset di dispositivi.

Prima di inviare un invito, registrare in Setup > Self Service Portal la configurazione pilota prevista: tipi di dispositivi ammessi, modello di proprietà, gruppo di dispositivi e pacchetto di enrollment appropriati, nonché azioni self-service consentite. Il numero massimo di dispositivi limita i dispositivi per utente, non il numero di utenti pilota né la portata della configurazione. Limitare il gruppo pilota separatamente mediante l’effettiva assegnazione di utenti e gruppi. Prima di modificare una configurazione SSP condivisa, verificare e documentare la configurazione Default effettiva (fallback in assenza di un’assegnazione più specifica), tutti i gruppi corrispondenti agli utenti pilota e non pilota e le loro priorità, oltre alle azioni consentite e agli effetti sui dispositivi già registrati. Prima di ogni scrittura nelle impostazioni SSP condivise, ottenere da una seconda persona indipendente e autorizzata un’approvazione specifica della modifica e della sua portata; documentare le impostazioni precedenti, comprese Default, gruppi, priorità, azioni e assegnazione alle piattaforme, insieme al percorso di ripristino. Senza questa approvazione, lasciare invariata la configurazione. Dopo Save, prima di qualsiasi invito o enrollment, verificare e documentare l’assegnazione effettiva per identità pilota e non pilota, comprese Default e appartenenze a più gruppi, nonché gli effetti sui dispositivi già registrati e sulle relative azioni SSP. Se la portata è imprevista, interrompere ulteriori modifiche e inviti, ripristinare le impostazioni precedenti e verificare di nuovo assegnazioni effettive ed effetti sui dispositivi; se non è possibile annullare gli effetti in sicurezza, nessun Go e coinvolgere i responsabili competenti. Questa approvazione alla scrittura è distinta dal successivo Go per l’enrollment pilota. Una configurazione pilota apparentemente circoscritta può coinvolgere altri utenti per effetto di Default o dell’appartenenza a più gruppi. Solo se il percorso pilota approvato richiede il consenso alle condizioni d’uso SSP: Il responsabile SSP/enrollment verifica per l’identità di test e la piattaforma scelta che gli Enrollment texts effettivi e il campo Terms of use specifico della piattaforma contengano il testo approvato. Se Terms of use è vuoto, prima dell’enrollment non viene mostrato alcun testo di questo tipo né raccolto il relativo consenso: in tal caso, nessun Go per questo percorso di consenso SSP. Se il consenso viene invece raccolto tramite un processo separato approvato, documentare tale percorso; le condizioni d’uso SSP non sono un requisito generale degli altri percorsi di enrollment. Criteri, compliance e pacchetti di enrollment sono prerequisiti distinti, non conseguenze automatiche delle impostazioni di base.

Gate di approvazione prima di ogni enrollment pilota: Una seconda persona autorizzata verifica nel tenant effettivo edizione/licenza e disponibilità di licenze Mobile per gli utenti pilota indicati o i dispositivi senza utente, ruoli, regione documentata e autorizzazione di rete; per i percorsi SSP, l’assegnazione SSP effettiva per l’identità di test e per un’identità non pilota, inclusi Default/priorità e portata dei gruppi anziché il limite dei dispositivi per utente; per i Dedicated Devices senza utente, invece, il percorso di enrollment Android completamente gestito approvato separatamente e l’assegnazione del dispositivo; inoltre piattaforma/modalità di gestione, consenso, criteri/pacchetto e responsabilità per backup, reset e offboarding. Se il percorso approvato richiede il consenso SSP, il Go/No-go comprende gli Enrollment texts effettivi, il campo Terms of use specifico della piattaforma compilato con testo approvato e l’identità di test; altrimenti occorre documentare il processo separato di consenso approvato. Per i percorsi Apple MDM scelti è necessaria la prova fornita dal responsabile APNs; se si sceglie Apple Business o Android Enterprise, richiedere inoltre le prove dei rispettivi responsabili specifiche del percorso indicate sopra. Se è previsto il ripristino delle impostazioni di fabbrica di un dispositivo Android completamente gestito, sono espressamente richiesti lo stato FRP documentato in anticipo, la procedura di reset prevista e il percorso approvato di sblocco o recupero per gli account effettivamente autorizzati per FRP. I percorsi non scelti non costituiscono blocchi generali. La seconda persona documenta un Go/No-go esplicito per gli account e i dispositivi di test indicati. In mancanza di prove o in caso di No-go: nessun invito, nessun enrollment, nessuna modifica ai dispositivi; rinviare ai responsabili competenti. Questa guida documentale non concede di per sé un’autorizzazione e non attesta test sul tenant o sui dispositivi.

Solo dopo un Go separato, per i percorsi associati a un utente il responsabile dell’enrollment esegue il pilot limitato con un utente di test nominativo creato appositamente per ciascuna piattaforma approvata e documenta su quel dispositivo l’identità di enrollment, la registrazione, il gruppo assegnato, il criterio di destinazione, lo stato delle attività, il contatto IT, la ricezione dei messaggi e il percorso di ripristino. Solo per un pilot separatamente approvato di Dedicated Devices senza utente, il responsabile dei dispositivi/enrollment verifica invece sul dispositivo di test indicato il percorso di gestione ed enrollment scelto senza assegnazione a un utente, l’identità di enrollment o l’assegnazione del dispositivo, il criterio di destinazione con la configurazione kiosk, lo stato delle attività e il percorso documentato di ripristino/offboarding; non presupporre a tale scopo un utente di test né una corrispondenza con un gruppo SSP. Solo se il percorso approvato richiede il consenso SSP, osservare e documentare anche la visualizzazione delle Terms of use approvate prima dell’enrollment e la loro accettazione da parte dell’identità di test; nel caso di un processo di consenso separato, usare il relativo metodo approvato di documentazione. Sophos raccomanda di eseguire il test prima di invitare utenti reali; l’approvazione qui descritta non sostituisce questa verifica né la successiva decisione sulla distribuzione. A seconda della modalità, i percorsi di registrazione comprendono l’assistente Add-device, l’enrollment manuale, il Self Service Portal o l’enrollment automatizzato specifico della piattaforma; qui non si presuppone una sequenza di clic universale per tutti i dispositivi.

4. Ripristino e passaggio di consegne

Prima del pilot, documentare valori e autorizzazioni originali. Personal, IT contact ed Email configuration possono essere ripristinati reinserendo il valore precedente e selezionando nuovamente Save; verificare poi nell’account interessato, sul dispositivo di test o mediante un nuovo messaggio di prova, secondo il caso. Correggere un ruolo Fusion assegnato per errore con privilegi troppo ampi usando un amministratore ancora disponibile, poi effettuare nuovamente l’accesso con l’account interessato. Ritirare le configurazioni dei gruppi pilota e dell’SSP solo dopo aver verificato le assegnazioni effettive; la semplice rimozione di una configurazione non dimostra che i dispositivi già registrati siano stati deregistrati o che ulteriori enrollment siano stati bloccati.

Affidare esplicitamente l’offboarding dei dispositivi al responsabile dei dispositivi/enrollment: Per un pilot di dispositivi dedicati senza utente, il responsabile deve anche interrompere il percorso di enrollment autorizzato, verificare che non sia possibile registrare altri dispositivi tramite tale percorso e censire i dispositivi di test già registrati; bloccare gli inviti a utenti o gruppi non interrompe da solo questo percorso. In caso di interruzione o conclusione del pilot, far prima bloccare al responsabile nuovi inviti e percorsi di enrollment nell’ambito di utenti/gruppi effettivamente interessato e verificarne l’efficacia; consegnare poi l’inventario dei dispositivi di test già registrati con piattaforma, modalità, proprietà e assegnazione. Il responsabile dei dispositivi decide per ciascun dispositivo la deregistrazione, l’assegnazione a utenti/dispositivi e la verifica successiva, documentandone gli esiti. Unenroll non è un rollback delle impostazioni: a seconda della piattaforma, vengono rimossi profili, app, certificati, account e dati gestiti; per annullare l’enrollment dei dispositivi Android Enterprise completamente gestiti è necessario un ripristino delle impostazioni di fabbrica. Prima di ripristinare un dispositivo Android completamente gestito, far documentare al responsabile del dispositivo anche lo stato FRP, la procedura di reset prevista e il percorso approvato di sblocco o recupero per gli account effettivamente autorizzati per FRP; senza tale prova, non eseguire il reset. Prima di un unenrollment effettivo, verificare modalità del dispositivo, backup, proprietà, autorizzazione e conseguenze ufficiali specifiche della piattaforma. L’eliminazione non è una semplice pulizia dell’inventario: Prima annullare l’enrollment secondo la procedura specifica della piattaforma e verificare l’esito; solo dopo eliminare una voce relativa a un dispositivo non più gestito. Se invece si elimina un dispositivo ancora registrato, il suo enrollment viene annullato alla sincronizzazione successiva; eliminare un dispositivo Android Enterprise completamente gestito provoca un ripristino delle impostazioni di fabbrica e può distruggere dati. Prima di eliminare una voce, verificare quali informazioni sul dispositivo e quali dati conservati servano ancora: la scomparsa della riga dalla console non dimostra né l’avvenuta deregistrazione del dispositivo né il recupero dei dati. L’eliminazione della voce di un dispositivo Windows registrato, invece, non ne annulla automaticamente l’enrollment: verificarne lo stato sul dispositivo. Per i dispositivi Apple, prima di reset, deregistrazione o rilascio, far verificare al responsabile Apple/del dispositivo anche lo stato di Activation Lock e la procedura di riattivazione pertinente; non reimpostare né rimuovere un certificato APNs o un’integrazione Apple Business come presunto metodo di offboarding. L’opzione dell’app Unenroll e l’azione SSP Unenroll device sono controlli distinti; nasconderne uno non blocca automaticamente l’altro. Non presentare l’eliminazione dei dispositivi, la revoca della licenza o il ripristino delle impostazioni del tenant come procedure di disattivazione reversibili.

Per il passaggio alla gestione operativa, una seconda persona autorizzata fa ricontrollare tenant e licenza Mobile, funzionalità dei ruoli delegati, impostazioni di base salvate, portata effettiva dell’SSP e passaggio di consegne relativo ad approvazione/blocco e offboarding dei dispositivi. Proxy EAS e flusso di posta Exchange restano sotto la responsabilità del referente EAS separato; la sincronizzazione LDAP/directory sotto quella del referente per le identità. Senza runbook approvati e disponibili per dispositivi/enrollment e per EAS/LDAP, non concedere implicitamente l’autorizzazione a tali procedure né inserire riferimenti non funzionanti. Questa guida informativa non certifica che un tenant o un dispositivo pilota sia stato testato; le modifiche effettive ai dispositivi richiedono comunque un’approvazione separata.