Пакет SDK для приложения Intune для Android с несколькими удостоверениями

Пакет SDK для приложений Microsoft Intune для Android позволяет включать политики защиты приложений Intune (также известные как политики MAM) в родное приложение Java/Kotlin для Android. Приложение, управляемое Intune, интегрировано с пакетом SDK для приложений Intune. Администраторы Intune могут легко развернуть политики защиты приложений в вашем приложении, управляемом Intune, когда Intune активно управляет приложением.

Этап 5: Множественная идентичность

Цели этапа

• Определите, требуется ли вашему приложению поддержка нескольких удостоверений.
• Узнайте, как SDK приложения Intune воспринимает удостоверения.
• Рефакторинг приложения для обеспечения осведомленности об удостоверениях.
• Добавьте код, чтобы сообщить пакету SDK об активных и изменяющихся удостоверениях во всем приложении.
• Тщательно протестируйте применение политики защиты приложений как для управляемых, так и для неуправляемых удостоверений.

Терминология удостоверений

Термины «пользователь», «учетная запись» и «удостоверение» часто используются как взаимозаменяемые. В этом руководстве предпринята попытка разграничения следующим образом:

• Пользователь — человек, использующий программный продукт. Далее разделяется на конечного пользователя, человека, использующего приложение Android, иадминистратора-администратора / ,ИТ-администратора / / ,ИТ-специалиста, человека, использующего Центр администрирования Microsoft Intune.
• Учетная запись: запись программного обеспечения, принадлежащая организации, которая уникальным образом идентифицирует сущность пользователя. У пользователя может быть несколько учетных записей.
• Удостоверение. Набор данных, который пакет SDK для приложения Intune использует для уникальной идентификации учетной записи.

Общие сведения

По умолчанию пакет SDK для приложений Intune применяет политику ко всему приложению. После регистрации учетной записи с целевой политикой защиты приложений пакет SDK связывает каждый файл и каждое действие с удостоверением этой учетной записи и применяет целевую политику этой учетной записи повсеместно.

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

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

"Identity" для пакета SDK

Когда приложение, интегрированное с SDK, регистрирует учетную запись с помощью registerAccountForMAM, пакет SDK сохраняет все предоставленные параметры (upn, aadId, tenantId и authority) в качестве идентификатора. Однако большинство API удостоверений пакета SDK используют предоставленный OID (также известный как Microsoft Entra ID или AAD ID) в качестве идентификатора для удостоверения. API SDK MAM будут возвращать строку OID в качестве удостоверения и потребуют параметр строки OID для удостоверения. Некоторые методы могут также принимать или возвращать строку имени участника-пользователя, и в этом случае имя участника-пользователя предназначено только для информационных целей.

Параметры идентификаторов не чувствительны к регистру. Запросы к пакету SDK для удостоверения могут не возвращать тот же регистр, который использовался при регистрации или настройке удостоверения.

Управляемые и неуправляемые удостоверения

Как описано в разделе "Регистрация для использования политики защиты приложений", приложение отвечает за передачу сведений пакету SDK при входе пользователя в систему. На момент входа в систему для учетной записи пользователя может применяться или не применяться политика защиты приложений. Если для учетной записи применяется политика защиты приложений, пакет SDK считает ее управляемой; в противном случае она считается неуправляемой.

SDK будет применять политику для удостоверений, которые он считает управляемыми. SDK не будет применять политику для удостоверений, которые он считает неуправляемыми.

В настоящее время пакет SDK для приложений Intune поддерживает только одно управляемое удостоверение для каждого устройства. Как только какое-либо приложение, интегрированное с пакетом SDK, зарегистрирует управляемое удостоверение, все впоследствии зарегистрированные удостоверения, даже если на них в настоящий момент нацелены политики защиты приложений, будут считаться неуправляемыми.

Если управляемое удостоверение уже зарегистрировано на устройстве и приложение регистрирует другое удостоверение, на которое также распространяется действие политики защиты приложений, пакет SDK вернет MAMEnrollmentManager.Result.WRONG_USER его и предложит пользователю варианты исправления. Дополнительные сведения см. в разделе "Регистрация для получения уведомлений от SDK ".

Активное удостоверение

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

Так как пакет SDK не обладает специальными знаниями о приложении, он должен доверять приложению в том, что оно будет предоставлять правильное активное удостоверение.

• Если приложение неправильно сообщает пакету SDK об активном неуправляемом удостоверении, когда управляемое удостоверение фактически используется, пакет SDK не будет применять средства защиты. Это может привести к утечке данных, которая подвергает риску данные пользователей.

• Если приложение неправильно сообщает пакету SDK об активном управляемом удостоверении, когда неуправляемое удостоверение фактически используется, пакет SDK неправильно применит средства защиты. Это не является утечкой данных, но может без необходимости ограничить неуправляемых пользователей и поставить данные неуправляемых пользователей под угрозу удаления.

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

Упорядочение данных приложения по удостоверениям

Всякий раз, когда приложение записывает новый файл, пакет SDK связывает с этим файлом удостоверение (другое название — "теги") на основе текущего активного потока и идентификатора процесса. Кроме того, приложение может напрямую вызывать пакет SDK, чтобы вручную пометить файл с определенным идентификатором (дополнительные сведения см. в разделе Защищенные Files записи). SDK использует этот идентификатор файла с тегом как для шифрования файлов, так и для выборочной очистки.

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

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

Пакет SDK не может связать несколько удостоверений с одним файлом. Если приложение хранит данные, принадлежащие нескольким пользователям, в одном файле, поведение пакета SDK по умолчанию приведет к недостаточной или чрезмерной защите этих данных. Настоятельно рекомендуется упорядочить данные приложения по удостоверению.

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

Реализация мультиидентификации

Чтобы объявить поддержку нескольких удостоверений для приложения, начните с размещения следующих метаданных в AndroidManifest.xml.

  <meta-data
    android:name="com.microsoft.intune.mam.MAMMultiIdentity"
    android:value="true" />

Настройка активного удостоверения

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

1. Уровень потока
2. Context (как правило Activity) уровень
3. Уровень процесса

Набор удостоверений на уровне потока заменяет набор удостоверений на Context уровне, который заменяет набор удостоверений на уровне процесса.

Идентификатор, заданный для a, Context используется только в соответствующих связанных сценариях. Операции ввода-вывода файлов, например, не имеют связанного Context. Чаще всего приложения устанавливают удостоверение Context на .Activity Можно настроить удостоверение Context в Activity.onCreate. Приложение не должно отображать данные для удостоверения, если для Activity этого удостоверения не задано это удостоверение.

Как правило, удостоверение уровня процесса полезно только в том случае, если приложение работает только с одним удостоверением одновременно во всех потоках. Это нетипичное поведение для приложений, поддерживающих несколько учетных записей. Настоятельно рекомендуется разделить данные учетной записи и установить активное удостоверение в цепочке или Context уровнях.

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

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

Следующие методы в MAMPolicyManager можно использовать для установки активного идентификатора и получения ранее заданных значений идентификаторов.

public static void setUIPolicyIdentityOID(final Context context, final String oid,
                    final MAMSetUIIdentityCallback mamSetUIIdentityCallback, final EnumSet<IdentitySwitchOption> options);

public static String getUIPolicyIdentityOID(final Context context);

public static MAMIdentitySwitchResult setProcessIdentityOID(final String oid);

public static String getProcessIdentityOID();

public static MAMIdentitySwitchResult setCurrentThreadIdentityOID(final String oid);

public static String getCurrentThreadIdentityOID();

/**
 * Get the current app policy. This does NOT take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use the overload below.
 */
public static AppPolicy getCurrentThreadPolicy();

/**
 * Get the current app policy. This DOES take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use this function.
 */
public static AppPolicy getPolicy(final Context context);


public static AppPolicy getPolicyForIdentityOID(final String oid);

public static boolean getIsIdentityOIDManaged(final String oid);

Для удобства можно также установить идентификатор действия непосредственно с помощью метода MAMActivity вместо вызова MAMPolicyManager.setUIPolicyIdentityOID. Для этого используйте следующий метод:

     public final void switchMAMIdentityOID(final String newIdentityOid, final EnumSet<IdentitySwitchOption> options);

Распространенные ошибки переключения удостоверений

• При вызовах startActivityпакета SDK приложения Intune предполагается, что активное удостоверение на Context уровне связано с указанным Intent параметром. Настоятельно рекомендуется установить Context идентичность уровня с контекстом ', Activityа не с контекстом Application'.

• Рекомендуется устанавливать удостоверение Context с помощью onCreate метода действия. Однако не забудьте также описать другие точки входа, такие как onNewIntent. В противном случае, когда одно и то же действие повторно используется для отображения данных как для управляемых, так и для неуправляемых удостоверений, политика может применяться неправильно, что приводит к незащищенным корпоративным данным или к ненадлежащим ограничению личных данных.

Результаты переключения удостоверений

Все методы, используемые для установки значений результата обратной записи идентификаторов через MAMIdentitySwitchResult. Возвращаются четыре значения:

Перед отображением или использованием данных управляемой учетной записи приложение должно проверить, что значение MAMIdentitySwitchResult есть SUCCEEDED .

Большинство методов настройки активного удостоверения возвращают MAMIdentitySwitchResult синхронно. В случае настройки удостоверения Context с помощью setUIPolicyIdentityOID результат сообщается асинхронно. Приложение может реализовать обратный вызов MAMSetUIIdentityCallback для получения этого результата или может передать значение null для объекта обратного вызова. Если звонок сделан в setUIPolicyIdentityOID то время, когда результат предыдущего вызова setUIPolicyIdentityOIDна тот же Contextеще не был доставлен, новый обратный вызов заменит старый, и исходный обратный вызов никогда не получит результат.

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

Переключатель удостоверения пользовательского интерфейса может не работать при недопустимых аргументах, если он конфликтует с удостоверением потока или если пользователь отменяет требования условного запуска (например, нажимает кнопку "Назад" на экране с ПИН-кодом).

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

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

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

Identity, Intents и IdentitySwitchOptions

Помимо автоматического добавления активного удостоверения к новым файлам, пакет SDK также помечает намерения с помощью активного удостоверения. По умолчанию пакет SDK проверит удостоверение во входящем намерении и сравнит его с активным проверкой. Если эти удостоверения не совпадают, пакет SDK обычно (*) запрашивает переключение удостоверений (дополнительные сведения см. в разделе "Неявные изменения удостоверений " ниже).

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

Пакет SDK выполняет эту проверку, так как предполагает, что приложение по-прежнему отображает содержимое намерения, принадлежащего удостоверению, отмеченному в намерении. Это предположение защищает от непреднамеренного отключения приложениями средств защиты при отображении управляемых данных; Однако это предположение может не соответствовать фактическому поведению приложения.

Необязательные перечисления IdentitySwitchOption можно передать в API setUIPolicyIdentityOID и switchMAMIdentityOID , чтобы изменить поведение SDK по умолчанию.

• IGNORE_INTENT: при запросе переключения идентификаторов на уровне пользовательского интерфейса этот параметр информирует SDK пропустить сравнение запрошенного параметра идентификатора с последним сохраненным идентификатором намерения. Это полезно, если приложение больше не отображает содержимое, принадлежащее этому удостоверению, и пакет SDK не должен блокировать этот переключатель удостоверения. Например, вы можете:

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

  Приложение должно изменить удостоверение пользовательского интерфейса на шаге 4. В этом случае, поскольку поведение приложения заключается в уходе от данных управляемой учетной записи (документа в намерении), его следует использовать IGNORE_INTENT в вызове переключения удостоверений. Это позволяет избежать непреднамеренного сбоя этого вызова пакетом SDK.

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

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

  Приложение должно изменить удостоверение пользовательского интерфейса на шаге 4. В этом случае, поскольку поведение приложения заключается в продолжении отображения данных управляемого удостоверения (предварительный просмотр документа в намерении), его следует использовать DATA_FROM_INTENT в вызове переключения удостоверения. Это сообщает пакету SDK о необходимости проверки настроенной политики защиты приложений, чтобы определить, подходят ли данные для дальнейшего отображения.

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

Очистка активного удостоверения

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

Вы можете очистить активное удостоверение, вызвав любой из установленных методов идентификаторов с параметром идентификатора OID, установленным в значение null. Если очистить удостоверение на одном уровне, пакет SDK начнет искать активное удостоверение на других уровнях в соответствии с порядком приоритета.

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

Неявное изменение удостоверений

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

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

Источники неявных изменений удостоверений

• Прием данных из других приложений, управляемых Intune, может изменить активное удостоверение на уровне потока и контекста.

  • Если действие запускается из приложения, отправленного Intent другим приложением MAM, удостоверение действия будет задано на основе активного удостоверения в другом приложении в момент Intent отправки.

    • Например, действие по просмотру документа Word запускается из намерения Microsoft Outlook, когда пользователь выбирает вложенный документ. Удостоверение средства просмотра документов в Office переключается на удостоверение из Outlook.

  • Для служб идентификатор потока будет установлен одинаково на протяжении всего вызова onStart или onBind . Вызовы в возвращенный Binder из onBind также временно устанавливают идентификатор потока.

  • Вызовы в ContentProvider завещание аналогичным образом устанавливают идентичность потока на их продолжительность.

• Взаимодействие пользователя с действием может изменить активное удостоверение на уровне контекста. Например, вы можете:

  • Отмена пользователем запроса на авторизацию во время приведет Resume к неявному переключению на пустое удостоверение.

Обработка неявных изменений удостоверений

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

Приложение может реализовать интерфейс MAMIdentityRequirementListener для изменения удостоверений ServiceContextProvider , применяемых к этому потоку. Реализация должна переопределять:

public abstract void onMAMIdentitySwitchRequired(String upn, String oid,
        AppIdentitySwitchResultCallback callback);

Приложение может реализовать интерфейс MAMActivityIdentityRequirementListener для изменений удостоверений Activity , применяемых к этому действию. Реализация должна переопределять:

public abstract void onMAMIdentitySwitchRequired(String upn, String oid,
        AppIdentitySwitchReason reason,
        AppIdentitySwitchResultCallback callback);

Параметр AppIdentitySwitchReason перечисления описывает источник неявного переключателя идентификаторов.

Параметр AppIdentitySwitchResultCallback позволяет разработчикам переопределять поведение по умолчанию для переключателя идентификаторов:

public interface AppIdentitySwitchResultCallback {
  /**
    * @param result
    *            whether the identity switch can proceed.
    */
  void reportIdentitySwitchResult(AppIdentitySwitchResult result);
}
// Where [AppIdentitySwitchResult] is either `SUCCESS` or `FAILURE`.

onMAMIdentitySwitchRequired вызывается для всех неявных изменений тождества, кроме тех, которые сделаны через Binder, возвращаемый из MAMService.onMAMBind. Реализации onMAMIdentitySwitchRequired по умолчанию немедленно вызывают:

• callback.reportIdentitySwitchResult(FAILURE)когда причина .RESUME_CANCELLED

• callback.reportIdentitySwitchResult(SUCCESS) во всех остальных случаях.

Ожидается, что большинству приложений не потребуется блокировать или откладывать переключение удостоверений другим способом, но если приложению необходимо это сделать, необходимо учитывать следующие моменты:

• Если переключатель удостоверений заблокирован, поведение пользователя такое же, как если бы параметр защиты приложений SDK "получать данные из других приложений" запретил ввод данных.

• Если служба выполняется в основном потоке, reportIdentitySwitchResultее необходимо вызывать синхронно, иначе поток пользовательского интерфейса перестает отвечать.

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

• В , Activityкогда запрашивается переключение на пустое удостоверение с указанием причины RESUME_CANCELLED, приложение должно изменить возобновленное действие, чтобы отобразить данные, согласующиеся с этим переключателем удостоверения. Если это невозможно, приложение отклонит переключение, а пользователю будет снова предложено выполнить политику для возобновляющего удостоверения (например, путем отображения экрана входа ПИН-кода приложения).

Если запрошенное удостоверение управляется (используйте MAMPolicyManager.getIsIdentityOIDManaged для проверки), но приложение не может использовать эту учетную запись (например, потому, что учетные записи, такие как учетные записи электронной почты, должны быть сначала настроены в приложении), то в переключении удостоверения должно быть отказано.

Поведение по умолчанию для MAMActivity.onMAMIdentitySwitchRequired можно получить, вызвав статический метод MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, upn, oid, reason, callback).

Аналогично, если необходимо переопределить MAMActivity.onSwitchMAMIdentityComplete, можно реализовать MAMActivityIdentitySwitchListener реализацию без явного наследования от MAMActivity.

Переключатели удостоверений и ограничения на снимки экрана

Пакет SDK для приложений Intune использует флаг FLAG_SECURE для применения политики снимков Window экрана. Некоторые приложения также могут использоваться FLAG_SECURE для собственных целей. Если политика защиты приложений не ограничивает снимки экрана, пакет SDK не будет изменяться FLAG_SECURE.

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

Сохранение удостоверений в асинхронных операциях

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

Пакет SDK для приложений Intune предоставляет MAMAsyncTask и MAMIdentityExecutors для удобства при сохранении удостоверения в асинхронных операциях. Приложение должно либо использовать их (либо явно установить идентификатор потока для задач), если его асинхронные операции могут:

• Запись данных, принадлежащих управляемому удостоверению, в файл
• Общение с другими приложениями

MAMAsyncTask

Чтобы использовать MAMAsyncTask, просто наследуйте от него вместо AsyncTask и замените переопределения doInBackground и onPreExecute с и doInBackgroundMAMonPreExecuteMAM и соответственно. Конструктор MAMAsyncTask принимает контекст деятельности. Например, вы можете:

AsyncTask<Object, Object, Object> task = new MAMAsyncTask<Object, Object, Object>(thisActivity) {

    @Override
    protected Object doInBackgroundMAM(final Object[] params) {
        // Do operations.
    }

    @Override
    protected void onPreExecuteMAM() {
        // Do setup.
    };
}

MAMAsyncTask примет активное удостоверение на основе обычного порядка приоритета.

MAMIdentityExecutors

MAMIdentityExecutorsПозволяет обернуть существующий Executor экземпляр или ExecutorService экземпляр в качестве инструмента с сохранением ExecutorExecutorService/удостоверений с помощью wrapExecutor методов andwrapExecutorService. Например:

Executor wrappedExecutor = MAMIdentityExecutors.wrapExecutor(originalExecutor, activity);
ExecutorService wrappedService = MAMIdentityExecutors.wrapExecutorService(originalExecutorService, activity);

MAMIdentityExecutors примет активное удостоверение на основе обычного порядка приоритета.

Защита файлов

Запись защищенного Files

Как упоминалось в приведенном выше разделе «Упорядочение данных приложения по удостоверению», пакет SDK для приложений Intune связывает активное удостоверение (на уровне потока/процесса) с записываемыми файлами. Для шифрования и выборочной очистки крайне важно во время создания файла задать правильное удостоверение.

Приложение может запрашивать или изменять удостоверение файла с помощью класса MAMFileProtectionManager , в частности MAMFileProtectionManager.getProtectionInfo для запросов и MAMFileProtectionManager.protectForOID изменений.

Этот protectForOID метод также можно использовать для защиты каталогов. Защита каталога применяется рекурсивно ко всем файлам и подкаталогам, содержащимся в каталоге. Когда каталог защищен, ко всем новым файлам, создаваемым в этом каталоге, автоматически применяется такая же защита. Так как защита каталогов применяется рекурсивно, protectForOID для больших каталогов вызов может занять некоторое время. По этой причине приложениям, применяющим защиту к каталогу, содержащему большое количество файлов, может потребоваться асинхронный запуск protectForOID в фоновом потоке.

Вызов protectForOID с пустой строкой для параметра identity пометит файл или каталог с неуправляемым идентификатором. Эта операция удалит шифрование из файла или каталога, если оно было зашифровано ранее. При выполнении команды выборочной очистки файл или каталог не будут удалены.

Отображение содержимого защищенного файла

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

Если файл поступает извне приложения (из общедоступного расположения, доступного ContentProvider для записи, или из него), приложение должно попытаться определить идентификатор файла (используя правильную перегрузку MAMFileProtectionManager.getProtectionInfo для источника данных), прежде чем отображать сведения, считанные из файла.

Если getProtectionInfo сообщает ненулевое непустое удостоверение, приложение должно установить удостоверение пользовательского интерфейса в соответствии с этим удостоверением с помощью MAMActivity.switchMAMIdentityOID или MAMPolicyManager.setUIPolicyIdentityOID. Если переключатель идентификаторов не работает, данные из файла не должны отображаться.

При чтении из URI содержимого может потребоваться сначала прочитать удостоверение (путем перегрузки getProtectionInfo принимать ), Uriа затем соответствующим образом задать контекст или удостоверение потока. Это необходимо сделать перед открытием файлового дескриптора или входного потока ContentResolverв , иначе операция может завершиться ошибкой.

Пример потока может выглядеть примерно так:

• Пользователь выбирает документ, чтобы открыть его в приложении.

• Во время открытого потока, до чтения данных с диска, приложение подтверждает удостоверение, которое должно использоваться для отображения содержимого:

  MAMFileProtectionInfo info = MAMFileProtectionManager.getProtectionInfo(docPath)
  if (info != null)
      MAMPolicyManager.setUIPolicyIdentityOID(activity, info.getIdentityOID(), callback, EnumSet.noneOf<IdentitySwitchOption.class>)
  

• Приложение ожидает сообщения об обратном вызове о результате.

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

• Приложение откроет и отобразит файл.

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

Single-Identity переход на несколько удостоверений

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

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

Если вы не хотите, чтобы все предыдущие данные приложения были связаны с управляемым удостоверением, вы можете обнаружить этот переход и явно снять защиту.

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

Сценарии автономной работы

Пакет SDK для приложений Intune работает в автономном режиме, когда приложение Корпоративный портал не установлено. Теги идентификаторов файлов чувствительны к автономному режиму:

• Если Корпоративный портал не установлен, файлы невозможно идентифицировать. Вызов MAMFileProtectionManager.protectForOID в автономном режиме безопасен, но не действует.

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

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

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

Защита буфера данных

MAMDataProtectionManager пакета SDK предоставляет методы для проверки и изменения помеченного идентификатора в определенных буферах данных в byte[] формате ИЛИ.InputStream

MAMDataProtectionManager.protectForOID Позволяет приложению связывать данные с удостоверением и, если на это удостоверение в данный момент применяется политика шифрования, шифровать данные. Эти зашифрованные данные подходят для хранения на диске в файле.

MAMDataProtectionManager также позволяет запрашивать данные, связанные с удостоверением, и расшифровывать их.

Приложения, которые его используют MAMDataProtectionManager , должны реализовать приемник для MANAGEMENT_REMOVED уведомления. Дополнительные сведения см. в разделе "Регистрация для получения уведомлений от SDK ".

После завершения этого уведомления буферы, которые были защищены этим классом, больше не будут читаться (если шифрование файлов было включено, когда буферы были защищены). Приложение может предотвратить нечитаемость этих буферов, вызвав MAMDataProtectionManager.unprotect все буферы при обработке MANAGEMENT_REMOVED уведомления. Также безопасно звонить protectForOID во время этого уведомления, если вы хотите сохранить личную информацию. Шифрование гарантированно отключается во время уведомления, и вызов protectForOID обработчика не приведет к шифрованию буферов данных.

Поставщики контента

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

Ваше приложение должно вызвать статический метод isProvideContentAllowedForOid(provider, oid)MAMContentProvider перед возвратом содержимого. Если эта функция возвращает значение false, содержимое не должно быть возвращено вызывающему объекту.

Звонок isProvideContentAllowedForOid не требуется, если вы ContentProvider возвращаете ParcelFileDescriptor Файловые дескрипторы, возвращаемые поставщиком содержимого, обрабатываются автоматически на основе идентификатора файла.

Выборочная очистка

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

Пакет SDK предоставляет приложению дополнительную возможность дополнять (рекомендуется) или переопределять поведение очистки по умолчанию.

Обработчик очистки по умолчанию пакета SDK не обрабатывает буферы данных, защищенные .MAMDataProtectionManager Если приложение использовало эту функцию, оно должно дополнить или переопределить обработчик очистки по умолчанию, чтобы удалить эти данные.

Дополнение поведения очистки по умолчанию

В дополнение к стандартному поведению очистки SDK приложение может зарегистрироваться для WIPE_USER_AUXILIARY_DATAMAMNotificationType.

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

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

Переопределение поведения затирания по умолчанию

Чтобы переопределить поведение затирания SDK по умолчанию, приложение может зарегистрироваться для WIPE_USER_DATAMAMNotificationType.

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

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

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

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

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

Критерии выхода

Планируйте посвятить значительное время проверке интеграции мультиудостоверений в вашем приложении. Перед началом тестирования:

• Создайте и назначьте учетной записи политику защиты приложений. Это будет тестовая управляемая учетная запись.
• Создайте другую учетную запись, но не назначьте ей политику защиты приложений. Это будет тестовая неуправляемая учетная запись. В качестве альтернативы, если приложение поддерживает несколько типов учетных записей помимо учетных записей Microsoft Entra, вы можете использовать существующую учетную запись, не относящуюся к Entra, в качестве неуправляемой тестовой учетной записи.
• Заново ознакомьтесь с применением политики в приложении. При тестировании нескольких удостоверений необходимо легко различать, когда ваше приложение работает с применением политики, а когда нет. Параметр политики защиты приложений для блокировки снимков экрана эффективен для быстрого тестирования применения политик.
• Проанализируйте весь набор пользовательского интерфейса, предлагаемого вашим приложением. Перечисление экранов, на которых отображаются данные учетной записи. Приложение может одновременно представлять данные только одной учетной записи или же оно может представлять данные, принадлежащие нескольким учетным записям одновременно?
• Рассмотрим весь набор файлов, создаваемых вашим приложением. Перечислите, какие из этих файлов содержат данные, относящиеся учетной записи, а какие — системные.
  • Определите, как будет проверяться шифрование каждого из этих файлов.
• Рассмотрите весь набор способов взаимодействия вашего приложения с другими приложениями. Перечисление всех точек входного и выходного трафика. Какие типы данных может принимать приложение? Какие намерения он транслирует? Какие контент-провайдеры он реализует?
  • Определите, как вы будете использовать каждую из этих функций обмена данными.
  • Подготовьте тестовое устройство с управляемыми и неуправляемыми приложениями, которые могут взаимодействовать с вашим приложением.
• Подумайте, как ваше приложение позволяет конечному пользователю взаимодействовать со всеми учетными записями, вошедшими в систему. Нужно ли пользователю вручную переключиться на учетную запись, прежде чем отобразятся данные этой учетной записи?

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

Проверка сценариев входа и выхода

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

Для этих тестов установите приложение и Корпоративный портал Intune Intune. Не входите в систему перед началом теста.

Проверка активного удостоверения и жизненного цикла приложения

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

Для этих тестов установите приложение и корпоративный портал Intune Intune; перед началом теста войдите как с управляемой, так и с неуправляемой учетной записью.

Проверка сценариев совместного использования данных

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

Для этих тестов установите приложение и корпоративный портал Intune Intune; перед началом теста войдите как с управляемой, так и с неуправляемой учетной записью. Также:

• Настройте политику управляемой учетной записи следующим образом:
  • "Отправлять данные организации в другие приложения" в "Приложения, управляемые политикой".
  • "Получать данные из других приложений" в "Приложения, управляемые политикой".
• Установите другие приложения на тестовом устройстве.
  • Управляемое приложение, нацеленное на ту же политику, что и ваше приложение, которое может отправлять и получать данные (как Microsoft Outlook).
  • Любое неуправляемое приложение, которое может отправлять и получать данные.
• Войдите в другое управляемое приложение с помощью управляемой тестовой учетной записи. Даже если другое управляемое приложение поддерживает несколько удостоверений, входите только с помощью управляемой учетной записи.

Если ваше приложение поддерживает возможность отправлять данные в другие приложения, например Microsoft Outlook, отправляя вложение документа в Microsoft Office:

Приложение может активно импортировать данные из других приложений, например Microsoft Outlook вкладывать файл из Microsoft OneDrive. Приложение также может пассивно получать данные из других приложений, например, Microsoft Office может открывать документ из вложения Microsoft Outlook. Параметр политики защиты приложений "Получение приложения" охватывает оба сценария.

Если ваше приложение поддерживает активный импорт данных из других приложений:

Если ваше приложение может пассивно получать данные от других приложений:

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

Проверка сценариев выборочной очистки

Ваше приложение с несколькими удостоверениями могло дополнить или переопределить поведение очистки SDK по умолчанию. Эти тесты помогают убедиться в том, что интеграция с несколькими удостоверениями надлежащим образом удаляет управляемые данные при инициации очистки, не затрагивая неуправляемые данные.

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

Дальнейшие действия

После выполнения всех указанных выше критериев выхода ваше приложение успешно интегрировано как мультиудостоверение и может применять политики защиты приложений для каждого удостоверения. Последующие разделы, этап 6: конфигурация приложений и этап 7: функции участия приложения, могут требоваться или не требоваться в зависимости от желаемой поддержки политики защиты приложений в приложении. Если вы не уверены, применим ли к вашему приложению какой-либо из этих разделов, вернитесь к разделу "Основные решения по интеграции пакета SDK".