Bloccare la configurazione VPN su Android: checklist di distribuzione
Decidete la politica, confermate l'autorità che avete, verificate il comportamento per versione e mantenete vivo il percorso approvato always-on prima di applicare la restrizione.
Qualcuno vi chiede di impedire alle persone di configurare il proprio VPN sui dispositivi Android gestiti. La risposta tentatrice è una regola del firewall che blocca alcuni port noti. Quella risposta trascura come funziona la piattaforma e come le applicazioni si connettono davvero.
Il controllo supportato è una restrizione di gestione sul dispositivo o sul profilo che possedete, e ha un ambito esplicito, un comportamento specifico per versione e un'eccezione che dovete configurare deliberatamente.
Percorrete i cinque controlli qui sotto in ordine. Ognuno può invalidare il piano, quindi fermatevi al primo che non regge.
Controllo 1: decidete cosa significa nessun VPN
Due requisiti si nascondono dietro la stessa frase. Uno è che nessun utente possa creare un proprio VPN. L'altro è che possa funzionare solo il VPN approvato dell'organizzazione. Entrambi sono legittimi, e producono configurazioni diverse, storie di supporto diverse e modalità di guasto diverse.
Annotate quale dei due state acquistando prima di toccare qualsiasi console di gestione. Se l'intento è un unico tunnel approvato per tutti, state implementando un percorso approvato con un divieto intorno; se l'intento è nessun tunnel, dovete anche accettare che i percorsi di accesso remoto e di risoluzione dei problemi cambino.
Sbagliate questo e la distribuzione sembrerà funzionare mentre taglia in silenzio il VPN da cui dipende l'esercizio, cosa che di solito scopre la persona di turno a un'ora scomoda.
Controllo 2: confermate l'autorità che avete davvero
Android espone la restrizione tramite UserManager.DISALLOW_CONFIG_VPN, documentata nella documentazione di riferimento di UserManager. Impedisce la configurazione e l'avvio di VPN, e non è un'impostazione che un'applicazione ordinaria possa applicare a sé stessa o ad altre applicazioni.
La applica un amministratore autorizzato: un proprietario del dispositivo per l'intero dispositivo, o un proprietario del profilo per il profilo gestito, con la stessa autorità disponibile per un proprietario del profilo all'interno del profilo gestito. Se il vostro EMM non può agire come uno di questi, non avete questo controllo, e nessuna quantità di configurazione delle politiche nella console lo creerà.
L'ambito conta quanto l'autorità. Una restrizione applicata a un profilo di lavoro governa quel profilo, non la parte personale dello stesso telefono. Descriverla come controllo su tutto ciò che fa l'utente è impreciso, e sarà messa alla prova dalla prima persona che installa un VPN nel profilo personale e scopre che funziona.
Controllo 3: conoscete il comportamento per versione
La restrizione è cambiata tra le versioni, e le differenze decidono cosa farà davvero la vostra distribuzione sui dispositivi sul campo.
| Limite della piattaforma | Comportamento documentato |
|---|---|
| Proprietario del dispositivo o del profilo | La restrizione può essere applicata sotto l'autorità di quel proprietario |
| API 24 e successive | Un VPN always-on configurato dal proprietario del dispositivo o del profilo viene ancora avviato dal sistema |
| API 31 e successive | Attivare la restrizione disconnette un VPN che l'utente aveva già in esecuzione |
La riga API 31 è quella che sorprende le persone a metà distribuzione: su quei dispositivi l'applicazione non è cosmetica, disconnette un tunnel che era già in esecuzione. Pianificatelo come un evento visibile e non come un cambiamento silenzioso delle impostazioni.
La riga API 24 è quella che vi salva: un VPN always-on configurato dal proprietario sopravvive alla restrizione, ed è così che il percorso approvato resta disponibile.
Controllo 4: mantenete vivo il percorso approvato
Configurate e testate il VPN always-on dell'organizzazione prima di applicare la restrizione, non dopo. Se applicate prima, i dispositivi perdono il tunnel e gli strumenti con cui li diagnosticate nello stesso momento.
Verificate tre cose in modo esplicito: che il VPN always-on sia creato dal proprietario e non dall'utente, che si avvii su quei dispositivi dopo l'applicazione e che sopravviva a un riavvio. Un tunnel che sale solo manualmente non è un percorso approvato; è una coda di ticket di supporto.
Mantenete una via di ripristino che non dipenda dal fatto che il tunnel sia attivo. Una console di gestione, un percorso di amministratore locale o un canale fuori banda funzionano tutti. Ciò che non funziona è presumere di poter riparare una politica rotta attraverso la connessione che la politica ha appena disattivato.
Controllo 5: verificate, poi descrivete il limite con onestà
Provate con un dispositivo reale e un account reale. Confermate che un utente non possa aggiungere o avviare un VPN, confermate che il tunnel approvato si connetta e trasporti traffico, e confermate che il profilo personale si comporti ancora come documentato. Quei tre risultati sono i criteri di accettazione.
Poi fate attenzione a ciò che affermate. La restrizione governa la capacità VPN di Android. Non trasforma ogni connessione consentita in un protocollo ispezionato, e non impedisce a un'app di instradare le proprie richieste attraverso un proxy esplicito. Bloccare UDP 500, UDP 4500 e una OpenVPN porta non è lo stesso controllo, perché il traffico può viaggiare su molti trasporti, incluso un HTTPS dall'aspetto ordinario.
Se il requisito è più ampio della capacità VPN, combinate questo con la politica di distribuzione delle app, i controlli sugli account e le restrizioni di rete adatte all'ambiente. E annotate ciò che resta fuori dall'ambito, così che nessuno ripeta una restrizione parziale come completa nel prossimo audit.