Этап 2 перехода. Настройка на стороне сервера для AD RMS

Область применения: службы Active Directory Rights Management, Azure Information Protection, Office 365

К чему относится: клиент унифицированных меток и классический клиент AIP

Примечание

Для унификации и улучшения работы пользователей поддержка классического клиента Azure Information Protection и клиента управления метками на портале Azure прекращается с 31 марта 2021 г. Хотя классический клиент продолжит работать, дальнейшая поддержка предоставляться не будет и версии для обслуживания классического клиента больше не будут выпускаться.

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

В этой статье приведены сведения по второму этапу перехода с AD RMS на службу Azure Information Protection. Действия охватывают с 4 по 6 шаги перехода с AD RMS на службу Azure Information Protection.

Шаг 4. Экспорт данных конфигурации из AD RMS и их импорт в Azure Information Protection

Этот шаг состоит из двух этапов.

  1. Экспорт данных конфигурации из службы AD RMS путем экспорта доверенных доменов публикации (TPD) в XML-файл. Этот процесс одинаков для всех операций переноса.

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

Экспорт данных конфигурации из службы AD RMS

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

Экспорт данных конфигурации (сведений о доверенном домене публикаций)

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

  2. С помощью консоли управления службой AD RMS (Службы управления правами Active Directory) разверните имя кластера службы AD RMS, разверните Политики доверия и щелкните Доверенные домены публикаций.

  3. В области результатов выберите доверенный домен публикаций и щелкните на панели действий Экспорт доверенного домена публикаций.

  4. В диалоговом окне Экспорт доверенного домена публикаций выполните следующие действия.

    • Щелкните Сохранить как и сохраните путь и имя файла по своему усмотрению. Не забудьте указать .xml как расширение имени файла (оно не добавляется автоматически).

    • Укажите и подтвердите надежный пароль. Запомните этот пароль, так как он понадобится позже при импорте данных конфигурации в Azure Information Protection.

    • Не устанавливайте этот флажок, чтобы сохранить файл доверенного домена в RMS версии 1.0.

После экспорта всех доверенных доменов публикации вы можете начать процедуру импорта этих данных в Azure Information Protection.

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

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

Импорт данных конфигурации в службу Azure Information Protection

Точные процедуры для этого шага зависят от текущей конфигурации развертывания службы AD RMS и предпочтительной топологии для ключа клиента Azure Information Protection.

В текущем развертывании служб AD RMS используется одна из следующих конфигураций ключа сертификата лицензиара сервера (SLC).

  • Защита паролем в базе данных службы AD RMS. Это конфигурация по умолчанию.

  • Защита HSM с помощью аппаратного модуля безопасности (HSM) nCipher.

  • Защита HSM с помощью аппаратного модуля безопасности (HSM) от поставщика, отличного от nCipher.

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

Примечание

Подробнее о применении аппаратных модулей безопасности в службе AD RMS см. в статье Использование службы AD RMS с аппаратным модулем безопасности.

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

Используйте следующую таблицу при выборе процедуры для своего переноса.

Текущее развертывание службы AD RMS Выбранная топология ключа клиента Azure Information Protection Инструкции по переносу
Защита паролем в базе данных службы AD RMS Под управлением корпорации Майкрософт См. раздел программно-защищенный ключ к программно защищенным ключам после этой таблицы.

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

Для этого требуется набор инструментов BYOK Azure Key Vault и три набора инструкций. Сначала выполняется передача ключа из локального модуля HSM в модули HSM Azure Key Vault, затем нужно предоставить службе Azure Rights Management из Azure Information Protection права на использование ключа клиента, и, наконец, осуществляется передача данных конфигурации в Azure Information Protection.
Защита паролем в базе данных службы AD RMS С управлением клиентом (BYOK) См. процедуру Перенос программно-защищенного ключа в ключ, защищенный с помощью аппаратного модуля безопасности, описанную под этой таблицей.

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

При наличии ключа, защищенного с помощью HSM, который невозможно экспортировать, все равно можно перенести данные в Azure Information Protection, настроив кластер AD RMS для работы в режиме только для чтения. В этом режиме можно открыть ранее защищенное содержимое, но вновь защищенное содержимое использует новый ключ клиента, контролируемый вами (BYOK) или корпорацией Майкрософт. Дополнительные сведения см. в разделе An update is available for Office to support migrations from AD RMS to Azure RMS (Доступно обновление для Office, поддерживающее миграции из AD RMS в Azure RMS).

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

Примечание

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

Чтобы выполнить шаг 4, выберите инструкции для варианта переноса:

Шаг 5. Активация службы Azure Rights Management

Откройте сеанс PowerShell и выполните следующие команды.

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

    Connect-AipService
    
  2. Активируйте службу Azure Rights Management.

    Enable-AipService
    

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

Шаг 6. Настройте импортированные шаблоны.

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

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

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

Изменения шаблонов, которые может потребоваться внести для этого шага

  • Если вы создали настраиваемые шаблоны в Azure Information Protection до перехода, их необходимо вручную экспортировать и импортировать.

  • Если для работы с шаблонами AD RMS использовалась группа Все, может потребоваться добавить пользователей или группы вручную.

    При включении пользователей в группу "Все" в AD RMS предоставляются права всем пользователям, аутентифицированным в локальном экземпляре Active Directory. Эта группа не поддерживается службой Azure Information Protection. Ближайший аналог — это группа, которая создается автоматически для всех пользователей в клиенте Azure AD. Если вы использовали группу "Все" для работы с шаблонами AD RMS, необходимо вручную добавить пользователей и предоставить требуемые права.

Процедура, выполняемая в случае, если настраиваемые шаблоны созданы до миграции

Если настраиваемые шаблоны созданы до миграции (до или после активации службы Azure Rights Management), они не будут доступны пользователям после миграции, даже если для них было задано значение Опубликованы. Чтобы сделать их доступными для пользователей, сначала выполните указанные далее действия:

  1. Найдите эти шаблоны и запишите их идентификатор шаблона, выполнив Get-аипсервицетемплате.

  2. Экспортируйте шаблоны с помощью командлета PowerShell Azure RMS Export-аипсервицетемплате.

  3. Импортируйте шаблоны с помощью командлета PowerShell Azure RMS Import-аипсервицетемплате.

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

Процедура, выполняемая, если шаблоны в AD RMS использовали группу ВСЕ

Если шаблоны в AD RMS использовали группу " все ", ближайшая эквивалентная группа в Azure Information Protection называется AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@ <tenant_name> . onmicrosoft.com. Например, эта группа может выглядеть следующим образом для Contoso: AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.onmicrosoft.com . Эта группа содержит всех пользователей из вашего клиента Azure AD.

При управлении шаблонами и метками на портале Azure эта группа отображается как доменное имя вашего клиента в Azure AD. Например, для Contoso эта группа может выглядеть следующим образом: contoso.onmicrosoft.com. Чтобы добавить эту группу, в параметре отображаются <organization name> элементы добавить все.

Если вы точно не знаете, включают ли ваши шаблоны AD RMS группу "ВСЕ", можно использовать приведенный далее пример скрипта Windows PowerShell для определения этих шаблонов. Дополнительные сведения об использовании Windows PowerShell с AD RMS см. в разделе Использование Windows PowerShell для администрирования AD RMS.

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

Дополнительные сведения об этой настройке см. в статье Как настроить метку для применения защиты Rights Management.

Пример скрипта Windows PowerShell для выявления шаблонов, включающих группу "ВСЕ"

Данный раздел содержит пример скрипта, помогающего выявить шаблоны AD RMS, в которых определена группа "ВСЕ", в соответствии с описанием, содержащимся в предыдущем разделе.

Заявление об отказе: Этот пример скрипта не поддерживается ни в одной из программ или служб поддержки Microsoft Standard. Этот пример скрипта предоставляется "как есть" без каких-либо гарантий.

import-module adrmsadmin

New-PSDrive -Name MyRmsAdmin -PsProvider AdRmsAdmin -Root https://localhost -Force

$ListofTemplates=dir MyRmsAdmin:\RightsPolicyTemplate

foreach($Template in $ListofTemplates)
{
                $templateID=$Template.id

                $rights = dir MyRmsAdmin:\RightsPolicyTemplate\$Templateid\userright

     $templateName=$Template.DefaultDisplayName

        if ($rights.usergroupname -eq "anyone")

                         {
                           $templateName = $Template.defaultdisplayname

                           write-host "Template " -NoNewline

                           write-host -NoNewline $templateName -ForegroundColor Red

                           write-host " contains rights for " -NoNewline

                           write-host ANYONE  -ForegroundColor Red
                         }
 }
Remove-PSDrive MyRmsAdmin -force

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

Переходите к этапу 3 — настройка на стороне клиента.