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

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

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

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

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

• Общие сведения о шифровании в Azure
• Шифрование неактивных данных в Azure
• Управление безопасностью в облаке Майкрософт

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

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

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

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

Чтобы запретить другим пользователям изменять или удалять рабочий процесс приложения логики, можно использовать блокировку ресурсов Azure. Эта позволяет предотвратить изменение или удаление рабочих ресурсов. Дополнительные сведения о безопасности подключений см. в статьях Настройка подключений в Azure 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:

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

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

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

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

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

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

• При скрытии входных или выходных данных триггера или действия Azure Logic Apps не отправляет защищенные данные в Azure Log Analytics. Кроме того, к такому триггеру или действию нельзя добавить отслеживаемые свойства для мониторинга.

• API Azure Logic Apps для обработки журнала рабочего процесса не возвращает защищенные выходные данные.

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

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

  Параметры безопасных выходных данных

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

  

  У действий "создать", "анализ JSON" и "ответ" есть только параметр Безопасные входные данные. Когда он включен, то выходные данные также скрываются. Если эти действия явно используют защищенные выходные данные предыдущего действия в качестве входных данных, Azure Logic Apps скрывает входные и выходные данные этих действий, но не включает для этих действий параметр Безопасные входные данные. Если последующее действие явно использует скрытые выходные данные действий "создать", "анализ JSON" или "ответ" в качестве входных данных, Azure Logic Apps не скрывает входные или выходные данные этого последующего действия.

  

  Параметры безопасных входных данных

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

  

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

  

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

1. Откройте рабочий процесс приложения логики в конструкторе на портале Azure.

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

3. В открывающейся области сведений выберите "Параметры" и разверните узел "Безопасность".

   

4. Включите Безопасные входные данные, Безопасные выходные данные, либо оба параметра.

   

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

   

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

   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>') в определении рабочего процесса. Это выражение вычисляется только во время выполнения и описывается на языке определения рабочего процесса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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

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

• Включение 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

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

• В рабочих процессах потребления входящий вызов URL-адрес конечной точки для триггера на основе запросов может использовать только одну схему авторизации, либо OAuth 2.0 с идентификатором Microsoft Entra ID или подписанным URL-адресом ОБЩЕГО доступа (SAS). Хотя использование одной схемы не отключает другую схему, если одновременно используется обе схемы, Azure Logic Apps создает ошибку, так как служба не знает, какую схему выбрать. Если рабочий процесс потребления начинается с триггера запроса, можно отключить проверку подлинности SAS, а также ограничить авторизацию только OAuth 2.0 с идентификатором Microsoft Entra. Для стандартных рабочих процессов можно использовать другие типы проверки подлинности без отключения SAS.

• Azure Logic Apps поддерживает схемы авторизации типа носителя или типа проверки владения (только приложение логики потребления) для маркеров доступа OAuth идентификатора Microsoft Entra ID. Authorization Однако заголовок маркера доступа должен указывать Bearer тип или PoP тип. Дополнительные сведения о том, как получить и использовать токен PoP, см. в разделе "Получение маркера подтверждения владения( PoP).

• Ресурс приложения логики потребления ограничен максимальным количеством политик авторизации. Каждая политика авторизации также имеет максимальное количество утверждений. Дополнительные сведения см. в статье Ограничения и сведения о конфигурации для Azure Logic Apps.

• Политика авторизации должна включать по крайней мере утверждение издателя , которое имеет значение, которое начинается с https://sts.windows.net/ любого или https://login.microsoftonline.com/ (OAuth V2) в качестве издателя для идентификатора Microsoft Entra.

  Например, предположим, что ресурс приложения логики имеет политику авторизации, требующую двух типов утверждений, аудитории и издателя. Этот пример раздела полезных данных для декодированного маркера доступа включает оба типа утверждений, где aud — это значение Аудитории, а iss — значение Издателя:

  {
      "aud": "https://management.core.windows.net/",
      "iss": "https://sts.windows.net/<Azure-AD-issuer-ID>/",
      "iat": 1582056988,
      "nbf": 1582056988,
      "exp": 1582060888,
      "_claim_names": {
         "groups": "src1"
      },
      "_claim_sources": {
         "src1": {
            "endpoint": "https://graph.windows.net/7200000-86f1-41af-91ab-2d7cd011db47/users/00000-f433-403e-b3aa-7d8406464625d7/getMemberObjects"
         }
      },
      "acr": "1",
      "aio": "AVQAq/8OAAAA7k1O1C2fRfeG604U9e6EzYcy52wb65Cx2OkaHIqDOkuyyr0IBa/YuaImaydaf/twVaeW/etbzzlKFNI4Q=",
      "amr": [
         "rsa",
         "mfa"
      ],
      "appid": "c44b4083-3bb0-00001-b47d-97400853cbdf3c",
      "appidacr": "2",
      "deviceid": "bfk817a1-3d981-4dddf82-8ade-2bddd2f5f8172ab",
      "family_name": "Sophia Owen",
      "given_name": "Sophia Owen (Fabrikam)",
      "ipaddr": "167.220.2.46",
      "name": "sophiaowen",
      "oid": "3d5053d9-f433-00000e-b3aa-7d84041625d7",
      "onprem_sid": "S-1-5-21-2497521184-1604012920-1887927527-21913475",
      "puid": "1003000000098FE48CE",
      "scp": "user_impersonation",
      "sub": "KGlhIodTx3XCVIWjJarRfJbsLX9JcdYYWDPkufGVij7_7k",
      "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
      "unique_name": "SophiaOwen@fabrikam.com",
      "upn": "SophiaOwen@fabrikam.com",
      "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
      "ver": "1.0"
  }
  

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

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

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

   Примечание.

   Этот шаг делает Authorization заголовок видимым в журнале выполнения рабочего процесса и в выходных данных триггера.

2. В портал Azure откройте рабочий процесс потребления в конструкторе.

3. В конструкторе выберите триггер. В открывающейся области сведений выберите "Параметры".

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

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

   –или–

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

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

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

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

• Консольное приложение управляющей программы .NET Core, вызывающее защищенный веб-API с собственным удостоверением

• SignedHttpRequest, также известный как PoP (подтверждение владения)

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

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

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

"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"
   }
}

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

• Справочник по схемам для типов триггеров и действий — триггер запросов
• Справочник по схемам для типов триггеров и действий — триггер веб-перехватчика HTTP
• Справочник по схемам для типов триггеров и действий — варианты операций

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

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

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

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

Полный 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-адресе имеет параметры запроса, описанные в следующей таблице:

Входящий вызов конечной точки на триггере на основе запроса может использовать только одну схему авторизации, 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>например:

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

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

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

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

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

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

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

1. С помощью средства, которое отправляет вызовы 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

2. Выполните выходные данные из рабочих процессов — получение операции и проверьте, существует ли объект sasAuthenticationPolicy , где для свойства состояния задано значение Disabled.

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

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

1. Если вы еще этого не сделали, получите сведения о рабочем процессе, выполнив операцию 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

2. Выполните выходные данные из рабочих процессов — получение операции и вручную добавьте следующие элементы:

   1. properties В объекте добавьте accessControl объект, содержащий triggers объект, если он отсутствует.

   2. В объекте triggers добавьте sasAuthenticationPolicy объект, содержащий state свойство, которому Disabledприсвоено значение .

   После завершения редактируемая часть выглядит следующим образом:

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

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

   PATCH https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

4. В портал Azure перейдите в рабочий процесс потребления в конструкторе и убедитесь, что URL-адрес триггера запроса больше не включает SAS.

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

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

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

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

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

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

2. В меню ресурсов приложения логики в разделе "Параметры" выберите "Ключи доступа".

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

Создание 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-адрес приложения логики.

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

• Сведения о службе "Управление API"
• Защита серверной части веб-API в Azure Управление API с помощью авторизации OAuth 2.0 с помощью идентификатора Microsoft Entra
• Защита API с помощью аутентификации на основе сертификата клиента в Управлении API
• Политики аутентификации в службе управления API

Ограничение входящих 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.

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

{
   "$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 для отправки исходящих вызовов можно добавить проверку подлинности в запрос, отправляемый приложением логики. Например, можно выбрать следующие типы проверки подлинности.

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

  • Аутентификация на основе сертификата клиента

  • Проверка подлинности Active Directory OAuth (OAuth 2.0 с идентификатором Microsoft Entra)

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

• Ограничение доступа от 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 доступен и выбран, укажите следующие значения свойств:

При использовании защищенных параметров для управления конфиденциальной информацией, например, в шаблоне 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).

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

При использовании защищенных параметров для управления конфиденциальной информацией, например, в шаблоне 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": {}
}

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

• Повышение защиты API-интерфейсов с помощью аутентификации на основе сертификата клиента в службе управления API Azure
• Повышение защиты фоновых служб посредством проверки подлинности с помощью сертификата клиента в службе Azure API Management
• Повышение защиты служб RESTful с помощью сертификатов клиента
• Учетные данные сертификата для аутентификации приложения
• Использование TLS/SSL-сертификата в коде в Службе приложений Azure

Платформа Microsoft Entra

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

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

При использовании защищенных параметров для управления конфиденциальной информацией, например, в шаблоне 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": {}
}

Проверка подлинности 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, укажите следующие значения свойств.

При использовании защищенных параметров для управления конфиденциальной информацией, например, в шаблоне 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.

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

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

  Примечание.

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

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

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

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

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

   Свойство (конструктор)	Свойство (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
  • Параметры сети для Функций Azure
  • Выделенные узлы Azure для виртуальных машин
  • Изоляция виртуальных машин в Azure
  • Развертывание выделенных служб Azure в виртуальных сетях

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

• Изоляция в общедоступном облаке Azure
• Меры безопасности для приложений IaaS с высоким уровнем конфиденциальности в Azure

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

• Базовый план обеспечения безопасности Azure для Azure Logic Apps
• Автоматизация развертывания для Azure Logic Apps
• Мониторинг приложений логики