Этап миграции 2. Конфигурация на стороне сервера для AD RMS

Статья
10/18/2023

Используйте следующие сведения для этапа 2 миграции из AD RMS в Azure Information Protection. Эти процедуры охватывают шаги 4, хотя 6 от миграции с AD RMS в Azure Information Protection.

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

Этот шаг представляет собой двухуровневый процесс:

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

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

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

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

Войдите в кластер AD RMS в качестве пользователя с разрешениями администрирования AD RMS.
В консоль управления AD RMS (службы Active Directory Rights Management) разверните имя кластера AD RMS, разверните политики доверия и щелкните "Доверенные домены публикации".
В области результатов выберите доверенный домен публикации, а затем в области "Действия" выберите пункт "Экспорт доверенного домена публикации".
В диалоговом окне "Экспорт доверенного домена публикации":
- Нажмите кнопку "Сохранить как" и сохраните путь и имя файла. Обязательно укажите XML в качестве расширения имени файла (это не добавляется автоматически).
- Укажите и подтвердите надежный пароль. Помните этот пароль, так как вам потребуется позже при импорте данных конфигурации в Azure Information Protection.
- Не выбирайте проверка box, чтобы сохранить доверенный файл домена в RMS версии 1.0.

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

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

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

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

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

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

Защита паролей в базе данных AD RMS. Это конфигурация по умолчанию.
Защита HSM с помощью модуля безопасности оборудования nCipher (HSM).
Защита HSM с помощью аппаратного модуля безопасности (HSM) от поставщика, отличного от nCipher.
Пароль, защищенный с помощью внешнего поставщика шифрования.

Примечание.

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

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

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

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

Если у вас есть защищенный HSM-ключ, который невозможно экспортировать, вы по-прежнему можете перейти в Azure Information Protection, настроив кластер AD RMS для режима только для чтения. В этом режиме ранее защищенный контент по-прежнему можно открыть, но только что защищенное содержимое использует новый ключ клиента, управляемый вами (BYOK) или управляемый корпорацией Майкрософт. Дополнительные сведения см. в разделе "Обновление" для Office для поддержки миграции с AD RMS в Azure RMS.

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

Примечание.

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

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

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

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

Подключение в службу Azure Rights Management и при появлении запроса укажите учетные данные глобального администратора:
```
Connect-AipService
```
Активируйте службу 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 использовали группу ANYONE , может потребоваться вручную добавить пользователей или группы.

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

Процедура при создании пользовательских шаблонов перед миграцией

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

Определите эти шаблоны и запишите его идентификатор шаблона, запустив Get-AipServiceTemplate.
Экспортируйте шаблоны с помощью командлета PowerShell Azure RMS, Export-AipServiceTemplate.
Импортируйте шаблоны с помощью командлета PowerShell Azure RMS Import-AipServiceTemplate.

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

Процедура, если шаблоны в AD RMS использовали группу ANYONE

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

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

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

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

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

Пример скрипта Windows PowerShell для идентификации шаблонов AD RMS, включающих группу ANYONE

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

Отказ от ответственности. Этот пример скрипта не поддерживается в любой стандартной программе поддержки или службе Майкрософт. Этот пример скрипта предоставляется "как есть" без каких-либо гарантий.

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 — конфигурация на стороне клиента.