VPN bat behar duzu Apple MDM-rako? Hiru sarbide-behar, erantzun bakarra
Apple MDM APNs eta gailuak abiarazitako HTTPS bidez funtzionatzen du, ez LAN tunelez. Bereizi kudeaketa, pantaila partekatzea eta aplikazio pribatuetarako sarbidea VPN bat gehitu aurretik.
Galdera gutxitan da ea Apple gailuen kudeaketak zifratzea behar duen, bai baita. Benetako galdera da ea zure flotak VPN orokor bat behar duen Mac edo iPad bat kudeatu ahal izateko, eta internet bidez kudeatutako ezarpen gehienetan erantzuna ez da. Apple-k gailuari kudeaketa zerbitzu batera iristeko aukera ematen dio bere egutegiaren arabera, eta garrantzitsua den trafikoa sinatutako komando kanal bat da, ez mahaigaineko saio bat. Horrek zuretzat funtzionatzen duen hiru baldintzaren araberakoa da, eta erraz nahasten dira, kanpotik denek urruneko sarbidea diruditelako.
Izena eman beharrari garraioa aukeratu aurretik
Kudeaketa komandoak eta konfigurazio profilak behar bat dira, pantaila partekatze interaktiboa bigarrena da, eta barne aplikazio pribatu batera iristea hirugarrena. Jabe desberdinak dituzte, autentifikazio desberdina, eta askotan esposizio onargarri oso desberdina. Hauek elkarrekin nahastea da flota bat inork defenda dezakeen portu zerrenda publiko batekin amaitzeko modua.
Hiru beharrek ez dute garraio bera partekatzen:
| 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 |
Nahasmendua normalean zerbitzariaren kontrol zerrenda zahar batekin hasten da. OS X Server-en dokumentu historiko batek portu multzo luze bat zerrendatzen du, eta norbaitek guztiak ertzean birbidaltzen ditu kudeaketa zerbitzua han nonbait dagoelako. Hori ez da kudeaketa arkitektura bat, eta agerian dagoen azalera argitaratzen saiatzen ari zinen kontrol planoaz harago zabaltzen du.
Zer egiten du push jakinarazpenak benetan
Apple-k dokumentatutako fluxuan, kudeaketa zerbitzariak APNs jakinarazpen bat bidaltzen du gailuari lana itxaroten dagoela esateko. Ondoren gailuak konexio bat irekitzen du kudeaketa zerbitzariarekin eta bere komandoak eskatzen ditu. Push-a ate-kanpaia da, ez tunel bat: ez du karga arbitrariorik eramaten, ez urruneko mahaigain saiorik, ez beste aplikazio baten trafikorik.
Beraz, gailuak aurreikusitako zerbitzuan erregistratuta egon behar du, espero diren muturretan fidatu, eta kudeaketa zerbitzura eta fluxu horrek behar dituen Apple zerbitzuetara iritsi behar du. Apple-ren sare prestakuntzako gida mendekotasun horiek zerrendatzen ditu, eta ez dira fluxuaren zati negoziagarriak. Zure sarearen barruan soilik dagoen kudeaketa zerbitzari batek gailuak benetan erabil dezakeen bide onartu bat behar du oraindik. MDM deitzeak ez du mutur eskuraezin bat eskuragarri egiten.
Mantendu baimendutako bideak argi, erdian dagoen proxy eta TLS ikuskapen politika edozein barne. Espero den ziurtagiri katea hausten duen ikuskapen gailu bat erregistro hautsia bezala ikusiko da.
VPN-a erantzun okerra denean
Zure kudeaketa zerbitzua interneten argitaratuta badago ziurtagiri egoki batekin eta gailuak konexio guztiak abiarazten baditu, VPN batek jauzi bat gehitzen du kontrol bat gehitu gabe. Gailua bere erregistro identitatearekin autentifikatzen da jada, eta zerbitzariak jada erabakitzen du zein komando onartuko dituen. Horren aurrean tunel batek sare bidea aldatzen du, ez konfiantza erabakia.
Kontrol plano berak VPN profila bera ere eman dezake. Ordena hori garrantzitsua da: kudeatutako VPN konfigurazioa karga bat gehiago bezala iristen da, beraz gailuak ez du tunela existitu beharrik sortzen duen profila jaso aurretik.
VPN-a erantzun zuzena denean
Badaude flotak non kudeaketa muturra ez litzatekeen inoiz internetetik eskuragarri izan behar, eta hori diseinu legitimo bat da, ez ausardi falta. Ingurune arautuetan, barneko IT talde txikietan eta beste administrazio interfaze batzuk ere ostatatzen dituzten zerbitzarietan askotan hori gertatzen da. Kasu horretan kudeaketa zerbitzuaren aurrean sarbide bide babestu bat arkitektura deliberatua da, ez behin-behineko konponbidea.
Pantaila partekatzea eta aplikazio pribatuetarako sarbidea normalean marraren alde horretan ere bai. Biek komando kanal bat baino askoz gehiago agertzen dute, eta biek merezi dute beren autentifikazioa erregistro identitatearen gainean ibili beharrean.
Berreskuratzea hausten duen abiarazte tranpa
Hona hemen diseinatuko nukeen hutsa: kudeaketa zerbitzurako bide bakarra VPN batetik doa, eta gailuan dagoen VPN profila edo kredentziala iraungi da. Gailuak ezin dio zerbitzariari ordezko komando bat jasotzeko iritsi, eta zerbitzariak ezin du ezer bultzatu altxatuko ez den tunel batetik. Berreskuratzea orain ehunka kilometrora egon daitekeen erabiltzaile baten mende dago.
Mantendu bigarren bide independente bat berreskuratzeko, dela banda kanpoko kudeaketa kanal bat, dela administrari lokal bat, dela tunelik gabe eskuragarri jarraitzen duen kudeaketa zerbitzu bat. Probatu ezazu dena funtzionatzen ari denean, istripu batean ez baituzu proba garbirik izango.
Gero idatzi bide bakoitzak hiru beharretatik zeini egiten dion zerbitzu, eta kendu horietako ezeini zerbitzatzen ez dioten portu birbidaltzeak. Tunel orokorrik gabe kudea daitekeen eta tunela hautsi zena denean konpondu ahal izango den flota bat da diseinatzen merezi duen emaitza.