Использование политик администрирования в Android
Михаил Варакин
преподаватель Центра компьютерного обучения «Специалист»
при МГТУ им. Н.Э. Баумана
По мере увеличения занимаемой доли рынка мобильных устройств платформа Android становится все более привлекательной для разработчиков корпоративных приложений. При этом для корпоративной среды характерна потребность в соблюдении политик, обеспечивающих необходимый уровень безопасности информационных систем. В Android API 8 (Android 2.2) впервые появилась поддержка корпоративных приложений с помощью Device Administration API, обеспечивающего возможность администрирования устройств на платформе Android на системном уровне. Данный API дает возможность разработчикам создавать приложения, необходимые в корпоративной среде, где администраторам ИС предприятия требуется контроль над мобильными устройствами персонала. Одно из таких приложений уже имеется на всех современных устройствах: встроенный почтовый клиент использует Device Administration API при синхронизации с Microsoft Exchange и посредством этого приложения администраторы Exchange могут обеспечивать соблюдение требований политик работы с паролями, а также удаленно стирать данные (делать сброс к заводским установкам) в случае потери или кражи устройства.
Организационные аспекты использования
Приложение, использующее Device Administration API, может быть установлено на устройство любым способом, как через Google Play, так и из других источников. Факт наличия установленного приложения еще не обеспечивает соблюдения политик, для которого оно было создано – от пользователя требуется согласие на применение политик администрирования. В случае отказа приложение останется в системе и будет находиться в неактивном состоянии. Как правило, согласие пользователя на использование политик предоставляет ему полезные возможности, например, доступ к конфиденциальной информации, недоступной в случае отказа. При несоблюдении пользователем действующих политик (например, при использовании недостаточно стойкого пароля), реакция приложения определяется тем, что посчитал нужным реализовать разработчик; обычно пользователь теряет возможность использования корпоративных сервисов. При использовании механизма администрирования в корпоративных средах следует иметь в виду следующие особенности:
- при попытке соединения с сервисом, требующим соблюдения определенного набора политик, не все из которых поддерживаются мобильным устройством (например, из-за устаревшей версии Android), соединение не будет устанавливаться;
- если на устройстве активированы несколько приложений, использующих Device Administration API, применяются наиболее строгие ограничения, накладываемые политиками администрирования, использующимися в данных приложениях;
- кроме разнообразных ограничений, касающихся паролей (сложность, период устаревания, количество попыток ввода), максимального времени неактивности перед блокировкой экрана, требований к шифрованию носителей и запрета использования камеры, в настоящий момент Device Administration API предоставляет дополнительные возможности: требование смены пароля, немедленная блокировка экрана и сброс к заводским установкам (с возможностью очистки внешнего накопителя – SD-карты);
- опасения пользователей относительно возможностей доступа администраторов компании к личным данным и переписке, паролям владельцев устройств в социальных сетях и т. п. совершенно безосновательны: Device Administration API таких возможностей не предоставляет.
Как это работает
В настоящий момент Device Administration API содержит три класса, являющихся основой для полнофункциональных приложений администрирования устройств:
- DeviceAdminReceiver: базовый класс для классов, реализующих политики администрирования; callback-методы этого класса предоставляют удобные средства для описания реакций на те или иные события, связанные с политиками – индивидуальные «приемники сообщений» для разных событий;
- DevicePolicyManager: класс для управления политиками, применяющимися на устройстве;
- DeviceAdminInfo: класс, использующийся для описания метаданных.
Основная логика приложения реализуется в классе, расширяющем класс DeviceAdminReceiver, являющемся наследником класса BroadcastReceiver. Здесь важно помнить, что callback-методы нашего класса исполняются в главном потоке приложения (UI thread), так что выполнение длительных операций в них недопустимо из-за опасности блокировки интерфейса пользователя. Все необходимые «долгоиграющие» действия должны выполняться в другом потоке (или даже в отдельном сервисе). Как и обычный BroadcastReceiver, наш класс должен быть описан в манифесте приложения:
<application
. . .
<receiver
android:name=".MyDeviceAdminReceiver"
android:permission="android.permission.BIND_DEVICE_ADMIN"
<meta-data
android:name="android.app.device_admin"
android:resource="@xml/device_admin_data" />
<intent-filter>
<action
android:name="android.app.action.DEVICE_ADMIN_ENABLED"/>
</intent-filter>
</receiver>
. . .
</application>
Как видно на примере, наш приемник будет принимать сообщения с action, равным ACTION_DEVICE_ADMIN_ENABLED. Для того, чтобы такие сообщения нам могла посылать только система, требуем наличия полномочий BIND_DEVICE_ADMIN (эти полномочия не предоставляются приложениям). Элемент meta-data содержит указание на ресурс, содержащий поддерживаемые приложением политики. В нашем случае путь к XML-файлу такой: res/xml/device_admin_data. Примерное содержимое файла показано ниже:
<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>
Дочерние элементы в uses-policies описывают типы политик, использующихся в приложении. Полный список возможных политик можно найти в константах класса DeviceAdminInfo, в том числе на сайте developer.android.com: http://developer.android.com/reference/android/app/admin/DeviceAdminInfo.html.
Рассмотрим примерную реализацию компонента администрирования:
public class MyDeviceAdminReceiver extends DeviceAdminReceiver {
@Override
public void onDisabled(Context context, Intent intent) {
super.onDisabled(context, intent);
// Вызывается перед тем, как данное приложение перестанет
// быть администратором устройства (будет отключено
// пользователем).
}
@Override
public void onEnabled(Context context, Intent intent) {
super.onEnabled(context, intent);
// Вызывается, когда пользователь разрешил использовать
// этот приложение как администратор устройства.
// Здесь можно использовать DevicePolicyManager
// для установки политик администрирования.
}
@Override
public void onPasswordChanged(Context context, Intent intent) {
super.onPasswordChanged(context, intent);
// Вызывается после смены пароля пользователем.
// Соответствует ли новый пароль политикам,
// можно узнать с помощью метода
// DevicePolicyManager.isActivePasswordSufficient()
}
@Override
public void onPasswordExpiring(Context context, Intent intent) {
super.onPasswordExpiring(context, intent);
// Вызывается несколько раз при приближении времени
// устаревания пароля: при включении устройства, раз в день
// перед устареванием пароля и в момент устаревания пароля.
// Если пароль не был изменен после устаревания, метод
// вызывается раз в день
}
@Override
public void onPasswordFailed(Context context, Intent intent) {
super.onPasswordFailed(context, intent);
// Вызывается в случае ввода неправильного пароля.
// Количество неудачных попыток ввода пароля можно узнать
// с помощью метода getCurrentFailedPasswordAttempts()
// класса DevicePolicyManager.
}
. . .
}
Для управления политиками в приложении требуется получить ссылку на менеджер управления политиками (обратите внимание, что context передается показанным выше методам в качестве параметра):
DevicePolicyManager dpm = (DevicePolicyManager) context
.getSystemService(Context.DEVICE_POLICY_SERVICE);
В дальнейшем этот менеджер будет использоваться для установки политик. Метод onEnabled(), устанавливающий требуемое качество пароля мог бы выглядеть примерно так:
@Override
public void onEnabled(Context context, Intent intent) {
super.onEnabled(context, intent);
DevicePolicyManager dpm = (DevicePolicyManager) context
.getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName cn = new ComponentName (context, getClass ()
dpm.setPasswordQuality (cn, DevicePolicyManager.
PASSWORD_QUALITY_NUMERIC);
}
Установки других параметров пароля делаются с помощью соответствующих методов DevicePolicyManager:
dpm.setPasswordMinimumLength(cn, 32);
dpm.setPasswordHistoryLength(cn, 10);
dpm.setPasswordExpirationTimeout(cn, 864000000L);
Помимо установки политик, DevicePolicyManager позволяет совершать и другие операции (разумеется, не в методе onEnabled() ):
- моментальная блокировка экрана:
dpm.lockNow(); - сброс к заводским установкам с очисткой SD-карты:
dpm.wipeData(DevicePolicyManager.WIPE_EXTERNAL_STORAGE); - блокировка камеры:
dpm.setCameraDisabled(cn, true);
Дополнительная информация
Развернутый работающий пример приложения можно найти в комплекте поставки Android SDK (<путь-к-SDK>/samples/android-<версия-API/ApiDemos/).
На сайте developer.android.com есть статьи по данной теме в разделах Training: http://developer.android.com/training/enterprise/device-management-policy.html и API Guides: http://developer.android.com/guide/topics/admin/device-admin.html.
Описания классов пакета android.app.admin на этом же сайте: http://developer.android.com/guide/topics/admin/device-admin.html.
Научиться разработке мобильных приложений под Android Вы сможете в Центре компьютерного обучения «Специалист» при МГТУ им. Н.Э. Баумана.
