Sophos Mobile: pianificare in sicurezza le regole per le password e i criteri di sicurezza di Windows

Per i criteri Windows in Sophos Mobile, la decisione più importante non è scegliere l’impostazione più rigida, ma predisporre un test pilota recuperabile: confermare l’edizione e lo stato di gestione, verificare il recupero BitLocker prima di un possibile riavvio, censire gli account locali e solo allora assegnare una singola modifica a un dispositivo di prova. Un criterio Windows non è il criterio Device Encryption di Sophos Fusion e non sostituisce una procedura di recupero BitLocker. Per la gestione delle chiavi e il ripristino, vedere Gestire BitLocker con Sophos Fusion.

Prima della prima assegnazione

Piattaforma e ambito di applicazione: Il dispositivo di destinazione deve essere effettivamente gestito come computer Windows tramite Sophos Mobile; Sophos Endpoint Protection da solo non equivale a una registrazione MDM. L’elenco dei requisiti di Sophos Mobile comprende Windows 10/11 Enterprise, Education e Pro, ma non Home; ciò non garantisce che ogni singola configurazione di criterio sia efficace su tutte le edizioni o build elencate. Secondo Sophos, Restrictions non si applica a Pro e Device Guard non si applica né a Pro né a Windows in modalità S. Verificare sul dispositivo specifico l’edizione, la versione di Windows, i requisiti hardware e le direttive GPO/MDM effettive; una vecchia pagina della guida non costituisce un’approvazione valida oggi.
Ciclo di vita: Il supporto Microsoft per le normali edizioni di Windows 10 è terminato il 14 ottobre 2025; le edizioni LTSC/LTSB e i dispositivi con Extended Security Updates (ESU) idonei e attivati vanno valutati separatamente in base a edizione e versione. ESU non estende il ciclo di vita del prodotto Microsoft né il supporto ordinario, ma fornisce aggiornamenti di sicurezza per un periodo limitato ai dispositivi idonei e correttamente registrati. L’elenco dei requisiti di Sophos Mobile (release 2026.38 del 21 settembre 2026) riporta comunque Windows 10 Enterprise/Education/Pro dalla versione 20H2 e Windows 11 Enterprise/Education/Pro. Si tratta di un elenco di piattaforme Sophos, non di una garanzia di supporto Microsoft per le build meno recenti di Windows 10 e non di una prova del funzionamento di ogni criterio Windows. Anche per Windows 11 contano versione ed edizione: per esempio, 23H2 Pro è già fuori dal periodo di supporto agli aggiornamenti Microsoft, mentre per 23H2 Enterprise/Education valgono scadenze diverse. Prima del test pilota, verificare la versione specifica nel ciclo di vita Microsoft Release Health e testare l’impostazione desiderata proprio su quel dispositivo.
Accesso e via di ritorno: Predisporre un accesso di ripristino locale autorizzato, assistenza raggiungibile presso il dispositivo e una finestra di modifica. Se si usa BitLocker, tenere disponibile, secondo la procedura approvata, il Recovery Key corrispondente al dispositivo interessato e al protector attuale e verificarne la disponibilità prima della modifica; non considerare una voce semplicemente presente o obsoleta come un ripristino verificato. Identificare innanzitutto chi gestisce realmente l’attuale BitLocker Recovery Key di questo dispositivo e dove lo conserva (per esempio Fusion Device Encryption o un altro sistema autorizzato di gestione delle chiavi). La sola gestione MDM di Sophos Mobile non dimostra che la chiave sia archiviata in Fusion. Non esporre una chiave Fusion di produzione con Show Key solo per verificare la preparazione al ripristino. Documentare le regole password e le GPO esistenti. Per Device Guard, verificare inoltre lo stato attuale di VBS/Credential Guard, Secure Boot e supporto DMA.
Piccolo gruppo pilota: Non assegnare subito il criterio a un gruppo ampio di dispositivi. Documentare stato iniziale, utenti interessati e modifica visibile prevista. Secondo Sophos, per un criterio Windows non esiste una procedura generale Uninstall policy per tornare indietro; le impostazioni si correggono aggiornando il criterio o assegnandone un altro. Un computer disconnesso o che non si sincronizza non riceverà necessariamente subito tale correzione.

Regole per le password: evitare riavvii e account bloccati

La configurazione Password policies controlla Maximum number of failed attempts, Time in minutes until the device is locked, Password history e Maximum password age in days.

Time in minutes until the device is locked stabilisce dopo quanti minuti di inattività il dispositivo viene bloccato. L’utente può sbloccarlo autonomamente. Questo blocco per inattività è distinto dalla soglia di tentativi falliti che può provocare un riavvio con richiesta di recupero BitLocker. Maximum password age in days stabilisce dopo quanti giorni gli utenti devono cambiare la password.

Password history è il numero di password usate in precedenza che Sophos Mobile conserva per impedirne il riutilizzo; una nuova password non può coincidere con nessuna di esse. Sophos consente il valore 0 per escludere la rispettiva limitazione sui tentativi falliti, sul tempo di blocco e sull’età massima della password. Non è un invito a disattivare tutte le protezioni: occorre scegliere i valori in base al modello degli account e alle possibilità di ripristino e testarli separatamente. La complessità delle password (per esempio lunghezza o classi di caratteri) non si configura con questo criterio Mobile; dipende da Windows e, tra l’altro, dal tipo di account. Non considerare i valori numerici di complessità documentati in passato come impostazioni predefinite universalmente valide per Windows oggi.

Se per l’account interessato è attivo ed effettivo un criterio di complessità di Windows pertinente, durante la creazione o la modifica della password possono essere applicati anche controlli sul nome dell’account e su parti del nome completo o del nome visualizzato. L’applicabilità e le modalità di questi controlli dipendono dal criterio effettivo e dal tipo di account; chiarirle per gli account interessati prima del test pilota. Questo non implica né una regola universale per qualsiasi sequenza di caratteri del nome né una conferma dei requisiti attuali degli account Microsoft.

Prima di attivare «Maximum number of failed attempts»: Sophos descrive, per i computer Windows, un riavvio con richiesta di recupero BitLocker al raggiungimento della soglia. Microsoft precisa per la corrispondente regola MDM di Windows: su un desktop non avviene alcuna cancellazione, ma viene avviato il recupero BitLocker; senza BitLocker attivo, la regola non può essere applicata. Non interpretare quindi una soglia di tentativi falliti né come cancellazione dei dati né come protezione efficace su un dispositivo non cifrato. Prima dell’assegnazione verificare sul dispositivo specifico lo stato di BitLocker e l’effettiva disponibilità dell’accesso di recupero; non provocare intenzionalmente errori di accesso sui dispositivi di produzione. Se oltre all’utente registrato in Sophos Mobile sono presenti altri utenti locali e almeno uno di essi non può modificare la propria password, secondo Sophos questo criterio Password non può essere assegnato. Verificare e correggere le autorizzazioni degli account solo con un intervento separato e approvato; non ampliare alla cieca i diritti degli utenti né eliminare account per imporre il criterio.

Per il test pilota, censire prima gli account e le direttive esistenti, impostare la durata di inattività e l’età massima della password in base al flusso di lavoro e confermare la preparazione al recupero prima di impostare una soglia di tentativi falliti. Dopo l’assegnazione, verificare in sola lettura quale criterio è associato al dispositivo e se la durata di inattività scelta e l’età massima della password diventano effettive. La prova della soglia di tentativi falliti va eseguita esclusivamente in un ambiente di test isolato e autorizzato, con un Recovery Key accessibile. Se compare inaspettatamente una richiesta di recupero BitLocker, non riprovare né tentare altre chiavi a caso: associare gli ID del dispositivo e della chiave e seguire la procedura di ripristino autorizzata del sistema che gestisce effettivamente le chiavi; solo se Sophos Device Encryption custodisce la chiave attuale, vale la procedura di recupero Fusion.

Restrictions: chiarire in anticipo le conseguenze di ogni casella

Restrictions non è una funzione generale di hardening per Pro: Sophos esclude esplicitamente Windows Pro. La configurazione comprende, fra le altre opzioni, Forbid resetting the computer (impedisce il ripristino sia tramite Impostazioni sia tramite Windows RE), Disable VPN settings, Disable Account settings, Forbid Bluetooth, Telemetry level e Forbid manual MDM unenrollment. Bloccare il ripristino o l’annullamento della registrazione MDM può ostacolare in particolare una procedura prevista di assistenza o dismissione. Scegliere una sola impostazione motivata per ogni modifica pilota e verificarne il funzionamento sul dispositivo prima e dopo l’assegnazione.

Forbid manual configuration nella sezione Wi-Fi comporta un rischio particolare: quando viene applicata, elimina i profili già configurati dall’utente e quelli di Wi-Fi Sense. Deselezionare la casella non ricrea automaticamente i profili cancellati. Prima di intervenire, assicurarsi di avere un altro accesso alla rete e alla gestione già testato, oltre a una procedura documentata per ripristinare i profili WLAN necessari. Profili WLAN, certificati e SCEP appartengono alla procedura separata per reti e certificati Windows; senza tali garanzie, non attivare qui il blocco WLAN.

Nell’elenco Sophos, Telemetry level indica i livelli Full, Enhanced, Basic e Security. L’effetto reale su Windows e l’ammissibilità dipendono dall’edizione attuale e dalle direttive Microsoft; l’elenco Sophos non dimostra che ciascun livello funzioni su ogni dispositivo pilota. Anche termini storici dell’interfaccia come Cortana o Wi-Fi Sense non dimostrano un effetto sulle versioni attuali di Windows.

Device Guard: scegliere prima una via reversibile

La configurazione Device Guard di Sophos può attivare la sicurezza basata sulla virtualizzazione (VBS) e Credential Guard. Turn on virtualization-based security (VBS) è il campo specifico per attivare VBS; la selezione in Credential Guard configuration è separata. Secondo Sophos, le impostazioni vengono applicate al primo avvio del computer Windows dopo l’assegnazione del criterio. Prima dell’assegnazione verificare l’hardware e le direttive GPO/MDM esistenti e pianificare un riavvio controllato.

In Platform security level, Sophos distingue due opzioni:

Secure Boot usa le funzionalità di protezione supportate dal dispositivo. Senza Input/Output Memory Management Units (IOMMU), VBS usa la funzione Secure Boot di UEFI; in presenza di IOMMU, usa Secure Boot con protezione dagli accessi diretti alla memoria (DMA).
Secure Boot and DMA protection richiede Secure Boot con protezione DMA. Se il dispositivo non supporta la protezione DMA, questa selezione non attiva VBS.

Verifiche preliminari di Credential Guard prima dell’assegnazione: Solo se si intende attivare Credential Guard sul dispositivo pilota, censire i percorsi di autenticazione e accesso effettivamente usati nel tenant interessato: WLAN o 802.1X cablato, VPN (in particolare PEAP/EAP-MSCHAPv2), SSO NTLMv1, RDP/assistenza remota con credenziali Windows salvate o CredSSP e applicazioni che usano la delega Kerberos non vincolata. Microsoft documenta gli effetti sull’autenticazione: con MS-CHAP e NTLMv1 l’SSO può non funzionare più e potrebbe essere necessario accedere di nuovo manualmente; ciò non significa che questi protocolli siano sempre completamente bloccati. L’autenticazione WLAN/VPN basata su certificati non viene bloccata. Il client Desktop remoto non può inoltrare al computer di destinazione credenziali Windows salvate; CredSSP non può più utilizzare credenziali salvate o SSO, ma è ancora possibile usare credenziali immesse esplicitamente. La delega Kerberos non vincolata, invece, viene bloccata. Verificare le dipendenze aggiuntive solo se sono effettivamente presenti nel test pilota: Chiarire con i responsabili delle identità e delle applicazioni se servono Kerberos PKINIT con RSA anziché Diffie-Hellman o Kerberos DES: Credential Guard blocca PKINIT con RSA e DES; reinserire la password non risolve questi casi. Censire inoltre eventuali Security Support Provider/Authentication Packages (SSP/AP) personalizzati o non Microsoft e le applicazioni che leggono credenziali Windows salvate: queste integrazioni possono smettere di funzionare, soprattutto se richiedono hash delle password LSA o interfacce non supportate. Per i percorsi realmente interessati, concordare prima dell’assegnazione un’alternativa compatibile e un test funzionale rappresentativo; se un percorso critico resta da chiarire, non assegnare Credential Guard. Valutare insieme ai responsabili delle identità e della rete soltanto i percorsi effettivamente pertinenti al dispositivo scelto; prima del riavvio predisporre un accesso alla gestione o alla console locale testato in modo indipendente e una procedura approvata per tornare indietro senza blocco UEFI. Se la normale connessione di rete o di assistenza remota è l’unica possibilità di accesso, non assegnare ancora Credential Guard.

Per un test pilota che richiede la disattivazione da remoto, la scelta pertinente è Credential Guard configuration: Turn on without lock: Sophos indica Turn off o un criterio di gruppo Windows come vie di ritorno. Turn on with UEFI lock non va considerato un interruttore reversibile da remoto. Sophos segnala che per la disattivazione è necessaria la presenza fisica presso il computer; Microsoft documenta una specifica procedura EFI/di avvio con conferma prima del boot. Non attivare questa modalità senza aver predisposto esplicitamente una procedura locale per tornare indietro. Turn off non rimuove un blocco UEFI già impostato. Anche senza blocco UEFI, altre direttive di gestione possono prevalere sulla modifica, oppure Credential Guard può essere già attivato per impostazione predefinita da Windows.

Confrontare lo stato iniziale e quello desiderato sul dispositivo di prova in System Information (msinfo32.exe), alla voce Virtualization-based Security Services Running: Credential Guard deve risultare in esecuzione se la sua attivazione era l’obiettivo del test pilota. Il solo completamento di un’attività del criterio non prova che la funzione sia realmente attiva. Dopo il riavvio, sul dispositivo pilota rappresentativo, utilizzare un account di prova autorizzato per verificare gli accessi e le connessioni effettivamente usati e censiti in precedenza (in particolare 802.1X/WLAN, VPN, RDP/assistenza remota e applicazioni SSO o con delega interessate; se presenti, anche integrazioni PKINIT-RSA/DES e SSP/AP e applicazioni che leggono credenziali Windows salvate), nonché la via di ritorno indipendente; non dedurre dal solo funzionamento di Credential Guard che rete e assistenza funzionino. In caso di discrepanze, controllare prima edizione, Secure Boot/DMA, altri criteri e stato del riavvio; non sperimentare attivando e disattivando il blocco UEFI. Per tornare indietro con without lock, usare il criterio Windows predisposto o la GPO competente, sincronizzare il dispositivo e ricontrollare lo stato dopo il riavvio. Con with UEFI lock, fermarsi e seguire la procedura locale di ripristino Microsoft approvata con accesso fisico.

Non distribuire alla cieca le configurazioni e-mail

La guida Mobile elenca Email account per Exchange Online/Server e IMAP/POP come configurazioni Windows. Per i segnaposto come %_EMAILADDRESS_% e %_USERNAME_%, i campi Exchange Login e Email Address dell’utente assegnato devono essere compilati in Sophos Fusion. Con più account Exchange associati a criteri della casella di posta differenti, secondo Sophos Windows può applicare un solo criterio; inoltre, l’utente può rifiutare modifiche alla configurazione Exchange. I campi password in una bozza di criterio non sostituiscono una procedura approvata per la gestione delle identità e dei segreti.

Importante incongruenza rispetto allo stato attuale: Sophos descrive espressamente la configurazione e-mail Exchange per l’app Mail di Microsoft; Microsoft ha terminato il supporto per Windows Mail/Calendar/People il 31 dicembre 2024 e dichiara che non è più possibile inviare o ricevere e-mail o eventi tramite queste app. La pagina Sophos relativa a IMAP/POP non indica alcun client di destinazione attualmente supportato; non è nemmeno dimostrato che tale configurazione venga trasferita al nuovo Outlook. Perciò non fornire qui alcuna procedura per distribuire in produzione questa app di posta né presumere un trasferimento automatico al nuovo Outlook. Verificare prima client di destinazione, autenticazione, criteri della casella di posta e supporto attuale nel tenant specifico e testarli separatamente.

Distribuzione, verifica e annullamento

Dopo i controlli preliminari, creare in Sophos Mobile, sotto Policies > Windows, un nuovo criterio destinato esclusivamente al test pilota. Prima di modificare un criterio esistente, controllare tutti i dispositivi e i gruppi a cui è assegnato: le modifiche a un criterio Windows già assegnato vengono sincronizzate automaticamente alla successiva connessione dei dispositivi e non costituiscono un test su un solo dispositivo. Con Add configuration, aggiungere soltanto la configurazione verificata, salvare e selezionare tramite Assign esclusivamente il dispositivo pilota scelto. Per i criteri Windows, la pagina Schedule task descritta nella finestra Sophos è disponibile per i criteri Android, Knox e iOS, non per Windows; non promettere quindi qui un’assegnazione Windows differita. Il test inizia soltanto quando l’addetto designato è pronto.

Dopo l’assegnazione, confrontare la vista Policies del dispositivo interessato, lo stato delle attività e il comportamento effettivo sul dispositivo. I criteri Windows vengono sincronizzati automaticamente alla connessione del dispositivo; la visualizzazione nell’interfaccia non basta, da sola, a dimostrare l’effetto locale. Se una modifica è imprevista, non attivare un secondo interruttore rilevante per la sicurezza: mantenere il dispositivo raggiungibile, correggere in modo controllato solo il criterio riservato al dispositivo pilota oppure assegnare un criterio sostitutivo già verificato, attendere la sincronizzazione e il riavvio necessario e ricontrollare localmente. Prima di modificare un ulteriore criterio condiviso già assegnato, controllare i dispositivi e i gruppi a cui è assegnato. Questa procedura non ripristina automaticamente i profili WLAN già eliminati, un blocco UEFI o una richiesta di recupero BitLocker già provocata.

Delimitazione: Certificati root/client, SCEP e profili WLAN rientrano in una procedura autonoma per reti e certificati Windows. I protector BitLocker e la gestione dei Recovery Key appartengono a Device Encryption. La modalità kiosk e la registrazione Windows hanno ciascuna requisiti e procedure di ritorno specifici; nessuna di queste attività si considera automaticamente svolta con il criterio di sicurezza verificato qui.