Чи потрібен вам 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 на пристрої прострочені. Пристрій не може досягти сервера, щоб отримати замінну команду, а сервер не може проштовхнути нічого через тунель, який не підніметься. Відновлення тепер залежить від користувача, який може бути за сотні миль.
Тримайте другий, незалежний шлях для відновлення: позасмуговий канал керування, локальний адміністратор або служба керування, що залишається досяжною без тунелю. Перевіряйте його, поки все працює, бо під час інциденту чистої перевірки ви не отримаєте.
Потім запишіть, яку з трьох потреб обслуговує кожен шлях, і видаліть переспрямування портів, які не обслуговують жодної з них. Парк, яким можна керувати без загального тунелю і який ще можна відремонтувати, коли зламався саме тунель, — це результат, заради якого варто проєктувати.