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

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

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

• Доступ к операциям логического приложения.
• Доступ к входам и выводам истории запуска.
• Доступ к входным параметрам.
• Типы аутентификации для триггеров и действий, поддерживающих аутентификацию.
• Доступ для входящих вызовов к триггерам на основе запросов.
• Доступ к исходящим вызовам другим сервисам и системам.
• Заблокируйте создание подключений для определённых разъёмов.
• Рекомендации по изоляции для логических приложений.
• Azure Security Baseline for Azure Logic Apps.

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

• Azure encryption overview.
• Azure Data Encryption-at-Rest.
• Бенчмарк безопасности Microsoft в облаке.

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

Прежде чем создавать или управлять логическими приложениями, их рабочими процессами и соединениями, нужны специальные права, которые предоставляются через роли с помощью ролевой системы контроля доступа 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. Только пользователь с разрешениями администратора может снять это ограничение, что обеспечивает возможность своевременного доступа к данным в рабочих процессах приложения логики. Допустимый диапазон 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 скрывает входные и выходные данные этих действий, но не включает параметр Безопасные входные данные этих действий. Если нижнее действие явно использует скрытые выходные данные из действия Compose, Parse JSON или Response в качестве входных данных, Azure Logic Apps не скрывает входные или выходные данные этого нижестоящего действия.

  

  Настройка защищенных входов

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

  

  Если действия Compose, Parse JSON и Response явно используют видимые выходные данные триггера или действия с защищенными входными данными, Azure Logic Apps скрывает входные и выходные данные этих действий, но не включает параметр безопасных входных данных этого действия. Если нижнее действие явно использует скрытые выходные данные из действия Compose, Parse JSON или Response в качестве входных данных, 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 c Microsoft Entra ID, вы можете определить и скрыть параметры, которые принимают идентификатор клиента и клиентский секрет, используемые для аутентификации. Чтобы определить эти параметры в рабочем процессе приложения логики, используйте parameters раздел определения рабочего процесса приложения логики и шаблон Resource Manager для развертывания. Чтобы обезопасить значения параметров, которые не должны отображаться при редактировании приложения логики или просмотре журнала выполнения, определите параметры с помощью securestring типа or 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 типа or 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 применяет эту версию при получении входящего вызова триггера Request или обратного вызова для триггера или действия 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 ID.
• Создание ключей или токенов подписанного общего доступа (SAS).
• Отключите аутентификацию с использованием подписи общего доступа (SAS).
• Ограничить входящие IP-адреса.
• Опубликуйте приложение логики с помощью Azure API Management.

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

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

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

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

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

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

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

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

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

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

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

  {
      "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 ID как единственный способ обращения к конечной точке запроса

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

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

   Замечание

   На этом шаге Authorization заголовок становится видимым в истории выполнения расчетной схемы и в выходных данных триггера.

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

3. В конструкторе выберите триггер. В открывшейся информационной панели выберите Параметры.

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

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

   -или-

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

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

Получите токен Proof-of-Possession (PoP)

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

• Консольное приложение .NET Core, вызывающее защищённый веб-API с собственной идентификацией.

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

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

Включите OAuth с помощью Microsoft Entra ID для вашего ресурса Consumption Logic App

Чтобы добавить политику авторизации в приложение "Логика потребления", выполните следующие действия для портала 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
],

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

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

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

Для получения дополнительной информации ознакомьтесь со следующими разделами:

• Ссылка на схему для триггеров и типов действий — триггер запроса.
• Схема для типов триггеров и действий — HTTP Webhook trigger.
• Схема для типов триггеров и действий — опции операций.

Генерация ключа или маркера общий доступ (SAS)

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

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

Например, чтобы просмотреть этот URL в триггере Request , найдите свойство HTTP 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-адресе имеет параметры запроса, которые описаны в следующей таблице:

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

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

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

• Восстанови ключи доступа.
• Создайте 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
• PowerShell Invoke-RestMethod
• Microsoft Edge — средство сетевой консоли
• Бруно
• curl

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

Если проверка подлинности SAS отключена, URL-адрес конечной точки триггера больше не содержит ключ SAS. Кроме того, определение рабочего процесса потребления включает объект JSON sasAuthenticationPolicy . У этого объекта есть свойство состояния , для которого задано значение Disabled, например:

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

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

1. С помощью средства, отправляющего вызовы REST API, можно получить сведения о рабочем процессе, выполнив операцию Workflows — 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. Возьмите выходные данные операции Workflows — Get и проверьте, существует ли объект sasAuthenticationPolicy , для свойства state которого задано значение Disabled.

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

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

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

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

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

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

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

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

   PUT 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 ID, на уровне ресурса приложения логики добавьте политику авторизации для OAuth с идентификатором Microsoft Entra.

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

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

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

Чтобы создать новый ключ доступа в любое время, используйте Azure REST API или портал 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 Management

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

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

• Об управлении API.
• Защитите бэкенд веб-API в Azure API Management, используя авторизацию OAuth 2.0 с Microsoft Entra ID.
• Безопасные API с использованием аутентификации клиентских сертификатов в API Management.
• Политики аутентификации управления API.

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

Наряду с подписанным URL-адресом (SAS) может потребоваться специально ограничить количество клиентов, которые могут вызывать рабочий процесс приложения логики. Например, если вы управляете конечной точкой запроса с помощью службы "Управление API Azure", вы можете ограничить рабочий процесс приложения логики, чтобы он принимал запросы только с 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-триггер или HTTP-действие, поддерживают шифрование и защищены с помощью Transport Layer Security (TLS) 1.0, 1.1, 1.2 или 1.3, ранее известного как Secure Sockets Layer (SSL). Azure Logic Apps согласовывает с целевой конечной точкой использование максимально возможной поддерживаемой версии. Например, если целевая конечная точка поддерживает 1.3, триггер ИЛИ действие HTTP сначала использует 1.3. В противном случае соединитель использует следующую по величине поддерживаемую версию.

Этот список включает в себя информацию о самоподписанных сертификатах 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 с типом учетных данных "Сертификат" для Azure Logic Apps с одним клиентом.

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

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

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

  • Базовая аутентификация.

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

  • Аутентификация в Active Directory OAuth (OAuth 2.0 с Microsoft Entra ID).

  • Управляемая аутентификация личности.

• Ограничьте доступ с IP-адресов рабочих процессов приложения логики.

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

• Повысьте безопасность подключений к локальным системам.

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

  • Локальный шлюз данных.

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

  • Подключайтесь через Azure API Management.

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

    Замечание

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

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

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

    1. В зависимости от того, добавляете ли вы триггер или действие Управления API, выполните следующие действия:

       • Триггер:

         1. В конструкторе рабочих процессов выберите " Добавить триггер".

         2. После того как откроется панель Добавить триггер , в поле поиска введите Управление API.

         3. В списке результатов триггера выберите Выбрать триггер управления API Azure.

       • Действие:

         1. В конструкторе рабочих процессов выберите знак «плюс» (+) в том месте, куда требуется добавить действие.

         2. После того как откроется кнопка Добавить область действий , в поле поиска введите Управление API.

         3. В списке результатов действия выберите Выбрать действие службы управления API Azure.

       В следующем примере показано нахождение триггера службы "Управление API Azure":

       

    2. В списке экземпляров службы "Управление API" выберите ранее созданный экземпляр службы "Управление API".

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

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

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

    1. В конструкторе рабочих процессов выберите знак «плюс» (+) в том месте, куда требуется добавить действие.

    2. После того как откроется кнопка Добавить область действий , в поле поиска введите Управление API.

    3. В списке результатов действий выберите Вызвать API управления Azure API Management.

       

    4. В списке экземпляров службы "Управление API" выберите ранее созданный экземпляр службы "Управление API".

    5. В списке Операции API выберите операцию API для вызова, а затем нажмите кнопку Создать.

       

Добавление аутентификации к исходящим вызовам

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

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

Для 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 с помощью аутентификации клиентских сертификатов в Azure API Management.
• Улучшить безопасность серверных сервисов с помощью аутентификации клиентских сертификатов в Azure API Management.
• Повышайте безопасность вашего сервиса RESTful, используя сертификаты клиентов.
• Учётные данные сертификатов для аутентификации приложений.
• Используйте сертификат TLS/SSL в вашем коде в Служба приложений Azure.

Платформа Microsoft Entra

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

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

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

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

При использовании защищенных параметров для обработки и защиты конфиденциальной информации, например в шаблоне 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	нет	< идентификатор личности, назначенный пользователю>	Управляемое удостоверение, назначенное пользователем для использования. Примечание: Не включайте это свойство при использовании управляемого удостоверения, назначенного системой.
   Публика	audience	Да	< target-resource-ID>	Идентификатор целевого ресурса, к которому требуется получить доступ. Например, https://storage.azure.com/ маркеры доступа для проверки подлинности становятся действительными для всех учетных записей хранения. Однако вы также можете указать URL-адрес корневой службы, например https://fabrikamstorageaccount.blob.core.windows.net для определенной учетной записи хранения. Примечание: Свойство Audience может быть скрыто в некоторых триггерах или действиях. Чтобы сделать это свойство видимым, в триггере или действии откройте список Дополнительные параметры и выберите Аудитория. Важно: Убедитесь, что этот идентификатор целевого ресурса точно соответствует значению, которое ожидает Microsoft Entra ID, включая все необходимые завершающие слэши. Таким образом, https://storage.azure.com/ идентификатор ресурса для всех учетных записей хранилища Blob Azure должен оканчиваться косой чертой. Однако идентификатор ресурса для определенной учетной записи облачного хранилища не требует косой черты в конце строки. Чтобы найти эти идентификаторы ресурсов, ознакомьтесь со службами Azure, поддерживающими Microsoft Entra ID.

   При использовании защищенных параметров для обработки и защиты конфиденциальной информации, например в шаблоне 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 для государственных организаций , поддерживая все уровни воздействия в регионах, описанных в Руководстве по изоляции уровня 5 воздействия Azure для государственных организаций. Чтобы соответствовать этим требованиям, Azure Logic Apps поддерживает возможность создания и выполнения рабочих процессов в среде с выделенными ресурсами, что позволяет уменьшить влияние других клиентов Azure на ваши приложения логики и избежать совместного использования вычислительных ресурсов с другими клиентами.

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

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

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

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

  • Планы службы приложений Azure.
  • Параметры сети Функции Azure.
  • Выделенные узлы Azure для виртуальных машин.
  • Изоляция виртуальных машин в Azure.
  • Развернуть выделенные сервисы Azure в виртуальных сетях.

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

• Изоляция в публичном облаке Azure.
• Безопасность для высокочувствительных приложений IaaS в Azure.

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

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