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

  • Статья

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

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

Если у вас есть вопросы о межтенантных ключах, управляемых клиентом, с управляемыми дисками, по электронной почте crosstenantcmkvteam@service.microsoft.com.

Ограничения

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

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

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

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

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

Screenshot showing a cross-tenant CMK with a federated identity.

В приведенном выше примере существует два клиента 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 и сделайте следующее.

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

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

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

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

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

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

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

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

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

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

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

      Screen shot showing how to create a new multi-tenant application registration.

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

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

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

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

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

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

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

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

      Screen shot showing how to create a resource group and a user-assigned managed identity.

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

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

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

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

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

      Screen shot showing how to navigate to Certificate and secrets.

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

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

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

      Screen shot showing how to select a managed identity.

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

      Screen shot showing how to add a credential.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Screen shot showing how to create a key vault.

    Запишите имя хранилища ключей и приложения 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 хранилища ключей и ключа.

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

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

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

    1. Выберите и создайте ресурс, найдите набор шифрования дисков и выберите "Создать > набор шифрования дисков".

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

    3. В разделе " Сведения об экземпляре" укажите имя набора шифрования дисков.

      Screenshot showing how to enter the project and instance details to create a new disk encryption set.

    4. Выберите регион, в котором создается набор шифрования дисков.

    5. Для параметра Тип шифрования выберите значение Шифрование неактивных данных с помощью управляемого клиентом ключа.

    6. В разделе "Ключ шифрования" выберите клавишу ВВОД из переключателя URI и введите универсальный код ресурса (URI ) ключа, созданного в клиенте клиента.

    7. В разделе "Назначаемое пользователем удостоверение" выберите " Выбрать удостоверение".

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

    9. В разделе Мультитенантное приложение выберите " Выбрать приложение".

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

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

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

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

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

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

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

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

    Следующие шаги

    См. также: