Sophos Mobile: migrare dalla modalità Amministratore dispositivo Android ad Android Enterprise

Questo articolo aiuta a definire il percorso di migrazione e le verifiche necessarie. Non autorizza a eseguire un ripristino in produzione. Sophos considera la modalità Amministratore dispositivo obsoleta: in Sophos Mobile è disponibile solo per Android 9 o versioni precedenti; con Android 10 e successivi non è possibile registrare dispositivi in questa modalità. Questo non significa che tutte le funzionalità di Android Device Policy Manager siano state eliminate in generale e non è un invito a continuare a utilizzare Android 9. Non registrare nuovi dispositivi nella vecchia modalità. La migrazione descritta di seguito presuppone un ambiente Android Enterprise già predisposto e configurato.

Stabilire innanzitutto proprietà e modalità di destinazione

Prima di qualsiasi modifica, confrontare la modalità di gestione effettiva, l’identità del dispositivo, la proprietà, la versione Android, l’utente assegnato, le policy, le applicazioni, la raggiungibilità e l’ultimo stato del dispositivo sia sul dispositivo sia nel tenant Sophos corretto.

Preparare la nuova registrazione prima dell’intervento

Questa verifica va eseguita mentre il vecchio dispositivo è ancora gestito. Non avvia né il ripristino né la disiscrizione. Registrare nel verbale di migrazione le seguenti informazioni per la modalità di destinazione scelta:

In Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise, verificare l’Android Enterprise mode esistente, i dettagli dell’account visualizzati e lo stato di Use managed Google domain device enrollment. Riutilizzare la registrazione esistente dell’organizzazione, senza eseguire nuovamente Register account né sostituire il collegamento a Google. Se il collegamento manca o non è chiaro, chiarirlo prima seguendo la sezione Collegare l’organizzazione a Google.
Predisporre una Android Enterprise device policy per il dispositivo aziendale e una Android Enterprise work profile policy per quello personale. Annotare i nomi della policy di destinazione e del relativo pacchetto di operazioni. Il pacchetto per ciascun tipo di dispositivo deve contenere almeno Enroll e Assign policy, con quella specifica policy. Una vecchia policy Amministratore dispositivo non può sostituirla.
Se si utilizza il Self Service Portal, aprire in Setup > Self Service Portal la configurazione effettiva per l’utente. Nelle impostazioni della piattaforma Android, Enrollment package deve indicare il pacchetto di operazioni predisposto. Verificare Owner, il Device group di destinazione, la priorità dei gruppi e la quota residua di dispositivi. Controllare una configurazione esistente adatta, senza crearne indiscriminatamente una nuova né modificare Default. La preparazione è descritta in Preparare policy, pacchetto e identità dell’utente.
Verificare l’approvazione di Sophos Mobile Control in Managed Google Play. Senza questa approvazione, l’app gestita non si aggiorna automaticamente. Se la registrazione dei dispositivi nel dominio è attivata, gli utenti previsti devono essere presenti nel dominio Google gestito. Questa modalità di registrazione richiede Mobile Control 9.8 o versioni successive; per i profili di lavoro devono inoltre essere installati tutti gli aggiornamenti disponibili del sistema operativo e delle app. Per un’operazione avviata da Sophos Mobile, l’indirizzo e-mail assegnato deve corrispondere esattamente a quello usato per l’accesso a Google.
Scegliere un percorso di registrazione consentito nella modalità attuale dell’organizzazione e preparare in anticipo, con il reparto IT competente, le istruzioni da fornire all’utente descritte di seguito. Per un’organizzazione registrata prima del 9 aprile 2024 in modalità managed-Google-domain, senza la registrazione dei dispositivi nel dominio attivata, la registrazione da parte dell’amministratore non è disponibile; in questo caso predisporre il percorso SSP consentito. Non attivare l’opzione come semplice passaggio della migrazione. Le modifiche al collegamento dell’organizzazione o alla modalità di registrazione richiedono un’autorizzazione separata.

Per un dispositivo aziendale con un utente assegnato, la guida Android Enterprise, alla voce “Progetto pilota con amministratore” descrive il percorso supportato tramite Devices > Add > Add device wizard, la selezione dell’utente, Platform: Android e il pacchetto di registrazione predisposto. Eseguire questo percorso solo dopo il ripristino delle impostazioni di fabbrica, autorizzato separatamente e confermato sul dispositivo. Se è necessario il SSP, usare la procedura SSP descritta nella guida. Le procedure tramite QR, zero-touch e senza utente sono alternative che richiedono una preparazione specifica, non passaggi obbligatori aggiuntivi.

Per un dispositivo di cui sia accertata la proprietà personale, predisporre in anticipo per l’utente la sezione Configurare il profilo di lavoro nella guida Android BYOD. La sezione illustra Owner: Personal, il pacchetto per il profilo di lavoro e la configurazione di Mobile Control sul dispositivo. Questa nuova registrazione inizia solo dopo la conferma della disiscrizione dalla vecchia modalità e la successiva eliminazione del corretto record precedente. Va inclusa anche la verifica della privacy e del consenso descritta in “Prima della registrazione”; la procedura BYOD non si applica ai dispositivi aziendali con profilo di lavoro.

Se manca uno di questi prerequisiti, fermarsi prima di procedere con uno dei due percorsi di migrazione. Prima di un intervento in produzione, verificare il percorso scelto su un dispositivo di test rappresentativo e autorizzato. Account predisposti, un pacchetto salvato o opzioni visibili nel portale non dimostrano ancora che la registrazione del dispositivo sia riuscita. Dopo la registrazione, controllare la modalità di gestione, l’utente assegnato, lo stato delle operazioni e la policy effettiva in Sophos Mobile e sul dispositivo.

Percorsi di migrazione documentati

Non confondere i due percorsi documentati:

Aziendale, finora in modalità Amministratore dispositivo → Android Enterprise: gestione completa del dispositivo. In Gerät anzeigen > Aktionen > Zurücksetzen il dispositivo viene ripristinato alle impostazioni di fabbrica; successivamente va registrato di nuovo. Sophos indica come possibili percorsi la procedura guidata «Gerät hinzufügen», il Sophos Fusion Self Service Portal e la registrazione tramite codice QR o zero-touch. Eseguire questo intervento solo dopo un’autorizzazione separata.
Personale, finora in modalità Amministratore dispositivo → Android Enterprise: gestione del profilo di lavoro. In Gerät anzeigen > Aktionen > Deregistrieren, poi Aktionen > Löschen; solo dopo registrare il nuovo profilo di lavoro. Sophos indica la procedura guidata «Gerät hinzufügen» o il Sophos Fusion Self Service Portal. Anche questo intervento richiede un’autorizzazione separata. Il ripristino delle impostazioni di fabbrica non è una fase standard per i dispositivi BYOD.

Queste etichette provengono dalla guida Sophos in tedesco del 22 settembre 2026; in una console impostata in inglese compaiono Show device > Actions > Wipe, Unenroll e Delete. Verificare in anticipo i menu effettivi, le autorizzazioni e i metodi di registrazione disponibili nel tenant di destinazione. Un Wipe in Sophos Fusion, uno Zurücksetzen in Mobile Admin e la rimozione di un profilo di lavoro già configurato non sono denominazioni o passaggi di migrazione intercambiabili. I dispositivi aziendali già configurati con un profilo di lavoro e le altre modalità richiedono una decisione distinta: non assegnarli automaticamente a uno dei due percorsi.

Fermarsi prima di qualsiasi azione distruttiva

Dispositivo aziendale: ottenere un’autorizzazione scritta per il ripristino delle impostazioni di fabbrica di questo specifico dispositivo; verificare dati locali, account aziendali, app, autenticazione, un backup utilizzabile e la possibilità di ripristino. Un ripristino pianificato distrugge i dati locali non salvati. Devono essere disponibili un metodo di nuova registrazione Android Enterprise effettivamente funzionante, connettività Wi-Fi o mobile, credenziali e autorizzazioni necessarie. Verificare preventivamente gli account Google e i blocchi successivi al ripristino in base al dispositivo e alla specifica modalità di ripristino. Sophos documenta la Factory Reset Protection per i dispositivi Android Enterprise completamente gestiti: ciò non significa che la stessa configurazione FRP controllasse già il ripristino del dispositivo nella vecchia modalità Amministratore dispositivo. Non promettere soluzioni per aggirare FRP.
Dispositivo personale: chiarire con l’utente il consenso, lo stato dei dati personali e aziendali e gli effetti della disiscrizione dalla vecchia modalità. La disiscrizione dalla vecchia modalità disattiva Sophos Mobile Control come amministratore del dispositivo, rimuove le credenziali di accesso al server e i dati ricevuti e reimposta Sophos Intercept X for Mobile. Prima confermare che la disiscrizione sia avvenuta, poi eliminare il record associato: un’operazione in attesa e la scomparsa di una voce dalla console non dimostrano che la gestione sia stata rimossa dal dispositivo. La successiva rimozione di un profilo di lavoro comporta la perdita delle relative app e dei dati locali, non il ripristino del vecchio profilo. Non garantire la conservazione dei dati personali senza verificare il dispositivo.
Dispositivo offline, in stato ignoto o bloccato: non considerare l’operazione conclusa e non inviare alla cieca una seconda richiesta di eliminazione o ripristino. Chiarire con l’utente e con l’assistenza Sophos o del dispositivo lo stato effettivo, la consegna dell’operazione e il percorso di recupero autorizzato. Un’operazione impartita dal cloud non prova che sia stata eseguita.

Prima dell’intervento, se sono presenti Restrictions, registrare lo stato effettivo della cifratura del dispositivo e della scheda SD, oltre a un percorso di backup e recupero consentito e di comprovata utilizzabilità. Su alcuni dispositivi legacy la cifratura SD richiesta potrebbe essere stata interrotta; l’assegnazione non dimostra lo stato effettivo. Secondo la fonte relativa alla vecchia configurazione, disabilitare Allow backup disattiva il backup Google, non tutte le modalità alternative di backup. I blocchi USB/MTP possono impedire il trasferimento di file necessario. Non allentare i blocchi per tentativi. Allow factory reset riguarda il ripristino eseguito dall’utente: non ne deriva né l’autorizzazione né la possibilità di eseguire il Wipe dalla console, che richiede un’autorizzazione separata.

Usare la vecchia policy come inventario, non come modello per Android Enterprise

La policy per i dispositivi Android è destinata alla vecchia modalità Amministratore dispositivo. Android Enterprise full device e Android Enterprise work profile hanno ciascuno famiglie di policy distinte. Prima dell’autorizzazione, creare una matrice documentata di origine e destinazione per tutte e 14 le vecchie sottoconfigurazioni; per ogni riga registrare modalità di destinazione, nuova impostazione supportata o esplicita assenza di un sostituto, sistema operativo/OEM/licenza, test, effetti e percorso di recupero:

Le verifiche seguenti devono essere incluse nella matrice. Si registrano i valori esistenti, non configurazioni Amministratore dispositivo da creare. L’assenza di un sostituto deve restare una decisione aperta e visibile; opzioni di destinazione dal nome simile non dimostrano effetti equivalenti.

Connessioni e certificati

Per ogni configurazione APN esistente, inventariare anche questi campi:

User-friendly name, il nome aggiuntivo visualizzato sul dispositivo; le due voci Server separatamente come server HTTP per il traffico web e gateway WAP, insieme al Port del server web.
User name e la dipendenza da User password, solo tramite un riferimento all’identità con accesso limitato e un riferimento sicuro al segreto; MMSC (Multimedia Messaging Service Center), MMS proxy server e MMS proxy port separatamente per il percorso MMS.
Authentication type per l’autenticazione PPP, APN type per i tipi di connessione dati, Bearer per la tecnologia di accesso radio e Protocol e Roaming protocol per i protocolli dell’operatore nella rete di origine e in roaming.

Tranne APN, i campi legacy sono facoltativi; indicare esplicitamente quelli inutilizzati come non configurati, senza inserire valori ipotizzati. In APN type, * o un campo vuoto significa tutti i tipi di dati. Solo una configurazione APN può usare Use as default APN. Questi significati spiegano lo stato precedente, non come creare un nuovo APN nella modalità legacy. Associare ogni valore utilizzato a un sostituto di destinazione la cui compatibilità sia stata verificata separatamente oppure indicarne esplicitamente l’assenza; confermare separatamente l’accettazione dell’operatore per la SIM/l’abbonamento di destinazione. Rimane necessario un collegamento indipendente per il recupero.

Per APN, registrare il punto di accesso attuale, l’operatore e la SIM o l’abbonamento utilizzato. Verificare con l’operatore che accetti questo APN per l’abbonamento previsto. Registrare e confrontare anche i valori esistenti di Mobile Country Code (MCC) e Mobile Network Code (MNC): limitano l’utilizzo del vecchio APN all’operatore indicato. Un Use as default APN errato può interrompere i dati mobili. Prima dell’intervento, salvare quindi i valori dell’operatore e predisporre una connessione indipendente; non modificare l’APN predefinito per tentativi.

Per Wi-Fi e VPN, registrare i vecchi certificati Wi-Fi/EAP, gli SSID e i tipi di VPN e verificare separatamente l’accesso di destinazione; WEP non è uno standard di sicurezza accettabile per la destinazione. Testare il check-in di gestione anche tramite un accesso indipendente.

Per ogni configurazione Wi-Fi esistente, includere nella matrice i seguenti valori della vecchia configurazione:

SSID e Security type effettivo: None, WEP, WPA/WPA2 PSK, EAP/PEAP, EAP/TLS o EAP/TTLS. None e WEP non sono raccomandazioni per la destinazione. La vecchia descrizione esclude l’assegnazione della policy con WEP ad Android 12 e versioni successive; questa condizione storica non consente la registrazione nella vecchia modalità di gestione.
Phase 2 authorization solo per EAP/PEAP ed EAP/TTLS: registrare l’opzione esistente, None, PAP, CHAP, MSCHAP o MSCHAPv2. Non aggiungere un valore di questo tipo per EAP/TLS.
Per EAP, distinguere Identity da Anonymous identity. Quest’ultima è lo pseudonimo inviato senza cifratura nella fase 1 della negoziazione EAP. Per Password, documentare la dipendenza dalla password Wi-Fi esistente e il percorso sicuro per conservarla o fornire una password sostitutiva, non la password stessa.
Registrare separatamente Proxy host, ossia il nome o l’indirizzo IP del proxy di questa connessione Wi-Fi, e Proxy port. Global HTTP proxy non è un sostituto di comprovata equivalenza per questo proxy specifico della connessione.

Per ogni configurazione VPN esistente, registrare Connection name (nome visibile sul dispositivo), Server (nome host o indirizzo IP del gateway) e Connection type effettivo. La vecchia descrizione distingue le seguenti dipendenze:

L2TP/IPsec (PSK): documentare l’associazione all’utente in User e la dipendenza dalla password in Password separatamente dalla chiave di autenticazione precondivisa nel campo L2TP/IPsec (PSK).
L2TP/IPsec (certificate): registrare Client certificate e Root certificate selezionati, oltre a User e alla dipendenza da Password. In questo percorso legacy, la selezione dei certificati non sostituisce la dipendenza da utente e password.
Cisco AnyConnect: inventariare separatamente l’XML del profilo VPN e quello del profilo NVM (Network Visibility Module), ciascuno con responsabile, versione e riferimento a un luogo di archiviazione sicuro; indicare espressamente i profili assenti. Non dedurne né un’importazione automatica degli XML né la stessa visibilità di rete nella destinazione.

Registrare le associazioni delle identità solo nel verbale di migrazione ad accesso protetto. Per password, PSK e chiavi private, includere esclusivamente riferimenti a modalità sicure di conservazione o fornitura; non riportare segreti né identità reali sensibili nei riscontri pubblici. Associare ogni vecchio valore Wi-Fi utilizzato e ogni dipendenza VPN a un sostituto di destinazione verificato separatamente, oppure documentarne espressamente l’assenza. Per la VPN, verificare il supporto di app, sistema operativo, gateway e autenticazione, senza dedurlo dal vecchio tipo di connessione. Verificare il significato dei campi di destinazione, i ruoli dei certificati e la configurazione dell’app VPN nell’articolo collegato sulle connessioni Android; restano inoltre necessarie le verifiche sui certificati descritte di seguito.

Registrare separatamente Client certificate, Root certificate e SCEP. I vecchi certificati client e le ancore di attendibilità sono legati alle policy; SCEP richiede che la CA del server SCEP sia configurata come certificato radice. Dimostrare ex novo identità di destinazione, emissione/rinnovo, attendibilità della CA e autenticazione Wi-Fi/VPN; non disattivare mai la verifica dei certificati per risolvere un problema.

Nella vecchia policy per i dispositivi Android, il certificato radice configurato in Root certificate veniva installato sul dispositivo con l’assegnazione della policy. Per i dispositivi legacy, documentare il file del certificato X.509 configurato e la relativa codifica PEM o DER. Ogni certificato radice aggiuntivo richiedeva una configurazione Root certificate distinta; includere quindi singolarmente tutte le configurazioni radice esistenti nella matrice di origine e destinazione. La sola assegnazione precedente non dimostra né lo stato effettivo dei certificati sul dispositivo specifico né il loro trasferimento automatico ad Android Enterprise.

Per ogni configurazione Root certificate esistente, registrare anche la vecchia policy e le altre configurazioni della stessa policy che utilizzano effettivamente quel certificato radice, inclusa l’attendibilità del server Wi-Fi/EAP, se presente. Distinguere l’attendibilità del server dall’identità client e dalla CA del server SCEP. Associare ogni dipendenza alla policy e alla modalità di destinazione scelte, oppure documentare l’assenza di un sostituto supportato. Nel pilota di destinazione autorizzato, verificare l’identità del server attesa, l’attendibilità della CA e la connessione/autenticazione; non presumere un trasferimento automatico.

Solo per interpretare i vecchi campi SCEP: URL poteva essere collegato tramite %_SCEPPROXYURL_% all’URL del server nella scheda SCEP della pagina Sophos setup; Challenge poteva fare riferimento tramite %_CACHALLENGE_% all’URL di challenge configurato lì. Dopo aver sostituito i segnaposto con i dati effettivi, Subject deve essere un nome X.500 valido. Le vecchie opzioni SAN significano: RFC 822 name = un indirizzo e-mail valido; DNS name = il nome DNS del server della CA; Uniform resource identifier = l’URL completo e qualificato del server della CA. Registrare i campi configurati e non configurati e l’identità effettivamente risolta nell’inventario con accesso limitato; per i segreti utilizzare solo riferimenti sicuri di custodia/provisioning. Non è un’istruzione per un nuovo provisioning nella modalità legacy né per riutilizzare segreti di challenge. Non dedurne i significati SAN della destinazione e non copiare questi vecchi significati relativi alla CA in una nuova identità client.

Per ogni configurazione SCEP esistente, registrare le dipendenze seguenti con i responsabili PKI/MDM, senza modificare i vecchi record per ricavarne le informazioni:

Richiesta del certificato: documentare gli endpoint del server e della challenge, le relative dipendenze e, se applicabile, il collegamento alle variabili risolto tramite la configurazione. Non riportare password della challenge o altri segreti nel verbale o nell’articolo.
Identità e selezione: registrare il vecchio alias o riferimento di selezione, l’associazione all’utente/dispositivo, l’espressione Subject e il nome risolto, oltre ai tipi e valori SAN configurati e all’AD-UPN. Indicare espressamente i campi non configurati come assenti. Nel pilota, confrontarli con l’identità richiesta dal servizio e con la selezione effettiva del certificato nella destinazione; lasciare aperte le associazioni non supportate.
Legame di attendibilità: identificare senza ambiguità il certificato radice effettivamente selezionato nella vecchia policy attuale, se necessario tramite l’impronta digitale. Verificare l’attendibilità del server SCEP separatamente da quella del certificato client emesso e del server del servizio. Non rimuovere un’ancora di attendibilità ancora necessaria prima di aver osservato e verificato il corretto funzionamento nella destinazione.
Chiave e utilizzo: registrare il valore esistente di Key size, il requisito di compatibilità della CA e le selezioni e finalità distinte per firma digitale e cifratura. Chiarire i requisiti di destinazione con i responsabili PKI e del servizio che usa il certificato; nel pilota verificare il certificato emesso e l’utilizzo richiesto. Non attivare indiscriminatamente entrambe le finalità né trasferire automaticamente il vecchio valore della chiave.

Verificare separatamente il percorso supportato per ottenere il certificato nella destinazione, i ruoli dei certificati e le finalità d’uso usando la guida alle connessioni Android e il runbook sui certificati/SCEP lì collegato. Queste guide di destinazione non sostituiscono né l’inventario né la verifica dell’effetto reale nella destinazione.

Identificare inoltre senza ambiguità il Client certificate esistente tramite un riferimento sicuro al file effettivo PKCS #12 (.pfx) e al Certificate name letto dal file. Nell’inventario dei certificati registrare quali configurazioni della stessa vecchia policy lo selezionano. Altre policy legacy richiedevano caricamenti separati; è una dipendenza preesistente, non un’istruzione per un nuovo provisioning nella modalità legacy. Non pubblicare né esportare una chiave privata e non presumere il trasferimento automatico alla destinazione.

App, autorizzazioni e password delle app

Filtro app di Restrictions: registrare il valore di Filter type separatamente da App Control: documentare Allowed apps o Forbidden apps, il gruppo di app associato e i suoi membri, oltre alle app effettivamente interessate. Secondo la fonte relativa alla vecchia configurazione, le app installate da Sophos Mobile sono escluse da questo filtro; il blocco dell’avvio di App Control non è quindi un sostituto di comprovata equivalenza. Secondo la stessa fonte, anche il blocco del browser nativo non riguarda i browser di terze parti. Per l’obiettivo di protezione delle app e del browser richiesto, verificare separatamente l’ambito di applicazione e l’effetto reale nella destinazione.
App Control: documentare il vecchio gruppo di app selezionato e i suoi membri. Questo blocco impedisce l’avvio, anche delle app del produttore non disinstallabili; non rimuove le app. Per ogni app bloccata, registrare la modalità di destinazione e la nuova appartenenza al gruppo. Ciò non implica né un trasferimento automatico dal Play Store né un blocco delle app personali nella modalità di destinazione.
App permissions: per ogni vecchia app, annotare l’identità esatta e ogni autorizzazione a runtime configurata con il relativo valore: Selectable significa modificabile dall’utente, Granted concessa e Denied negata. Per ogni app e autorizzazione, associare modalità di destinazione, app di destinazione, effetto desiderato e modifica consentita all’utente, oppure segnalare l’assenza di un sostituto. Nei profili di lavoro, da Android 12 in poi, posizione, fotocamera, microfono, sensori corporei e attività fisica possono essere negati per conto dell’utente, ma non concessi. Questo limite va considerato nella decisione sulla destinazione.
App Protection: registrare il vecchio gruppo di app e i suoi membri, Password complexity, Grace period in minutes e Allow fingerprint authentication. Tutte le app protette utilizzano la stessa password, impostata dall’utente alla prima apertura di una di queste app. Durante il periodo di tolleranza configurato dopo la chiusura di un’app protetta, è possibile aprire le app protette senza una nuova richiesta di password. L’impronta digitale è una possibile alternativa alla password delle app. Il vecchio sistema di protezione può essere aggirato tramite altre app, funzioni di sistema o modalità multifinestra; non garantisce quindi una protezione aziendale equivalente. Confrontare separatamente le impostazioni supportate per la gestione completa del dispositivo e per il profilo di lavoro.

Account e-mail e istruzioni per l’utente

Per Email account, verificare separatamente app di posta, cloud Exchange, autenticazione OAuth supportata ed effettivo flusso della posta. Un vecchio campo password o Allow all certificates non è una soluzione alternativa per Exchange Online. Oltre a server, certificati e utente assegnato, registrare i seguenti valori precedenti:

Nome dell’account, percorso, trasporto e contenuti

Registrare Account name e il Server name effettivo; distinguere un endpoint Exchange diretto dall’URL di un EAS proxy. outlook.office365.com si applica al cloud Microsoft 365 mondiale, non universalmente agli altri cloud Microsoft. Osservare il percorso di posta realmente approvato, senza sostituirlo senza verifica.
Registrare i valori risolti di Email address e Sender indipendentemente da User; %_EMAILADDRESS_% viene sostituito dall’indirizzo reale in entrambi i campi. I dati identificativi rimangono nel registro con accesso limitato.
Per Password, documentare solo il riferimento sicuro di custodia/provisioning e la dipendenza esistente: un campo legacy vuoto richiedeva l’inserimento della password da parte dell’utente sul dispositivo. Non è una raccomandazione di usare un fallback con password al posto di OAuth supportato.
Registrare gli stati esistenti di SSL/TLS e Allow all certificates, il Client certificate selezionato e Synchronize content types. La vecchia opzione di esclusione della verifica non è un valore di destinazione sicuro. Associare ogni campo di posta utilizzato a un effetto di destinazione supportato oppure indicare esplicitamente l’assenza di un sostituto. Nel pilota autorizzato verificare l’identità effettiva di account/mittente e server, la fiducia TLS e i contenuti selezionati per la sincronizzazione con dati innocui; non usare fallback con password né aggirare la verifica dei certificati.

Identità nel vecchio account e nella destinazione

Registrare innanzitutto il vecchio valore di User e il nome di accesso effettivamente ricavato. Per i segnaposto %_USERNAME_% e %_EMAILADDRESS_%, i campi Exchange Login e Email Address dell’utente assegnato devono essere compilati in Sophos Fusion. La fonte relativa alla vecchia configurazione indica generalmente %_EMAILADDRESS_% per Exchange Online e %_USERNAME_% per Exchange Server. L’indirizzo e-mail e il nome di accesso effettivo non sono comunque automaticamente identici.

Registrare anche Domain. Secondo la vecchia descrizione, il campo resta vuoto per Exchange Online e contiene il dominio dell’account utente per Exchange Server. Queste informazioni spiegano quale identità usa il vecchio account. Prima dell’autorizzazione, confrontare i vecchi valori risolti e l’utente assegnato con l’identità di destinazione scelta. Verificare come vengono rappresentati nome utente e dominio nella destinazione; l’autenticazione supportata va verificata separatamente, come descritto sopra.

Configurazione sul vecchio dispositivo

Documentare OEM/API e configurazione automatica o manuale dell’account. La vecchia descrizione indica LG GATE, Samsung Knox e Sony Enterprise API per la configurazione automatica. Sugli altri dispositivi, l’utente doveva configurare l’app di posta usando i dettagli disponibili in Sophos Mobile Control. Per il client di destinazione, prevedere istruzioni specifiche per l’utente e un test pilota dell’app, senza ripetere la vecchia configurazione.

Sincronizzazione e account predefinito

Registrare Synchronization interval come intervallo tra le sincronizzazioni, separatamente da Synchronization period, che indica l’età dei messaggi inclusi. Documentare il meccanismo di destinazione per la frequenza di recupero o l’assenza di un sostituto. Registrare anche Default account e chiarire come l’app di destinazione sceglie l’account predefinito o se manca un’impostazione gestita.

Flusso dei dati, formato e dimensione dei messaggi

Per Allow forwarding emails e Allow use of HTML format, registrare i valori esistenti e le precedenti decisioni sulle esigenze aziendali e sulla protezione dei dati. Per entrambe le impostazioni, indicare se l’app di destinazione o Exchange possono applicarle. Altrimenti segnalare espressamente l’assenza di un sostituto.

Riportare letteralmente il valore di Maximum attachment size in MB. Nonostante il nome del campo, Sophos descrive la dimensione massima di un singolo messaggio e-mail, non esplicitamente quella di un solo allegato. Verificare separatamente quale effetto sia rilevante per l’attività e quale limite impongano l’app di destinazione o Exchange.

Caso particolare Sony nei dispositivi legacy

La fonte tedesca indica Enterprise API Level 6.x o precedente, quella inglese Level 6 o precedente. Sui dispositivi interessati, le informazioni dell’account Exchange devono corrispondere all’utente assegnato. Mobile Control non può trasmettere l’ID ActiveSync su questi dispositivi. Al primo contatto con il proxy EAS, questo cerca quindi un dispositivo con ID ActiveSync sconosciuto e un’assegnazione utente corrispondente. Se lo trova, associa l’ID inviato dal client di posta e inoltra la richiesta; altrimenti la rifiuta. Prima di autorizzare il vecchio account, confrontare versione API, utente assegnato e identità effettiva del client. Osservare il percorso di posta autorizzato esistente senza reimpostare le identità né aggirare i controlli di accesso. Verificare separatamente il percorso di destinazione; non trasferire questa condizione legacy a Gmail su Android Enterprise.

Kiosk e uscita autorizzata

Per Kiosk mode, registrare il valore esistente di Select source (Custom, App list o No app), l’esatto App ID, l’installazione effettiva, lo stato di assegnazione e lo stato del dispositivo. Per App list, documentare la voce dell’app Android selezionata e già aggiunta a Sophos Mobile; prima di associarla alla destinazione, confrontare l’identità del pacchetto ricavata da quella voce con App ID e con l’app effettivamente installata. Se l’app kiosk configurata manca al momento dell’assegnazione della vecchia policy, l’operazione di assegnazione della policy resta Incomplete / Unvollständig finché l’app non viene installata. In presenza di questo stato legacy, confrontare prima identità e installazione; un ripristino non è una soluzione da tentare alla cieca. No app significa invece che vengono trasferite le restrizioni, ma non viene avviata alcuna app. Non confonderlo con un pacchetto mancante o con un’opzione Enterprise denominata None.

Se le funzioni del dispositivo non sono disabilitate, l’utente può uscire dalla vecchia app kiosk e usare normalmente il dispositivo; la sola selezione dell’app non dimostra che l’uscita sia impedita. Documentare in particolare gli stati esistenti di Allow Home button e Allow task manager, oltre all’accesso amministrativo fisico o alternativo autorizzato. Prima del ripristino, verificare app kiosk, possibilità di avvio e uscita, e dimostrarne separatamente il funzionamento nella modalità di destinazione.

Per Sony Enterprise API Level 9 o successivo, secondo la vecchia fonte, se anche una sola delle opzioni Allow volume up, Allow volume down o Allow volume mute è disabilitata, tutti i tasti del volume sono disabilitati. Registrare modello interessato, livello API e stato precedente. Nel pilota di destinazione autorizzato, verificare quali controlli audio e dei tasti siano supportati per questo modello e la modalità di gestione scelta. Testare sul dispositivo l’audio e i tasti necessari, senza presumere che abbiano lo stesso comportamento precedente.

Knox Premium, protezione all’avvio e app amministratore

Registrare il valore esistente di Allow firmware auto update options, il responsabile e il supporto del dispositivo/licenza. La vecchia opzione fa cercare automaticamente al dispositivo gli aggiornamenti firmware; l’utente non può modificarlo nelle impostazioni del dispositivo. Non significa che ogni aggiornamento venga installato automaticamente. Documentare separatamente il sostituto di destinazione supportato o la sua assenza e osservare il comportamento reale degli aggiornamenti nel pilota autorizzato, senza attivare nuovamente opzioni legacy.

Le vecchie Knox Premium restrictions agiscono sul dispositivo Samsung Knox, non sul contenitore Knox. La loro applicazione richiede una licenza Samsung Knox Premium registrata in Sophos Mobile. Verificare separatamente tipo di dispositivo, registrazione della licenza ed effetto reale sul dispositivo. Per la modalità Enterprise di destinazione scelta, chiarire specificamente quale licenza serva e quale effetto sul dispositivo sia supportato; la vecchia registrazione della licenza non dimostra che venga trasferita.

Registrare lo stato esistente di Enable ODE Trusted Boot verification. Secondo la vecchia descrizione, all’avvio la partizione dati viene decifrata solo in presenza di binario e kernel ufficiali. Chiarire accesso ai dati e percorso di recupero autorizzato prima di riavviare o ripristinare; non disabilitare la verifica per abbreviare la migrazione o il recupero.

Registrare separatamente Prevent installation of another administrator app e Prevent activation of another administration app. La prima vecchia opzione impedisce l’installazione di app con diritti di amministratore del dispositivo, tranne quelle installate da Sophos Mobile; la seconda impedisce l’attivazione di tali diritti. Verificare prima l’effetto reale sulle app necessarie e sul percorso di registrazione previsto, senza allentare indiscriminatamente i blocchi.

Se è presente Allow Common Criteria mode, registrare anche tutte e sei le condizioni precedenti:

cifratura del dispositivo attivata;
cifratura rapida disattivata;
cifratura della memoria esterna attivata;
soglia di tentativi errati prima della cancellazione del dispositivo impostata;
revoca dei certificati attivata;
cronologia delle password disattivata.

Senza queste condizioni, secondo la vecchia fonte, CC Mode non viene applicato. Sono dipendenze della configurazione iniziale, non un invito ad attivare nuove opzioni legacy o a indebolire la protezione tramite password nella destinazione. Non testare la cancellazione dopo tentativi errati sui dispositivi in produzione. Verificare separatamente supporto attuale, sostituto di destinazione e recupero nel pilota autorizzato; la vecchia descrizione non prova una certificazione attuale.

Blocco schermo e restrizioni

Per il blocco schermo esistente, registrare in Password policies il valore di Password type e il suo significato nella vecchia configurazione: Pattern, PIN or password richiede un blocco schermo senza ulteriori restrizioni; Simple password richiede una password con almeno una lettera e ammette cifre; PIN or password consente questi due tipi di blocco. Alphanumeric password e Complex password richiedono una password con lettere e cifre. Solo Complex password aggiunge i sei valori minimi di composizione indicati sotto. Queste informazioni descrivono la policy di partenza, non la creazione di una nuova policy legacy né un comportamento identico in Android Enterprise.

Per Simple password, PIN or password, Alphanumeric password e Complex password, registrare anche i valori presenti per ciascun tipo: Minimum password length (numero totale di caratteri), Maximum idle time before password prompt (durata di inattività impostata; il dispositivo può imporre una durata più breve), Maximum password age in days (intervallo di cambio; il vecchio intervallo è 0–730 giorni, con 0 non è richiesto alcun cambio), Maximum sign-in attempts (tentativi errati prima della cancellazione del dispositivo nella vecchia modalità) e Password history (numero di password precedenti memorizzate che non possono essere riutilizzate). Non inventare valori per campi assenti nel tipo scelto. Prima dell’autorizzazione, documentare per il tipo e per ogni campo l’effetto supportato nella destinazione o la sua esplicita assenza, il sistema operativo/OEM e il blocco scelto per il dispositivo o il profilo di lavoro; non trasferire automaticamente i vecchi valori.

Per Password policies, in presenza di un Complex password esistente, registrare singolarmente i sei valori minimi: lettere, minuscole, maiuscole, caratteri non alfabetici, cifre e caratteri speciali. Caratteri non alfabetici e caratteri speciali sono valori legacy distinti, non un requisito unico. Confrontare ogni valore con la gestione completa del dispositivo, il blocco del dispositivo o il blocco del profilo di lavoro scelti e con le indicazioni OS/OEM. Per ogni minimo, documentare il sostituto supportato o la sua assenza e l’applicazione osservata senza prove distruttive.

Registrare anche Allow fingerprint authentication e Allow iris authentication, con la selezione esistente. I vecchi metodi di sblocco valgono solo sui dispositivi che li supportano. Verificare separatamente, per sistema operativo e OEM, disponibilità e metodi di sblocco effettivamente consentiti nella modalità di destinazione. L’impronta digitale di App Protection o Weak biometric recognition non dimostrano un sostituto identico.

Per Password policies e Restrictions, verificare recupero, backup ed effetto di ogni blocco e restrizione rilevante per sistema operativo e modalità; non supporre effetti identici sui dispositivi personali e aziendali. Una soglia di tentativi errati può cancellare il dispositivo; non testarla su dispositivi in produzione.

Per le Restrictions effettivamente utilizzate, compilare la matrice fino alla singola impostazione rilevante: vecchio valore, effetto osservato sul dispositivo, obiettivo di protezione aziendale, sistema operativo/OEM e dipendenze tra opzioni principali e subordinate, sostituto di destinazione supportato oppure discrepanza esplicita e autorizzata. Includere in particolare condivisione e registrazione dei dati, uso delle connessioni radio, delle funzioni di condivisione e delle periferiche, raggiungibilità, comunicazioni di emergenza e roaming, aggiornamenti e recupero, account inclusa la rimozione degli account Google, oltre alle fonti di installazione delle app e alla disinstallazione. Motivare l’esclusione delle impostazioni inutilizzate o non applicabili. Non valutare i blocchi solo in base al nome: secondo la vecchia fonte, il divieto di registrare video consente foto e streaming; gli appunti condivisi richiedono Allow clipboard. Se si usa Bluetooth, verificare anche associazioni e profili esistenti; per tethering o fotocamera dalla schermata di blocco, controllare anche l’opzione principale. Registrare anche i valori subordinati SD/USB rilevanti insieme alle rispettive opzioni principali. Un vecchio blocco di Beam non controlla Quick Share. Nel pilota di destinazione autorizzato, verificare con dati di test innocui le funzioni necessarie e i flussi di dati vietati; in caso di sostituto assente o di effetto diverso, interrompere la distribuzione fino a una decisione documentata.

Le sottopagine storiche descrivono le impostazioni di partenza, in parte risalenti al 2022–2023, non l’attuale supporto dei vecchi protocolli o delle funzionalità OEM sui dispositivi di destinazione. Le verifiche descritte indicano quali dipendenze chiarire prima della migrazione. Prima di raccomandare policy concrete, verificare entrambe le policy di destinazione complete e il proprio tenant. Gli argomenti KB separati sulle policy per dispositivi completamente gestiti, sulle policy per i profili di lavoro, sulle connessioni Android, sul BYOD e su FRP non sostituiscono l’autorizzazione alla migrazione. Per l’autenticazione della posta, consultare anche l’articolo sulla migrazione Exchange.

Pilota, interruzione e recupero

Solo dopo aver chiarito proprietà, tenant, licenze e percorso di recupero autorizzato, eseguire un pilota su dispositivi sacrificabili e rappresentativi per ciascuna modalità. Prima, salvaguardare i dati del dispositivo e le policy precedenti; preparare separatamente la nuova policy e il metodo di registrazione. Durante il pilota confermare l’operazione sul dispositivo, controllare la nuova modalità di gestione e l’assegnazione effettiva, e osservare app, accesso agli account e flusso della posta, kiosk (se presente), Wi-Fi/VPN, emissione e rinnovo dei certificati e i dati personali dopo il passaggio BYOD. Decidere di procedere con altri dispositivi solo dopo aver verificato gli effetti.

Per i valori precedenti registrati, annotare nel pilota risultati concreti attesi ed effettivi:

Rete mobile

Con la SIM e l’operatore previsti, verificare l’accesso ai dati mobili separatamente dall’accesso indipendente di recupero e gestione già testato. Controllare poi il check-in di gestione. Se manca l’accesso ai dati, non migrare altri dispositivi; utilizzare l’accesso indipendente e il percorso di escalation autorizzati in anticipo.

App e autorizzazioni

Verificare prima l’avvio di ogni app precedentemente bloccata e delle app necessarie all’attività e alle emergenze. Poi, usando dati di test, controllare ogni app di destinazione e le sue autorizzazioni a runtime. Confrontare lo stato atteso con il funzionamento reale dell’app quando l’autorizzazione è concessa o negata. Verificare anche se l’utente può modificare l’autorizzazione come previsto oppure se la modifica viene impedita. Considerare i limiti di Android 12 nei profili di lavoro.

Prima di una modifica, registrare impostazioni e assegnazione. Utilizzare solo il percorso di aggiornamento o sostituzione supportato e già testato. Se occorre annullare una modifica alla policy, confermare la sincronizzazione e ripetere le stesse verifiche sulle autorizzazioni.

Non concedere indiscriminatamente le autorizzazioni solo per far funzionare un’app. Revocarle in seguito non recupera i dati già divulgati.

Password delle app e blocco schermo

Nella destinazione, verificare la richiesta di password attesa, gli accessi alternativi consentiti, il periodo senza nuova richiesta e l’autenticazione. Per il blocco del dispositivo o del profilo di lavoro, controllare senza prove distruttive i singoli requisiti minimi e i metodi biometrici disponibili, senza avvicinarsi alla soglia di tentativi errati.

Per il blocco di destinazione scelto, confrontare i tipi di blocco consentiti e la lunghezza totale con la decisione documentata; osservare la durata effettiva di inattività prima della richiesta di password, inclusi eventuali limiti più brevi imposti dal dispositivo. Verificare il comportamento di cambio e riutilizzo, se supportato, su un account/dispositivo di test autorizzato o tramite riscontri di stato supportati; registrare espressamente l’eventuale assenza di supporto. Sui dispositivi in produzione non accelerare il cambio password, non indebolire la protezione e non esaurire i tentativi errati consentiti. Mantenere il percorso di recupero predisposto e interrompere la distribuzione in caso di discrepanze.

Posta

Con un account di test autorizzato e contenuti innocui, verificare tempi di consegna, account predefinito in fase di composizione, inoltro consentito o vietato, comportamento HTML e dimensioni dei messaggi rilevanti. Non utilizzare dati riservati reali. Confrontare il risultato con la decisione di destinazione documentata, anche se nella destinazione manca un’impostazione precedentemente gestita.

Fermarsi in caso di discrepanze

In caso di discrepanza, interrompere la distribuzione. Una configurazione di destinazione visibile non basta: chiarire prima causa, sostituto supportato e percorso di recupero sicuro.

Se manca la raggiungibilità, lo stato dei dati non è chiaro, il dispositivo o la modalità sono errati, l’accesso non riesce oppure interviene un blocco dopo il ripristino, fermarsi e richiedere assistenza. Prima dell’intervento, individuare il supporto competente, una connessione indipendente funzionante e un percorso per rimettere in servizio il dispositivo. Rollback non significa annullare un ripristino delle impostazioni di fabbrica o la cancellazione di un profilo di lavoro: il recupero è possibile solo da backup la cui utilizzabilità sia stata dimostrata e tramite una nuova registrazione autorizzata; non sono comprovate né la consegna immediata di operazioni remote né l’identico effetto delle policy. Senza test sul tenant e sul dispositivo, nessuna procedura di migrazione per la produzione né garanzia di successo.