Blocarea configurației VPN pe Android: listă de verificare pentru implementare

Cineva vă roagă să împiedicați oamenii să își configureze propriul VPN pe dispozitive Android administrate. Răspunsul tentant este o regulă de firewall care blochează câteva porturi cunoscute. Acel răspuns ignoră modul în care funcționează platforma și modul în care aplicațiile se conectează de fapt.

Controlul acceptat este o restricție de administrare asupra dispozitivului sau profilului pe care îl dețineți, și are un domeniu explicit, un comportament dependent de versiune și o excepție pe care trebuie să o configurați în mod deliberat.

Parcurgeți cele cinci verificări de mai jos în ordine. Oricare poate invalida planul, așa că opriți-vă la prima care nu rezistă.

Verificarea 1: decideți ce înseamnă niciun VPN

În spatele aceleiași propoziții se ascund două cerințe. Una este că niciun utilizator nu poate crea propriul VPN. Cealaltă este că doar VPN-ul aprobat al organizației poate rula. Ambele sunt legitime și produc configurații diferite, povești de suport diferite și moduri de eșec diferite.

Notați pe care dintre ele îl cumpărați înainte de a atinge vreo consolă de administrare. Dacă intenția este un singur tunel aprobat pentru toți, implementați un traseu aprobat cu o interdicție în jurul lui; dacă intenția este niciun tunel, trebuie să acceptați și că traseele de acces la distanță și de depanare se schimbă.

Greșiți aici și implementarea va părea că funcționează în timp ce taie în liniște VPN-ul de care depinde operațiunea, lucru descoperit de obicei de persoana de gardă la o oră incomodă.

Verificarea 2: confirmați autoritatea pe care o aveți cu adevărat

Android expune restricția prin UserManager.DISALLOW_CONFIG_VPN, documentată în referința UserManager. Împiedică configurarea și pornirea VPN-ului și nu este o setare pe care o aplicație obișnuită o poate aplica asupra ei sau asupra altor aplicații.

Este aplicată de un administrator autorizat: un proprietar al dispozitivului pentru întregul dispozitiv sau un proprietar al profilului pentru profilul administrat, cu aceeași autoritate disponibilă pentru un proprietar al profilului în interiorul profilului administrat. Dacă EMM-ul dumneavoastră nu poate acționa ca unul dintre aceștia, nu aveți acest control, iar nicio configurare de politici din consolă nu îl va crea.

Domeniul contează la fel de mult ca autoritatea. O restricție aplicată unui profil de lucru guvernează acel profil, nu partea personală a aceluiași telefon. Descrierea acesteia ca un control asupra a tot ce face utilizatorul este inexactă și va fi testată de prima persoană care instalează un VPN în profilul personal și constată că funcționează.

Verificarea 3: cunoașteți comportamentul pe versiuni

Restricția s-a schimbat de-a lungul versiunilor, iar diferențele decid ce va face de fapt implementarea dumneavoastră pe dispozitivele din teren.

Rândul API 31 este cel care surprinde oamenii la mijlocul implementării: pe acele dispozitive aplicarea nu este cosmetică, deconectează un tunel care funcționa deja. Planificați asta ca un eveniment vizibil, nu ca o schimbare silențioasă de setări.

Rândul API 24 este cel care vă salvează: un VPN de conexiune permanentă configurat de proprietar supraviețuiește restricției și astfel traseul aprobat rămâne disponibil.

Verificarea 4: mențineți viu traseul aprobat

Configurați și testați VPN-ul de conexiune permanentă al organizației înainte de a aplica restricția, nu după. Dacă aplicați mai întâi, dispozitivele pierd tunelul și instrumentele cu care le-ați diagnostica în același timp.

Verificați explicit trei lucruri: că VPN-ul de conexiune permanentă este creat de proprietar, nu de utilizator; că pornește pe acele dispozitive după aplicare; și că supraviețuiește unei reporniri. Un tunel care urcă doar manual nu este un traseu aprobat; este o coadă de tichete de suport.

Păstrați o cale de recuperare care nu depinde de faptul că tunelul este activ. O consolă de administrare, o cale de administrator local sau un canal în afara benzii funcționează toate. Ce nu funcționează este să presupuneți că puteți repara o politică stricată prin conexiunea pe care politica tocmai a dezactivat-o.

Verificarea 5: verificați, apoi descrieți limita cu onestitate

Testați cu un dispozitiv real și un cont real. Confirmați că un utilizator nu poate adăuga sau porni un VPN, confirmați că tunelul aprobat se conectează și transportă trafic și confirmați că profilul personal se comportă în continuare conform documentației. Aceste trei rezultate sunt criteriile de acceptare.

Apoi fiți atenți la ce afirmați. Restricția guvernează capacitatea VPN a Androidului. Nu transformă fiecare conexiune permisă într-un protocol inspectat și nu împiedică o aplicație să își direcționeze propriile cereri printr-un proxy explicit. Blocarea UDP 500, UDP 4500 și a unui OpenVPN port nu este același control, pentru că traficul poate călători prin multe transporturi, inclusiv printr-un HTTPS cu aspect obișnuit.

Dacă cerința este mai largă decât capacitatea VPN, combinați aceasta cu politica de distribuție a aplicațiilor, controalele de cont și restricțiile de rețea potrivite mediului. Și notați ce rămâne în afara domeniului, ca nimeni să nu repete o restricție parțială ca fiind completă la următorul audit.