Сведения о личных ключах (BYOK) для Azure Information Protection

Область применения: Azure Information Protection, Office 365

К чему относится: клиент унифицированных меток и классический клиент AIP

Примечание

Для унификации и улучшения работы пользователей поддержка классического клиента Azure Information Protection и клиента управления метками на портале Azure прекращается с 31 марта 2021 г. Хотя классический клиент продолжит работать, дальнейшая поддержка предоставляться не будет и версии для обслуживания классического клиента больше не будут выпускаться.

Рекомендуется перейти на унифицированные метки и выполнить обновление до клиента унифицированных меток. Дополнительные сведения см. в недавней записи блога о прекращении использования.

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

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

В число поддерживаемых приложений входят:

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

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

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

Совет

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

Если у вас есть классический клиент и требуется дополнительная Локальная защита, реализуйте вместо него защиту собственного ключа (HYOK) .

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

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

Примечание

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

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

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

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

  • Защита от непредусмотренных конфигураций

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

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

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

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

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

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

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

Преимущество Описание
Встроенные интерфейсы Хранилище ключей Azure поддерживает ряд встроенных интерфейсов для управления ключами, включая 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 — Германия и Microsoft Azure для государственных организаций.
Унифицированное взаимодействие с пользователем. Azure Key Vault также позволяет администраторам безопасности хранить, получать доступ и управлять сертификатами и секретами, такими как пароли, для других служб, использующих шифрование.

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

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

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

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

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

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

Совет

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

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

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

Примечание

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

Дополнительные сведения об управляемом предложении 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, используемый Azure Key Vault, — проверка FIPS 140-2 уровня 2.

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

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

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

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

  2. Создайте копию главного ключа и безопасно перенесите ее из АППАРАТного модуля безопасности в 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 зависят от конфигурации системы. Убедитесь, что система соответствует следующим необходимым требованиям:

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

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

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

Бесплатная подписка Azure, которая предоставляет доступ к конфигурации Azure Active Directory и конфигурации настраиваемого шаблона 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 Key для обеспечения соответствия требованиям, эти требования к соответствию могут также указывать, какой регион или экземпляр Azure можно использовать для хранения ключа клиента Azure Information Protection.

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

Чтобы указать расположение клиента Azure Information Protection, используйте командлет PowerShell Get-аипсервицеконфигуратион и укажите регион из 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.

Создание ключа, защищенного АППАРАТным модулем безопасности, в локальной среде и его передача в хранилище ключей

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

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

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

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

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

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

При необходимости добавьте разрешенные операции с помощью командлета Update-азкэйваулткэй и параметра кэйопс .

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

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

Идентификатор ключа — это URL-адрес, содержащий имя хранилища ключей, контейнер ключей, имя ключа и версию ключа. Пример:

https://contosorms-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333.

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

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

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

Включение авторизации ключа с помощью портал Azure
  1. Войдите в портал Azure и перейдите к разделу > <your key vault name> > политики доступа к хранилищам ключей > Добавить новый.

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

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

    • Для параметра Выбор субъекта задано значение Microsoft Rights Management Services.
    • Выбранные разрешения на доступ к ключам включают Получение, расшифровку и Подписывание.
Включение авторизации ключа с помощью PowerShell

Выполните командлет PowerShell Key Vault, Set-азкэйваултакцессполиции предоставьте разрешения на доступ к участнику службы Rights Management Azure, используя GUID 00000012-0000-0000-C000-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 00000012-0000-0000-c000-000000000000 --scope /keys/contosomhsmkey

Где:

  • 00000012-0000-0000-C000-000000000000 — GUID для использования в этой команде
  • Контосомхсм — это пример имени HSM. При выполнении этой команды замените это значение на собственное имя HSM.

Управляемая пользовательская роль шифрования HSM позволяет пользователю расшифровывать, подписывать и получать разрешения для ключа, который требуется для УПРАВЛЯЕМЫХ функций HSM.

Примечание

Хотя управляемый HSM находится в общедоступной предварительной версии, предоставление управляемой роли пользователя для шифрования HSM поддерживается только через Azure CLI.

Настройка Azure Information Protection для использования ключа

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

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

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

    Connect-AipService
    
  2. Выполните командлет Use-аипсервицекэйваулткэй, указав URL-адрес ключа. Пример:

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

    Важно!

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

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

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

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

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

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

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

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