Повышение безопасности с использованием политик управления устройствами (Enhancing Security with Device Management Policies)


Платформа Android 2.2 (API 8) предлагает возможности управления устройством системного уровня через API администрирования устройства (Device Administration).

В этом уроке вы узнаете, как создать защищенное приложение, которое управляет доступом к своему содержанию, используя политики управления устройством (device management policies). В частности, приложение может быть настроено таким образом, что будет отображать экран блокировки с достаточно сильным паролем, перед выводом на экран содержания с ограниченным доступом для пользователя.

Определение и объявление политики

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

Вы должны объявить выбранный набор политик, которая будет обеспечиваться приложением, в файлеres/xml/device_admin.xml. Android манифест также должен ссылаться на объявленный набор политик.

Каждая объявленная политика соответствует некоторому количеству методов, относящихся к политике устройства вDevicePolicyManager (определение минимальной длины пароля и минимального количества символов верхнего регистра, далее приведены два примера). Если приложение пытается вызвать не объявленные в XML методы соответствующей политики, это приведет к SecurityException во время выполнения. Другие разрешения, такие как force-lock, доступны, если приложение собирается управлять другими видами политик. Как вы увидите позже, список объявленных политик будет представлен пользователю на экране системы, как часть процесса активации администратором устройства.

Следующий фрагмент объявляет политику длинны пароля в res/xml/device_admin.xml:

XML описание политики в манифесте Android:

Создание Device Administration Receiver

Создадим широковещательный приемник администрирования устройства (Device Administration broadcast receiver), который получает уведомления о событиях, связанных с объявленной политикой. Приложение может выборочно переопределять методы обратного вызова.

В примере приложения, Device Admin, когда администратор устройства отключен пользователем, настройки политики стираются из общих настроек. Вы должны рассмотреть возможность реализации бизнес-логики, которая имеет к вам отношение. Например, приложение может предпринять некоторые действия для смягчения риска безопасности, реализуя некоторую комбинацию удаления важных данных на устройстве, отключения удаленной синхронизации, предупреждение администратора и т.д.

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

Активация Device Administration

Перед соблюдением любой из политик, пользователю необходимо вручную активировать приложение в качестве администратора устройства. Фрагмент ниже показывает, как можно вызвать активити настроек, в которой пользователь может активировать приложение. Хорошая практика – это включение пояснительного текста для отображения пользователям, почему приложение обратилось с просьбой сделать его администратором устройства (указывается как дополнение EXTRA_ADD_EXPLANATION в намерении).

Экран активации, в котором вы можете предоставить описание вашей политики устройства

Рисунок 1. Экран активации, в котором вы можете предоставить описание вашей политики устройства

Если пользователь выберет “Активировать”, приложение становится администратором устройства и может начать настройку и обеспечение соблюдения политики.

Приложение также должно быть готово к обработке ситуации, когда пользователь покидает процесс активации, нажав кнопку “Отмена”, кнопку “Назад” или кнопку “Главная”. Таким образом, метод onResume() в активити настройки политик должен иметь логику, чтобы пересмотреть условия и представить активацию Администратора Устройства пользователю, если это необходимо.

Реализация контроллера политик устройства

После успешной активации администратора устройства, приложение настраивает диспетчер политик устройста с запрошенной политикой. Имейте в виду, что новые политики добавляются в Android с каждым релизом. Целесообразно выполнять проверку версий в ваших приложениях при использовании новой политики в то время когда поддерживается старая версия платформы. Например, политика минимального количества символов в верхнем регистре в пароле стала доступна только с API 11 (Honeycomb) и выше. Следующий код демонстрирует, как можно проверить версию во время выполнения.

В данный момент приложение не может реализовать политику. Пока приложение не имеет доступа к фактическому паролю экрана блокировки, через Device Policy Manager API оно может определить, является ли существующий пароль подходящим для политики. Если окажется, что существующий пароль экрана блокировки не подходит, API администрирования устройства не сможет автоматически принять корректирующие меры. Это ответственность лежит на приложении – нужен явный запуск системы смены пароля экрана блокировки в приложении Settings. Например:

Как правило, пользователь может выбрать один из имеющихся механизмов блокировки, например: отсутствие блокировки, шаблон, PIN-код (число) или пароль (буквы и цифры). Когда политики паролей настроены, те типы паролей, которые слабее определенных в политике, будут отключены. Например, если “Числовой” пароль указан в настройках политики, пользователь может выбрать либо PIN-код (числовой) либо пароль (буквы и цифры).

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

Источник

Перевод kraY

Оставьте комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *