Kas vajate Apple MDM-i jaoks VPN-i? Kolm juurdepääsuvajadust, üks vastus
Apple MDM töötab APNs-il ja seadme algatatud HTTPS-il, mitte LAN-tunnelil. Eraldage haldus, ekraanijagamine ja privaatsete rakenduste juurdepääs enne VPN-i lisamist.
Küsimus on harva selles, kas Apple'i seadmete haldus vajab krüpteerimist, sest vajab küll. Tegelik küsimus on, kas teie seadmepark vajab üldotstarbelist VPN-i enne, kui Maci või iPad'i saab üldse hallata, ja enamiku interneti kaudu hallatavate juurutuste puhul on vastus ei. Apple lubab seadmel jõuda haldusteenuseni oma ajakava järgi, ja oluline liiklus on allkirjastatud käsukanal, mitte töölaua sessioon. Kas see teie juures töötab, sõltub kolmest tingimusest, ja neid on lihtne segi ajada, sest väljast vaadates näevad need kõik välja nagu kaugjuurdepääs.
Nimetage vajadus enne, kui valite transpordi
Halduskäsud ja konfiguratsiooniprofiilid on üks vajadus, interaktiivne ekraanijagamine teine ja juurdepääs privaatsele sisemisele rakendusele kolmas. Neil on erinevad omanikud, erinev autentimine ja sageli väga erinev vastuvõetav avatus. Nende ühte patta panemine on viis, kuidas seadmepark jõuab avaliku portide loeteluni, mida keegi ei suuda kaitsta.
Kolm vajadust ei jaga ühte transporti:
| 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 |
Segadus algab tavaliselt vanast serveri kontroll-loendist. Ajalooline OS X Serveri dokument loetleb pika portide komplekti ja keegi suunab need kõik servas edasi, sest haldusteenus on kuskil seal sees. See ei ole haldusarhitektuur ja see laiendab avatud pinda palju kaugemale juhtimistasandist, mida te avaldada püüdsite.
Mida tõuketeatis tegelikult teeb
Apple'i dokumenteeritud voos saadab haldusserver APNs-teate, et öelda seadmele, et töö ootab. Seejärel avab seade ühenduse haldusserveriga ja küsib oma käsud. Tõuge on uksekell, mitte tunnel: see ei kanna suvalist kandevõimet, ühtegi kaugtöölaua sessiooni ega mõne teise rakenduse liiklust.
Seega peab seade olema kavandatud teenusesse registreeritud, usaldama oodatud lõpp-punkte ja suutma jõuda nii haldusteenuseni kui ka Apple'i teenusteni, millest voog sõltub. Apple'i võrgu ettevalmistamise juhend loetleb need sõltuvused ja need ei ole voo läbiräägitavad osad. Haldusserver, mis eksisteerib ainult teie võrgu sees, vajab ikka toetatud teed, mida seade saab tegelikult kasutada. Selle MDM-iks nimetamine ei tee kättesaamatut lõpp-punkti kättesaadavaks.
Hoidke lubatud teed selged, sealhulgas kõik puhverserveri ja TLS-i kontrollimise poliitika, mis on vahepeal. Kontrollseade, mis rikub oodatud sertifikaadiahela, näeb väljast täpselt välja nagu katkine registreerimine.
Kui VPN on vale vastus
Kui teie haldusteenus on avaldatud internetis korrektse sertifikaadiga ja seade algatab iga ühenduse, lisab VPN ühe hüppe ilma kontrolli lisamata. Seade autendib end juba oma registreerimisidentiteediga ja server otsustab juba, milliseid käske ta vastu võtab. Tunnel selle ees muudab võrguteed, mitte usaldusotsust.
Sama juhtimistasand võib edastada ka VPN-profiili enda. See järjekord on oluline: hallatav VPN-konfiguratsioon saabub lihtsalt veel ühe kandevõimena, nii et seade ei vaja tunnelit enne, kui ta saab profiili, mis selle loob.
Kui VPN on õige vastus
On seadmeparke, kus halduse lõpp-punkt ei tohiks kunagi olla internetist kättesaadav, ja see on legitiimne disain, mitte julguse puudumine. Reguleeritud keskkonnad, väikesed sisemised IT-meeskonnad ja serverid, mis majutavad ka muid haldusliideseid, jõuavad sageli sinna. Sel juhul on kaitstud juurdepääsutee haldusteenuse ees teadlik arhitektuur, mitte möödasõit.
Ekraanijagamine ja privaatsete rakenduste juurdepääs kuuluvad tavaliselt samuti joone sellele küljele. Mõlemad avavad palju enamat kui käsukanal ja mõlemad väärivad oma autentimist, selle asemel et sõita registreerimisidentiteedi peal.
Alglaadimise lõks, mis rikub taastamise
Siin on tõrge, mille vastu ma disainiksin: ainus tee haldusteenuseni kulgeb läbi VPN-i ja seadmes olev VPN-profiil või mandaat on aegunud. Seade ei saa serverini jõuda, et hankida asenduskäsk, ja server ei saa mitte midagi läbi lükata tunnelist, mis ei tõuse. Taastamine sõltub nüüd kasutajast, kes võib olla sadade kilomeetrite kaugusel.
Hoidke teist, sõltumatut teed taastamiseks, olgu selleks välisriba halduskanal, kohalik administraator või haldusteenus, mis jääb kättesaadavaks ilma tunnelita. Testige seda siis, kui kõik töötab, sest intsidendi ajal te puhast testi ei saa.
Seejärel kirjutage üles, millist kolmest vajadusest iga tee teenib, ja eemaldage portide edasisuunamised, mis ei teeni ühtegi neist. Seadmepark, mida saab hallata ilma üldise tunnelita ja mida saab siiski parandada, kui tunnel on see, mis katki läks, on tulemus, mille nimel tasub disainida.