Bloker VPN-konfiguration på Android: tjekliste til udrulning
Beslut politikken, bekræft den myndighed du har, kontroller adfærden pr. version, og hold den godkendte always-on-vej i live, før du håndhæver.
Nogen beder dig forhindre folk i at konfigurere deres egen VPN på administrerede Android-enheder. Det fristende svar er en firewallregel, der blokerer nogle få kendte porte. Det svar overser, hvordan platformen fungerer, og hvordan applikationer faktisk forbinder.
Den understøttede kontrol er en administrationsbegrænsning på den enhed eller profil, du ejer, og den har et udtrykkeligt omfang, versionsafhængig adfærd og en undtagelse, du skal konfigurere bevidst.
Gå gennem de fem kontroller nedenfor i rækkefølge. Hver af dem kan ugyldiggøre planen, så stop ved den første, der ikke holder.
Kontrol 1: beslut, hvad ingen VPN betyder
To krav gemmer sig bag samme sætning. Det ene er, at ingen bruger må oprette sin egen VPN. Det andet er, at kun organisationens godkendte VPN må køre. Begge er legitime, og de giver forskellige konfigurationer, forskellige supportforløb og forskellige fejltilstande.
Skriv ned, hvilken af dem du køber, før du rører en administrationskonsol. Hvis hensigten er en enkelt godkendt tunnel til alle, implementerer du en godkendt vej med et forbud omkring den; hvis hensigten er ingen tunneler overhovedet, må du også acceptere, at fjernadgangs- og fejlfindingsveje ændrer sig.
Tager du fejl her, ser udrulningen ud til at virke, mens den stille skærer den VPN fra, som driften er afhængig af, og det opdages normalt af den person, der har vagten på et ubelejligt tidspunkt.
Kontrol 2: bekræft den myndighed, du faktisk har
Android eksponerer begrænsningen gennem UserManager.DISALLOW_CONFIG_VPN, dokumenteret i UserManager-referencen. Den forhindrer VPN-konfiguration og -opstart, og det er ikke en indstilling, som en almindelig applikation kan anvende på sig selv eller på andre apps.
Den anvendes af en autoriseret administrator: en enhedsejer for hele enheden eller en profilejer for den administrerede profil, med samme myndighed tilgængelig for en profilejer inde i den administrerede profil. Hvis din EMM ikke kan fungere som en af disse, har du ikke denne kontrol, og ingen mængde politikonfiguration i konsollen vil skabe den.
Omfang betyder lige så meget som myndighed. En begrænsning, der anvendes på en arbejdsprofil, styrer den profil, ikke den personlige side af samme telefon. At beskrive det som kontrol over alt, brugeren gør, er upræcist, og det vil blive testet af den første, der installerer en VPN i den personlige profil og konstaterer, at den virker.
Kontrol 3: kend adfærden pr. version
Begrænsningen har ændret sig gennem versionerne, og forskellene afgør, hvad din udrulning faktisk vil gøre på enhederne i marken.
| Platformsgrænse | Dokumenteret adfærd |
|---|---|
| Enhedsejer eller profilejer | Begrænsningen kan anvendes under den ejers myndighed |
| API 24 og senere | En always-on-VPN, som enheds- eller profilejeren har konfigureret, startes stadig af systemet |
| API 31 og senere | Slås begrænsningen til, afbrydes en VPN, som brugeren allerede havde kørende |
API 31-rækken er den, der overrasker folk midt i udrulningen: på de enheder er håndhævelsen ikke kosmetisk, den afbryder en tunnel, der allerede kørte. Planlæg det som en synlig begivenhed i stedet for en stille indstillingsændring.
API 24-rækken er den, der redder dig: en always-on-VPN, der er konfigureret af ejeren, overlever begrænsningen, og det er sådan, den godkendte vej overhovedet forbliver tilgængelig.
Kontrol 4: hold den godkendte vej i live
Konfigurer og test organisationens always-on-VPN, før du håndhæver begrænsningen, ikke bagefter. Håndhæver du først, mister enhederne tunnelen og det værktøj, du ville diagnosticere dem med, på samme tid.
Bekræft tre ting udtrykkeligt: at always-on-VPN'en oprettes af ejeren og ikke af brugeren, at den starter på de enheder efter håndhævelsen, og at den overlever en genstart. En tunnel, der kun kommer op manuelt, er ikke en godkendt vej; det er en kø af supportbilletter.
Behold en gendannelsesvej, der ikke afhænger af, at tunnelen er oppe. En administrationskonsol, en lokal admin-vej eller en out-of-band-kanal virker alle. Det, der ikke virker, er at antage, at du kan rette en ødelagt politik gennem den forbindelse, som politikken netop har deaktiveret.
Kontrol 5: verificér, og beskriv så grænsen ærligt
Test med en rigtig enhed og en rigtig konto. Bekræft, at en bruger ikke kan tilføje eller starte en VPN, bekræft, at den godkendte tunnel forbinder og bærer trafik, og bekræft, at den personlige profil stadig opfører sig som dokumenteret. De tre resultater er acceptkriterierne.
Vær derefter omhyggelig med, hvad du påstår. Begrænsningen styrer Androids VPN-evne. Den gør ikke hver tilladt forbindelse til en inspiceret protokol, og den forhindrer ikke en app i at route sine egne anmodninger gennem en eksplicit proxy. At blokere UDP 500, UDP 4500 og en OpenVPN-port er ikke den samme kontrol, fordi trafik kan rejse over mange transporter, inklusive almindeligt udseende HTTPS.
Hvis kravet er bredere end VPN-evnen, så kombinér det med appdistributionspolitik, kontokontroller og netværksbegrænsninger, der passer til miljøet. Og registrér, hvad der forbliver uden for omfanget, så ingen gentager en delvis begrænsning som en fuldstændig i næste revision.