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

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

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

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

Примечание.

Azure Key Vault и Управляемый HSM Azure Key Vault поддерживают одни и те же ИНТЕРФЕЙСы API и интерфейсы управления для настройки ключей, управляемых клиентом. Все действия, поддерживаемые Для Azure Key Vault, также поддерживаются для управляемого HSM в Azure Key Vault.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Шаблоны Azure Resource Manager (ARM) не рекомендуется создавать приложения Microsoft Entra.
• Одно и то же мультитенантное приложение можно использовать для доступа к ключам в любом количестве клиентов, таких как Tenant 2, Tenant 3, Tenant 4 и т. д. В каждом арендаторе создается независимый экземпляр приложения. У этих экземпляров одинаковые идентификаторы приложения, но разные идентификаторы объекта. Таким образом, каждый экземпляр этого приложения авторизуется независимо. Обратите внимание на то, как объект приложения, применяемый для этой функции, используется для секционирования приложения по всем клиентам.
  • Приложение может иметь не более 20 учетных данных федеративного удостоверения, что требует от поставщика услуг совместного использования федеративных удостоверений среди своих клиентов. Дополнительные сведения о проектировании федеративных удостоверений и ограничениях см. в разделе "Настройка приложения для доверия к внешнему поставщику удостоверений"
• В редких сценариях поставщик услуг может использовать один объект Application на каждого клиента, но для управления приложениями во всех клиентах требуются значительные затраты на обслуживание.
• В клиенте поставщика услуг невозможно автоматизировать проверку издателя.

Этап 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"

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

• В клиенте клиента Клиент 2 администратор может задать политики, чтобы запретить пользователям, не являющихся администраторами, устанавливать приложения. Эти политики могут предотвратить создание субъектов-служб пользователями без прав администратора. Если такая политика настроена, пользователи с разрешениями на создание субъектов-служб должны быть вовлечены.
• Доступ к Azure Key Vault можно авторизовать с помощью Azure RBAC или политик доступа. При предоставлении доступа к хранилищу ключей обязательно используйте активный механизм для хранилища ключей.
• Регистрация приложения Microsoft Entra имеет идентификатор приложения (идентификатор клиента). При установке приложения в арендаторе создается субъект-служба. Субъект-служба использует тот же идентификатор приложения, что и регистрация приложения, но создает собственный идентификатор объекта. При авторизации приложения доступа к ресурсам может потребоваться использовать субъект-службу Name или ObjectID свойство.

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

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

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

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

Портал Azure

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

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

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

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

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

Создание регистрации:

1. Найдите идентификатор Microsoft Entra в поле поиска. Найдите и выберите расширение Идентификатора Microsoft Entra.

2. В области слева выберите элементы Управление > Регистрация приложений.

3. Выберите + Создать регистрацию.

4. Укажите имя регистрации приложения и выберите учетную запись в любом каталоге организации (любой каталог Microsoft Entra — Multitenant).

5. Выберите Зарегистрировать.

6. Запишите значение ApplicationId или ClientId приложения.

   

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

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

1. В поле поиска введите запрос управляемые удостоверения. Найдите и выберите расширение Управляемые удостоверения.

2. Выберите + Создать.

3. Укажите группу ресурсов, регион и имя для управляемого удостоверения.

4. Выберите Review + create (Просмотреть и создать).

5. При успешном развертывании запишите значение ResourceId Azure управляемого удостоверения, назначаемого пользователем, которое доступно в разделе Свойства. Например:

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

   

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

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

1. Перейдите к идентификатору Microsoft Entra id > Регистрация приложений > приложения.

2. Выберите Сертификаты и секреты.

3. Выберите элемент Федеративные учетные данные.

   

4. Выберите элемент + Добавить учетные данные.

5. В разделе Сценарий федеративных учетных данных выберите элемент Ключи, управляемые клиентом.

6. Щелкните элемент Выберите управляемое удостоверение. В области выберите подписку. В разделе Управляемое удостоверение выберите элемент Управляемое удостоверение, назначаемое пользователем. В поле Выбор найдите созданное ранее управляемое удостоверение и нажмите кнопку Выбрать в нижней части области.

   

7. В разделе Сведения об учетных данных укажите имя и необязательное описание учетных данных и нажмите кнопку Добавить.

   

PowerShell

Чтобы использовать 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"

Azure CLI

• Используйте среду 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Портал

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

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

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

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

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

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

1. На домашней странице или в меню портала Azure выберите + Создать ресурс. В поле поиска введите запрос хранилища ключей. В списке результатов выберите элемент Хранилища ключей. На странице Хранилища ключей нажмите кнопку Создать.

2. На вкладке Основные сведения выберите подписку. В разделе Группа ресурсов выберите команду Создать и введите имя группы ресурсов.

3. Введите уникальное имя хранилища ключей.

4. Выберите регион и ценовую категорию.

5. Включите защиту от очистки для нового хранилища ключей.

6. На вкладке Политика доступа выберите значение Управление доступом на основе ролей Azure для параметра Модель разрешений.

7. Выберите Просмотр и создание, а затем щелкните Создать.

   

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

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

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

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

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

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

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

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

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

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

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

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

PowerShell

Чтобы настроить клиент клиента в 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 хранилища ключей и ключа.

Azure CLI

• Используйте среду 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 Key Vault.

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

Внимание

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

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

Портал Azure

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

1. Перейдите к учетной записи хранилища.

2. В разделе "Безопасность и сеть" выберите "Шифрование". По умолчанию для параметра управления ключами устанавливается значение Ключи, управляемые Майкрософт, как показано на следующем изображении.

   

3. Выберите параметр Ключи, управляемые клиентом.

4. Выберите параметр Выбрать в Key Vault.

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

6. Выберите подписку, которая содержит хранилище ключей и ключ.

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

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

   

9. Сохранение изменений.

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

PowerShell

Чтобы настроить ключи, управляемые клиентом, для новой учетной записи хранения с помощью PowerShell, сначала установите модуль Az.Storage PowerShell версии 5.1.0 или более поздней. Этот модуль устанавливается с модулем Az PowerShell версии 9.1.0 или более поздней.

Затем вызовите Set-AzStorageAccount, указав идентификатор ресурса для управляемого удостоверения, назначаемого пользователем, настроенного ранее в подписке isV, и идентификатор приложения (клиента) для мультитенантного приложения, настроенного ранее в подписке поставщика программного обеспечения. Укажите URI хранилища ключей и имя ключа из хранилища ключей клиента.

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

$accountName = "<storage-account>"
$kvUri = "<key-vault-uri>"
$keyName = "<key-name>"
$multiTenantAppId = "<multi-tenant-app-id>"

Set-AzStorageAccount -ResourceGroupName $isvRgName `
    -Name $accountName `
    -KeyvaultEncryption `
    -UserAssignedIdentityId $userIdentity.Id `
    -IdentityType SystemAssignedUserAssigned `
    -KeyName $keyName `
    -KeyVaultUri $kvUri `
    -KeyVaultUserAssignedIdentityId $userIdentity.Id `
    -KeyVaultFederatedClientId $multiTenantAppId 

Azure CLI

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

Затем вызовите az storage account update, указав идентификатор ресурса для управляемого удостоверения, назначаемого пользователем, настроенного ранее в подписке isV, и идентификатор приложения (клиента) для мультитенантного приложения, настроенного ранее в подписке поставщика программного обеспечения. Укажите URI хранилища ключей и имя ключа из хранилища ключей клиента.

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

accountName="<storage-account>"
kvUri="<key-vault-uri>"
keyName="<key-name>"
multiTenantAppId="<multi-tenant-app-id>" # appId value from multi-tenant app

# Get the resource ID for the user-assigned managed identity.
identityResourceId=$(az identity show --name $userIdentityName \
    --resource-group $isvRgName \
    --query id \
    --output tsv)

az storage account update --name $accountName \
    --resource-group $isvRgName \
    --identity-type SystemAssigned,UserAssigned \
    --user-identity-id $identityResourceId \
    --encryption-key-vault $kvUri \
    --encryption-key-name $keyName \
    --encryption-key-source Microsoft.Keyvault \
    --key-vault-user-identity-id $identityResourceId \
    --key-vault-federated-client-id $multiTenantAppId

Изменение ключа

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

Примечание.

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

Портал Azure

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

1. Перейдите к своей учетной записи хранения и откройте раздел параметров Шифрование.
2. Выберите хранилище ключей, а затем — новый ключ.
3. Сохранение изменений.

PowerShell

Чтобы изменить ключ с помощью PowerShell, вызовите команду Set-AzStorageAccount и укажите имя и версию нового ключа. Если новый ключ находится в другом хранилище ключей, необходимо также обновить URI хранилища ключей.

Azure CLI

Чтобы изменить ключ с помощью Azure CLI, вызовите команду az storage account update, а также укажите имя и версию нового ключа. Если новый ключ находится в другом хранилище ключей, необходимо также обновить URI хранилища ключей.

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

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

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

Внимание

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

Портал Azure

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

1. Перейдите в хранилище ключей, содержащее ключ.

2. В разделе "Объекты" выберите "Ключи".

3. Щелкните правой кнопкой мыши ключ и выберите "Отключить".

   

PowerShell

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

$kvName  = "<key-vault-name>"
$keyName = "<key-name>"
$enabled = $false
# $false to disable the key / $true to enable it

# Check the current state of the key (before and after enabling/disabling it)
Get-AzKeyVaultKey -Name $keyName -VaultName $kvName

# Disable (or enable) the key
Update-AzKeyVaultKey -VaultName $kvName -Name $keyName -Enable $enabled

Azure CLI

Чтобы отозвать управляемый клиентом ключ с помощью Azure CLI, вызовите команду az keyvault key set-attributes , как показано в следующем примере. Не забудьте заменить значения заполнителей в квадратных скобках собственными значениями, чтобы определить переменные или использовать переменные, определенные в предыдущих примерах.

kvName="<key-vault-name>"
keyName="<key-name>"
enabled="false"
# "false" to disable the key / "true" to enable it:

# Check the current state of the key (before and after enabling/disabling it)
az keyvault key show \
    --vault-name $kvName \
    --name $keyName

# Disable (or enable) the key
az keyvault key set-attributes \
    --vault-name $kvName \
    --name $keyName \
    --enabled $enabled

Вернуться к ключам, управляемым Корпорацией Майкрософт

Ключи, управляемые клиентом, можно переключаться с ключей, управляемых корпорацией Майкрософт, в любое время с помощью портал Azure, PowerShell или Azure CLI.

Портал Azure

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

1. Перейдите к учетной записи хранилища.

2. В разделе "Безопасность и сеть" выберите "Шифрование".

3. Измените тип шифрования на ключи, управляемые корпорацией Майкрософт.

   

PowerShell

Чтобы переключиться с управляемых клиентом ключей обратно на ключи, управляемые корпорацией Майкрософт, с помощью PowerShell вызовите Set-AzStorageAccount с -StorageEncryption параметром, как показано в следующем примере. Не забудьте заменить значения заполнителей в скобках собственными значениями и использовать переменные, определенные в предыдущих примерах.

Set-AzStorageAccount -ResourceGroupName $storageAccount.ResourceGroupName `
    -AccountName $storageAccount.StorageAccountName `
    -StorageEncryption  

Azure CLI

Чтобы переключиться с ключей, управляемых клиентом, на ключи, управляемые корпорацией Майкрософт, с помощью Azure CLI, вызовите az storage account update и задайте значение --encryption-key-source parameter Microsoft.Storage, как показано в следующем примере. Не забудьте заменить значения заполнителей в скобках собственными значениями и использовать переменные, определенные в предыдущих примерах.

az storage account update \
    --name <storage-account> \
    --resource-group <resource_group> \
    --encryption-key-source Microsoft.Storage

См. также

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