Bloqueja la configuració de VPN a Android: llista de comprovació per al desplegament
Decidiu la política, confirmeu l'autoritat que teniu, comproveu el comportament per versió i manteniu viu el camí aprovat d'always-on abans d'aplicar la restricció.
Algú us demana que impedeixi que la gent configuri la seva pròpia VPN en dispositius Android gestionats. La resposta temptadora és una regla de tallafocs que bloquegi uns quants ports coneguts. Aquesta resposta ignora com funciona la plataforma i com es connecten realment les aplicacions.
El control suportat és una restricció de gestió sobre el dispositiu o el perfil que posseïu, i té un abast explícit, un comportament específic per versió i una excepció que heu de configurar deliberadament.
Feu les cinc comprovacions següents en ordre. Cadascuna pot invalidar el pla, així que atureu-vos a la primera que no es compleixi.
Comprovació 1: decidiu què vol dir cap VPN
Darrere d'una mateixa frase s'amaguen dos requisits. Un és que cap usuari no pugui crear la seva pròpia VPN. L'altre és que només pugui funcionar la VPN aprovada de l'organització. Tots dos són legítims i produeixen configuracions diferents, històries de suport diferents i maneres de fallar diferents.
Anoteu quin dels dos compreu abans de tocar cap consola de gestió. Si la intenció és un únic túnel aprovat per a tothom, esteu implementant un camí aprovat amb una prohibició al voltant; si la intenció és no tenir cap túnel, també heu d'acceptar que els camins d'accés remot i de resolució de problemes canvien.
Equivoqueu-vos aquí i el desplegament semblarà funcionar mentre talla en silenci la VPN de la qual depèn l'operació, normalment descobert per la persona de guàrdia en un moment inoportú.
Comprovació 2: confirmeu l'autoritat que realment teniu
Android exposa la restricció mitjançant UserManager.DISALLOW_CONFIG_VPN, documentada a la referència de UserManager. Impedeix la configuració i l'inici de VPN, i no és un paràmetre que cap aplicació corrent pugui aplicar-se a si mateixa ni a altres aplicacions.
L'aplica un administrador autoritzat: un propietari del dispositiu per a tot el dispositiu, o un propietari del perfil per al perfil gestionat, amb la mateixa autoritat disponible per a un propietari del perfil dins del perfil gestionat. Si el vostre EMM no pot actuar com un d'aquests, no teniu aquest control, i cap quantitat de configuració de polítiques a la consola el crearà.
L'abast importa tant com l'autoritat. Una restricció aplicada a un perfil de treball governa aquell perfil, no la part personal del mateix telèfon. Descriure-ho com a control sobre tot el que fa l'usuari és inexacte, i ho posarà a prova la primera persona que instal·li una VPN al perfil personal i comprovi que funciona.
Comprovació 3: conegueu el comportament per versió
La restricció ha canviat entre versions, i les diferències decideixen què farà realment el vostre desplegament als dispositius del camp.
| Límit de la plataforma | Comportament documentat |
|---|---|
| Propietari del dispositiu o del perfil | La restricció es pot aplicar sota l'autoritat d'aquest propietari |
| API 24 i posteriors | El sistema encara inicia una VPN always-on que hagi configurat el propietari del dispositiu o del perfil |
| API 31 i posteriors | Activar la restricció desconnecta una VPN que l'usuari ja tenia en marxa |
La fila d'API 31 és la que sorprèn la gent a mig desplegament: en aquests dispositius l'aplicació no és cosmètica, desconnecta un túnel que ja funcionava. Planifiqueu-ho com un esdeveniment visible i no com un canvi silenciós de paràmetres.
La fila d'API 24 és la que us salva: una VPN always-on configurada pel propietari sobreviu a la restricció, i així és com el camí aprovat continua disponible.
Comprovació 4: manteniu viu el camí aprovat
Configureu i proveu la VPN always-on de l'organització abans d'aplicar la restricció, no després. Si apliqueu primer, els dispositius perden el túnel i les eines amb què els diagnosticaríeu alhora.
Verifiqueu tres coses explícitament: que la VPN always-on la crea el propietari i no l'usuari, que s'inicia en aquests dispositius després de l'aplicació, i que sobreviu a un reinici. Un túnel que només puja manualment no és un camí aprovat; és una cua de tiquets de suport.
Manteniu una via de recuperació que no depengui que el túnel estigui actiu. Una consola de gestió, un camí d'administrador local o un canal fora de banda serveixen. El que no serveix és assumir que podeu arreglar una política trencada a través de la connexió que la política acaba de desactivar.
Comprovació 5: verifiqueu i, després, descriviu el límit amb honestedat
Proveu amb un dispositiu real i un compte real. Confirmeu que un usuari no pot afegir ni iniciar una VPN, confirmeu que el túnel aprovat es connecta i transporta trànsit, i confirmeu que el perfil personal encara es comporta tal com està documentat. Aquests tres resultats són els criteris d'acceptació.
Després aneu amb compte amb el que afirmueu. La restricció governa la capacitat de VPN d'Android. No converteix cada connexió permesa en un protocol inspeccionat ni impedeix que una aplicació encamini les seves pròpies peticions a través d'un proxy explícit. Bloquejar UDP 500, UDP 4500 i un OpenVPN port no és el mateix control, perquè el trànsit pot viatjar per molts transports, incloent-hi HTTPS d'aspecte corrent.
Si el requisit és més ampli que la capacitat de VPN, combineu-ho amb la política de distribució d'aplicacions, controls de compte i restriccions de xarxa adequades a l'entorn. I anoteu què queda fora de l'abast, perquè ningú no repeteixi una restricció parcial com a completa a la propera auditoria.