Treng du ein VPN for Apple MDM? Tre tilgangsbehov, eitt svar
Apple MDM går på APNs og HTTPS som eininga sjølv startar, ikkje på ein LAN-tunnel. Skil administrasjon, skjermdeling og tilgang til private appar før du legg til ein VPN.
Spørsmålet er sjeldan om Apple-einingsadministrasjon treng kryptering, for det gjer han. Det eigentlege spørsmålet er om flåten din treng ein generell VPN før ein Mac eller iPad i det heile kan administrerast, og for dei fleste internettadministrerte utrullingane er svaret nei. Apple lèt eininga nå ein administrasjonsteneste etter sin eigen tidsplan, og trafikken som tel er ein signert kommandokanal, ikkje ei skrivebordsøkt. Om det verkar for deg avheng av tre vilkår, og dei er lette å forveksle fordi dei utanfrå alle ser ut som fjern tilgang.
Namngi behovet før du vel ein transport
Administrasjonskommandoar og konfigurasjonsprofilar er eitt behov, interaktiv skjermdeling er eit andre, og å nå ein privat intern applikasjon er eit tredje. Dei har ulike eigarar, ulik autentisering og ofte svært ulik akseptabel eksponering. Å slå dei saman er måten ein flåte endar opp med ei offentleg portliste som ingen kan forsvare.
Dei tre behova deler ikkje éin transport:
| Need | What actually carries it |
|---|---|
| Management commands and profiles | The enrolled device pulls from a service it can reach; APNs only wakes it |
| Interactive screen sharing | A remote-support tool or private desktop path with its own authentication |
| Private application access | That application's permitted network path, which may well be a VPN |
Forvirringa startar vanlegvis med ein gamal sjekkliste for tenaren. Eit historisk OS X Server-dokument listar eit langt sett portar, og nokon videresender alle saman ved kanten fordi administrasjonstenesta er der inne ein stad. Det er ikkje ein administrasjonsarkitektur, og det utvidar den eksponerte flata langt utover kontrollplanet du prøvde å publisere.
Kva push-varslinga faktisk gjer
I den dokumenterte flyten til Apple sender administrasjonstenaren eit APNs-varsel for å fortelje eininga at arbeid ventar. Eininga opnar deretter ei tilkopling til administrasjonstenaren og ber om kommandoane sine. Pushet er ei dørklokke, ikkje ein tunnel: det ber ingen vilkårleg nyttelast, inga ekstern skrivebordsøkt og ingen annan app sin trafikk.
Eininga må altså vere registrert hos den tiltenkte tenesta, stole på dei forventa endepunkta og kunne nå både administrasjonstenesta og Apple-tenestene flyten er avhengig av. Rettleiinga til Apple for nettverksførebuing listar desse avhengigheitene, og dei er ikkje forhandlingsbare delar av flyten. Ein administrasjonstenar som berre finst inne i nettverket ditt treng framleis ein støtta veg som eininga faktisk kan bruke. Å kalle det MDM gjer ikkje eit uoppnåeleg endepunkt oppnåeleg.
Hald dei tillatne vegane eksplisitte, inkludert kva som helst proxy- og TLS-inspeksjonspolitikk i midten. Eit inspeksjonsapparat som bryt den forventa sertifikatkjeda vil sjå nøyaktig ut som ei broten registrering.
Når VPN-en er det gale svaret
Viss administrasjonstenesta di er publisert på internett med eit riktig sertifikat og eininga startar kvar tilkopling, legg ein VPN til eit hopp utan å leggje til ein kontroll. Eininga autentiserer seg allereie med registreringsidentiteten sin, og tenaren avgjer allereie kva kommandoar han vil godta. Ein tunnel framfor det endrar nettverksvegen, ikkje tillitsavgjerda.
Det same kontrollplanet kan òg levere sjølve VPN-profilen. Den rekkjefølgja betyr noko: ein administrert VPN-konfigurasjon kjem inn som berre endå ei nyttelast, så eininga treng ikkje at tunnelen finst før ho kan ta imot profilen som opprettar han.
Når VPN-en er det rette svaret
Det finst flåtar der administrasjonsendepunktet aldri bør vere tilgjengeleg frå internett, og det er eit legitimt design, ikkje mangel på mot. Regulerte miljø, små interne IT-team og tenarar som òg hostar andre administrative grensesnitt hamnar ofte der. I så fall er ein verna tilgangsveg framfor administrasjonstenesta medviten arkitektur, ikkje ei naudløysing.
Skjermdeling og tilgang til private appar høyrer vanlegvis òg til på den sida av linja. Begge avdekkjer langt meir enn ein kommandokanal, og begge fortener si eiga autentisering i staden for å ri på registreringsidentiteten.
Bootstrap-fella som øydelegg gjenoppretting
Her er feilen eg ville designe mot: den einaste vegen til administrasjonstenesta går gjennom ein VPN, og VPN-profilen eller legitimasjonen på eininga er gått ut. Eininga kan ikkje nå tenaren for å hente ein erstatningskommando, og tenaren kan ikkje skyve noko gjennom ein tunnel som ikkje kjem opp. Gjenoppretting avheng no av ein brukar som kan vere hundrevis av mil unna.
Hald ein andre, uavhengig veg for gjenoppretting, anten det er ein administrasjonskanal utanfor bandet, ein lokal administrator eller ein administrasjonsteneste som blir tilgjengeleg utan tunnelen. Test han medan alt verkar, for du får ikkje ein rein test under ei hending.
Skriv deretter ned kva av dei tre behova kvar veg tener, og fjern portvideresendingane som ikkje tener nokon av dei. Ein flåte som kan administrerast utan ein generell tunnel, og som framleis kan reparerast når tunnelen er det som gjekk i stykker, er resultatet det er verdt å designe for.