Получение сведений о собственном ключе (BYOK) для Azure Information Protection

  • Статья

Примечание.

Ищете информацию о Microsoft Purview Information Protection (прежнее название — Microsoft Information Protection, MIP)?

Надстройка Azure Information Protection отменяется и заменяется метками, встроенными в приложения и службы Microsoft 365. Дополнительные сведения о состоянии поддержки других компонентов Azure Information Protection.

Новый клиент Защита информации Microsoft Purview (без надстройки) в настоящее время находится в предварительной версии и планируется для общедоступной доступности.

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

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

К поддерживаемым приложениям относятся:

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

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

  • Клиентские приложения, такие как Office 2019, Office 2016 и Office 2013

Совет

При необходимости примените дополнительную безопасность к определенным документам с помощью дополнительного локального ключа. Дополнительные сведения см. в разделе " Шифрование двойного ключа" (DKE) (только клиент унифицированных меток).

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

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

Примечание.

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

Общий доступ к хранилищам ключей и подпискам

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

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

  • Защита от неправильной настройки

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

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

Пример. Использование общей подписки Azure, когда администраторы для ключа клиента Azure Information Protection являются теми же лицами, которые администрируют ключи для ключа клиента Office 365 и CRM online. Если администраторы ключей для этих служб отличаются, рекомендуется использовать выделенные подписки.

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

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

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

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

Преимущество Description
Встроенные интерфейсы Azure Key Vault поддерживает ряд встроенных интерфейсов для управления ключами, включая PowerShell, CLI, REST API и портал Azure.

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

Например, анализ журналов использования ключей с помощью Operations Management Suite Log analytics, задания оповещений при выполнении указанных условий и т. д.
Разделение ролей Azure Key Vault обеспечивает разделение ролей как признанную рекомендацию по обеспечению безопасности.

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

Дополнительные сведения см. на странице "Продукты по регионам " на сайте Azure.
Разделенные домены безопасности Azure Key Vault использует отдельные домены безопасности для своих центров обработки данных в таких регионах, как Северная Америка, EMEA (Европа, Ближний Восток и Африка) и Азия.

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

Использование Azure Key Vault для ключей клиента обеспечивает простой пользовательский интерфейс для администраторов, которые управляют всеми этими элементами.

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

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

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

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

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

Совет

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

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

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

Примечание.

Дополнительные сведения о предложении управляемого устройства HSM и настройке хранилища и ключа см. в документации по Azure Key Vault.

Ниже описаны дополнительные инструкции по предоставлению авторизации ключа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требование Description
Подписка Azure Требуется для всех конфигураций.
Дополнительные сведения см. в статье "Проверка наличия подписки Azure, совместимой с BYOK".
Модуль AIPService PowerShell для Azure Information Protection Требуется для всех конфигураций.
Дополнительные сведения см. в разделе "Установка модуля AIPService PowerShell".
Предварительные требования к Azure Key Vault для BYOK Если вы используете защищенный локальным ключом HSM, убедитесь, что вы также соответствуете предварительным требованиям для BYOK , перечисленным в документации по Azure Key Vault.
Встроенное ПО Thales версии 11.62 Если вы переносите AD RMS из AD RMS в Azure Information Protection с помощью ключа программного обеспечения на аппаратный ключ и используете встроенное ПО Thales для HSM, необходимо иметь версию встроенного ПО Thales версии 11.62.
Обход брандмауэра для доверенного службы Майкрософт Если хранилище ключей, содержащее ключ клиента, использует конечные точки службы виртуальная сеть для Azure Key Vault, необходимо разрешить доверенным службы Майкрософт обойти этот брандмауэр.
Дополнительные сведения см. в разделе виртуальная сеть Конечные точки службы для Azure Key Vault.

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

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

Бесплатная подписка Azure, которая предоставляет доступ к конфигурации Microsoft Entra и настраиваемой конфигурации шаблона Azure Rights Management, недостаточно для использования Azure Key Vault.

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

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

  2. Войдите в качестве глобального администратора для клиента Azure Information Protection с помощью Connect-AzAccount.

  3. Скопируйте маркер, отображаемый в буфер обмена. Затем в браузере перейдите https://microsoft.com/devicelogin и введите скопированный маркер.

    Дополнительные сведения см. в статье Вход с помощью Azure PowerShell.

  4. В сеансе PowerShell введите Get-AzSubscriptionи убедитесь, что отображаются следующие значения:

    • Имя и идентификатор подписки
    • Идентификатор клиента Azure Information Protection
    • Подтверждение включения состояния

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

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

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

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

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

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

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

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

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

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

Регион Или экземпляр Azure Рекомендуемое расположение для хранилища ключей
Rms.na.aadrm.com Северная часть США или восточная часть США
Rms.eu.aadrm.com Северная Европа или Западная Европа
Rms.ap.aadrm.com Восточная Азия или Юго-Восточная Азия
Rms.sa.aadrm.com Западная часть США или восточная часть США
Rms.govus.aadrm.com Центральная часть США или восточная часть США 2
Rms.aadrm.us US Gov Вирджиния или US Gov Аризона
Rms.aadrm.cn Восточная часть Китая 2 или Северная Китай 2

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

Внимание

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

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

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

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

При создании ключа убедитесь, что длина ключа — 2048 бит (рекомендуется) или 1024 бита. Другие длины ключей не поддерживаются Azure Information Protection.

Примечание.

1024-разрядные ключи не считаются достаточным уровнем защиты для активных ключей клиента.

Корпорация Майкрософт не поддерживает использование более низких длин ключей, таких как 1024-разрядные ключи RSA, и связанное использование протоколов, которые предлагают неадекватный уровень защиты, например SHA-1.

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

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

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

  • шифрование
  • decrypt
  • wrapKey
  • unwrapKey
  • sign
  • verify

По умолчанию разрешены все операции Key Vault.

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

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

При необходимости добавьте разрешенные операции с помощью Update-AzKeyVaultKey и параметра KeyOps .

Настройка Azure Information Protection с идентификатором ключа

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

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

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

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

Служба Azure Rights Management должна быть авторизована для использования ключа. Администраторы Azure Key Vault могут включить эту авторизацию с помощью портал Azure или Azure PowerShell.

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

  1. Войдите в портал Azure и перейдите в хранилища ключей, включив ><политики> доступа к хранилищу>>ключей.

  2. В области "Добавление политики доступа" в списке "Настройка" (необязательно) выберите Azure Information Protection BYOK и нажмите кнопку "ОК".

    Выбранный шаблон имеет следующую конфигурацию:

    • Для параметра Select principal задано значение Microsoft Rights Management Services.
    • К выбранным разрешениям ключа относятся Get, Decrypt и Sign.
Включение авторизации ключей с помощью PowerShell

Запустите командлет PowerShell Key Vault, Set-AzKeyVaultAccessPolicy и предоставьте разрешения субъекту-службе Azure Rights Management с помощью GUID 00000012-0000-0000-c0000-000000000000.

Например:

Set-AzKeyVaultAccessPolicy -VaultName 'ContosoRMS-kv' -ResourceGroupName 'ContosoRMS-byok-rg' -ServicePrincipalName 00000012-0000-0000-c000-000000000000 -PermissionsToKeys decrypt,sign,get
Включение авторизации ключей для управляемых ключей HSM с помощью Azure CLI

Чтобы предоставить субъекту-службе 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 Information Protection для использования ключа

Завершив все описанные выше действия, вы можете настроить Azure Information Protection для использования этого ключа в качестве ключа клиента вашей организации.

С помощью командлетов Azure RMS выполните следующие команды:

  1. Подключение в службу Azure Rights Management и выполните вход:

    Connect-AipService

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

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

    Внимание

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

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

    Например: Get-AzKeyVaultKey -VaultName 'contosorms-kv' -KeyName 'contosorms-byok'

    Чтобы убедиться, что URL-адрес ключа задан правильно для Azure Information Protection, выполните команду Get-AzKeyVaultKey в Azure Key Vault, чтобы отобразить URL-адрес ключа.

  3. Если служба Azure Rights Management уже активирована, запустите Set-AipServiceKeyProperties , чтобы сообщить Azure Information Protection использовать этот ключ в качестве активного ключа клиента для службы Azure Rights Management.

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

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

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