Ju duhet një VPN për Apple MDM? Tri nevoja aksesi, një përgjigje
Apple MDM punon mbi APNs dhe HTTPS të nisur nga pajisja, jo mbi një tunel LAN. Ndani menaxhimin, ndarjen e ekranit dhe aksesin në aplikacione private përpara se të shtoni një VPN.
Pyetja rrallë është nëse menaxhimi i pajisjeve Apple ka nevojë për kriptim, sepse ka. Pyetja e vërtetë është nëse flota juaj ka nevojë për një VPN të përgjithshme përpara se një Mac ose iPad të mund të menaxhohet fare, dhe për shumicën e vendosjeve të menaxhuara përmes internetit përgjigjja është jo. Apple lejon që pajisja të arrijë një shërbim menaxhimi sipas orarit të vet, dhe trafiku që ka rëndësi është një kanal komandash i nënshkruar, jo një sesion desktopi. Nëse kjo funksionon për ju varet nga tri kushte, dhe ato janë të lehta për t'u ngatërruar, sepse nga jashtë të gjitha duken si akses në distancë.
Emërtoni nevojën përpara se të zgjidhni një transport
Komandat e menaxhimit dhe profilet e konfigurimit janë një nevojë, ndarja interaktive e ekranit është e dyta, dhe arritja e një aplikacioni privat të brendshëm është e treta. Ato kanë pronarë të ndryshëm, vërtetim të ndryshëm dhe shpesh ekspozim të pranueshëm shumë të ndryshëm. Grumbullimi i tyre së bashku është mënyra se si një flotë përfundon me një listë publike portash që askush nuk mund ta mbrojë.
Tri nevojat nuk ndajnë një 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 |
Konfuzioni zakonisht fillon me një listë të vjetër kontrolli të serverit. Një dokument historik për OS X Server rendit një grup të gjatë portash, dhe dikush i përcjell të gjitha në skaj, sepse shërbimi i menaxhimit është diku aty brenda. Kjo nuk është arkitekturë menaxhimi, dhe zgjeron sipërfaqen e ekspozuar shumë përtej planit të kontrollit që po përpiqeshit të publikoni.
Çfarë bën në të vërtetë njoftimi push
Në rrjedhën e dokumentuar të Apple, serveri i menaxhimit dërgon një njoftim APNs për t'i thënë pajisjes se po pret punë. Pajisja më pas hap një lidhje me serverin e menaxhimit dhe kërkon komandat e saj. Push është një zile dere, jo një tunel: nuk mbart asnjë ngarkesë arbitrare, asnjë sesion desktopi në distancë dhe asnjë trafik të një aplikacioni tjetër.
Prandaj pajisja duhet të jetë e regjistruar në shërbimin e synuar, të besojë pikat e pritura fundore dhe të mund të arrijë si shërbimin e menaxhimit, ashtu edhe shërbimet Apple nga të cilat varet rrjedha. Udhëzuesi i Apple për përgatitjen e rrjetit rendit ato varësi, dhe ato nuk janë pjesë të negociueshme të rrjedhës. Një server menaxhimi që ekziston vetëm brenda rrjetit tuaj vazhdon të ketë nevojë për një rrugë të mbështetur që pajisja vërtet mund të përdorë. Ta quash MDM nuk e bën të arritshme një pikë fundore të paarritshme.
Mbajini rrugët e lejuara të qarta, përfshirë çdo politikë proxy dhe inspektimi TLS në mes. Një pajisje inspektimi që thyen zinxhirin e pritur të certifikatave do të duket saktësisht si një regjistrim i thyer.
Kur VPN është përgjigjja e gabuar
Nëse shërbimi juaj i menaxhimit është publikuar në internet me një certifikatë të rregullt dhe pajisja nis çdo lidhje, një VPN shton një kërcim pa shtuar një kontroll. Pajisja vërtetohet tashmë me identitetin e saj të regjistrimit, dhe serveri tashmë vendos cilat komanda do të pranojë. Një tunel përpara kësaj ndryshon rrugën e rrjetit, jo vendimin e besimit.
I njëjti plan kontrolli mund të dorëzojë edhe vetë profilin VPN. Ky rend ka rëndësi: një konfigurim VPN i menaxhuar vjen thjesht si një ngarkesë tjetër, prandaj pajisja nuk ka nevojë që tuneli të ekzistojë përpara se të marrë profilin që e krijon atë.
Kur VPN është përgjigjja e duhur
Ka flota ku pika fundore e menaxhimit nuk duhet të jetë kurrë e arritshme nga interneti, dhe ky është një dizajn legjitim, jo mungesë guximi. Ambientet e rregulluara, ekipet e vogla të IT-së të brendshme dhe serverat që strehojnë edhe ndërfaqe të tjera administrative shpesh përfundojnë atje. Në atë rast, një rrugë aksesi e mbrojtur përpara shërbimit të menaxhimit është arkitekturë e qëllimshme, jo një zgjidhje e përkohshme.
Ndarja e ekranit dhe aksesi në aplikacione private zakonisht i përkasin gjithashtu asaj ane të vijës. Të dyja ekspozojnë shumë më tepër se një kanal komandash, dhe të dyja meritojnë vërtetimin e tyre në vend që të hipin mbi identitetin e regjistrimit.
Kurthi i nisjes që thyen rikuperimin
Këtu është dështimi kundër të cilit do të dizajnoja: e vetmja rrugë drejt shërbimit të menaxhimit kalon përmes një VPN, dhe profili ose kredenciali VPN në pajisje ka skaduar. Pajisja nuk mund të arrijë serverin për të marrë një komandë zëvendësuese, dhe serveri nuk mund të shtyjë asgjë përmes një tuneli që nuk do të ngrihet. Rikuperimi tani varet nga një përdorues që mund të jetë qindra milje larg.
Mbani një rrugë të dytë, të pavarur për rikuperim, qoftë një kanal menaxhimi jashtë brezit, një administrator lokal ose një shërbim menaxhimi që mbetet i arritshëm pa tunel. Testojeni ndërsa gjithçka funksionon, sepse gjatë një incidenti nuk do të merrni një provë të pastër.
Më pas shkruani cilën nga tri nevojat shërben secila rrugë, dhe hiqni përcjelljet e portave që nuk shërbejnë asnjërën prej tyre. Një flotë që mund të menaxhohet pa një tunel të përgjithshëm, dhe që mund të riparohet ende kur tuneli është ai që u prish, është rezultati për të cilin ia vlen të dizajnohet.