Использование собственных ключей (BYOK) для Azure Information Protection

Примечание

Ищете Information Protection Microsoft Purview, ранее Microsoft informācijas aizsardzība (MIP)?

Клиент унифицированных меток Azure Information Protection теперь находится в режиме обслуживания. Мы рекомендуем использовать метки, встроенные в приложения и службы Office 365. Mer informasjon

Организации с подпиской 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 密钥保管库

Ключи, созданные клиентом, должны храниться в Azure 密钥保管库 для защиты BYOK.

Примечание

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

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

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

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

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

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

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

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

Преимущества использования хранилища ключей Azure

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

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

Хранение ключа клиента в Azure 密钥保管库 обеспечивает следующие преимущества:

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

Другие службы и средства интегрированы с 密钥保管库 для оптимизированных возможностей для конкретных задач, таких как мониторинг.

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

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

Дополнительные сведения см. на странице Доступность продуктов по регионам на сайте Azure.
Разделенные домены безопасности Azure 密钥保管库 использует отдельные домены безопасности для своих центров обработки данных в таких регионах, как 北米, EMEA (Европа, Ближний Восток и Африка) и Азия.

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

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

Последние обновления и сведения о том, как другие службы используют Azure 密钥保管库, см. в блоге команды 密钥保管库 Azure.

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

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

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

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

Совет

Для дополнительной гарантии ведение журнала использования Information Protection Azure можно перекрестно ссылаться на журнал azure 密钥保管库. 密钥保管库 журналы предоставляют надежный метод для независимого мониторинга того, что ключ используется только службой Azure Rights Management.

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

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

Примечание

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

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

BYOK поддерживает ключи, созданные в Azure 密钥保管库 или локальной среде.

При создании ключа в локальной среде необходимо передать или импортировать его в 密钥保管库 и настроить Azure Information Protection для использования ключа. Выполните любое дополнительное управление ключами из 密钥保管库 Azure.

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

  • Создано в Azure 密钥保管库. Создайте и сохраните ключ в Azure 密钥保管库 как ключ, защищенный устройством HSM, или ключ, защищенный программным обеспечением.

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

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

      Хотя этот метод имеет большую административную нагрузку, для вашей организации может потребоваться соблюдать определенные правила. Модули HSM, используемые Azure 密钥保管库, проверяются на уровне 2 FIPS 140-2.

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

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

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

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

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

После передачи копия ключа защищена 密钥保管库 Azure.

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

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

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

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

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

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

  1. Проверка предварительных требований BYOK
  2. Выбор расположения 密钥保管库
  3. Создание и настройка ключа

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

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

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

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

Клиент Azure Information Protection должен иметь подписку Azure. Если у вас еще нет учетной записи, вы можете зарегистрироваться для получения бесплатной учетной записи. Однако для использования ключа, защищенного HSM, необходимо иметь уровень служб Azure 密钥保管库 уровня "Премиум".

Бесплатная подписка Azure, которая предоставляет доступ к конфигурации Azure Active Directory и настраиваемой конфигурации шаблона Azure Rights Management, недостаточно для использования Azure 密钥保管库.

Чтобы убедиться, что у вас есть подписка 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, используйте командлет PowerShell Get-AipServiceConfiguration и определите регион из 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 и ключ, который вы хотите использовать для Information Protection Azure. Дополнительные сведения см. в документации по Azure Key Vault.

Обратите внимание на следующее, чтобы настроить 密钥保管库 Azure и ключ для BYOK:

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

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

Примечание

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

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

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

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

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

  • encrypt
  • расшифровка
  • wrapKey
  • unwrapKey
  • sign
  • проверка

По умолчанию разрешены все операции 密钥保管库.

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

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

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

Настройка azure Information Protection с помощью идентификатора ключа

Ключи, хранящиеся в Azure 密钥保管库 имеют идентификатор ключа.

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

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

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

Служба Azure Rights Management должна быть авторизована для использования ключа. Администраторы 密钥保管库 Azure могут включить эту авторизацию с помощью Azure-Portal или Azure PowerShell.

Включение авторизации ключа с помощью Azure-Portal
  1. Войдите в Azure-Portal и перейдите в хранилища ключей, в которые >< добавлены политики доступа кхранилищу>>ключей>.

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

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

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

Запустите командлет PowerShell 密钥保管库 Set-AzKeyVaultAccessPolicy и предоставьте разрешения субъекту-службе Azure Rights Management с помощью GUID 00000012-0000-0000-c000-0000000000000000.

Пример:

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, чтобы отобразить URL-адрес ключа.

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

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

Дальнейшие шаги

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