Безопасный доступ и данные для рабочих процессов в Azure Logic Apps

Статья
10/15/2024

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

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

Доступ к операциям приложения логики
Доступ к входным и выходным данным журнала выполнения
Доступ к входным параметрам
Типы проверки подлинности для триггеров и действий, поддерживающих проверку подлинности
Доступ для входящих вызовов триггеров на основе запросов
Доступ для исходящих вызовов к другим службам и системам
Блокировка создания подключений для конкретных соединителей
Руководство по изоляции приложений логики
Базовый план обеспечения безопасности Azure для Azure Logic Apps

Дополнительные сведения об обеспечении безопасности в Azure см. в следующих статьях:

Доступ к операциям приложения логики

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

Рабочие процессы уровня "Потребление"

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

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

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

Стандартные рабочие процессы

Примечание.

Эта возможность входит в предварительную версию, и на нее распространяются Дополнительные условия использования предварительных версий Microsoft Azure.

Роль	Description
Средство чтения "Стандартный" Logic Apps (предварительная версия)	У вас есть доступ только для чтения ко всем ресурсам в приложении логики "Стандартный" и рабочих процессах, включая запуски рабочего процесса и их журнал.
Оператор Logic Apps standard (предварительная версия)	У вас есть доступ к включению, повторной отправке и отключению рабочих процессов и созданию подключений к службам, системам и сетям для приложения логики "Стандартный". Роль оператора может выполнять задачи администрирования и поддержки на платформе Azure Logic Apps, но не имеет разрешений на изменение рабочих процессов или параметров.
Разработчик Logic Apps уровня "Стандартный" (предварительная версия)	У вас есть доступ к созданию и изменению рабочих процессов, подключений и параметров для стандартного приложения логики. Роль разработчика не имеет разрешений на внесение изменений за пределы области рабочих процессов, например изменения на уровне приложений, например настройка интеграции виртуальной сети. Служба приложений Планы не поддерживаются.
Участник Logic Apps уровня "Стандартный" (предварительная версия)	У вас есть доступ к управлению всеми аспектами стандартного приложения логики, но вы не можете изменить доступ или владение.

Доступ к данным журнала выполнения

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

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

Для управления доступом к входным и выходным данным в журнале выполнения приложения логики доступны следующие варианты.

Ограничение доступа по диапазону IP-адресов.

Этот вариант позволяет защитить доступ к журналу выполнения на основе запросов из определенного диапазона IP-адресов.
Защита данных в журнале выполнения с помощью обфускации.

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

Ограничение доступа по диапазону IP-адресов

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

Например, чтобы запретить всем пользователям доступ к входным и выходным данным, укажите диапазон IP-адресов 0.0.0.0-0.0.0.0. Только пользователь с разрешениями администратора может удалить это ограничение, что обеспечивает возможность jit-доступа к данным в рабочих процессах приложения логики. Допустимый диапазон IP-адресов имеет формат x.x.x.x/x или x.x.x.x-x.x.x.x.

Чтобы указать допустимые диапазоны IP-адресов, выполните следующие действия для приложения логики "Потребление" или "Стандартный" в портал Azure или шаблоне Azure Resource Manager:

Портал
Шаблон Resource Manager

Рабочие процессы уровня "Потребление"

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

Стандартные рабочие процессы

На портале Azure откройте свой ресурс приложения логики категории "Стандартный".
В меню приложения логики в разделе "Параметры" выберите "Сеть".
В разделе конфигурации входящего трафика рядом с общедоступным сетевым доступом выберите "Включено" без ограничения доступа.
На странице ограничений доступа в разделе "Доступ к приложению" выберите "Включено" из выбора виртуальных сетей и IP-адресов.
В разделе "Доступ к сайту" и правила на вкладке "Основной сайт" добавьте одно или несколько правил, чтобы разрешить или запретить запросы из определенных диапазонов IP-адресов. Вы также можете использовать параметры фильтра заголовков HTTP и параметры пересылки. Допустимый диапазон IP-адресов имеет формат x.x.x.x/x или x.x.x.x-x.x.x.x.

Дополнительные сведения см. в разделе "Блокировка входящих IP-адресов" в Azure Logic Apps (цен. категория "Стандартный").

Рабочие процессы уровня "Потребление"

В шаблоне ARM укажите диапазоны IP-адресов в определении ресурса приложения логики с помощью раздела accessControl с разделом contents, например:

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {<workflow-definition>},
            "parameters": {},
            "accessControl": {
               "contents": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     },
                     {
                        "addressRange": "2001:0db8::/64"
                     }
                  ]
               }
            }
         }
      }
   ],
   "outputs": {}
}

Стандартные рабочие процессы

В шаблоне ARM укажите разрешенные диапазоны входящих IP-адресов в определении ресурса приложения логики с помощью раздела Microsoft.Web/sites/config. В этом разделе propertiesдобавьте ipSecurityRestrictions раздел и используйте ipAddressраздел , tag=Defaultaction="Deny" | "Allow"priorityи name="Ports" разделы для определения правила и задания ipAddress допустимого диапазона IP-адресов в формате x.x.x.x/x/x/x.x-x. например:

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

Защита данных в журнале выполнения с помощью обфускации

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

Безопасные входные данные — не поддерживаются	Безопасные выходные данные — не поддерживаются
Добавление к переменной массива Добавление к строковой переменной Переменная декремента Для каждого Если Переменная добавочного увеличения Инициализация переменной Повторение Размах Установка переменной Выключатель Кончать До условия	Добавление к переменной массива Добавление к строковой переменной Составлять Переменная декремента Для каждого Если Переменная добавочного увеличения Инициализация переменной Анализ JSON Повторение Ответ Размах Установка переменной Выключатель Кончать До Wait

Безопасные входные данные — не поддерживаются

Безопасные выходные данные — не поддерживаются

Добавление к переменной массива
Добавление к строковой переменной
Переменная декремента
Для каждого
Если
Переменная добавочного увеличения
Инициализация переменной
Повторение
Размах
Установка переменной
Выключатель
Кончать
До условия

Добавление к переменной массива
Добавление к строковой переменной
Составлять
Переменная декремента
Для каждого
Если
Переменная добавочного увеличения
Инициализация переменной
Анализ JSON
Повторение
Ответ
Размах
Установка переменной
Выключатель
Кончать
До
Wait

Защита входных и выходных данных в конструкторе

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

Триггер или действие теперь отображает значок блокировки в строке заголовка. Все маркеры, представляющие защищенные выходные данные из предыдущих действий, также отображают значки блокировки. Например, в последующем действии после выбора маркера для защищенных выходных данных из списка динамического содержимого этот маркер отображает значок блокировки.
После выполнения рабочего процесса можно просмотреть журнал для этого запуска.
1. Выберите "Обзор" в меню приложения логики потребления или в меню "Стандартный рабочий процесс".
2. В разделе " Журнал запусков" выберите запуск, который требуется просмотреть.
3. В области журнала выполнения рабочего процесса выберите действия, которые требуется проверить.
  
  Если вы решили скрыть входные и выходные данные, эти значения теперь будут скрыты.

Защита входных и выходных данных в представлении кода

В базовом определении триггера или действия измените массив runtimeConfiguration.secureData.properties, добавив одно из следующих значений, или сразу оба значения:

"inputs": защищает входные данные в журнале выполнения.
"outputs": защищает выходные данные в журнале выполнения.

"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

Доступ к входным параметрам

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

Например, при проверке подлинности http-действий с помощью OAuth с помощью идентификатора Microsoft Entra можно определить и скрыть параметры, принимаюющие идентификатор клиента и секрет клиента, используемые для проверки подлинности. Чтобы определить эти параметры в рабочем процессе приложения логики, используйте parameters раздел в определении рабочего процесса приложения логики и шаблоне Resource Manager для развертывания. Чтобы дополнительно защитить значения параметров и не отображать их при изменении приложения логики или просмотре журнала выполнения, определите параметры с помощью типов securestring или secureobject и с использованием кодирования при необходимости. Параметры этого типа не возвращаются с помощью определения ресурса и недоступны при просмотре ресурса после развертывания. Чтобы получить доступ к этим значениям параметров во время выполнения, используйте выражение @parameters('<parameter-name>') в определении рабочего процесса. Это выражение вычисляется только во время выполнения и описывается на языке определения рабочего процесса.

Примечание.

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

Дополнительные сведения см. в следующих разделах этой статьи:

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

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

Например, при использовании секретов можно определить и использовать защищенные параметры шаблона, которые извлекают эти секреты из Azure Key Vault при развертывании. Затем можно сослаться на хранилище ключей и секрет в файле параметров. Дополнительные сведения см. в следующих разделах:

Передача конфиденциальных значений при развертывании с помощью Azure Key Vault
Раздел Защищенные параметры в шаблонах Azure Resource Manager далее в этой статье

Безопасные параметры в определениях рабочих процессов (рабочий процесс потребления)

Чтобы защитить конфиденциальную информацию в определении рабочего процесса приложения логики, используйте защищенные параметры, чтобы эти сведения не отображались после сохранения рабочего процесса приложения логики. Предположим, например, что для действия HTTP требуется обычная проверка подлинности, в которой используются имя пользователя и пароль. В определении рабочего процесса в разделе parameters определяются параметры basicAuthPasswordParam и basicAuthUsernameParam с помощью типа securestring. Затем определение действия ссылается на эти параметры в разделе authentication.

Внимание

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

"definition": {
   "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
   "actions": {
      "HTTP": {
         "type": "Http",
         "inputs": {
            "method": "GET",
            "uri": "https://www.microsoft.com",
            "authentication": {
               "type": "Basic",
               "username": "@parameters('basicAuthUsernameParam')",
               "password": "@parameters('basicAuthPasswordParam')"
            }
         },
         "runAfter": {}
      }
   },
   "parameters": {
      "basicAuthPasswordParam": {
         "type": "securestring"
      },
      "basicAuthUsernameParam": {
         "type": "securestring"
      }
   },
   "triggers": {
      "manual": {
         "type": "Request",
         "kind": "Http",
         "inputs": {
            "schema": {}
         }
      }
   },
   "contentVersion": "1.0.0.0",
   "outputs": {}
}

Безопасные параметры в шаблонах Azure Resource Manager (рабочий процесс потребления)

Шаблон Resource Manager для ресурса приложения логики и рабочего процесса содержит несколько parameters разделов. Для защиты паролей, ключей, секретов и других конфиденциальных данных определите защищенные параметры на уровне шаблона и определения рабочего процесса с помощью типа securestring или secureobject. Затем эти значения можно сохранить в Azure Key Vault и использовать файл параметров для ссылки на хранилище ключей и секрет. Затем шаблон извлекает эти сведения при развертывании. Дополнительные сведения см. в статье Передача конфиденциальных значений при развертывании с помощью Azure Key Vault.

Внимание

Этот список содержит дополнительные сведения об этих разделах parameters:

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

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

Наименование параметра	Description
`TemplatePasswordParam`	Параметр шаблона, принимающий пароль, который затем передается в параметр `basicAuthPasswordParam` определения рабочего процесса
`TemplateUsernameParam`	Параметр шаблона, принимающий имя пользователя, которое затем передается в параметр `basicAuthUserNameParam` определения рабочего процесса
`basicAuthPasswordParam`	Параметр определения рабочего процесса, который принимает пароль для обычной проверки подлинности в действии HTTP
`basicAuthUserNameParam`	Параметр определения рабочего процесса, который принимает имя пользователя для обычной проверки подлинности в действии HTTP

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {
      "LogicAppName": {
         "type": "string",
         "minLength": 1,
         "maxLength": 80,
         "metadata": {
            "description": "Name of the Logic App."
         }
      },
      "TemplatePasswordParam": {
         "type": "securestring"
      },
      "TemplateUsernameParam": {
         "type": "securestring"
      },
      "LogicAppLocation": {
         "type": "string",
         "defaultValue": "[resourceGroup().location]",
         "allowedValues": [
            "[resourceGroup().location]",
            "eastasia",
            "southeastasia",
            "centralus",
            "eastus",
            "eastus2",
            "westus",
            "northcentralus",
            "southcentralus",
            "northeurope",
            "westeurope",
            "japanwest",
            "japaneast",
            "brazilsouth",
            "australiaeast",
            "australiasoutheast",
            "southindia",
            "centralindia",
            "westindia",
            "canadacentral",
            "canadaeast",
            "uksouth",
            "ukwest",
            "westcentralus",
            "westus2"
         ],
         "metadata": {
            "description": "Location of the Logic App."
         }
      }
   },
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
               "actions": {
                  "HTTP": {
                     "type": "Http",
                     "inputs": {
                        "method": "GET",
                        "uri": "https://www.microsoft.com",
                        "authentication": {
                           "type": "Basic",
                           "username": "@parameters('basicAuthUsernameParam')",
                           "password": "@parameters('basicAuthPasswordParam')"
                        }
                     },
                  "runAfter": {}
                  }
               },
               "parameters": {
                  "basicAuthPasswordParam": {
                     "type": "securestring"
                  },
                  "basicAuthUsernameParam": {
                     "type": "securestring"
                  }
               },
               "triggers": {
                  "manual": {
                     "type": "Request",
                     "kind": "Http",
                     "inputs": {
                        "schema": {}
                     }
                  }
               },
               "contentVersion": "1.0.0.0",
               "outputs": {}
            },
            "parameters": {
               "basicAuthPasswordParam": {
                  "value": "[parameters('TemplatePasswordParam')]"
               },
               "basicAuthUsernameParam": {
                  "value": "[parameters('TemplateUsernameParam')]"
               }
            }
         }
      }
   ],
   "outputs": {}
}

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

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

Тип аутентификации	Приложение логики и поддерживаемые соединители
Базовая	Azure Управление API, служба приложение Azure, HTTP, HTTP + Swagger, веб-перехватчик HTTP
Сертификат клиента	Azure Управление API, служба приложение Azure, HTTP, HTTP + Swagger, веб-перехватчик HTTP
OAuth Active Directory (OAuth 2.0 с идентификатором Microsoft Entra)	- Использование: Azure Управление API, служба приложение Azure, Функции Azure, HTTP, HTTP + Swagger, веб-перехватчик HTTP - Стандартный: служба автоматизации Azure, Хранилище BLOB-объектов Azure, Центры событий Azure, очереди Azure, Служебная шина Azure, таблицы Azure, HTTP, веб-перехватчик HTTP, SQL Server
Raw	Azure Управление API, служба приложение Azure, Функции Azure, HTTP, HTTP + Swagger, веб-перехватчик HTTP
Управляемое удостоверение	Встроенные соединители: - Использование: Azure Управление API, служба приложение Azure, Функции Azure, HTTP, веб-перехватчик HTTP - Стандартный: служба автоматизации Azure, Хранилище BLOB-объектов Azure, Центры событий Azure, очереди Azure, Служебная шина Azure, таблицы Azure, HTTP, веб-перехватчик HTTP, SQL Server Примечание. В настоящее время большинство встроенных соединителей на основе поставщика услуг не поддерживают выбор управляемых удостоверений, назначенных пользователем для проверки подлинности. Управляемые соединители: служба приложение Azure, служба автоматизации Azure, Хранилище BLOB-объектов Azure, экземпляр контейнера Azure, Azure Cosmos DB, azure Data Explorer, Фабрика данных Azure, Azure Data Lake, Сетка событий Azure, Центры событий Azure, Azure IoT Central V2, Azure IoT Central V3, Azure Key Vault, Azure Log Analytics, Очереди Azure, Azure Resource Manager, Служебная шина Azure, Azure Sentinel, хранилище таблиц Azure, виртуальная машина Azure, HTTP с идентификатором Microsoft Entra, SQL Server

Внимание

Доступ для входящих вызовов триггеров на основе запросов

Входящий вызовы, которые приложение логики получает через триггер на основе запросов, например триггер запроса или триггер веб-перехватчика HTTP, поддерживают шифрование и защищаются с помощью протокола TLS 1.2 как минимум, известного как SSL. Azure Logic Apps применяет эту версию при получении входящего вызова триггера запроса или обратного вызова триггера веб-перехватчика HTTP или действия.

Примечание.

Если вы получаете ошибки подтверждения TLS, убедитесь в том, что используется протокол TLS 1.2. Дополнительные сведения см. в статье Решение проблемы с TLS 1.0.

Для входящих вызовов используйте следующие комплекты шифров:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Внимание

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

Например, при проверке сообщений подтверждения TLS в Azure Logic Apps или с помощью средства безопасности в URL-адресе приложения логики можно найти следующие наборы шифров. Повторюсь, не следует использовать эти устаревшие шифры:

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

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

Включение OAuth с помощью идентификатора Microsoft Entra
Создание ключей или маркеров подписанного URL-адреса (SAS)
Отключение проверки подлинности подписанного URL-адреса (SAS)
ограничение входящих IP-адресов;
Предоставление приложения логики с помощью службы управления API Azure

Включение OAuth 2.0 с идентификатором Microsoft Entra

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

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

В рабочем процессе уровня "Стандартный", который начинается с триггера запроса (но не триггера веб-перехватчика), можно использовать Функции Azure подготовку для проверки подлинности входящих вызовов, отправленных в конечную точку, созданную триггером запроса с помощью управляемого удостоверения. Эта подготовка также называется "Простая проверка подлинности". Дополнительные сведения см. в разделе "Активация рабочих процессов" в стандартных приложениях логики с помощью простой проверки подлинности.

Включите OAuth 2.0 с идентификатором Microsoft Entra в качестве единственного способа вызова конечной точки запроса (только потребление)

Для конечных точек на основе запросов можно ограничить авторизацию только OAuth 2.0 с идентификатором Microsoft Entra. Этот параметр работает даже при отключении проверки подлинности подписанного URL-адреса (SAS).

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

Примечание.

Этот шаг делает Authorization заголовок видимым в журнале выполнения рабочего процесса и в выходных данных триггера.
В портал Azure откройте рабочий процесс потребления в конструкторе.
В конструкторе выберите триггер. В открывающейся области сведений выберите "Параметры".
В разделе "Общие>условия триггера" нажмите кнопку "Добавить". В поле условия триггера введите одно из следующих выражений на основе типа токена, который требуется использовать:

@startsWith(triggerOutputs()?['headers']?['Authorization'], 'Bearer')

–или–

@startsWith(triggerOutputs()?['headers']?['Authorization'], 'PoP')

Если конечная точка триггера вызывается без правильной авторизации, журнал выполнения просто показывает триггер как Skipped без сообщения о том, что условие триггера не выполнено.

Получение маркера подтверждения владения (PoP)

Библиотеки Библиотеки проверки подлинности Майкрософт (MSAL) предоставляют маркеры PoP для использования. Если рабочий процесс приложения логики потребления, который требуется вызвать, требует маркер PoP, можно получить этот маркер с помощью библиотек MSAL. В следующих примерах показано, как получить токены PoP:

Чтобы использовать маркер PoP с рабочим процессом приложения логики потребления, выполните действия по настройке OAuth с идентификатором Microsoft Entra.

Включение OAuth с идентификатором Microsoft Entra для ресурса приложения логики потребления

Чтобы добавить политику авторизации в приложение логики потребления, выполните действия для шаблона портал Azure или Azure Resource Manager:

Портал
Шаблон Resource Manager

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

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

Свойство	Обязательное поле	Type	Описание
Имя политики	Да	Строка	Имя, которое будет использоваться для политики авторизации
Тип политики	Да	Строка	AAD для маркеров типа носителя или AADPOP для маркеров типа проверки владения.
Утверждения	Да	Строка	Пара "ключ-значение", указывающая тип утверждения и значение, которое триггер запроса рабочего процесса ожидает в маркере доступа, представленном каждым входящий вызов триггера. Вы можете добавить любое стандартное утверждение, которое вы хотите, выбрав "Добавить стандартное утверждение". Чтобы добавить утверждение, относящееся к токену PoP, выберите "Добавить настраиваемое утверждение". Доступные стандартные типы утверждений: - Издатель - Аудитория - Тема - Идентификатор JWT (идентификатор веб-маркера JSON) Требования: — Как минимум, список утверждений должен включать утверждение издателя, которое имеет значение, которое начинается с или `https://login.microsoftonline.com/` как `https://sts.windows.net/` идентификатор издателя Microsoft Entra. — Каждое утверждение должно содержать одно строковое значение, но не массив значений. Например, можно иметь утверждение с типом Role и значением Developer. Но вы не можете использовать утверждение с типом Role и двумя значениями Developer и Program Manager. Значение утверждения ограничено максимальным количеством символов. Дополнительные сведения об этих типах утверждений см . в маркерах безопасности Microsoft Entra. Можно также указать собственный тип и значение утверждения.

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

Чтобы добавить еще одно утверждение, выберите один из следующих вариантов.
- Чтобы добавить другой тип утверждения, нажмите Добавить стандартное утверждение, выберите тип утверждения и укажите его значение.
- Чтобы добавить собственное утверждение, выберите Добавить пользовательское утверждение. Дополнительные сведения см. в статье о предоставлении необязательных утверждений для приложения. После этого ваше пользовательское утверждение будет сохранено как часть идентификатора JWT, например, "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee".
Чтобы добавить еще одну политику авторизации, нажмите Добавить политику. Повторите предыдущие шаги, чтобы настроить политику.
По завершении выберите Сохранить.
Чтобы включить Authorization заголовок из маркера доступа в выходные данные триггера на основе запроса, просмотрите заголовок "Авторизация" в выходных данных триггера HTTP и триггеров веб-перехватчика HTTP.

Свойства рабочего процесса, такие как политики, не отображаются в представлении кода рабочего процесса в портал Azure. Для обращения к политикам программным способом вызовите следующий API через Azure Resource Manager (ARM): https://management.azure.com/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group-name}/providers/Microsoft.Logic/workflows/{your-workflow-name}?api-version=2016-10-01&_=1612212851820. Обязательно замените значения заполнителей на идентификатор подписки Azure, имя группы ресурсов и имя рабочего процесса.

В шаблоне ARM определите политику авторизации, выполнив следующие действия и используя следующий синтаксис:

В разделе properties определения ресурса вашего приложения логикидобавьте объект accessControl, если он не существует, который содержит объект triggers.

Дополнительные сведения об объекте accessControl см. в разделе Ограничение диапазона входящих IP-адресов в шаблоне Azure Resource Manager и в Справочнике по шаблонам рабочих процессов Microsoft.Logic.
В объекте triggers добавьте объект openAuthenticationPolicies, содержащий объект policies, в котором определена одна или несколько политик авторизации.
Укажите имя для политики авторизации, установите тип политики AAD, включите массив claims и укажите в нем один или несколько типов утверждений.

Как минимум, массив должен включать тип утверждения издателя, claims для которого задано свойство iss утвержденияname, и задать value для начала https://sts.windows.net/ или https://login.microsoftonline.com/ в качестве идентификатора издателя Microsoft Entra. Дополнительные сведения об этих типах утверждений см. в разделе "Утверждения" в маркерах безопасности Microsoft Entra. Можно также указать собственный тип и значение утверждения.
Чтобы включить заголовок Authorization из маркера доступа в выходные данные триггера на основе запроса, см. раздел Включение заголовка авторизации в выходные данные триггера запроса.

Необходимо использовать следующий синтаксис:

"resources": [
   {
      // Start logic app resource definition
      "properties": {
         "state": "<Enabled-or-Disabled>",
         "definition": {<workflow-definition>},
         "parameters": {<workflow-definition-parameter-values>},
         "accessControl": {
            "triggers": {
               "openAuthenticationPolicies": {
                  "policies": {
                     "<policy-name>": {
                        "type": "AAD",
                        "claims": [
                           {
                              "name": "<claim-name>",
                              "value": "<claim-value>"
                           }
                        ]
                     }
                  }
               }
            },
         },
      },
      "name": "[parameters('LogicAppName')]",
      "type": "Microsoft.Logic/workflows",
      "location": "[parameters('LogicAppLocation')]",
      "apiVersion": "2016-06-01",
      "dependsOn": [
      ]
   }
   // End logic app resource definition
],

Включение заголовка Authorization в выходные данные триггера запроса или веб-перехватчика HTTP

Для приложений логики, позволяющих включить OAuth с идентификатором Microsoft Entra ID для авторизации входящих вызовов для доступа к триггерам на основе запросов, можно включить триггер запроса или выходные данные триггера веб-перехватчика HTTP, чтобы включить Authorization заголовок из маркера доступа OAuth. В базовом определении JSON триггера добавьте и присвойте свойству operationOptions значение IncludeAuthorizationHeadersInOutputs. Ниже приведен пример триггера запроса :

"triggers": {
   "manual": {
      "inputs": {
         "schema": {}
      },
      "kind": "Http",
      "type": "Request",
      "operationOptions": "IncludeAuthorizationHeadersInOutputs"
   }
}

Дополнительные сведения см. в следующих разделах:

Создание ключа или маркера подписанного URL-адреса (SAS)

Когда рабочий процесс начинается с триггера на основе запроса, и вы сохраняете этот рабочий процесс в первый раз, Azure Logic Apps создает вызываемую конечную точку на этом триггере. Эта конечная точка имеет URL-адрес, который может получать входящий вызов или запросы для запуска рабочего процесса. URL-адрес включает подписанный URL-адрес (SAS), который является ключом или маркером, предоставляющим разрешения, например службам хранилища. URL-адрес конечной точки использует следующий формат:

https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>

Например, чтобы просмотреть этот URL-адрес в триггере запроса, найдите свойство HTTP-адреса триггера:

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

Полный URL-адрес выглядит следующим образом:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

SAS в URL-адресе имеет параметры запроса, описанные в следующей таблице:

Параметр запроса	Description
`sp`	Указывает разрешения для разрешенных методов HTTP.
`sv`	Указывает версию SAS, используемую для создания подписи.
`sig`	Указывает подпись, используемую для проверки подлинности доступа к триггеру. Эта подпись создается с использованием алгоритма SHA256 с секретным ключом доступа для всех URL-путей и свойств. Этот ключ хранится в секрете и шифруется, хранится в приложении логики и никогда не предоставляется или не публикуется. Приложение логики авторизует только те триггеры, которые содержат действительную подпись, созданную с помощью секретного ключа.

Внимание

Не забудьте защитить ключ SAS так же, как и ключ учетной записи от несанкционированного использования. Настройте или укажите план отзыва скомпрометированного ключа доступа. Используйте усмотрение при распространении URI, использующих ключи доступа, и распределяйте такие URI только по безопасному подключению, например HTTPS. Не забудьте выполнять только операции, использующие ключ доступа по протоколу HTTPS. Любой пользователь, имеющий универсальный код ресурса (URI) с допустимым ключом, может получить доступ к связанному ресурсу. Чтобы обеспечить безопасность и защитить доступ к рабочему процессу приложения логики, повторно создайте ключи доступа по регулярному расписанию, так как они могут потребовать соблюдения политик безопасности или скомпрометации. Таким образом, вы можете убедиться, что только авторизованные запросы могут активировать рабочий процесс, который защищает данные и процессы от несанкционированного доступа.

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

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

Если у вас есть рабочий процесс потребления, начинающийся с триггера запроса , можно отключить проверку подлинности SAS. Этот параметр работает, даже если вы также ограничиваете авторизацию только OAuth 2.0 с идентификатором Microsoft Entra. Для стандартных рабочих процессов можно использовать другие типы проверки подлинности без отключения SAS.

Дополнительные сведения о безопасности при использовании ключа SAS см. в следующих разделах в этом руководстве:

Повторное создание ключей доступа
Создание URL-адресов обратного вызова с истекающим сроком действия
Создание URL-адресов с использованием первичного или вторичного ключа

Отключение проверки подлинности подписанного URL-адреса (только для SAS) (только для потребления)

По умолчанию триггер на основе запросов включает проверку подлинности SAS. URL-адрес конечной точки триггера включает SAS, начиная с параметров запроса, sp-<permissions>sv-<SAS-version>sig=<signature>например:

Если рабочий процесс потребления начинается с триггера запроса , и вы хотите использовать OAuth с идентификатором Microsoft Entra ID, можно отключить проверку подлинности SAS, чтобы избежать ошибок и проблем, связанных с выполнением рабочего процесса. Вы также добавляете уровень безопасности, удаляя зависимость от секретов, что снижает риск при регистрации или утечке секретов.

Этот параметр работает, даже если вы также включите OAuth 2.0 с идентификатором Microsoft Entra в качестве единственного варианта для вызова конечной точки на основе запросов. Для стандартных рабочих процессов можно использовать другие типы проверки подлинности без отключения SAS.

Примечание.

Это действие отключает проверку подлинности SAS для входящих запросов и блокирует работу существующих ключей ИЛИ подписей SAS. Однако ключи или подписи SAS остаются действительными и по-прежнему работают, если снова включить проверку подлинности SAS. Сведения об отключении ключей и подписей SAS путем создания новых версий см. в разделе "Повторное создание ключей доступа".

После отключения проверки подлинности SAS URL-адрес конечной точки триггера запроса больше не включает ключ SAS, например:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01

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

Для этой задачи необходим инструмент для отправки вызовов REST API, например:

Visual Studio Code с расширением из Visual Studio Marketplace
PowerShell Invoke-RestMethod
Microsoft Edge — средство сетевой консоли
Бруно
curl

Внимание

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

Проверка триггеров с включенным или отключенным SAS

Если проверка подлинности SAS отключена, URL-адрес конечной точки триггера больше не включает ключ SAS. Кроме того, определение рабочего процесса потребления включает объект SASAuthenticationPolicy JSON. Этот объект имеет свойство состояния , которое имеет значение "Отключено", например:

"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}

Чтобы найти рабочие процессы потребления, в которых SAS включен или отключен, проверьте, включает ли определение рабочего процесса объект sasAuthenticationPolicy , в котором для свойства состояния задано значение Disabled.

С помощью средства, которое отправляет вызовы REST API, получите сведения о рабочем процессе, выполнив операцию Get с помощью следующего запроса GET, например:

GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Выполните выходные данные из рабочих процессов — получение операции и проверьте, существует ли объект sasAuthenticationPolicy , где для свойства состояния задано значение Disabled.

Добавление свойства sasAuthenticationPolicy в определение рабочего процесса

Для рабочих процессов потребления, в которых требуется отключить проверку подлинности SAS, выполните следующие действия.

Если вы еще этого не сделали, получите сведения о рабочем процессе, выполнив операцию Get с помощью следующего запроса GET, например:

GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Выполните выходные данные из рабочих процессов — получение операции и вручную добавьте следующие элементы:
1. properties В объекте добавьте accessControl объект, содержащий triggers объект, если он отсутствует.
2. В объекте triggers добавьте sasAuthenticationPolicy объект, содержащий state свойство, которому Disabledприсвоено значение .
После завершения редактируемая часть выглядит следующим образом:
```
"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}
```
Отправьте другой запрос, чтобы обновить рабочий процесс с измененными выходными данными, которые используются в качестве входных данных в тексте запроса, выполнив операцию обновления рабочих процессов с помощью следующего запроса PATCH, например:

PATCH https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
В портал Azure перейдите в рабочий процесс потребления в конструкторе и убедитесь, что URL-адрес триггера запроса больше не включает SAS.
Чтобы включить Oauth 2.0 с идентификатором Microsoft Entra, на уровне ресурса приложения логики добавьте политику авторизации для OAuth с идентификатором Microsoft Entra.

Дополнительные сведения см. в разделе "Включить OAuth 2.0" с идентификатором Microsoft Entra.

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

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

Чтобы создать новый ключ доступа в любое время, используйте REST API Azure или портал Azure. Все ранее созданные URI или URL-адреса, использующие старый ключ, недействительны и больше не имеют авторизации для активации рабочего процесса приложения логики. URI, полученные после повторного создания, подписаны новым ключом доступа.

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

Внимание

Не забудьте защитить ключ доступа так же, как и ключ учетной записи от несанкционированного использования. Настройте или укажите план отзыва скомпрометированного ключа доступа. Используйте усмотрение при распространении URI, использующих ключи доступа, и распределяйте такие URI только по безопасному подключению, например HTTPS. Не забудьте выполнять только операции, использующие ключ доступа по протоколу HTTPS. Любой пользователь, имеющий универсальный код ресурса (URI) с допустимым ключом, может получить доступ к связанному ресурсу.

Создание URL-адресов обратного вызова с истекающим сроком действия

Если URL-адрес конечной точки триггера на основе запросов используется совместно с другими сторонами, можно создать URL-адреса обратного вызова, использующие определенные ключи и имеющие даты истечения срока действия. Таким образом можно легко менять ключи или ограничивать доступ для запуска приложения логики в определенные периоды времени. Чтобы указать дату окончания срока действия для URL-адреса, используйте REST API для Azure Logic Apps, например:

POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

В тексте добавьте NotAfter свойство с помощью строки даты JSON. Это свойство возвращает URL-адрес обратного вызова, действительный только до даты и времени, заданной для параметра NotAfter.

Создание URL-адресов с использованием первичного или вторичного секретного ключа

При создании или перечислении URL-адресов обратного вызова для триггера на основе запросов можно указать ключ, который нужно использовать для подписи URL-адреса. Чтобы создать URL-адрес, подписанный определенным ключом, используйте REST API Azure Logic Apps, например:

POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

Добавьте в текст свойство KeyType со значением Primary или Secondary. Это свойство возвращает URL-адрес, подписанный с помощью указанного ключа безопасности.

Предоставление рабочего процесса приложения логики с помощью Azure Управление API

Для получения дополнительных протоколов и параметров проверки подлинности рассмотрите возможность предоставления рабочего процесса приложения логики в качестве API с помощью Azure Управление API. Эта служба предоставляет любой конечной точке широкие возможности мониторинга, обеспечения безопасности, применения политики и документирования. Управление API может предоставлять общедоступную или частную конечную точку для приложения логики. Для авторизации доступа к этой конечной точке можно использовать OAuth с идентификатором Microsoft Entra, сертификатом клиента или другими стандартами безопасности. Когда служба Управления API получает запрос, она отправляет его в приложение логики и применяет необходимые преобразования или ограничения. Чтобы разрешить только Управление API вызывать рабочий процесс приложения логики, можно ограничить входящий IP-адрес приложения логики.

Дополнительные сведения см. в следующей документации:

Ограничение входящих IP-адресов

Наряду с подписанным URL-адресом (SAS) может потребоваться специально ограничить клиенты, которые могут вызывать рабочий процесс приложения логики. Например, если вы управляете конечной точкой запроса с помощью Azure Управление API, можно ограничить рабочий процесс приложения логики только для IP-адреса созданного экземпляра службы Управление API.

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

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

Портал
Шаблон Resource Manager

В портал Azure ограничение IP-адресов влияет как на триггеры, так и действия, вопреки описанию на портале в разделе "Разрешенные входящий IP-адрес". Чтобы настроить этот фильтр отдельно для триггеров и действий, используйте accessControl объект в шаблоне Azure Resource Manager для ресурса приложения логики или рабочего процесса— создание или обновление операции в REST API Azure Logic Apps.

Рабочие процессы уровня "Потребление"

В портал Azure откройте приложение логики потребления в конструкторе рабочих процессов.
В меню приложения логики в разделе Параметры выберите Параметры рабочего процесса.
В разделе Конфигурация контроля доступа под заголовком Разрешенные входящие IP-адреса выберите путь для своего сценария:
- Чтобы сделать рабочий процесс вызываемым с помощью встроенного действия Azure Logic Apps, но только как вложенный рабочий процесс, выберите только другие приложения логики. Этот параметр работает только при использовании действия Azure Logic Apps для вызова вложенного рабочего процесса.
  
  Этот параметр записывает пустой массив в ресурс приложения логики и требует, чтобы вызовы только из родительских рабочих процессов, использующих встроенное действие Azure Logic Apps , могли активировать вложенный рабочий процесс.
- Чтобы сделать рабочий процесс вызываемым с помощью действия HTTP, но только как вложенный рабочий процесс, выберите определенные диапазоны IP-адресов. При появлении диапазона IP-адресов для триггеров введите исходящие IP-адреса родительского рабочего процесса. Допустимый диапазон IP-адресов имеет формат x.x.x.x/x или x.x.x.x-x.x.x.x.
  
  Примечание.
  
  Если вы используете параметр "Только другие приложения логики" и действие HTTP для вызова вложенного рабочего процесса, вызов блокируется и возникает ошибка "401 Несанкционированный".
- Для сценариев, в которых необходимо ограничить входящие вызовы с других IP-адресов, когда появится поле Диапазоны IP для триггеров, укажите диапазоны IP-адресов, принимаемые триггером. Допустимый диапазон IP-адресов имеет формат x.x.x.x/x или x.x.x.x-x.x.x.x.
При необходимости в разделе Ограничение вызовов для получения входных и выходных сообщений из журнала выполнения на указанные IP-адреса можно указать диапазоны IP-адресов для входящих вызовов, которые могут получать доступ к входным и выходным сообщениям в журнале выполнения.

Стандартные рабочие процессы

На портале Azure откройте свой ресурс приложения логики категории "Стандартный".
В меню приложения логики в разделе "Параметры" выберите "Сеть".
В разделе конфигурации входящего трафика рядом с общедоступным сетевым доступом выберите "Включено" без ограничения доступа.
На странице ограничений доступа в разделе "Доступ к приложению" выберите "Включено" из выбора виртуальных сетей и IP-адресов.
В разделе "Доступ к сайту" и правила на вкладке "Основной сайт" добавьте одно или несколько правил, чтобы разрешить или запретить запросы из определенных диапазонов IP-адресов. Допустимый диапазон IP-адресов имеет формат x.x.x.x/x или x.x.x.x-x.x.x.x.

Дополнительные сведения см. в разделе "Блокировка входящих IP-адресов" в Azure Logic Apps (цен. категория "Стандартный").

Рабочие процессы уровня "Потребление"

В шаблоне ARM укажите разрешенные диапазоны входящих IP-адресов в определении ресурса приложения логики с помощью раздела accessControl. В этом разделе используйте разделы triggers, actions и по желанию contents в зависимости от ситуации, включив раздел allowedCallerIpAddresses со свойством addressRange и указав в качестве значения этого свойства допустимый диапазон IP-адресов в формате x.x.x.x/x или x.x.x.x-x.x.x.x.

Если рабочий процесс вложенного приложения логики использует параметр Only other Logic Apps, который разрешает входящий вызов только из других рабочих процессов приложения логики, использующих встроенное действие Azure Logic Apps, задайте allowedCallerIpAddresses для свойства пустой массив ([]) и опустите addressRange свойство.
Если рабочий процесс вложенного приложения логики использует параметр "Определенные диапазоны IP- адресов" для других входящих вызовов , таких как другие рабочие процессы приложения логики, использующие действие HTTP, включите allowedCallerIpAddresses раздел и задайте addressRange для свойства допустимый диапазон IP-адресов.

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

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               <workflow-definition>
            },
            "parameters": {
            },
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": []
               },
               "actions": {
                  "allowedCallerIpAddresses": []
               },
               // Optional
               "contents": {
                  "allowedCallerIpAddresses": []
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

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

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               <workflow-definition>
            },
            "parameters": {
            },
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     }
                  ]
               },
               "actions": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     }
                  ]
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

Стандартные рабочие процессы

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

Доступ для исходящих вызовов к другим службам и системам

В зависимости от возможности целевой конечной точки исходящие вызовы, отправленные триггером или действием HTTP, поддерживают шифрование и защищаются с помощью протокола TLS 1.0, 1.1 или 1.2, который раньше назывался SSL. Azure Logic Apps выполняет согласование с целевой конечной точкой, используя максимальную возможную поддерживаемую версию. Например, если целевая конечная точка поддерживает версию 1.2, триггер или действие HTTP сначала использует версию 1.2. В противном случае соединитель использует следующую наибольшую поддерживаемую версию.

Ниже приводятся сведения о самозаверяющих сертификатах TLS/SSL.

Для рабочих процессов приложения логики потребления в мультитенантной среде Azure Logic Apps операции HTTP не разрешают самозаверяющие СЕРТИФИКАТЫ TLS/SSL. Если приложение логики выполняет HTTP-вызов к серверу и представляет самозаверяющий сертификат TLS/SSL, HTTP-вызов завершается ошибкой TrustFailure.
Для рабочих процессов приложения логики уровня "Стандартный" в среде Azure Logic Apps с одним клиентом операции HTTP поддерживают самозаверяющий TLS/SSL-сертификаты. Но для использования этого типа проверки подлинности необходимо выполнить несколько дополнительных действий. В противном случае вызов завершится ошибкой. Дополнительные сведения см. в разделе Проверка подлинности сертификата TLS/SSL для Azure Logic Apps с одним клиентом.

Если вы хотите использовать сертификат клиента или OAuth с идентификатором Microsoft Entra ID с типом учетных данных сертификата , вам по-прежнему придется выполнить несколько дополнительных действий для этого типа проверки подлинности. В противном случае вызов завершится ошибкой. Дополнительные сведения см. в статье "Сертификат клиента" или OAuth с идентификатором Microsoft Entra ID с типом учетных данных "Certificate" для Azure Logic Apps с одним клиентом.

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

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

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

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

Azure Logic Apps обеспечивают интеграцию с этими службами для обеспечения безопасных и надежных локальных подключений.
- Локальный шлюз данных
  
  Многие управляемые соединители в Azure Logic Apps обеспечивают безопасное подключение к локальным системам, включая файловую систему, SQL, SharePoint и DB2. Шлюз отправляет данные из локальных источников по шифрованным каналам через Служебную шину Azure. Весь трафик поступает как безопасный исходящий трафик от агента шлюза. Узнайте, как работает локальный шлюз данных.
- Подключение через службу управления API Azure
  
  Служба "Управление API Azure" имеет возможности локального подключения, включая VPN типа "сеть–сеть" и интеграцию ExpressRoute, для защищенного прокси-сервера и подключения к локальным системам. Если у вас есть API, предоставляющий доступ к локальной системе, и вы предоставили этот API, создав экземпляр службы Управление API, можно вызвать этот API из рабочего процесса приложения логики, выбрав соответствующую операцию Управление API в конструкторе рабочих процессов.
  
  Примечание.
  
  Соединитель показывает только те службы управления API, для которых у вас есть разрешения на просмотр и подключение, но не отображает службы управления API на основе потребления.
  
  В зависимости от типа ресурса приложения логики выполните соответствующие действия.
  
  Рабочие процессы потребления
  1. В зависимости от того, добавляете ли вы триггер или действие Управление API, выполните следующие действия:
    - Триггер:
      1. В конструкторе рабочих процессов выберите " Добавить триггер".
      2. После открытия области добавления триггера в поле поиска введите Управление API.
      3. В списке результатов триггера выберите "Выбрать триггер azure Управление API".
    - Действие:
      1. В конструкторе рабочих процессов выберите знак плюса (+), где нужно добавить действие.
      2. После открытия области действий в поле поиска введите Управление API.
      3. В списке результатов действий выберите действие Azure Управление API.
    В следующем примере показано, как найти триггер azure Управление API:
  2. В списке экземпляров службы Управление API выберите ранее созданный экземпляр службы Управление API.
  3. В списке операций API выберите операцию API для вызова, а затем нажмите кнопку "Добавить действие".
  Стандартные рабочие процессы
  
  Для стандартных рабочих процессов можно добавлять только Управление API действия, а не триггеры.
  1. В конструкторе рабочих процессов выберите знак плюса (+), где нужно добавить действие.
  2. После открытия области действий в поле поиска введите Управление API.
  3. В списке результатов действий выберите "Вызов API Управление API Azure".
  4. В списке экземпляров службы Управление API выберите ранее созданный экземпляр службы Управление API.
  5. В списке операций API выберите операцию API для вызова, а затем нажмите кнопку "Создать".

Добавление проверки подлинности в исходящие вызовы

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

Внимание

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

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

Для вызовов HTTP обычная проверка подлинности использует строку в кодировке Base64, содержащую имя пользователя и пароль для выполнения запроса. Этот метод передает учетные данные без шифрования и создает повышенные риски безопасности, если этот параметр не используется с протоколом HTTPS/SSL.

Внимание

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

Свойство (конструктор)	Свойство (JSON)	Обязательное поле	значение	Описание
Аутентификация	`type`	Да	Базовая	Тип проверки подлинности
Username	`username`	Да	<имя-пользователя>	Имя пользователя для аутентификации доступа к целевой конечной точке службы
Пароль	`password`	Да	<пароль>	Пароль для аутентификации доступа к целевой конечной точке службы

При использовании защищенных параметров для управления конфиденциальной информацией, например, в шаблоне Azure Resource Manager для автоматизации развертывания, можно использовать выражения для доступа к этим значениям параметров во время выполнения. В следующем примере определение действия HTTP задает тип проверки подлинности type как Basic и использует функцию parameters() для получения значений параметров.

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Basic",
         "username": "@parameters('userNameParam')",
         "password": "@parameters('passwordParam')"
      }
  },
  "runAfter": {}
}

Проверка подлинности сертификатов клиента

Проверка подлинности сертификата клиента позволяет или требует, чтобы пользователи выполняли проверку подлинности непосредственно с помощью сертификатов X.509 с идентификатором Microsoft Entra для приложений и входа в браузер. Эта возможность помогает внедрить фишинговую проверку подлинности и пройти проверку подлинности с помощью сертификата X.509 в инфраструктуре открытых ключей (PKI).

Внимание

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

Свойство (конструктор)	Свойство (JSON)	Обязательное поле	значение	Описание
Аутентификация	`type`	Да	Сертификат клиента или `ClientCertificate`	Тип проверки подлинности. Управлять сертификатами можно с помощью службы управления API Azure. Примечание. Пользовательские соединители не поддерживают проверку подлинности на основе сертификатов ни для входящих, ни для исходящих вызовов.
Pfx	`pfx`	Да	<закодированное-содержимое-файла-pfx>	Содержимое в кодировке Base64 из PFX-файла Чтобы преобразовать PFX-файл в формат в кодировке Base64, можно использовать PowerShell 7, выполнив следующие действия. 1. Сохраните содержимое сертификата в переменную: `$pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx')` 2. Преобразование содержимого сертификата с помощью `ToBase64String()` функции и сохранение этого содержимого в текстовый файл: `[System.Convert]::ToBase64String($pfx_cert) \| Out-File 'pfx-encoded-bytes.txt'` Устранение неполадок: при использовании `cert mmc/PowerShell` команды может возникнуть следующая ошибка: `Could not load the certificate private key. Please check the authentication certificate password is correct and try again.` Чтобы устранить эту ошибку, попробуйте преобразовать PFX-файл в PEM-файл и вернуться еще раз с помощью `openssl` команды: `openssl pkcs12 -in certificate.pfx -out certificate.pem` `openssl pkcs12 -in certificate.pem -export -out certificate2.pfx` Затем, когда вы получите строку в кодировке Base64 для только что преобразованного файла PFX сертификата, строка будет работать в Azure Logic Apps.
Пароль	`password`	No	<пароль-для-файла-pfx>	Пароль для доступа к PFX-файлу

Примечание.

Если вы пытаетесь выполнить проверку подлинности с помощью сертификата клиента с помощью OpenSSL, может появиться следующая ошибка:

BadRequest: Could not load private key

Для устранения этой ошибки выполните следующие действия.

Удалите все экземпляры OpenSSL.
Установите OpenSSL версии 1.1.1t.
Оставьте сертификат с помощью нового обновления.
Добавьте новый сертификат в операцию HTTP при использовании проверки подлинности сертификата клиента.

При использовании защищенных параметров для управления конфиденциальной информацией, например, в шаблоне Azure Resource Manager для автоматизации развертывания, можно использовать выражения для доступа к этим значениям параметров во время выполнения. В следующем примере определение действия HTTP задает тип проверки подлинности type как ClientCertificate и использует функцию parameters() для получения значений параметров.

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ClientCertificate",
         "pfx": "@parameters('pfxParam')",
         "password": "@parameters('passwordParam')"
      }
   },
   "runAfter": {}
}

Внимание

Если у вас есть ресурс приложения логики уровня "Стандартный" в одном клиенте Azure Logic Apps, и вы хотите использовать операцию HTTP с сертификатом TSL/SSL, сертификатом клиента или открытой проверкой подлинности Microsoft Entra ID (Microsoft Entra ID OAuth) с Certificate типом учетных данных, обязательно выполните дополнительные действия по настройке для этого типа проверки подлинности. В противном случае вызов завершится ошибкой. Дополнительные сведения см. в разделе Проверка подлинности в среде с одним арендатором.

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

Платформа Microsoft Entra

В триггере запроса можно использовать платформу Microsoft Entra для проверки подлинности входящих вызовов после настройки политик авторизации Microsoft Entra для приложения логики.

Внимание

Во всех других триггерах и действиях, поддерживающих проверку подлинности OAuth Active Directory (OAuth 2.0 с идентификатором Microsoft Entra ID), укажите следующие значения свойств:

Свойство (конструктор)	Свойство (JSON)	Обязательное поле	значение	Описание
Аутентификация	`type`	Да	OAuth Active Directory (OAuth 2.0 с идентификатором Microsoft Entra) или `ActiveDirectoryOAuth`	Тип проверки подлинности. В настоящее время Azure Logic Apps следует требованиям протокола OAuth 2.0.
Центр авторизации	`authority`	No	<URL-адрес для поставщика токена>	URL-адрес центра, предоставляющего ключ доступа, например `https://login.microsoftonline.com/` для регионов глобальной службы Azure. Для других национальных облаков ознакомьтесь с конечными точками проверки подлинности Microsoft Entra. Выбор центра идентификации.
Клиент	`tenant`	Да	<ИД клиента>	Идентификатор клиента для клиента Microsoft Entra
Аудитория	`audience`	Да	<ресурс для авторизации>	Ресурс, который нужно использовать для авторизации, например `https://management.core.windows.net/`.
Идентификатор клиента	`clientId`	Да	<ИД клиента>	Идентификатор клиента для приложения, запрашивающего авторизацию.
Тип учетных данных	`credentialType`	Да	Сертификат или Секретный	Тип учетных данных, который клиент использует для запроса авторизации. Это свойство и значение не отображаются в базовом определении приложения логики, но определяет свойства, отображаемые для выбранного типа учетных данных.
Секрет	`secret`	Да, но только для учетных данных типа "Секрет"	<секрет-клиента>	Секрет клиента для запроса на авторизацию
Pfx	`pfx`	Да, но только для учетных данных типа "Сертификат"	<закодированное-содержимое-файла-pfx>	Содержимое файла обмена личной информацией (PFX-файла) с кодировкой base64.
Пароль	`password`	Да, но только для учетных данных типа "Сертификат"	<пароль-для-файла-pfx>	Пароль для доступа к PFX-файлу

При использовании защищенных параметров для управления конфиденциальной информацией, например, в шаблоне Azure Resource Manager для автоматизации развертывания, можно использовать выражения для доступа к этим значениям параметров во время выполнения. В следующем примере определение действия HTTP задает тип проверки подлинности type как ActiveDirectoryOAuth, тип учетных данных как Secret и использует функцию parameters() для получения значений параметров.

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ActiveDirectoryOAuth",
         "tenant": "@parameters('tenantIdParam')",
         "audience": "https://management.core.windows.net/",
         "clientId": "@parameters('clientIdParam')",
         "credentialType": "Secret",
         "secret": "@parameters('secretParam')"
     }
   },
   "runAfter": {}
}

Внимание

Если у вас есть ресурс приложения логики уровня "Стандартный" в однотенантном Azure Logic Apps, и вы хотите использовать операцию HTTP с сертификатом TSL/SSL, сертификатом клиента или идентификатором Microsoft Entra ID OAuth с Certificate типом учетных данных, обязательно выполните дополнительные действия по настройке для этого типа проверки подлинности. В противном случае вызов завершится ошибкой. Дополнительные сведения см. в разделе "Проверка подлинности в среде с одним клиентом".

Проверка подлинности Raw

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

Внимание

Ниже приведен пример заголовка для HTTPS-запроса, который соответствует протоколу OAuth 1.0.

Authorization: OAuth realm="Photos",
   oauth_consumer_key="dpf43f3p2l4k3l03",
   oauth_signature_method="HMAC-SHA1",
   oauth_timestamp="137131200",
   oauth_nonce="wIjqoS",
   oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
   oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"

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

Свойство (конструктор)	Свойство (JSON)	Обязательное поле	значение	Описание
Аутентификация	`type`	Да	Необработанные	Тип проверки подлинности
Value	`value`	Да	<значение-заголовка-авторизации>	Значение заголовка авторизации, используемое для проверки подлинности

При использовании защищенных параметров для управления конфиденциальной информацией, например, в шаблоне Azure Resource Manager для автоматизации развертывания, можно использовать выражения для доступа к этим значениям параметров во время выполнения. В следующем примере определение действия HTTP задает тип проверки подлинности type как Raw и использует функцию parameters() для получения значений параметров.

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Raw",
         "value": "@parameters('authHeaderParam')"
      }
   },
   "runAfter": {}
}

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

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

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

Примечание.

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

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

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

Встроенные триггеры и действия

Свойство (конструктор)	Свойство (JSON)	Обязательное поле	значение	Описание
Аутентификация	`type`	Да	управляемое удостоверение; или `ManagedServiceIdentity`	Тип проверки подлинности
управляемое удостоверение;	`identity`	No	<user-assigned-identity-ID>	Назначаемое пользователем управляемое удостоверение для использования. Примечание. Не включайте это свойство при использовании управляемого удостоверения, назначаемого системой.
Аудитория	`audience`	Да	<идентификатор-целевого-ресурса>	Идентификатор целевого ресурса, к которому требуется получить доступ. Например, значение `https://storage.azure.com/` делает маркеры доступа действительными для проверки подлинности для всех учетных записей хранения. Однако можно также указать URL-адрес корневой службы для конкретной учетной записи хранения, например `https://fabrikamstorageaccount.blob.core.windows.net`. Примечание. Свойство Аудитории может быть скрыто в некоторых триггерах или действиях. Чтобы сделать это свойство видимым, в триггере или действии откройте список расширенных параметров и выберите аудиторию. Важно. Убедитесь, что этот идентификатор целевого ресурса точно соответствует значению, которое ожидает идентификатор Microsoft Entra, включая все необходимые косые черты. Например, для идентификатора ресурса `https://storage.azure.com/` для всех учетных записей хранилища BLOB-объектов Azure требуется завершающая косая черта. Но для идентификатора ресурса конкретной учетной записи хранения завершающая косая черта не требуется. Чтобы найти эти идентификаторы ресурсов, просмотрите службы Azure, поддерживающие идентификатор Microsoft Entra.

При использовании защищенных параметров для управления конфиденциальной информацией, например, в шаблоне Azure Resource Manager для автоматизации развертывания, можно использовать выражения для доступа к этим значениям параметров во время выполнения. Например, следующее определение действия HTTP задает тип проверки подлинности type как ManagedServiceIdentity и использует функцию parameters() для получения значений параметров:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ManagedServiceIdentity",
         "audience": "https://management.azure.com/"
      },
   },
   "runAfter": {}
}

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

Свойство (конструктор)	Обязательное поле	значение	Описание
Имя подключения	Да	<имя_соединения>
Управляемое удостоверение	Да	Управляемое удостоверение, назначаемое системой или <Имя управляемого удостоверения, назначаемого пользователем>	Тип проверки подлинности

Блокировка создания подключений

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

Руководство по изоляции приложений логики

Вы можете использовать Azure Logic Apps в Azure для государственных организаций, поддерживающем все уровни влияния в регионах, описанные в руководстве по изоляции Azure для государственных организаций для уровня влияния 5. Для удовлетворения этих требований Azure Logic Apps предоставляет возможность создавать и выполнять рабочие процессы в среде с выделенными ресурсами, чтобы можно было снизить влияние других клиентов Azure на производительность приложений логики и избежать использования вычислительных ресурсов совместно с другими клиентами.
Рабочие процессы приложения логики уровня "Стандартный" могут безопасно взаимодействовать с виртуальной сетью Azure через частные конечные точки, настроенные для входящего трафика и интеграции виртуальной сети для исходящего трафика. Дополнительные сведения см. в разделе Безопасный трафик между виртуальными сетями и рабочими процессами с одним клиентом в службе Azure Logic Apps с использованием частных конечных точек.
Чтобы выполнить собственный код или осуществить преобразование XML, создайте и вызовите функцию Azure вместо того, чтобы использовать встроенную функцию кода, или предоставьте сборки для использования в качестве карт соответственно. Также настройте среду внешнего размещения для приложения-функции в соответствии с требованиями к изоляции.

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

Дополнительные сведения см. в следующей документации:

Дополнительные сведения об изоляции см. в следующей документации:

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

Безопасный доступ и данные для рабочих процессов в Azure Logic Apps

Доступ к операциям приложения логики

Рабочие процессы уровня "Потребление"

Стандартные рабочие процессы

Доступ к данным журнала выполнения

Ограничение доступа по диапазону IP-адресов

Рабочие процессы уровня "Потребление"

Стандартные рабочие процессы

Защита данных в журнале выполнения с помощью обфускации

Рекомендации по защите входных и выходных данных

Защита входных и выходных данных в конструкторе

Защита входных и выходных данных в представлении кода

Доступ к входным параметрам

Безопасные параметры в определениях рабочих процессов (рабочий процесс потребления)

Безопасные параметры в шаблонах Azure Resource Manager (рабочий процесс потребления)

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

Доступ для входящих вызовов триггеров на основе запросов

Включение OAuth 2.0 с идентификатором Microsoft Entra

Рекомендации перед включением OAuth 2.0 с идентификатором Microsoft Entra

Включите OAuth 2.0 с идентификатором Microsoft Entra в качестве единственного способа вызова конечной точки запроса (только потребление)

Получение маркера подтверждения владения (PoP)

Включение OAuth с идентификатором Microsoft Entra для ресурса приложения логики потребления

Включение заголовка Authorization в выходные данные триггера запроса или веб-перехватчика HTTP

Создание ключа или маркера подписанного URL-адреса (SAS)

Отключение проверки подлинности подписанного URL-адреса (только для SAS) (только для потребления)

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

Проверка триггеров с включенным или отключенным SAS

Добавление свойства sasAuthenticationPolicy в определение рабочего процесса

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

Создание URL-адресов обратного вызова с истекающим сроком действия

Создание URL-адресов с использованием первичного или вторичного секретного ключа

Предоставление рабочего процесса приложения логики с помощью Azure Управление API

Ограничение входящих IP-адресов

Рабочие процессы уровня "Потребление"

Стандартные рабочие процессы

Доступ для исходящих вызовов к другим службам и системам

Добавление проверки подлинности в исходящие вызовы

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

Проверка подлинности сертификатов клиента

Платформа Microsoft Entra

Проверка подлинности Raw

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

Блокировка создания подключений

Руководство по изоляции приложений логики

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

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

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