Pianificare e verificare in sicurezza i criteri di conformità di Sophos Mobile

Un criterio di conformità non è un certificato né un profilo del dispositivo. Valuta determinate regole per i dispositivi registrati e può attivare azioni in caso di violazione. Contano l’edizione effettiva del prodotto (Sophos Mobile o Sophos Mobile Threat Defense), la piattaforma e la versione del sistema operativo, la proprietà aziendale o personale del dispositivo, la modalità di registrazione e gestione, l’eventuale app Intercept X for Mobile (IXM) gestita da Sophos Mobile e il gruppo di dispositivi a cui è assegnato il criterio. La presenza di una regola o di un modello PCI/HIPAA non dimostra né che sia applicabile a tutti i dispositivi né che esista una certificazione.

Prima di qualsiasi intervento in produzione: Check now controlla tutti i dispositivi registrati ed esegue le azioni configurate. Anche creare o modificare un criterio e assegnarlo a un gruppo non sono semplici operazioni di consultazione. Definire prima l’intero insieme dei dispositivi interessati e la procedura di ripristino; non usare la flotta di produzione per fare prove.

Che cosa viene effettivamente valutato?

Scegliere prima l’edizione del prodotto, poi verificare piattaforma, sistema operativo e modalità di registrazione: con Android Enterprise fully managed l’MDM gestisce l’intero dispositivo; con Apple User Enrollment i dispositivi Apple personali vengono registrati con capacità di gestione limitate; supervised indica iPhone/iPad supervisionati. Un’app IXM gestita da Sophos Mobile non dimostra, da sola, che il dispositivo sia interamente sottoposto a Mobile Device Management (MDM). Confrontare nel proprio tenant le regole disponibili per l’edizione e la modalità effettivamente utilizzate; non confondere le regole e le azioni di Sophos Mobile con quelle di Sophos Mobile Threat Defense.

Le regole definiscono quali funzioni o stati del dispositivo sono consentiti, vietati o richiesti. La reazione a una violazione viene scelta separatamente; un criterio di conformità, da solo, non dimostra che un’impostazione del dispositivo venga modificata attivamente o imposta.

Per creare un criterio in Sophos Mobile o nell’edizione autonoma Sophos Mobile Threat Defense, aprire il menu Compliance policies, fare clic su Create compliance policy e selezionare il modello Default, PCI o HIPAA. Inserire un nome e, facoltativamente, una descrizione; la scelta del modello non limita le impostazioni successive. Solo il modello Default non prevede azioni preimpostate; PCI/HIPAA possono già contenerne. Sophos descrive le regole e le azioni dei modelli PCI/HIPAA come basate su HIPAA e PCI DSS. L’ordine dei modelli e degli standard nella documentazione è però ambiguo; non dedurre qui una corrispondenza tra un singolo modello e uno standard. La scheda della piattaforma deve essere attivata con Enable platform: senza la spunta, non viene eseguito alcun controllo di conformità per i dispositivi di quella piattaforma. I livelli di gravità high, medium e low sono assegnati in modo fisso alle regole e non corrispondono a un’azione di risposta selezionabile liberamente. Nella pianificazione del criterio aiutano a valutare l’importanza di ogni regola e a scegliere una reazione adeguata a una violazione. Questo non autorizza l’esecuzione di un’azione durante un incidente. Nell’edizione completa, Highlight rules aiuta a evidenziare un tipo di gestione, ma non dimostra che una regola abbia effetto su ogni dispositivo di quel tipo.

Fare clic su Save solo dopo aver configurato e verificato le regole e le relative reazioni per tutte le piattaforme necessarie. Il criterio viene così salvato con il nome inserito; la successiva assegnazione ai gruppi avviene separatamente, dopo i controlli descritti di seguito.

Sophos Mobile (edizione completa/MDM): oltre alle regole di gestione e del sistema operativo specifiche della piattaforma, sono possibili segnali IXM se Sophos Mobile gestisce l’app. Per ogni regola si possono scegliere le reazioni Deny email, Lock container, Set health, Create alert e Transfer task bundle; restano validi i requisiti relativi alla piattaforma e alla singola azione.
Sophos Mobile Threat Defense (edizione del prodotto distinta): il suo catalogo separato di regole comprende, tra l’altro, le autorizzazioni IXM e il rilevamento di malware/app su Android, il Web Filtering su iOS e le regole di sicurezza per Chromebook. Per questa edizione è descritta la reazione Create alert, non le azioni MDM relative a e-mail, container, health o task bundle.

Nell’edizione autonoma, Installed apps e Mandatory apps si applicano solo ai Chromebook. Per Installed apps, selezionare prima Allowed apps o Forbidden apps, poi il gruppo contenente le app o le estensioni consentite o vietate. Per Mandatory apps, selezionare il gruppo contenente le app o le estensioni che devono essere installate. Le corrispondenze con Android, iOS e Mac descritte più avanti e le precisazioni sulle app di sistema e sugli aggiornamenti delle app Android appartengono al catalogo generale dell’edizione completa di Sophos Mobile, non a queste due regole dell’edizione autonoma Threat Defense.

Il catalogo separato Mobile Threat Defense compliance rules all’interno della guida di Sophos Mobile descrive un sottoinsieme di regole per dispositivi Android/iOS la cui app IXM è gestita da Sophos Mobile: ad esempio root/jailbreak, limiti del sistema operativo, sincronizzazione IXM e scansioni delle app Android. La sola gestione dell’app non dimostra una gestione MDM completa del dispositivo; inoltre, questo sottoinsieme non coincide con il catalogo di regole dell’edizione autonoma Sophos Mobile Threat Defense. Su Android, la regola Intercept X for Mobile permissions can be denied stabilisce se il rifiuto delle autorizzazioni dell’app IXM rende il dispositivo non conforme. Può segnalare come violazione la mancata disponibilità del Web Filtering quando l’Accessibility Service è stato negato; Sophos raccomanda il valore No se si utilizza il Web Filtering. La regola iOS Web Filtering turned on compare nel catalogo generale delle regole di Sophos Mobile e nel catalogo dell’edizione autonoma Threat Defense, non nel sottoinsieme IXM appena citato. Richiede che su iPhone e iPad sia attiva la funzione Web Filtering di Intercept X for Mobile; è un criterio distinto dalla regola Android sulle autorizzazioni. Le regole per Chromebook non sono automaticamente regole per Android/iOS.

Il sottoinsieme IXM gestito è documentato in entrambe le guide, per Sophos Mobile e per Sophos Mobile Threat Defense. Per i dispositivi la cui app IXM è gestita da Sophos Mobile, indica queste corrispondenze:

Managed required si applica ad Android e iOS. La regola definisce la reazione quando un dispositivo non è più gestito. Non equivale a Device administrator management allowed e non dimostra una gestione MDM completa.
Minimum OS version e Maximum OS version si applicano ad Android e iOS in questo sottoinsieme. Definiscono rispettivamente la versione minima richiesta e la versione massima consentita del sistema operativo. L’assenza di un elenco di piattaforme nel catalogo generale descritto più avanti non modifica questa corrispondenza.
Malware apps allowed si applica qui solo ad Android. La regola stabilisce se sono consentite le app dannose rilevate da IXM.
PUAs allowed si applica qui solo ad Android. La regola stabilisce se sono consentite le app potenzialmente indesiderate rilevate da IXM.

Le due regole sulle app valutano la conformità. Non sono impostazioni di scansione né autorizzano a sbloccare le app rilevate o a escluderle dalle scansioni future. Le conseguenze dei rilevamenti e le eccezioni vengono verificate separatamente nella guida alla risposta a un incidente di conformità collegata più avanti.

Una regola Maximum interval between … synchronizations è una regola di conformità configurabile per la rispettiva fonte di sincronizzazione: il software MDM nativo del sistema operativo, Sophos Mobile Control, IXM o Sophos Chrome Security. Nel catalogo generale si applica questa corrispondenza:

Native MDM: iPhone/iPad senza Sophos Mobile Control o IXM, nonché Mac e computer Windows.
SMC (Sophos Mobile Control): dispositivi Android e iPhone/iPad.
Intercept X for Mobile: dispositivi Android e iPhone/iPad.
Sophos Chrome Security: Chromebook.

Ognuna di queste regole limita l’intervallo massimo consentito tra le sincronizzazioni del rispettivo agente con Sophos Fusion; non scambiare agenti e valori temporali. Maximum interval between Intercept X for Mobile scans, invece, limita su Android l’intervallo tra le scansioni antimalware IXM, non tra le sincronizzazioni. Un intervallo superato va valutato solo in base alla regola effettivamente attivata e violata e all’ora della sincronizzazione o della scansione corrispondente. Distintamente, una sincronizzazione ritardata o non riuscita può rendere non aggiornato lo stato di conformità visualizzato; da sola non dimostra né una violazione della regola né la conformità. Uno stato sconosciuto all’EAS Proxy è un caso ancora diverso, nell’ambito del flusso di quarantena Exchange configurato separatamente, e non costituisce automaticamente una violazione della regola sull’intervallo massimo.

Selezionare le regole in base al controllo da svolgere

I gruppi seguenti organizzano il catalogo generale delle regole dell’edizione completa di Sophos Mobile ai fini della pianificazione. Non sono un elenco di valori predefiniti raccomandati. Verificare prima edizione e modalità di gestione, poi selezionare solo i criteri appropriati e controllare separatamente la reazione di ogni regola.

Stato di gestione, versioni e aggiornamenti

Managed required / Device administrator management allowed: la prima regola riguarda i dispositivi che non sono più gestiti; la seconda definisce le azioni per i dispositivi Android su cui Sophos Mobile stesso è impiegato come Device Administrator. Questa modalità di gestione è obsoleta in Sophos Mobile ed è disponibile solo su Android 9 o versioni precedenti; non può essere utilizzata su Android 10 o versioni successive. Sophos raccomanda la migrazione ad Android Enterprise. È un limite di questa modalità di gestione di Sophos Mobile, non un’affermazione secondo cui le API Android Device Administrator siano state rimosse in generale, né una guida alla registrazione di nuovi dispositivi in tale modalità.
Minimum SMC version: versione minima consentita dell’app Sophos Mobile Control, per Android e iPhone/iPad. Non confonderla con la versione IXM o del sistema operativo.
Minimum OS version / Maximum OS version: versione minima o massima consentita del sistema operativo. Il catalogo non indica un elenco specifico di piattaforme per queste due voci; verificarne la disponibilità nella scheda della rispettiva piattaforma.
Mandatory OS updates: per iPhone/iPad supervisionati, non per Apple User Enrollment. Latest available update richiede l’ultimo aggiornamento disponibile; Latest critical update l’ultimo aggiornamento classificato come critico da Apple. L’ultimo aggiornamento disponibile può essere più recente dell’ultimo critico. Latest critical update non è disponibile da iOS/iPadOS 27 in poi. Per gestire gli aggiornamenti di questi dispositivi, Sophos indica una policy dichiarativa con Software update settings o Enforced software update; non dedurne che la precedente opzione di conformità mantenga lo stesso effetto. Software update settings richiede iOS/iPadOS 26 o successivo, la modalità di gestione Apple Device Enrollment e un dispositivo supervisionato. Per Enforced software update, Sophos indica come requisiti iOS/iPadOS 26 o successivo e Apple Device Enrollment, senza elencare un ulteriore requisito di supervisione. Questa versione minima 26 va distinta dal limite 27 della precedente opzione Latest critical update.

Le informazioni sugli aggiornamenti Apple richiedono un percorso di rete dedicato: per ottenere informazioni sugli aggiornamenti disponibili su iPhone, iPad e Mac, mesu.apple.com deve essere raggiungibile tramite HTTPS 443. Se questa destinazione non è raggiungibile, Sophos Mobile non dispone delle informazioni sugli aggiornamenti; le regole di conformità relative agli aggiornamenti obbligatori non hanno quindi effetto. Verificare il percorso effettivo con l’amministrazione di rete prima di considerare affidabile lo stato di una regola di questo tipo. Questo non estende i limiti di piattaforma, sistema operativo o registrazione di Mandatory OS updates indicati sopra e non afferma che tutte le installazioni degli aggiornamenti Apple falliscano.

Protezione del dispositivo e separazione dei dati di lavoro

Root access allowed (Android): stabilire se sono ammessi dispositivi con privilegi di root. L’autorizzazione documentata comprende anche i dispositivi Sony con Enterprise API Level 4 o successivo e i dispositivi Samsung con Knox Standard SDK 5.5 (API Level 17) o precedente classificati come non sicuri dal sistema operativo. Sono precisazioni storiche della guida della regola, non raccomandazioni per utilizzare oggi questi dispositivi.
Android Debug Bridge (ADB) allowed (Android): stabilire se l’interfaccia di debug ADB è consentita o vietata.
Allow jailbreak (iPhone/iPad): stabilire separatamente se sono ammessi dispositivi con jailbreak; non trasferire la regola Android relativa al root.
Screen lock required (Android, iPhone/iPad, Windows): stabilire se è richiesta una password del dispositivo o un altro meccanismo di blocco. Su Android valgono Pattern, PIN e Password, non Swipe. Con Apple User Enrollment, la regola è soddisfatta se la policy assegnata contiene una configurazione Password policies.
Encryption required (Android, Mac, Windows): richiedere la crittografia; su macOS la regola riguarda la crittografia completa FileVault. Secondo la guida della regola, iPhone e iPad sono sempre crittografati e non figurano nell’elenco delle piattaforme a cui questa regola si applica.
Container configured (Android): deve essere configurato e attivato un container, ad esempio un profilo di lavoro Android o un container Samsung Knox. È un criterio relativo allo stato, non la reazione Lock container.
Data roaming allowed: consentire o vietare il roaming dati, per Android e iPhone/iPad senza Apple User Enrollment.

Non applicare un rimedio generico alla crittografia Android: la guida attuale della regola contiene ancora il riferimento a Require PIN to start device o Require Password to start device durante la configurazione del blocco schermo. Questo non dimostra che l’opzione PIN/password all’avvio sia disponibile nelle versioni Android attuali o in tutte le modalità Android Enterprise. La KBA-000004067, separata, descrive un caso di errore in cui viene mostrata la chiave di crittografia standard e indica PIN all’avvio e sincronizzazione manuale come rimedio, senza specificare versione del sistema operativo o modalità di registrazione; non è un rimedio universale per le versioni Android attuali o per le modalità Android Enterprise. Prima di intervenire sul dispositivo, accertare l’errore effettivamente osservato, la versione del sistema operativo supportata e la modalità di registrazione; non raccomandare genericamente di cambiare il PIN o usare Synchronize now.

App, profili e autorizzazioni

Installed apps: selezionare prima Allowed apps o Forbidden apps, poi il gruppo di app contenente le app consentite o vietate. Si applica ad Android, iPhone/iPad senza Apple User Enrollment, Mac e Chromebook. Le app di sistema Android sono sempre consentite; i gruppi di app Chrome OS possono contenere app ed estensioni.
Mandatory apps: selezionare dall’elenco il gruppo di app che devono essere installate. I gruppi Chrome OS possono contenere anche estensioni. Su iOS non inserire app di sistema tra quelle obbligatorie: Sophos Mobile non riesce a rilevarne l’installazione e, secondo la guida della regola, segna come non conformi tutti i dispositivi interessati. Per Android, Sophos descrive in SMCAND-3159 come gli aggiornamenti di più app in parallelo durante una sincronizzazione dell’app Control con il backend Mobile possano far passare brevemente lo stato a non conforme e poi di nuovo a conforme, soprattutto sui dispositivi meno recenti. Per interpretare il caso in sola lettura, confrontare la regola effettivamente violata, i momenti degli aggiornamenti e della sincronizzazione e lo stato osservato successivamente. Questo non giustifica un allentamento della regola sulle app obbligatorie. Da un successivo stato conforme non dedurre né un funzionamento privo di conseguenze né il ripristino dell’accesso alle app, alla posta o a Wireless; il ritorno automatico alla conformità descritto nella documentazione non è un risultato osservato qui e non garantisce un termine entro cui avverrà.
Suspicious apps allowed (Android): stabilire se sono consentite le app sospette rilevate da IXM. È un’opzione di conformità distinta, non automaticamente equivalente alle impostazioni di scansione per le app con bassa reputazione.
Third-party profiles allowed (iPhone/iPad, senza Apple User Enrollment): stabilire se sono ammessi profili di configurazione non gestiti da Sophos Mobile.
Unmanaged apps from unknown sources allowed (iPhone/iPad): stabilire se sono ammesse app sviluppate internamente, installate manualmente tramite un file IPA e firmate con un profilo di provisioning ad hoc. Non equipararla alla regola Chromebook per le app esterne al Chrome Web Store.
SMC permissions can be denied (Android): per funzionare, l’app Control richiede autorizzazioni che devono essere concesse durante l’installazione. La regola stabilisce se negarle provoca una violazione della conformità. Si tratta di un’app diversa da quella della regola Intercept X for Mobile permissions can be denied descritta sopra.
Locate permission required (Android): per la funzione Locate, stabilire se l’autorizzazione dell’app Control ad accedere ai dati di posizione, concessa durante l’installazione, è necessaria per la conformità.
App is able to locate (iPhone/iPad): i servizi di localizzazione devono essere attivi e l’app Control deve essere autorizzata a usarli. Questa combinazione è distinta dal criterio Android relativo all’installazione. Nessuna delle regole di localizzazione concede un’autorizzazione organizzativa o legale a raccogliere dati di posizione.

Verificare in modo mirato Chromebook, Mac e Windows

Chromebook: le regole seguenti riguardano Sophos Chrome Security, non l’app Control per Android:

Tamper protection turned off: scegliere le reazioni per il caso in cui la Chrome Security policy sia stata manomessa.
Minimum Sophos Chrome Security version: stabilire la versione minima consentita dell’estensione Chrome Security.
Apps from unknown sources allowed: stabilire se sono ammesse app ed estensioni esterne al Chrome Web Store.

Mac: i criteri riguardano la rispettiva protezione attivata, non dimostrano che sia la regola di conformità stessa ad attivarla:

Firewall required: il firewall macOS deve essere attivo.
System Integrity Protection required: SIP deve essere attivo. Questa funzione di protezione macOS limita le azioni dell’utente root; è possibile configurarla avviando il sistema da macOS Recovery. Ciò non autorizza a modificare SIP durante il normale funzionamento.
Security updates required: l’installazione automatica degli aggiornamenti di sicurezza macOS deve essere attiva. La guida della regola la limita a macOS 26 (Tahoe) o precedente; questo limite non coincide con quello di iOS/iPadOS 27 relativo alla regola degli aggiornamenti mobili.

Computer Windows: selezionare tre criteri Defender distinti e non dedurli da un solo stato:

Windows Defender must be turned on: la protezione in tempo reale di Windows Defender deve essere attiva. Questo resta il criterio previsto. Per Windows 10, tuttavia, Sophos descrive in SMCSRV-13801 un limite del controllo: la regola verifica solo che il servizio Defender sia in esecuzione, non che la protezione in tempo reale sia attiva. Un dispositivo può quindi risultare conforme anche con la protezione disattivata. Prima di fare affidamento sulla protezione, verificare separatamente e in sola lettura la protezione in tempo reale effettiva sul dispositivo Windows 10 interessato, senza modificare interruttori di protezione o criteri. Un servizio in esecuzione e lo stato di conformità non sostituiscono questa verifica sul dispositivo.
Clean status from Windows Defender required: il dispositivo non è conforme se Windows Defender mostra avvisi.
Up-to-date Windows Defender definitions required: Windows Defender deve utilizzare le definizioni spyware più recenti.

Non confondere le reazioni con le regole

Create alert crea, nell’edizione completa, un evento visibile nella pagina dei dettagli del dispositivo e un avviso; Threat Defense descrive gli avvisi in Sophos Fusion. Un avviso non equivale a un blocco configurato della posta elettronica o del container. Scegliere soltanto Create alert, però, non garantisce né che la health del dispositivo resti invariata né che l’accesso Wireless non cambi; la non conformità può avere anche altre conseguenze.
Deny email è una reazione configurata alla violazione di una regola del criterio nell’edizione completa; richiede una connessione configurata al Sophos Mobile EAS Proxy ed è prevista per Android, iPhone/iPad e Windows. La sola presenza di un EAS Proxy non dimostra né l’autenticazione del servizio di posta interessato né che la consegna sia stata effettivamente interrotta o ripristinata. Separatamente, Sophos descrive una quarantena Exchange per dispositivi non registrati solo con EAS Proxy in modalità PowerShell e una regola di accesso predefinita di Exchange configurata di conseguenza. In questo caso, anche i dispositivi registrati possono finire in quarantena se il loro stato di conformità è sconosciuto al proxy a causa di un intervallo troppo lungo dall’ultima sincronizzazione o dell’assenza di collegamento a Sophos Mobile. La notifica di registrazione inviata da Exchange durante la quarantena non è né Create alert né la prova che sia stato attivato Deny email. Non dedurre da una violazione di una regola o da un avviso né una quarantena generalizzata né un ripristino automatico della posta; l’indagine rientra nella risposta agli incidenti, non in questa pianificazione dei criteri.
Lock container nell’edizione completa attuale è previsto per Android Enterprise, non come blocco del container iOS accertato. La tabella generale delle azioni di conformità dell’edizione completa descrive questa azione configurata come blocco di tutte le app tranne Sophos Mobile Control, Sophos Intercept X for Mobile, Google Play Store, Contacts, Messages e Phone. La descrizione generale non specifica l’effetto sulle app del profilo personale BYOD; né le sei eccezioni né l’esempio del profilo di lavoro che segue dimostrano che le app personali rimangano accessibili. Per un profilo di lavoro Android supportato, Sophos documenta le impostazioni della gestione separata dell’accesso Auto (impostazione predefinita senza autorizzazione manuale: il profilo di lavoro viene bloccato se una regola di conformità violata include Lock container), Deny (profilo di lavoro bloccato) e Allow (profilo di lavoro sbloccato). Quando il profilo è bloccato, le sue app e i suoi dati non sono accessibili; l’impostazione viene applicata solo dopo la sincronizzazione del dispositivo. Questo controllo di accesso al profilo di lavoro è distinto dal comando di blocco dell’intero dispositivo; non dimostra né l’effetto dell’azione di conformità configurata sulle app personali, né la sua disponibilità per ogni scenario BYOD/di registrazione, né una procedura di ripristino verificata. Verificare ambito ed effetto su un dispositivo autorizzato prima di approvare l’adozione.
Distinguere Set health dalla health calcolata: nell’edizione completa Set health è un’azione scelta esplicitamente per ogni regola: quando questa viene violata, si assegna il valore selezionato Rosso/Giallo/Verde; se più regole sono violate, prevale il peggiore dei valori di health assegnati. Per Android, iPhone e iPad, l’azione richiede che Synchronized Security sia attivata; per ottenere un effetto Wireless intenzionale occorre inoltre configurare nel criterio il valore di health relativo alla non conformità e le regole Wireless. Separatamente, Fusion mostra una health del dispositivo basata sulle violazioni delle regole di conformità; quando Synchronized Security è attiva, la si può sovrascrivere manualmente, mentre Auto ripristina il calcolo basato sullo stato di conformità. Non è chiarito quale valore risulti senza l’azione Set health in ogni edizione e modalità, né come venga stabilita la priorità tra una sovrascrittura manuale e un’azione della regola concomitante; da Create alert non dedurre né un’assegnazione automatica di Rosso/Giallo né che la health rimanga invariata. Verificare separatamente la regola violata e la non conformità, l’azione Set health salvata, la health visualizzata e la modalità manuale/Auto, il valore comunicato a Wireless e l’accesso effettivo. Sophos Wireless può limitare l’accesso alla rete in base alla configurazione; la sola indicazione nella console non dimostra un determinato effetto su Wireless.
Transfer task bundle può configurare erroneamente i dispositivi o perfino cancellarli. Non impostare attività di wipe/reset o task bundle automatici come reazione standard; None significa soltanto che non viene trasferito alcun task bundle, non che la non conformità sia priva di conseguenze.

Caso particolare: su un dispositivo Android Enterprise fully managed non conforme, nell’edizione completa vengono disattivate automaticamente tutte le app, indipendentemente dalla reazione scelta per ogni regola. Questo non equivale all’azione configurabile Lock container e non è un effetto documentato per dispositivi Android BYOD/con profilo di lavoro, per dispositivi che usano solo MTD o per altre modalità Android. In Android BYOD, l’effetto di Lock container dipende dalla modalità di gestione effettivamente supportata e dalla configurazione; non dedurre il blocco dell’intero dispositivo da un possibile blocco dell’area di lavoro. Prima di qualsiasi approvazione, verificare su un dispositivo di test autorizzato l’accessibilità del telefono, dell’area di lavoro e delle app critiche, nonché la procedura di ripristino.

Synchronized Security non è disponibile per tutti i dispositivi: Sophos esclude Chromebook, Apple User Enrollment e dispositivi con indirizzo MAC specifico della rete, privato o randomizzato, perché non comunicano il proprio indirizzo MAC a Sophos Mobile. La possibilità distinta di passare l’indirizzo MAC mediante la configurazione dell’app IXM con un EMM di terze parti non dimostra un’eccezione per gli indirizzi MAC privati/randomizzati. Pianificare un pilota Wireless soltanto con una modalità di dispositivo e registrazione effettivamente supportata e dopo aver verificato la configurazione MAC e di Synchronized Security; la sola visualizzazione della health non sostituisce una prova di accesso.

Assegnazione graduale invece di un test globale

Rilevare dispositivi e prerequisiti: registrare tenant, licenza/edizione, modalità di gestione, piattaforma/sistema operativo, proprietà, stato di gestione IXM, ultima sincronizzazione, regole esistenti e dipendenze attive da EAS Proxy e Sophos Wireless. Documentare l’idoneità a Synchronized Security e i limiti relativi agli indirizzi MAC, la health visualizzata del dispositivo con modalità manuale/Auto, le regole Wireless esistenti, i criteri e le relative assegnazioni.
Valutare separatamente ogni regola e azione: aprire il catalogo aggiornato delle regole dell’edizione corretta del prodotto; per ogni piattaforma attivata, inventariare ogni regola ereditata dal modello o impostata manualmente, insieme alla sua reazione. Verificare segnale, modalità e prerequisiti dell’azione prima di Save e prima dell’assegnazione; non considerare PCI/HIPAA modelli passivi. Per un pilota approvato, pianificare un nuovo criterio isolato senza azioni di blocco o distruttive e ricontrollare le azioni effettivamente salvate. L’assenza di Set health non dimostra che la health calcolata o impostata manualmente, né l’accesso Wireless, rimangano invariati. Importante: anche il solo Create alert o None per un task bundle non impediscono la disattivazione automatica documentata delle app su un dispositivo Android Enterprise fully managed non conforme. Escludere tali dispositivi da questo pilota finché non sia stata autorizzata e preparata una prova specifica per dispositivo, versione e modalità dell’accessibilità delle app e del ripristino.
Selezionare un gruppo pilota circoscritto: considerare separatamente i dispositivi aziendali e personali previsti. Se per il pilota approvato occorre un nuovo gruppo, prima preparare il gruppo di dispositivi e verificarne l’ambito. Se vengono gestiti entrambi i tipi di proprietà, Sophos raccomanda criteri di conformità distinti per i dispositivi aziendali e personali; la sola presenza di due campi di assegnazione separati non significa che vengano utilizzati criteri diversi. In Device groups > [nome del gruppo] > Compliance policies, le assegnazioni corporate e personal sono distinte. Prima di Save, verificare per ogni dispositivo destinatario il suo unico gruppo di dispositivi attuale (anche il gruppo Default esistente, se assegnato), il tipo di proprietà (corporate/personal) e il criterio assegnato a quel gruppo, per evitare un’estensione involontaria. Dopo aver selezionato i criteri per corporate e personal e averne verificato l’ambito, fare clic su Save per salvare l’assegnazione al gruppo. Nella pagina Device groups, confrontare poi entrambe le colonne Compliance policy (corporate) e Compliance policy (personal) del gruppo scelto con l’assegnazione prevista. Prima di modificare un criterio esistente condiviso, controllare tutti i gruppi a cui è assegnato; la modifica può interessare anche altri gruppi, non perché un dispositivo appartenga a più gruppi. Un nuovo pilota isolato non deve modificare tacitamente un criterio condiviso.
Verificare gli effetti nel pilota autorizzato: prima di generare intenzionalmente una violazione, accertarsi di nuovo che nel pilota con soli avvisi o senza azioni non siano presenti dispositivi Android Enterprise fully managed; Create alert o None non proteggono le loro app. Solo dopo, confrontare l’assegnazione al gruppo e il singolo dispositivo, compresi il nuovo valore di conformità, la regola violata, l’ora della sincronizzazione ed eventualmente avviso/evento. Sul dispositivo di test supportato, osservare separatamente prima e dopo la violazione l’azione Set health effettivamente salvata, la health visualizzata e la modalità manuale/Auto; se Synchronized Security è attiva, osservare anche la health comunicata, la regola Wireless e l’accesso Wireless effettivo. Se la configurazione lo richiede, verificare anche il flusso della posta e l’accessibilità delle app. Anche senza un’azione Set health non presumere che l’accesso alla rete resti invariato; non interpretare una sincronizzazione ritardata o assente come conformità. Provocare intenzionalmente una violazione solo dopo aver confermato la procedura di ripristino e senza mettere a rischio i dati di produzione. Prima di estendere il pilota ai dispositivi Android Enterprise completamente gestiti, verificare su un dispositivo autorizzato se la conseguenza automatica documentata si verifica nella versione e nella modalità effettive e se il ripristino funziona.
Estendere solo dopo l’approvazione: confrontare con la situazione iniziale i dispositivi interessati e le violazioni inattese. In caso di anomalie, interrompere l’estensione, ripristinare previa autorizzazione le precedenti assegnazioni ai gruppi e le configurazioni documentate di regole/azioni e verificare nuovamente il ripristino sul dispositivo e nei servizi esterni. Rimuovere una regola non annulla automaticamente task bundle o wipe già eseguiti né i blocchi dell’accesso applicati da servizi esterni.

Non usare come test: Compliance policies > Check now interessa tutti i dispositivi registrati ed esegue le azioni configurate, anche se si intendeva coinvolgere soltanto un piccolo gruppo. Prima di una verifica globale pianificata, occorre controllare tutti i gruppi e le reazioni e ottenere l’approvazione della modifica; questo articolo non autorizza a premere il pulsante nel tenant di produzione.

Solo esempio di pianificazione, non verificato: un gruppo appositamente approvato con un iPhone aziendale (non Apple User Enrollment né Android Enterprise fully managed), una regola non distruttiva già verificata come applicabile e Create alert potrebbe costituire un pilota circoscritto. Prima dell’assegnazione, rilevare tutte le coppie regola/azione e le appartenenze ai gruppi nonché, se Wireless fa parte della prova, l’idoneità a Synchronized Security e la configurazione MAC e Wireless. In caso di violazione autorizzata e reversibile, nell’edizione completa verificare la violazione/non conformità e l’evento nella pagina dei dettagli del dispositivo nella console, nonché l’avviso nella console; nell’edizione autonoma Sophos Mobile Threat Defense verificare l’avviso nella pagina Alerts di Sophos Fusion. Separatamente, verificare la health visualizzata (manuale/Auto) e, sul dispositivo destinatario, il flusso della posta, l’accessibilità delle app e l’accesso Wireless effettivo prima e dopo la sincronizzazione. Non dedurre da Create alert che la health o l’accesso alla rete rimarranno invariati. Interrompere se sono coinvolti altri dispositivi, manca la sincronizzazione o si rilevano variazioni inattese della health o dell’accesso; non estendere il pilota, ripristinare previa autorizzazione l’assegnazione precedente e verificarne nuovamente gli effetti. Questo è un piano di verifica, non un risultato osservato.

Ambito e prerequisiti per l’uso

L’indagine su un dispositivo già anomalo o bloccato, la valutazione degli avvisi, la gestione dei falsi positivi e il ripristino dell’accesso e-mail/Wireless non fanno parte di questa guida alla pianificazione dei criteri. Non sostituisce una procedura per gli incidenti o per il reset. Un intervento sul PIN all’avvio di Android o una sincronizzazione manuale tratti dalla KBA-000004067 non sono rimedi generali senza aver verificato l’errore concreto e la combinazione supportata di dispositivo e modalità di registrazione. Per la prima valutazione in sola lettura e la verifica dell’accesso Wi-Fi, consultare la guida sulla risposta a un incidente di conformità; neppure questa concede un’autorizzazione operativa.

Le procedure descritte non sono state validate su dispositivi o in un tenant. Questo articolo non concede un’autorizzazione operativa. La relazione tra l’azione Set health selezionata, la health calcolata automaticamente o sovrascritta manualmente e l’effetto su Wireless non è qui risolta per ogni modalità. Le combinazioni di regole e azioni per edizione, sistema operativo e modalità, nonché le procedure di ripristino per EAS/Wireless e l’accessibilità delle app Android, devono essere autorizzate e verificate su dispositivi specifici prima dell’adozione operativa.