Нуждаете ли се от 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 профилът или идентификационните данни на устройството са изтекли. Устройството не може да достигне сървъра, за да вземе заместваща команда, а сървърът не може да прокара нищо през тунел, който няма да се вдигне. Възстановяването вече зависи от потребител, който може да е на стотици километри.
Пазете втори, независим път за възстановяване, било то извънлентов канал за управление, локален администратор или услуга за управление, която остава достъпна без тунела. Тествайте го, докато всичко работи, защото по време на инцидент няма да получите чисто тестване.
След това запишете коя от трите нужди обслужва всеки път и премахнете пренасочването на портове, което не обслужва нито една от тях. Парк, който може да се управлява без универсален тунел и все още може да бъде поправен, когато тунелът е това, което се е счупило, е резултатът, за който си струва да се проектира.