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

Статья
2024-08-25

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

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

Если у вас есть вопросы о ключах, управляемых клиентами в межтенантной среде, с управляемыми дисками, отправьте email по адресу [email protected].

Ограничения

Управляемые диски и хранилище ключей клиента должны быть расположены в одном регионе Azure, но могут находиться в разных подписках.
Эта функция не поддерживает диски ценовой категории "Ультра" и управляемые диски SSD Azure ценовой категории "Премиум" версии 2.
Эта функция недоступна в Microsoft Azure, который управляется компанией 21Vianet или в правительственных облаках.

Сведения о кросс-тенантных ключах, управляемых пользователем

Многие поставщики служб, создающие предложения SaaS (программное обеспечение как услуга) в Azure, хотят предоставить своим клиентам возможность управлять собственными ключами шифрования. Ключи, управляемые клиентом, позволяют поставщику службы шифровать данные клиента с помощью ключа шифрования, управляемого клиентом поставщика службы и недоступного поставщику службы. В Azure клиент поставщика услуг может использовать Azure Key Vault для управления ключами шифрования в собственном клиенте и подписке Microsoft Entra.

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

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

В приведенном выше примере существует два клиента Microsoft Entra: клиент независимого поставщика услуг (клиент 1) и клиент клиента (клиент 2). Клиент 1 содержит службы платформы Azure и клиент 2 размещает хранилище ключей клиента.

Регистрация мультитенантного приложения создается поставщиком услуг в клиенте 1. Учетные данные федеративной идентификации создаются в этом приложении с использованием управляемой идентичности, назначенной пользователем. Затем имя и идентификатор приложения отправляются клиенту.

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

Теперь у поставщика службы есть следующее:

Идентификатор приложения для мультитенантного приложения, установленного в арендаторе клиента, которому предоставлен доступ к ключу, управляемому клиентом.
Управляемое удостоверение, сконфигурированное в качестве метода аутентификации в мультитенантном приложении.
сведения о расположении ключа в хранилище ключей клиента.

С этими тремя параметрами поставщик услуг подготавливает ресурсы Azure в клиенте 1 , которые можно зашифровать с помощью ключа, управляемого клиентом, в клиенте 2.

Давайте разделим указанное выше комплексное решение на три этапа:

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

Для большинства приложений поставщиков служб операции настройки на этапе 1 выполняются однократно. Операции на этапах 2 и 3 будут повторяться для каждого клиента.

Этап 1. Поставщик услуг настраивает приложение Microsoft Entra

Этап	Описание	Минимальная роль в Azure RBAC	Минимальная роль в системе Microsoft Entra RBAC
1.	Создайте новую мультитенантную регистрацию приложения Microsoft Entra или начните с существующей регистрации приложения. Запишите идентификатор приложения (идентификатор клиента) регистрации приложения на портале Azure, в Microsoft API Graph, Azure PowerShell или Azure CLI.	Отсутствует	Разработчик приложений
2.	Создайте управляемое удостоверение, назначаемое пользователем (для использования в качестве учетных данных федеративного удостоверения). Портал Azure / Azure CLI / Azure PowerShell/ Шаблоны Azure Resource Manager	Участник с управляемой учетной записью	Отсутствует
3.	Настройте управляемое удостоверение, назначаемое пользователем, в качестве учетных данных федеративного удостоверения в приложении, чтобы оно могло перевоплощаться в удостоверение приложения. Справочные материалы по API Graph/ Портал Azure/ Azure CLI/ Azure PowerShell	Отсутствует	Владелец приложения
4.	Предоставьте клиенту общий доступ к имени приложения и идентификатору приложения, чтобы он смог установить и авторизовать приложение.	Отсутствует	Отсутствует

Этап 2. Клиент разрешает доступ к хранилищу ключей

Этап	Описание	Роли Azure RBAC с минимальными привилегиями	Наименее привилегированные роли Microsoft Entra
1.	Рекомендуется: попросите пользователя войти в ваше приложение. Если пользователь может войти в приложение, значит, в его тенанте существует служебный принципал для вашего приложения. Субъект-службу (учетная запись службы) можно создать с помощью Microsoft Graph, Microsoft Graph PowerShell, Azure PowerShell или Azure CLI. Создайте URL-адрес для предоставления согласия администратора и предоставьте согласие, действующее на уровне всего арендатора, для создания субъекта-службы с использованием идентификатора приложения.	Отсутствует	Пользователи с разрешениями на установку приложений
2.	Создайте ресурс Azure Key Vault и ключ, используемый в качестве ключа, управляемого клиентом.	Чтобы пользователь мог создать хранилище ключей, ему должна быть назначена роль Участник Key Vault. Чтобы добавить ключ в хранилище ключей, требуется роль специалиста по шифрованию хранилища ключей.	Отсутствует
3.	Предоставьте удостоверению приложения, для которого получено согласие, доступ к хранилищу ключей Azure, назначив роль Key Vault Crypto Service Encryption User.	Чтобы назначить приложению роль пользователя службы шифрования хранилища ключей, требуется роль администратора доступа пользователей.	Отсутствует
4	Скопируйте URL-адрес хранилища ключей и имя ключа в конфигурацию ключей, управляемых клиентом, предложения SaaS.	Отсутствует	Отсутствует

Примечание.

Чтобы авторизовать доступ к управляемому HSM для шифрования с помощью CMK, см. пример для Storage Account здесь. Дополнительные сведения об управлении ключами с помощью управляемого HSM см. в статье "Управление управляемым HSM с помощью Azure CLI"

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

После завершения этапа 1 и 2 поставщик услуг может настроить шифрование в ресурсе Azure с помощью ключа и хранилища ключей в клиенте клиента и ресурса Azure в клиенте поставщика услуг. Поставщик службы может настроить кросс-тенантные ключи, управляемые клиентом, с помощью клиентских средств, поддерживаемых этим ресурсом Azure, с помощью шаблона ARM или REST API.

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

В этом разделе объясняется, как настроить кросс-тенантный ключ, управляемый клиентом (CMK), и зашифровать данные клиента. Вы узнаете, как шифровать данные клиента в ресурсе в Tenant1 с помощью CMK, хранящегося в хранилище ключей в Tenant2. Для этого можно использовать портал Azure, Azure PowerShell или Azure CLI.

Войдите на портал Azure и выполните следующие действия.

Поставщик услуг настраивает идентификационные данные

Поставщик услуги выполняет следующие действия в арендаторе поставщика услуги Tenant1.

Поставщик услуг создает новую регистрацию мультитенантного приложения

Можно создать новую регистрацию мультитенантного приложения Microsoft Entra или начать с существующей регистрации такого приложения. Если вы начинаете с существующей регистрации приложения, запишите идентификатор приложения (идентификатор клиента).

Чтобы создать новую регистрацию:

Найдите идентификатор Microsoft Entra в поле поиска. Найдите и выберите расширение Microsoft Entra ID.
В области слева выберите Управление > регистрацией приложений.
Выберите + Создать регистрацию.
Укажите имя регистрации приложения и выберите учетную запись в любом каталоге организации (любой каталог Microsoft Entra — Multitenant).
Выберите Зарегистрировать.
Запишите значение ApplicationId или ClientId приложения.

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

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

В поле поиска введите запрос управляемые удостоверения. Найдите и выберите расширение Управляемые идентификаторы.
Выберите + Создать.
Укажите группу ресурсов, регион и имя для управляемого удостоверения.
Выберите Review + create.
При успешном развертывании запишите значение ResourceId Azure управляемого удостоверения, назначаемого пользователем, которое доступно в разделе Свойства. Рассмотрим пример.

/subscriptions/tttttttt-0000-tttt-0000-tttt0000tttt/resourcegroups/XTCMKDemo/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ConsotoCMKDemoUA

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

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

Перейдите к Microsoft Entra ID > Регистрация приложений > вашего приложения.
Выберите Сертификаты и секреты.
Выберите элемент Федеративные учетные данные.
Выберите «Добавить учетные данные».
В сценарии "Федеративные учетные данные" выберите Управляемое удостоверение.
Щелкните Выберите управляемое удостоверение. На панели выберите подписку. В разделе Управляемое удостоверение выберите элемент Управляемое удостоверение, назначаемое пользователем. В поле Выбор найдите управляемое удостоверение, которое вы создали ранее, и нажмите кнопку Выбрать в нижней части панели.
В разделе Сведения об учетных данных укажите имя и необязательное описание учетных данных и нажмите кнопку Добавить.

Чтобы использовать Azure PowerShell для настройки клиента поставщика программного обеспечения, установите последний модуль Az . Дополнительные сведения об установке PowerShell см. в статье Установка Azure PowerShell в ОС Windows с помощью PowerShellGet.

Если вы решили использовать Azure PowerShell локально:
- Установите последнюю версию модуля Az PowerShell.
- Подключитесь к учетной записи Azure с помощью командлета Connect-AzAccount.
Если вы решили использовать Azure Cloud Shell:
- Дополнительные сведения см. в статье Общие сведения об Azure Cloud Shell.

Поставщик услуг настраивает удостоверения

Следующие действия выполняются поставщиком услуг (ISV) в клиенте поставщика услуг Tenant1.

Поставщик услуг входит в Azure.

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

$isvTenantId="<isv-tenant-id>"
$isvSubscriptionId="<isv-subscription-id>"

# Sign in to Azure in the ISV's tenant.
Connect-AzAccount -Tenant $isvTenantId
# Set the context to the ISV's subscription.
Set-AzContext -Subscription $isvSubscriptionId

Поставщик услуг создает новую регистрацию многопользовательского приложения

Выберите имя для зарегистрированного приложения с несколькими арендаторами в Tenant1 и создайте мультитенантное приложение в портале Azure.

Имя, указанное для мультитенантного приложения, используется клиентом для идентификации приложения в Tenant2. Обратите внимание на идентификатор объекта приложения и идентификатор приложения. Эти значения потребуются в последующих шагах.

$multiTenantAppName="<multi-tenant-app>"
$multiTenantApp = New-AzADApplication -DisplayName $multiTenantAppName `
    -SignInAudience AzureADMultipleOrgs

# Object ID for the new multi-tenant app
$objectId = $multiTenantApp.Id
# Application (client) ID for the multi-tenant app
$multiTenantAppObjectId = $multiTenantApp.AppId

Поставщик услуг создает назначаемое пользователем управляемое удостоверение

Войдите в тенант независимого поставщика программного обеспечения, а затем создайте управляемую идентичность, назначаемую пользователем, для использования в качестве учетной информации федеративного удостоверения. Чтобы создать пользовательское управляемое удостоверение, необходимо назначить роль, которая включает действие Microsoft.ManagedIdentity/userAssignedIdentities/write.

$isvRgName="<isv-resource-group>"
$isvLocation="<location>"
$userIdentityName="<user-assigned-managed-identity>"

# Create a new resource group in the ISV's subscription.
New-AzResourceGroup -Location $isvLocation -ResourceGroupName $isvRgName

# Create the new user-assigned managed identity.
$userIdentity = New-AzUserAssignedIdentity -Name $userIdentityName `
    -ResourceGroupName $isvRgName `
    -Location $isvLocation `
    -SubscriptionId $isvSubscriptionId

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

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

Чтобы настроить учетные данные федеративного удостоверения из PowerShell, сначала установите версию 6.3.0 или более позднюю версию модуля Az.Resources .

New-AzADAppFederatedCredential -ApplicationObjectId $multiTenantApp.Id `
    -Name "MyFederatedIdentityCredential" `
    -Audience "api://AzureADTokenExchange" `
    -Issuer "https://login.microsoftonline.com/<tenant-id>/v2.0" `
    -Subject $userIdentity.PrincipalId `
    -Description "Federated Identity Credential for CMK"

Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см. в статье "Начало работы с Azure Cloud Shell".
Если вы предпочитаете запускать справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, попробуйте запустить Azure CLI в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.
- Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы завершить процесс проверки подлинности, выполните действия, отображаемые в терминале. Сведения о других параметрах входа см. в статье "Проверка подлинности в Azure с помощью Azure CLI".
- Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений и управление ими с помощью Azure CLI.
- Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.

Поставщик услуг настраивает идентичности

В арендаторе Tenant1 поставщик услуг выполняет следующие действия.

Поставщик услуг входит в Azure.

Войдите в Azure для использования Azure CLI.

az login

Поставщик услуг создает новую регистрацию мультитенантного приложения

Выберите имя мультитенантного приложения в Tenant1 и создайте мультитенантное приложение в портал Azure.

Имя, указанное для мультитенантного приложения, используется клиентом для идентификации приложения в Tenant2. Скопируйте идентификатор приложения (или идентификатор клиента) приложения, идентификатор объекта приложения, а также идентификатор клиента для приложения. Эти значения понадобятся вам на следующих этапах.

multiTenantAppName="<multi-tenant-app>"
multiTenantAppObjectId=$(az ad app create --display-name $multiTenantAppName \
    --sign-in-audience AzureADMultipleOrgs \
    --query id \
    --output tsv)

multiTenantAppId=$(az ad app show --id $multiTenantAppObjectId --query appId --output tsv)

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

Войдите в клиент поставщика программного обеспечения, затем создайте управляемое удостоверение, назначаемое пользователем, чтобы использовать его в качестве учетных данных федеративного удостоверения. Чтобы создать пользовательски назначаемое управляемое удостоверение, необходимо иметь назначенную роль, которая включает действие Microsoft.ManagedIdentity/userAssignedIdentities/write.

isvSubscriptionId="<isv-subscription-id>"
isvRgName="<isv-resource-group>"
isvLocation="<location>"
userIdentityName="<user-assigned-managed-identity>"

az group create --location $isvLocation \
    --resource-group $isvRgName \
    --subscription $isvSubscriptionId

principalId=$(az identity create --name $userIdentityName \
    --resource-group $isvRgName \
    --location $isvLocation \
    --subscription $isvSubscriptionId \
    --query principalId \
    --out tsv)

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

Запустите метод az ad app federated-credential create, чтобы настроить учетные данные федеративного удостоверения в приложении и создать доверительные отношения с внешним поставщиком удостоверений.

Используйте api://AzureADTokenExchange в качестве значения audience в учетных данных федеративного удостоверения. Дополнительные сведения см. в справочнике по API.

# Create a file named "credential.json" with the following content.
# Replace placeholders in angle brackets with your own values.
{
    "name": "MyFederatedIdentityCredential",
    "issuer": "https://login.microsoftonline.com/<tenantID>/v2.0",
    "subject": "<user-assigned-identity-principal-id>",
    "description": "Federated Identity Credential for CMK",
    "audiences": [
        "api://AzureADTokenExchange"
    ]
}

az ad app federated-credential create --id $multiTenantAppObjectId --parameters credential.json

Поставщик услуг делится идентификатором приложения с клиентом

Найдите идентификатор приложения (идентификатор клиента) мультитенантного приложения и поделитесь им с клиентом.

Клиент предоставляет приложению поставщика службы доступ к ключу в хранилище ключей

В арендаторе клиента Tenant2 клиент выполняет следующие действия. Клиент может использовать портал Azure, Azure PowerShell или Azure CLI.

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

Войдите на портал Azure и выполните следующие действия.

Клиент устанавливает приложение поставщика услуг в клиентском облаке

Чтобы установить зарегистрированное приложение поставщика услуг в арендаторе клиента, создайте представителя службы, используя идентификатор зарегистрированного приложения. Субъект-службу можно создать с помощью любого из следующих способов:

Учетную запись службы можно создать вручную с помощью Microsoft Graph, Microsoft Graph PowerShell, Azure PowerShell или Azure CLI.
Создайте URL-адрес для предоставления согласия администратора и предоставьте арендаторское согласие для создания служебного принципала. Вам потребуется предоставить свой AppId.

Клиент создает хранилище ключей

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

На домашней странице или в меню портала Azure выберите + Создать ресурс. В поле поиска введите запрос хранилища ключей. В списке результатов выберите элемент Хранилища ключей. На странице Хранилища ключей нажмите кнопку Создать.
На вкладке Основные сведения выберите подписку. В разделе Группа ресурсов выберите команду Создать и введите имя группы ресурсов.
Введите уникальное имя хранилища ключей.
Выберите регион и ценовую категорию.
Включите защиту от очистки для нового хранилища ключей.
На вкладке Политика доступа выберите значение Управление доступом на основе ролей Azure для параметра Модель разрешений.
Выберите Просмотр и создание, а затем щелкните Создать.

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

Дополнительные сведения см. в статье Краткое руководство. Создание хранилища ключей с помощью портала Azure.

Клиент назначает учетной записи роль офицера криптографии Key Vault

Этот шаг гарантирует, что вы сможете создать ключи шифрования.

Перейдите к хранилищу ключей и выберите элемент Управление доступом (IAM) в области слева.
В разделе Предоставить доступ к этому ресурсу выберите элемент Добавление назначения ролей.
Выполните поиск по запросу Специалист по шифрованию хранилища ключей и выберите соответствующий результат.
В разделе Члены выберите элемент Пользователь, группа или субъект-служба.
Выберите элемент Члены и найдите свою учетную запись пользователя.
Выберите Проверить и назначить.

Клиент создает ключ шифрования

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

На странице свойств хранилища ключей выберите элемент Ключи.
Выберите Создать/импортировать.
На экране создания ключа укажите имя ключа. Оставьте другие значения по умолчанию.
Выберите Создать.
Скопируйте URI ключа.

Клиент предоставляет приложению поставщика службы доступ к хранилищу ключей

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

Перейдите к хранилищу ключей и выберите элемент Управление доступом (IAM) в области слева.
В разделе Предоставить доступ к этому ресурсу выберите элемент Добавление назначения ролей.
Выполните поиск и выберите пользователя службы шифрования Key Vault Crypto Service Encryption.
В разделе Члены выберите элемент Пользователь, группа или субъект-служба.
Выберите элемент Члены и найдите имя установленного приложения, полученного от поставщика службы.
Выберите Проверить + Назначить.

Теперь вы можете настроить ключи, управляемые клиентом, с помощью URI хранилища ключей и ключа.

Чтобы настроить арендатора клиента в Azure PowerShell, установите последний модуль Az. Дополнительные сведения об установке PowerShell см. в статье Установка Azure PowerShell в ОС Windows с помощью PowerShellGet.

Если вы решили использовать Azure PowerShell локально:
- Установите последнюю версию модуля Az PowerShell.
- Подключитесь к учетной записи Azure с помощью командлета Connect-AzAccount.
Если вы решили использовать Azure Cloud Shell:
- Дополнительные сведения см. в статье Общие сведения об Azure Cloud Shell.

Клиент входит в Azure

В Azure PowerShell войдите в клиент клиента и задайте активную подписку на подписку клиента.

$customerTenantId="<customer-tenant-id>"
$customerSubscriptionId="<customer-subscription-id>"

# Sign in to Azure in the customer's tenant.
Connect-AzAccount -Tenant $customerTenantId
# Set the context to the customer's subscription.
Set-AzContext -Subscription $customerSubscriptionId

Клиент устанавливает приложение поставщика услуг в арендаторе клиента

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

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

$customerRgName="<customer-resource-group>"
$customerLocation="<location>"
$multiTenantAppId="<multi-tenant-app-id>" # appId value from Tenant1 

# Create a resource group in the customer's subscription.
New-AzResourceGroup -Location $customerLocation -ResourceGroupName $customerRgName

# Create the service principal with the registered app's application ID (client ID).
$servicePrincipal = New-AzADServicePrincipal -ApplicationId $multiTenantAppId

Клиент создает хранилище ключей

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

$kvName="<key-vault>"

$kv = New-AzKeyVault -Location $customerLocation `
    -Name $kvName `
    -ResourceGroupName $customerRgName `
    -SubscriptionId $customerSubscriptionId `
    -EnablePurgeProtection `
    -EnableRbacAuthorization

Клиент назначает учетной записи пользователя роль "Специалист по шифрованию хранилища ключей"

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

$currentUserObjectId = (Get-AzADUser -SignedIn).Id

New-AzRoleAssignment -RoleDefinitionName "Key Vault Crypto Officer" `
    -Scope $kv.ResourceId `
    -ObjectId $currentUserObjectId

Клиент создает ключ шифрования

$keyName="<key-name>"

Add-AzKeyVaultKey -Name $keyName `
    -VaultName $kvName `
    -Destination software

Клиент предоставляет приложению поставщика службы доступ к хранилищу ключей

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

New-AzRoleAssignment -RoleDefinitionName "Key Vault Crypto Service Encryption User" `
    -Scope $kv.ResourceId `
    -ObjectId $servicePrincipal.Id

Теперь вы можете настроить ключи, управляемые клиентом, с помощью URI хранилища ключей и ключа.

Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см. в статье "Начало работы с Azure Cloud Shell".
Если вы предпочитаете запускать справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, попробуйте запустить Azure CLI в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.
- Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы завершить процесс проверки подлинности, выполните действия, отображаемые в терминале. Сведения о других параметрах входа см. в статье "Проверка подлинности в Azure с помощью Azure CLI".
- Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений и управление ими с помощью Azure CLI.
- Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.

Клиент входит в Azure

Войдите в Azure для использования Azure CLI.

az login

Клиент устанавливает приложение поставщика услуг в арендаторе клиента

Получив идентификатор мультитенантного приложения поставщика услуг, установите приложение в своем арендаторе Tenant2 с помощью следующей команды. При установке приложения в вашем tenant-е создается основной объект службы.

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

# Create the service principal with the registered app's application ID (client ID)
multiTenantAppId="<multi-tenant-app-id>"
az ad sp create --id $multiTenantAppId --query id --out tsv

Клиент создает хранилище ключей

customerSubscriptionId="<customer-subscription-id>"
customerRgName="<customer-resource-group>"
customerLocation="<location>"
kvName="<key-vault>"

az group create --location $customerLocation \
    --name $customerRgName

az keyvault create --name $kvName \
    --location $customerLocation \
    --resource-group $customerRgName \
    --subscription $customerSubscriptionId \
    --enable-purge-protection true \
    --enable-rbac-authorization true

Назначение клиентом роли "Специалист по шифрованию хранилища ключей" некоторой учетной записи

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

currentUserObjectId=$(az ad signed-in-user show --query id --output tsv)

kvResourceId=$(az keyvault show --resource-group $customerRgName \
    --name $kvName \
    --query id \
    --output tsv)

az role assignment create --role "Key Vault Crypto Officer" \
    --scope $kvResourceId \
    --assignee-object-id $currentUserObjectId

Клиент создает ключ шифрования

keyName="<key-name>"
az keyvault key create --name $keyName --vault-name $kvName

Клиент предоставляет приложению поставщика службы доступ к хранилищу ключей

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

servicePrincipalId=$(az ad sp show --id $multiTenantAppId --query id --output tsv)

az role assignment create --role "Key Vault Crypto Service Encryption User" \
    --scope $kvResourceId \
    --assignee-object-id $servicePrincipalId

Теперь вы можете настроить ключи, управляемые клиентом, с помощью URI хранилища ключей и ключа.

Создание набора шифрования дисков

Теперь, когда вы создали Azure Key Vault и выполнили необходимые конфигурации Microsoft Entra, разверните набор шифрования дисков, настроенный для работы между клиентами и связав его с ключом в хранилище ключей. Это можно сделать с помощью портал Azure, Azure PowerShell или Azure CLI. Вы также можете использовать шаблон ARM или REST API.

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

Выберите + Создать ресурс, найдите набор шифрования дисков и выберите Создать > набор шифрования дисков.
В разделе "Сведения о проекте" выберите подписку и группу ресурсов, в которой необходимо создать набор шифрования дисков.
В разделе " Сведения об экземпляре" укажите имя набора шифрования дисков.
Выберите регион, в котором создается набор шифрования дисков.
Для параметра Тип шифрования выберите значение Шифрование неактивных данных с помощью управляемого клиентом ключа.
В разделе «Ключ шифрования» выберите переключатель «Ввести ключ из URI», затем введите URI ключа, созданного у арендатора клиента.
В разделе "Назначаемое пользователем удостоверение" выберите "Выбрать удостоверение".
Выберите управляемое удостоверение, назначаемое пользователем, созданное ранее в клиенте поставщика программного обеспечения, и нажмите кнопку "Добавить".
В разделе Мультитенантное приложение выберите " Выбрать приложение".
Выберите многотенантное зарегистрированное приложение, созданное ранее в клиенте поставщика программного обеспечения, и нажмите кнопку "Выбрать".
Выберите Review + create.

Чтобы использовать Azure PowerShell, установите последний модуль Az или модуль Az.Storage. Дополнительные сведения об установке PowerShell см. в статье Установка Azure PowerShell в ОС Windows с помощью PowerShellGet.

Если вы решили использовать Azure PowerShell локально:
- Установите последнюю версию модуля Az PowerShell.
- Подключитесь к учетной записи Azure с помощью командлета Connect-AzAccount.
Если вы решили использовать Azure Cloud Shell:
- Дополнительные сведения см. в статье Общие сведения об Azure Cloud Shell.

В приведенном ниже скрипте в параметре -FederatedClientId должен быть указан идентификатор приложения (идентификатор клиента) мультитенантного приложения. Кроме того, нужно предоставить идентификатор подписки, имя группы ресурсов и имя удостоверения.

$userAssignedIdentities = @{"/subscriptions/subscriptionId/resourceGroups/resourceGroupName/providers/Microsoft.ManagedIdentity/userAssignedIdentities/identityName" = @{}};

$config = New-AzDiskEncryptionSetConfig `
   -Location 'westcentralus' `
   -KeyUrl "https://vault1.vault.azure.net:443/keys/key1/mykey" `
   -IdentityType 'UserAssigned' `
   -RotationToLatestKeyVersionEnabled $True `
   -UserAssignedIdentity $userAssignedIdentities `
   -FederatedClientId "00000000-0000-0000-0000-000000000000" `
   $config `
   | New-AzDiskEncryptionSet -ResourceGroupName 'rg1' -Name 'enc1'

Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см. в статье "Начало работы с Azure Cloud Shell".
Если вы предпочитаете запускать справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, попробуйте запустить Azure CLI в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.
- Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы завершить процесс проверки подлинности, выполните действия, отображаемые в терминале. Сведения о других параметрах входа см. в статье "Проверка подлинности в Azure с помощью Azure CLI".
- Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений и управление ими с помощью Azure CLI.
- Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.

В приведенном ниже скрипте в параметре myAssignedId должен быть указан идентификатор ресурса для ранее созданного управляемого удостоверения, назначаемого пользователем, а в параметре myFederatedClientId — идентификатор приложения (идентификатор клиента) мультитенантного приложения.

az disk-encryption-set create --resource-group MyResourceGroup --name MyDiskEncryptionSet --key-url MyKey --mi-user-assigned myAssignedId --federated-client-id myFederatedClientId --location westcentralus

Использование шаблона ARM

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "desname": {
      "defaultValue": "<Enter ISV disk encryption set name>",
      "type": "String"
    },
    "region": {
      "defaultValue": "WestCentralUS",
      "type": "String"
    },
    "userassignedmicmk": {
      "defaultValue": "/subscriptions/<Enter ISV Subscription Id>/resourceGroups/<Enter ISV resource group name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<Enter ISV User Assigned Identity Name>",
      "type": "String"
    },
    "cmkfederatedclientId": {
      "defaultValue": "<Enter ISV Multi-Tenant App Id>",
      "type": "String"
    },
    "keyVaultURL": {
      "defaultValue": "<Enter Client Key URL>",
      "type": "String"
    },
    "encryptionType": {
      "defaultValue": "EncryptionAtRestWithCustomerKey",
      "type": "String"
    }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.Compute/diskEncryptionSets",
      "apiVersion": "2021-12-01",
      "name": "[parameters('desname')]",
      "location": "[parameters('region')]",
      "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
          "[parameters('userassignedmicmk')]": {}
        }
      },
      "properties": {
        "activeKey": {
          "keyUrl": "[parameters('keyVaultURL')]"
        },
        "federatedClientId": "[parameters('cmkfederatedclientId')]",
        "encryptionType": "[parameters('encryptionType')]"
      }
    }
  ]
}

Использование REST API

Укажите токен носителя в заголовке авторизации и укажите тип содержимого "application/json" в теле запроса. На вкладке "Сеть" используйте фильтр для management.azure при выполнении любого запроса ARM на портале.

PUT https://management.azure.com/subscriptions/<Enter ISV Subscription Id>/resourceGroups/<Enter ISV Resource Group Name>/providers/Microsoft.Compute/diskEncryptionSets/<Enter ISV Disk Encryption Set Name>?api-version=2021-12-01
Authorization: Bearer ...
Content-Type: application/json

{
  "name": "<Enter ISV disk encryption set name>",
  "id": "/subscriptions/<Enter ISV Subscription Id>/resourceGroups/<Enter ISV resource group name>/providers/Microsoft.Compute/diskEncryptionSets/<Enter ISV disk encryption set name>/",
  "type": "Microsoft.Compute/diskEncryptionSets",
  "location": "westcentralus",
  "identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
"/subscriptions/<Enter ISV Subscription Id>/resourceGroups/<Enter ISV resource group name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<Enter ISV User Assigned Identity Name>
": {}
    }
  },
  "properties": {
    "activeKey": {
      "keyUrl": "<Enter Client Key URL>"
    },
    "encryptionType": "EncryptionAtRestWithCustomerKey",
    "federatedClientId": "<Enter ISV Multi-Tenant App Id>"
  }
}

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

См. также:

Поделиться через

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

Ограничения

Сведения о кросс-тенантных ключах, управляемых пользователем

Этап 1. Поставщик услуг настраивает приложение Microsoft Entra

Рекомендации для поставщиков служб

Этап 2. Клиент разрешает доступ к хранилищу ключей

Рекомендации для клиентов поставщиков служб

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

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

Поставщик услуг настраивает идентификационные данные

Поставщик услуг создает новую регистрацию мультитенантного приложения

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

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

Поставщик услуг делится идентификатором приложения с клиентом

Клиент предоставляет приложению поставщика службы доступ к ключу в хранилище ключей

Клиент устанавливает приложение поставщика услуг в клиентском облаке

Клиент создает хранилище ключей

Клиент назначает учетной записи роль офицера криптографии Key Vault

Клиент создает ключ шифрования

Клиент предоставляет приложению поставщика службы доступ к хранилищу ключей

Создание набора шифрования дисков

Использование шаблона ARM

Использование REST API

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

Обратная связь

Дополнительные ресурсы