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

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

По умолчанию пакет SDK применяет политику ко всему приложению. Несколько удостоверений — это функция MAM, которую можно включить для применения политики на уровне каждого удостоверения. Это требует более частого участия приложений, чем другие функции MAM.

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

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

Цели этапа

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

Обзор удостоверений

Удостоверение — это просто имя пользователя учетной записи (например, user@contoso.com). Разработчики могут устанавливать удостоверение приложения на следующих уровнях:

• Удостоверение процесса: Устанавливает удостоверение на уровне процесса и в основном используется для приложений с одним удостоверением. Это удостоверение влияет на все задачи, файлы и пользовательский интерфейс.

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

• Удостоверение потока: влияет на политики, применяемые в текущем потоке. Это удостоверение влияет на все задачи, файлы и пользовательский интерфейс.

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

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

Очереди обсуждений

Приложения часто отправляют асинхронные и синхронные задачи в очереди потоков. SDK перехватывает вызовы Grand Central Dispatch (GCD) и связывает текущее удостоверение потока с отправленными задачами. После завершения задач пакет SDK временно изменяет идентификатор потока на идентификатор, связанный с задачами, завершает задачи, а затем восстанавливает исходный идентификатор потока.

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

В Swift, из-за того, как пакет SDK распространяет удостоверения для DispatchWorkItem, удостоверение, связанное с А, DispatchWorkItem является идентификатором потока, создавшего элемент, а не потока, который его отправляет.

Владелец файла

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

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

Общие данные

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

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

Предоставление общего доступа к расширениям

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

Включение нескольких удостоверений

По умолчанию приложения считаются едиными удостоверениями. Пакет SDK задает идентификатор процесса для зарегистрированного пользователя. Чтобы включить поддержку нескольких удостоверений, добавьте логический параметр с именем MultiIdentity и значением YES в словарь IntuneMAMSettings в файле Info.plist приложения.

Переключение удостоверений

• Переключение удостоверений, инициированное приложением:

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

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

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

  В приложениях с несколькими удостоверениями не следует использовать setProcessAccountId их в качестве способа настройки удостоверения. Приложения, использующие UIScenes, должны использовать setUIPolicyAccountId:forWindow API для настройки удостоверения.

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

  В swift из-за async/await [IntuneMAMPolicyManager setCurrentThreadAccountId:] и [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] недоступны. Вместо этого в swift для установки текущего удостоверения используйте IntuneMAMSwiftContextManager.setAccountId(_, forScope:). Существуют варианты этого API для передачи закрытий асинхронного, throwing и async throwing.

• Переключение удостоверений, инициированное пакетом SDK:

  Иногда пакет SDK запрашивает у приложения переключение на определенное удостоверение. Приложения с несколькими удостоверениями должны реализовать identitySwitchRequiredForAccountId метод для IntuneMAMPolicyDelegate обработки этого запроса.

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

  Приложению не нужно отвечать setUIPolicyAccountId на этот вызов. Если пакету SDK требуется, чтобы приложение переключилось на неуправляемую учетную запись пользователя, пустая строка будет передана в identitySwitchRequiredForAccountId вызов.

• Автоматическая регистрация удостоверений, инициированная пакетом SDK:

  Если пакету SDK необходимо автоматически зарегистрировать пользователя в приложении для выполнения действия, приложения должны реализовать addIdentity:completionHandler: метод в IntuneMAMPolicyDelegate. Затем приложение должно вызвать обработчик завершения и передать IntuneMAMAddIdentityResultSuccess, если приложение может добавить удостоверение, или IntuneMAMAddIdentityResultFailed в противном случае.

• Выборочная салфетка:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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