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

Пакет SDK для приложений Microsoft Intune для Android позволяет включить политики защиты приложений Intune (также известные как политики ПРИЛОЖЕНИЙ или MAM) в собственное приложение Java/Kotlin для Android. Приложение, управляемое Intune, интегрировано с пакетом SDK для приложений Intune. Администраторы Intune могут легко развертывать политики защиты приложений в приложении, управляемом Intune, когда Intune активно управляет приложением.

Примечание.

Это руководство разделено на несколько отдельных этапов. Начните с просмотра этапа 1. Планирование интеграции.

Этап 5. Несколько удостоверений

Этап Goals

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

Терминология идентификации

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

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

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

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

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

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

Совет

Если вы не знаете, должно ли приложение поддерживать защиту с одним или несколькими удостоверениями, вернитесь к вопросу Является ли мое приложение одним или несколькими удостоверениями?

Предупреждение

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

"Удостоверение" в пакете SDK

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

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

Совет

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Уровень потока
2. Context (обычно ) Activity Уровень
3. Уровень процесса

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

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

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

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

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

Предостережение

Приложения, которые используют WorkManager , должны проявлять особую осторожность при настройке удостоверения. В частности, эти приложения не должны задавать удостоверение для переданного Context в конструкторе Worker . Этот Context экземпляр может быть совместно использоваться несколькими Worker экземплярами одновременно. Чтобы избежать неопределенного поведения, приложения должны вместо этого задать удостоверение потока в Worker.doWork() соответствии с Worker требованиями реализации.

Примечание.

CLIPBOARD_SERVICE Так как используется для операций пользовательского интерфейса, пакет SDK использует удостоверение пользовательского интерфейса действия переднего плана для ClipboardManager операций.

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

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

public static String getUIPolicyIdentity(final Context context);

public static MAMIdentitySwitchResult setProcessIdentity(final String identity);

public static String getProcessIdentity();

public static MAMIdentitySwitchResult setCurrentThreadIdentity(final String identity);

public static String getCurrentThreadIdentity();

/**
 * 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 getPolicyForIdentity(final String identity);

public static boolean getIsIdentityManaged(final String identity);

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

     public final void switchMAMIdentity(final String newIdentity, final EnumSet<IdentitySwitchOption> options);

Примечание.

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

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

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

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

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

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

Возвращаемое значение	Сценарий
SUCCEEDED	Изменение удостоверения выполнено успешно.
NOT_ALLOWED	Изменение удостоверения запрещено. Это происходит, если предпринята попытка задать удостоверение пользовательского интерфейса (Context) при установке другого удостоверения в текущем потоке.
CANCELLED	Пользователь отменил изменение удостоверения, как правило, нажав кнопку "Назад" в пин-коде или запросе проверки подлинности.
FAILED	Сбой изменения удостоверения по неустановленной причине.

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

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

Предостережение

Context Если для setUIPolicyIdentity предоставлено Activityзначение , пакет SDK не знает, успешно ли было выполнено изменение удостоверения, до тех пор, пока не будет выполнена проверка условного запуска, настроенного администратором. Для этого может потребоваться ввести ПИН-код или корпоративные учетные данные.

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

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

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

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

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

Примечание.

Для переключения удостоверения может потребоваться повторное выполнение действия. В этом случае обратный onSwitchMAMIdentityComplete вызов будет доставлен в новый экземпляр действия.

Identity, Intents и IdentitySwitchOptions

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

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

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

Необязательные перечисления IdentitySwitchOption можно передать в API setUIPolicyIdentity и switchMAMIdentity , чтобы изменить поведение пакета 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 применял политики управляемого удостоверения, но у вас может не быть явного удостоверения для переключения.

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

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

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

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

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

Предостережение

Если приложение не прослушивает неявные изменения удостоверений, будьте осторожны, чтобы не предполагать активное удостоверение. При сомнении getCurrentThreadIdentityиспользуйте методы , getUIPolicyIdentityи getProcessIdentity для подтверждения активного удостоверения.

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

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

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

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

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

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

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

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

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

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

Ваше приложение может реализовать интерфейс MAMIdentityRequirementListener в Service или ContextProvider для изменения удостоверений, применяемого к этому потоку. Реализация должна переопределить:

public abstract void onMAMIdentitySwitchRequired(String identity,
        AppIdentitySwitchResultCallback callback);

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

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

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

Значение перечисления	Поведение пакета SDK по умолчанию	Описание
CREATE	Разрешите переключатель удостоверений.	Переключение удостоверений происходит из-за создания действия.
NEW_INTENT	Разрешите переключатель удостоверений.	Переключение удостоверений происходит из-за назначения действия нового намерения.
RESUME_CANCELLED	Заблокируйте переключатель удостоверения.	Переключение удостоверений происходит из-за отмены возобновления. Чаще всего это происходит, когда конечный пользователь нажимает кнопку "Назад" в пин-коде, проверке подлинности или пользовательском интерфейсе соответствия.

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

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

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

• callback.reportIdentitySwitchResult(FAILURE) если причина — RESUME_CANCELLED.

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

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

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

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

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

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

Предостережение

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

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

К поведению по умолчанию для MAMActivity.onMAMIdentitySwitchRequired можно получить доступ, вызвав статический метод MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, identity, 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 на doInBackgroundMAM и onPreExecuteMAM соответственно. Конструктор 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 методов и .wrapExecutorService Например:

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

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

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

Запись защищенных файлов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Если сообщается о сбое, приложение не отображает документ.

• Откроется приложение и отрисовывает файл.

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

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

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

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

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

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

Автономные сценарии

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

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

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

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

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

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

Предупреждение

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

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

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

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

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

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

Поставщики содержимого

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

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

Вызов isProvideContentAllowed не требуется, если возвращается ContentProviderParcelFileDescriptor. Дескрипторы файлов, возвращаемые поставщиком содержимого, обрабатываются автоматически на основе идентификатора файла.

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

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

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

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

Примечание.

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

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

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

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

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

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

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

Предупреждение

Приложение никогда не должно регистрироваться как для , так WIPE_USER_DATA и WIPE_USER_AUXILIARY_DATAдля .

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

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

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

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

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

Условия выхода

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

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

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

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

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

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

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

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

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

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

Сценарий	Действия
Представление одной учетной записи, управляемое	— Переключитесь на управляемую учетную запись. — Перейдите ко всем страницам приложения, на которые представлены данные одной учетной записи. — Убедитесь, что политика применяется на каждой странице.
Представление одной учетной записи, неуправляемая	— Переключитесь на неуправляемую учетную запись. — Перейдите ко всем страницам приложения, на которые представлены данные одной учетной записи. — Убедитесь, что политика не применяется ни на одной странице.
Представление с несколькими учетными записями	— Перейдите ко всем страницам приложения, на которые одновременно представлены данные нескольких учетных записей. — Убедитесь, что политика применяется на каждой странице.
Управляемая пауза	— На экране с отображаемыми управляемыми данными и активной политикой приостановите работу приложения, перейдя на начальный экран устройства или другое приложение. — Возобновление работы приложения. — Убедитесь, что политика по-прежнему применяется.
Неуправляемая пауза	— На экране, где отображаются неуправляемые данные и политика не активна, приостановите работу приложения, перейдя на начальный экран устройства или другое приложение. — Возобновление работы приложения. — Убедитесь, что политика не применяется.
Управляемое завершение	— На экране с отображаемыми управляемыми данными и активной политикой принудительное завершение приложения. — Перезапустите приложение. — Убедитесь, что если приложение возобновляется на экране с данными управляемой учетной записи (ожидаемый), политика по-прежнему применяется. Если приложение возобновляет работу на экране с данными неуправляемой учетной записи, убедитесь, что политика не применяется.
Неуправляемая инструкция kill	— На экране, где отображаются неуправляемые данные и политика активна, принудительное завершение приложения. — Перезапустите приложение. — Убедитесь, что, если приложение возобновляется на экране с данными неуправляемой учетной записи (ожидается), политика не применяется. Если приложение возобновляется на экране с данными управляемой учетной записи, убедитесь, что политика по-прежнему применяется.
Переключатель удостоверений ad hoc	— Эксперимент переключения между учетными записями и приостановки, возобновления, убийства или перезапуска приложения. — Убедитесь, что данные управляемой учетной записи всегда защищены, а данные неуправляемой учетной записи никогда не защищены.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предупреждение

Напоминаем, что если приложение использовало MAMDataProtectionManager.protect, оно должно реализовать обработчик для WIPE_USER_AUXILIARY_DATA или WIPE_USER_DATA.

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

Сценарий	Предпосылки	Действия
Обработчик дополнительной очистки	В приложении реализован обработчик для WIPE_USER_AUXILIARY_DATA	- Выполните выборочную очистку из Центра администрирования Microsoft Intune. — подтвердите (как правило, с помощью ведения журнала), что обработчик очистки успешно выполнен. — Убедитесь, что управляемая учетная запись удалена из приложения и все данные этой учетной записи удалены. — Убедитесь, что неуправляемая учетная запись по-прежнему входит в систему, данные неуправляемой учетной записи не удалены, а политика по-прежнему не применяется.
Переопределенный обработчик очистки	В приложении реализован обработчик для WIPE_USER_DATA	- Выполните выборочную очистку из Центра администрирования Microsoft Intune. — подтвердите (как правило, с помощью ведения журнала), что обработчик очистки успешно выполнен. — Убедитесь, что управляемая учетная запись удалена из приложения и все данные этой учетной записи удалены. — Убедитесь, что неуправляемая учетная запись по-прежнему входит в систему, данные неуправляемой учетной записи не удалены, а политика по-прежнему не применяется. — Убедитесь, что после завершения обработки обработчика очистки приложение успешно завершило работу или все еще находится в работоспособном состоянии.
Защита файлов вручную	— вызовы приложения MAMFileProtectionManager.protect — В приложении реализован обработчик для WIPE_USER_DATA	— Убедитесь, что вы выполнили сценарии, в которых приложение будет вручную защищать по крайней мере один файл, принадлежащий управляемой учетной записи. - Выполните выборочную очистку из Центра администрирования Microsoft Intune. — Убедитесь, что файлы удалены.
Защита буфера данных вручную	— вызовы приложения MAMDataProtectionManager.protect — Приложение реализовало обработчик для или WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA	— Убедитесь, что вы выполнили сценарии, в которых приложение будет вручную защищать по крайней мере один буфер данных, принадлежащий управляемой учетной записи. - Выполните выборочную очистку из Центра администрирования Microsoft Intune. — Убедитесь, что буферы данных удалены из файлов, в которых они хранились, и ваше приложение по-прежнему может считывать неуправляемые данные из этих файлов.

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

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