За гранью App Store, или Что нового открывает MDM и Supervised для B2B в iOS

Привет! Меня зовут Денис Кудинов, я iOS-Development team lead в «Лаборатории Касперского». В этой статье расскажу об Mobile Device Management, а также о supervised- и BYOD-режимах — как работает технология и что с ее помощью можно сделать такого, что недоступно обычным приложениям из App Store. Считайте это презентацией возможностей Configuration Profiles, да и Apple MDM в целом :)



Статья будет полезна разработчикам B2B-приложений для iOS, которые хотят разбавить свои инструменты новыми фичами, а также для product owner-ов и бэкенд-разработчиков, которые хотят поддержать взаимодействие с мобильными устройствами.

Профили конфигурации

Начнем с определения Configuration profile. Он представляет собой XML-файл, в котором описаны различные настройки, политики и ограничения, распространяющиеся на устройство. Например, в таком профиле могут быть описаны:

• парольные политики;
• политики сетей Wi-Fi;
• политики подключения принтеров через AirPrint;
• настройки VPN;
• контакты (CardDav);
• дополнительные сертификаты;
• календари (CalDav);
• и многое другое.

Так как файл Configuration Profile — это XML, его можно редактировать любыми удобными инструментами, в том числе текстовым редактором.

Способы создания профилей

Существует два способа создания конфигурационных профилей.

Создаем с помощью утилиты Apple Configurator

Apple Configurator — это проприетарная утилита для macOS, которая разрабатывается инженерами Apple. Ее основная задача — создание конфигурационных профилей и их деплой на большое количество устройств. Базовый сценарий — раскатка администратором IТ-инфраструктуры профилей на устройства в энтерпрайзе.

Ниже скриншот интерфейса Apple Configurator:



Слева — категории настроек для устройств, а справа — детали и сами настройки.
В качестве примера рассмотрим парольные политики, т. е. настройки различных ограничений, накладываемых на пароли, которые может устанавливать пользователь на устройстве.



В конфигурационном профиле можно:

• запрещать или разрешать использование простых паролей (вроде 1234, 1111 и т. п.);
• требовать добавления как минимум одной буквы и одной цифры, чтобы пароль был более сложным;
• влиять на длину пароля;
• регулировать количество сложных символов в пароле (восклицательные знаки, точки с запятой и т. п.);
• управлять сроком жизни паролей;
• устанавливать некоторые другие параметры, которые влияют на безопасность и ротацию паролей.

Создаем XML вручную

Профиль конфигурации — человеко-читаемый, поэтому его можно создать руками.
Любому iOS/macOS-разработчику знаком plist — это обычный XML-файл:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist … >
<plist version="1.0">
<dict>
 <key>PayloadContent</key>
 <array>
 <dict>
 ...
 </dict>
 </array>
 <key>PayloadDisplayName</key>
 <string>Untitled</string>
 <key>PayloadIdentifier</key>
 <string>MacBook-Pro….</string>
 <key>PayloadRemovalDisallowed</key>
 <false/>
 <key>PayloadType</key>
 <string>Configuration</string>
 <key>PayloadUUID</key>
 <string>3DD756B4-52D5-4416-8F4D-5C167BD2AA68</string>
 <key>PayloadVersion</key>
 <integer>1</integer>
</dict>
</plist>

В конфигурационном профиле есть один словарь с двумя ключами:

• PayloadContent — отвечает за сам контент, в нем содержится основная полезная нагрузка профиля.
• PayloadIdentifier — идентификатор конфигурационного профиля.

Парольная политика со скриншота выше в виде XML-файла выглядит так:

<key>PayloadContent</key>
 <array>
 <dict>
 <key>PayloadDescription</key>
 <string>Configures passcode settings</string>
 <key>PayloadDisplayName</key>
 <string>Passcode</string>
 <key>PayloadIdentifier</key>
 <string>com.apple.mobiledevice.passwordpolicy….>
 <key>PayloadType</key>
 <string>com.apple.mobiledevice.passwordpolicy</string>
 <key>PayloadUUID</key>
 <string>24A53A9C-C449-4500-AA10-99044DEB514D</string>
 <key>PayloadVersion</key>
 <integer>1</integer>
 <key>allowSimple</key>
 <true/>
 <key>forcePIN</key>
 <true/>
 <key>maxFailedAttempts</key>
 <integer>2</integer>
 <key>maxGracePeriod</key>
 <integer>0</integer>
 <key>maxInactivity</key>
 <integer>15</integer>
 <key>maxPINAgeInDays</key>
 <integer>42</integer>
 <key>minComplexChars</key>
 <integer>4</integer>
 <key>minLength</key>
 <integer>16</integer>
 <key>pinHistory</key>
 <integer>42</integer>
 <key>requireAlphanumeric</key>
 <true/>
 </dict>
 </array>

Здесь установлены те же значения, что и на скриншоте выше. Например, максимальный возраст пароля — 42 дня (maxPINAgeInDays). Т. е. конфигурационный профиль хранится в довольно простом формате, который при необходимости можно поправить руками.

Ручной подход к изменению профиля может пригодиться в компаниях, где условия и политики часто меняются. Если появилось решение использовать более сложные пароли, можно взять существующий конфигурационный профиль и поменять в нем одну настройку. Далее все эти профили раскатываются на устройства.

Как установить профиль на устройство

Существует три варианта раскатывания профилей.

Скачиваем по ссылке

Пользователь может просто скачать конфигурационный профиль по ссылке и установить его на свое устройство.
Однако есть одна сложность. После перехода по ссылке и загрузки файла пользователю необходимо разрешить установку профиля, а затем перейти в настройки, чтобы все доустановить.

Процесс установки выглядит следующим образом:



Обратите внимание, у моего конфигурационного профиля установлена зеленая галочка «Проверен» (она сообщает, что профиль валидный).

Как сделать профиль «проверенным»

Выше я обращал ваше внимание на галочку «Проверен», которая может положительно влиять на установку профиля пользователем.
Существует возможность подписывать профили. Неподписанные работают без проблем. Но у подписанных появляется статус «проверен», который означает всего лишь валидность SSL-сертификата на сервере MDM (о самом сервере мы поговорим далее).

В теории эта подпись работает следующим образом:



Разберем, как подписать профиль, на примере let’s encrypt.
Для этого необходимо три файла, которые генерирует let’s encrypt:

• fullchain.pem — целая цепочка сертификатов;
• cert.pem — сертификат сервера;
• privkey.pem — приватный ключ этого сертификата.

На первом шаге мы конвертируем сертификат в формат .crt с помощью утилиты OpenSSL с двумя параметрами: in — имя входящего сертификата, out — имя сгенерированного.

openssl x509 -inform DER -in cert.pem -out server.crt

На втором шаге необходимо подписать профиль.

openssl smime -sign
-signer server.crt
-inkey privkey.pem
-certfile fullchain.pem
-nodetach
-outform der
-in Enroll.mobileconfig
-out EnrollSigned.mobileconfig

Установленные здесь параметры команды:

• signer — передаем сертификат, сгенерированный на первом шаге;
• inkey — передаем приватный ключ;
• certfile — файл, в котором находится вся цепочка сертификатов;
• in, out — входящий и исходящий конфигурационный профили.

После выполнения этого скрипта мы получим подписанный профиль, который при установке на устройство будет отмечен зеленой галочкой.

Если вам придется самостоятельно разворачивать MDM-сервер и подписывать конфигурационные профили, рекомендую полезную статью на Medium.

Итак, галочку получили и поставили. На этом процесс установки профиля завершен.



Кажется, что процесс простой. Но мы провели небольшое исследование среди обычных пользователей. Сразу оговорюсь, что все они были мотивированы на установку профиля — их поставили в ситуацию, когда это необходимо по работе. Несмотря на мотивацию, мы увидели, что 30% не справились со скачиванием или запретили устанавливать профиль.

В целом 70% — не так уж мало, если это дает большие бенефиты для приложения. Но не стоит забывать, что у нас был кейс не рядового использования приложения. Простым немотивированным пользователям пройти этот путь будет довольно сложно. Придется целиться в свою нишу, которая точно даст разрешение на установку.

Другие способы установки

Тот же Apple Configurator позволяет раскатывать конфигурационные профили на устройства. Для этого необходимо выбрать в приложении подключенное устройство, нажать Add и добавить заранее сгенерированный профиль.



На самом устройстве, как и в первом случае, придется зайти в настройки, чтобы доустановить профиль (если устройство не в supervised-режиме, о котором мы поговорим дальше).

Еще один вариант — раскатывать с помощью MDM-сервера. Здесь важно обратить внимание, что у сервера уже должно быть подключение к конечному устройству.

Что умеют конфигурационные профили

Перечислю некоторые основные возможности конфигурационных профилей, которые могут потребоваться бизнесу.

Они позволяют:

• конфигурировать календари и контакты, т. е. сделать их едиными для всего бизнеса;
• конфигурировать почтовые клиенты, чтобы у всех на iPhone работала корпоративная почта. Наверное, это одна из супернужных фич;
• настраивать Wi-Fi-сети, вплоть до указания имени сети и пароля для доступа;
• устанавливать HTTP- и DNS-прокси;
• настраивать принтеры;
• устанавливать дополнительные сертификаты, которые могут потребоваться для работы внутри сети;
• конфигурировать VPN;
• создавать Web-clip;
• создавать черные/белые списки приложений и сайтов.

Mobile device management (MDM)

MDM — это технология для удаленного управления устройством, позволяющая выполнять на нем команды с сервера. Частично эта технология основана на конфигурационных профилях. В частности, сама установка первого соединения происходит именно с помощью конфигурационного профиля.

Технология позволяет получать из iOS-приложений информацию, недоступную другими способами, а также устанавливать на устройства другие конфигурационные профили и приложения из AppStore.

В теории механизм MDM работает следующим образом.

На сервере крутится реализация протокола MDM. Сам протокол описан в огромной PDF-ке на 250 страниц, а реализаций есть много, в том числе open source. Полную документацию по протоколу MDM можно найти по этой ссылке.

Для подключения клиента на устройство необходимо установить конфигурационный профиль с параметрами соединения с сервером.

Сервер общается с клиентом в формате «команда-ответ» (command-response). При этом связь двусторонняя.

Сервер может иметь свою внутреннюю логику и хранить данные, но важную роль здесь играет человек — администратор системы, который может посылать на устройство команды в зависимости от своих задач. Управлять устройством может и любая бизнес-логика, работающая поверх протокола MDM.

Основные возможности MDM

• просмотр информации об устройстве, которая раньше (без MDM) была недоступна приложению;
• установка и удаление приложений. Удалять можно только те приложения, которые ранее устанавливались через MDM;
• просмотр информации о других установленных конфигурационных профилях (если они существуют);
• планировка обновлений ОС;
• удаленный wipe устройства;
• перевод устройства в Lost Mode;
• удаленная блокировка/разблокировка устройства;
• планирование команд на основе собственной бизнес-логики.

Вот один из примеров информации, недоступной приложениям, но доступной через MDM: мы можем увидеть уникальные идентификаторы устройства (в том числе UDID), данные по SIM-картам вплоть до номера телефона.

Механизм Enroll устройства в MDM-программе

Рассмотрим, как работает механизм соединения с MDM-сервером.

Конфигурационный профиль для enroll в MDM устанавливается на устройство. После этого устройство отправляет команду на check in.



Сервер обрабатывает эту команду и сохраняет данные, необходимые для общения с клиентом через push-уведомления (APNs Apple) — Push magic, Push token.
После того как устройство зарегистрировалось, с помощью Push magic и Push token сервер может сделать любой запрос к устройству на «языке» протокола MDM:



После выполнения команды устройство отвечает силами ОС, никаких предусловий на устройстве не ожидается.

Что такое команды в MDM

Команды на устройство отправляются через push-сообщения в виде XML-файлов в специальном формате. Кстати, если у вас на поддержке несколько заказчиков, которых хотелось бы разграничить в MDM, необходимо предусмотреть использование разных push-сертификатов для разных юрлиц. Каждому также нужен будет enterprise-аккаунт на developer.apple.com.

Скорость выполнения команд зависит от количества информации на устройстве. Они не обязательно выполняются мгновенно. Однако можно рассчитывать на то, что ответ от устройства будет получен в любом случае (если не случится чего-то непредвиденного, вроде удаления вашего конфигурационного профиля или отключения Интернета у пользователя).

Простой Check in выглядит следующим образом (этого достаточно для того, чтобы сервер мог зарегистрировать устройство):

<?xml version=”1.0” encoding=”UTF-8”?>
<!DOCTYPE plist PUBLIC ”…”>
<plist version=”1.0”>
 <dict>
 <key>MessageType</key>
 <string>Authenticate</string>
 <key>Topic</key>
 <string>...</string>
 <key>UDID</key>
 <string>...</string>
 </dict>
</plist>

Здесь стоит обратить внимание на пару ключей:

• MessageType — это тип сообщения, которое отправляет устройство к серверу;
• UDID — это уникальный идентификатор устройства.

Описание всех команд MDM можно найти здесь

Что можно сделать командами MDM

Как я отмечал выше, MDM позволяет получать информацию об устройстве, которая недоступна приложениям. Кроме того, с помощью MDM-команд можно устанавливать на устройство другие профили и приложения.

Информацию можно получить:

• о SIM-карте, в том числе номер телефона. Если SIM-карт несколько, информация будет по всем;
• об оборудовании Wi-Fi. Что немаловажно, можно получить MAC-адрес платы Wi-Fi;
• о Bluetooth-оборудовании (также с MAC-адресом);
• об аккаунте iTunes (например, его хеш, что позволит однозначно идентифицировать пользователя);
• об уникальных идентификаторах устройства, таких как UDID или IMEI.

На скриншоте представлены UDID девайса, обязательные для общения push-строки и некоторые другие сервисные данные.



Ответ от команды DeviceInfo в минимальном объеме выглядит примерно так:



Как видите, здесь присутствуют серийный номер устройства, IMEI и MAC-адреса модулей Bluetooth и Wi-Fi, которые позволяют идентифицировать устройство.

MDM позволяет получить ID всех установленных на устройстве приложений, их версии, а также некоторые дополнительные сервисные данные. Есть возможность устанавливать на устройство другие приложения (их выбор никак не ограничен). При этом на самом устройстве появляется запрос на установку. Если пользователь согласится, установка начнется напрямую из AppStore. Кроме приложений из AppStore можно ставить и уже собранные, но правильно подписанные приложения через .ipa (в случае macOS — через .pkg).

Фактически этот механизм позволяет раскатывать всем сотрудникам одинаковые приложения, например почтовый клиент и другие инструменты бизнеса. А избежать запроса разрешения пользователя можно с помощью supervised-режима, о котором поговорим далее.

Аналогично через команды MDM можно собрать все профили, которые уже установлены на устройстве.

Скриншоты ниже мы сделали с нашего внутреннего инструмента. Вы видите список профилей моего устройства. Помимо профиля, который позволяет общаться с MDM-сервером, там есть профиль от Charles Proxy, а также еще один корпоративный.



По каждому профилю доступна информация о том, кто его установил, и некоторые идентификаторы.

Применение MDM

Не просто конфигурационные профили, а server-based MDM можно применять следующим образом:

• Поддержка Lost mode — режима, в который переходит потерянное устройство. Оно блокируется физически, а на главном экране появляется надпись: «Если вы нашли это устройство, пожалуйста, позвоните по такому-то номеру». Это может быть полезно, если сотрудник организации потеряет устройство.
• Контроль новых установленных приложений. Эта фича интересна с точки зрения безопасности. Можно отслеживать приложения, не только установленные через AppStore, но и собранные через Xcode. Обнаружение последнего может послужить администратору триггером для проведения исследования — что это за приложение и как оно работает с устройством (не несет ли потенциального вреда).
• Отслеживание установленных рутовых сертификатов. Это дает огромные бенефиты по безопасности. Если вы видите на устройстве с iOS установленные рутовые сертификаты, это может означать, что используется некое специфическое приложение, которое требует установки таких сертификатов (например, тот же Charles Proxy). Возможно, оно используется в рабочих целях. Иначе, если сертификат ставили не вы, это повод для разбирательства, поскольку наличие кастомного рутового сертификата на устройстве может привести к mitm (собственно, что и делает Charles Proxy).
• Отслеживание роуминга — взаимодействия с GSM-сетями. Может показаться, что это не особо важное применение, но на нем тоже строится определенная логика. Например, вы хотите ограничить доступ пользователям к своим веб-ресурсам, если они находятся в роуминге.
• Обеспечивать разные политики безопасности и доступа к устройству, например политики Face-ID или Touch-ID, если они доступны, а также определять парольные политики. Разные опции можно включать и отключать в зависимости от политики компании. Даже если это негативно влияет на пользовательский опыт, это может хорошо отразиться на безопасности.
• Раскатывать корпоративные приложения. Об этом мы говорили выше.
• Управлять обновлениями ОС. Можно выставлять политики принудительного обновления ОС или, наоборот, откладывать эти обновления, если вы хотите, чтобы пару недель очередной апдейт погулял по миру и его проверили другие пользователи.

«Лаборатория Касперского» уже использует большую часть этих возможностей, а наши MDM-решения вышли на рынок. Все-таки мы — центр экспертизы по мобильным и носимым устройствам. Если вы хотите выходить на передовую MDM-решений, приходите к нам разрабатывать под iOS в группу B2B-продуктов.

Supervised mode

Supervised — это режим полного управления устройством, насколько это в принципе возможно в соответствии с политикой Apple. Этот режим поддерживает расширенный набор команд с сервера MDM, допуская больше разных действий в конфигурационных профилях и в целом больше контроля над пользовательским устройством. Supervised-режим также позволяет снимать ограничения на использование некоторых API из клиента, например Content filter extension.

Supervised-режим обладает некоторыми недостатками. В частности, его установка возможна только при активации iPhone, т. е. чтобы его установить, потребуется вайпнуть устройство. Это не самый user friendly способ. Но это удобно для бизнеса, когда устройства изначально принадлежат ему. В России довольно много компаний, которые закупают устройства и раскатывают по ним свои политики.

И по воздуху supervised-режим накатить невозможно — только через Apple Configurator.

Возможности Supervised в MDM

В MDM этот режим открывает дополнительные возможности:

• Незаметную установку профилей и приложений. До сих пор мы говорили о том, что пользователь должен подтвердить установку и произвести какие-то настройки для конфигурационного профиля. В supervised-режиме этого делать не потребуется. Все можно делать без ведома пользователя. Это удобно именно для раскатки приложений или обновления политик.
• Больше вариантов ограничений, например в случае установки других приложений или подключения к сетям.
• Возможность вайпнуть устройство удаленно, например если пользователь его потерял и данные с него не хочется передавать третьим лицам.
• Доступ к системным возможностям — например, шорткаты или find my можно полностью отключить. Также можно запретить пользователю самостоятельно вайпать устройство.
• Возможность устанавливать на экран блокировки— при блокировке устройства выводить надпись, кому оно принадлежит и куда передать в случае обнаружения.
• Content filter.
• Kiosk mode — режим, при котором запускается только одно приложение и его невозможно свернуть или закрыть. Этот режим можно встретить в магазинах, где iPad используется для отображения каталога в приложении.
• Activation Lock — запрет на активацию устройства, если его все-таки удалось вайпнуть.
• Unroll deny позволяет запретить отмену участия в MDM-программе (т. е. запретить удалять конфигурационный профиль).

Полный список отличий supervised-режима можно найти по ссылке.

BYOD-режим

Bring Your Own Device (BYOD) — это режим, когда пользователь приносит собственное устройство в бизнес, который все же хочет повышенные права на управление ими.

Режим BYOD компания Apple представила всего пару лет назад. Пользователь через настройки может ввести дополнительный AppleID, который становится на устройстве рядом с его основным. Рабочий и персональный аккаунты не смешиваются, и персональный контент (фотография, приложения) не затрагивается MDM-сервером. Все рабочие файлы живут в отдельной песочнице. Фактически BYOD — это смесь обычного использования устройства и supervised-режима.

На данный момент поддерживается в общей сложности два Apple ID — личный и рабочий. Переключение в этот режим не требует от пользователя удаления всего контента, ему не нужно вайпать устройство, можно изменить настройки в любой момент. При этом в рабочей учетке BYOD частично доступны методы supervised-режима.

Ограничения BYOD

Список ограничений достаточно большой, но я приведу ключевые:

• Нельзя устанавливать Lost Mode при потере — нет удаленного вайпа, потому что очевидно, что иначе были бы затронуты и пользовательские данные.
• Нет доступа к уникальным идентификаторам устройства — IMEI и UDID.
• Мягче политики паролей — не все можно менять.
• Невозможно удалить пользовательские данные из приложений (хотя в supervised-режиме это доступно).
• Нет доступа к данным о роуминге.

Более подробную информацию об этом режиме можно найти у Apple: https://support.apple.com/ru-ru/guide/deployment/dep23db2037d/web.

В целом MDM — мощная технология, которая позволяет добавлять принципиально новую логику в приложения, особенно в сегменте B2B. В этой статье я прошелся по верхам, но если вам интересно погрузиться в эту тему подробнее, то напишите мне в комментариях, и я постараюсь подготовить новую статью. Или же приходите работать ко мне в команду, научу лично :)

>>>

Эта статья написана по мотивам выступления на Mobius. Видео моего доклада: