Vai al contenuto
Avanet

Pianificare Wi-Fi Apple, certificati, VPN e proxy con Sophos Mobile

Ambito: Sophos Mobile in Sophos Fusion (in precedenza Sophos Central), iPhone e iPad con iOS/iPadOS. Questa guida distingue le policy dispositivo iOS (Device Policy) dalle policy utente iOS (User Policy). Non è una configurazione passo per passo collaudata per un tenant specifico, né una guida a macOS o un’autorizzazione alla distribuzione massiva in produzione. Verificare prima sul dispositivo di destinazione la versione del sistema operativo, la modalità di registrazione, la supervisione (Supervision), il tipo di policy e le funzioni disponibili nel proprio tenant.

⚠️ Non interrompere la connettività: Un certificato Wi-Fi/EAP errato, una CA SCEP irraggiungibile, un PAC/WPAD difettoso o un tunnel VPN possono interrompere anche il canale di ritorno per le operazioni MDM. Prima delle modifiche, verificare una connessione indipendente dal profilo modificato e una procedura di ripristino locale. Un rollback salvato nella console non raggiunge automaticamente un dispositivo rimasto offline e senza accesso.

Distinguere anzitutto la modalità di gestione

CasoRegola decisionale
iPhone/iPad aziendale con Device EnrollmentPolicy dispositivo iOS per Wi-Fi, certificati e VPN a livello di dispositivo; proxy HTTP globale solo con supervisione.
iPhone/iPad personale con Apple User EnrollmentPolicy utente iOS per Wi-Fi gestito e certificati; VPN per app solo dopo una verifica nel tenant.

Device Enrollment non implica automaticamente la supervisione: Automated Device Enrollment supervisiona il dispositivo, mentre altre modalità non lo fanno necessariamente. Apple User Enrollment non lo supervisiona mai e riguarda i dati gestiti, non l’intero dispositivo personale. Per il BYOD, un Managed Apple Account e il consenso dell’utente sono prerequisiti. In questo caso non sono disponibili un proxy HTTP globale, una normale VPN a livello dell’intero dispositivo né impostazioni proxy nella configurazione Wi-Fi gestita; Sophos non può leggere MAC/UDID/IMEI per l’identificazione NAC.

Sophos limita lo User Enrollment basato su profilo a iOS/iPadOS 17 o versioni precedenti; ciò non significa che lo User Enrollment account-driven sia stato abolito in generale. Quando l’utente annulla la registrazione, il volume APFS gestito e il Managed Apple Account vengono rimossi dal dispositivo: questo non costituisce un rollback generale di Wi-Fi o VPN. Apple descrive la VPN per app come funzione possibile dello User Enrollment, non come prova che in Sophos funzioni l’assegnazione della VPN alle app.

Pianificare insieme Wi-Fi e catena dei certificati

Isolare il progetto pilota BYOD prima di ogni modifica: Per le policy utente iOS/iPadOS, Sophos sincronizza automaticamente le modifiche ogni volta che il dispositivo si riconnette a Sophos Mobile; non serve eseguire manualmente Update devices. Usare quindi una policy utente separata, assegnata soltanto al dispositivo BYOD autorizzato per la prova, e verificarne le assegnazioni attuali e il numero di dispositivi destinatari prima di modificarla e prima di selezionare Save. Non modificare nel progetto pilota una policy già condivisa con dispositivi BYOD di produzione. Assegnarla successivamente a dispositivi di prova selezionati non limita la sincronizzazione delle modifiche sugli altri dispositivi ai quali la stessa policy è già assegnata. Questa regola sull’ambito vale anche per le modifiche ai certificati e le correzioni durante il ripristino; la sola sincronizzazione non conferma né il funzionamento della rete né il canale di ritorno MDM.

Chi verifica chi? Nel Wi-Fi aziendale con EAP (autenticazione tra dispositivo e rete), il dispositivo verifica il nome e la catena di certificati del server RADIUS. Se l’autenticazione si basa su certificati, RADIUS verifica a sua volta l’identità client emessa. La CA del server e l’identità client hanno quindi ruoli diversi. La voce Identity certificate selezionabile nella configurazione Wi-Fi richiede una configurazione Client certificate nella stessa policy; il certificato del server sotto Trusted certificates richiede una configurazione Root certificate in tale policy.

Solo segnaposto fittizi, non riutilizzare: radius.test.invalid come nome del server, Test-CA come CA del server attendibile e CN=Testperson,OU=Pilot,O=Beispiel come subject X.500 (campi dell’identità client). Sostituire tutti i valori con i nomi, la CA e i campi d’identità confermati dal proprio team PKI/RADIUS. Sul dispositivo di prova, verificare che l’identità del server configurata corrisponda alla catena reale e che RADIUS accetti il certificato client emesso. Il certificato radice è un certificato X.509 in formato PEM/DER; un certificato client importato è in formato PKCS#12 (.pfx). Il caricamento di un file .pfx non lo rende automaticamente riutilizzabile in più policy: se il certificato client serve in un’altra policy, occorre caricarlo di nuovo in quella policy. Verificare provenienza della CA, titolarità della chiave, validità e uso previsto. Caricare una CA radice non dimostra che tutte le app la considerino attendibile.

Per Root certificate in una policy dispositivo iOS, aprire la configurazione nella pagina Edit policy tramite Add configuration > Root certificate. Selezionare il file X.509 in PEM/DER con Upload a file e aprirlo con Open. Dopo il caricamento, Certificate name mostra il Distinguished Name (DN) dell’emittente, non l’identità client. Salvare la configurazione con Apply, poi salvare la policy con Save nella pagina Edit policy. Secondo Sophos, l’assegnazione della policy installa sul dispositivo il certificato radice caricato. La visualizzazione e il salvataggio, da soli, non dimostrano attendibilità, validità o corretta installazione. Per ogni ulteriore certificato radice è necessaria una configurazione Root certificate distinta nella stessa policy.

Per Root certificate in una policy utente iOS, Sophos descrive l’importazione nella pagina Edit policy tramite Add configuration > Root certificate. Selezionare il file X.509 in PEM/DER con Upload a file e aprirlo con Open. Dopo il caricamento, Certificate name mostra il Distinguished Name dell’emittente. Salvare la configurazione con Apply, poi salvare la policy con Save nella pagina Edit policy. Aggiungere una configurazione Root certificate distinta per ogni ulteriore certificato radice. Secondo Sophos, l’assegnazione della policy utente installa il certificato sul dispositivo; all’interno della stessa policy è possibile utilizzarlo, per esempio, come certificato del server EAP nel Wi-Fi. La visualizzazione dopo il caricamento e la policy salvata non dimostrano né la corretta installazione, né l’attendibilità del certificato, né il buon esito dell’autenticazione Wi-Fi.

Nella configurazione Client certificate della policy dispositivo iOS, selezionare prima Upload a file sotto File, poi il file del certificato PKCS#12 (.pfx). In Certificate name, Sophos Mobile mostra il nome letto dal file del certificato. Il solo nome non dimostra l’attendibilità, la validità o la corretta installazione del certificato.

Prima della configurazione SCEP: Se si usa la connessione SCEP configurata in Sophos setup con le variabili indicate sotto, verificare prima il flusso dei prerequisiti SCEP e dei certificati: raggiungibilità della CA da Sophos Fusion, regole firewall limitate alla regione pertinente e, per questo percorso documentato con CA Windows, un accesso autorizzato a creare challenge e richiedere certificati. Prima di configurare SCEP, predisporre il certificato CA del server SCEP come Root certificate nella stessa policy. L’attendibilità di questo server è distinta da quella del server RADIUS e dall’identità client emessa; ciò non significa che Windows sia un prerequisito di ogni implementazione SCEP diretta.

SCEP (Simple Certificate Enrollment Protocol) consente a un dispositivo di richiedere un certificato alla CA. È necessario un URL della CA raggiungibile oppure la variabile del proxy SCEP Sophos configurata correttamente. Concordare con il team PKI i campi del subject X.500 e SAN/UPN (nomi d’identità aggiuntivi), la challenge, i parametri per ritentare le richieste in sospeso, la lunghezza della chiave e i bit di utilizzo, in base alla propria CA. Per la configurazione SCEP di una policy dispositivo iOS sono importanti queste decisioni:

  • Endpoint e nome della CA: URL è l’indirizzo web del server CA. %_SCEPPROXYURL_% fa riferimento all’URL del server nella scheda SCEP della pagina Sophos setup. CA name è un nome riconosciuto dalla CA; può servire, per esempio, a distinguere diverse istanze della CA. Confermare con il team PKI il nome previsto dalla propria CA. Il campo non è la voce Certificate name visualizzata per un certificato importato, né il nome di esempio della CA attendibile del server RADIUS.
  • Identità utente o dispositivo: Subject può contenere segnaposto per dati dell’utente o proprietà del dispositivo. Sophos indica CN=%_USERNAME_% per un utente e CN=%_DEVPROP(SerialNumber)_% per un iPhone o iPad. Sono esempi di sintassi documentati, non valori verificati per il proprio tenant. Concordare l’identità desiderata con il team PKI e verificare che i dati siano disponibili e che, dopo la sostituzione, il subject sia un nome X.500 valido. BYOD: La presenza documentata di un segnaposto per il numero di serie non prova che, con User Enrollment, sia possibile risolvere un’identità basata sul numero di serie: Sophos non può leggere gli identificativi del dispositivo in questa modalità. Verificare subject ed emissione con un utente di prova.
  • Tipo e valore SAN: In Type of Subject Alternative Name selezionare il tipo approvato dal team PKI e inserire il valore corrispondente in Value of Subject Alternative Name. RFC 822 name indica un indirizzo e-mail valido. Per questa configurazione SCEP iOS, Sophos descrive DNS name come il nome DNS del server CA e Uniform resource identifier come il suo URL completo: non sono il nome del server RADIUS o l’indirizzo della challenge. AD user logon name è distinto e indica l’UPN impostato in Active Directory. Challenge è l’indirizzo web da cui il dispositivo ottiene una password challenge dal server SCEP. %_CACHALLENGE_% fa riferimento all’URL della challenge configurato nella scheda SCEP della pagina Sophos setup, non alla password stessa. Non riportare segreti reali in esempi pubblici o ticket.
  • Richieste in sospeso: Retries definisce il numero di nuovi tentativi quando il server risponde con pending; non è un contatore generale dei tentativi per tutti gli errori di rete. Retry delay è l’intervallo tra questi tentativi, in secondi. Concordare numero e intervallo con il team PKI, senza confonderli con il rinnovo del certificato.
  • Chiave e uso previsto: Key size indica la dimensione della chiave pubblica nel certificato emesso e deve corrispondere a quella configurata sul server SCEP. Certificate usage definisce l’uso consentito: Use as digital signature per le firme digitali, Use for encryption per la cifratura dei dati. La selezione deve rispettare i requisiti PKI e quelli del servizio di destinazione; non dimostra né il buon esito dell’autenticazione Wi-Fi/VPN né la cifratura di tutto il traffico del dispositivo.

Durante la creazione della policy è presente il campo SCEP renewal interval. Verificare con il team PKI intervallo, scadenza, revoca e sostituzione: impostare un intervallo non garantisce né il rinnovo riuscito né il recupero di un dispositivo rimasto offline.

Sostituzione dell’identità nelle policy dispositivo e utente: Nell’esempio precedente CN=%_USERNAME_%, %_USERNAME_% viene sostituito con Exchange Login dell’utente assegnato al dispositivo, non necessariamente con il suo nome visualizzato e non automaticamente con l’UPN di AD. Prima dell’assegnazione, verificare l’utente associato e il valore di questa proprietà; dopo la sostituzione, il subject deve comunque essere un nome X.500 valido e approvato dal team PKI. AD user logon name resta il campo UPN distinto.

Per SCEP in una policy utente iOS, definire separatamente gli endpoint. URL è l’indirizzo web del server CA. La variabile %_SCEPPROXYURL_% fa riferimento all’URL del server nella scheda SCEP della pagina Sophos setup. Challenge è l’URL da cui ottenere una password challenge dal server SCEP, non la password stessa. %_CACHALLENGE_% fa riferimento all’URL della challenge configurato nella stessa scheda SCEP. Come per i parametri delle richieste descritti sopra, Retries conta solo i nuovi tentativi dopo una risposta pending; Retry delay ne indica l’intervallo in secondi. Key size deve corrispondere alla dimensione della chiave pubblica configurata sul server SCEP. Confermare questi parametri con il team PKI: non sono intervalli di rinnovo e non dimostrano il buon esito dell’emissione.

Wi-Fi aziendale e indirizzo Wi-Fi privato

Per un progetto pilota Wi-Fi isolato per dispositivi, il percorso seguente collega le impostazioni di rete all’assegnazione della policy. Prima, assicurarsi di disporre della connessione indipendente e della via di ripristino descritte nella sezione sul progetto pilota; non modificare una policy assegnata in produzione.

  1. In Policies, aprire la piattaforma Apple appropriata per il dispositivo di destinazione, creare una policy dispositivo con Create e inserire nome, descrizione e nome dell’organizzazione. Nella pagina Edit policy, aggiungere la configurazione Wi-Fi con Add configuration e aprirne il nome per modificarla. Per il Wi-Fi Enterprise, predisporre prima i certificati client e radice necessari nella stessa policy, come descritto sopra; Apply nelle configurazioni dei certificati radice non sostituisce Save per l’intera policy.
  2. In SSID, inserire il nome Wi-Fi confermato dal team di rete e impostare Security type in base al metodo effettivo, inclusa la variante Personal/Enterprise. Personal richiede la password Wi-Fi; per Enterprise, usare le impostazioni EAP, di autenticazione e di attendibilità descritte sotto. Connect automatically stabilisce automaticamente la connessione quando la rete è disponibile; Hidden network indica una rete che non trasmette il proprio SSID. Selezionare entrambe le opzioni solo in base alla rete prevista, non come prova di sicurezza.
  3. Verificare tutte le configurazioni e salvare la policy con Save nella pagina Edit policy. Per l’assegnazione successiva, seguire la procedura «Creare e assegnare il criterio»: selezionare la policy pilota salvata, contrassegnare solo i singoli dispositivi autorizzati per la prova e verificare elenco e numero prima di Finish. Rispettare le limitazioni sulla pianificazione e su iPadOS indicate nella procedura. Osservare poi separatamente lo stato dell’attività/assegnazione, l’autenticazione Wi-Fi effettiva e il check-in MDM secondo i criteri di verifica riportati sotto; salvataggio e assegnazione non sono risultati di connessione confermati.

Per la configurazione Wi-Fi di una policy dispositivo iOS, selezionare anzitutto Security type in base alla rete. Una variante Personal offre il campo per la password Wi-Fi. Solo una variante Enterprise rende disponibili Protocols, Authentication e Trusted certificates. In Accepted EAP types, concordare con il team RADIUS i metodi accettati dal dispositivo in base all’autenticazione della rete. I certificati client e radice descritti sopra restano vincolati alla stessa policy.

In Authentication della policy dispositivo iOS, User è il nome utente Wi-Fi e Password la password Wi-Fi per l’autenticazione con credenziali. Secondo Sophos, Require password on each connect invia la password a ogni autenticazione; l’opzione non garantisce una richiesta interattiva della password. Concordare il percorso di autenticazione con credenziali e questa selezione con il team RADIUS. Per l’autenticazione basata su certificati, selezionare invece la Identity certificate appropriata da una configurazione Client certificate della stessa policy dispositivo. Sul dispositivo di prova, verificare l’accettazione delle credenziali o del certificato client da parte di RADIUS in base al percorso scelto; in entrambi i casi, verificare separatamente l’identità del server e la catena di attendibilità.

Per TTLS, Internal identity indica il protocollo di autenticazione dell’utente all’interno del tunnel. Non è l’identità esterna. Per EAP-FAST è possibile configurare una Protected Access Credential (PAC); questa PAC non è uno script di configurazione automatica del proxy. Concordare con il team RADIUS il protocollo TTLS e, se necessario, la credenziale EAP-FAST, quindi verificare l’autenticazione sul dispositivo di destinazione. Senza questo chiarimento, escludere dal progetto pilota il relativo ramo EAP.

Per EAP, impostare entrambi i limiti TLS oppure lasciare entrambi non impostati. Sophos descrive Outer identity per TTLS, PEAP ed EAP-FAST e richiede un’identità esterna per TLS 1.3. Non usare nomi utente o segreti, perché l’identità esterna viene trasmessa in chiaro. Se necessario per l’instradamento, il team PKI/RADIUS deve verificare un’identità esterna anonima con il realm appropriato. Osservare sul dispositivo di prova l’autenticazione e la versione TLS negoziate: la sola selezione non dimostra che la connessione funzioni.

Turn off private address fa sì che il dispositivo utilizzi per questa rete Wi-Fi il proprio indirizzo MAC hardware anziché un indirizzo specifico della rete generato da iOS. Ciò riduce la privacy. Usare l’opzione solo quando è indispensabile identificare il dispositivo con lo stesso indirizzo MAC sulle proprie reti. Secondo Sophos, Synchronized Security non funziona con indirizzi MAC privati: Sophos Fusion Wireless conosce solo l’indirizzo privato, Sophos Mobile solo quello hardware. Tuttavia, la sola disattivazione non garantisce che Synchronized Security funzioni: verificare l’associazione e il comportamento desiderato nella rete prevista. Non trattarla come una soluzione alternativa per il NAC sui dispositivi BYOD. Con User Enrollment, Sophos non dispone dell’indirizzo MAC per il NAC.

Anche per Wi-Fi in una policy utente iOS, Sophos distingue in Security type tra Personal ed Enterprise. Personal usa la password Wi-Fi. Protocols, Authentication e Trusted certificates sono disponibili solo per Enterprise. Per l’autenticazione con credenziali, User è il nome utente Wi-Fi e Password la password Wi-Fi. Secondo Sophos, Require password on each connect invia la password a ogni autenticazione. Concordare questa selezione con il team RADIUS, senza intenderla come garanzia che venga richiesta la password all’utente. Per l’autenticazione basata su certificati, selezionare invece la Identity certificate appropriata da una configurazione Client certificate della stessa policy utente. Anche il certificato del server in Trusted certificates richiede una configurazione Root certificate in questa policy. Usare il certificato client e la sua accettazione da parte di RADIUS come criteri di verifica solo per il percorso di autenticazione basato su certificati.

Secondo la descrizione Wi-Fi, le decisioni EAP illustrate sopra valgono anche per questa policy utente. Concordare Accepted EAP types con l’autenticazione della rete; per TTLS chiarire il protocollo in Internal identity e per EAP-FAST, se necessario, la Protected Access Credential (PAC). Questa credenziale non è uno script PAC per il proxy. Impostare entrambi i limiti TLS oppure lasciare entrambi non impostati. Outer identity è descritta per TTLS, PEAP ed EAP-FAST ed è richiesta per TLS 1.3. Rispettare le indicazioni precedenti sulla trasmissione in chiaro e sul realm. Non dedurne né la disponibilità di tutte le opzioni nel proprio tenant né il buon esito dell’autenticazione; restano valide l’esclusione del proxy Wi-Fi gestito e le limitazioni MAC/NAC per User Enrollment.

Proxy e VPN sono interventi distinti

  • Proxy Wi-Fi: Nella policy dispositivo iOS si può configurare manualmente o tramite PAC (file con regole proxy). Con Apple User Enrollment, la configurazione Wi-Fi non supporta un proxy. Sophos indica come possibile alternativa WPAD (rilevamento automatico del proxy) sull’access point e la selezione manuale, da parte dell’utente, della modalità automatica per il proxy HTTP nelle impostazioni Wi-Fi: non è una configurazione proxy BYOD gestita da remoto. Verificare separatamente PAC/WPAD, DNS e raggiungibilità.
  • Proxy HTTP globale: Sophos consente questa configurazione dispositivo iOS soltanto sui dispositivi supervisionati; manualmente con server/porta ed eventuali credenziali, oppure automaticamente con un URL PAC. In modalità manuale, Server indica il nome o l’indirizzo IP del proxy HTTP e Port il suo numero di porta. Authentication è il nome utente per connettersi al server proxy e Password la password corrispondente. Non è una promessa di supporto BYOD né di continuità in caso di guasto.
  • VPN a livello di dispositivo: La policy dispositivo iOS prevede tipo di connessione, server e autenticazione; per Custom SSL/TLS deve essere installata l’app del fornitore. Non trasferire questa configurazione ad Apple User Enrollment: Apple non consente una normale VPN a livello dell’intero dispositivo in questa modalità.
  • VPN per app: Configurazione distinta per app selezionate, non equivalente a una VPN a livello di dispositivo. Verificare separatamente l’app del fornitore, server, autenticazione, certificati/proxy facoltativi, On-Demand e regole di dominio per Safari/altri browser, Calendario, Contatti e Mail. Verificare anche Send all traffic through VPN rispetto all’ambito effettivo: dal nome non dedurre un isolamento universale delle app né un effetto su tutto il dispositivo. La documentazione Sophos qui non è uniforme: La descrizione della User Policy include la VPN per app, ma l’assegnazione alle app indica solo Device Policies come prerequisito e opzione selezionabile. Non affermare quindi che esista una procedura di assegnazione BYOD funzionante: verificarla prima nel tenant attuale con un’app e un dispositivo di prova.

VPN a livello di dispositivo: fornitore, autenticazione e percorso del traffico

Le indicazioni seguenti riguardano la configurazione VPN di una policy dispositivo iOS, non la configurazione VPN per app o Apple User Enrollment. Verificare nel proprio tenant la disponibilità e il supporto del fornitore. Connection name è il nome della connessione visualizzato sul dispositivo. In Server, inserire il nome host o l’indirizzo IP del server VPN; confermare l’endpoint appropriato con il responsabile VPN.

  • In Connection type, selezionare il fornitore o il tipo di connessione appropriato. Per un’app del fornitore VPN disponibile nell’App Store, Sophos descrive Custom SSL/TLS. L’app deve essere installata; inserire il suo identificatore in formato reverse DNS in Identifier (reverse DNS format). Se il fornitore specifica parametri di connessione propri, inserire le chiavi e i valori confermati come proprietà di connessione in Third-party settings. Non riutilizzare chiavi o valori di configurazioni di altri fornitori.
  • User authentication riguarda l’autenticazione dell’utente. Account è l’account utente della connessione VPN; Group può indicare un gruppo di autenticazione necessario. In Password, indicare la password VPN; in Certificate, il certificato di autenticazione VPN. Chiarire con il responsabile VPN se sia necessario un gruppo e quale identità utilizzare. Queste credenziali non sono quelle del proxy.
  • Device authentication è distinta. Per Keys (Shared Secret)/Group name, indicare il gruppo richiesto in Group name e la chiave condivisa in Keys (Shared Secret). Sophos menziona Use hybrid authentication e Request password, ma in questa pagina indica solo di selezionarle secondo necessità. Il loro effetto e la selezione necessaria non sono chiariti qui; includere queste due opzioni nel progetto pilota solo dopo la conferma del fornitore. Per Certificate, selezionare il certificato necessario per l’autenticazione del dispositivo. Secondo Sophos, Including user PIN include facoltativamente il PIN dell’utente nell’autenticazione del dispositivo. Non applicare nessuno di questi rami a tutti i fornitori senza verificarlo e non riportare chiavi o PIN reali nei ticket.
  • Send all traffic through VPN è l’impostazione per instradare tutto il traffico attraverso questa connessione VPN. Sophos descrive l’invio di tutto il traffico attraverso la VPN. Verificare sul dispositivo di prova il percorso effettivo del traffico nella modalità scelta per fornitore e tunnel e controllare separatamente il canale di ritorno MDM. Non è una prova che tutto il traffico sia intercettato senza eccezioni o che le app siano isolate.
  • In Proxy, definire il proxy di questa connessione VPN. No proxy significa senza proxy di connessione. Per Manually, inserire indirizzo e porta del proxy in Server and port; Authentication è il nome utente del proxy e Password la sua password. Per Automatic, indicare in Proxy server URL l’URL del server con le impostazioni proxy. Questa selezione non è né il proxy Wi-Fi né la configurazione del proxy HTTP globale; non dedurne requisiti di supervisione o garanzie di continuità in caso di guasto.
  • Provider type distingue il livello di trasporto, non il fornitore selezionato in Connection type. App proxy trasporta il traffico nel tunnel VPN a livello applicativo, Packet tunnel a livello di rete. App proxy non equivale quindi a una VPN per app. Resta da verificare sul dispositivo di destinazione quale opzione supporti il fornitore e quale traffico venga effettivamente intercettato.

VPN per app: parametri e avvio della connessione

Per Per app VPN in una policy dispositivo iOS, Sophos descrive i parametri e i comportamenti seguenti; il loro effetto resta da verificare nel progetto pilota. Queste indicazioni non risolvono la contraddizione descritta sopra nell’assegnazione alle app per le User Policy.

Per Per app VPN, sia nelle policy dispositivo iOS sia nelle policy utente iOS, Connection name è il nome della connessione visualizzato sul dispositivo. Si tratta dell’etichetta visibile della connessione, non dell’identificatore reverse DNS dell’app del fornitore, dell’indirizzo del server o dell’account utente.

  • App del fornitore: Se il fornitore VPN ha un’app nell’App Store che fornisce la connessione VPN, selezionare Custom SSL/TLS. Questa app VPN deve essere installata sul dispositivo; inserire il suo identificatore in formato reverse DNS in Identifier (reverse DNS format), non quello dell’app aziendale da instradare nel tunnel.
  • Autenticazione VPN: Server è il nome host o l’indirizzo IP del server VPN, Account l’account utente per autenticare la connessione. In User authentication, scegliere tra Password e Certificate e indicare, rispettivamente, la password VPN in Password o il certificato di autenticazione VPN in Certificate. Questi dati sono distinti dalle credenziali di un proxy di connessione.
  • Avvio della connessione: Se Connect automatically on demand è attivata, secondo Sophos il dispositivo attiva la VPN quando l’app stabilisce una connessione di rete. Se l’opzione è disattivata, gli utenti devono attivare la VPN autonomamente. Verificare entrambi i percorsi sul dispositivo di prova previsto.
  • Proxy di connessione: Proxy offre No proxy, Manually e Automatic. Per la configurazione manuale, indicare indirizzo valido e porta del proxy in Server and port, nome utente del proxy in Authentication e relativa password in Password. Per la configurazione automatica, inserire in Proxy server URL l’URL del server con le impostazioni proxy. È il proxy di questa connessione VPN, non la configurazione del proxy HTTP globale.

Per Domains in Safari, Domains in Calendar, Domains in Contacts e Domains in Mail vale la stessa sintassi: un dominio, un dominio parziale o un nome host per riga. Un dominio parziale corrisponde quando tutti i componenti separati da punti coincidono partendo da destra; i punti iniziali e finali vengono ignorati. Una stringa senza punti corrisponde solo all’host con quel nome, non a qualsiasi dominio con quella terminazione. Si applica inoltre la regola aggiuntiva sul dominio di secondo livello per Calendario, Contatti e Mail; la sezione sul progetto pilota descrive il test positivo appropriato.

VPN per app nella policy utente e assegnazione alle app

La descrizione Sophos di Per app VPN in una policy utente iOS documenta anche i parametri illustrati sopra per l’app del fornitore VPN installata e il suo identificatore reverse DNS, l’autenticazione con Password o Certificate, l’avvio della connessione On-Demand, il proxy di connessione e la sintassi dei domini. Queste caratteristiche comuni documentate non dimostrano che esista un percorso di assegnazione funzionante con Apple User Enrollment.

Sophos documenta i seguenti campi condizionali per Per app VPN sia nelle policy dispositivo iOS sia nelle policy utente iOS. Le condizioni valgono per entrambi i tipi di policy; verificare nel proprio tenant la disponibilità e il supporto del fornitore:

  • In Third-party settings è possibile inserire le proprietà di connessione specificate dal fornitore VPN. Il campo è disponibile solo per Custom SSL/TLS. Con Add, inserire i valori confermati per Key e Value. Queste proprietà di connessione non sono la Managed configuration dell’app aziendale da instradare nel tunnel.
  • Group indica il gruppo necessario per l’autenticazione. Il campo è disponibile solo per Cisco AnyConnect e Cisco Legacy AnyConnect. Non applicare questa condizione ad altri tipi di connessione.
  • In Provider type, App proxy trasporta il traffico nel tunnel VPN a livello applicativo, Packet tunnel a livello di rete. Questa impostazione non è disponibile per Cisco AnyConnect. Verificare sul dispositivo di prova previsto quale opzione supporti il fornitore e quale traffico venga effettivamente intercettato. Il solo livello di trasporto non dimostra né l’isolamento delle app né un effetto VPN sull’intero dispositivo.

L’assegnazione di una connessione esistente all’app aziendale fa parte del flusso di distribuzione delle app nella sezione «Verificare la configurazione gestita e il comportamento dell’app». In quella sezione, Assegnare una VPN per app è esplicitamente limitato alle policy dispositivo esistenti. I responsabili delle policy forniscono la connessione appropriata; i responsabili delle app la selezionano in VPN connection used by the app. Questo rimando non risolve l’incertezza descritta sopra per le policy utente e non autorizza un percorso di assegnazione BYOD non verificato.

Controlli preliminari, osservazione del progetto pilota e diagnosi dei guasti

  1. Inventario e via di ripristino: Annotare proprietà del dispositivo, registrazione, supervisione, versione iOS/iPadOS, policy interessata e assegnazione. Per un dispositivo aziendale supervisionato e uno personale BYOD usato volontariamente per la prova, individuare in entrambi i casi una connessione indipendente (per esempio rete cellulare o un’altra rete Wi-Fi) e una persona di riferimento. Senza questa via, non distribuire modifiche che potrebbero bloccare la connessione. Per modificare una policy dispositivo iOS, usare una policy pilota assegnata soltanto al dispositivo aziendale di prova; prima di aggiornarla, verificarne le assegnazioni attuali e il numero di dispositivi destinatari. Non modificare per il progetto pilota una policy già assegnata ai dispositivi di produzione.
  2. Dipendenze: Verificare la raggiungibilità di DNS, APNs/MDM, CA/SCEP/RA, server RADIUS/EAP, PAC/WPAD ed endpoint VPN prima e dopo la modifica. Controllare catena dei certificati, nomi dei server, scadenza e sostituzione pianificata; non copiare nei ticket chiavi private, challenge o credenziali. Una policy correttamente assegnata, da sola, non dimostra che Wi-Fi o VPN funzionino.
  3. Progetto pilota mirato: Iniziare con dispositivi di prova separati e un’assegnazione minima. Registrare come criteri di verifica, non come risultati già confermati, che il dispositivo accetti l’identità verificata del server RADIUS e si connetta al Wi-Fi aziendale. Per l’autenticazione basata su certificati, verificare inoltre la ricezione del certificato client e la sua accettazione da parte di RADIUS; per l’autenticazione con nome utente e password, verificare il percorso previsto per le credenziali. Per la VPN per app, verificare il traffico nel tunnel dell’app di prova gestita a cui è assegnata; usare l’accesso di altre app come test negativo solo se tali app non hanno un’altra assegnazione VPN e non corrispondono a una regola di dominio configurata. Se sono configurati domini per Safari/altri browser, Calendario, Contatti o Mail, verificare anche gli accessi previsti ai domini corrispondenti e non aspettarsi indiscriminatamente che «gli altri accessi restino fuori dal tunnel». Verificare separatamente i domini di Safari e degli altri browser: secondo Sophos, per usare Calendario, Contatti e Mail come test positivi è inoltre necessario che il dominio di secondo livello del dominio configurato coincida con quello del server VPN. Un dominio diverso non costituisce un test positivo valido del tunnel e la mancata connessione, da sola, non dimostra che la distribuzione della VPN sia fallita. Verificare le regole di dominio nel proprio tenant, senza trasformare questa condizione in una procedura di configurazione non collaudata. Verificare separatamente sul dispositivo di prova l’effetto di Send all traffic through VPN nella modalità scelta per fornitore e tunnel; non dedurne effetti non verificati sull’intero dispositivo o sull’isolamento delle app. Per la VPN per app in una User Policy, dimostrare che l’assegnazione alle app sia effettivamente disponibile oppure escludere per ora la funzione. Per PAC/WPAD, osservare il comportamento previsto in caso di mancato accesso web/proxy; dopo ogni modifica, confermare separatamente un nuovo check-in MDM e il funzionamento effettivo della rete. Se il check-in non avviene o manca la connessione indipendente, fermare il progetto pilota e non assegnare altri dispositivi.
  4. Diagnosi dei guasti: Se il Wi-Fi non funziona, controllare anzitutto SSID e tipo di sicurezza, nome del server EAP e CA attendibile; per l’autenticazione con credenziali, verificare nome utente, password e percorso di autenticazione RADIUS previsto; per l’autenticazione basata su certificati, verificare identità client emessa e raggiungibilità della CA; se non funziona il web, controllare PAC/WPAD/DNS e accesso al proxy; se non funziona un’app, controllare app del fornitore, tunnel, certificato e assegnazione. Osservare separatamente lo stato dell’operazione/check-in e la connessione effettiva. Evitare di provocare un secondo guasto rimuovendo certificati o profili senza controllo.

Ripristino senza reimpostare il dispositivo

Prima del progetto pilota, preparare una policy sostitutiva e una catena di attendibilità sostitutiva funzionanti, con una rete raggiungibile. Rimuovere la vecchia CA e i certificati d’identità solo dopo aver confermato sul dispositivo di destinazione la sostituzione e il check-in MDM.

Per le policy dispositivo iOS, secondo Sophos le modifiche richiedono Update devices: l’operazione crea un’attività di aggiornamento per tutti i dispositivi ai quali è assegnata la policy modificata, non soltanto per il dispositivo pilota. Aggiornare quindi solo la policy pilota isolata, dopo averne verificato i dispositivi destinatari attuali; un’attività mirata Assign policy per dispositivi selezionati non equivale all’aggiornamento di una policy condivisa. L’operazione mirata Uninstall policy è prevista per Device Enrollment, ma può rimuovere a sua volta la connessione di rete. Per le policy utente iOS sui dispositivi con User Enrollment, l’operazione Uninstall policy non è disponibile: Sophos offre invece l’operazione mirata Unassign iOS user policy. A seconda del guasto, può essere utile anche aggiornare la policy o assegnarne un’altra. Non confondere l’operazione mirata con Unassign per tutti i dispositivi.

iPadOS: distinguere le azioni dirette dai tipi di attività. La guida all’assegnazione delle policy chiarisce la terminologia non uniforme delle procedure dirette di aggiornamento e disinstallazione: la panoramica dei tipi indica iOS/iPadOS, mentre le istruzioni dirette citano solo iOS device policies. Non applicare quindi la loro sequenza di clic a iPadOS senza verificarla; chiarire il percorso diretto disponibile nel tenant e sul dispositivo pilota. Ciò non significa che il ripristino su iPadOS sia in generale impossibile o non documentato: i tipi di attività iOS/iPadOS documentano Uninstall policy per Device Enrollment e Unassign iOS user policy per User Enrollment. Il flusso dei pacchetti di attività in base alla modalità di gestione descrive questa scelta; continuare a verificare separatamente il trasferimento dell’attività e l’effetto effettivo della revoca.

Verificare il ripristino separatamente su un dispositivo aziendale di prova ancora raggiungibile con Device Enrollment e su un dispositivo BYOD di prova ancora raggiungibile con User Enrollment: sul primo provare l’operazione mirata Uninstall policy solo per quel dispositivo; sul secondo l’operazione mirata Unassign iOS user policy. Per ciascun dispositivo confermare lo stato dell’operazione/check-in e lo stato della policy effettivamente sincronizzata; poi verificare di nuovo e indipendentemente l’uno dall’altro il funzionamento di Wi-Fi/VPN e il contatto MDM. Limitare ulteriori assegnazioni o rimozioni ai soli dispositivi di prova effettivamente verificati finché entrambe le vie di ripristino non siano dimostrate. Un’operazione salvata o inviata non raggiunge automaticamente un dispositivo offline e privo di accesso. Serve la connessione indipendente e la procedura di ripristino locale pianificate in precedenza; Unassign per tutti i dispositivi non è una misura immediata a basso rischio. Né la cancellazione completa (Wipe) né l’annullamento dello User Enrollment costituiscono un rollback generale della policy.