Как только у сотрудника какой-либо компании появляется необходимость выполнять задачи на мобильных устройствах (пусть даже элементарно читать рабочую почту) и, соответственно, получать с них доступ к данным компании, появляются риски. Мобильные устройства (как и все эндпоинты) подвержены ряду уязвимостей — приложения, установленные не через официальные магазины, могут оказаться вредоносными; подключение к незащищенной Wi-Fi-сети может привести к утечке данных; устройство может быть утеряно или украдено… Отсюда возникают самые популярные сценарии управления устройствами — удаленное стирание данных, ограничение на источники установки приложений, требования к используемым сетям, запрет копирования конфиденциальных данных (например, на внешний носитель) и другие.

Тут-то и появляется необходимость в MDM, или Mobile Device Management, — наборе сервисов для защиты мобильных устройств сотрудников компании.

Меня зовут Мария Глущенко, я — Android-разработчик. В этой статье расскажу, какие режимы доступны для ОС Android и как реализовывать их функционал, в чем преимущества и недостатки этих решений и как мы их используем в мобильной команде «Лаборатории Касперского».

Какие бывают управляемые режимы

Вообще существует несколько крупных решений, включающих в себя, как правило, эндпоинт-приложения для всех популярных платформ — Windows/Linux/macOS/Android/iOS, а также администраторскую консоль управления. Среди крупных вендоров можно отметить Microsoft с их Intune и VMWare с Workspace One. Про MDM в iOS можно прочитать в этой статье моего коллеги Дениса Кудинова. Я же расскажу, как обстоит дело в Android.

ОС Android предоставляет возможности задавать на устройстве разные управляемые режимы в зависимости от потребностей конкретной компании. Общепринятая градация выглядит так:

● BYOD (bring your own device) — рабочие задачи могут выполняться с личного устройства сотрудника. В таком сценарии админ контролирует только рабочее пространство и не имеет доступа к персональным настройкам и данным. Это реализуется через рабочий профиль.

● COPE (company owned, personally enabled) — устройства предоставляет компания, но сотрудники могут использовать их также и в личных целях. Такой сценарий может быть реализован через механизм device owner с мягкими политиками или также через рабочий профиль.

● COBO (company owned, business only) — устройства предоставляет компания, и ими можно пользоваться только в рабочих целях, что достигается жесткими ограничениями на список разрешенных приложений и тому подобное. Для реализации такого сценария нужен механизм device owner.

● COSU (company owned, single use; новое официальное название — dedicated devices) — так называемый режим киоска, когда на устройстве могут быть заблокированы даже домашний экран, «шторка» и настройки, а для использования доступен минимальный набор приложений (часто — только одно). Для конфигурирования киоска существует отдельный механизм. 

Рассмотрим механизмы и API, позволяющие реализовать такие режимы, подробнее.

1. Device Administrator — легаси-решение для энтерпрайза, появившееся еще в Android 2.2 до того, как была придумана концепция отдельного рабочего пространства (об этом далее). Начиная с Android 9, с каждой новой версией все больше возможностей этого API помечаются как deprecated, поэтому использовать это решение напрямую в новых приложениях не рекомендуется. Однако стоит отметить, что и для последовавших более продвинутых решений Device Administrator является основой и должен быть реализован в приложении, поэтому стоит поговорить о деталях его имплементации.

How To:

● В манифесте должен быть прописан ресивер, наследующий DeviceAdminReceiver, с разрешением BIND_DEVICE_ADMIN и интент‑фильтром ACTION_DEVICE_ADMIN_ENABLED.

● В манифесте также должен быть указан xml‑файл с перечислением политик безопасности, которыми хочет управлять приложение.

● Чтобы активировать приложение как администратора устройства, нужно отправить интент с действием ACTION_ADD_DEVICE_ADMIN и получить явное подтверждение от пользователя в диалоговом окне:

Политики, доступные для управления:

● обязательная установка пароля для устройства и различные требования к его длине и сложности;

● автоматическая блокировка устройства после определенного периода неактивности;

● дистанционное удаление данных;

● блокировка камеры;

● обязательное шифрование файловой системы устройства.

Пример device admin-а в манифесте:

<activity android:name=”.app.DeviceAdminSample”

android:label=”@string/activity_sample_device_admin”>

<intent‑filter>

<action android:name=”android.intent.action.MAIN” />

<category android:name=”android.intent.category.SAMPLE_CODE” />

</intent‑filter>

</activity>

<receiver android:name=”.app.DeviceAdminSample$DeviceAdminSampleReceiver”

android:label=”@string/sample_device_admin”

android:description=”@string/sample_device_admin_description”

android:permission=”android.permission.BIND_DEVICE_ADMIN”>

<meta‑data android:name=”android.app.device_admin”

android:resource=”@xml/device_admin_sample” />

<intent‑filter>

<action android:name=”android.app.action.DEVICE_ADMIN_ENABLED” />

</intent‑filter>

</receiver>

 

Пример файла с политиками:

<device-admin xmlns:android="http://schemas.android.com/apk/res/android">

  <uses-policies>

    <limit-password />

    <watch-login />

    <reset-password />

    <force-lock />

    <wipe-data />

    <expire-password />

    <encrypted-storage />

    <disable-camera />

  </uses-policies>

</device-admin>

 Приложению с правами администратора становятся доступны следующие API:

● DeviceAdminReceiver

● DevicePolicyManager — через него происходит управление политиками и ограничениями (о них речь далее)

● DeviceAdminInfo

2. Рабочий профиль появился в Android 5 и представляет собой отдельное пространство со своими приложениями и файлами, закрытое от взаимодействия с личным (основным) профилем и полностью контролируемое админом.

Ключевые особенности этой концепции:

● настройки профиля и доступные в нем приложения определяет администратор;

● большинство интентов можно обрабатывать только в том же профиле, из которого они были запущены (исключения — некоторые системные и те, для которых специально указан атрибут cross profile);

● раздельные пространства для хранения файлов означают, что файловые URI из одного профиля невалидны для другого, передавать файлы можно через content ID.

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

● проверяет, что устройство зашифровано (и шифрует, если это не так);

● создает рабочий профиль, копирует туда приложение и делает его владельцем профиля;

● включает в профиле другие приложения, если это требуется;

● возвращает результат раскатки в методе onActivityResult.

С точки зрения конечного пользователя, создание рабочего профиля максимально упрощено и состоит всего из нескольких экранов с предложением создать профиль и объяснением, что он отделен от личного.

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

Есть несколько способов обработать сигнал от системы о выдаче приложению прав администратора. На всех версиях андроида (где в принципе есть Device Admin API) работает метод

`DeviceAdminReceiver.onProfileProvisioningComplete()`

 который нужно переопределить. На практике у приложения есть ограниченное время, чтобы обработать этот бродкаст (около 10 секунд), поэтому на Android 8 и выше рекомендуется добавить еще один способ — создать активити с интент-фильтром android.app.action.PROVISIONING_SUCCESSFUL и выполнить необходимые действия, переопределив в ней onCreate.

Команда автора при реализации device owner столкнулась с ситуацией, когда ни один из этих двух способов не отрабатывал. Был найден еще один способ (также для Android 8 и выше) — отнаследовать DeviceAdminService, прописать ему в манифесте интент-фильтр android.app.action.DEVICE_ADMIN_SERVICE и переопределить у него метод onCreate. В сценарии установки приложения через QR-код (об этом ниже) сработал только этот метод.

3. Наше приложение Kaspersky Endpoint Security долгое время обходилось возможностями, которые предоставляют механизмы администратора устройства и рабочего профиля, но, поскольку с каждой новой версией Android ужесточает ограничения на доступные API, в итоге пришлось заняться поддержкой «серьезного» MDM.

Механизм device owner (владелец устройства) продолжает идею рабочего профиля, но в этом сценарии администратор получает контроль над всем устройством. Поскольку делать такой функционал легкодоступным рискованно, для предотвращения использования этого механизма злоумышленниками существует ограничение — установить device owner можно только на «чистом» устройстве (ни разу не настроенном или сброшенном к заводским настройкам).

В процессе «раскатки» (provision) система выполняет следующие действия:

● зашифровывает устройство;

● создает управляемый профиль, в котором включены только минимально необходимые или явно указанные приложения;

● назначает приложение владельцем устройства.

В процессе раскатки необходимо передать системе данные о приложении, которое станет владельцем устройства. Как минимум это:

● пакет и имя класса, наследующего DeviceAdminReceiver;

● url, по которому можно скачать apk (должна быть именно прямая ссылка на скачивание, а не, например, страница приложения в Google Play);

● контрольная сумма apk или подписи apk (можно вычислить, в частности, с помощью утилиты openssl).

Также можно передать дополнительные данные — например, информацию о Wi-Fi-сети, к которой устройство подключится, чтобы скачать apk, и произвольные данные, которые могут быть нужны приложению для конфигурации. Полный список доступных параметров перечислен в документации. Раскатку можно осуществить следующими способами:

● NFC (Android 5 и выше) — необходимые данные передаются в бандле. До Android 10 можно использовать технологию device‑to‑device, на 10+ понадобятся специальные NFC‑теги.

● QR‑код (Android 7 и выше) — представляет собой json, в котором прописаны данные в формате key‑value. Этот способ не работает на устройствах без Google‑сервисов (например, HMS‑only), потому что использует встроенный QR‑сканер от гугла. Также он может не отрабатывать даже на тех устройствах китайских вендоров, где Google‑сервисы присутствуют (точную причину этого определить пока не удалось).

● (только для тестирования и отладки) Можно сделать приложение владельцем устройства через утилиту adb (идет в составе Android SDK). Для этого нужно:

○ включить на телефоне режим разработчика и разрешить отладку по usb;

○ удалить с устройства все учетные записи (в настройках);

○ выполнить в терминале команду `adb shell dpm set‑device‑owner [app_package_name]/[device_admin_receiver_class]`.

Владельцу устройства доступен широкий набор API для контроля настроек устройства. Основные классы, через которые задаются настройки, — DevicePolicyManager и UserManager (через него, например, можно задавать целый ряд так называемых restrictions — ограничений функциональности устройства). Стоит отметить, что многие методы этих классов доступны и в режиме владельца профиля, а некоторые — даже для любого администратора устройства, поэтому нужно внимательно читать документацию к каждому конкретному.

Некоторые настройки также можно задавать через Settings.Global, но такой метод является устаревшим и сейчас через него доступно очень малое количество настроек.

В таблице ниже приведен неполный список настроек, доступных владельцу профиля/устройства, которые могут быть полезны для реализации MDM-функционала.

4. Режим киоска предназначен для устройств, которые полностью управляются администратором и служат, как правило, только для одной задачи. С ними могут взаимодействовать как сотрудники (например, приложение для учета на складе), так и клиенты (например, терминал для заказа в кафе). На устройстве, как правило, нельзя открывать другие приложения, изменять настройки или выключать их.

Для программной реализации такого режима в андроиде используется lock task mode (Android 5 и выше). В таком режиме может быть запущено любое приложение, однако запуск разрешено выполнять только приложению, которое является device policy controller. Таким образом, есть два варианта запускать приложение в режиме киоска — либо оно само должно быть контроллером, либо на устройстве должно быть приложение-контроллер, способное запустить его.

Приложение-DPC может накладывать следующие ограничения для режима киоска:

● «шторка» с системной информацией скрыта, не показываются уведомления;

● недоступны кнопки «домой» и «overview», в отдельных случаях можно блокировать кнопку «назад»;

● блокируется лок‑скрин (устройство не засыпает); можно дополнительно выставить ограничение, чтобы при подключенном зарядном устройстве экран не выключался вообще;

● блокируются опции выключить/перезагрузить при долгом нажатии кнопки включения;

● любые из функций выше можно при желании включить, указав соответствующие флаги при запуске режима киоска (DevicePolicyManager.setLockTaskFeatures());

● приложение, являющееся DPC, может устанавливать список приложений, доступных для запуска в режиме киоска (DevicePolicyManager.setLockTaskPackages());

● На Android 9 и выше приложение‑DPC может запускать в lock task mode активити любого другого приложения (ранее добавленного через setLockTaskPackages()), на предыдущих версиях — только свои собственные активити.

Вендор-специфичные решения

Многие производители мобильных устройств предоставляют собственные MDM-решения. Их безусловное преимущество заключается в доступе к аппаратной части устройства и, следовательно, более широкому набору доступных настроек. Порядок получения доступа к каждому конкретному решению отличается — Samsung, например, продает Knox API для бизнеса всем желающим, а Huawei требует гораздо более сложную процедуру, включающую закупку устройств и предоставление подробной информации о том, как и для чего будет использоваться API.

Среди таких решений можно назвать:

● Samsung Knox — работает в режимах владельца профиля или устройства, предъявляет минимальные требования к интеграции (по сути, только покупка лицензии Knox).

● Huawei MDM — набор API, предоставляющих функционал, очень схожий с владельцем устройства, но с правами администратора устройства. Лицензия выдается только после предоставления информации о сценариях использования и ревью внутри компании.

● LG Gate MDM — решение в первую очередь ориентировано на сценарий BYOD и поэтому использует рабочий профиль. Для доступа требуется вступить в партнерскую программу, но на сайте LG Gate нет информации о том, какие требования предъявляются к партнерам.

● Xiaomi Enterprise Service — набор API, также по функционалу схожий с владельцем устройства. Для получения доступа нужно пройти первичную регистрацию и верификацию, а потом предоставить разработанное приложение на ревью. При этом в документации упоминается что апи позволяет создать не просто администраторское приложение, а кастомизированный ROM на замену системному.

● У Motorola есть готовое приложение Moto OEMConfig, позволяющее конфигурировать политики безопасности из EMM‑консоли, и лежащий в его основе Enterprise Device Management SDK. Для использования SDK в своем приложении достаточно подключить к проекту библиотеку.

Android Management API

Android Management API — это энтерпрайз-решение от Google, разработанное для взаимодействия с EMM-консолью. Оно представляет собой API, которое может вызывать консоль, а также готовое мобильное приложение-компаньон — Android Device Policy. Через API администратор может создать гибко настраиваемые политики, за применение которых на конечных устройствах отвечает уже мобильное приложение. Это решение может работать как для рабочего профиля, так и для владельца устройства (и Google даже предоставляет примеры политик для разных конфигураций).

Чтобы получить доступ к API и начать работу с ним, нужно:

● создать проект в Google Cloud Console;

● создать enterprise — как правило, эта сущность только одна, но никто не запрещает создать несколько;

● создать базовую политику;

● подключить мобильное устройство — для этого нужно создать enrollment token. Для создания токена в API передается имя энтерпрайза и опционально идентификатор политики. Полученный токен нужно зашить в ссылку или QR‑код, который будет открыт на устройстве. Для режима владельца устройства так же, как и в случае с собственным приложением, нужно предварительно сбросить телефон к заводским настройкам.

Сами политики представляют собой (в терминах API) json-объекты, через которые можно задавать перечень настроек для применения на устройстве. Полный список доступных для конфигурирования политик можно посмотреть по ссылке https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#Policy. Во многом они повторяют ограничения, доступные владельцу устройства (потому что реализованы именно через этот механизм в Android Device Policy). Среди основных можно выделить следующие:

● требования к сложности и надежности пароля;

● ограничение доступа к камере;

● конфигурация сетей;

● запрет сброса к заводским настройкам и загрузки в safe mode;

● запрет подключения sd card;

● запрет на установку приложений.

В случае если устройство не соответствует установленным политикам (например, имеет пароль недостаточной сложности или не зашифровано), Android Device Policy автоматически заблокирует, в зависимости от режима, либо рабочий профиль, либо телефон целиком. Через 10 дней, если проблему не исправить, рабочие данные будут удалены.

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

Стоит отметить, что у Google также есть решение Google Play EMM API, упрощающее разработку EMM-консоли, однако для его использования необходимо быть одобренным партнером, и на данный момент новые заявки не принимаются. Все новые приложения предлагается разрабатывать с использованием Android Management API.

Управляемые конфигурации приложений

Некоторые приложения, не относящиеся к MDM-функционалу напрямую (например, браузер или почтовый клиент), предоставляют возможность конфигурировать свои настройки, что может быть удобно для администратора. Этот механизм называется managed configurations и опирается на концепцию App Config.

App Config включает в себя набор стандартов, а также библиотеку node.js и реализующее ее cli-приложение. App Config можно использовать для создания конфигурируемых приложений на любой платформе. Одним из его главных преимуществ является валидация конфигураций, которая отсутствует, например, при использовании переменных окружения.

В Android поддержка App Config есть, начиная с версии 5.0, и реализована через RestrictionManager и механизм managed configurations.

Чтобы предоставить управляемые конфигурации для своего приложения, нужно создать в ресурсах файл app_restrictions.xml и прописать в нем набор restrictions (название сложилось исторически, конфигурировать можно что угодно, а не только ограничения). У рестрикшена можно задать следующие поля:

● ключ;

● название (локализуемое);

● тип (boolean, int, string…);

● описание (локализуемое);

● дефолтное значение.

Стоит отметить, что нужно подставлять локализуемые значения через @string/, а не создавать несколько файлов с рестрикшенами.

Проверять текущие значения конфигураций можно с помощью RestrictionManager (или UserManager — getApplicationRestrictions() работает идентично). Проверку стоит выполнять при запуске и возобновлении работы приложения (в методе onResume()), а также когда система оповещает об изменении конфигураций. Для этого нужно добавить BroadcastReceiver, отслеживающий интент ACTION_APPLICATION_RESTRICTIONS_CHANGED, причем не в манифесте приложения, а динамически в коде.

Метод getApplicationRestrictions() возвращает бандл с парами ключ-значение для каждой конфигурации. Стоит отметить, что в бандле будут только явно заданные значения — даже если для какого-то ключа в xml есть дефолтное, такой пары в бандле не будет. После получения конфигураций приложение может применить их соответствующим образом.

Управляемые конфигурации доступны и задокументированы в том числе в приложениях самого Google. Например, в Google Chrome для конфигурации доступно:

● на каких сайтах разрешать/блокировать куки;

● на каких сайтах разрешать/блокировать джаваскрипт;

● на каких сайтах разрешать/блокировать всплывающие окна;

● настройки прокси;

● страница, которая будет автоматически открываться в новой вкладке;

● и многое другое.

А в GMail можно задавать такие параметры, как адрес электронной почты, хост почтового сервера, обязательное включение SSL и подпись по умолчанию. В общем случае доступные управляемые конфигурации приложения, если они есть, перечислены на его странице в Google Play — магазин берет информацию о них напрямую из файла app_restrictions.

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

Также для управления приложениями, которые устанавливаются на устройство, есть полезная концепция Managed Google Play — по сути, это встроенная прямо в EMM-консоль администрирования страница магазина. Вместо того чтобы вводить вручную имя пакета запрещенного или разрешенного приложения, администратор может найти его прямо на этой странице и выбрать — имя пакета передастся обратно в консоль само. Пример реализации можно посмотреть, например, в консоли Airwatch, где через этот механизм можно выбирать обязательные для установки приложения.

Заключение

Мы рассмотрели общие механизмы и возможности MDM в Android, но, конечно, не могли в одной статье полностью охватить такую обширную тему и все технические детали. Надеюсь, статья будет полезна тем, кто только начинает погружаться в мир MDM и хочет разрабатывать собственные решения или интегрировать существующие. Любые дополнительные вопросы смело задавайте в комментариях.

Наша команда сейчас активно работает над расширением MDM-функциональности нашего приложения для бизнеса Kaspersky Endpoint Security (как Android, так и iOS). Если вам интересна тема MDM — приходите к нам, будем вместе работать над новыми фичами и делать жизнь энтерпрайза удобнее и безопаснее.