Как работает служба Azure Rights Management: технические сведения

Описание службы Microsoft Purview

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

Примечание.

Когда служба Azure Rights Management была доступна как отдельный продукт, а не часть Защита информации Microsoft Purview, ее часто сокращают до Azure RMS. Это сокращение отображается на рисунках в этой статье.

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

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

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

На следующем рисунке можно увидеть, как работает этот процесс. Документ, содержащий формулу секрета, шифруется, а затем успешно открывается авторизованным пользователем или службой. Документ шифруется с помощью ключа содержимого (зеленый ключ на этом рисунке). Ключ содержимого уникален для каждого документа и помещается в заголовок файла, где он шифруется корневым ключом клиента Azure Rights Management (красный ключ на этом рисунке). Ключ клиента может создаваться и управляться корпорацией Майкрософт, а также создавать собственный ключ клиента и управлять ими.

На протяжении всего процесса шифрования, когда служба Azure Rights Management шифрует и расшифровывает, авторизации и применяет ограничения, формула секрета никогда не отправляется в Azure.

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

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

Элементы управления шифрования: алгоритмы и длина ключа

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

Элементы управления шифрования	Использование в службе Azure Rights Management
Алгоритм: AES Длина ключа: 128 бит и 256 бит [1]	Шифрование содержимого
Алгоритм: RSA Длина ключа: 2048 бит [2]	Шифрование ключей
SHA-256	Подписывание сертификата

Сноска 1: 256 бит используется клиентом Защита информации Microsoft Purview в следующих сценариях:

• Универсальное шифрование (PFILE).

• Собственное шифрование pdf-документов, если документ был зашифрован с помощью стандарта ISO для шифрования PDF или полученный зашифрованный документ имеет расширение PPDF-файла.

• Собственное шифрование для текстовых файлов или файлов изображений (например, .ptxt или .pjpg).

Сноска 2: 2048 бит — это длина ключа при активации службы Azure Rights Management. 1024 бита поддерживается для следующих необязательных сценариев:

• Во время миграции из локальной среды, если кластер служб Active Directory Rights Management Services (AD RMS) работает в режиме шифрования 1.

• Для архивных ключей, которые были созданы локально до миграции, чтобы содержимое, ранее зашифрованное AD RMS, можно было по-прежнему открывать службой Azure Rights Management после миграции.

Хранение и защита криптографических ключей

Для каждого документа или сообщения электронной почты, защищенных службой Azure Rights Management, служба создает один ключ AES ("ключ содержимого"), и этот ключ внедряется в документ и сохраняется в выпусках документа.

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

Этот ключ клиента защищен в веб-службы Майкрософт, в строго контролируемой среде и под тщательным мониторингом. При использовании ключа клиента, управляемого клиентом (BYOK), эта безопасность повышается за счет использования массива высококлассных аппаратных модулей безопасности (HSM) в каждом регионе Azure без возможности извлечения, экспорта или совместного использования ключей при любых обстоятельствах. Дополнительные сведения о ключе клиента и BYOK см. в статье Управление корневым ключом для службы Azure Rights Management.

Лицензии и сертификаты, отправляемые на устройство Windows, шифруются с помощью закрытого ключа устройства клиента. Этот закрытый ключ создается при первом использовании пользователем на устройстве службы Azure Rights Management. Этот закрытый ключ, в свою очередь, шифруется с помощью DPAPI на клиенте, который защищает эти секреты с помощью ключа, полученного из пароля пользователя. На мобильных устройствах ключи используются только один раз, поэтому, так как они не хранятся на клиентах, эти ключи не нужно шифровать на устройстве.

Пошаговое руководство по работе службы: первое использование, шифрование содержимого, потребление содержимого

Чтобы более подробно понять, как работает служба Azure Rights Management, давайте рассмотрим типичный поток после активации службы Azure Rights Management и когда пользователь впервые использует службу Rights Management со своего компьютера Windows (процесс иногда называется инициализацией пользовательской среды или начальной загрузкой), шифрует содержимое (документ или сообщение электронной почты), а затем используется. (открывает и использует) содержимое, зашифрованное кем-то другим.

После инициализации пользовательской среды этот пользователь сможет шифровать документы или использовать зашифрованные документы на этом компьютере.

Примечание.

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

Инициализация пользовательской среды

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

Что происходит на шаге 1. Клиент службы Azure Rights Management, запущенной на компьютере, сначала подключается к службе, и служба проверяет подлинность пользователя с помощью учетной записи Microsoft Entra.

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

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

Одним из этих сертификатов является сертификат учетной записи прав. Этот сертификат, часто сокращенный как RAC, проверяет подлинность пользователя для Microsoft Entra ID и действителен в течение 31 дня. Сертификат автоматически обновляется клиентом, если учетная запись пользователя по-прежнему находится в Microsoft Entra ID и учетная запись включена. Этот сертификат не настраивается администратором.

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

Шифрование содержимого

Когда пользователь шифрует документ, клиент службы Azure Rights Management выполняет следующие действия с незашифрованным документом:

Что происходит на шаге 1. Клиент создает случайный ключ (ключ содержимого) и шифрует документ с помощью этого ключа с помощью алгоритма симметричного шифрования AES.

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

Основным атрибутом Microsoft Entra, используемым для идентификации выбранных пользователей и групп, является атрибут Microsoft Entra ProxyAddresses, в котором хранятся все адреса электронной почты пользователя или группы. Однако если учетная запись пользователя не имеет значений в атрибуте AD ProxyAddresses, вместо этого используется значение UserPrincipalName пользователя.

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

Что происходит на шаге 3. Наконец, клиент внедряет политику в файл с текстом документа, зашифрованного ранее, который вместе состоит из зашифрованного документа.

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

Потребление содержимого

Когда пользователь хочет использовать зашифрованный документ, клиент начинает с запроса доступа к службе Azure Rights Management:

Что происходит на шаге 1. Прошедший проверку подлинности пользователь отправляет политику документов и сертификаты пользователя в службу Azure Rights Management. Служба расшифровывает и оценивает политику, а также создает список прав (если таковые имеются) пользователя для документа. Чтобы определить пользователя, атрибут Microsoft Entra ProxyAddresses используется для учетной записи пользователя и групп, членом которых является пользователь. По соображениям производительности членство в группах кэшируется. Если учетная запись пользователя не имеет значений для атрибута Microsoft Entra ProxyAddresses, вместо этого используется значение в Microsoft Entra UserPrincipalName.

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

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

Что происходит на шаге 3. Наконец, клиент принимает лицензию на зашифрованное использование и расшифровывает ее с помощью собственного закрытого ключа пользователя. Это позволяет клиенту расшифровать текст документа по мере необходимости и отобразить его на экране.

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

Примечание.

Когда пользователи, которые являются внешними по сравнению с вашей организацией, потребляют зашифрованное содержимое, поток потребления будет одинаковым. Изменения в этом сценарии — способ проверки подлинности пользователя. Дополнительные сведения см. в статье Когда я делюсь зашифрованным документом с кем-то за пределами моей компании, как этот пользователь проходит проверку подлинности?

Варианты

В предыдущих пошаговых руководствах рассматриваются стандартные сценарии, но есть несколько вариантов:

• шифрование Email. Если для шифрования сообщений электронной почты используется Exchange Online и Шифрование сообщений Microsoft Purview, проверка подлинности для потребления также может использовать федерацию с поставщиком удостоверений социальных сетей или одноразовый секретный код. Затем потоки процесса очень похожи, за исключением того, что потребление содержимого происходит на стороне службы в сеансе веб-браузера через временно кэшированную копию исходящего сообщения электронной почты.

• Мобильные устройства. Когда мобильные устройства шифруют или используют файлы с помощью службы Azure Rights Management, потоки процесса упрощаются. Мобильные устройства сначала не проходят процесс инициализации пользователей, так как каждая транзакция (для шифрования или использования содержимого) является независимой. Как и на компьютерах с Windows, мобильные устройства подключаются к службе Azure Rights Management и проходят проверку подлинности. Чтобы зашифровать содержимое, мобильные устройства отправляют политику, а служба Azure Rights Management отправляет им лицензию на публикацию и симметричный ключ для шифрования документа. Чтобы использовать зашифрованное содержимое, когда мобильные устройства подключаются к службе Azure Rights Management и проходят проверку подлинности, они отправляют политику документа в службу Azure Rights Management и запрашивают лицензию на использование документа. В ответ служба Azure Rights Management отправляет на мобильные устройства необходимые ключи и ограничения. Оба процесса используют ПРОТОКОЛ TLS для защиты обмена ключами и других обменов данными.

• Соединитель Rights Management. При использовании службы Azure Rights Management с соединителем Rights Management потоки процесса остаются неизменными. Единственное отличие заключается в том, что соединитель выступает в качестве ретранслятора между локальными службами (такими как Exchange Server и SharePoint Server) и службой управления правами Azure. Сам соединитель не выполняет никаких операций, таких как инициализация пользовательской среды, шифрование или расшифровка. Он просто ретранслирует связь, которая обычно передается на сервер AD RMS, обрабатывая преобразование между протоколами, которые используются на каждой стороне. Этот сценарий позволяет использовать службу Azure Rights Management с локальными службами.

• Универсальное шифрование (pfile). Когда служба управления правами Azure шифрует файл, поток в основном совпадает с шифрованием содержимого, за исключением того, что клиент создает политику, которая предоставляет все права. При использовании файла он расшифровывается перед передачей в целевое приложение. Этот сценарий позволяет зашифровать все файлы, даже если они изначально не поддерживают службу Azure Rights Management.

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

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

Менее технический обзор службы Azure Rights Management см. в статье Сведения о службе Azure Rights Management.

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