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

Статья
08/15/2024

Область применения: Nosql Mongodb Кассандра Гремлин Таблица

Данные, хранящиеся в учетной записи 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

Этап	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. Клиент разрешает доступ к хранилищу ключей

Этап	Description	Роли Azure RBAC с минимальными привилегиями	Наименее привилегированные роли Microsoft Entra
1.	Рекомендуется: попросите пользователя войти в ваше приложение. Если пользователь может войти в него, значит, в его арендаторе есть субъект-служба для вашего приложения. Создать субъект-службу можно с помощью Microsoft Graph, Microsoft Graph PowerShell, Azure PowerShell или Azure CLI. Создайте URL-адрес предоставления согласия администратора и предоставьте согласие на уровне арендатора для создания субъекта-службы с использованием идентификатора приложения.	нет	Пользователи с разрешениями на установку приложений
2.	Создайте ресурс Azure Key Vault и ключ, используемый в качестве ключа, управляемого клиентом.	Чтобы создать хранилище ключей, требуется роль Участник Key Vault. Чтобы добавить ключ в хранилище ключей, требуется роль специалиста по шифрованию хранилища ключей.	нет
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.
В области слева выберите элементы Управление > Регистрация приложений.
Выберите + Создать регистрацию.
Укажите имя регистрации приложения и выберите учетную запись в любом каталоге организации (любой каталог 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. Дополнительные сведения см . в кратком руководстве по Bash в Azure Cloud Shell.
Если вы предпочитаете выполнять справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.
- Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы выполнить аутентификацию, следуйте инструкциям в окне терминала. Сведения о других возможностях, доступных при входе, см. в статье Вход с помощью 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-адрес предоставления согласия администратора и предоставьте согласие на уровне арендатора для создания субъекта-службы. Вам потребуется предоставить AppId.

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

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

На домашней странице или в меню портала 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

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

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

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

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

Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см . в кратком руководстве по Bash в Azure Cloud Shell.
Если вы предпочитаете выполнять справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.
- Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы выполнить аутентификацию, следуйте инструкциям в окне терминала. Сведения о других возможностях, доступных при входе, см. в статье Вход с помощью 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 зарегистрированное приложение поставщика услуг с помощью созданного ранее субъекта-службы, чтобы зарегистрированное приложение пользовалось доступом к хранилищу ключей.

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 с ключами, управляемыми клиентом, необходимо убедиться, что у него есть доступ к ключам, используемым клиентом. В сценариях с одним клиентом можно предоставить прямой доступ к хранилищу ключей субъекту 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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 с Azure Key Vault

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

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

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