Проверка подлинности доступа и подключений к ресурсам Azure с помощью управляемых удостоверений в Azure Logic Apps

Статья
05/10/2024

Область применения: Azure Logic Apps (Потребление + Стандартный)

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

Azure Logic Apps поддерживает следующие типы управляемых удостоверений:

В следующем списке описываются некоторые различия между этими типами управляемых удостоверений:

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

В этом руководстве показано, как выполнить следующие задачи:

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

Создайте и настройте удостоверение, назначаемое пользователем. В этом руководстве показано, как создать это удостоверение с помощью портал Azure или шаблона Azure Resource Manager (шаблона ARM) и использования удостоверения для проверки подлинности. Сведения о Azure PowerShell, Azure CLI и AZURE REST API см. в следующей документации:

Средство	Документация
Azure PowerShell	Создание назначаемого пользователем удостоверения
Azure CLI	Создание назначаемого пользователем удостоверения
Azure REST API	Создание назначаемого пользователем удостоверения

Необходимые компоненты

Учетная запись и подписка Azure. Если у вас нет ее, вы можете зарегистрироваться для получения бесплатной учетной записи Azure. Как назначенное системой управляемое удостоверение, так и ресурс, к которому необходимо назначить доступ, должны находиться в одной подписке Azure.
Целевой ресурс Azure, к которому требуется получить доступ. В этом ресурсе необходимо добавить необходимую роль для управляемого удостоверения, чтобы получить доступ к этому ресурсу от имени приложения логики или подключения. Чтобы добавить роль в управляемое удостоверение, требуются разрешения администратора Microsoft Entra, которые могут назначать роли удостоверениям в соответствующем клиенте Microsoft Entra.
Ресурс приложения логики и рабочий процесс, в котором требуется использовать триггер или действия, поддерживающие управляемые удостоверения.

Различия в управляемом удостоверении между приложениями логики "Потребление" и "Стандартный"

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

Приложение логики	Среда	Поддержка управляемых удостоверений
Потребление	— Мультитенантные Приложения Логики Azure	— Вы можете включить удостоверение, назначаемое системой, или удостоверение, назначаемое пользователем, но не в приложении логики. — Управляемое удостоверение можно использовать на уровне ресурса приложения логики и на уровне подключения. — Если вы создаете и включаете удостоверение, назначаемое пользователем, приложение логики может одновременно иметь только одно назначаемое пользователем удостоверение.
Стандартные	— Azure Logic Apps с одним клиентом — Среда службы приложений версии 3 (ASEv3) - Logic Apps с поддержкой Azure Arc	— Вы можете включить как назначаемое системой удостоверение, которое включено по умолчанию, так и удостоверение, назначаемое пользователем, одновременно. Вы также можете добавить несколько удостоверений, назначенных пользователем, в приложение логики. Однако приложение логики может одновременно использовать только одно управляемое удостоверение. — Управляемое удостоверение можно использовать на уровне ресурса приложения логики и на уровне подключения.

Сведения об ограничениях управляемых удостоверений в Azure Logic Apps см. в разделе "Ограничения для управляемых удостоверений" для приложений логики. Дополнительные сведения о типах ресурсов и средах приложения логики "Потребление" и "Стандартный" см. в следующей документации:

Где можно использовать управляемое удостоверение

В Azure Logic Apps только определенные встроенные и управляемые операции соединителя, поддерживающие OAuth с идентификатором Microsoft Entra, могут использовать управляемое удостоверение для проверки подлинности. В приведенных ниже таблицах приведены только выборки образца. Полный список см. в следующей документации:

Потребление
Стандартные

Для рабочего процесса приложения логики потребления в следующей таблице перечислены примеры соединителей, поддерживающих проверку подлинности управляемого удостоверения:

Тип соединителя	Поддерживаемые соединители
Встроенный	— Azure Управление API — службы приложение Azure - Функции Azure - HTTP - HTTP + Веб-перехватчик Примечание. Операции HTTP могут проверять подлинность подключений к учетным записям службы хранилища Azure в обход брандмауэров Azure, используя назначаемое системой удостоверение. Однако http-операции не поддерживают удостоверение, назначаемое пользователем, для проверки подлинности одних и того же подключения.
Управляется	— служба приложение Azure - служба автоматизации Azure - Хранилище BLOB-объектов Azure — Экземпляр контейнера Azure — Azure Cosmos DB — Обозреватель данных Azure - Фабрика данных Azure — Azure Data Lake — Azure Digital Twins - Сетка событий Azure - Центры событий Azure — Azure IoT Central V2 — Azure Key Vault -Журналы Azure Monitor — Очереди Azure — Azure Resource Manager - Служебная шина Azure — Azure Sentinel — Хранилище таблиц Azure — виртуальная машина Azure - SQL Server

Тип соединителя

Поддерживаемые соединители

Встроенный

— Azure Управление API
— службы приложение Azure
- Функции Azure
- HTTP
- HTTP + Веб-перехватчик

Примечание. Операции HTTP могут проверять подлинность подключений к учетным записям службы хранилища Azure в обход брандмауэров Azure, используя назначаемое системой удостоверение. Однако http-операции не поддерживают удостоверение, назначаемое пользователем, для проверки подлинности одних и того же подключения.

Управляется

— служба приложение Azure
- служба автоматизации Azure
- Хранилище BLOB-объектов Azure
— Экземпляр контейнера Azure
— Azure Cosmos DB
— Обозреватель данных Azure
- Фабрика данных Azure
— Azure Data Lake
— Azure Digital Twins
- Сетка событий Azure
- Центры событий Azure
— Azure IoT Central V2
— Azure Key Vault
-Журналы Azure Monitor
— Очереди Azure
— Azure Resource Manager
- Служебная шина Azure
— Azure Sentinel
— Хранилище таблиц Azure
— виртуальная машина Azure
- SQL Server

Для рабочего процесса приложения логики уровня "Стандартный" в следующей таблице перечислены примеры соединителей, поддерживающих проверку подлинности управляемого удостоверения:

Тип соединителя	Поддерживаемые соединители
Встроенный	- служба автоматизации Azure - Хранилище BLOB-объектов Azure - Центры событий Azure - Служебная шина Azure — Очереди Azure — Таблицы Azure - HTTP - HTTP + Веб-перехватчик — SQL Server Примечание. За исключением соединителей SQL Server и HTTP, большинство встроенных соединителей на основе поставщика услуг в настоящее время не поддерживают выбор удостоверений, назначенных пользователем для проверки подлинности. Вместо этого необходимо использовать назначаемое системой удостоверение. Операции HTTP могут проходить проверку подлинности подключений к учетным записям служба хранилища Azure за брандмауэрами Azure с помощью удостоверения, назначаемого системой.
Управляется	— служба приложение Azure - служба автоматизации Azure - Хранилище BLOB-объектов Azure — Экземпляр контейнера Azure — Azure Cosmos DB — Обозреватель данных Azure - Фабрика данных Azure — Azure Data Lake — Azure Digital Twins - Сетка событий Azure - Центры событий Azure — Azure IoT Central V2 — Azure Key Vault -Журналы Azure Monitor — Очереди Azure — Azure Resource Manager - Служебная шина Azure — Azure Sentinel — Хранилище таблиц Azure — виртуальная машина Azure - SQL Server

Тип соединителя

Поддерживаемые соединители

Встроенный

- служба автоматизации Azure
- Хранилище BLOB-объектов Azure
- Центры событий Azure
- Служебная шина Azure
— Очереди Azure
— Таблицы Azure
- HTTP
- HTTP + Веб-перехватчик
— SQL Server

Примечание. За исключением соединителей SQL Server и HTTP, большинство встроенных соединителей на основе поставщика услуг в настоящее время не поддерживают выбор удостоверений, назначенных пользователем для проверки подлинности. Вместо этого необходимо использовать назначаемое системой удостоверение. Операции HTTP могут проходить проверку подлинности подключений к учетным записям служба хранилища Azure за брандмауэрами Azure с помощью удостоверения, назначаемого системой.

Управляется

Включение назначаемого системой удостоверения в портал Azure

Потребление
Стандартные

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

В портал Azure откройте ресурс приложения логики потребления.
В меню приложения логики в разделе Параметры выберите Идентификатор.

На странице "Удостоверение" в разделе "Назначенная системой" выберите "Сохранить".> Когда Azure запросит подтверждение, выберите Да.

Примечание.

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

Теперь ресурс приложения логики может использовать назначаемое системой удостоверение. Это удостоверение зарегистрировано в идентификаторе Microsoft Entra и представлено идентификатором объекта.

Свойство	Значение	Описание
Идентификатор объекта (субъекта)	<identity-resource-ID>	Глобальный уникальный идентификатор (GUID), представляющий удостоверение, назначаемое системой для приложения логики в клиенте Microsoft Entra.

Теперь выполните действия, которые предоставляют системным удостоверениям доступ к ресурсу далее в этом руководстве.

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

На портале Azure откройте свой ресурс приложения логики категории "Стандартный".
В меню приложения логики в разделе Параметры выберите Идентификатор.

Ресурс приложения логики теперь может использовать назначаемое системой удостоверение, которое зарегистрировано в идентификаторе Microsoft Entra и представлено идентификатором объекта.

Свойство	Значение	Описание
Идентификатор объекта (субъекта)	<identity-resource-ID>	Глобальный уникальный идентификатор (GUID), представляющий удостоверение, назначаемое системой для приложения логики в клиенте Microsoft Entra.

Теперь выполните действия, которые предоставляют этому удостоверению доступ к ресурсу далее в этом руководстве.

Включение назначаемого системой удостоверения с помощью шаблона ARM

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

Потребление
Стандартные

{
   "apiVersion": "2016-06-01",
   "type": "Microsoft.logic/workflows",
   "name": "[variables('logicappName')]",
   "location": "[resourceGroup().location]",
   "identity": {
      "type": "SystemAssigned"
   },
   "properties": {},
   <...>
}

{
   "apiVersion": "2021-01-15",
   "type": "Microsoft.Web/sites",
   "name": "[variables('sites_<logic-app-resource-name>_name')]",
   "location": "[resourceGroup().location]",
   "kind": "functionapp,workflowapp",
   "identity": {
      "type": "SystemAssigned"
   },
   "properties": {},
   <...>
}

Когда Azure создает определение ресурса приложения логики, объект удостоверений получает следующие другие свойства:

"identity": {
   "type": "SystemAssigned",
   "principalId": "<principal-ID>",
   "tenantId": "<Entra-tenant-ID>"
}

Свойство (JSON)	значение	Описание
principalId	<ИД субъекта>	Глобальный уникальный идентификатор (GUID) объекта субъекта-службы для управляемого удостоверения, представляющего приложение логики в клиенте Microsoft Entra. Этот GUID иногда отображается как "идентификатор объекта" или objectID.
tenantId	<Microsoft-Entra-ID-tenant-ID>	Глобальный уникальный идентификатор (GUID), представляющий клиент Microsoft Entra, в котором приложение логики теперь является членом. В клиенте Microsoft Entra субъект-служба имеет то же имя, что и экземпляр приложения логики.

Создание назначаемого пользователем управляемого удостоверения через портал Azure

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

В поле поиска портал Azure введите управляемые удостоверения. В списке результатов выберите управляемые удостоверения.
На панели инструментов "Управляемые удостоверения" нажмите кнопку "Создать".

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

Свойство	Обязательное поле	значение	Описание
Подписка	Да	<имя-подписки-Azure>	Имя подписки Azure
Группа ресурсов	Да	<имя-группы-ресурсов-Azure>	Имя группы ресурсов Azure. Создайте группу или выберите имеющуюся. В этом примере создается новая группа с именем fabrikam-managed-identities-RG.
Регион	Да	<Azure-region>	Регион Azure, в котором будут храниться сведения о приложении логики. В этом примере используется регион западная часть США.
Имя	Да	<user-assigned-identity-name>	Имя, присваиваемое удостоверению. В этом примере используется fabrikam-user-assigned-identity.

После проверки этих сведений Azure создает управляемое удостоверение. Теперь можно добавить назначаемое пользователем удостоверение в ресурс приложения логики.

Добавление назначаемого пользователем удостоверения в приложение логики с помощью портала Azure

Потребление
Стандартные

В портал Azure откройте ресурс приложения логики потребления.
В меню приложения логики в разделе Параметры выберите Идентификатор.
На странице "Удостоверение" выберите "Пользователь", а затем нажмите кнопку "Добавить".
На панели Добавление управляемого удостоверения, назначаемого пользователем сделайте следующее:
1. В списке "Выбор подписки " выберите подписку Azure.
2. В списке со всеми управляемыми удостоверениями в подписке выберите нужное удостоверение, назначаемое пользователем. Чтобы отфильтровать список, в поле поиска Назначенные пользователем управляемые удостоверения нужно будет ввести имя удостоверения или группы ресурсов.
3. Закончив, нажмите кнопку Добавить.
  
  Примечание.
  
  Если вы получаете сообщение об ошибке, уведомляющее, что может быть активно только одно управляемое удостоверение, это значит, что приложение логики уже связано с назначенным системой удостоверением. Прежде чем можно будет добавить назначаемое пользователем удостоверение, нужно сначала отключить назначаемое системой удостоверение.
Теперь приложение логики связано с удостоверением, назначенным пользователем.
Теперь выполните действия, которые предоставляют удостоверению доступ к ресурсу далее в этом руководстве.

Создание назначаемого пользователем удостоверения с помощью шаблона ARM

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

В разделе ресурсов шаблона определение ресурса приложения логики требует следующих элементов:

Объект identity с свойством type, заданным для UserAssigned
Дочерний объект userAssignedIdentities , указывающий назначенный пользователем ресурс и имя

Потребление
Стандартные

В этом примере показан ресурс приложения логики потребления и определение рабочего процесса для HTTP-запроса PUT с непараметризованным объектом удостоверения . Ответ на запрос PUT и последующую операцию GET также включает этот объект удостоверения :

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {<template-parameters>},
   "resources": [
      {
         "apiVersion": "2016-06-01",
         "type": "Microsoft.logic/workflows",
         "name": "[variables('logicappName')]",
         "location": "[resourceGroup().location]",
         "identity": {
            "type": "UserAssigned",
            "userAssignedIdentities": {
               "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-assigned-identity-name>": {}
            }
         },
         "properties": {
            "definition": {<logic-app-workflow-definition>}
         },
         "parameters": {},
         "dependsOn": []
      },
   ],
   "outputs": {}
}

Если шаблон также включает определение ресурса управляемого удостоверения, можно параметризовать объект удостоверения . В следующем примере показано, как дочерний объект userAssignedIdentities ссылается на переменную userAssignedIdentityName, определяемую в разделе переменных шаблона. Эта переменная ссылается на идентификатор ресурса для назначенного пользователю удостоверения.

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {
      "Template_LogicAppName": {
         "type": "string"
      },
      "Template_UserAssignedIdentityName": {
         "type": "securestring"
      }
   },
   "variables": {
      "logicAppName": "[parameters(`Template_LogicAppName')]",
      "userAssignedIdentityName": "[parameters('Template_UserAssignedIdentityName')]"
   },
   "resources": [
      {
         "apiVersion": "2016-06-01",
         "type": "Microsoft.logic/workflows",
         "name": "[variables('logicAppName')]",
         "location": "[resourceGroup().location]",
         "identity": {
            "type": "UserAssigned",
            "userAssignedIdentities": {
               "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', variables('userAssignedIdentityName'))]": {}
            }
         },
         "properties": {
            "definition": {<logic-app-workflow-definition>}
         },
         "parameters": {},
         "dependsOn": [
            "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', variables('userAssignedIdentityName'))]"
         ]
      },
      {
         "apiVersion": "2018-11-30",
         "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
         "name": "[parameters('Template_UserAssignedIdentityName')]",
         "location": "[resourceGroup().location]",
         "properties": {}
      }
  ]
}

Ресурс приложения логики "Стандартный" может включать и иметь как назначаемое системой удостоверение, так и несколько удостоверений, назначенных пользователем. Определение ресурса приложения логики с категорией "Стандартный" основано на определении ресурса приложения-функции Функций Azure.

В этом примере показано определение ресурса приложения логики "Стандартный" и определения рабочего процесса, включающее непараметризованный объект удостоверения :

{
   "$schema": "https://schema.management.azure.com/schemas/2019-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {<template-parameters>},
   "resources": [
      {
         "apiVersion": "2021-02-01",
         "type": "Microsoft.Web/sites/functions",
         "name": "[variables('logicappName')]",
         "location": "[resourceGroup().location]",
         "identity": {
            "type": "UserAssigned",
            "userAssignedIdentities": {
               "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-assigned-identity-name>": {}
            },
         },
         "properties": {
            "name": "[variables('appName')]",
            "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
            "hostingEnvironment": "",
            "clientAffinityEnabled": false,
            "alwaysOn": true
         },
         "parameters": {},
         "dependsOn": []
      }
   ],
   "outputs": {}
}

{
   "$schema": "https://schema.management.azure.com/schemas/2019-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {<template-parameters>},
   "resources": [
      {
         "apiVersion": "2021-02-01",
         "type": "Microsoft.Web/sites/functions",
         "name": "[variables('logicappName')]",
         "location": "[resourceGroup().location]",
         "identity": {
            "type": "UserAssigned",
            "userAssignedIdentities": {
               "[resourceId(Microsoft.ManagedIdentity/userAssignedIdentities', variables('userAssignedIdentityName'))]": {}
            }
         },
         "properties": {
            "name": "[variables('appName')]",
            "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
            "hostingEnvironment": "",
            "clientAffinityEnabled": false,
            "alwaysOn": true
         },
         "parameters": {},
         "dependsOn": [
            "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
            "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', variables('userAssignedIdentityName'))]"
         ]
      },
      {
         "apiVersion": "2018-11-30",
         "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
         "name": "[parameters('Template_UserAssignedIdentityName')]",
         "location": "[resourceGroup().location]",
         "properties": {}
      },
   ],
   "outputs": {}
}

Когда шаблон создает ресурс приложения логики, объект удостоверений содержит следующие свойства:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<resource-ID>": {
            "principalId": "<principal-ID>",
            "clientId": "<client-ID>"
        }
    }
}

Значение свойства principalId — это уникальный идентификатор удостоверения, используемого для администрирования Microsoft Entra. Значение свойства clientId — это уникальный идентификатор нового удостоверения приложения логики, который используется для указания удостоверения, используемого во время вызовов среды выполнения. Дополнительные сведения о шаблонах Azure Resource Manager и управляемых удостоверениях для Функции Azure см. в следующей документации:

Предоставление удостоверению доступа к ресурсам

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

Примечание.

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

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

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

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

В этом разделе описано, как назначить доступ на основе ролей с помощью портал Azure и шаблона Azure Resource Manager (шаблон ARM). Сведения о Azure PowerShell, Azure CLI и AZURE REST API см. в следующей документации:

Средство	Документация
Azure PowerShell	Добавление назначения роли
Azure CLI	Добавление назначения роли
Azure REST API	Добавление назначения роли

Для хранилища ключей Azure также можно создать политику доступа для управляемого удостоверения в хранилище ключей и назначить соответствующие разрешения для этого удостоверения в этом хранилище ключей. Далее в этом разделе описано, как выполнить эту задачу с помощью портала Azure. Шаблоны Resource Manager, PowerShell и Azure CLI см. в следующей документации:

Средство	Документация
Шаблон Azure Resource Manager (шаблон ARM)	Определение ресурса политики доступа Key Vault
Azure PowerShell	Назначение политики доступа Key Vault
Azure CLI	Назначение политики доступа Key Vault

Назначение доступа на основе ролей управляемому удостоверению с помощью портал Azure

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

На портале Azure откройте ресурс, в котором вы хотите использовать удостоверение.
В меню ресурсов выберите элемент Управления доступом (IAM)>Добавить>назначение ролей.

Примечание.

Если параметр Добавить назначение ролей отключен, у вас нет разрешений на назначение ролей. Дополнительные сведения см. в статье Встроенные роли Microsoft Entra.
Назначьте необходимую роль управляемому удостоверению. На вкладке Роль назначьте роль, которая предоставляет удостоверению необходимые права доступа к текущему ресурсу.

В этом примере назначьте роль Участник данных BLOB-объектов хранилища, которая включает доступ на запись для больших двоичных объектов в контейнере Службы хранилища Azure. Дополнительные сведения о конкретных ролях контейнера хранилища см. в разделе "Роли", которые могут обращаться к большим двоичным объектам в контейнере служба хранилища Azure.
Затем выберите управляемое удостоверение, для которого необходимо назначить роль. В разделе Назначение доступа для выберите Управляемое удостоверение>Добавить участников.

В зависимости от типа управляемого удостоверения выберите или укажите следующие значения:

Тип	Экземпляр службы Azure	Отток подписок	Элемент
назначаемые системой;	Приложение логики	<имя-подписки-Azure>	<your-logic-app-name>
назначаемые пользователями.	Нет данных	<имя-подписки-Azure>	<your-user-assigned-identity-name>

Дополнительные сведения о назначении ролей см. в разделе "Назначение ролей" с помощью портал Azure.

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

Дополнительные сведения об этой задаче см. в статье "Назначение доступа к управляемому удостоверению" к ресурсу Azure или другому ресурсу.

Создание политики доступа с помощью портал Azure

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

На портале Azure откройте целевой ресурс, в котором вы хотите использовать удостоверение. В этом примере в качестве целевого ресурса используется хранилище ключей Azure.
В меню ресурсов выберите "Создать политики доступа", которая открывает область "Создать политику> доступа".

Примечание.

Если у ресурса нет параметра Политики доступа, попробуйте вместо этого присвоить назначение ролей.
На вкладке Разрешения выберите разрешения, которые необходимы удостоверению для доступа к целевому ресурсу.

Например, чтобы использовать удостоверение с операцией секретов списка управляемых соединителей Azure Key Vault, удостоверение должно иметь разрешения списка. Поэтому в столбце Разрешения секретов выберите Список.
Затем нажмите кнопку Далее. На вкладке Субъект найдите и выберите управляемое удостоверение, которым в этом примере является назначаемое пользователем удостоверение.
Пропустите необязательный шаг Приложения, нажмите кнопку Далее и завершите создание политики доступа.

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

Подтверждение подлинности доступа на основе управляемых удостоверений

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

Внимание

Если у вас есть функция Azure, в которой вы хотите использовать назначаемое системой удостоверение, сначала включите проверку подлинности для Функций Azure.

Ниже показано, как использовать управляемое удостоверение с триггером или действием с помощью портал Azure. Сведения об указании управляемого удостоверения в базовом определении JSON триггера или действия см. в разделе проверки подлинности управляемого удостоверения.

Потребление
Стандартные

В портал Azure откройте ресурс приложения логики потребления.
Если вы еще не сделали этого, добавьте триггер или действие, поддерживающее управляемые удостоверения.

Примечание.

Не все операции соединителя поддерживают добавление типа проверки подлинности. Подробная информация содержится в статье Типы проверки подлинности для триггеров и действий, поддерживающих такую функцию.
Выполните следующие действия с добавленным триггером или действием:
- Встроенные операции соединителя, поддерживающие проверку подлинности управляемого удостоверения
  
  Эти действия продолжаются с помощью действия HTTP в качестве примера.
  1. В списке расширенных параметров добавьте свойство Authentication , если свойство еще не отображается.
    
    Теперь в действии отображаются как свойство проверки подлинности, так и список типов проверки подлинности.
  2. В списке типов проверки подлинности выберите управляемое удостоверение.
    
    Теперь в разделе проверки подлинности показаны следующие параметры:
    - Список управляемых удостоверений, из которого можно выбрать определенное управляемое удостоверение.
    - Свойство Аудитории отображается на определенных триггерах и действиях, чтобы задать идентификатор ресурса для целевого ресурса или службы Azure. В противном случае по умолчанию свойство аудитории будет использовать идентификатор ресурса https://management.azure.com/, который представляет собой идентификатор ресурса для Azure Resource Manager.
  3. В списке управляемых удостоверений выберите удостоверение, которое вы хотите использовать, например:
    
    Примечание.
    
    Выбранный по умолчанию параметр — управляемое удостоверение, назначаемое системой, даже если у вас нет управляемых удостоверений.
    
    Чтобы успешно использовать управляемое удостоверение, необходимо сначала включить это удостоверение в приложении логики. В приложении логики потребления можно иметь управляемое удостоверение, назначаемое системой или назначаемое пользователем, но не оба.
  Дополнительные сведения см. в разделе Пример проверки подлинности встроенного триггера или действия с управляемым удостоверением.
- Операции с управляемым соединителем, поддерживающие проверку подлинности с использованием управляемого удостоверения
  1. В области "Создание подключения" в списке проверки подлинности выберите управляемое удостоверение, например:
  2. На следующей панели в поле "Имя подключения" укажите имя, используемое для подключения.
  3. Для типа проверки подлинности выберите один из следующих вариантов на основе управляемого соединителя:
    - Одиночная проверка подлинности: эти соединители поддерживают только один тип проверки подлинности, который является управляемым удостоверением в данном случае.
      1. В списке управляемых удостоверений выберите текущее управляемое удостоверение с поддержкой.
      2. Когда вы будете готовы, нажмите кнопку "Создать".
    - Многофакторная проверка подлинности: эти соединители поддерживают несколько типов проверки подлинности, но вы можете выбрать и использовать только один тип одновременно.
      
      Эти действия продолжаются с помощью действия Хранилище BLOB-объектов Azure в качестве примера.
      1. В списке типов проверки подлинности выберите "Управляемое удостоверение Logic Apps".
      2. Когда вы будете готовы, нажмите кнопку "Создать".
    Дополнительные сведения см. в разделе Пример проверки подлинности триггера или действия управляемых соединителей с управляемым удостоверением.

На портале Azure откройте свой ресурс приложения логики категории "Стандартный".
Если вы еще не сделали этого, добавьте триггер или действие, поддерживающее управляемые удостоверения.

Примечание.

Не все триггеры и действия поддерживают добавление типа проверки подлинности. Подробная информация содержится в статье Типы проверки подлинности для триггеров и действий, поддерживающих такую функцию.
Выполните следующие действия с добавленным триггером или действием:
- Встроенные операции, поддерживающие проверку подлинности с использованием управляемого удостоверения
  
  Эти действия продолжаются с помощью действия HTTP в качестве примера.
  1. В списке расширенных параметров добавьте свойство Authentication , если свойство еще не отображается.
    
    Теперь в действии отображаются как свойство проверки подлинности, так и список типов проверки подлинности.
  2. В списке типов проверки подлинности выберите управляемое удостоверение.
    
    Теперь в разделе проверки подлинности показаны следующие параметры:
    - Список управляемых удостоверений, из которого можно выбрать определенное управляемое удостоверение.
    - Свойство Аудитории отображается на определенных триггерах и действиях, чтобы задать идентификатор ресурса для целевого ресурса или службы Azure. В противном случае по умолчанию свойство аудитории будет использовать идентификатор ресурса https://management.azure.com/, который представляет собой идентификатор ресурса для Azure Resource Manager.
  3. В списке управляемых удостоверений выберите удостоверение, которое вы хотите использовать, например:
    
    Примечание.
    
    Выбранный по умолчанию параметр — управляемое удостоверение, назначаемое системой, даже если у вас нет управляемых удостоверений.
    
    Чтобы успешно использовать управляемое удостоверение, необходимо сначала включить это удостоверение в приложении логики. В приложении логики уровня "Стандартный" можно определить и включить управляемое удостоверение, назначаемое системой, и назначаемое пользователем. Однако приложение логики должно одновременно использовать только одно управляемое удостоверение.
    
    Например, рабочий процесс, в который входит разные Служебная шина Azure сущности обмена сообщениями, должны использовать только одно управляемое удостоверение. См. статью "Подключение к Служебная шина Azure из рабочих процессов".
  Дополнительные сведения см. в разделе Пример проверки подлинности встроенного триггера или действия с управляемым удостоверением.
- Операции с управляемым соединителем, поддерживающие проверку подлинности с использованием управляемого удостоверения
  1. В области "Создание подключения" в списке проверки подлинности выберите управляемое удостоверение, например:
  2. На следующей панели в поле "Имя подключения" укажите имя, используемое для подключения.
  3. Для типа проверки подлинности выберите один из следующих вариантов на основе управляемого соединителя:
    - Одиночная проверка подлинности: эти соединители поддерживают только один тип проверки подлинности, который является управляемым удостоверением в данном случае.
      1. В списке управляемых удостоверений выберите текущее управляемое удостоверение с поддержкой.
      2. Когда вы будете готовы, нажмите кнопку "Создать".
    - Многофакторная проверка подлинности: эти соединители поддерживают несколько типов проверки подлинности, но вы можете выбрать и использовать только один тип одновременно.
      
      Эти действия продолжаются с помощью действия Хранилище BLOB-объектов Azure в качестве примера.
      1. В списке типов проверки подлинности выберите "Управляемое удостоверение Logic Apps".
      2. В списке Управляемое удостоверение выберите удостоверение, которое хотите использовать.
      3. Когда вы будете готовы, нажмите кнопку "Создать".
    Дополнительные сведения см. в разделе Пример проверки подлинности триггера или действия управляемых соединителей с управляемым удостоверением.

Пример проверки подлинности встроенного триггера или действия с управляемым удостоверением

Встроенный триггер или действие HTTP могут использовать назначаемое системой удостоверение, включенное для ресурса приложения логики. Как правило, триггер или действие HTTP используют следующие свойства для указания ресурса или сущности, к которым требуется получить доступ:

Свойство	Обязательное поле	Описание
Method	Да	Метод HTTP, используемый операцией, которую необходимо выполнить
URI-адрес	Да	URL-адрес конечной точки для доступа к целевому ресурсу или сущности Azure. Синтаксис URI обычно включает идентификатор ресурса для целевого ресурса Или службы Azure.
Заголовки	No	Любые значения заголовка, которые требуется включить в исходящий запрос, например тип содержимого
Запросы	No	Любые параметры запроса, которые необходимо включить в запрос. Например, параметры запроса для определенной операции или версии API операции, которую требуется выполнить.
Аутентификация	Да	Тип проверки подлинности, используемый для проверки подлинности доступа к целевому ресурсу или службе Azure

В качестве конкретного примера предположим, что вы хотите выполнить операцию со снимком BLOB-объекта на большом двоичном объекте в учетной записи хранилища Azure, где вы ранее настроили доступ к удостоверению. Однако соединитель хранилища BLOB-объектов Azure в настоящее время не поддерживает эту операцию. Вместо этого операцию можно выполнить с помощью действия HTTP или другой операции REST API службы BLOB-объектов.

Внимание

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

Чтобы запустить операцию blob-объекта моментального снимка, действие HTTP указывает следующие свойства:

Свойство	Обязательное поле	Пример значения	Description
URI-адрес	Да	`https://<storage-account-name>/<folder-name>/{name}`	Идентификатор ресурса для файла хранилища BLOB-объектов Azure в глобальной (общедоступной) среде Azure, который использует этот синтаксис
Method	Да	`PUT`	Метод HTTP, используемый операцией снимка BLOB-объекта
Заголовки	Для службы хранилища Azure	`x-ms-blob-type` = `BlockBlob` `x-ms-version` = `2024-05-05` `x-ms-date` = `formatDateTime(utcNow(),'r')`	Значения заголовков `x-ms-blob-type`, `x-ms-version` и `x-ms-date`, необходимые для операций службы хранилища Azure. Важно. В исходящих запросах триггера HTTP и действия для служба хранилища Azure заголовок требует `x-ms-version` свойства и версии API для выполнения операции. Значение `x-ms-date` должно быть текущей датой. Иначе рабочий процесс выдаст ошибку `403 FORBIDDEN`. Чтобы получить текущую дату в требуемом формате, можно использовать пример. Дополнительные сведения см. в следующей документации: - Заголовок запроса — снимок BLOB-объекта - Управление версиями для служб хранилища Azure
Запросы	Только для операции Snapshot Blob	`comp` = `snapshot`	Название и значение параметра запроса для операции.

Потребление
Стандартные

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

В следующем примере показан пример действия HTTP со всеми ранее описанными значениями свойств, которые используются для операции создания моментального снимка BLOB-объекта:
В действии HTTP добавьте свойство Authentication . В списке дополнительных параметров выберите "Проверка подлинности".

Теперь раздел проверки подлинности отображается в действии HTTP .

Примечание.

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

Например, чтобы пройти проверку подлинности доступа к ресурсу Key Vault в глобальном облаке Azure, необходимо задать для свойства Аудитории именно следующий идентификатор ресурса:https://vault.azure.net

Если свойство Аудитории не задано по умолчанию, свойство Аудитории использует https://management.azure.com/ идентификатор ресурса, который является идентификатором ресурса для Azure Resource Manager.

Внимание

Убедитесь, что идентификатор целевого ресурса точно соответствует значению, которое ожидает идентификатор Microsoft Entra. В противном случае может возникнуть 400 Bad Request ошибка или 401 Unauthorized ошибка. Таким образом, если идентификатор ресурса включает в себя все конечные косые черты, обязательно включите их. В противном случае не включайте их.

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

В этом примере свойству аудитории присваивается значение https://storage.azure.com/, чтобы маркеры доступа, используемые для проверки подлинности, были допустимы для всех учетных записей хранения. Однако можно также указать URL-адрес корневой службы для конкретной учетной записи хранения, https://<your-storage-account>.blob.core.windows.net.

Дополнительные сведения о авторизации доступа с помощью идентификатора Microsoft Entra для служба хранилища Azure см. в следующей документации:
- Авторизация доступа к большим двоичным объектам Azure и очередям с помощью идентификатора Microsoft Entra
- Авторизация доступа к служба хранилища Azure с помощью OAuth
Продолжайте создание рабочего процесса нужным вам образом.

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

В следующем примере показан пример действия HTTP со всеми ранее описанными значениями свойств, которые используются для операции создания моментального снимка BLOB-объекта:
В действии HTTP добавьте свойство Authentication . В списке дополнительных параметров выберите "Проверка подлинности".

Теперь раздел проверки подлинности отображается в действии HTTP .

Примечание.

Не все триггеры и действия поддерживают добавление типа проверки подлинности. Подробная информация содержится в статье Типы проверки подлинности для триггеров и действий, поддерживающих такую функцию.
В списке Проверка подлинности выберите Управляемое удостоверение.
В списке управляемых удостоверений выберите доступные параметры в зависимости от вашего сценария.
- Если вы настроили удостоверение, назначаемое системой, выберите управляемое удостоверение, назначаемое системой.
- Если вы настроили удостоверение, назначаемое пользователем, выберите это удостоверение.
Этот пример продолжится с управляемым удостоверением, назначаемым системой.
В некоторых триггерах и действиях отображается свойство Аудитории, чтобы задать идентификатор ресурса для целевого ресурса или службы Azure.

Например, чтобы пройти проверку подлинности доступа к ресурсу Key Vault в глобальном облаке Azure, необходимо задать для свойства Аудитории именно следующий идентификатор ресурса:https://vault.azure.net

Если свойство Аудитории не задано по умолчанию, свойство Аудитории использует https://management.azure.com/ идентификатор ресурса, который является идентификатором ресурса для Azure Resource Manager.

Внимание

Убедитесь, что идентификатор целевого ресурса точно соответствует значению, которое ожидает идентификатор Microsoft Entra. В противном случае может возникнуть 400 Bad Request ошибка или 401 Unauthorized ошибка. Таким образом, если идентификатор ресурса включает в себя все конечные косые черты, обязательно включите их. В противном случае не включайте их.

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

В этом примере свойству аудитории присваивается значение https://storage.azure.com/, чтобы маркеры доступа, используемые для проверки подлинности, были допустимы для всех учетных записей хранения. Однако можно также указать URL-адрес корневой службы для конкретной учетной записи хранения, https://<your-storage-account>.blob.core.windows.net.

Дополнительные сведения о авторизации доступа с помощью идентификатора Microsoft Entra для служба хранилища Azure см. в следующей документации:
- Авторизация доступа к большим двоичным объектам Azure и очередям с помощью идентификатора Microsoft Entra
- Авторизация доступа к служба хранилища Azure с помощью OAuth
Продолжайте создание рабочего процесса нужным вам образом.

Пример проверки подлинности триггера или действия управляемых соединителей с управляемым удостоверением

Управляемый соединитель Azure Resource Manager имеет действие с именем "Чтение ресурса", которое может использовать управляемое удостоверение, которое можно включить в ресурсе приложения логики. В этом примере показано, как использовать управляемое удостоверение, назначаемое системой, с управляемым соединителем.

Потребление
Стандартные

В конструкторе рабочих процессов добавьте действие Azure Resource Manager с именем "Чтение ресурса".
На панели "Создание подключения" в списке проверки подлинности выберите "Управляемое удостоверение" и нажмите кнопку "Войти".

Примечание.

В других соединителях список типов проверки подлинности отображает управляемое удостоверение Logic Apps, поэтому выберите этот параметр.
Укажите имя подключения и выберите управляемое удостоверение, которое вы хотите использовать.

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

В этом примере единственным доступным вариантом является Назначаемое системой управляемое удостоверение.

Примечание.

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

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

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

Потребление
Стандартные

В ресурсе приложения логики потребления конфигурация подключения сохраняется в объекте определения parameters ресурса, который содержит $connections объект, содержащий указатели на идентификатор ресурса подключения, а также идентификатор ресурса управляемого удостоверения при включении удостоверения, назначаемого пользователем.

В этом примере показана parameters конфигурация объекта, когда приложение логики включает удостоверение, назначаемое системой:

"parameters": {
   "$connections": {
      "value": {
         "<action-name>": {
            "connectionId": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>",
            "connectionName": "<connector-name>",
            "connectionProperties": {
               "authentication": {
                  "type": "ManagedServiceIdentity"
               }
            },
            "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/<managed-connector-type>"
         }
      }
   }
}

В этом примере показана parameters конфигурация объекта, когда приложение логики включает управляемое удостоверение, назначаемое пользователем:

"parameters": {
   "$connections": {
      "value": {
         "<action-name>": {
            "connectionId": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>",
            "connectionName": "<connector-name>",
            "connectionProperties": {
               "authentication": {
                  "type": "ManagedServiceIdentity",
                  "identity": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/microsoft.managedidentity/userassignedidentities/<managed-identity-name>"
               }
            },
            "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/<managed-connector-type>"
         }
      }
   }
}

В ресурсе приложения логики уровня "Стандартный" конфигурация подключения сохраняется в файле ресурса приложения логики или проекта connections.json , который содержит managedApiConnections сведения о конфигурации подключения для каждого управляемого соединителя, используемого в рабочем процессе. Эти сведения о подключении включают указатели на идентификатор ресурса подключения вместе со свойствами управляемого удостоверения, такими как идентификатор ресурса при включении удостоверения, назначаемого пользователем.

В этом примере показана managedApiConnections конфигурация объекта, когда приложение логики включает удостоверение, назначаемое системой:

{
    "managedApiConnections": {
        "<connector-name>": {
            "api": {
                "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/<connector-name>"
            },
            "authentication": { // Authentication for the internal token store
                "type": "ManagedServiceIdentity"
            },
            "connection": {
                "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
            },
            "connectionProperties": {
                "authentication": { // Authentication for the target resource
                    "audience": "<resource-URL>",
                    "type": "ManagedServiceIdentity"
                }
            },
            "connectionRuntimeUrl": "<connection-runtime-URL>"
        }
    }
}

В этом примере показана managedApiConnections конфигурация объекта, когда приложение логики включает удостоверение, назначаемое пользователем:

{
    "managedApiConnections": {
        "<connector-name>": {
            "api": {
                "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/<connector-name>"
            },
            "authentication": { // Authentication for the internal token store
                "type": "ManagedServiceIdentity"
            },
            "connection": {
                "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
            },
            "connectionProperties": {
                "authentication": { // Authentication for the target resource
                    "audience": "<resource-URL>",
                    "type": "ManagedServiceIdentity",
                    "identity": "<user-assigned-identity>" // Optional
                }
            },
            "connectionRuntimeUrl": "<connection-runtime-URL>"
        }
    }
}

Шаблон ARM для подключений API и управляемых удостоверений

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

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

Потребление
Стандартные

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

Одиночная проверка подлинности

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

Свойству kind задано значение V1 для приложения логики категории "Потребление".
Свойство parameterValueType имеет значение Alternative.

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_<connector-name>_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues": {},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureautomation')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_<connector-name>_name')]",
        "parameterValueSet": {},
        "parameterValueType": "Alternative"
    }
},

Множественная проверка подлинности

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

Свойству kind задано значение V1 для приложения логики категории "Потребление".
Объект parameterValueSet включает в себя свойство name, для которого задано значение managedIdentityAuth, и свойство values, для которого задан пустой объект.

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_<connector-name>_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues":{},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureblob')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_<connector-name>_name')]",
        "parameterValueSet":{
            "name": "managedIdentityAuth",
            "values": {}
        },
        "parameterValueType": "Alternative"
    }
}

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

Одиночная проверка подлинности

В этом примере показано определение базового ресурса подключения для действия соединителя, которое поддерживает только один тип проверки подлинности и использует управляемое удостоверение в рабочем процессе приложения логики уровня "Стандартный", где определение включает следующие атрибуты:

Свойству kind задано значение V2 для приложения логики категории "Стандартный".
Свойство parameterValueType имеет значение Alternative.

{
    "type": "Microsoft.Web/connections",
    "name": "[variables('connections_<connector-name>_name')]",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "location": "[parameters('location')]",
    "kind": "V2",
    "properties": {
        "alternativeParameterValues": {},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), '<connector-name>')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_<connector-name>_name')]",
        "parameterValueSet": {},
        "parameterValueType": "Alternative"
    }
},

Множественная проверка подлинности

В этом примере показано определение базового ресурса подключения для действия соединителя, которое поддерживает несколько типов проверки подлинности и использует управляемое удостоверение в рабочем процессе приложения логики "Стандартный", где определение включает следующие атрибуты:

Свойству kind задано значение V2 для приложения логики категории "Стандартный".
Объект parameterValueSet включает в себя свойство name, для которого задано значение managedIdentityAuth, и свойство values, для которого задан пустой объект.

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_<connector-name>_name')]",
    "location": "[parameters('location')]",
    "kind": "V2",
    "properties": {
        "alternativeParameterValues":{},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), '<connector-name>')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_<connector-name>_name')]",
        "parameterValueSet":{
            "name": "managedIdentityAuth",
            "values": {}
        },
        "parameterValueType": "Alternative"
    }
}

В последующем определении ресурса Microsoft.Web/connections убедитесь, что вы добавите политику доступа, указывающую определение ресурса для каждого подключения API и укажите следующие сведения:

Параметр	Описание
<имя_соединения>	Имя подключения к API, например azureblob
<object-ID>	Идентификатор объекта для удостоверения Microsoft Entra, ранее сохраненный из регистрации приложения
<ИД клиента>	Идентификатор клиента для удостоверения Microsoft Entra, ранее сохраненный из регистрации приложения

{
   "type": "Microsoft.Web/connections/accessPolicies",
   "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
   "name": "[concat('<connector-name>','/','<object-ID>')]",
   "location": "<location>",
   "dependsOn": [
      "[resourceId('Microsoft.Web/connections', parameters('<connector-name>'))]"
   ],
   "properties": {
      "principal": {
         "type": "ActiveDirectory",
         "identity": {
            "objectId": "<object-ID>",
            "tenantId": "<tenant-ID>"
         }
      }
   }
}

Дополнительные сведения см. в статье Microsoft.Web/connections/accesspolicies (шаблон ARM).

Настройка расширенного контроля над проверкой подлинности подключения API

Когда рабочий процесс приложения логики уровня "Стандартный" использует подключение API, созданное управляемым соединителем, Azure Logic Apps взаимодействует с целевым ресурсом, например учетной записью электронной почты, хранилищем ключей и т. д., с помощью двух подключений:

Подключение 1 настроено с проверкой подлинности для внутреннего хранилища токенов.
Подключение 2 настроено с проверкой подлинности для целевого ресурса.

Однако если рабочий процесс приложения логики потребления использует подключение API, подключение #1 абстрагируется от вас без каких-либо параметров конфигурации. Благодаря ресурсу приложения логики "Стандартный" вы можете управлять приложением логики и рабочими процессами. По умолчанию подключение 1 автоматически настраивается для использования назначаемого системой удостоверения.

Если в сценарии требуется более подробный контроль над проверкой подлинности подключений API, вы можете дополнительно изменить проверку подлинности для подключения #1 с удостоверения, назначаемого системой по умолчанию, на любое назначаемое пользователем удостоверение, которое вы добавили в приложение логики. Эта проверка подлинности применяется к каждому подключению API, поэтому можно смешивать назначаемые системой и пользователем удостоверения в разных подключениях к одному целевому ресурсу.

В файле connections.json приложения логики уровня "Стандартный", в котором хранятся сведения о каждом подключении API, каждое определение подключения содержит два authentication раздела, например:

"keyvault": {
   "api": {
      "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity",
   },
   "connection": {
      "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

Первый раздел authentication сопоставлен с подключением № 1.

В нем описывается проверка подлинности, используемая для взаимодействия с внутренним хранилищем маркеров. В прошлом этот раздел всегда имел значение ManagedServiceIdentity для приложения, которое развертывается в Azure и не имеет настраиваемых параметров.
Второй раздел authentication сопоставлен с подключением № 2.

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

Зачем изменять проверку подлинности для хранилища токенов?

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

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

Изменение проверки подлинности для хранилища токенов

На портале Azure откройте свой ресурс приложения логики категории "Стандартный".
В меню ресурса в разделе Рабочие процессы выберите Подключения.
На панели "Подключения" выберите представление JSON.
В редакторе JSON найдите раздел managedApiConnections, который содержит подключения API для всех рабочих процессов в ресурсе приложения логики.

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

Например, предположим, что рабочий процесс имеет подключение к Azure Key Vault:

"keyvault": {
   "api": {
      "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity"
   },
   "connection": {
      "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

В определении подключения выполните следующие действия:

Найдите первый раздел authentication. Если в этом authentication разделе нет identity свойства, приложение логики неявно использует удостоверение, назначаемое системой.
Добавьте свойство identity, используя пример на этом шаге.
Задайте в качестве значения свойства идентификатор ресурса для назначаемого пользователем удостоверения.

"keyvault": {
   "api": {
      "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity",
      // Add "identity" property here
      "identity": "/subscriptions/<Azure-subscription-ID>/resourcegroups/<resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-resource-ID>"
   },
   "connection": {
      "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

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

Например, для Azure Key Vault добавьте удостоверение в политики доступа хранилища ключей. Для Хранилища Blob-объектов Azure назначьте необходимую роль для удостоверения учетной записи хранения.

Отключение управляемого удостоверения

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

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

Примечание.

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

По возможности старайтесь не отключать удостоверение, назначаемое системой. Если вы хотите удалить доступ удостоверения к ресурсам Azure, удалите назначение ролей этого удостоверения из целевого ресурса. При удалении ресурса приложения логики Azure автоматически удаляет управляемое удостоверение из идентификатора Microsoft Entra.

В этом разделе описано использование портала Azure и шаблона Azure Resource Manager (ARM). Сведения о Azure PowerShell, Azure CLI и AZURE REST API см. в следующей документации:

Средство	Документация
Azure PowerShell	1. Удаление назначения ролей. 2. Удаление назначаемого пользователем удостоверения.
Azure CLI	1. Удаление назначения ролей. 2. Удаление назначаемого пользователем удостоверения.
Azure REST API	1. Удаление назначения ролей. 2. Удаление назначаемого пользователем удостоверения.

Дополнительные сведения см. в статье Удаление назначений ролей Azure.

Отключение управляемого удостоверения на портале Azure

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

Удаление назначений ролей

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

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

Совет

Если кнопка Удалить недоступна, скорее всего, у вас нет разрешений. Дополнительные сведения о разрешениях, которые позволяют управлять ролями для ресурсов, см. в разделе "Разрешения роли администратора" в идентификаторе Microsoft Entra.

Отключение управляемого удостоверения в ресурсе приложения логики

Откройте ресурс приложения логики на портале Azure.
В меню ресурсов приложения логики в разделе "Параметры" выберите "Удостоверение", а затем выполните действия по удостоверению:
- Выберите Назначенное системой>Включено>Сохранить. Когда Azure запросит подтверждение, выберите Да.
- Выберите Назначаемое пользователем и нужное управляемое удостоверение, а затем нажмите Удалить. Когда Azure запросит подтверждение, выберите Да.

Отключение управляемого удостоверения в шаблоне ARM

Если вы создали управляемое удостоверение приложения логики с помощью шаблона развертывания ARM, задайте свойству type элемента identity значение None.

"identity": {
   "type": "None"
}

Безопасный доступ и данные в Azure Logic Apps

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

Проверка подлинности доступа и подключений к ресурсам Azure с помощью управляемых удостоверений в Azure Logic Apps

Необходимые компоненты

Различия в управляемом удостоверении между приложениями логики "Потребление" и "Стандартный"

Где можно использовать управляемое удостоверение

Включение назначаемого системой удостоверения в портал Azure

Включение назначаемого системой удостоверения с помощью шаблона ARM

Создание назначаемого пользователем управляемого удостоверения через портал Azure

Добавление назначаемого пользователем удостоверения в приложение логики с помощью портала Azure

Создание назначаемого пользователем удостоверения с помощью шаблона ARM

Предоставление удостоверению доступа к ресурсам

Назначение доступа на основе ролей управляемому удостоверению с помощью портал Azure

Создание политики доступа с помощью портал Azure

Подтверждение подлинности доступа на основе управляемых удостоверений

Пример проверки подлинности встроенного триггера или действия с управляемым удостоверением

Пример проверки подлинности триггера или действия управляемых соединителей с управляемым удостоверением

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

Шаблон ARM для подключений API и управляемых удостоверений

Одиночная проверка подлинности

Множественная проверка подлинности

Одиночная проверка подлинности

Множественная проверка подлинности

Настройка расширенного контроля над проверкой подлинности подключения API

Зачем изменять проверку подлинности для хранилища токенов?

Изменение проверки подлинности для хранилища токенов

Отключение управляемого удостоверения

Отключение управляемого удостоверения на портале Azure

Удаление назначений ролей

Отключение управляемого удостоверения в ресурсе приложения логики

Отключение управляемого удостоверения в шаблоне ARM

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

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

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

Проверка подлинности доступа и подключений к ресурсам Azure с помощью управляемых удостоверений в Azure Logic Apps

Необходимые компоненты

Различия в управляемом удостоверении между приложениями логики "Потребление" и "Стандартный"

Где можно использовать управляемое удостоверение

Включение назначаемого системой удостоверения в портал Azure

Включение назначаемого системой удостоверения с помощью шаблона ARM

Создание назначаемого пользователем управляемого удостоверения через портал Azure

Добавление назначаемого пользователем удостоверения в приложение логики с помощью портала Azure

Создание назначаемого пользователем удостоверения с помощью шаблона ARM

Предоставление удостоверению доступа к ресурсам

Назначение доступа на основе ролей управляемому удостоверению с помощью портал Azure

Создание политики доступа с помощью портал Azure

Подтверждение подлинности доступа на основе управляемых удостоверений

Пример проверки подлинности встроенного триггера или действия с управляемым удостоверением

Пример проверки подлинности триггера или действия управляемых соединителей с управляемым удостоверением

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

Шаблон ARM для подключений API и управляемых удостоверений

Одиночная проверка подлинности

Множественная проверка подлинности

Настройка расширенного контроля над проверкой подлинности подключения API

Зачем изменять проверку подлинности для хранилища токенов?

Изменение проверки подлинности для хранилища токенов

Отключение управляемого удостоверения

Отключение управляемого удостоверения на портале Azure

Удаление назначений ролей

Отключение управляемого удостоверения в ресурсе приложения логики

Отключение управляемого удостоверения в шаблоне ARM

Связанный контент

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

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