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, deljenje ekrana i pristup privatnim aplikacijama pre nego što dodate VPN.
Pitanje retko glasi treba li upravljanju Apple uređajima enkripcija, jer treba. Pravo pitanje je treba li vašoj floti VPN opšte namene pre nego što se Mac ili iPad uopšte može upravljati, a za većinu postavki kojima se upravlja preko interneta odgovor je ne. Apple dozvoljava uređaju da dođe do servisa za upravljanje po sopstvenom rasporedu, a saobraćaj 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 uslova, i lako ih je zameniti jer spolja svi izgledaju kao daljinski pristup.
Imenujte potrebu pre nego što odaberete prenos
Naredbe za upravljanje i konfiguracioni profili jedna su potreba, interaktivno deljenje ekrana druga, a dosezanje privatne interne aplikacije treća. Imaju različite vlasnike, različitu autentifikaciju i često vrlo različitu prihvatljivu izloženost. Njihovo trpanje u istu hrpu način je na koji flota završi sa javnim spiskom portova koji niko ne može braniti.
Tri potrebe ne dele isti prenos:
| 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 spiskom servera. Istorijski dokument za OS X Server navodi dug spisak portova, i neko ih sve preusmeri na ivici jer je servis za upravljanje negde unutra. To nije arhitektura upravljanja i proširuje izloženu površinu daleko iznad kontrolne ravni koju ste pokušavali da objavite.
Šta push obaveštenje zapravo radi
U Appleovom dokumentovanom toku server za upravljanje šalje APNs obaveštenje da kaže uređaju kako ga čeka posao. Uređaj zatim otvara vezu prema serveru 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 saobraćaj neke druge aplikacije.
Zato uređaj mora biti upisan u predviđeni servis, verovati očekivanim krajnjim tačkama i moći dosegnuti i servis za upravljanje i Appleove servise od kojih tok zavisi. Appleove smernice za pripremu mreže navode te zavisnosti i one nisu pregovarački delovi toka. Server za upravljanje koji postoji samo unutar vaše mreže i dalje treba podržan put koji uređaj zaista može koristiti. Nazvati to MDM-om ne čini nedostupnu krajnju tačku dostupnom.
Držite dozvoljene puteve izričitim, uključujući bilo koju politiku proxyja i TLS inspekcije u sredini. Uređaj za inspekciju koji prekida očekivani lanac sertifikata izgledaće tačno kao pokvarena registracija.
Kada je VPN pogrešan odgovor
Ako je vaš servis za upravljanje objavljen na internetu sa ispravnim sertifikatom i uređaj pokreće svaku vezu, VPN dodaje skok bez dodavanja kontrole. Uređaj se već autentifikuje svojim identitetom upisa, a server već odlučuje koje će naredbe prihvatiti. Tunel ispred toga menja mrežni put, a ne odluku o poverenju.
Ista kontrolna ravan može isporučiti i sam VPN profil. Taj je redosled 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 tačka upravljanja nikada ne bi smela biti dostupna sa interneta, i to je legitiman dizajn, a ne manjak smelosti. Regulisana okruženja, mali interni IT timovi i serveri koji ujedno hostuju druga administrativna sučelja često tamo završe. U tom je slučaju zaštićeni put pristupa ispred servisa za upravljanje namerna arhitektura, a ne zaobilazno rešenje.
Deljenje ekrana i pristup privatnim aplikacijama obično takođe pripadaju na tu stranu linije. Oba otkrivaju mnogo više od kanala naredbi i oba zaslužuju sopstvenu autentifikaciju umesto da se voze na identitetu upisa.
Zamka pri podizanju koja lomi oporavak
Evo kvara protiv kojeg bih projektovao: 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 servera da preuzme zamensku naredbu, a server ne može progurati ništa kroz tunel koji se neće podići. Oporavak sada zavisi od korisnika koji je možda stotinama milja daleko.
Držite drugi, nezavisni put za oporavak, bilo da je to vanpojasni kanal upravljanja, lokalni administrator ili servis za upravljanje koji ostaje dostupan bez tunela. Testirajte ga dok sve radi, jer tokom incidenta nećete dobiti čist test.
Zatim zapišite kojoj od tri potrebe služi koji put i uklonite preusmeravanja portova koja ne služe nijednoj od njih. Flota kojom se može upravljati bez opšteg tunela i koja se još može popraviti kad je tunel ono što se pokvarilo jest ishod za koji vredi projektovati.