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

Принцип работы Azure RMS Внутренняя логика

  • Статья

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

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

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

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

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

Защита файлов с помощью Azure RMS

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

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

Элементы управления шифрования, используемые Azure RMS: алгоритмы и длина ключей

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

Элементы управления шифрования Использование в Azure RMS
Алгоритм: AES

Длина ключа: 128 и 256 бит [1]		 Защита содержимого
Алгоритм: RSA

Длина ключа: 2048 бит [2]		 Защита ключа
SHA-256 Подписание сертификата
Сноска 1

256 бит используется клиентом Azure Information Protection в следующих сценариях:

  • Универсальная защита (PFILE).

  • Встроенная защита pdf-документов, когда документ был защищен стандартом ISO для шифрования PDF, или полученный защищенный документ имеет расширение ИМЕНИ PPDF-файла.

  • Встроенная защита текстовых или графических файлов (например, ptxt или Pjpg).

Сноска 2

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

  • Во время переноса из локальной среды, если кластер AD RMS работает в режиме шифрования 1.

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

Как хранятся и защищаются криптографические ключи Azure RMS

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

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

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

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

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

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

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

Примечание.

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

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

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

Процесс активации клиента RMS. Шаг 1. Аутентификация клиента

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

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

Процесс активации клиента RMS. Шаг 2. Скачивание сертификатов в клиент

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

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

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

Защита содержимого

Когда пользователь защищает документ, RMS-клиент выполняет следующие действия над незащищенным документом:

Защита документации с помощью RMS. Шаг 1. Шифрование документа

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

Защита документации с помощью RMS. Шаг 2. Создание политики

Что происходит на шаге 2. RMS-клиент создает сертификат, который включает политику для документа с правами на использование для пользователей или групп и другие ограничения, например дату окончания срока действия. Эти параметры можно задать в шаблоне, который настроил администратор, или указать при защите содержимого (иногда это называется политикой ad-hoc).

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

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

Защита документации с помощью RMS. Шаг 3. Встраивание политики в документ

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

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

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

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

Потребление документа службами RMS. Шаг 1. Аутентификация пользователя и предоставление списка прав

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

Потребление документа службами RMS. Шаг 2. Лицензия на использование возвращается в клиент

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

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

Потребление документа службами RMS. Шаг 3. Расшифровка документа и принудительное применение прав

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

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

Примечание.

Если пользователи, которые являются внешними по отношению к организации, используют защищенное вами содержимое, поток потребления будет одинаков. Для этого сценария меняется способ проверки подлинности пользователя. Дополнительные сведения см. в разделе Если предоставить доступ к защищенному документу кому-либо за пределами компании, как для этого пользователя выполняется проверка подлинности?

Варианты

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

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

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

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

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

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

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

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

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

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