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


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

Служба хранилища 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, охватывающем поставщика службы и клиента.

Снимок экрана: кросс-тенантный 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 и сделайте следующее.

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

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

      Снимок экрана: добавление учетных данных.

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

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

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

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

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

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

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

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

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

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

    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 хранилища ключей и ключа.

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

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

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

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

    Внимание

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

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

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

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

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

      Снимок экрана: параметры шифрования на портале Azure.

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

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

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

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

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

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

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

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

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

    Снимок экрана: настройка кросс-тенантного ключа, управляемого клиентом.

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

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

    Примечание.

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

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

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

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

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

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

    Внимание

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

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

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

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

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

      Снимок экрана: отключение ключа, управляемого клиентом, в хранилище ключей.

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

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

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

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

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

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

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

    См. также