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

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

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

Ведение журнала BYOK и ведения журнала использования легко работают с приложениями, которые интегрируются со службой Azure Rights Management, используемой Защита информации Microsoft Purview.

Поддерживаемые приложения:

• Облачные службы, такие как Microsoft SharePoint или Microsoft 365

• Локальные службы под управлением приложений Exchange и SharePoint, которые используют службу Azure Rights Management с помощью соединителя Rights Management

• Клиентские приложения, такие как Office 2024 и Office 2021.

хранилище ключей Azure Key Vault

Ключи, созданные клиентом, должны храниться в Azure Key Vault для BYOK.

Совместное использование хранилищ ключей и подписок

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

Так как разные службы имеют различные требования к управлению ключами, корпорация Майкрософт также рекомендует использовать выделенную подписку Azure для хранилища ключей по следующим причинам:

• Защита от неправильной конфигурации

• Более безопасный, если разные службы имеют разных администраторов

Чтобы предоставить общий доступ к подписке на Azure другим службам, которые используют Azure Key Vault, убедитесь, что она использует общий набор администраторов. Убедитесь, что все администраторы, использующие подписку, имеют полное представление о каждом ключе, которыми они могут управлять. Администраторы с таким уровнем понимания с меньшей вероятностью неправильно настроят ваши ключи.

Пример. Используйте общую подписку Azure, если администраторы ключа клиента Azure Rights Management являются теми же пользователями, которые администрируют ваши ключи для ключа клиента Microsoft Purview и Dynamics 365 Online. Если ключевые администраторы этих служб отличаются, рекомендуется использовать выделенные подписки.

Преимущества использования Azure Key Vault

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

Помимо управления ключами, Azure Key Vault предлагает администраторам безопасности тот же интерфейс управления для хранения, доступа к сертификатам и секретам (например, паролей) и управления ими для других служб и приложений, использующих шифрование.

Хранение ключа клиента в Azure Key Vault обеспечивает следующие преимущества:

Последние обновления и сведения о том, как другие службы используют Azure Key Vault, см. в блоге команды Azure Key Vault.

Ведение журнала использования для BYOK

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

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

Дополнительные сведения о ведении журнала использования ключей для BYOK см. в разделе Ведение журнала использования для службы Azure Rights Management.

Варианты создания и хранения ключа

BYOK поддерживает ключи, созданные в Azure Key Vault или локальной среде.

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

Параметры для создания и хранения собственного ключа:

• Создано локально. Создайте ключ в локальной среде и перенесите его в Azure Key Vault с помощью одного из следующих вариантов:

  • Ключ, защищенный HSM, передается как ключ, защищенный HSM. Наиболее типичный выбранный метод.

    Хотя этот метод имеет наибольшие административные издержки, может потребоваться, чтобы ваша организация соблюдала определенные правила. Модули HSM, используемые Azure Key Vault, прошли проверку FIPS 140.

  • Ключ, защищенный программным обеспечением, который преобразуется и передается в Azure Key Vault как ключ, защищенный устройством HSM. Этот метод поддерживается только при миграции из служб Active Directory Rights Management Services (AD RMS).

  • Создан локально в качестве защищенного программного ключа и передан в Azure Key Vault в качестве ключа, защищенного программным обеспечением. Для этого метода требуется . PFX-файл сертификата.

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

1. Создайте ключ клиента в локальной среде в соответствии с политиками ИТ и безопасности вашей организации. Этот ключ является master копией. Он остается локальным, и вы отвечаете за его резервное копирование.

2. Создайте копию ключа master и безопасно перенесите ее из модуля HSM в Azure Key Vault. На протяжении всего этого процесса master копия ключа никогда не покидает границу аппаратной защиты.

После передачи копия ключа защищена Azure Key Vault.

• Создано в Azure Key Vault. Создайте и сохраните ключ в Azure Key Vault в виде ключа, защищенного HSM, или ключа, защищенного программным обеспечением.

  Важно!

  Ключи, созданные непосредственно в Azure Key Vault, нельзя экспортировать для использования за пределами Azure Key Vault. Большинство организаций, использующих BYOK, имеют требования к соответствию, которые требуют, чтобы они поддерживали собственную копию ключа за пределами Azure Key Vault. Не создавайте ключ непосредственно в Azure Key Vault. Вместо этого создайте ключ в локальной среде и передайте его в Azure Key Vault.

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

Экспорт доверенного домена публикации

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

Однако экспорт TPD не поддерживается, если вы используете BYOK для ключа клиента Azure Rights Management.

Чтобы подготовиться к этому сценарию, заранее создайте подходящий TPD. Дополнительные сведения см. в статье Подготовка Azure Information Protection плана "Выход из облака".

Реализация BYOK для ключа клиента Azure Rights Management

Чтобы реализовать BYOK, выполните следующие действия.

1. Ознакомьтесь с предварительными условиями BYOK
2. Выбор расположения хранилища ключей
3. Создание и настройка ключа

Предварительные требования для BYOK

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

Проверка наличия подписки на Azure, совместимую с BYOK

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

Бесплатная подписка Azure, предоставляющая доступ к Microsoft Entra конфигурации, недостаточно для использования Azure Key Vault.

Чтобы убедиться, что у вас есть подписка на Azure, совместимая с BYOK, выполните следующие действия для проверки с помощью командлетов Azure PowerShell:

1. Запустите сеанс Azure PowerShell от имени администратора.

2. Запустите Connect-AzAccount и войдите с ролью, которая может получить доступ к ресурсам в Azure Key Vault.

3. Выполните Get-AzSubscription команду, чтобы убедиться, что отображаются следующие значения:

   • Имя и идентификатор подписки
   • Идентификатор клиента для службы Azure Rights Management
   • Подтверждение включения состояния

   Если значения не отображаются и вы вернелись в запрос, у вас нет подписки на Azure, которую можно использовать для BYOK.

4. Убедитесь, что вы можете использовать уровень Azure Key Vault Premium, необходимый для ключей, защищенных устройством HSM. Если у вас есть хранилище ключей, выполните следующую команду, чтобы проверка его номер SKU:

   Get-AzKeyVault -VaultName "YourVaultName" | Select-Object VaultName, Sku
   

   Значение SKU должно иметь значение Premium для ключей, защищенных устройством HSM. Если вы создаете новое хранилище ключей, обязательно выберите уровень "Премиум" во время создания. Сведения о ценах см. в разделе цены Azure Key Vault.

Выбор расположения хранилища ключей

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

Сначала сделайте свой выбор для соответствия требованиям, а затем, чтобы свести к минимуму задержку в сети:

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

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

Чтобы определить расположение клиента, использующего службу Azure Rights Management, используйте командлет PowerShell Get-AipServiceConfiguration и определите регион из URL-адресов. Например, вы можете:

LicensingIntranetDistributionPointUrl : https://5c6bb73b-1038-4eec-863d-49bded473437.rms.na.aadrm.com/_wmcs/licensing

Регион можно определить из rms.na.aadrm.com, и в этом примере он находится в Северная Америка.

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

Создание и настройка ключа

Создайте Azure Key Vault и ключ, который вы хотите использовать для службы Azure Rights Management. Дополнительные сведения см. в документации по Azure Key Vault.

Обратите внимание на следующее для настройки Azure Key Vault и ключа для BYOK:

• Требования к длине ключа
• Создание защищенного модуля HSM ключа в локальной среде и его передача в хранилище ключей
• Настройка службы Azure Rights Management для идентификатора ключа
• Авторизация Azure Rights Management для использования ключа

Требования к длине ключа

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

Создание защищенного модуля HSM ключа в локальной среде и его передача в хранилище ключей

Чтобы создать защищенный HSM ключ в локальной среде и передать его в хранилище ключей в качестве ключа, защищенного HSM, следуйте инструкциям в документации по Azure Key Vault: Создание и передача ключей, защищенных HSM, для Azure Key Vault.

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

• Получить
• Расшифровать
• Знак

Чтобы проверка разрешенные операции для определенного ключа, выполните следующую команду PowerShell:

(Get-AzKeyVaultKey -VaultName <key vault name> -Name <key name>).Attributes.KeyOps

Настройка службы Azure Rights Management для идентификатора ключа

Ключи, хранящиеся в Azure Key Vault, имеют идентификатор ключа.

Идентификатор ключа — это URL-адрес, содержащий имя хранилища ключей, контейнер ключей, имя ключа и версию ключа. Пример: https://contosorms-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333

Настройте службу Azure Rights Management для использования ключа, указав URL-адрес хранилища ключей.

Авторизация Azure Rights Management для использования ключа

Служба Azure Rights Management должна быть авторизована на использование ключа через Azure RBAC. Для этого необходимо создать пользовательскую роль с необходимыми разрешениями и назначить ее субъекту-службе Rights Management.

Включение авторизации ключа с помощью интерфейса командной строки Azure

1. Войдите в Azure CLI и получите идентификатор подписки хранилища ключей:

   az login
   az keyvault show --name <vault-name> --resource-group <resource-group-name> --query "id" -o tsv
   

   Выходные данные содержат идентификатор подписки в формате: /subscriptions/<subscription-id>/resourceGroups/...

2. Создайте JSON-файл PurviewRMSCustomAKVRole.json со следующим содержимым, заменив <subscription-id> идентификатором подписки из предыдущего шага:

   {
     "Name": "Purview Rights Management key vault Encryption User",
     "IsCustom": true,
     "Description": "Grants access to use key vault keys for the Purview Rights Management service.",
     "Actions": [],
     "NotActions": [],
     "DataActions": [
       "Microsoft.KeyVault/vaults/keys/read",
       "Microsoft.KeyVault/vaults/keys/sign/action",
       "Microsoft.KeyVault/vaults/keys/decrypt/action"
     ],
     "NotDataActions": [],
     "AssignableScopes": [
       "/subscriptions/<subscription-id>"
     ]
   }
   

3. Создайте пользовательское определение роли, изменив путь к файлу определения роли при необходимости:

   az role definition create --role-definition "./PurviewRMSCustomAKVRole.json"
   

   Примечание.

   Выполните эту команду из каталога, в котором вы сохранили PurviewRMSCustomAKVRole.json, или замените ./PurviewRMSCustomAKVRole.json полным путем к файлу.

4. Получите идентификатор ресурса хранилища ключей и назначьте роль субъекту-службе Rights Management одной командой:

   az role assignment create --role "Purview Rights Management key vault Encryption User" --assignee "00000012-0000-0000-c000-000000000000" --scope $(az keyvault show --name <vault-name> --resource-group <resource-group-name> --query "id" -o tsv)
   

Включение авторизации ключа с помощью Azure PowerShell

1. Войдите в Azure PowerShell и получите идентификатор подписки хранилища ключей:

   Connect-AzAccount
   
   # Define your key vault and resource group names
   $vaultName = "<vault-name>"
   $resourceGroupName = "<resource-group-name>"
   
   # Get the key vault resource ID and subscription ID
   $keyVault = Get-AzKeyVault -VaultName $vaultName -ResourceGroupName $resourceGroupName
   $resourceId = $keyVault.ResourceId
   $subscriptionId = ($resourceId -split "/")[2]
   
   # Create the custom role definition JSON file
   $jsonRoleDefinition = @"
   {
     "Name": "Purview Rights Management key vault Encryption User",
     "IsCustom": true,
     "Description": "Grants access to use key vault keys for the Purview Rights Management service.",
     "Actions": [],
     "NotActions": [],
     "DataActions": [
       "Microsoft.KeyVault/vaults/keys/read",
       "Microsoft.KeyVault/vaults/keys/sign/action",
       "Microsoft.KeyVault/vaults/keys/decrypt/action"
     ],
     "NotDataActions": [],
     "AssignableScopes": [
       "/subscriptions/$($subscriptionId)"
     ]
   }
   "@
   
   $jsonRoleDefinition | Out-File -FilePath "./PurviewRMSCustomAKVRole.json"
   
   # Create the custom role definition
   New-AzRoleDefinition -InputFile "./PurviewRMSCustomAKVRole.json"
   
   # Assign the role to the Rights Management service principal
   New-AzRoleAssignment -RoleDefinitionName "Purview Rights Management key vault Encryption User" -ServicePrincipalName "00000012-0000-0000-c000-000000000000" -Scope $resourceId
   

Включение авторизации ключа для ключей управляемого модуля HSM с помощью интерфейса командной строки Azure

Чтобы предоставить пользователю субъекта-службы Azure Rights Management разрешения в качестве пользователя Управляемого шифрования HSM, выполните следующую команду:

az keyvault role assignment create --hsm-name "ContosoMHSM" --role "Managed HSM Crypto User" --assignee-principal-type ServicePrincipal --assignee https://aadrm.com/ --scope /keys/contosomhskey

Где:

• ContosoMHSM — это пример имени HSM. При выполнении этой команды замените это значение собственным именем HSM.

Роль пользователя Управляемого пользователя шифрования HSM позволяет пользователю расшифровывать, подписывать и получать разрешения на ключ, необходимые для работы с управляемым устройством HSM.

Настройка службы Azure Rights Management для использования ключа

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

Сначала скопируйте URL-адрес ключа из Azure Key Vault, включая версию ключа. Его можно получить с помощью Azure CLI или PowerShell:

Azure CLI:

az keyvault key show --vault-name <vault-name> --name <key-name> --query "key.kid" -o tsv

Azure PowerShell:

(Get-AzKeyVaultKey -VaultName "<vault-name>" -Name "<key-name>").Id

Настройка нового ключа BYOK

Если это новый ключ, выполните следующие действия, чтобы настроить службу Azure Rights Management.

1. Установите и импортируйте модуль PowerShell AIPService, если вы еще не выполнили следующие действия:

   Примечание.

   Модуль AIPService работает только в Windows PowerShell 5.1. Она несовместима с PowerShell 7 или другими современными версиями. Запуститеpowershell.exe, чтобы открыть Windows PowerShell.

   Install-Module -Name AIPService
   Import-Module -Name AIPService
   

2. Подключитесь к службе Azure Rights Management:

   Connect-AipService
   

3. Выполните командлет Use-AipServiceKeyVaultKey, указав URL-адрес ключа:

   Use-AipServiceKeyVaultKey -KeyVaultKeyUrl "https://contosorms-kv.vault.azure.net/keys/contosorms-byok/<key-version>"
   

   Важно!

   В этом примере — это версия ключа, <key-version> которую вы хотите использовать. Необходимо указать версию ключа. Если ключ будет обновлен или обновлен позже, служба Azure Rights Management перестанет работать для вашего клиента, если вы не обновите конфигурацию с помощью новой версии ключа.

4. Выведите список ключей, настроенных для клиента для получения идентификатора нового ключа с помощью Get-AipServiceKeys. Найдите ключ с соответствующим KeyVaultKeyUrl. Скопируйте значение KeyIdentifier:

   Get-AipServiceKeys | Select-Object KeyIdentifier, KeyVaultKeyUrl
   

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

   Set-AipServiceKeyProperties -KeyIdentifier <key-id-from-previous-step> -Active $true
   

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

Переход с Azure Key Vault hsmPlatform 1 на hsmPlatform 2

Azure Key Vault hsmPlatform 1 прекращается. Дополнительные сведения об этом прекращении использования см. в разделе объявление о прекращении Azure Key Vault hsmPlatform 1.

Если ключ клиента Azure Rights Management хранится в хранилище ключей hsmPlatform 1, необходимо перейти на hsmPlatform 2, чтобы продолжить использование BYOK.

Определите, находится ли ключ в hsmPlatform 1

Сначала определите, находится ли существующий ключ Rights Management в hsmPlatform 1:

Использование интерфейса командной строки Azure:

az keyvault key show --vault-name <vault-name> --name <key-name> --query "attributes.hsmPlatform" -o tsv

Использование Azure PowerShell:

(Get-AzKeyVaultKey -VaultName "<vault-name>" -Name "<key-name>").Attributes.HsmPlatform

• hsmPlatform Если значение равно 1, ключ находится в hsmPlatform 1 и требует миграции.
• hsmPlatform Если значение равно 2 или выше, ключ уже находится на hsmPlatform 2 и никаких действий не требуется.

Этапы миграции ключей в hsmPlatform 1

Если ключ находится в hsmPlatform 1, выполните следующие действия для миграции:

Шаг 1. Поиск локального модуля HSM

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

Шаг 2. Создание хранилища ключей hsmPlatform 2

Создайте новый Azure Key Vault, использующий hsmPlatform 2. В созданных сегодня хранилищах ключей автоматически используется hsmPlatform 2. Убедитесь, что вы:

• Выберите уровень "Премиум" для ключей, защищенных устройством HSM.
• Включите обратимое удаление и защиту от очистки.
• Выберите расположение, которое сокращает задержку в сети, как описано в разделе Выбор расположения хранилища ключей.

Шаг 3. Импорт ключа из локального модуля HSM

Выполните процесс миграции HSM, чтобы импортировать ключ из локального модуля HSM в новую Azure Key Vault. Подробные инструкции см. в статье Создание и передача ключей, защищенных HSM, для Azure Key Vault.

Шаг 4. Проверка соответствия открытых ключей

Перед обновлением конфигурации службы Rights Management убедитесь, что открытые ключи совпадают во всех расположениях:

1. Получите открытый ключ из нового хранилища ключей:

   Использование интерфейса командной строки Azure:

   az keyvault key show --vault-name <new-vault-name> --name <key-name> --query "key.n" -o tsv
   

   Использование Azure PowerShell:

   Get-AzKeyVaultKey -VaultName "<new-vault-name>" -Name "<key-name>" | Format-List Key
   

Просмотрите значение n из выходных данных, представляющее модуль открытого ключа.

1. Получите открытый ключ из службы Rights Management:

   Connect-AipService
   Get-AipServiceKeys | Select-Object KeyIdentifier, PublicKey
   

2. Сравните с локальной копией HSM с помощью инструментов поставщика HSM для экспорта или отображения открытого ключа. Если вам не удается найти сведения о открытом ключе, обратитесь к поставщику HSM. служба поддержки Майкрософт не может помочь с операциями, зависящими от HSM.

Все три открытых ключа должны точно соответствовать. Если они не совпадают, убедитесь, что вы импортируете правильный ключ из модуля HSM.

Шаг 5. Настройка управления доступом в новом хранилище ключей

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

Шаг 6. Обновление службы Rights Management для использования нового хранилища ключей

Выполните команду Convert-AipServiceKeyToKeyVault , чтобы обновить URL-адрес ключа в новом хранилище:

Connect-AipService
Convert-AipServiceKeyToKeyVault -KeyIdentifier <existing-key-id> -KeyVaultKeyUrl "https://<new-vault-name>.vault.azure.net/keys/<key-name>/<key-version>"

Моя организация потеряла доступ к исходному материалу ключа

Если у вас больше нет доступа к исходному локальному устройству HSM или материалу ключа, используемому для создания ключа BYOK, необходимо создать новый ключ:

1. Создайте новый ключ , следуя инструкциям из раздела Создание и настройка ключа.

2. Настройте управление доступом, как описано в разделе Авторизация службы Azure Rights Management для использования ключа.

3. Задайте новый ключ как активный:

   Connect-AipService
   Use-AipServiceKeyVaultKey -KeyVaultKeyUrl "https://<vault-name>.vault.azure.net/keys/<key-name>/<key-version>"
   Set-AipServiceKeyProperties -KeyIdentifier <new-key-id> -Active $true
   

4. Обратитесь в службу поддержки Microsoft Purview, чтобы обсудить дальнейшие действия для содержимого, защищенного с помощью предыдущего ключа. Перейдите по адресу Центр администрирования Microsoft 365 и отправьте запрос на обслуживание или обратитесь к представителю службы поддержки Майкрософт. Дополнительные сведения см. в разделе Получение поддержки Microsoft 365 для бизнеса.

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

Если вы еще не активировали службу Rights Management, выполните это действие.

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

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