Sophos Mobile Threat Defense su Android: pianificare in sicurezza la policy di protezione

Bozza: non è una procedura operativa approvata. Una policy Mobile Threat Defense per Android configura Sophos Intercept X for Mobile (IXM) quando l’app è registrata in Sophos Mobile. Non è una policy per dispositivi Android Enterprise né dimostra che siano attivi la gestione MDM completa, il filtraggio web o l’integrazione MTD con Intune. Sophos Mobile Threat Defense consente di gestire IXM e Sophos Chrome Security, mentre Sophos Mobile include le funzioni di Device Management e Threat Defense. Sophos Mobile Device Management da solo non dà diritto a MTD: per la gestione di IXM qui descritta occorre una licenza Sophos Mobile o Sophos Mobile Threat Defense. Verificare licenza, diritti amministrativi, registrazione dell’app e modalità del dispositivo nel tenant effettivo. La guida alle licenze Mobile spiega la verifica in Profile icon > Licensing in Sophos Fusion.

Sui dispositivi Android Enterprise gestiti da Sophos Mobile, la policy MTD installa IXM; prima di assegnarla, l’app deve essere aggiunta a Sophos Mobile come app Google Play gestita. Questo prerequisito riguarda il percorso di gestione Mobile Enterprise, non indistintamente tutti i tenant Threat Defense con sola gestione dell’app. Verificare la voce nel catalogo Play, il collegamento Android Enterprise e la prova limitata dell’installazione seguendo Preparare Managed Google Play e distribuire le app; non modificare senza verifica una configurazione dell’app condivisa. Per un altro percorso di registrazione, verificare separatamente installazione e registrazione di IXM; un’app visibile non dimostra che entrambi i passaggi siano riusciti.

Fermarsi prima di assegnare Web Filtering: con Android Enterprise e profilo di lavoro, la configurazione MTD Android Web Filtering non si applica: IXM nel profilo di lavoro non può accedere al Sophos Accessibility Service necessario. Né una voce di policy salvata né un’app visibile rendono efficace il filtro in tale modalità. Quando Web Filtering è attivo su un dispositivo idoneo, blocca tutti i siti web se https://4.sophosxl.net/lookup non è raggiungibile. Verificare prima dell’attivazione l’accesso al servizio di classificazione, l’autorizzazione al servizio di accessibilità, i browser idonei, un canale di comunicazione alternativo indipendente e un progetto pilota ristretto. Non presumere di poter aggirare il limite del profilo di lavoro spostando l’app nell’area personale senza averlo verificato.

Ambito e decisioni prima delle modifiche

Rilevare tenant, edizione e licenza MTD effettiva, ruolo, dispositivo/versione Android, Android Enterprise completamente gestito, profilo di lavoro o modalità di gestione dell’app verificata separatamente, registrazione di IXM in Sophos Mobile e stato delle policy esistenti. La proprietà personale del dispositivo non equivale a un profilo di lavoro e MTD non implica automaticamente MDM. La registrazione del dispositivo in un EMM di terze parti non sostituisce la registrazione dell’app IXM in Sophos Mobile. Il percorso separato di registrazione automatica di IXM tramite EMM di terze parti richiede impostazioni personalizzate dell’app, una configurazione di enrollment IXM preparata e un Connection code. Questo percorso non è utilizzabile insieme a Intune Mobile Threat Defense già configurato; non si tratta di un divieto generale per tutti i dispositivi gestiti da Intune. Chiarire percorso adatto, associazione del codice e dell’utente, installazione e registrazione seguendo Registrare Intercept X for Mobile. Questo documento non autorizza né tale procedura di enrollment tramite EMM né l’uso di un fornitore EMM qualsiasi. Confermare nel sistema di destinazione la combinazione supportata di versione Android, edizione e modalità dell’app; non dedurla dal titolo della policy.
Solo per il gruppo di test approvato, registrare il tipo di policy interessato, l’appartenenza a dispositivi o gruppi, le autorizzazioni necessarie all’app e lo stato precedente. Creazione, assegnazione, logica dei conflitti e dei gruppi e ripristino seguono la procedura separata Assegnare le policy: in Policies > [Plattform] > Create, scegliere il tipo MTD adatto, inserire nome e descrizione e verificare la configurazione Network aggiunta automaticamente. Aggiungere le altre aree previste tramite Add configuration e aprirne le impostazioni; verificare ogni configurazione prima di Save. Assegnare quindi la policy soltanto ai destinatari approvati. Questo testo non stabilisce una priorità universale tra policy concorrenti. Registrazione e distribuzione dell’app restano attività separate.
Prima di un progetto pilota del filtro web, verificare che IXM funzioni fuori dal caso non supportato del profilo di lavoro, che l’autorizzazione di accessibilità sia effettivamente disponibile e che l’URL del servizio sia raggiungibile dalle reti previste. Preparare pagine di test appropriate, dipendenze di browser e app aziendali critici, eccezioni approvate e un canale di comunicazione alternativo raggiungibile. Se i prerequisiti non sono confermati, non assegnare la policy.

Antivirus: scansione delle app ed eccezioni

La configurazione Android Antivirus gestisce la protezione antimalware. Dopo l’assegnazione, l’utente non può più modificare autonomamente le relative impostazioni di IXM. Valutare i campi singolarmente; attivare una scansione non garantisce che ogni oggetto venga rilevato o che un elemento rilevato venga rimosso automaticamente.

Update mode determina quando IXM scarica le informazioni aggiornate sul malware. La connessione dati scelta deve essere disponibile sui dispositivi previsti; un’opzione di aggiornamento attivata non equivale a un aggiornamento completato.
Scheduled scan interval determina la frequenza. Daily while charging avvia una scansione solo dopo più di 30 minuti di collegamento a una fonte di alimentazione; non garantisce una scansione completata ogni giorno.
Le app installate vengono controllate per impostazione predefinita. Scan system apps include le app di sistema normalmente escluse, protette da Android e non disinstallabili dagli utenti.
Scan storage esamina anche i file nella memoria interna condivisa, sulle schede SD e sui supporti USB collegati. Monitor storage sorveglia le modifiche in tali posizioni ed esamina i file appena salvati. Queste opzioni possono aumentare il carico di scansione e coinvolgere file privati: chiarire preventivamente proprietà del dispositivo, autorizzazioni, volume dei dati e aspetti di privacy.
Detect PUAs controlla le applicazioni potenzialmente indesiderate: non sono necessariamente dannose, ma possono comportare rischi per privacy, sicurezza o utilizzo in ambito aziendale. Enable user to allow PUAs consente agli utenti di autorizzarle; un’app così autorizzata viene ignorata nelle scansioni successive. Non trattare quindi rilevamento e autorizzazione come un’unica opzione.
In Apps with low reputation > Mode, Allow disattiva proprio questo controllo. Warn mostra un avviso; gli utenti possono autorizzare l’app e sopprimere ulteriori avvisi per essa. Block impedisce di aprire le app corrispondenti. La scelta deve rispettare le regole approvate per le eccezioni, non dipendere solo dal numero di notifiche fastidiose.
Scan notification controlla le notifiche dopo la scansione di un’app al momento dell’installazione. Se la casella è deselezionata, non vengono generate notifiche per le app pulite; ciò non significa che tutte le notifiche di rilevamento siano disattivate o che le app non vengano esaminate.
L’App group selezionato esclude le app dalla scansione ed è quindi un’eccezione di sicurezza: mantenerlo ristretto e approvato, senza escludere indiscriminatamente un intero gruppo di app aziendali. Prima della modifica, documentare membri e motivazione operativa; dopo la revoca dell’eccezione, eseguire nuovamente la scansione sullo stesso dispositivo e verificare i risultati.

Distinguere impostazioni locali, scansione e privacy

Nell’app, Settings contiene le opzioni locali di scansione, notifica e aggiornamento. Manage allowed apps mostra le app consentite, che non compaiono nei risultati delle scansioni; dopo la rimozione da questo elenco possono ricomparire in Threats and PUAs. Questo non garantisce che ogni opzione locale resti modificabile quando IXM è gestita. Inoltre, l’opzione locale App reputation non equivale alla scelta centrale Allow/Warn/Block. L’ambito locale di Scan storage indica memoria SD e USB; non estendere quindi automaticamente a ogni interfaccia locale l’ambito centrale descritto sopra, che include la memoria interna condivisa.

Per verificare quanto siano aggiornati i dati, controllare in Settings le voci Version (motore antivirus e dati antivirus) e Last update; toccando Last update si verifica la disponibilità di aggiornamenti. Una data visualizzata non dimostra che una scansione sia appena terminata. Track data to help improve usability consente l’invio di dati di utilizzo anonimi; Send log to Sophos condivide prima i file di trace/log con un’altra app per inviarli al supporto Sophos. Sono decisioni distinte in materia di privacy, non prerequisiti della scansione né una garanzia di assenza di telemetria. Prima di inoltrare i log, approvare contenuto, destinatario, canale di trasmissione sicuro ed eliminazione al termine della finalità; condividere solo i dati diagnostici necessari.

Una scansione manuale locale si avvia in App security > Show scan details > Start. La panoramica App security issues e Show scan details mostrano i rilevamenti; in Threats and PUAs > [App] > Object details si possono verificare origine dell’installazione, autorizzazioni richieste e descrizione della minaccia. Non eseguire automaticamente le azioni Allow o di disinstallazione proposte: chiarire prima autorizzazione, stato di gestione e conseguenze per i dati aziendali. Se la policy non lo impedisce, le scansioni locali programmate si configurano in Settings, attivando Scheduled scans e scegliendo Scheduled scan interval. IXM usa interrogazioni online e un motore di scansione locale; questo non garantisce il rilevamento di tutte le minacce né un’efficacia identica senza connessione di rete.

Un APK già ottenuto legittimamente può essere selezionato nel file manager prima dell’installazione e controllato tramite la funzione di condivisione con Scan with Intercept X. Non usare l’installazione di APK da origini sconosciute come prerequisito dei test: le installazioni esterne a Google Play aumentano il rischio; anche una scansione APK senza rilevamenti non dimostra un’origine attendibile e non autorizza l’installazione.

Avviare una scansione centrale e verificare l’ultimo risultato

In Sophos Fusion, My Environment > Mobile Devices > [Testgerät] > Actions > Scan for malware richiede una licenza Sophos Mobile o Sophos Mobile Threat Defense e un’app IXM per Android gestita da Sophos Mobile: il clic invia un’attività di scansione, non produce immediatamente un rilevamento confermato. Controllare lo stato dell’attività in Open in Sophos Mobile > Tasks. Se l’azione manca, verificare prima installazione e gestione anziché ripetere ciecamente le scansioni.

Nei dettagli del dispositivo in Fusion, aggiornare Scan results con Refresh. L’elenco mostra l’ultima scansione, non una cronologia completa. Type distingue Threat, Suspicious, PUA e Low reputation; Name, Identifier e Version identificano l’app, Threat indica l’eventuale minaccia e Detected at la data di rilevamento. Nel campo di ricerca, filtrare per nome della minaccia o dell’app, versione o Identifier; i filtri sopra l’elenco restringono il tipo di rilevamento. Per ulteriori informazioni sulla minaccia, aprire il nome Threat e poi il risultato omonimo. Rendere identificativi delle app e dettagli dei rilevamenti accessibili soltanto alle persone autorizzate. Risultati vecchi o vuoti non dimostrano che una nuova scansione sia riuscita: verificare insieme stato dell’attività, attualità dei risultati e visualizzazione nell’app sullo stesso dispositivo, senza presumere una rimozione automatica.

Network: sicurezza Wi-Fi, non configurazione della rete Wi-Fi

Network > Man-in-the-middle protection gestisce la funzione IXM Wi-Fi Security, in particolare il controllo degli attacchi man-in-the-middle. In caso di attacco rilevato vengono generati un evento nei dettagli del dispositivo e un avviso. Le impostazioni Network assegnate non possono più essere modificate dall’utente nell’app; impostare Extra settings solo su indicazione del supporto Sophos. Questa non è una configurazione di SSID Wi-Fi, certificati o VPN.

All’attivazione di Wi-Fi Security, a causa del modello di autorizzazioni di localizzazione di Android, l’app richiede l’accesso alla posizione precisa e alla posizione in background: il nome di una rete Wi-Fi può consentire di dedurre la posizione. In questo caso, la richiesta dell’autorizzazione non significa che IXM acquisisca o tracci la posizione; questa affermazione limitata non garantisce che non vengano trattati dati di rete o diagnostici. Concordare l’autorizzazione sensibile con i responsabili della privacy e con il proprietario del dispositivo prima del progetto pilota. Senza autorizzazioni confermate, non presumere che la protezione Wi-Fi funzioni; non aggirare le impostazioni gestite con modifiche personali dell’utente.

Nell’app, in Network security > Wi-Fi Security, Check Wi-Fi controlla la rete attualmente connessa. Background check esegue il controllo quando ci si connette al Wi-Fi, se lo stato di gestione consente l’impostazione. Il controllo comprende manipolazione dei contenuti, SSL interception (intercettazione tramite un certificato falso) e SSL stripping (declassamento da HTTPS a HTTP). Wi-Fi Security non può rilevare lo spoofing ARP (associazione falsa del gateway al MAC dell’attaccante) sui dispositivi con Android 10 o versioni successive a causa di una limitazione di Android (Sophos Known Issue SMSECAND-4570). Anche i captive portal, per esempio la pagina di accesso di un Wi-Fi pubblico, possono generare ulteriori avvisi. L’assenza di un allarme non dimostra che ogni rete sia sicura; osservare separatamente risultato nell’app, autorizzazioni ed eventuale evento centrale, senza simulare un attacco reale.

Web Filtering su Android: effetti, elenchi e autorizzazioni

La configurazione MTD controlla il trattamento dei siti dannosi tramite Filter malicious websites e quello delle categorie di contenuti tramite Filter websites by category. Le categorie vengono aggiornate continuamente; una classificazione non è un dato permanente e immutabile. Create events determina se nei dettagli del dispositivo generano eventi soltanto gli accessi bloccati o anche gli avvisi. Per un progetto pilota approvato, documentare gli eventi selezionati e verificare lì gli eventi di test attesi; l’assenza di una riga di avviso quando sono configurati solo gli eventi di blocco non dimostra, da sola, un errore di protezione.

La classificazione richiede https://4.sophosxl.net/lookup; se il servizio non è raggiungibile, Web Filtering blocca tutti i siti web. Con il filtro attivo, i contenuti criminali più gravi vengono sempre bloccati e gli URL di tali contenuti sono mascherati nei log, negli eventi e nei report, non tutti gli URL. Non accedere a tali contenuti per un test. Per Web Filtering, prevedere di impostare su No la regola di conformità Intercept X for Mobile permissions can be denied, affinché un filtro non funzionante per la disattivazione del servizio di accessibilità venga rilevato come non conforme. Questa non è una riparazione automatica: verificare separatamente azioni ed eventuali conseguenze per accesso e app di una policy di conformità e non configurare reazioni rischiose o modifiche dello stato senza approvazione.

Mantenere ristrette le eccezioni e verificare l’ordine

Le eccezioni non sono una soluzione rapida priva di rischi: la allowlist della policy ha precedenza sulla blocklist della policy; entrambe hanno precedenza sulla allowlist dell’utente. Segue il blocco per categoria. Per l’edizione Threat Defense è descritta anche una blocklist dell’utente tra allowlist dell’utente e blocco per categoria; per l’edizione completa questo passaggio intermedio non è chiarito. Prima di creare un’eccezione, verificare quindi nel progetto pilota l’ordine effettivo, che dipende da edizione e versione, anziché presumere un ordine identico. Un’autorizzazione locale dell’utente non annulla una blocklist della policy; resta da rispettare il blocco obbligatorio dei contenuti criminali più gravi.

Allowed domains consente l’accesso alle pagine anche se la categoria è bloccata; Blocked domains blocca le pagine anche se la categoria è consentita. Entrambi i campi accettano un nome di dominio, un dominio con wildcard, un indirizzo IPv4/IPv6 o una sottorete per riga, senza separatori e senza prefissi di protocollo come https:// o chrome://. Il carattere jolly * deve trovarsi all’inizio. Un singolo * in Blocked domains blocca tutti i siti web nell’ambito del filtro.

Gli esempi di sintassi www.example.com, *.example.com, 203.0.113.0/24 e 2001:db8::/32 sono forme valide, non eccezioni aziendali da copiare. Per un test approvato, scegliere prima un nome di dominio specifico effettivamente necessario e sostituirlo con la propria voce verificata. Una wildcard o una sottorete copre un ambito più ampio di un singolo nome o indirizzo; verificare quindi preventivamente portata e dipendenze delle app necessarie, senza usare voci ampie come soluzione rapida.

Web Filtering può interessare anche il traffico web di app di terze parti e di sistema, nonché risorse caricate successivamente come i caratteri tipografici: wildcard ampie possono rendere inutilizzabili app o siti web aziendali. Provare nel progetto pilota isolato soltanto una singola eccezione approvata e verificabile, registrando l’elenco originale; dopo il test rimuoverla in modo mirato e ricontrollare gli effetti dei blocchi e delle autorizzazioni. Non usare una allowlist globale come presunta soluzione per un servizio di classificazione non disponibile.

Controllare browser e uso locale

I browser supportati sono Android web browser, Firefox, Google Chrome e Microsoft Edge; altri potrebbero funzionare, ma non sono stati testati. Nell’app, Web Filtering è visibile in Network security > Web Filtering. Vi compaiono Malicious content e le categorie con le opzioni Warn e Block, se lo stato di gestione consente le modifiche. Always allow access to this page nella finestra di avviso aggiunge un’eccezione locale; Clear allowed pages list rimuove le eccezioni locali. Non si tratta né di un modo generale per aggirare le regole centrali né della rimozione di una policy MTD. Concordare preventivamente anche una cancellazione estesa delle autorizzazioni locali.

Controllare il browser previsto in Protected browsers; Protected browsers (not tested) non costituisce una verifica di accettazione per altri browser. Se manca un browser supportato installato, controllare nelle impostazioni di sistema Android, in Accessibility, se Sophos Accessibility Service è attivo. L’interfaccia non dimostra che una policy del tenant sia stata effettivamente applicata e non sostituisce il controllo degli effetti della policy e dell’app. Il limite del profilo di lavoro resta valido a prescindere dalle opzioni visibili.

Non presentare Link Checker e Device security come componenti della policy

Link Checker è una funzione separata dell’app che consente di controllare i link provenienti da app diverse dai browser per verificare la presenza di contenuti dannosi o inappropriati. Non può controllare i link aperti internamente a un’app; i link devono essere passati al browser. Non è un ulteriore componente di configurazione delle tre aree MTD qui trattate, Antivirus, Network e Web Filtering, e la loro assegnazione non lo attiva automaticamente.

Attenzione: cambia il browser predefinito. Solo se questa funzione separata dell’app è desiderata e approvata, documentare il browser Android predefinito attuale. In Network security > Link Checker, azionare quindi l’interruttore accanto a Link Checker is turned off, confermare il messaggio con OK, scegliere Intercept X ed eseguire Set as default. Se sono presenti più browser, scegliere quello di destinazione in Checked links open in this browser. Provare un link innocuo passato dall’esterno; per le app con browser interno, valutare separatamente l’impostazione disponibile per aprire i link nel browser. In Gmail si tratta di Open web links in Gmail: disattivarla solo dopo approvazione, se i link devono essere passati al browser. La modifica riguarda l’apertura dei link in questa app e non garantisce la copertura di tutti i link.

Se in Android viene scelto un altro browser predefinito, Link Checker si disattiva. Settings > Clear defaults interrompe l’uso di IXM come app predefinita per i link supportati. Per tornare alla configurazione precedente, ripristinare il browser predefinito documentato e l’eventuale opzione dei link modificata nell’app, quindi verificare di nuovo il passaggio dello stesso link innocuo; questo non rimuove la policy centrale di filtraggio web.

Device security valuta le impostazioni di sicurezza Android e mostra raccomandazioni: verde (Secure), rosso (Insecure), giallo (Unknown, per esempio quando modello/versione Android non consentono una verifica univoca) o grigio (Turned off, non incluso nella valutazione). Non interpretare giallo e grigio come sicuri; neppure il verde dimostra che una policy MTD sia stata applicata. Quando l’app è gestita da Sophos Mobile, le impostazioni di sistema rilevanti per la sicurezza sono configurate dall’organizzazione. Non invitare quindi gli utenti a sovrascrivere le impostazioni gestite; una raccomandazione non è un ulteriore componente di una policy MTD Android.

Verifica limitata e ripristino

Prima: documentare un piccolo gruppo pilota approvato e un dispositivo di test raggiungibile per ciascuna modalità Android effettivamente prevista; versione della policy, registrazione di IXM, stato delle scansioni e delle autorizzazioni, ultimi risultati, pagine di test consentite e bloccate, dipendenze di browser e app aziendali e un canale di comunicazione alternativo indipendente. Per i dispositivi con profilo di lavoro non definire come obiettivo la riuscita del filtro web; non distribuire Web Filtering in tale modalità come protezione efficace.
Dopo l’assegnazione: attendere la successiva connessione/sincronizzazione, controllare sul dispositivo la policy e la configurazione dell’app e osservare separatamente il funzionamento. Per Web Filtering, aprire soltanto pagine di test Web Security & Control innocue e approvate; gli esempi sono innocui nel contenuto nonostante la classificazione usata per i test. Confrontare destinazioni web consentite e bloccate, stato del servizio di accessibilità e controllo Wi-Fi su una rete conosciuta. Verificare separatamente stato e ultimi risultati delle scansioni antivirus; non usare malware reale nei test. Con Create events controllare soltanto gli eventi di test del filtro web previsti; non confondere lo stato dell’attività di scansione con il suo risultato. Un’assegnazione riuscita non prova l’efficacia della protezione. Anche la raggiungibilità del servizio di classificazione dal computer dell’amministratore non ne dimostra la raggiungibilità da IXM nella rete prevista per il dispositivo; verificare questo caso nel progetto pilota approvato, senza provocare intenzionalmente un’interruzione in produzione.
In caso di blocco errato o protezione assente: interrompere l’estensione, tutelare i dispositivi e le dipendenze interessati e circoscrivere la causa: il servizio è raggiungibile? Il servizio di accessibilità è ancora autorizzato? Il problema riguarda un’eccezione, il gruppo di esclusione dalla scansione o l’intera policy? Rimuovere una nuova eccezione introdotta nel progetto pilota oppure ripristinare l’elenco precedente; in caso di modifiche ai gruppi, ripristinare il gruppo destinatario ristretto originale. Se necessario, ripristinare in modo mirato soltanto una versione della policy verificata per il problema in corso oppure assegnare un’alternativa precedentemente verificata. Se il servizio di classificazione è indisponibile, la policy di ripristino non deve attivare anch’essa Web Filtering con la stessa dipendenza dal servizio irraggiungibile; senza un percorso di ripristino raggiungibile e approvato, non apportare altre modifiche e chiedere supporto tramite il canale indipendente. Non «disinstallare» alla cieca una policy MTD come se fosse una policy per dispositivi Android e non rimuovere l’app IXM: le impostazioni MTD modificate vengono sincronizzate alla connessione successiva; il ripristino avviene con una modifica mirata della policy o con l’assegnazione di un’altra policy verificata, non con l’azione MDM di disinstallazione. Sullo stesso dispositivo di test, dopo la successiva connessione a Sophos Mobile, ricontrollare la policy effettivamente applicata, lo stato dell’app e delle autorizzazioni, le destinazioni aziendali consentite, la funzione di protezione e gli eventi. Non disattivare le autorizzazioni del filtro né eseguire test incontrollati con * o una allowlist globale.

Da chiarire prima dell’approvazione: licenza concreta, ruolo amministrativo, versioni Android supportate, modalità MDM/dell’app, autorizzazioni privacy per scansioni e posizione, effettiva disponibilità del servizio di accessibilità e raggiungibilità del servizio, effetti delle eccezioni, gruppo destinatario e percorso di ripristino nel tenant del cliente non sono stati testati. Il responsabile della policy MTD non sostituisce né le istruzioni separate per assegnazione/registrazione né le policy di filtraggio web iOS o MDM Android Enterprise. Prima di assegnare la policy in produzione, verificare la licenza, l’efficacia della policy e il percorso di ripristino su un dispositivo di test autorizzato; senza questa evidenza, non procedere al rollout.