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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

  3. В разделе Конфигурация контроля доступа>Разрешенные IP-адреса для входящего трафика щелкните Конкретные диапазоны IP-адресов.

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

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

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

  3. В разделе "Входящий трафик" выберите ограничение доступа.

  4. Создайте одно или несколько правил, чтобы разрешить или запретить запросы из определенных диапазонов IP-адресов. Вы также можете использовать параметры фильтра заголовков HTTP и параметры пересылки.

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

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

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

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

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

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

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

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

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

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

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

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

    Secured outputs as inputs and downstream impact on most actions

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

    Secured outputs as inputs with downstream impact on specific actions

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

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

    Secured inputs and downstream impact on most actions

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

    Secured inputs and downstream impact on specific actions

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

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

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

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

    В правом верхнем углу триггера или действия нажмите кнопку многоточия (...) и выберите Параметры.

    Screenshot shows Azure portal, Consumption workflow designer, and trigger or action with opened settings.

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

    В конструкторе выберите триггер или действие, чтобы открыть область сведений. На вкладке Параметры разверните узел "Безопасность".

    Screenshot shows Azure portal, Standard workflow designer, and trigger or action with opened settings.

  3. Включите Безопасные входные данные, Безопасные выходные данные, либо оба параметра. Для рабочих процессов потребления обязательно выберите "Готово".

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

    Screenshot shows Consumption workflow with an action's Secure Inputs or Secure Outputs settings enabled.

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

    Screenshot shows Consumption workflow and an action's title bar with lock icon.

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

    Screenshot shows Standard workflow with an action's Secure Inputs or Secure Outputs settings enabled.

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

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

    Screenshot shows Consumption workflow with a subsequent action's dynamic content list open, and the previous action's token for secured output with lock icon.

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

    Screenshot shows Standard workflow with a subsequent action's dynamic content list open, and the previous action's token for secured output with lock icon.

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

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

    1. В меню приложения логики выберите Overview (Обзор). В разделе " Журнал запусков" выберите запуск, который требуется просмотреть.

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

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

      Screenshot shows Consumption workflow run history view with hidden inputs and outputs.

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

    1. В меню "Рабочий процесс" выберите пункт Обзор. В разделе " Журнал выполнения" выберите запуск, который требуется просмотреть.

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

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

      Screenshot shows Standard workflow run history view with hidden inputs and outputs.

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

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

  • "inputs": защищает входные данные в журнале выполнения.
  • "outputs": защищает выходные данные в журнале выполнения.
"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

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

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

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

Примечание.

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

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

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

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

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

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

Наименование параметра Description
TemplatePasswordParam Параметр шаблона, принимающий пароль, который затем передается в параметр basicAuthPasswordParam определения рабочего процесса
TemplateUsernameParam Параметр шаблона, принимающий имя пользователя, которое затем передается в параметр basicAuthUserNameParam определения рабочего процесса
basicAuthPasswordParam Параметр определения рабочего процесса, который принимает пароль для обычной проверки подлинности в действии HTTP
basicAuthUserNameParam Параметр определения рабочего процесса, который принимает имя пользователя для обычной проверки подлинности в действии HTTP
{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {
      "LogicAppName": {
         "type": "string",
         "minLength": 1,
         "maxLength": 80,
         "metadata": {
            "description": "Name of the Logic App."
         }
      },
      "TemplatePasswordParam": {
         "type": "securestring"
      },
      "TemplateUsernameParam": {
         "type": "securestring"
      },
      "LogicAppLocation": {
         "type": "string",
         "defaultValue": "[resourceGroup().location]",
         "allowedValues": [
            "[resourceGroup().location]",
            "eastasia",
            "southeastasia",
            "centralus",
            "eastus",
            "eastus2",
            "westus",
            "northcentralus",
            "southcentralus",
            "northeurope",
            "westeurope",
            "japanwest",
            "japaneast",
            "brazilsouth",
            "australiaeast",
            "australiasoutheast",
            "southindia",
            "centralindia",
            "westindia",
            "canadacentral",
            "canadaeast",
            "uksouth",
            "ukwest",
            "westcentralus",
            "westus2"
         ],
         "metadata": {
            "description": "Location of the Logic App."
         }
      }
   },
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
               "actions": {
                  "HTTP": {
                     "type": "Http",
                     "inputs": {
                        "method": "GET",
                        "uri": "https://www.microsoft.com",
                        "authentication": {
                           "type": "Basic",
                           "username": "@parameters('basicAuthUsernameParam')",
                           "password": "@parameters('basicAuthPasswordParam')"
                        }
                     },
                  "runAfter": {}
                  }
               },
               "parameters": {
                  "basicAuthPasswordParam": {
                     "type": "securestring"
                  },
                  "basicAuthUsernameParam": {
                     "type": "securestring"
                  }
               },
               "triggers": {
                  "manual": {
                     "type": "Request",
                     "kind": "Http",
                     "inputs": {
                        "schema": {}
                     }
                  }
               },
               "contentVersion": "1.0.0.0",
               "outputs": {}
            },
            "parameters": {
               "basicAuthPasswordParam": {
                  "value": "[parameters('TemplatePasswordParam')]"
               },
               "basicAuthUsernameParam": {
                  "value": "[parameters('TemplateUsernameParam')]"
               }
            }
         }
      }
   ],
   "outputs": {}
}

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

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

Тип аутентификации Приложение логики и поддерживаемые соединители
Базовая Управление API Azure, службы приложений Azure, HTTP, HTTP + Swagger, веб-перехватчик HTTP
Сертификат клиента Управление API Azure, службы приложений Azure, HTTP, HTTP + Swagger, веб-перехватчик HTTP
Active Directory OAuth - Потребление: Azure Управление API, службы приложение Azure, Функции Azure, HTTP, HTTP + Swagger, веб-перехватчик HTTP

- Стандартный: служба автоматизации Azure, Хранилище BLOB-объектов Azure, Центры событий Azure, очереди Azure, Служебная шина Azure, таблицы Azure, HTTP, веб-перехватчик HTTP, SQL Server
Raw Управление API Azure, службы приложений Azure, функции Azure, HTTP, HTTP + Swagger, веб-перехватчик HTTP
Управляемое удостоверение Встроенные соединители:

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

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

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

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

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

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

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

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Примечание.

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

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

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

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

Создание подписанных URL-адресов (SAS)

Каждая конечная точка запроса в приложении логики содержит подписанный URL-адрес (SAS) в своем URL-адресе, который имеет следующий формат.

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

Каждый URL-адрес содержит параметры запроса sp, sv и sig, которые описаны в следующей таблице.

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

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

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

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

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

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

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

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

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

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

POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-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 для Logic Apps, например, следующим образом:

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

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

Включение открытой проверки подлинности идентификатора Microsoft Entra (Идентификатор Microsoft Entra ID OAuth)

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

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

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

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

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

  • 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": "72f988bf-86f1-41af-91ab-2d7cd011db47",
        "unique_name": "SophiaOwen@fabrikam.com",
        "upn": "SophiaOwen@fabrikam.com",
        "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
        "ver": "1.0"
    }
    

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

  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:

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

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

Выполните следующие действия на портале Azure или в шаблоне Azure Resource Manager:

На портале Azure добавьте в свое приложение логики одну или несколько политик авторизации:

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

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

    Screenshot that shows Azure portal, Consumption logic app menu, Authorization page, and selected button to add policy.

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

    Screenshot that shows Azure portal, Consumption logic app Authorization page, and information for authorization policy.

    Свойство Обязательное поле Type Описание
    Имя политики Да Строка Имя, которое будет использоваться для политики авторизации
    Тип политики Да Строка AAD для маркеров типа носителя или AADPOP для маркеров типа проверки владения.
    Утверждения Да Строка Пара "ключ-значение", указывающая тип утверждения и значение, которое триггер запроса рабочего процесса ожидает в маркере доступа, представленном каждым входящий вызов триггера. Вы можете добавить любое стандартное утверждение, которое вы хотите, выбрав "Добавить стандартное утверждение". Чтобы добавить утверждение, относящееся к токену PoP, выберите "Добавить настраиваемое утверждение".

    Доступные стандартные типы утверждений:

    - Издатель
    - Аудитория
    - Тема
    - Идентификатор JWT (идентификатор веб-маркера JSON)

    Требования:

    — Как минимум, список утверждений должен включать утверждение издателя, которое имеет значение, которое начинается с или https://login.microsoftonline.com/ как https://sts.windows.net/ идентификатор издателя Microsoft Entra.

    — Каждое утверждение должно содержать одно строковое значение, но не массив значений. Например, можно иметь утверждение с типом Role и значением Developer. Но вы не можете использовать утверждение с типом Role и двумя значениями Developer и Program Manager.

    Значение утверждения ограничено максимальным количеством символов.

    Дополнительные сведения об этих типах утверждений см . в маркерах безопасности Microsoft Entra. Можно также указать собственный тип и значение утверждения.

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

    Screenshot that shows Azure portal, Consumption logic app Authorization page, and information for a proof-of-possession policy.

  4. Чтобы добавить еще одно утверждение, выберите один из следующих вариантов.

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

    • Чтобы добавить собственное утверждение, выберите Добавить пользовательское утверждение. Дополнительные сведения см. в статье о предоставлении необязательных утверждений для приложения. После этого ваше пользовательское утверждение будет сохранено как часть идентификатора JWT, например, "tid": "72f988bf-86f1-41af-91ab-2d7cd011db47".

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

  6. По завершении выберите Сохранить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  3. В разделе Конфигурация контроля доступа под заголовком Разрешенные входящие IP-адреса выберите путь для своего сценария:

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

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

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

      Примечание.

      Если вы используете параметр "Только другие приложения логики" и действие HTTP для вызова вложенного рабочего процесса, вызов блокируется и возникает ошибка "401 Несанкционированный".

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

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

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

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

  3. В разделе "Входящий трафик" выберите ограничение доступа.

  4. Создайте одно или несколько правил, чтобы разрешить или запретить запросы из определенных диапазонов IP-адресов. Вы также можете использовать параметры фильтра заголовков HTTP и параметры пересылки. Допустимый диапазон IP-адресов имеет формат x.x.x.x/x или x.x.x.x-x.x.x.x.

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

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

В зависимости от возможности целевой конечной точки исходящие вызовы, отправленные триггером или действием 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 с типом учетных данных Certificate, вам по-прежнему придется выполнить несколько дополнительных действий для этого типа проверки подлинности. В противном случае вызов завершится ошибкой. Дополнительные сведения см . в сертификате клиента или OAuth с идентификатором Microsoft Entra ID с типом учетных данных Certificate для Azure Logic Apps с одним клиентом.

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

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

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

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

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

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

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

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

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

    • Подключение через службу управления API Azure

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

      Примечание.

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

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

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

      1. В конструкторе рабочих процессов под полем поиска выберите Встроенный. В поле поиска найдите встроенный соединитель с именем Управление API.

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

        • Триггер. Выберите триггер Azure Управление API.

        • Действие. Выберите действие azure Управление API.

        В следующем примере добавляется триггер:

        Screenshot shows Azure portal, Consumption workflow designer, and Azure API Management trigger.

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

      4. Выберите операцию API для вызова.

        Screenshot shows Azure portal, Consumption workflow designer, and selected API to call.

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

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

      1. В конструкторе рабочих процессов в конце рабочего процесса или между шагами нажмите кнопку "Добавить действие".

      2. После открытия панели действий "Добавление действия" в поле поиска в списке среды выполнения выберите "В приложении", чтобы отобразить только встроенные соединители. Выберите встроенное действие с именем Call a Azure Управление API API.

        Screenshot shows Azure portal, Standard workflow designer, and Azure API Management action.

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

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

        Screenshot shows Azure portal, Standard workflow designer, and selected API to call.

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

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

Важно!

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

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

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

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

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

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

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

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

Свойство (конструктор) Свойство (JSON) Обязательное поле значение Описание
Проверка подлинности type Да Сертификат клиента
или
ClientCertificate
Тип проверки подлинности. Управлять сертификатами можно с помощью службы управления API Azure.

Примечание. Пользовательские соединители не поддерживают проверку подлинности на основе сертификатов ни для входящих, ни для исходящих вызовов.
Pfx pfx Да <закодированное-содержимое-файла-pfx> Содержимое в кодировке Base64 из PFX-файла

Чтобы преобразовать PFX-файл в формат в кодировке Base64, можно использовать PowerShell 7, выполнив следующие действия.

1. Сохраните содержимое сертификата в переменную:

$pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx')

2. Преобразование содержимого сертификата с помощью ToBase64String() функции и сохранение этого содержимого в текстовый файл:

[System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt'

Устранение неполадок: при использовании cert mmc/PowerShell команды может возникнуть следующая ошибка:

Could not load the certificate private key. Please check the authentication certificate password is correct and try again.

Чтобы устранить эту ошибку, попробуйте преобразовать PFX-файл в PEM-файл и вернуться еще раз с помощью openssl команды:

openssl pkcs12 -in certificate.pfx -out certificate.pem
openssl pkcs12 -in certificate.pem -export -out certificate2.pfx

Затем, когда вы получите строку в кодировке Base64 для только что преобразованного файла PFX сертификата, строка будет работать в Azure Logic Apps.
Пароль password No <пароль-для-файла-pfx> Пароль для доступа к PFX-файлу

Примечание.

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

BadRequest: Could not load private key

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

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

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

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

Важно!

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

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

Платформа удостоверений Майкрософт

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

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

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

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

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

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

    Примечание.

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

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

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

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