Ĉu vi bezonas VPN por Apple MDM? Tri alirbezonoj, unu respondo
Apple MDM funkcias sur APNs kaj HTTPS iniciatita de la aparato, ne sur loka reta tunelo. Apartigu administradon, ekranan kundividon kaj aliron al privataj aplikaĵoj antaŭ ol aldoni VPN.
La demando malofte estas ĉu administrado de Apple-aparatoj bezonas ĉifradon, ĉar ĝi bezonas. La vera demando estas ĉu via aparataro bezonas ĝeneraluzan VPN antaŭ ol Mac aŭ iPad entute povas esti administrata, kaj por plej multaj interret-administrataj enkondukoj la respondo estas ne. Apple permesas al la aparato atingi administran servon laŭ sia propra horaro, kaj la trafiko, kiu gravas, estas subskribita komanda kanalo, ne labortabla sesio. Ĉu tio funkcias por vi dependas de tri kondiĉoj, kaj ili facile konfuziĝas, ĉar de ekstere ili ĉiuj aspektas kiel fora aliro.
Nomu la bezonon antaŭ ol elekti transporton
Administraj komandoj kaj agordaj profiloj estas unu bezono, interaga ekrana kundivido estas dua, kaj atingi privatan internan aplikaĵon estas tria. Ili havas malsamajn posedantojn, malsaman aŭtentikigon kaj ofte tre malsaman akcepteblan eksponiĝon. Kunigi ilin estas kiel aparataro finas kun publika havena listo, kiun neniu povas defendi.
La tri bezonoj ne dividas unu transporton:
| 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 |
La konfuzo kutime komenciĝas per malnova servila kontrol-listo. Historia dokumento pri OS X Server listigas longan aron da havenoj, kaj iu plusendas ĉiujn ĉe la rando ĉar la administra servo estas ie interne. Tio ne estas administra arkitekturo, kaj ĝi larĝigas la eksponitan surfacon multe preter la rega ebeno, kiun vi provis publikigi.
Kion la puŝa sciigo efektive faras
En la dokumentita fluo de Apple, la administra servilo sendas APNs-sciigon por diri al la aparato, ke laboro atendas. La aparato tiam malfermas konekton al la administra servilo kaj petas siajn komandojn. La puŝo estas pordosono, ne tunelo: ĝi portas neniun arbitran ŝarĝon, neniun foregan labortablan sesion, kaj neniun trafikon de alia aplikaĵo.
Do la aparato devas esti enskribita ĉe la celata servo, fidi la atendatajn finpunktojn kaj povi atingi kaj la administran servon kaj la Apple-servojn, de kiuj dependas la fluo. La gvidilo de Apple pri reta preparado listigas tiujn dependecojn, kaj ili ne estas negocieblaj partoj de la fluo. Administra servilo, kiu ekzistas nur ene de via reto, ankoraŭ bezonas subtenatan vojon, kiun la aparato povas efektive uzi. Nomante ĝin MDM oni ne faras atingebla neatingeblan finpunkton.
Tenu la permesitajn vojojn eksplicitaj, inkluzive de ajna prokura kaj TLS-inspekta politiko en la mezo. Inspekta aparato, kiu rompas la atendatan atestilan ĉenon, aspektos ĝuste kiel rompita enskribiĝo.
Kiam la VPN estas la malĝusta respondo
Se via administra servo estas publikigita en la interreto kun taŭga atestilo kaj la aparato iniciatas ĉiun konekton, VPN aldonas salton sen aldoni regadon. La aparato jam aŭtentikigas sin per sia enskribiĝa identeco, kaj la servilo jam decidas, kiujn komandojn ĝi akceptos. Tunelo antaŭ tio ŝanĝas la retan vojon, ne la fidan decidon.
La sama rega ebeno povas ankaŭ liveri la VPN-profilon mem. Tiu ordo gravas: administrata VPN-agordo alvenas kiel simple alia ŝarĝo, do la aparato ne bezonas, ke la tunelo ekzistu antaŭ ol ĝi ricevu la profilon, kiu ĝin kreas.
Kiam la VPN estas la ĝusta respondo
Estas aparataroj, kie la administra finpunkto neniam devus esti atingebla el la interreto, kaj tio estas legitima dezajno, ne manko de kuraĝo. Reguligitaj medioj, malgrandaj internaj IT-teamoj kaj serviloj, kiuj ankaŭ gastigas aliajn administrajn interfacojn, ofte finas tie. En tiu kazo protektita alirvojo antaŭ la administra servo estas intenca arkitekturo, ne provizora solvo.
Ekrana kundivido kaj aliro al privataj aplikaĵoj kutime ankaŭ apartenas al tiu flanko de la linio. Ambaŭ malkaŝas multe pli ol komanda kanalo, kaj ambaŭ meritas propran aŭtentikigon anstataŭ veturi sur la enskribiĝa identeco.
La praŝarga kaptilo, kiu rompas reakiron
Jen la paneo, kontraŭ kiu mi dezajnus: la sola vojo al la administra servo iras tra VPN, kaj la VPN-profilon aŭ legitimilon sur la aparato eksvalidiĝis. La aparato ne povas atingi la servilon por kolekti anstataŭan komandon, kaj la servilo ne povas puŝi ion tra tunelo, kiu ne leviĝos. Reakiro nun dependas de uzanto, kiu povas esti centojn da mejloj for.
Tenu duan, sendependan vojon por reakiro, ĉu eksterbenda administra kanalo, ĉu loka administranto, ĉu administra servo, kiu restas atingebla sen la tunelo. Testu ĝin dum ĉio funkcias, ĉar vi ne ricevos puran teston dum okazaĵo.
Poste skribu, kiun el la tri bezonoj ĉiu vojo servas, kaj forigu la havenajn plusendojn, kiuj servas neniun el ili. Aparataro, kiu povas esti administrata sen ĝenerala tunelo kaj ankoraŭ riparebla, kiam la tunelo estas tio, kio rompiĝis, estas la rezulto, por kiu indas dezajni.