VPN-configuratie op Android blokkeren: checklist voor de uitrol
Bepaal het beleid, bevestig de bevoegdheid die u hebt, controleer het gedrag per versie en houd het goedgekeurde always-on-pad in leven voordat u handhaaft.
Iemand vraagt u te voorkomen dat mensen hun eigen VPN configureren op beheerde Android-apparaten. Het verleidelijke antwoord is een firewallregel die een paar bekende poorten blokkeert. Dat antwoord mist hoe het platform werkt en hoe applicaties daadwerkelijk verbinden.
De ondersteunde controle is een beheerbeperking op het apparaat of profiel dat u bezit, en die heeft een expliciete reikwijdte, versieafhankelijk gedrag en een uitzondering die u bewust moet configureren.
Doorloop de vijf controles hieronder in volgorde. Elk kan het plan ongeldig maken, dus stop bij de eerste die geen stand houdt.
Controle 1: bepaal wat geen VPN betekent
Achter dezelfde zin schuilen twee eisen. De ene is dat geen enkele gebruiker zijn eigen VPN mag aanmaken. De andere is dat alleen de goedgekeurde VPN van de organisatie mag draaien. Beide zijn legitiem, en ze leveren verschillende configuraties, verschillende supportverhalen en verschillende faalwijzen op.
Schrijf op welke van de twee u koopt voordat u een beheerconsole aanraakt. Als de bedoeling één goedgekeurde tunnel voor iedereen is, implementeert u een goedgekeurd pad met een verbod eromheen; als de bedoeling helemaal geen tunnels is, moet u ook accepteren dat paden voor externe toegang en probleemoplossing veranderen.
Ga hier de fout in en de uitrol lijkt te werken terwijl hij stil de VPN afsnijdt waar de operatie van afhankelijk is, meestal ontdekt door de persoon die dienst heeft op een ongunstig uur.
Controle 2: bevestig de bevoegdheid die u werkelijk hebt
Android maakt de beperking beschikbaar via UserManager.DISALLOW_CONFIG_VPN, gedocumenteerd in de UserManager-referentie. Het voorkomt VPN-configuratie en -start, en het is geen instelling die een gewone applicatie op zichzelf of op andere apps kan toepassen.
Hij wordt toegepast door een bevoegde beheerder: een apparaateigenaar voor het hele apparaat, of een profieleigenaar voor het beheerde profiel, waarbij dezelfde bevoegdheid beschikbaar is voor een profieleigenaar binnen het beheerde profiel. Als uw EMM niet als een van die kan optreden, hebt u deze controle niet, en geen enkele beleidsconfiguratie in de console zal hem creëren.
Reikwijdte is net zo belangrijk als bevoegdheid. Een beperking op een werkprofiel beheert dat profiel, niet de persoonlijke kant van dezelfde telefoon. Dat beschrijven als controle over alles wat de gebruiker doet is onjuist, en het zal worden getest door de eerste persoon die een VPN in het persoonlijke profiel installeert en ontdekt dat die werkt.
Controle 3: ken het gedrag per versie
De beperking is tussen releases veranderd, en de verschillen bepalen wat uw uitrol werkelijk doet op de apparaten in het veld.
| Platformgrens | Gedocumenteerd gedrag |
|---|---|
| Apparaat- of profieleigenaar | De beperking kan onder de bevoegdheid van die eigenaar worden toegepast |
| API 24 en later | Een always-on-VPN die de apparaat- of profieleigenaar heeft geconfigureerd, wordt nog steeds door het systeem gestart |
| API 31 en later | Het aanzetten van de beperking verbreekt een VPN die de gebruiker al had draaien |
De API 31-regel is degene die mensen midden in de uitrol verrast: op die apparaten is handhaving niet cosmetisch, het verbreekt een tunnel die al liep. Plan dat als een zichtbare gebeurtenis en niet als een stille instellingswijziging.
De API 24-regel is degene die u redt: een door de eigenaar geconfigureerde always-on-VPN overleeft de beperking, en zo blijft het goedgekeurde pad überhaupt beschikbaar.
Controle 4: houd het goedgekeurde pad in leven
Configureer en test de always-on-VPN van de organisatie voordat u de beperking handhaaft, niet erna. Handhaaft u eerst, dan verliezen de apparaten de tunnel en het gereedschap waarmee u ze zou diagnosticeren tegelijk.
Verifieer drie dingen expliciet: dat de always-on-VPN door de eigenaar wordt aangemaakt en niet door de gebruiker; dat hij op die apparaten start na de handhaving; en dat hij een herstart overleeft. Een tunnel die alleen handmatig omhoogkomt is geen goedgekeurd pad; het is een wachtrij van supporttickets.
Houd een herstelroute die niet afhankelijk is van een werkende tunnel. Een beheerconsole, een lokaal adminpad of een out-of-band-kanaal werken allemaal. Wat niet werkt, is aannemen dat u een kapot beleid kunt repareren via de verbinding die het beleid net heeft uitgeschakeld.
Controle 5: verifieer en beschrijf daarna de grens eerlijk
Test met een echt apparaat en een echt account. Bevestig dat een gebruiker geen VPN kan toevoegen of starten, bevestig dat de goedgekeurde tunnel verbindt en verkeer draagt, en bevestig dat het persoonlijke profiel zich nog gedraagt zoals gedocumenteerd. Die drie resultaten zijn de acceptatiecriteria.
Wees daarna voorzichtig met wat u beweert. De beperking beheert de VPN-mogelijkheid van Android. Hij maakt niet elke toegestane verbinding een geïnspecteerd protocol, en hij weerhoudt een app er niet van zijn eigen verzoeken via een expliciete proxy te routeren. UDP 500, UDP 4500 en één OpenVPN-poort blokkeren is niet dezelfde controle, omdat verkeer over vele transporten kan reizen, inclusief gewoon uitziend HTTPS.
Als de eis breder is dan de VPN-mogelijkheid, combineer dit dan met app-distributiebeleid, accountcontroles en netwerkbeperkingen die bij de omgeving passen. En leg vast wat buiten de reikwijdte blijft, zodat niemand in de volgende audit een gedeeltelijke beperking als volledige herhaalt.