Trebate li VPN za Apple MDM? Tri potrebe za pristup, jedan odgovor
Apple MDM radi na APNs i HTTPS-u koji pokreće uređaj, a ne na LAN tunelu. Odvojite upravljanje, dijeljenje zaslona i pristup privatnim aplikacijama prije nego dodate VPN.
Pitanje rijetko glasi treba li upravljanju Apple uređajima enkripcija, jer treba. Pravo je pitanje treba li vašoj floti VPN opće namjene prije nego što se Mac ili iPad uopće može upravljati, a za većinu postava kojima se upravlja preko interneta odgovor je ne. Apple dopušta uređaju da dođe do servisa za upravljanje po vlastitom rasporedu, a promet koji je važan je potpisan kanal naredbi, a ne sesija radne površine. Hoće li to raditi kod vas svodi se na tri uvjeta, i lako ih je zamijeniti jer izvana svi izgledaju kao daljinski pristup.
Imenujte potrebu prije nego odaberete prijenos
Naredbe za upravljanje i konfiguracijski profili jedna su potreba, interaktivno dijeljenje zaslona druga, a dosezanje privatne interne aplikacije treća. Imaju različite vlasnike, različitu autentifikaciju i često vrlo različitu prihvatljivu izloženost. Njihovo strpavanje u istu hrpu način je na koji flota završi s javnim popisom portova koji nitko ne može braniti.
Tri potrebe ne dijele isti prijenos:
| 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 |
Zbrka obično počinje sa starim kontrolnim popisom poslužitelja. Povijesni dokument za OS X Server navodi dug popis portova, i netko ih sve preusmjeri na rubu jer je servis za upravljanje negdje unutra. To nije arhitektura upravljanja i proširuje izloženu površinu daleko iznad kontrolne ravnine koju ste pokušavali objaviti.
Što push obavijest zapravo radi
U Appleovu dokumentiranom toku poslužitelj za upravljanje šalje APNs obavijest da kaže uređaju kako ga čeka posao. Uređaj zatim otvara vezu prema poslužitelju za upravljanje i traži svoje naredbe. Push je zvono na vratima, a ne tunel: ne nosi proizvoljan teret, ni sesiju udaljene radne površine, ni promet neke druge aplikacije.
Zato uređaj mora biti upisan u predviđeni servis, vjerovati očekivanim krajnjim točkama i moći dosegnuti i servis za upravljanje i Appleove servise o kojima tok ovisi. Appleove smjernice za pripremu mreže navode te ovisnosti i one nisu pregovarački dijelovi toka. Poslužitelj za upravljanje koji postoji samo unutar vaše mreže i dalje treba podržan put koji uređaj doista može koristiti. Nazvati to MDM-om ne čini nedostupnu krajnju točku dostupnom.
Držite dopuštene putove izričitima, uključujući bilo koju politiku proxyja i TLS inspekcije u sredini. Uređaj za inspekciju koji prekida očekivani lanac certifikata izgledat će točno kao pokvarena registracija.
Kada je VPN pogrešan odgovor
Ako je vaš servis za upravljanje objavljen na internetu s ispravnim certifikatom i uređaj pokreće svaku vezu, VPN dodaje skok bez dodavanja kontrole. Uređaj se već autentificira svojim identitetom upisa, a poslužitelj već odlučuje koje će naredbe prihvatiti. Tunel ispred toga mijenja mrežni put, a ne odluku o povjerenju.
Ista kontrolna ravnina može isporučiti i sam VPN profil. Taj je redoslijed važan: upravljana VPN konfiguracija stiže kao još jedan teret, pa uređaju ne treba postojeći tunel da bi primio profil koji ga stvara.
Kada je VPN pravi odgovor
Postoje flote u kojima krajnja točka upravljanja nikada ne bi smjela biti dostupna s interneta, i to je legitiman dizajn, a ne manjak smjelosti. Regulirana okruženja, mali interni IT timovi i poslužitelji koji ujedno hostaju druga administrativna sučelja često tamo završe. U tom je slučaju zaštićeni put pristupa ispred servisa za upravljanje namjerna arhitektura, a ne zaobilazno rješenje.
Dijeljenje zaslona i pristup privatnim aplikacijama obično također pripadaju na tu stranu crte. Oba otkrivaju mnogo više od kanala naredbi i oba zaslužuju vlastitu autentifikaciju umjesto da se voze na identitetu upisa.
Zamka pri pokretanju koja lomi oporavak
Evo kvara protiv kojeg bih projektirao: jedini put do servisa za upravljanje ide kroz VPN, a VPN profil ili akreditiv na uređaju je istekao. Uređaj ne može doći do poslužitelja da preuzme zamjensku naredbu, a poslužitelj ne može progurati ništa kroz tunel koji se neće podići. Oporavak sada ovisi o korisniku koji je možda stotinama milja daleko.
Držite drugi, neovisni put za oporavak, bilo da je to izvanpojasni kanal upravljanja, lokalni administrator ili servis za upravljanje koji ostaje dostupan bez tunela. Testirajte ga dok sve radi, jer tijekom incidenta nećete dobiti čist test.
Zatim zapišite kojoj od tri potrebe služi koji put i uklonite preusmjeravanja portova koja ne služe nijednoj od njih. Flota kojom se može upravljati bez općeg tunela i koja se još može popraviti kad je tunel ono što se pokvarilo jest ishod za koji vrijedi projektirati.