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

Статья
12/09/2023

Область применения: 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 - Среда службы интеграции (ISE)	— Приложение логики может включить удостоверение, назначаемое системой, или удостоверение, назначаемое пользователем. — Управляемое удостоверение можно использовать на уровне ресурса приложения логики и на уровне подключения. — Если вы включите удостоверение, назначаемое пользователем, приложение логики может одновременно иметь только одно удостоверение, назначаемое пользователем.
Standard	— Azure Logic Apps с одним клиентом — Среда службы приложений версии 3 (ASEv3) - Logic Apps с поддержкой Azure Arc	— Вы можете включить как назначаемое системой удостоверение, которое включено по умолчанию, так и удостоверение, назначаемое пользователем, одновременно. — Управляемое удостоверение можно использовать на уровне ресурса приложения логики и на уровне подключения. — Если вы включите удостоверение, назначаемое пользователем, ресурс приложения логики может одновременно иметь несколько удостоверений, назначенных пользователем.

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

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

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

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

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

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

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

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

Встроенный

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

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

Управляемое

— служба приложение Azure
- служба автоматизации Azure
- Хранилище BLOB-объектов Azure
— Экземпляр контейнера Azure
— Azure Cosmos DB
— Обозреватель данных Azure
- Фабрика данных Azure
— Azure Data Lake
- Сетка событий Azure
- Центры событий Azure
— Azure IoT Central V2
— Azure IoT Central версии 3
— Azure Key Vault
— Azure Log Analytics
— Очереди Azure
— Azure Resource Manager
- Служебная шина Azure
— Azure Sentinel
— Таблица Azure служба хранилища
— виртуальная машина Azure
— HTTP с идентификатором Microsoft Entra
- 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 - Центры событий Azure — Azure IoT Central V2 — Azure IoT Central версии 3 — Azure Key Vault — Azure Log Analytics — Очереди Azure — Azure Resource Manager - Служебная шина Azure — Azure Sentinel — Таблица Azure служба хранилища — виртуальная машина Azure — HTTP с идентификатором Microsoft Entra - SQL Server

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

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

Встроенный

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

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

Управляемое

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

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

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

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

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

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

Screenshot shows Azure portal, Consumption logic app, Identity page, and System assigned tab with selected options, On and Save.

Примечание.

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

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

Screenshot shows Consumption logic app, Identity page, and object ID for system-assigned identity.

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

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

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

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

Screenshot shows Azure portal, Standard logic app, Identity page, and System assigned tab with selected options for On and Save.

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

Screenshot shows Standard logic app, Identity page, and object ID for system-assigned identity.

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

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

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

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

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

{
   "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 получает следующие дополнительные свойства:

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

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

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

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

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

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

Screenshot shows page named Create User Assigned Managed Identity, with managed identity details.

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

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

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

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

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

{
   "$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": {}
}

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

{
   "$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.

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

{
   "$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 включает следующие свойства:

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

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

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

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

Примечание.

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

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

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

Например, чтобы получить доступ к учетной записи Хранилища BLOB-объектов 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 RBAC.

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

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

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

Примечание.

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

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

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

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

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

Важно!

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

В этой пошаговой инструкции показано, как использовать управляемое удостоверение с триггером или действием через портал Azure. Сведения об указании управляемого удостоверения в базовом определении JSON триггера или действия см. в разделе проверки подлинности управляемого удостоверения.

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

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

Примечание.

Не все операции соединителя поддерживают добавление типа проверки подлинности. Подробная информация содержится в статье Типы проверки подлинности для триггеров и действий, поддерживающих такую функцию.
Выполните следующие действия с добавленным триггером или действием:
- Встроенные операции соединителя, поддерживающие проверку подлинности управляемого удостоверения
  1. В списке Добавить новый параметр добавьте свойство Проверка подлинности, если оно еще не отображается.
  2. В списке Тип проверки подлинности выберите Управляемое удостоверение.
  Дополнительные сведения см. в разделе Пример проверки подлинности встроенного триггера или действия с управляемым удостоверением.
- Операции с управляемым соединителем, поддерживающие проверку подлинности с использованием управляемого удостоверения
  1. На странице выбора арендатора выберите Подключение с помощью управляемого удостоверения, например:
  2. На следующей странице в поле Имя подключения введите имя, которое будет использоваться для подключения.
  3. Для типа проверки подлинности выберите один из следующих вариантов на основе управляемого соединителя:
    - Одиночная проверка подлинности: эти соединители поддерживают только один тип проверки подлинности. В списке Управляемое удостоверение выберите управляемое удостоверение, включенное в настоящее время, если оно еще не выбрано, а затем нажмите кнопку Создать, например:
    - Множественная проверка подлинности: эти соединители предоставляют несколько типов проверки подлинности, но выбрать все равно можно только один тип. В списке Тип проверки подлинности выберите Управляемое удостоверение Logic Apps>Создать, например:
    Дополнительные сведения см. в разделе Пример проверки подлинности триггера или действия управляемых соединителей с управляемым удостоверением.

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

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

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

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

Важно!

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

Для запуска операции снимка BLOB-объекта в действии HTTP указываются следующие свойства:

Свойство	Обязательное поле	Пример значения	Description
Метод	Да	`PUT`	Метод HTTP, используемый операцией снимка BLOB-объекта
URI-адрес	Да	`https://<storage-account-name>/<folder-name>/{name}`	Идентификатор ресурса для файла хранилища BLOB-объектов Azure в глобальной (общедоступной) среде Azure, который использует этот синтаксис
Заголовки	Для службы хранилища Azure	`x-ms-blob-type` = `BlockBlob` `x-ms-version` = `2019-02-02` `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 со всеми ранее описанными значениями свойств, которые используются для операции создания моментального снимка BLOB-объекта:

Screenshot shows Azure portal, Consumption workflow, and HTTP action set up to access resources.

Затем добавьте свойство Проверка подлинности в действие HTTP. Из списка Добавить новый параметр выберите Проверка подлинности.

Примечание.

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

Например, если вы хотите аутентифицировать доступ к ресурсу Key Vault в глобальном облаке Azure, вам необходимо задать для свойства Аудитория значение, в точности равное следующему идентификатору ресурса: https://vault.azure.net. У этого идентификатора ресурса нет косой черты в конце. Если ее использовать, это может привести к ошибке 400 Bad Request или 401 Unauthorized.

Важно!

Убедитесь, что идентификатор целевого ресурса точно соответствует ожидаемому идентификатору Microsoft Entra ID, включая все необходимые конечные косые черты. Например, для идентификатора ресурса для всех учетных записей хранилища 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 с помощью идентификатора Microsoft Entra
Продолжайте создание рабочего процесса нужным вам образом.

Screenshot shows Azure portal, Standard workflow, and HTTP action set up to access resources.

Затем добавьте свойство Проверка подлинности в действие HTTP. Из списка Добавить новый параметр выберите Проверка подлинности.

Примечание.

Не все триггеры и действия поддерживают добавление типа проверки подлинности. Подробная информация содержится в статье Типы проверки подлинности для триггеров и действий, поддерживающих такую функцию.
В списке Тип проверки подлинности выберите Управляемое удостоверение.
В списке управляемых удостоверений выберите пункт Назначаемое системой управляемое удостоверение, если он еще не выбран.
Для некоторых триггеров и действий также отображается свойство Аудитория для задания идентификатора целевого ресурса. Задайте для свойства аудитории значение идентификатора ресурса целевого ресурса или службы. В противном случае по умолчанию свойство аудитории будет использовать идентификатор ресурса https://management.azure.com/, который представляет собой идентификатор ресурса для Azure Resource Manager.

Например, если вы хотите аутентифицировать доступ к ресурсу Key Vault в глобальном облаке Azure, вам необходимо задать для свойства Аудитория значение, в точности равное следующему идентификатору ресурса: https://vault.azure.net. У этого идентификатора ресурса нет косой черты в конце. Если ее использовать, это может привести к ошибке 400 Bad Request или 401 Unauthorized.

Важно!

Убедитесь, что идентификатор целевого ресурса точно соответствует ожидаемому идентификатору Microsoft Entra ID, включая все необходимые конечные косые черты. Например, для идентификатора ресурса для всех учетных записей хранилища 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 с помощью идентификатора Microsoft Entra
Продолжайте создание рабочего процесса нужным вам образом.

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

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

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

После добавления действия в рабочий процесс и выбора клиента Microsoft Entra выберите Подключение с управляемым удостоверением.
На странице имени подключения укажите имя подключения и выберите нужное управляемое удостоверение.

Действие Azure Resource Manager — это действие с одной проверкой подлинности, поэтому в поле сведений о подключении отображается список управляемых удостоверений , который автоматически выбирает управляемое удостоверение, которое в настоящее время включено в ресурсе приложения логики. Если включено управляемое удостоверение, назначаемое системой, в списке Управляемое удостоверение выбирается Назначаемое системой управляемое удостоверение. Если вместо этого вы включили управляемое удостоверение, назначаемое пользователем, в списке будет выбрано это удостоверение.

Если вы используете триггер или действие с несколькими проверками подлинности, например Хранилище BLOB-объектов Azure, в поле сведений о подключении отображается список типов проверки подлинности, включающий параметр "Управляемое удостоверение Logic Apps" среди других типов проверки подлинности.

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

Примечание.

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

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

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

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

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

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

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

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

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

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

{
    "managedApiConnections": {
        "<connector-name>": {
            "api": {
                "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{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/<connection-name>"
            },
            "connectionProperties": {
                "authentication": { // Authentication for the target resource
                    "audience": "<resource-URL>",
                    "type": "ManagedServiceIdentity"
                }
            },
            "connectionRuntimeUrl": "<connection-runtime-URL>"
        }
    }
}

{
    "managedApiConnections": {
        "<connector-name>": {
            "api": {
                "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{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/<connection-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, которое создается управляемым соединителем, таким как Office 365 Outlook, Azure Key Vault и т. п., где используется управляемое удостоверение, вам нужно выполнить дополнительный шаг.

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

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

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

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

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

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

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_azureautomation_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_azureautomation_name')]",
        "parameterValueSet": {},
        "parameterValueType": "Alternative"
    }
},

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

В этом примере показано базовое определение ресурса подключения для действия Хранилища BLOB-объектов Azure в приложении логики категории "Потребление", которое использует управляемое удостоверение, при этом данное определение включает в себя следующие атрибуты:

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

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_azureblob_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_azureblob_name')]",
        "parameterValueSet":{
            "name": "managedIdentityAuth",
            "values": {}
        },
        "parameterValueType": "Alternative"
    }
}

Приведенные ниже примеры относятся к приложениям логики категории "Стандартный" и показывают, как базовое определение ресурса соединителя различается у соединителя с одиночной проверкой подлинности, такого как служба автоматизации Azure, и соединителя с множественной проверкой подлинности, такого как Хранилище BLOB-объектов Azure.

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

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

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

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

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

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

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

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_azureblob_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_azureblob_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('<connection-name>','/','<object-ID>')]",
   "location": "<location>",
   "dependsOn": [
      "[resourceId('Microsoft.Web/connections', parameters('connection_name'))]"
   ],
   "properties": {
      "principal": {
         "type": "ActiveDirectory",
         "identity": {
            "objectId": "<object-ID>",
            "tenantId": "<tenant-ID>"
         }
      }
   }
}

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

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

Если рабочий процесс использует подключение API, созданное управляемым соединителем, таким как Office 365 Outlook, Azure Key Vault и т. п., служба Azure Logic Apps взаимодействует с целевым ресурсом, например с учетной записью электронной почты, хранилищем ключей и т. д., используя два подключения:

Conceptual diagram showing first connection with authentication between logic app and token store plus second connection between token store and target resource.

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

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

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

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

"keyvault": {
   "api": {
      "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity",
   },
   "connection": {
      "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-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/{region}/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity"
   },
   "connection": {
      "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-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/{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/<connection-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, у которого вы хотите удалить доступ для управляемого удостоверения.
В меню целевого ресурса выберите Управление доступом (IAM). Выберите под панелью инструментов пункт Назначение ролей.
В списке ролей выберите управляемые удостоверения, которые требуется удалить. На панели инструментов нажмите кнопку Удалить.

Совет

Если кнопка Удалить недоступна, скорее всего, у вас нет разрешений. Дополнительные сведения о разрешениях, которые позволяют управлять ролями для ресурсов, см. в разделе о разрешениях роли Администратор istrator в идентификаторе 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

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

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