Переход с AD RMS на службу Azure Information Protection
Используйте следующий набор инструкций для переноса развертывания службы Active Directory Rights Management (AD RMS) в Azure Information Protection.
После миграции серверы AD RMS больше не используются, но пользователи по-прежнему имеют доступ к документам и сообщениям электронной почты, защищенным вашей организацией с помощью AD RMS. Только что защищенное содержимое будет использовать службу Azure Rights Management (Azure RMS) из Azure Information Protection.
Рекомендуемое чтение перед миграцией в Azure Information Protection
Хотя и не требуется, вы можете ознакомиться со следующей документацией перед началом миграции. Эти знания позволяют лучше понять, как работает технология, когда она относится к шагу миграции.
Планирование и реализация ключа клиента Azure Information Protection. Ознакомьтесь с параметрами управления ключами, которые у вас есть для клиента Azure Information Protection, где ваш ключ SLC, эквивалентный в облаке, управляется корпорацией Майкрософт (по умолчанию) или управляется вами (конфигурация byOK или собственный ключ).
Обнаружение служб RMS. В этом разделе примечания к развертыванию клиента RMS объясняется, что порядок обнаружения служб — реестр, а затем точка подключения службы (SCP), а затем облако. Во время миграции при установке SCP клиенты настраиваются с параметрами реестра для клиента Azure Information Protection, чтобы они не использовали кластер AD RMS, возвращаемый из SCP.
Обзор соединителя Microsoft Rights Management. В этом разделе из документации по соединителю RMS объясняется, как локальные серверы могут подключаться к службе Azure Rights Management для защиты документов и сообщений электронной почты.
Кроме того, если вы не знакомы с тем, как работает AD RMS, вы можете узнать , как работает Azure RMS? Под капотом вы можете определить, какие технологические процессы совпадают или отличаются для облачной версии.
Предварительные требования для переноса AD RMS в Azure Information Protection
Прежде чем приступить к миграции в Azure Information Protection, убедитесь, что выполнены следующие предварительные требования и что вы понимаете какие-либо ограничения.
Поддерживаемое развертывание RMS:
Следующие выпуски AD RMS поддерживают миграцию в Azure Information Protection:
Windows Server 2012 (x64)
Windows Server 2012 R2 (x64)
Windows Server 2016 (x64)
Поддерживаются все допустимые топологии AD RMS:
Один лес, один кластер RMS
Один лес, несколько кластеров RMS только для лицензирования
Несколько лесов, несколько кластеров RMS
Примечание.
По умолчанию несколько кластеров AD RMS переносятся в один клиент для Azure Information Protection. Если вы хотите, чтобы отдельные клиенты для Azure Information Protection были разделены, их необходимо рассматривать как различные миграции. Ключ из одного кластера RMS нельзя импортировать в несколько клиентов.
Все требования к запуску Azure Information Protection, включая подписку на Azure Information Protection (служба Azure Rights Management не активируется):
См . требования к Azure Information Protection.
Клиент Azure Information Protection необходим для классификации и маркировки, а также необязательно, но рекомендуется, если требуется защитить только данные.
Дополнительные сведения см. в руководствах администратора для клиента унифицированных меток Azure Information Protection.
Несмотря на то что перед миграцией из AD RMS необходимо иметь подписку на Azure Information Protection, перед началом миграции рекомендуется не активировать службу Rights Management для вашего клиента.
Процесс миграции включает этот шаг активации после экспорта ключей и шаблонов из AD RMS и импортировал их в клиент для Azure Information Protection. Однако если служба Rights Management уже активирована, вы по-прежнему можете выполнить миграцию из AD RMS с помощью некоторых дополнительных действий.
Только Office 2010:
Если у вас есть компьютеры под управлением Office 2010, необходимо установить клиент Azure Information Protection, чтобы обеспечить возможность проверки подлинности пользователей в облачных службах.
Внимание
Расширенная поддержка Office 2010 закончилась 13 октября 2020 г. Дополнительные сведения см. в статье AIP и устаревшие версии Windows и Office.
Подготовка к Azure Information Protection:
Синхронизация каталогов между локальным каталогом и идентификатором Microsoft Entra
Группы с поддержкой почты в идентификаторе Microsoft Entra
См. статью " Подготовка пользователей и групп для Azure Information Protection".
Если вы использовали функции Управления правами на доступ к данным (IRM) Exchange Server (например, правила транспорта и Outlook Web Access) или SharePoint Server с AD RMS:
Запланируйте короткий период времени, когда IRM не будет доступен на этих серверах
После миграции можно продолжать использовать IRM на этих серверах. Однако одним из этапов миграции является временное отключение службы IRM, установка и настройка соединителя, перенастройка серверов и повторное включение IRM.
Это единственный перерыв в обслуживании во время процесса миграции.
Если вы хотите управлять собственным ключом клиента Azure Information Protection, используя защищенный HSM ключ:
- Для этой необязательной конфигурации требуется Azure Key Vault и подписка Azure, которая поддерживает Key Vault с ключами, защищенными HSM. Дополнительные сведения см. на странице цен на Azure Key Vault.
Рекомендации по режиму шифрования
Если кластер AD RMS в настоящее время находится в режиме шифрования 1, не обновите кластер до режима шифрования 2 перед началом миграции. Вместо этого миграция с помощью криптографического режима 1 можно повторно использовать ключ клиента в конце миграции в качестве одной из задач после миграции.
Чтобы подтвердить криптографический режим AD RMS для Windows Server 2012 R2 и Windows 2012: вкладка "Общие свойства >кластера AD RMS".
Ограничения миграции
Если у вас есть программное обеспечение и клиенты, которые не поддерживаются службой Rights Management, используемой Azure Information Protection, они не смогут защитить или использовать содержимое, защищенное Azure Rights Management. Обязательно проверка поддерживаемые приложения и клиенты из разделов "Требования к Azure Information Protection".
Если развертывание AD RMS настроено для совместной работы с внешними партнерами (например, с помощью доверенных доменов пользователей или федерации), они также должны перейти в Azure Information Protection одновременно с миграцией или как можно скорее после этого. Чтобы продолжить доступ к содержимому, ранее защищенному вашей организацией с помощью Azure Information Protection, они должны внести изменения конфигурации клиента, аналогичные внесенным вами, и включить в этот документ.
Из-за возможных вариантов конфигурации, которые могут быть у ваших партнеров, точные инструкции по этой перенастройки не область для этого документа. Однако ознакомьтесь со следующим разделом по планированию и дополнительной справке, обратитесь к служба поддержки Майкрософт.
Планирование миграции при совместной работе с внешними партнерами
Включите партнеров AD RMS в этап планирования миграции, так как они также должны перенестися в Azure Information Protection. Прежде чем выполнить любой из следующих шагов миграции, убедитесь, что на месте выполняется следующее:
У них есть клиент Microsoft Entra, поддерживающий службу Azure Rights Management.
Например, у них есть подписка На Office 365 E3 или E5, подписка Enterprise Mobility + Security или автономная подписка для Azure Information Protection.
Служба Azure Rights Management еще не активирована, но они знают URL-адрес службы Azure Rights Management.
Эти сведения можно получить, установив средство управления правами Azure, подключився к службе (Подключение-AipService), а затем просмотрите сведения о клиенте для службы Azure Rights Management (Get-AipServiceConfiguration).
Они предоставляют URL-адреса для кластера AD RMS и URL-адрес службы Azure Rights Management, чтобы настроить перенесенные клиенты для перенаправления запросов на защищенное содержимое AD RMS в службу Azure Rights Management клиента. Инструкции по настройке перенаправления клиента приведены на шаге 7.
Перед началом миграции пользователей они импортируют корневые ключи кластера AD RMS (SLC) в свой клиент. Аналогичным образом необходимо импортировать корневые ключи кластера AD RMS перед началом миграции пользователей. Инструкции по импорту ключа рассматриваются в этом процессе миграции, шаг 4. Экспортируйте данные конфигурации из AD RMS и импортируйте их в Azure Information Protection.
Общие сведения о шагах по переносу AD RMS в Azure Information Protection
Этапы миграции можно разделить на пять этапов, которые могут выполняться в разное время и разными администраторами.
Этап 1. Подготовка миграции
Дополнительные сведения см. в разделе "ЭТАП 1: ПОДГОТОВКА МИГРАЦИИ".
Шаг 1. Установка модуля PowerShell AIPService и определение URL-адреса клиента
Процесс миграции требует выполнения одного или нескольких командлетов PowerShell из модуля AIPService. Чтобы выполнить многие действия по миграции, необходимо знать URL-адрес службы Azure Rights Management клиента, и вы можете удостоверять это значение с помощью PowerShell.
Шаг 2. Подготовка к миграции клиента
Если вы не сможете перенести все клиенты одновременно и будете переносить их в пакетах, используйте элементы управления подключением и разверните скрипт предварительной миграции. Однако если вы будете переносить все одновременно, а не выполнять поэтапное миграцию, можно пропустить этот шаг.
Шаг 3. Подготовка развертывания Exchange для миграции
Этот шаг необходим, если в настоящее время используется функция IRM Exchange Online или Exchange для защиты сообщений электронной почты. Однако если вы будете переносить все одновременно, а не выполнять поэтапное миграцию, можно пропустить этот шаг.
Этап 2. Конфигурация на стороне сервера для AD RMS
Дополнительные сведения см. в РАЗДЕЛЕ "ЭТАП 2. КОНФИГУРАЦИЯ НА СТОРОНЕ СЕРВЕРА ДЛЯ AD RMS".
Шаг 4. Экспорт данных конфигурации из AD RMS и импорт его в Azure Information Protection
Вы экспортируете данные конфигурации (ключи, шаблоны, URL-адреса) из AD RMS в XML-файл, а затем отправляете этот файл в службу Azure Rights Management из Azure Information Protection с помощью командлета Import-AipServiceTpd PowerShell. Затем определите, какой импортированный сертификат лицензиара сервера (SLC) будет использоваться в качестве ключа клиента для службы Azure Rights Management. Дополнительные шаги могут потребоваться в зависимости от конфигурации ключа AD RMS:
Защищенный программным обеспечением ключ для миграции ключей, защищенных программным обеспечением:
Централизованное управление ключами на основе паролей в AD RMS для ключа клиента Azure Information Protection, управляемого корпорацией Майкрософт. Это самый простой путь миграции, и никаких дополнительных шагов не требуется.
Защищенный HSM ключ к миграции ключей, защищенных HSM:
Ключи, хранящиеся HSM для AD RMS, в ключ клиента Azure Information Protection, управляемый клиентом (сценарий "принести собственный ключ" или BYOK). Для этого необходимо выполнить дополнительные действия, чтобы передать ключ из локальной среды hSM nCipher HSM в Azure Key Vault и авторизовать службу Azure Rights Management для использования этого ключа. Существующий ключ, защищенный HSM, должен быть защищен модулем; Защищенные OCS ключи не поддерживаются службами Rights Management.
Защищенный программным обеспечением ключ для миграции ключей, защищенных HSM:
Централизованно управляемые ключи на основе паролей в AD RMS к ключу клиента Azure Information Protection, управляемому клиентом (сценарий "принести собственный ключ" или BYOK). Для этого требуется большая конфигурация, так как сначала необходимо извлечь ключ программного обеспечения и импортировать его в локальную среду HSM, а затем выполнить дополнительные действия, чтобы передать ключ из локальной среды nCipher HSM в HSM Azure Key Vault и авторизовать службу Azure Rights Management для использования хранилища ключей, в которой хранится ключ.
Шаг 5. Активация службы Azure Rights Management
Если это возможно, выполните этот шаг после процесса импорта и не раньше. Дополнительные шаги требуются, если служба была активирована перед импортом.
Шаг 6. Настройка импортированных шаблонов
При импорте шаблонов политик прав их состояние архивируется. Если вы хотите, чтобы пользователи могли видеть и использовать их, необходимо изменить состояние шаблона, которое будет опубликовано на классическом портале Azure.
Этап 3. Конфигурация на стороне клиента
Дополнительные сведения см. в разделе "ЭТАП 3: КОНФИГУРАЦИЯ НА СТОРОНЕ КЛИЕНТА".
Шаг 7. Перенастройка компьютеров Windows для использования Azure Information Protection
Существующие компьютеры Windows необходимо перенастроить для использования службы Azure Rights Management вместо AD RMS. Этот шаг применяется к компьютерам в организации, а также к компьютерам в партнерских организациях, если вы сотрудничали с ними во время работы AD RMS.
Этап 4. Поддержка конфигурации служб
Дополнительные сведения см. в РАЗДЕЛЕ "ЭТАП 4. ПОДДЕРЖКА КОНФИГУРАЦИИ СЛУЖБ".
Шаг 8. Настройка интеграции IRM для Exchange Online
На этом шаге выполняется миграция AD RMS для Exchange Online, чтобы теперь использовать службу Azure Rights Management.
Шаг 9. Настройка интеграции IRM для Exchange Server и SharePoint Server
Этот шаг завершает миграцию AD RMS для Exchange или SharePoint в локальной среде, чтобы использовать службу Azure Rights Management, которая требует развертывания соединителя Rights Management.
Этап 5. Задачи после миграции
Дополнительные сведения см. в разделе "ЭТАП 5: ЗАДАЧИ ПОСЛЕ МИГРАЦИИ".
Шаг 10. Отмена подготовки AD RMS
После подтверждения того, что все компьютеры Windows используют службу Azure Rights Management и больше не обращаются к серверам AD RMS, вы можете отменить развертывание AD RMS.
Шаг 11. Выполнение задач миграции клиента
Если вы развернули расширение мобильных устройств для поддержки мобильных устройств, таких как телефоны iOS и iPads, телефоны и планшеты Android, телефоны и планшеты Windows, а также компьютеры Mac, необходимо удалить записи SRV в DNS, которые перенаправили эти клиенты для использования AD RMS.
Элементы управления подключением, настроенные на этапе подготовки, больше не нужны. Однако если вы не использовали элементы управления подключением, так как вы решили перенести все одновременно, а не выполнить поэтапную миграцию, можно пропустить инструкции по удалению элементов управления подключением.
Если компьютеры с Windows работают под управлением Office 2010, проверка, нужно ли отключить задачу управления шаблонами политики прав AD RMS (автоматизировано).
Внимание
Расширенная поддержка Office 2010 закончилась 13 октября 2020 г. Дополнительные сведения см. в статье AIP и устаревшие версии Windows и Office.
Шаг 12. Повторное создание ключа клиента Azure Information Protection
Этот шаг рекомендуется, если вы не работали в режиме шифрования 2 перед миграцией.
Следующие шаги
Чтобы начать миграцию, перейдите на этап 1 — подготовка.