Настройка ключей, управляемых клиентом, для учетной записи 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 в клиенте 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 Contributor, чтобы создать хранилище ключей. Чтобы добавить ключ в хранилище ключей, требуется роль специалиста по шифрованию хранилища ключей.	нет
3.	Предоставьте удостоверению приложения, для которого получено согласие, доступ к хранилищу ключей Azure, назначив роль пользователя службы шифрования хранилища ключей.	Чтобы назначить приложению роль пользователя службы шифрования хранилища ключей, требуется роль администратора доступа пользователей.	нет
4.	Скопируйте URL-адрес хранилища ключей и имя ключа в конфигурацию ключей, управляемых клиентом предложения SaaS.	нет	нет

Примечание.

Чтобы авторизовать доступ к управляемой HSM для шифрования с помощью CMK, см. пример для учетной записи хранения здесь. Дополнительные сведения об управлении ключами с помощью управляемого 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)

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

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.

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

Клиент назначает учетной записи роль Офицера криптографии хранилища ключей.

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

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

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

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

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

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

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

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

Теперь вы можете настроить ключи, управляемые клиентом, с помощью 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

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

Назначьте роль 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. Дополнительные сведения см. в статье "Начало работы с 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 с помощью следующей команды. При установке приложения в вашем арендаторе создается учетная запись службы.

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

# 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 Пользователь шифрования 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.

Параметр	Описание	Пример значения
`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"
  }
}

Внимание

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

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

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

Вопросы и ответы

Как перенести учетную запись 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 2024-08-15

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Клиент назначает учетной записи роль Офицера криптографии хранилища ключей.

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

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

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

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

Вопросы и ответы

См. также

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

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