Решения для удалённого доступа в Mars IS
Доброго времени суток, %username%!
В любой крупной компании (да и не только в крупной), люди хотят иметь доступ к корпоративной информации (рабочая почта, календарь, внутренние ресурсы) в любой момент и максимально просто. Для предоставления и управления этими доступами были созданы отдельные решения, названные Mobile Device Management.
Исторически в нашей компании мы использовали разные решения для управления мобильными устройствами. Сначала это было решение, заточенное под конкретного производителя, потом мы перешли на другой продукт, позволивший нам поддерживать как iOS так и Android устройства. В последствии было принято решение перейти на решение от Microsoft.
Microsoft Intune
На момент проведения анализа функционала решения, облачная версия предоставляла достаточно малый список возможностей, поэтому было принято решение использовать Intune Hybrid.
Что такое Intune Hybrid?
Это старый добрый System Center Configuration Manager, интегрированный с Microsoft Intune. У этого решения есть свои особенности:
- Все управление мобильными устройствами происходит через SCCM.
- Все политики безопасности и конфигурации создаются и управляются через SCCM.
По большому счету, управление мобильными устройствами стало совсем не отличаться от управления рабочими станциями. Облачная часть используется только для коммуникации между устройствами и SCCM.
Вместе с решением перейти на MS Intune, возникла необходимость перевести всех пользователей на новую платформу. К сожалению, у нас было всего 5 месяцев на миграцию и 28000 пользователей по всему миру.
Для начала использовался наименее деструктивный подход в миграции и пользователям рекомендовали перенастроить устройства для работы с новым сервисом.
Такой подход перестал работать в определенный момент, и пользователей начали принудительно отключать от предыдущего сервиса с параллельным блокированием возможности настроить устройство. Это создавало определенные сложности и дополнительную нагрузку на сервис деск. На графике открытых инцидентов по сервису мобильных устройств наглядно виден период наиболее активной миграции.
К счастью, переход завершился успешно — в установленные сроки и без неожиданных проблем.
Как там жизнь на Mars с Microsoft Intune?
В ходе миграции, было достаточно сложно адаптироваться всем командам поддержки, так как функционал по управлению мобильными устройствами был значительно шире и удобнее чем в SCCM. Но пожертвовав каким-то количеством функционала, мы получили значительно большую стабильность сервиса и меньшее количество инцидентов в целом. Для сравнения, с предыдущим решением на 28000 пользователей у нас было около 700 инцидентов в месяц, сейчас же уровень держится на ± 350 инцидентах.
С новыми релизами SCCM Microsoft добавляет новый функционал, и я надеюсь, что они продолжат инвестировать усилия именно в гибридное решение.
Что же нового?
Миграция на новый продукт также предоставила новые возможности по управлению доступом, так как Intune это только часть сервиса Enterprise Mobility + Security. Наиболее важными и интересными для нас функциями стали Conditional Access и Mobile Application Management.
Conditional access — это политика регулирования доступа к сервису. Допустим, один пользователь хочет подключиться с личного телефона к Exchange Online. Политика доступа требует, что для получения доступа к EXO его устройство должно быть под управлением Microsoft Intune. Если этот пользователь попробует настроить почтовый ящик через стандартное приложение «Почта» на iOS, он увидит только одно сообщение: «Администратор требует, чтобы устройство управлялось через Microsoft Intune». Аналогично можно регулировать доступ к любому приложению, зарегистрированному в Azure AD.
Mobile Application Management — это управление корпоративными данными внутри приложения. Именно эта настройка определяет, можно ли сохранять рабочие документы в память телефона, копировать их в сторонние приложения и так далее.
Обе эти функции позволяют гибко и безболезненно для пользователей настраивать параметры безопасности.
Миграция на Intune Standalone
Заинтересовавшись новыми решениями от Microsoft, в частности co-management и autopilot, мы поняли, что необходимо переходить на полностью облачное решение (т.н. Intune Standalone).
На момент принятия решения, Microsoft уже опубликовал пошаговую инструкцию по миграции пользователей из SCCM в Intune Standalone:
- Экспорт конфигураций из SCCM и импорт их в Intune.
- Миграция тестовых пользователей.
- Миграция всех пользователей.
- Переключение MDM Authority с SCCM на Intune.
На этапе экспорта/импорта использовалось решение от самой Microsoft. К сожалению, импорт не прошел совсем отлично и из SCCM были мигрированы не только конкретные приложения, но и все deployment types создав отдельные приложения в Intune.
Выглядело это примерно вот так:
Более того, по какой-то причине версия приложения так же не была импортирована корректно и из-за этого пришлось опубликовывать все приложения вручную. При этом конфигурации и политики были мигрированы без каких-либо проблем.
Миграция тестовой группы
Изначально тестовая группа состояла из моих коллег и меня. Мы боялись, что пользователи могут заметить, что их мигрируют. Это могло спровоцировать волну звонков в сервис деск. Но тестирование показало, что при отсутствии разницы в конфигурациях и опубликованных приложениях, пользователи ничего не замечают.
В чём состоял механизм миграции? Необходимого пользователя убирали из SCCM коллекции, которая использовалась в настройках Intune подписки. Делалось это через исключающую коллекцию, которая, в свою очередь, была завязана на группе в Active Directory. Соответственно для того, чтобы мигрировать пользователя, нужно было просто добавить его в необходимую AD группу.
Но неожиданно возникли проблемы с предоставлением доступа Сервис Деску для управления мигрированными устройствами. Мной была создана специальная роль, которая имела только необходимые для своих задач права. Роль была назначена на необходимую группу, но доступ у некоторых людей так и не появлялся. Были проверены лицензии аналитиков, их учетные записи, но все тщетно. Проверка эффективных ролей через Graph API показывала, что роль есть, но доступа у человека все еще не было. После продолжительного расследования совместно с поддержкой Microsoft, была обнаружена необходимость в наличии лицензии (Intune в пакете EMS E3 или EMS E5) для аналитиков. А также, аналитикам в свою очередь нужно быть мигрированными на Intune Standalone. Необходимость не была задокументирована и потребовалось пару недель на решение.
Параллельно я привлек к миграции группу торговых представителей из одной Европейской страны, активно использующих VPN сервис в повседневной работе и обкатывал как саму миграцию, так и отдельно настроенный для Intune Standalone NDES сервер. Именно на этом шаге, миграция чуть не была отменена с возвращением всех пользователей обратно.
Для того чтобы пользователь мог воспользоваться VPN сервисом, ему доставляется профиль, который настраивает VPN клиент, используя указанный SCEP сертификат, который ссылается на Root CA. Соответственно, для функционирования должны присутствовать пара сертификатов.
У нас был только один сертификат (Root CA).
Самое простое — это предположить, что проблема в NDES сервере. Но он работал идеально и даже не получал запросы на получение сертификатов. При исследовании логов с самих устройств я обнаружил, что устройство даже не получало необходимую настройку для запроса SCEP сертификата. Microsoft эскалировали эту проблему до разработчиков Intune, которые обнаружили важность наличия не только всех сертификатов, но и необходимость в том, чтобы все сертификаты и настройки доставлялись до одних и тех же групп пользователей и устройств. В нашем случае Root CA доставлялся на все устройства, а SCEP только на определенные.
И вот, мы приступили к миграции по нарастающей от 1000 до 4000 пользователей в одну волну. Процесс занял 4 недели. Готовы были ко всему (все мы знаем, что крайне редко все идет по плану). Но все прошло гладко без всплеска звонков в сервис деск.
Устаревшие устройства
В соответствии с нашими стандартами мы стремимся к минимальным версиям мобильных ОС:
· Т-1 для iOS.
· T-2 для Android.
*T — самая новая версия на текущий момент.
В меньшей степени это применимо к iOS, т.к. Apple достаточно долго поддерживает свои устройства. В большей степени это относится к Android устройствам. Например, люди все еще используют Android 4.4.2 на устройствах, которым больше 4 лет.
В этом случае ведем диалог с локальной ИТ командой, чтобы определить сроки замены устройств, так как необходимо найти баланс между безопасностью и денежными затратами на их обновление.
Что дальше?
Смена решения привела к внутренним изменениям. Например, существовали скрипты по очистки SCCM от неактуальных устройств, написанные на PowerShell, которые сейчас нет возможности использовать. Во всех своих новых решениях Microsoft продвигает Graph API, который необходимо освоить.
Отчетность до недавнего времени была построена на базе SSRS, сейчас же мы будем использовать Power BI + oData Feed с данными из Intune Data Warehouse.
Ранее я упомянул Conditonal Access и Mobile Application Management. Первое решение уже внедрили, над вторым сейчас работаем. Так же тестируем Azure Application Proxy как замену VPN на мобильных устройствах. Если будет интересно, с радостью расскажу об этом в новых статьях.
