Настройка ключей, управляемых клиентом, для учетной записи Azure Cosmos DB с помощью Azure Key Vault

Применяется к: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

Данные, хранящиеся в учетной записи Azure Cosmos DB, автоматически шифруются с помощью управляемых службой ключей, управляемых корпорацией Майкрософт. Однако можно добавить второй уровень шифрования с помощью ключей, которыми вы управляете. Эти ключи называются ключами, управляемыми клиентом (или CMK). Управляемые клиентом ключи хранятся в экземпляре Azure Key Vault.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Step	Description	Минимальная роль в 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. Клиент разрешает доступ к хранилищу ключей

Step	Description	Роли Azure RBAC с наименьшими правами доступа	Наименее привилегированные роли Microsoft Entra
1.	Рекомендуется: попросите пользователя войти в ваше приложение. Если пользователь может войти в систему, значит, в его арендуемом пространстве существует служебный принципал для вашего приложения. Используйте Microsoft Graph, Microsoft Graph PowerShell, Azure PowerShell или Azure CLI для создания субъекта-службы. Создайте URL-адрес для предоставления согласия администратора и предоставьте согласие, действующее на уровне всего арендатора, для создания субъекта-службы с использованием идентификатора приложения.	Нет	Пользователи с разрешениями на установку приложений
2.	Создайте Azure Key Vault и ключ, используемый в качестве ключа, управляемого клиентом.	Пользователь должен быть назначен на роль Key Vault Contributor, чтобы создать хранилище ключей. Пользователю необходимо назначить роль Key Vault Crypto Officer, чтобы добавить ключ в хранилище ключей.	Нет
3.	Предоставьте идентификатору приложения доступ к хранилищу ключей Azure, назначив роль Key Vault Crypto Service Encryption User	Чтобы назначить приложению роль Key Vault Crypto Service Encryption User, вам должна быть назначена роль User Access Administrator.	Нет
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 ID в поле поиска. Найдите и выберите расширение Microsoft Entra ID.
В области слева выберите Управление > регистрацией приложений.
Выберите +Создать регистрацию.
Укажите имя регистрации приложения и выберите учетную запись в любом каталоге организации (любой каталог Microsoft Entra — Multitenant).
Выберите Зарегистрировать.
Запишите значение ApplicationId или ClientId приложения.

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

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

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

/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. Для получения дополнительной информации см. Get started with 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)

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

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-адрес для предоставления согласия администратора и предоставьте арендаторское согласие для создания служебного принципала. Вам потребуется предоставить ваш идентификатор приложения.

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

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

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

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

Дополнительные сведения см. в разделе Quickstart — создание Azure Key Vault с помощью портала 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.

Назначьте учетной записи пользователя роль Офицера по криптографии 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

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

Назначьте роль Key Vault Crypto Service Encryption User в Azure RBAC зарегистрированному приложению поставщика услуг через созданный ранее служебный принципал, чтобы оно могло получить доступ к хранилищу ключей.

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

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

Используйте среду Bash в Azure Cloud Shell. Для получения дополнительной информации см. Get started with 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

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

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

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 Пользователь шифрования Key Vault Crypto Service Encryption с помощью субъекта-службы, созданного вами ранее, чтобы зарегистрированное приложение могло получить доступ к хранилищу ключей.

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 Cosmos DB, зашифрованной ключом из другого клиента

До этого момента вы настроили мультитенантное приложение на клиенте поставщика услуг. Вы также установили приложение в тенанте клиента и настроили хранилище ключей и ключ в тенанте клиента. Затем можно создать учетную запись Azure Cosmos DB в клиенте поставщика услуг и настроить ключи, управляемые клиентом, с ключом клиента.

При создании учетной записи Azure Cosmos DB с ключами, управляемыми клиентом, необходимо убедиться, что у него есть доступ к ключам, используемым клиентом. В одноклиентских сценариях можно предоставить прямой доступ к хранилищу ключей главному субъекту (principal) Azure Cosmos DB или использовать определённую управляемую идентичность. В сценарии с несколькими клиентами мы больше не можем зависеть от прямого доступа к хранилищу ключей, так как он находится в другом клиенте, управляемом клиентом. Из-за этого ограничения в предыдущих разделах мы создали приложение для нескольких арендаторов и зарегистрировали управляемое удостоверение внутри приложения, чтобы предоставить ему доступ к хранилищу ключей клиента. Управляемое удостоверение, в сочетании с идентификатором межтенантного приложения, используется нами при создании межклиентской учетной записи CMK Azure Cosmos DB. Для получения дополнительной информации см. раздел этой статьи Этап 3 - Поставщик услуг шифрует данные в ресурсе Azure с использованием ключа, управляемого клиентом.

Когда новая версия ключа доступна в хранилище ключей, она автоматически обновляется в учетной записи Azure Cosmos DB.

Использование шаблонов JSON в Azure Resource Manager

Разверните шаблон ARM со следующими параметрами:

Замечание

Если вы воссоздаете этот пример в одном из шаблонов Azure Resource Manager, используйте apiVersion к 2022-05-15.

Parameter	Description	Пример значения
`keyVaultKeyUri`	Идентификатор ключа, управляемого клиентом, который находится в хранилище ключей поставщика услуг.	`https://my-vault.vault.azure.com/keys/my-key`
`identity`	Объект, указывающий, что управляемое удостоверение должно быть присвоено учетной записи Azure Cosmos DB.	`"identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}}`
`defaultIdentity`	Сочетание идентификатора ресурса управляемого удостоверения и идентификатора приложения мультитенантного приложения Microsoft Entra.	`UserAssignedIdentity=/subscriptions/00001111-aaaa-2222-bbbb-3333cccc4444/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity&FederatedClientId=aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e`

Ниже приведен пример сегмента шаблона с тремя параметрами, настроенными:

{
  "kind": "GlobalDocumentDB",
  "location": "East US 2",
  "identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity": {}
    }
  },
  "properties": {
    "locations": [
      {
        "locationName": "East US 2",
        "failoverPriority": 0,
        "isZoneRedundant": false
      }
    ],
    "databaseAccountOfferType": "Standard",
    "keyVaultKeyUri": "https://my-vault.vault.azure.com/keys/my-key",
    "defaultIdentity": "UserAssignedIdentity=/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity&FederatedClientId=aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e"
  }
}

Important

Эта функция пока не поддерживается в Azure PowerShell, Azure CLI или на портале Azure.

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

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

FAQs

Как перенести учетную запись Azure Cosmos DB с ключами, управляемыми клиентом, в другую группу ресурсов или в другую подписку?

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

Общие рекомендации по переносу учетной записи Cosmos DB в другую группу ресурсов или подписку описаны в статье о перемещении ресурсов Azure в новую группу ресурсов или статью подписки .

После того как вы успешно переместили учетную запись Azure Cosmos DB согласно общим рекомендациям, все удостоверения (System-Assigned или User-Assigned), связанные с учетной записью, должны быть переназначены. Это переназначение необходимо, чтобы гарантировать, что эти идентификаторы продолжат иметь необходимые разрешения для доступа к ключу Key Vault.

Как перенести учетную запись Azure Cosmos DB в другой клиент?

Если для вашей учетной записи Cosmos DB включены ключи, управляемые клиентом, вы можете переносить учетную запись только в том случае, если она является меж-арендаторской учетной записью с управляемыми клиентом ключами. Дополнительные сведения см. в руководстве по настройке клиентских ключей управления для разных тенантов в учетной записи Azure Cosmos DB с помощью Azure Key Vault.

Предупреждение

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

См. также

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

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

Были ли сведения на этой странице полезными?

Last updated on 2026-04-27

Настройка ключей, управляемых клиентом, для учетной записи Azure Cosmos DB с помощью Azure Key Vault

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создание учетной записи Azure Cosmos DB, зашифрованной ключом из другого клиента

Использование шаблонов JSON в Azure Resource Manager

FAQs

См. также

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

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