Поделиться через


Подготовка пользователей и групп для Azure Information Protection

Примечание.

Ищете информацию о Microsoft Purview Information Protection (прежнее название — Microsoft Information Protection, MIP)?

Надстройка Azure Information Protection отменяется и заменяется метками, встроенными в приложения и службы Microsoft 365. Дополнительные сведения о состоянии поддержки других компонентов Azure Information Protection.

Клиент Защита информации Microsoft Purview (без надстройки) общедоступен.

Перед развертыванием Azure Information Protection для вашей организации убедитесь, что у вас есть учетные записи для пользователей и групп в идентификаторе Microsoft Entra для клиента вашей организации.

Эти учетные записи можно создать разными способами, в частности:

  • Вы создаете пользователей в Центр администрирования Microsoft 365 и группы в Центре администрирования Exchange Online.

  • создать пользователей и группы на портале Azure;

  • создать пользователей и группы с помощью командлетов Azure AD PowerShell и Exchange Online;

  • Вы создаете пользователей и группы в локальная служба Active Directory и синхронизируете их с идентификатором Microsoft Entra.

  • Вы создаете пользователей и группы в другом каталоге и синхронизируете их с идентификатором Microsoft Entra.

При создании пользователей и групп с помощью первых трех методов из этого списка они автоматически создаются в идентификаторе Microsoft Entra, а Azure Information Protection может использовать эти учетные записи напрямую. Однако во многих корпоративных сетях для создания пользователей и групп и управления ими используется локальный каталог. Azure Information Protection не может напрямую использовать эти учетные записи; Их необходимо синхронизировать с идентификатором Microsoft Entra.

Исключение, указанное в предыдущем абзаце, — это динамические списки рассылки, которые можно создать для Exchange Online. В отличие от статических списков рассылки, эти группы не реплика идентификатору Microsoft Entra и поэтому не могут использоваться Azure Information Protection.

Как пользователи и группы используются в Azure Information Protection

Есть три варианта использования пользователей и групп в Azure Information Protection:

Для назначения меток пользователям при настройке политики Azure Information Protection, чтобы метки можно было применить к документам и сообщениям электронной почты. Только администраторы могут выбирать этих пользователей и группы.

  • Политика Azure Information Protection по умолчанию автоматически назначается всем пользователям в идентификаторе Microsoft Entra клиента. Тем не менее можно также назначить дополнительные метки указанным пользователям или группам, используя политики с областью действия.

Для назначения прав на использование и элементов управления доступом при работе со службой Azure Rights Management для защиты документов и сообщений электронной почты. Администраторы и пользователи могут выбирать этих пользователей и группы.

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

  • Элементы управления доступом включают дату окончания срока действия и требуется ли подключение к Интернету для доступа.

Для настройки службы Azure Rights Management в рамках поддержки определенных сценариев. Только администраторы могут выбирать эти группы. Примеры настраиваемых объектов:

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

  • Делегированное администрирование службы Azure Rights Management.

  • Элементы управления подключением для поддержки поэтапного развертывания.

Требования Azure Information Protection к учетным записям пользователей

Для назначения меток:

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

Для назначения прав на использование и элементов управления доступом, а также настройки службы Azure Rights Management:

  • Для авторизации пользователей используются два атрибута в идентификаторе Microsoft Entra: proxyAddresses и userPrincipalName.

  • Атрибут Microsoft Entra proxyAddresses сохраняет все адреса электронной почты для учетной записи и может заполняться разными способами. Например, пользователь в Microsoft 365 с почтовым ящиком Exchange Online автоматически имеет адрес электронной почты, хранящийся в этом атрибуте. Если вы назначите альтернативный адрес электронной почты для пользователя Microsoft 365, он также сохраняется в этом атрибуте. Атрибут также может заполняться адресами электронной почты, которые синхронизируются из локальных учетных записей.

    Azure Information Protection может использовать любое значение в этом атрибуте Microsoft Entra proxyAddresses, обеспечивая добавление домена в клиент (проверенный домен). См. дополнительные сведения о проверке доменов:

  • Атрибут Microsoft Entra userPrincipalName используется только в том случае, если учетная запись в клиенте не имеет значений в атрибуте Microsoft Entra proxyAddresses. Например, вы создаете пользователя в портал Azure или создаете пользователя для Microsoft 365, у которых нет почтового ящика.

Назначение внешним пользователям прав на использование и элементов управления доступом

Помимо использования microsoft Entra proxyAddresses и Microsoft Entra userPrincipalName для пользователей в клиенте, Azure Information Protection также использует эти атрибуты таким же образом, чтобы авторизовать пользователей из другого клиента.

Другие методы авторизации:

  • Для адресов электронной почты, которые не находятся в идентификаторе Microsoft Entra, Azure Information Protection может авторизовать их при проверке подлинности с помощью учетной записи Майкрософт. Однако не все приложения могут открывать защищенное содержимое при использовании учетной записи Майкрософт для проверки подлинности. Дополнительные сведения

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

Требования Azure Information Protection к учетным записям групп

Для назначения меток:

  • Чтобы настроить политики область, назначающие дополнительные метки членам группы, можно использовать любой тип группы в идентификаторе Microsoft Entra ID с адресом электронной почты, содержащим проверенный домен для клиента пользователя. Группу, у которой есть адрес электронной почты, часто называют группой с поддержкой почты.

    Например, можно использовать группу безопасности с поддержкой почты, статическую группу распространения и группу Microsoft 365. Вы не можете использовать группу безопасности (динамическую или статическую), так как у группы этого типа нет адреса электронной почты. Вы также не можете использовать динамический список рассылки из Exchange Online, так как эта группа не реплика идентификатору Microsoft Entra.

Для назначения прав на использование и элементов управления доступом:

  • Вы можете использовать любой тип группы в идентификаторе Microsoft Entra с адресом электронной почты, содержащим проверенный домен для клиента пользователя. Группу, у которой есть адрес электронной почты, часто называют группой с поддержкой почты.

Для настройки службы Azure Rights Management:

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

  • Вы можете использовать любую группу в идентификаторе Microsoft Entra (с адресом электронной почты или без нее) из проверенного домена в клиенте для делегированного администрирования службы Azure Rights Management.

Назначение прав внешним группам на использование и элементов управления доступом

Помимо использования прокси-сервера Microsoft Entra для групп в клиенте, Azure Information Protection также использует этот атрибут таким же образом, чтобы авторизовать группы из другого клиента.

Использование учетных записей из локального каталога Active Directory в Azure Information Protection

Если у вас есть учетные записи, управляемые локально, которые вы хотите использовать с Azure Information Protection, необходимо синхронизировать их с идентификатором Microsoft Entra. Чтобы упростить развертывание, рекомендуется использовать Подключение Microsoft Entra. Тем не менее можно использовать любой другой метод синхронизации каталогов.

При синхронизации учетных записей не нужно синхронизировать все атрибуты. Список атрибутов, которые должны быть синхронизированы, см . в разделе Azure RMS из документации По Microsoft Entra.

В списке атрибутов для Azure Rights Management вы увидите, что для пользователей необходимо синхронизировать локальные атрибуты AD mail, proxyAddresses и userPrincipalName. Значения почты и proxyAddresses синхронизируются с атрибутом Microsoft Entra proxyAddresses. Дополнительные сведения см. в разделе "Заполнение атрибута proxyAddresses в идентификаторе Microsoft Entra ID"

Подтверждение подготовки пользователей и групп для Azure Information Protection

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

Примечание.

Модули Azure AD и MSOnline PowerShell устарели с 30 марта 2024 г. Дополнительные сведения см. в обновлении об отмене. После этой даты поддержка этих модулей ограничена поддержкой миграции в пакет SDK Для Microsoft Graph PowerShell и исправления безопасности. Устаревшие модули будут продолжать функционировать до 30 марта 2025 года.

Рекомендуется перенести в Microsoft Graph PowerShell для взаимодействия с идентификатором Microsoft Entra (ранее — Azure AD). Часто задаваемые вопросы о миграции см. в разделе "Вопросы и ответы о миграции". Примечание. Версии 1.0.x MSOnline могут возникнуть сбоем после 30 июня 2024 г.

Например, используя модуль PowerShell версии 1 для идентификатора Microsoft Entra ID, MSOnline в сеансе PowerShell, сначала подключитесь к службе и укажите учетные данные глобального администратора:

Connect-MsolService

Примечание. Если эта команда не работает, можно запустить Install-Module MSOnline для установки модуля MSOnline.

Затем настройте сеанс PowerShell, чтобы избежать усечения значений:

$Formatenumerationlimit =-1

Подтверждение готовности учетных записей пользователей к использованию в Azure Information Protection

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

Get-Msoluser | select DisplayName, UserPrincipalName, ProxyAddresses

Сначала нужно проверить, отображаются ли пользователи, которых нужно использовать в Azure Information Protection.

Затем проверьте, заполнен ли столбец ProxyAddresses. Если он заполнен, значения адресов электронной почты в этом столбце можно использовать для авторизации пользователя в Azure Information Protection.

Если столбец ProxyAddresses не заполнен, для авторизации пользователей в службе Azure Rights Management будет использоваться значение атрибута UserPrincipalName.

Например:

Отображаемое имя. UserPrincipalName ProxyAddresses
Jagannath Reddy jagannathreddy@contoso.com {}
Ankur Roy ankurroy@contoso.com {SMTP:ankur.roy@contoso.com, smtp: ankur.roy@onmicrosoft.contoso.com}

В этом примере:

  • Учетная запись пользователя Jagannath Reddy будет авторизована с использованием jagannathreddy@contoso.com.

  • Учетная запись пользователя Ankur Roy будет авторизована с использованием ankur.roy@contoso.com и ankur.roy@onmicrosoft.contoso.com, но не ankurroy@contoso.com.

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

  1. Если доменное имя в значении имени участника-пользователя является проверенным доменом для клиента Microsoft Entra, добавьте значение имени участника-пользователя в качестве другого адреса электронной почты в идентификаторе Microsoft Entra, чтобы значение имени участника-пользователя можно было использовать для авторизации учетной записи пользователя для Azure Information Protection.

    Если доменное имя в значении имени участника-пользователя не является именем проверенного домена для клиента, его нельзя использовать в Azure Information Protection. Однако пользователь все еще может пройти авторизацию как участник группы, если в адресе электронной почты группы используется имя проверенного домена.

  2. Если имя участника-пользователя не поддерживает маршрутизацию (например, ankurroy@contoso.local), укажите альтернативное имя пользователя и объясните пользователю, как выполнить вход в Office. Необходимо также задать раздел реестра для Office.

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

    Дополнительные сведения см. в статье Настройка альтернативного идентификатора входа и Приложение Office ликации периодически запрашивать учетные данные в SharePoint, OneDrive и Lync Online.

Совет

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

Пример: Get-MsolGroup | select DisplayName, ProxyAddresses | Export-Csv -Path UserAccounts.csv

Примечание.

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

Подтверждение готовности учетных записей групп к использованию в Azure Information Protection

Чтобы подтвердить учетные записи групп, используйте следующую команду:

Get-MsolGroup | select DisplayName, ProxyAddresses

Проверьте, отображаются ли группы, которые нужно использовать в Azure Information Protection. Адреса электронной почты в столбце ProxyAddresses можно использовать для авторизации участников отображаемых групп в службе Azure Rights Management.

Затем проверьте, содержат ли группы пользователей (или другие группы), которые необходимо использовать в рамках работы с Azure Information Protection. Для этого можно использовать PowerShell (например, командлет Get-MsolGroupMember) или портал управления.

Для двух сценариев с конфигурацией службы Azure Rights Management, в которых используются группы безопасности, можно выполнить команду PowerShell ниже, чтобы найти идентификатор объекта и отображаемое имя, которые можно использовать для идентификации этих групп. Можно также использовать портал Azure для поиска этих групп и копирования значений идентификатора объекта и отображаемого имени:

Get-MsolGroup | where {$_.GroupType -eq "Security"}

Рекомендации по использованию Azure Information Protection при изменении адресов электронной почты

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

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

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

Кэширование членства в группах в Azure Information Protection

Для повышения производительности служба Azure Information Protection кэширует членство в группе. Это означает, что любые изменения членства в группах в идентификаторе Microsoft Entra могут занять до трех часов, чтобы вступили в силу, когда эти группы используются Azure Information Protection, и этот период времени подлежит изменению.

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

Следующие шаги

Когда вы подтвердили, что пользователи и группы можно использовать с Azure Information Protection, и вы готовы начать защиту документов и сообщений электронной почты, проверка, нужно ли активировать службу Azure Rights Management. Эта служба должна быть активирована, прежде чем защитить документы и сообщения электронной почты вашей организации:

  • Начиная с февраля 2018 г. Если подписка, включающая Azure Rights Management или Azure Information Protection, была получена в течение или после этого месяца, служба автоматически активируется для вас.

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

Дополнительные сведения, включая проверка состояния активации, см. в статье "Активация службы защиты из Azure Information Protection".