Sophos Mobile: verificare in sicurezza i certificati SCEP e i percorsi di connessione

SCEP può installare e rinnovare certificati in Sophos Mobile (MDM). Questa procedura riguarda la configurazione SCEP nel tenant e i diversi percorsi di connessione coinvolti, non la configurazione completa di una CA Windows, di un’infrastruttura Wi-Fi/VPN o di tutti i payload delle policy Android, Apple e Windows. L’installazione e il rinnovo SCEP secondo questa procedura non supportano i Chromebook.

Prima di modificare l’ambiente di produzione: i responsabili CA/PKI, rete e MDM e, se necessario, chi gestisce il servizio di autenticazione Wi-Fi/VPN devono concordare quali dispositivi e modalità di registrazione siano interessati, se e come un determinato servizio possa usare il certificato SCEP e come raggiungere i dispositivi in caso di perdita della connettività. Né Save né la distribuzione di una policy dimostrano che un certificato client sia stato emesso, rinnovato o associato a un profilo Wi-Fi/VPN.

Tre percorsi di connessione, non un’apertura indiscriminata delle porte

Sophos Fusion si connette alla CA aziendale compatibile con SCEP; il dispositivo gestito comunica separatamente con Sophos Mobile. Una successiva autenticazione al servizio Wi-Fi/VPN con quello stesso certificato SCEP non è automatica e va dimostrata per ciascuna piattaforma e ciascun profilo. Qui tenant indica l’ambiente Sophos Mobile dell’organizzazione e MDM la sua gestione dei dispositivi.

Individuare la regione del tenant: in Sophos Fusion, sotto My Products > Mobile, controllare l’URL nella barra degli indirizzi del browser. La regione si trova nella prima parte del nome host, prima del primo punto, subito dopo smc-user-if-cloudstation-. Nell’esempio smc-user-if-cloudstation-eu-west-1, la regione è eu-west-1. Per le autorizzazioni di rete, usare la regione ricavata dall’URL del proprio browser, non il valore dell’esempio né un testo identico nel percorso dell’URL o nei parametri di query. La regione di hosting viene scelta alla creazione dell’account Sophos Fusion; per gli account esistenti, qui viene ricavata dall’URL effettivo del browser. Questo host amministrativo non è né un endpoint dei dispositivi né il server SCEP. La stessa procedura per individuare la regione vale anche per Mobile Threat Defense, ma non dimostra l’esistenza di una funzione SCEP autonoma in MTD.
Da Fusion ai server aziendali (traffico in ingresso): l’elenco regionale aggiornato degli IP sorgente per definire la specifica autorizzazione in ingresso indica TCP 443 per SCEP e TCP 636 per la distinta connessione LDAP/AD. Consentire verso la rispettiva destinazione SCEP o AD aziendale solo gli IP sorgente Mobile pubblicati attualmente per la regione effettiva del tenant. Non usare la regione dell’esempio né creare regole in ingresso globali o senza restrizioni. La connessione LDAP/AD serve all’autenticazione degli utenti con credenziali AD durante la registrazione dei dispositivi tramite Apple Business (in precedenza Apple Business Manager), Google Zero-touch o Samsung KME. Questa autenticazione non equivale né alla prima emissione di un certificato client SCEP a un dispositivo gestito né al successivo rinnovo del certificato.
Dal dispositivo a Sophos Mobile (traffico in uscita): i dispositivi gestiti devono raggiungere via HTTPS 443 l’host regionale smc-device-if-cloudstation-. Le destinazioni complete dei dispositivi sono smc-device-if-cloudstation-eu-central-1.prod.hydra.sophos.com per eu-central-1, smc-device-if-cloudstation-eu-west-1.prod.hydra.sophos.com per eu-west-1, smc-device-if-cloudstation-us-west-2.prod.hydra.sophos.com per us-west-2 e smc-device-if-cloudstation-us-east-2.prod.hydra.sophos.com per us-east-2, ciascuna tramite HTTPS 443. Usare soltanto la destinazione della regione effettiva del tenant individuata in precedenza; queste destinazioni dei dispositivi non sono l’host amministrativo né le destinazioni SCEP aziendali. Sono inoltre necessarie connessioni per le notifiche push, la registrazione e altre funzioni delle piattaforme. I percorsi di verifica distinti e le guide interne alle piattaforme riportati di seguito le inquadrano in base al tipo di dispositivo e alla funzione effettivamente usata; i quattro host regionali dei dispositivi non costituiscono un elenco completo delle destinazioni del traffico in uscita. Queste destinazioni aggiuntive non sono né IP sorgente SCEP in ingresso né un elenco generico di porte SCEP.

Tenere distinte le altre dipendenze del traffico in uscita dei dispositivi:

Notifiche push Windows: per i computer Windows, sono documentate per Windows Notification Service (WNS) e Microsoft Push Notification Service (MPNS) le destinazioni *.notify.windows.com, *.wns.windows.com e *.notify.live.net, ciascuna tramite HTTPS 443. Si tratta di connessioni push Windows, non di porte SCEP in ingresso.
Registrazione e provisioning Android: per Android, consultare la guida Android Enterprise e, per i prerequisiti QR/Zero-touch/KME, la guida al provisioning; anche in quei percorsi occorre verificare le autorizzazioni in base al dispositivo e alla modalità specifici.
Notifiche push per la gestione Apple: per la gestione di iPhone, iPad e Mac, verificare separatamente il percorso delle notifiche push Apple; la guida APNs descrive l’identità del certificato, il rinnovo e la verifica della raggiungibilità disponibile su iPhone/iPad.
Informazioni sugli aggiornamenti Apple e conformità: separatamente, Sophos Mobile necessita di informazioni sugli aggiornamenti Apple disponibili: se il servizio Apple previsto a questo scopo non è raggiungibile, queste informazioni mancano e le regole di conformità che impongono aggiornamenti non hanno effetto. Verificare il percorso di rete aziendale e i limiti relativi a piattaforma, sistema operativo e modalità di registrazione nella guida alla conformità. Le notifiche push per la gestione Apple e le informazioni sugli aggiornamenti sono requisiti del traffico in uscita dei dispositivi, non endpoint SCEP in ingresso o per l’emissione di certificati.
Traffico dell’app IXM: per iPhone/iPad con Sophos Intercept X for Mobile (IXM), verificare le connessioni separate dell’app nella guida di rete IXM, che descrive l’associazione tra servizi e porte e i limiti in base alla versione dell’app, all’edizione, alla modalità di gestione e alla funzione effettivamente usata. Non si tratta di connessioni SCEP in ingresso; l’intestazione Apple in un elenco di connessioni di rete non implica che IXM sia applicabile ai Mac.

Un indirizzo di destinazione documentato non dimostra ancora la raggiungibilità nella propria rete.

Per diagnosticare un problema, registrare separatamente se (a) Fusion raggiunge l’endpoint SCEP aziendale, (b) il dispositivo raggiunge Sophos Mobile e riceve la sua policy e (c) il servizio Wi-Fi/VPN accetta il certificato emesso. Il successo di uno di questi percorsi non sostituisce la verifica degli altri due.

Definire prima attendibilità e responsabilità

Termini utili alla decisione: PKI indica l’infrastruttura a chiave pubblica, CA l’autorità che emette i certificati. SCEP richiede il certificato client; Subject e SAN (Subject Alternative Name), ed eventualmente UPN (identificativo dell’utente), definiscono l’identità da verificare. EAP è un metodo di autenticazione per il servizio Wi-Fi. L’importazione di un file PKCS #12 (.pfx) è una modalità di distribuzione diversa da SCEP: il relativo certificato non viene rinnovato automaticamente dall’intervallo di rinnovo SCEP.

Tenere distinte le tre questioni relative all’attendibilità, anche se la stessa CA svolge più ruoli nella PKI aziendale:

Connessione al server SCEP: prima di SCEP, il team MDM distribuisce nella policy appropriata una configurazione Root certificate con il certificato della CA del server SCEP. Nelle policy per dispositivi Android Enterprise, selezionare inoltre il certificato nel campo SCEP Root certificate tra i certificati della stessa policy. Non si tratta del certificato client emesso e non dimostra l’identità del client.
Identità client emessa: per Android Enterprise e iOS, dopo aver sostituito tutti i segnaposto, il Subject deve essere un nome X.500 valido della persona o del dispositivo previsti. Definire separatamente il tipo e il valore del SAN; nei campi SCEP per dispositivi, AD user logon name indica l’UPN AD dell’utente, non un identificativo arbitrario del dispositivo. Il campo iOS CA name è un nome riconosciuto dalla CA, ad esempio per distinguere le sue istanze: non dimostra chi sia l’emittente del certificato né quale sia l’ancoraggio di attendibilità. Il team PKI/CA verifica quindi sul certificato effettivamente emesso la CA emittente e la catena, i valori Subject/SAN/UPN consentiti, l’uso della chiave e l’accesso alla chiave privata. I team MDM e del servizio concordano la verifica effettiva dell’identità da parte del servizio che userà il certificato; non riutilizzare i valori di esempio.
Attendibilità da parte del servizio: se Wi-Fi/VPN deve usare il certificato client, il servizio deve considerare attendibile la relativa catena CA. Nel caso di EAP, occorre inoltre verificare che il dispositivo consideri attendibile il certificato del server Wi-Fi. Nessuna di queste verifiche discende dal solo fatto che il server SCEP sia attendibile.

Responsabili prima dell’approvazione:

Team PKI/CA: verificare la CA Windows compatibile con SCEP, la raggiungibilità di /CertSrv/MSCEP_ADMIN e /CertSrv/MSCEP e le autorizzazioni per generare le challenge e richiedere i certificati. Non inserire password delle challenge, credenziali del servizio o chiavi private in ticket o screenshot. Il riferimento storico a Windows 2003 nella guida Sophos non è una dichiarazione attuale di supporto per quel server.
Team di rete: verificare FQDN di destinazione, percorso tramite proxy TLS/HTTP e autorizzazione strettamente limitata degli IP sorgente regionali rispetto alla topologia reale; controllare separatamente l’uscita dei dispositivi, le notifiche push e un percorso di gestione/rete indipendente per le emergenze. Non sostituire queste verifiche disattivando indiscriminatamente i filtri.
Team MDM/del servizio: definire prima della configurazione la piattaforma, il tipo di policy per dispositivo o utente e la modalità di registrazione. Per il percorso relativo ai dispositivi Android Enterprise descritto qui, usare una Android Enterprise device policy; una policy Work Profile riguarda un ambito di gestione diverso. La guida Android Enterprise spiega questa scelta della modalità. Trattare separatamente il payload SCEP per dispositivi iOS e non usarlo come prova per le policy per utenti iOS. I campi SCEP comuni e quelli specifici delle piattaforme vengono verificati separatamente nella procedura pilota riportata di seguito. Fermarsi se il tipo di policy non è confermato o la modalità di registrazione non è supportata.

Fermarsi se l’identità prevista o la catena di attendibilità delle CA non sono chiare, se il tipo di dispositivo o la modalità non corrispondono alla policy verificata oppure se il dispositivo sarebbe gestibile soltanto attraverso la rete Wi-Fi/VPN da modificare e manca un percorso di ritorno indipendente.

L’emissione del certificato non implica l’associazione a Wi-Fi/VPN

La configurazione SCEP richiede un certificato alla CA. Prima di modificare Wi-Fi/VPN, verificare separatamente:

Campo di selezione per il Wi-Fi: nelle policy per dispositivi Android Enterprise e nelle policy per dispositivi iOS, Identity certificate seleziona un certificato da una configurazione Client certificate della stessa policy. Questa configurazione importa un file PKCS #12 (.pfx); è una modalità di distribuzione diversa da SCEP. Questo non dimostra che nel campo di selezione per il Wi-Fi sia selezionabile un certificato emesso tramite SCEP. Una rete Wi-Fi EAP per Android Enterprise non può essere nascosta: l’SSID deve essere trasmesso.
Rinnovo e attendibilità del server: pianificare separatamente importazione, validità e sostituzione dei certificati PKCS #12; SCEP renewal interval non li rinnova automaticamente. Il certificato radice per il server EAP nella policy Wi-Fi non va automaticamente equiparato a quello usato per considerare attendibile il server SCEP.

Anche per la VPN non esiste un collegamento universale a SCEP: in Android Enterprise la policy seleziona un’app VPN gestita, già installata tramite Google Play; i parametri di connessione risiedono nella configurazione gestita dell’app. In iOS, l’autenticazione tramite certificato e la selezione del certificato dipendono dal tipo di connessione. Questa selezione, da sola, non dimostra che sia possibile usare un certificato SCEP. Prima di un progetto pilota Wi-Fi/VPN, confermare, mediante documentazione pertinente del produttore o in un progetto pilota circoscritto, l’associazione supportata del certificato e il comportamento dopo il rinnovo per piattaforma, tipo di policy, metodo di autenticazione ed eventuale client VPN. Se manca questa prova, limitare il progetto pilota all’emissione e al rinnovo SCEP; non avviare la migrazione Wi-Fi/VPN né revocare la catena di attendibilità precedente.

Configurare SCEP solo in un progetto pilota circoscritto

In Setup > Sophos setup > SCEP, concordare con il team PKI l’URL del server SCEP https://<server>/CertSrv/MSCEP e l’URL della challenge https://<server>/CertSrv/MSCEP_ADMIN. Usare un utente autorizzato nel formato username@domain e la relativa password; verificare con il team PKI i tipi di carattere ammessi per la challenge e le autorizzazioni. Selezionare nel campo Challenge characters i tipi di carattere concordati per la password della challenge prima di eseguire Save; mantenere la lunghezza della challenge preimpostata da Sophos. Adottare una diversa prescrizione PKI solo come eccezione documentata, approvata e testata separatamente. Se è attivo un proxy HTTP, inizialmente Use HTTP proxy si applica a questa connessione; disattivare l’opzione solo se Sophos Mobile deve raggiungere intenzionalmente il server SCEP senza passare dal proxy.
Eseguire Save e documentare il test di connessione al server SCEP. In caso di errore, verificare URL, attendibilità del certificato, proxy, autorizzazioni e IP sorgente consentiti con i rispettivi responsabili, senza modificare subito le policy su larga scala.
Per prima cosa, creare una policy o modificarne una esistente adatta alla modalità del progetto pilota. Per la creazione, la modifica delle configurazioni, il salvataggio e la successiva assegnazione al gruppo pilota, consultare la guida alle policy; verificare prima la piattaforma e il tipo di policy supportato. In questa policy, configurare prima Root certificate con il certificato della CA del server SCEP, poi SCEP e SCEP renewal interval. Per i campi SCEP URL e Challenge, le guide alle policy per dispositivi Android Enterprise e iOS indicano rispettivamente i segnaposto %_SCEPPROXYURL_% e %_CACHALLENGE_% per l’URL del server SCEP e quello della challenge configurati in precedenza; concordare Subject, SAN/UPN, dimensione e uso della chiave con PKI e servizio di destinazione per la piattaforma specifica. Assegnare la policy solo al gruppo pilota circoscritto. PKI e MDM stabiliscono in anticipo, per quella piattaforma e quella modalità di policy, dove osservare la distribuzione della policy, il certificato sul dispositivo e l’emissione/il rinnovo nella PKI; se è dimostrata anche l’associazione a Wi-Fi/VPN, individuare inoltre il log del servizio. Non presumere che campi di stato o nomi dei log siano uguali per tutti i dispositivi. SCEP renewal interval determina quando il dispositivo effettua la richiesta, non se il rinnovo riesce.
Campi SCEP specifici delle piattaforme: nelle policy per dispositivi Android Enterprise, definire un Alias name riconoscibile per le finestre di selezione e, nel campo Root certificate, selezionare il certificato della CA del server SCEP dalla stessa policy. Nelle policy per dispositivi iOS, concordare CA name con la CA; Retries indica il numero di tentativi successivi a una risposta pending del server e Retry delay definisce l’intervallo in secondi. Non presentare questi campi iOS come campi Android. Key size deve corrispondere alla configurazione del server SCEP. Per Certificate usage, concordare separatamente con PKI e servizio l’uso previsto, scegliendo tra Use as digital signature e Use for encryption; non inventare una dimensione o una selezione predefinita.
Per Type of Subject Alternative Name e Value of Subject Alternative Name, verificare separatamente il tipo e il valore documentati: RFC 822 name per un indirizzo e-mail valido, DNS name per il nome DNS del server CA oppure Uniform resource identifier per il suo URL completo. AD user logon name resta l’UPN AD dell’utente. La descrizione dei campi non sostituisce la verifica dell’identità sul certificato effettivamente emesso.
Prima emissione dopo la distribuzione della policy: sul dispositivo pilota confrontare issuer/catena, Subject e SAN/UPN, numero di serie, date di inizio/fine validità e uso della chiave con i requisiti PKI approvati. Una registrazione del dispositivo in AD non conta come emissione di un certificato client SCEP. Se l’emissione non è stata osservata, fermarsi: non approvare la rotazione.
Rinnovo successivo: PKI e MDM definiscono un periodo di osservazione in base all’intervallo di rinnovo e alla validità del certificato. Durante tale periodo, verificare sul dispositivo la presenza di un nuovo certificato valido, con un nuovo numero di serie e valori di identità/issuer corretti, nonché la corrispondente operazione confermata nella PKI. Se non è osservabile o non avviene nel periodo pilota, non dichiarare validata la rotazione.
Solo se l’associazione a Wi-Fi/VPN è stata dimostrata nel progetto pilota: attribuire nel log del servizio le autenticazioni riuscite prima e dopo il rinnovo proprio al dispositivo pilota e al suo certificato. Senza log del servizio o associazione confermata, non modificare Wi-Fi/VPN.

Rotazione e percorso di ripristino

Prima di modificare URL SCEP, accesso alle challenge o CA, nonché prima di un cambio di profilo Wi-Fi/VPN dimostrato separatamente, registrare nel verbale del progetto pilota le assegnazioni precedenti e nuove delle policy, gli ancoraggi di attendibilità e i gruppi interessati per ciascuna classe di dispositivi. PKI, rete e MDM stabiliscono un percorso di gestione effettivamente raggiungibile e indipendente dalla rete basata sul certificato da sostituire, il responsabile locale del ripristino e il criterio di arresto. Il metodo concreto per riassegnare o rimuovere una policy e i suoi effetti sui dispositivi devono essere convalidati nel progetto pilota per la piattaforma e la modalità di registrazione; qui non si presume un metodo di ripristino universale. Secondo Sophos, Uninstall policy è previsto solo per le policy dei dispositivi Android, dei contenitori Knox e dei dispositivi iOS; per gli altri tipi, comprese le policy dei dispositivi Android Enterprise, occorre invece aggiornare la policy o assegnarne un’altra. Questo non dimostra che una CA o un certificato client già installati vengano rimossi o ripristinati.

Decisione prima della distribuzione generale: distribuire per prima la nuova catena di attendibilità nel progetto pilota solo se la modalità specifica consente la distribuzione parallela. Verificare la nuova emissione e un effettivo rinnovo successivo. Se è previsto un cambio Wi-Fi/VPN, verificare inoltre l’associazione documentata al profilo e l’autenticazione al servizio prima e dopo il rinnovo. Rimuovere i vecchi profili e ancoraggi di attendibilità soltanto dopo un’accettazione controllata e una distribuzione pianificata. Non revocare prematuramente la vecchia CA se è ancora necessaria per le connessioni esistenti.

In caso di errore, decidere in base alla raggiungibilità:

Fermare tutte le ulteriori assegnazioni e revoche. Mantenere la CA, i profili e gli ancoraggi di attendibilità precedenti; coinvolgere i responsabili PKI, rete e MDM facendo riferimento al verbale del progetto pilota.
Dispositivo raggiungibile tramite il percorso indipendente verificato: il team MDM ripristina le assegnazioni precedenti documentate di policy/rete/CA usando il metodo di assegnazione/rimozione già convalidato per quella modalità; PKI e rete verificano le rispettive parti. Se Wi-Fi/VPN è stato modificato, ripetere il test di autenticazione nel log del servizio.
Dispositivo offline o senza percorso indipendente: il responsabile locale del ripristino designato in precedenza usa esclusivamente la procedura locale di recupero già pianificata e testata; poi verifica nuovamente la raggiungibilità e, se pertinente, l’autenticazione al servizio. La semplice reimpostazione di un’impostazione cloud non è un rollback dimostrato per dispositivi diventati offline. Se il percorso locale non è stato verificato, non presumere di poter ripristinare in sicurezza il dispositivo da remoto né estendere la modifica.

Senza una prima emissione osservata, un rinnovo osservato e un percorso di ripristino verificato, la modifica SCEP in produzione resta bloccata; una modifica Wi-Fi/VPN richiede in aggiunta la prova dell’associazione del certificato e del suo utilizzo riuscito prima e dopo il rinnovo.

Limite delle verifiche: questa è una bozza basata sulle fonti, non testata nel tenant né sui dispositivi. Le versioni OS/server supportate, il comportamento dei client durante il rinnovo offline e la concreta verifica dell’identità in EAP/VPN vanno confermati separatamente nell’ambiente aziendale.