Нужен ли 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 на устройстве истекли. Устройство не может достичь сервера, чтобы получить заменяющую команду, а сервер не может протолкнуть ничего через туннель, который не поднимется. Восстановление теперь зависит от пользователя, который может быть за сотни миль.
Держите второй, независимый путь для восстановления — внеполосный канал управления, локального администратора или службу управления, остающуюся достижимой без туннеля. Проверяйте его, пока всё работает, потому что во время инцидента чистой проверки вы не получите.
Затем запишите, какую из трёх потребностей обслуживает каждый путь, и удалите пробросы портов, которые не обслуживают ни одну из них. Парк, которым можно управлять без общего туннеля и который всё ещё можно починить, когда сломался именно туннель, — это результат, ради которого стоит проектировать.