Да ли вам треба VPN за Apple MDM? Три потребе приступа, један одговор
Apple MDM ради на APNs и HTTPS-у који покреће уређај, а не на LAN тунелу. Одвојте управљање, дељење екрана и приступ приватним апликацијама пре него што додате VPN.
Питање ретко гласи треба ли управљању Apple уређајима енкрипција, јер треба. Право питање је треба ли вашој флоти VPN опште намене пре него што се Mac или iPad уопште може управљати, а за већину поставки којима се управља преко интернета одговор је не. Apple дозвољава уређају да дође до сервиса за управљање по сопственом распореду, а саобраћај који је важан је потписан канал наредби, а не сесија радне површине. Хоће ли то радити код вас своди се на три услова, и лако их је заменити јер споља сви изгледају као даљински приступ.
Именујте потребу пре него што одаберете пренос
Наредбе за управљање и конфигурациони профили једна су потреба, интерактивно дељење екрана друга, а досезање приватне интерне апликације трећа. Имају различите власнике, различиту аутентификацију и често врло различиту прихватљиву изложеност. Њихово трпање у исту хрпу начин је на који флота заврши са јавним списком портова који нико не може бранити.
Три потребе не деле исти пренос:
| 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 |
Збрка обично почиње са старим контролним списком сервера. Историјски документ за OS X Server наводи дуг списак портова, и неко их све преусмери на ивици јер је сервис за управљање негде унутра. То није архитектура управљања и проширује изложену површину далеко изнад контролне равни коју сте покушавали да објавите.
Шта push обавештење заправо ради
У Appleовом документованом току сервер за управљање шаље APNs обавештење да каже уређају како га чека посао. Уређај затим отвара везу према серверу за управљање и тражи своје наредбе. Push је звоно на вратима, а не тунел: не носи произвољан терет, ни сесију удаљене радне површине, ни саобраћај неке друге апликације.
Зато уређај мора бити уписан у предвиђени сервис, веровати очекиваним крајњим тачкама и моћи досегнути и сервис за управљање и Appleове сервисе од којих ток зависи. Appleове смернице за припрему мреже наводе те зависности и оне нису преговарачки делови тока. Сервер за управљање који постоји само унутар ваше мреже и даље треба подржан пут који уређај заиста може користити. Назвати то MDM-ом не чини недоступну крајњу тачку доступном.
Држите дозвољене путеве изричитим, укључујући било коју политику проксија и TLS инспекције у средини. Уређај за инспекцију који прекида очекивани ланац сертификата изгледаће тачно као покварена регистрација.
Када је VPN погрешан одговор
Ако је ваш сервис за управљање објављен на интернету са исправним сертификатом и уређај покреће сваку везу, VPN додаје скок без додавања контроле. Уређај се већ аутентификује својим идентитетом уписа, а сервер већ одлучује које ће наредбе прихватити. Тунел испред тога мења мрежни пут, а не одлуку о поверењу.
Иста контролна раван може испоручити и сам VPN профил. Тај је редослед важан: управљана VPN конфигурација стиже као још један терет, па уређају не треба постојећи тунел да би примио профил који га ствара.
Када је VPN прави одговор
Постоје флоте у којима крајња тачка управљања никада не би смела бити доступна са интернета, и то је легитиман дизајн, а не мањак смелости. Регулисана окружења, мали интерни ИТ тимови и сервери који уједно хостују друга административна сучеља често тамо заврше. У том је случају заштићени пут приступа испред сервиса за управљање намерна архитектура, а не заобилазно решење.
Дељење екрана и приступ приватним апликацијама обично такође припадају на ту страну линије. Оба откривају много више од канала наредби и оба заслужују сопствену аутентификацију уместо да се возе на идентитету уписа.
Замка при подизању која ломи опоравак
Ево квара против којег бих пројектовао: једини пут до сервиса за управљање иде кроз VPN, а VPN профил или акредитив на уређају је истекао. Уређај не може доћи до сервера да преузме заменску наредбу, а сервер не може прогурати ништа кроз тунел који се неће подићи. Опоравак сада зависи од корисника који је можда стотинама миља далеко.
Држите други, независни пут за опоравак, било да је то ванпојасни канал управљања, локални администратор или сервис за управљање који остаје доступан без тунела. Тестирајте га док све ради, јер током инцидента нећете добити чист тест.
Затим запишите којој од три потребе служи који пут и уклоните преусмеравања портова која не служе ниједној од њих. Флота којом се може управљати без општег тунела и која се још може поправити кад је тунел оно што се покварило јесте исход за који вреди пројектовати.