Trenger du VPN for Apple MDM? Tre tilgangsbehov, ett svar

Spørsmålet er sjelden om Apple-enhetsadministrasjon trenger kryptering, for det gjør den. Det egentlige spørsmålet er om flåten din trenger en generell VPN før en Mac eller iPad i det hele tatt kan administreres, og for de fleste internettadministrerte utrullinger er svaret nei. Apple lar enheten nå en administrasjonstjeneste etter eget tidskjema, og trafikken som betyr noe er en signert kommandokanal, ikke en skrivebordsøkt. Om dette virker hos deg avhenger av tre betingelser, og de er lette å forveksle fordi de utenfra alle ser ut som fjern tilgang.

Navngi behovet før du velger en transport

Administrasjonskommandoer og konfigurasjonsprofiler er ett behov, interaktiv skjermdeling er et andre, og å nå en privat intern applikasjon er et tredje. Disse har ulike eiere, ulik autentisering og ofte svært ulik akseptabel eksponering. Å slå dem sammen er måten en flåte ender opp med en offentlig portliste som ingen kan forsvare.

De tre behovene deler ikke én transport:

Forvirringen starter vanligvis med en gammel sjekkliste for serveren. Et historisk OS X Server-dokument lister et langt sett porter, og noen videresender alle sammen ved kanten fordi administrasjonstjenesten ligger der inne et sted. Dette er ikke en administrasjonsarkitektur, og det utvider den eksponerte flaten langt utover kontrollplanet du prøvde å publisere.

Hva push-varslingen faktisk gjør

I Apples dokumenterte flyt sender administrasjonsserveren et APNs-varsel for å fortelle enheten at arbeid venter. Enheten åpner deretter en tilkobling til administrasjonsserveren og ber om kommandoene sine. Pushet er en dørklokke, ikke en tunnel: det bærer ingen vilkårlig nyttelast, ingen ekstern skrivebordsøkt og ingen annen apps trafikk.

Enheten må altså være registrert hos den tiltenkte tjenesten, stole på de forventede endepunktene og kunne nå både administrasjonstjenesten og Apple-tjenestene flyten er avhengig av. Apples veiledning for nettverksforberedelse lister disse avhengighetene, og de er ikke forhandlingsbare deler av flyten. En administrasjonsserver som bare finnes inne i nettverket ditt trenger fortsatt en støttet vei som enheten faktisk kan bruke. Å kalle det MDM gjør ikke et uoppnåelig endepunkt oppnåelig.

Hold de tillatte veiene eksplisitte, inkludert enhver proxy- og TLS-inspeksjonspolicy i midten. Et inspeksjonsapparat som bryter den forventede sertifikatkjeden vil se nøyaktig ut som en brutt registrering.

Når VPN-en er det gale svaret

Hvis administrasjonstjenesten din er publisert på internett med et riktig sertifikat og enheten starter hver tilkobling, legger en VPN til et hopp uten å legge til en kontroll. Enheten autentiserer seg allerede med registreringsidentiteten sin, og serveren bestemmer allerede hvilke kommandoer den vil godta. En tunnel foran det endrer nettverksveien, ikke tillitsbeslutningen.

Det samme kontrollplanet kan også levere selve VPN-profilen. Den rekkefølgen betyr noe: en administrert VPN-konfigurasjon ankommer som bare enda en nyttelast, så enheten trenger ikke at tunnelen finnes før den kan motta profilen som oppretter den.

Når VPN-en er det riktige svaret

Det finnes flåter der administrasjonsendepunktet aldri bør være tilgjengelig fra internett, og det er et legitimt design, ikke mangel på mot. Regulerte miljøer, små interne IT-team og servere som også hoster andre administrative grensesnitt havner ofte der. I så fall er en beskyttet tilgangsvei foran administrasjonstjenesten bevisst arkitektur, ikke en nødløsning.

Skjermdeling og tilgang til private apper hører vanligvis også til på den siden av linjen. Begge avslører langt mer enn en kommandokanal, og begge fortjener sin egen autentisering i stedet for å ri på registreringsidentiteten.

Bootstrap-fellen som ødelegger gjenoppretting

Her er feilen jeg ville designet mot: den eneste veien til administrasjonstjenesten går gjennom en VPN, og VPN-profilen eller legitimasjonen på enheten er utløpt. Enheten kan ikke nå serveren for å hente en erstatningskommando, og serveren kan ikke skyve noe gjennom en tunnel som ikke kommer opp. Gjenoppretting avhenger nå av en bruker som kan være hundrevis av mil unna.

Hold en andre, uavhengig vei for gjenoppretting, enten det er en administrasjonskanal utenfor båndet, en lokal administrator eller en administrasjonstjeneste som forblir tilgjengelig uten tunnelen. Test den mens alt virker, for du får ikke en ren test under en hendelse.

Skriv deretter ned hvilke av de tre behovene hver vei tjener, og fjern portvideresendingene som ikke tjener noen av dem. En flåte som kan administreres uten en generell tunnel, og som fortsatt kan repareres når tunnelen er det som gikk i stykker, er resultatet det er verdt å designe for.