Partilhar via

Acesso seguro e dados para fluxos de trabalho em Aplicativos Lógicos do Azure

  • Artigo

Os Aplicativos Lógicos do Azure dependem do Armazenamento do Azure para armazenar e criptografar automaticamente dados em repouso. Esta encriptação protege os dados e ajuda a cumprir as obrigações de conformidade e segurança da sua organização. Por predefinição, o Armazenamento do Microsoft Azure utiliza chaves geridas pela Microsoft para encriptar os dados. Para obter mais informações, veja Encriptação do Armazenamento do Microsoft Azure para dados inativos.

Para controlar ainda mais o acesso e proteger os dados confidenciais no Azure Logic Apps, pode configurar segurança adicional nestas áreas:

Para obter mais informações sobre segurança no Azure, revise estes tópicos:

Acesso a operações lógicas de aplicativos

Somente para aplicativos lógicos de consumo, antes de criar ou gerenciar aplicativos lógicos e suas conexões, você precisa de permissões específicas, que são fornecidas por meio de funções usando o controle de acesso baseado em função do Azure (Azure RBAC). Você também pode configurar permissões para que apenas usuários ou grupos específicos possam executar tarefas específicas, como gerenciar, editar e exibir aplicativos lógicos. Para controlar suas permissões, você pode atribuir funções internas ou personalizadas a membros que têm acesso à sua assinatura do Azure. Os Aplicativos Lógicos do Azure têm as seguintes funções específicas, com base no fato de você ter um fluxo de trabalho de aplicativo lógico Consumo ou Padrão:

Fluxos de trabalho de consumo
Função Description
Colaborador do Aplicativo Lógico Você pode gerenciar fluxos de trabalho de aplicativos lógicos, mas não pode alterar o acesso a eles.
Operador de aplicativo lógico Você pode ler, habilitar e desabilitar fluxos de trabalho de aplicativos lógicos, mas não pode editá-los ou atualizá-los.
Contribuinte Você tem acesso total para gerenciar todos os recursos, mas não pode atribuir funções no RBAC do Azure, gerenciar atribuições em Plantas do Azure ou compartilhar galerias de imagens.

Por exemplo, suponha que você tenha que trabalhar com um fluxo de trabalho de aplicativo lógico que você não criou e autenticar conexões usadas por esse fluxo de trabalho de aplicativo lógico. Sua assinatura do Azure requer permissões de Colaborador para o grupo de recursos que contém esse recurso de aplicativo lógico. Se você criar um recurso de aplicativo lógico, terá acesso de Colaborador automaticamente.

Para impedir que outras pessoas alterem ou excluam seu fluxo de trabalho do aplicativo lógico, você pode usar o Bloqueio de Recursos do Azure. Esse recurso impede que outras pessoas alterem ou excluam recursos de produção. Para obter mais informações sobre segurança de conexão, consulte Configuração de conexão em Aplicativos Lógicos do Azure e Segurança e criptografia de conexão.

Fluxos de trabalho padrão

Nota

Esta funcionalidade está em pré-visualização e está sujeita aos Termos de Utilização Suplementares para Pré-visualizações do Microsoft Azure.

Função Description
Logic Apps Standard Reader (Pré-visualização) Você tem acesso somente leitura a todos os recursos em um aplicativo lógico padrão e fluxos de trabalho, incluindo as execuções do fluxo de trabalho e seu histórico.
Operador padrão de aplicativos lógicos (visualização) Você tem acesso para habilitar, reenviar e desabilitar fluxos de trabalho e para criar conexões com serviços, sistemas e redes para um aplicativo lógico padrão. A função Operador pode executar tarefas de administração e suporte na plataforma Aplicativos Lógicos do Azure, mas não tem permissões para editar fluxos de trabalho ou configurações.
Desenvolvedor Logic Apps Standard (Visualização) Você tem acesso para criar e editar fluxos de trabalho, conexões e configurações para um aplicativo lógico padrão. A função Desenvolvedor não tem permissões para fazer alterações fora do escopo de fluxos de trabalho, por exemplo, alterações em todo o aplicativo, como configurar a integração de rede virtual. Os Planos do Serviço de Aplicativo não são suportados.
Contribuidor padrão de aplicativos lógicos (visualização) Você tem acesso para gerenciar todos os aspetos de um aplicativo lógico padrão, mas não pode alterar o acesso ou a propriedade.

Acesso a dados do histórico de execuções

Durante a execução de um aplicativo lógico, todos os dados são criptografados durante o trânsito usando TLS (Transport Layer Security) e em repouso. Quando o aplicativo lógico terminar de ser executado, você poderá exibir o histórico dessa execução, incluindo as etapas executadas junto com o status, a duração, as entradas e as saídas de cada ação. Esses detalhes detalhados fornecem informações sobre como seu aplicativo lógico foi executado e onde você pode começar a solucionar quaisquer problemas que surjam.

Quando você exibe o histórico de execução do seu aplicativo lógico, os Aplicativos Lógicos do Azure autenticam seu acesso e, em seguida, fornecem links para as entradas e saídas para as solicitações e respostas para cada execução. No entanto, para ações que lidam com senhas, segredos, chaves ou outras informações confidenciais, você deseja impedir que outras pessoas visualizem e acessem esses dados. Por exemplo, se seu aplicativo lógico obtiver um segredo do Cofre de Chaves do Azure para usar ao autenticar uma ação HTTP, você deseja ocultar esse segredo da exibição.

Para controlar o acesso às entradas e saídas no histórico de execução do seu aplicativo lógico, você tem estas opções:

Restringir o acesso por intervalo de endereços IP

Você pode limitar o acesso às entradas e saídas no histórico de execução dos fluxos de trabalho do aplicativo lógico para que apenas solicitações de intervalos de endereços IP específicos possam exibir esses dados.

Por exemplo, para impedir que qualquer pessoa acesse entradas e saídas, especifique um intervalo de endereços IP, como 0.0.0.0-0.0.0.0. Somente uma pessoa com permissões de administrador pode remover essa restrição, que oferece a possibilidade de acesso "just-in-time" aos dados em seus fluxos de trabalho de aplicativos lógicos. Um intervalo de IP válido usa estes formatos: x.x.x.x/x ou x.x.x.x-x.x.x.x

Para especificar os intervalos de IP permitidos, siga estas etapas para seu aplicativo lógico Consumo ou Padrão no portal do Azure ou no modelo do Azure Resource Manager:

Fluxos de trabalho de consumo

  1. No portal do Azure, abra o fluxo de trabalho do aplicativo lógico de consumo no designer.

  2. No menu do aplicativo lógico, em Configurações, selecione Configurações do fluxo de trabalho.

  3. Na seção Configuração de controle de acesso, em Endereços IP de entrada permitidos, na lista de opções Acesso de gatilho, selecione Intervalos de IP específicos.

  4. Na caixa Intervalos de IP para conteúdo, especifique os intervalos de endereços IP que podem acessar o conteúdo de entradas e saídas.

Fluxos de trabalho padrão

  1. No portal do Azure, abra seu recurso de aplicativo lógico padrão.

  2. No menu do aplicativo lógico, em Configurações, selecione Rede.

  3. Na seção Configuração de tráfego de entrada, ao lado de Acesso à rede pública, selecione Habilitado sem restrição de acesso.

  4. Na página Restrições de acesso, em Acesso ao aplicativo, selecione Habilitado em redes virtuais e endereços IP selecionados.

  5. Em Acesso ao site e regras, na guia Site principal, adicione uma ou mais regras para Permitir ou Negar solicitações de intervalos de IP específicos. Você também pode usar as configurações do filtro de cabeçalho HTTP e as configurações de encaminhamento. Um intervalo de IP válido usa estes formatos: x.x.x.x/x ou x.x.x.x-x.x.x.x

    Para obter mais informações, consulte Bloqueando endereços IP de entrada nos Aplicativos Lógicos do Azure (Padrão).

Proteja os dados no histórico de execução usando ofuscação

Muitos gatilhos e ações têm configurações para proteger entradas, saídas ou ambas do histórico de execução de um aplicativo lógico. Todos os conectores gerenciados e conectores personalizados suportam essas opções. No entanto, as seguintes operações internas não oferecem suporte a essas opções:

Entradas seguras - Não suportadas Saídas Seguras - Não suportadas
Acrescentar à variável de matriz
Acrescentar à variável string
Variável de decréscimo
Para cada
Se o
Variável de incremento
Inicializar variável
Recorrência
Âmbito de aplicação
Definir variável
Mudar
Encerrar
Até		 Acrescentar à variável de matriz
Acrescentar à variável string
Compor
Variável de decréscimo
Para cada
Se o
Variável de incremento
Inicializar variável
Analisar JSON
Recorrência
Resposta
Âmbito de aplicação
Definir variável
Mudar
Encerrar
Até
Wait

Considerações para proteger entradas e saídas

Antes de usar essas configurações para ajudá-lo a proteger esses dados, revise estas considerações:

  • Quando você obscurece as entradas ou saídas em um gatilho ou ação, os Aplicativos Lógicos do Azure não enviam os dados protegidos para o Azure Log Analytics. Além disso, não é possível adicionar propriedades controladas a esse gatilho ou ação para monitoramento.

  • A API de Aplicativos Lógicos do Azure para lidar com o histórico do fluxo de trabalho não retorna saídas seguras.

  • Para proteger saídas de uma ação que obscurece entradas ou explicitamente obscurece saídas, ative manualmente Saídas seguras nessa ação.

  • Certifique-se de ativar Entradas ou Saídas Seguras em ações downstream em que você espera que o histórico de execução obscureça esses dados.

    Configuração de saídas seguras

    Quando você ativa manualmente as Saídas Seguras em um gatilho ou ação, os Aplicativos Lógicos do Azure ocultam essas saídas no histórico de execução. Se uma ação downstream usar explicitamente essas saídas seguras como entradas, os Aplicativos Lógicos do Azure ocultarão as entradas dessa ação no histórico de execução, mas não habilitarão a configuração Entradas Seguras da ação.

    Saídas seguras como entradas e impacto a jusante na maioria das ações

    As ações Compor, Analisar JSON e Resposta têm apenas a configuração Entradas seguras . Quando ativada, a configuração também oculta as saídas dessas ações. Se essas ações usarem explicitamente as saídas protegidas upstream como entradas, os Aplicativos Lógicos do Azure ocultarão as entradas e saídas dessas ações, mas não habilitarão a configuração de Entradas Seguras dessas ações. Se uma ação downstream usar explicitamente as saídas ocultas das ações Compor, Analisar JSON ou Resposta como entradas, os Aplicativos Lógicos do Azure não ocultarão as entradas ou saídas dessa ação downstream.

    Saídas seguras como entradas com impacto a jusante em ações específicas

    Configuração de entradas seguras

    Quando você ativa manualmente as Entradas Seguras em um gatilho ou ação, os Aplicativos Lógicos do Azure ocultam essas entradas no histórico de execução. Se uma ação downstream usar explicitamente as saídas visíveis desse gatilho ou ação como entradas, os Aplicativos Lógicos do Azure ocultarão as entradas dessa ação downstream no histórico de execução, mas não habilitarão as Entradas Seguras nessa ação e não ocultarão as saídas dessa ação.

    Insumos seguros e impacto a jusante na maioria das ações

    Se as ações Compor, Analisar JSON e Resposta usarem explicitamente as saídas visíveis do gatilho ou ação que tem as entradas seguras, os Aplicativos Lógicos do Azure ocultarão as entradas e saídas dessas ações, mas não habilitarão a configuração Entradas Seguras dessas ações. Se uma ação downstream usar explicitamente as saídas ocultas das ações Compor, Analisar JSON ou Resposta como entradas, os Aplicativos Lógicos do Azure não ocultarão as entradas ou saídas dessa ação downstream.

    Insumos seguros e impacto a jusante em ações específicas

Proteja entradas e saídas no designer

  1. No portal do Azure, abra o fluxo de trabalho do aplicativo lógico no designer.

  2. No designer, selecione o gatilho ou a ação em que deseja proteger dados confidenciais.

  3. No painel de informações que se abre, selecione Configurações e expanda Segurança.

    A captura de tela mostra o portal do Azure, o designer de fluxo de trabalho e o gatilho ou ação com as configurações abertas.

  4. Ative Entradas seguras, Saídas seguras ou ambas.

    A captura de tela mostra o fluxo de trabalho com as configurações de Entradas ou Saídas Seguras de uma ação habilitadas.

    O gatilho ou ação agora mostra um ícone de cadeado na barra de título. Todos os tokens que representam saídas seguras de ações anteriores também mostram ícones de cadeado. Por exemplo, em uma ação subsequente, depois de selecionar um token para uma saída segura da lista de conteúdo dinâmico, esse token mostra um ícone de cadeado.

    A captura de tela mostra o fluxo de trabalho com a lista de conteúdo dinâmico de uma ação subsequente aberta e o token da ação anterior para saída segura com ícone de cadeado.

  5. Depois que o fluxo de trabalho for executado, você poderá exibir o histórico dessa execução.

    1. Selecione Visão geral no menu do aplicativo Lógica de consumo ou no menu Fluxo de trabalho padrão.

    2. Em Histórico de execuções, selecione a execução que deseja exibir.

    3. No painel Histórico de execução do fluxo de trabalho, selecione as ações que deseja revisar.

      Se você optar por ocultar entradas e saídas, esses valores agora aparecem ocultos.

      A captura de tela mostra a exibição do histórico de execução do fluxo de trabalho padrão com entradas e saídas ocultas.

Proteja entradas e saídas na visualização de código

Na definição de gatilho ou ação subjacente, adicione ou atualize a runtimeConfiguration.secureData.properties matriz com um destes valores ou ambos:

  • "inputs": Protege entradas no histórico de execução.
  • "outputs": Protege as saídas no histórico de execução.
"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

Acesso a entradas de parâmetros

Se você implantar em ambientes diferentes, considere parametrizar os valores em sua definição de fluxo de trabalho que variam com base nesses ambientes. Dessa forma, você pode evitar dados codificados usando um modelo do Azure Resource Manager para implantar seu aplicativo lógico, proteger dados confidenciais definindo parâmetros seguros e passar esses dados como entradas separadas pelos parâmetros do modelo usando um arquivo de parâmetros.

Por exemplo, se você autenticar ações HTTP com OAuth com ID do Microsoft Entra, poderá definir e obscurecer os parâmetros que aceitam a ID do cliente e o segredo do cliente usados para autenticação. Para definir esses parâmetros no fluxo de trabalho do aplicativo lógico, use a seção na definição de fluxo de trabalho do aplicativo lógico e o parameters modelo do Gerenciador de Recursos para implantação. Para ajudar a proteger valores de parâmetros que você não deseja que sejam mostrados ao editar seu aplicativo lógico ou exibir o histórico de execução, defina os parâmetros usando o ou secureobject digite e use a securestring codificação conforme necessário. Os parâmetros que têm esse tipo não são retornados com a definição de recurso e não são acessíveis ao exibir o recurso após a implantação. Para acessar esses valores de parâmetro durante o tempo de execução, use a expressão dentro da definição do @parameters('<parameter-name>') fluxo de trabalho. Essa expressão é avaliada somente em tempo de execução e é descrita pela Linguagem de Definição de Fluxo de Trabalho.

Nota

Se você usar um parâmetro em um cabeçalho ou corpo de solicitação, esse parâmetro poderá ficar visível quando você exibir o histórico de execução do fluxo de trabalho e a solicitação HTTP de saída. Certifique-se de que também define as suas políticas de acesso ao conteúdo em conformidade. Você também pode usar ofuscação para ocultar entradas e saídas em seu histórico de execução. Por padrão, Authorization os cabeçalhos não são visíveis por meio de entradas ou saídas. Então, se um segredo é usado lá, esse segredo não é recuperável.

Para obter mais informações, revise estas seções neste tópico:

Se você automatizar a implantação de aplicativos lógicos usando modelos do Gerenciador de Recursos, poderá definir parâmetros de modelo seguros, que são avaliados na implantação, usando os securestring tipos e secureobject . Para definir parâmetros de modelo, use a seção de nível parameters superior do modelo, que é separada e diferente da seção de parameters definição do fluxo de trabalho. Para fornecer os valores para parâmetros de modelo, use um arquivo de parâmetro separado.

Por exemplo, se você usar segredos, poderá definir e usar parâmetros de modelo seguros que recuperam esses segredos do Cofre de Chaves do Azure na implantação. Em seguida, você pode fazer referência ao cofre de chaves e ao segredo em seu arquivo de parâmetros. Para obter mais informações, revise estes tópicos:

Parâmetros seguros em definições de fluxo de trabalho (fluxo de trabalho de consumo)

Para proteger informações confidenciais na definição de fluxo de trabalho do aplicativo lógico, use parâmetros seguros para que essas informações não fiquem visíveis depois que você salvar o fluxo de trabalho do aplicativo lógico. Por exemplo, suponha que você tenha uma ação HTTP que requer autenticação básica, que usa um nome de usuário e senha. Na definição do fluxo de trabalho, a parameters seção define os basicAuthPasswordParam parâmetros e basicAuthUsernameParam usando o securestring tipo. Em seguida, a definição da ação faz referência a esses parâmetros na authentication seção.

Importante

Para uma segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Esta opção fornece segurança superior sem ter que fornecer credenciais. O Azure gerencia essa identidade e ajuda a manter as informações de autenticação seguras para que você não precise gerenciar essas informações confidenciais. Para configurar uma identidade gerenciada para Aplicativos Lógicos do Azure, consulte Autenticar acesso e conexões com recursos do Azure com identidades gerenciadas em Aplicativos Lógicos do Azure.

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

Parâmetros seguros em modelos do Azure Resource Manager (fluxo de trabalho de consumo)

Um modelo do Gerenciador de Recursos para um recurso de aplicativo lógico e fluxo de trabalho tem várias parameters seções. Para proteger senhas, chaves, segredos e outras informações confidenciais, defina parâmetros seguros no nível do modelo e no nível de definição do fluxo de trabalho usando o securestring ou secureobject tipo. Em seguida, você pode armazenar esses valores no Cofre de Chaves do Azure e usar o arquivo de parâmetro para fazer referência ao cofre de chaves e ao segredo. Em seguida, o modelo recupera essas informações na implantação. Para obter mais informações, revise Passar valores confidenciais na implantação usando o Cofre de Chaves do Azure.

Importante

Para uma segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Esta opção fornece segurança superior sem ter que fornecer credenciais. O Azure gerencia essa identidade e ajuda a manter as informações de autenticação seguras para que você não precise gerenciar essas informações confidenciais. Para configurar uma identidade gerenciada para Aplicativos Lógicos do Azure, consulte Autenticar acesso e conexões com recursos do Azure com identidades gerenciadas em Aplicativos Lógicos do Azure.

Esta lista inclui mais informações sobre estas parameters secções:

  • No nível superior do modelo, uma parameters seção define os parâmetros para os valores que o modelo usa na implantação. Por exemplo, esses valores podem incluir cadeias de conexão para um ambiente de implantação específico. Em seguida, você pode armazenar esses valores em um arquivo de parâmetro separado, o que facilita a alteração desses valores.

  • Dentro da definição de recursos do aplicativo lógico, mas fora da definição do fluxo de trabalho, uma parameters seção especifica os valores para os parâmetros da definição do fluxo de trabalho. Nesta seção, você pode atribuir esses valores usando expressões de modelo que fazem referência aos parâmetros do modelo. Essas expressões são avaliadas na implantação.

  • Dentro da definição do fluxo de trabalho, uma parameters seção define os parâmetros que o fluxo de trabalho do aplicativo lógico usa em tempo de execução. Em seguida, você pode fazer referência a esses parâmetros dentro do fluxo de trabalho do seu aplicativo lógico usando expressões de definição de fluxo de trabalho, que são avaliadas em tempo de execução.

Este modelo de exemplo que tem várias definições de parâmetro seguro que usam o securestring tipo:

Nome do parâmetro Description
TemplatePasswordParam Um parâmetro de modelo que aceita uma senha que é passada para o parâmetro de definição do basicAuthPasswordParam fluxo de trabalho
TemplateUsernameParam Um parâmetro de modelo que aceita um nome de usuário que é passado para o parâmetro de definição do basicAuthUserNameParam fluxo de trabalho
basicAuthPasswordParam Um parâmetro de definição de fluxo de trabalho que aceita a senha para autenticação básica em uma ação HTTP
basicAuthUserNameParam Um parâmetro de definição de fluxo de trabalho que aceita o nome de usuário para autenticação básica em uma ação 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": {}
}

Tipos de autenticação para conectores que suportam a autenticação

A tabela a seguir identifica os tipos de autenticação disponíveis nas operações do conector nas quais você pode selecionar um tipo de autenticação:

Authentication type Aplicativo lógico & conectores suportados
Básica Gerenciamento de API do Azure, Serviço de Aplicativo do Azure, HTTP, HTTP + Swagger, HTTP Webhook
Certificado do cliente Gerenciamento de API do Azure, Serviço de Aplicativo do Azure, HTTP, HTTP + Swagger, HTTP Webhook
Ative Directory OAuth (OAuth 2.0 com ID do Microsoft Entra) - Consumo: Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook

- Padrão: Automação do Azure, Armazenamento de Blobs do Azure, Hubs de Eventos do Azure, Filas do Azure, Barramento de Serviço do Azure, Tabelas do Azure, HTTP, HTTP Webhook, SQL Server
Cru Gerenciamento de API do Azure, Serviço de Aplicativo do Azure, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Identidade gerida Conectores embutidos:

- Consumo: Gerenciamento de API do Azure, Serviço de Aplicativo do Azure, Azure Functions, HTTP, HTTP Webhook

- Padrão: Automação do Azure, Armazenamento de Blobs do Azure, Hubs de Eventos do Azure, Filas do Azure, Barramento de Serviço do Azure, Tabelas do Azure, HTTP, HTTP Webhook, SQL Server

Nota: Atualmente, a maioria dos conectores internos baseados em provedor de serviços não oferece suporte à seleção de identidades gerenciadas atribuídas pelo usuário para autenticação.

Conectores gerenciados: Serviço de Aplicativo do Azure, Automação do Azure, Armazenamento de Blob do Azure, Instância de Contêiner do Azure, Azure Cosmos DB, Azure Data Explorer, Azure Data Factory, Azure Data Lake, Grade de Eventos do Azure, Hubs de Eventos do Azure, Azure IoT Central V2, Azure IoT Central V3, Azure Key Vault, Azure Log Analytics, Azure Queues, Azure Resource Manager, Azure Service Bus, Azure Sentinel, Azure Table Storage, VM do Azure, HTTP com ID do Microsoft Entra, SQL Server

Importante

Para uma segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Esta opção fornece segurança superior sem ter que fornecer credenciais. O Azure gerencia essa identidade e ajuda a manter as informações de autenticação seguras para que você não precise gerenciar essas informações confidenciais. Para configurar uma identidade gerenciada para Aplicativos Lógicos do Azure, consulte Autenticar acesso e conexões com recursos do Azure com identidades gerenciadas em Aplicativos Lógicos do Azure.

Acesso para chamadas de entrada a acionadores baseados em pedidos

As chamadas de entrada que um aplicativo lógico recebe por meio de um gatilho baseado em solicitação, como o gatilho Request ou o gatilho HTTP Webhook, suportam criptografia e são protegidas com Transport Layer Security (TLS) 1.2 no mínimo, anteriormente conhecido como Secure Sockets Layer (SSL). Os Aplicativos Lógicos do Azure impõem essa versão ao receber uma chamada de entrada para um gatilho de Solicitação ou um retorno de chamada para o gatilho ou ação HTTP Webhook.

Nota

Se você receber erros de handshake TLS, certifique-se de usar o TLS 1.2. Para obter mais informações, consulte Resolvendo o problema do TLS 1.0.

Para chamadas de entrada, use os seguintes pacotes de codificação:

  • 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

Importante

Para compatibilidade com versões anteriores, os Aplicativos Lógicos do Azure atualmente dão suporte a alguns pacotes de codificação mais antigos. No entanto, não use pacotes de codificação mais antigos ao desenvolver novos aplicativos, pois esses pacotes podem não ser suportados no futuro.

Por exemplo, você pode encontrar os seguintes pacotes de codificação se inspecionar as mensagens de handshake TLS nos Aplicativos Lógicos do Azure ou usando uma ferramenta de segurança na URL do seu aplicativo lógico. Novamente, não use estas suítes mais antigas:

  • 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

A lista a seguir inclui maneiras de limitar o acesso a gatilhos que recebem chamadas de entrada para o fluxo de trabalho do aplicativo lógico para que apenas clientes autorizados possam chamar seu fluxo de trabalho:

Ativar OAuth 2.0 com o Microsoft Entra ID

Em um fluxo de trabalho de Consumo que começa com um gatilho baseado em solicitação, você pode autenticar e autorizar chamadas de entrada enviadas para o ponto de extremidade criado por esse gatilho habilitando o OAuth 2.0 com o Microsoft Entra ID. Para configurar essa autenticação, defina ou adicione uma política de autorização no nível de recursos do aplicativo lógico. Dessa forma, as chamadas de entrada usam tokens de acesso OAuth para autorização.

Quando o fluxo de trabalho do aplicativo lógico recebe uma solicitação de entrada que inclui um token de acesso OAuth, os Aplicativos Lógicos do Azure comparam as declarações do token com as declarações especificadas por cada política de autorização. Se existir uma correspondência entre as declarações do token e todas as declarações em pelo menos uma política, a autorização será bem-sucedida para a solicitação de entrada. O token pode ter mais declarações do que o número especificado pela política de autorização.

Em um fluxo de trabalho padrão que começa com o gatilho Request (mas não um gatilho webhook), você pode usar a provisão do Azure Functions para autenticar chamadas de entrada enviadas para o ponto de extremidade criado pelo gatilho Request usando uma identidade gerenciada. Esta disposição é também conhecida como "Autenticação Fácil". Para obter mais informações, consulte Acionar fluxos de trabalho em aplicativos lógicos padrão com autenticação fácil.

Considerações antes de habilitar o OAuth 2.0 com o Microsoft Entra ID

  • Para uma segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Esta opção fornece segurança superior sem ter que fornecer credenciais. O Azure gerencia essa identidade e ajuda a manter as informações de autenticação seguras para que você não precise gerenciar essas informações confidenciais. Para configurar uma identidade gerenciada para Aplicativos Lógicos do Azure, consulte Autenticar acesso e conexões com recursos do Azure com identidades gerenciadas em Aplicativos Lógicos do Azure.

  • Em fluxos de trabalho de consumo, as chamadas de entrada para a URL do ponto de extremidade para um gatilho baseado em solicitação podem usar apenas um esquema de autorização, OAuth 2.0 com ID do Microsoft Entra ou SAS (Assinatura de Acesso Compartilhado). Embora o uso de um esquema não desabilite o outro, se você usar os dois esquemas ao mesmo tempo, os Aplicativos Lógicos do Azure gerarão um erro porque o serviço não sabe qual esquema escolher. Se o fluxo de trabalho de Consumo começar com o gatilho Solicitação, você poderá desabilitar a autenticação SAS, bem como restringir a autorização para usar apenas o OAuth 2.0 com o Microsoft Entra ID. Para fluxos de trabalho padrão, você pode usar outros tipos de autenticação sem desabilitar o SAS.

  • Os Aplicativos Lógicos do Azure dão suporte aos esquemas de autorização do tipo portador ou do tipo de prova de posse (somente aplicativo lógico de consumo) para tokens de acesso OAuth do Microsoft Entra ID. No entanto, o Authorization cabeçalho do token de acesso deve especificar o tipo ou PoP o Bearer tipo. Para obter mais informações sobre como obter e usar um token PoP, consulte Obter um token de prova de posse (PoP).

  • Seu recurso de aplicativo lógico de consumo é limitado a um número máximo de políticas de autorização. Cada política de autorização também tem um número máximo de reivindicações. Para obter mais informações, consulte Limites e configuração para Aplicativos Lógicos do Azure.

  • Uma política de autorização deve incluir pelo menos a declaração do Emissor , que tem um valor que começa com um https://sts.windows.net/ ou https://login.microsoftonline.com/ (OAuth V2) como o emissor do Microsoft Entra ID.

    Por exemplo, suponha que seu recurso de aplicativo lógico tenha uma política de autorização que exija dois tipos de declaração, Público e Emissor. Esta seção de carga útil de exemplo para um token de acesso decodificado inclui ambos os tipos de declaração, onde aud é o valor Audience e iss é o valor 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"
}

Habilite o OAuth 2.0 com o Microsoft Entra ID como a única opção para chamar um ponto de extremidade de solicitação (somente consumo)

Para pontos de extremidade baseados em solicitação, você pode restringir a autorização para usar apenas o OAuth 2.0 com o Microsoft Entra ID. Essa opção funciona mesmo se você também desabilitar a autenticação de assinatura de acesso compartilhado (SAS).

  1. Para seu fluxo de trabalho de Consumo, configure seu gatilho de solicitação ou gatilho de Webhook HTTP com a capacidade de verificar o token de acesso OAuth seguindo as etapas para incluir o cabeçalho 'Autorização' nas saídas de gatilho de webhook de solicitação ou HTTP.

    Nota

    Esta etapa torna o Authorization cabeçalho visível no histórico de execução do fluxo de trabalho e nas saídas do gatilho.

  2. No portal do Azure, abra seu fluxo de trabalho de Consumo no designer.

  3. No designer, selecione o gatilho. No painel de informações que se abre, selecione Configurações.

  4. Em Condições gerais>do gatilho, selecione Adicionar. Na caixa de condição de gatilho, insira uma das seguintes expressões, com base no tipo de token que você deseja usar:

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

    -or-

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

Se você chamar o ponto de extremidade do gatilho sem a autorização correta, o histórico de execução apenas mostrará o gatilho como Skipped sem qualquer mensagem de que a condição do gatilho falhou.

Obter um token de prova de posse (PoP)

As bibliotecas da Biblioteca de Autenticação da Microsoft (MSAL) fornecem tokens PoP para você usar. Se o fluxo de trabalho do aplicativo lógico de consumo que você deseja chamar exigir um token PoP, você poderá obter esse token usando as bibliotecas MSAL. Os exemplos a seguir mostram como adquirir tokens PoP:

Para usar o token PoP com o fluxo de trabalho do aplicativo lógico de consumo, siga as etapas para configurar o OAuth com o Microsoft Entra ID.

Habilite o OAuth com o Microsoft Entra ID para seu recurso de aplicativo lógico de consumo

Para adicionar uma política de autorização ao seu aplicativo de lógica de consumo, siga as etapas para o portal do Azure ou o modelo do Azure Resource Manager:

  1. No portal do Azure, abra seu aplicativo lógico de consumo e fluxo de trabalho no designer.

  2. No menu do aplicativo lógico, em Configurações, selecione Autorização.

  3. Na página Autorização, selecione Adicionar política.

    A captura de tela mostra o portal do Azure, a página Autorização e o botão selecionado para adicionar política.

  4. Forneça informações sobre a política de autorização especificando os tipos e valores de declaração que seu aplicativo lógico espera no token de acesso apresentado por cada chamada de entrada para o gatilho Request :

    A captura de tela mostra o portal do Azure, a página Autorização e os detalhes da política de autorização.

    Property Necessário Type Description
    Nome da política Sim String O nome que você deseja usar para a política de autorização
    Tipo de política Sim String AAD para tokens do tipo portador ou AADPOP para tokens do tipo Prova de Posse.
    Pedidos Sim String Um par chave-valor que especifica o tipo de declaração e o valor que o gatilho Request do fluxo de trabalho espera no token de acesso apresentado por cada chamada de entrada para o gatilho. Você pode adicionar qualquer declaração padrão desejada selecionando Adicionar declaração padrão. Para adicionar uma declaração específica a um token PoP, selecione Adicionar declaração personalizada.

    Tipos de sinistros padrão disponíveis:

    - Emissor
    - Público-alvo
    - Assunto
    - ID JWT (JSON Web Token identifier)

    Prescrições:

    - No mínimo, a lista de Reclamações deve incluir a declaração do Emitente , que tem um valor que começa com https://sts.windows.net/ ou https://login.microsoftonline.com/ como o ID do emissor do Microsoft Entra.

    - Cada declaração deve ser um único valor de cadeia de caracteres, não uma matriz de valores. Por exemplo, você pode ter uma declaração com Role como o tipo e Developer como o valor. Você não pode ter uma declaração que tenha Role como o tipo e os valores definidos como Desenvolvedor e Gerenciador de Programas.

    - O valor da reivindicação é limitado a um número máximo de caracteres.

    Para obter mais informações sobre esses tipos de declaração, consulte Declarações nos tokens de segurança do Microsoft Entra. Você também pode especificar seu próprio tipo de reivindicação e valor.

    O exemplo a seguir mostra as informações de um token PoP:

    A captura de tela mostra o portal do Azure, a página Autorização e as informações da política de prova de posse.

  5. Para adicionar outra declaração, selecione uma destas opções:

    • Para adicionar outro tipo de declaração, selecione Adicionar declaração padrão, selecione o tipo de declaração e especifique o valor da declaração.

    • Para adicionar sua própria declaração, selecione Adicionar declaração personalizada. Para obter mais informações, veja como fornecer declarações opcionais ao seu aplicativo. Sua reivindicação personalizada é então armazenada como parte de sua ID JWT; por exemplo, "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee".

  6. Para adicionar outra política de autorização, selecione Adicionar política. Repita as etapas anteriores para configurar a política.

  7. Quando tiver terminado, selecione Guardar.

  8. Para incluir o Authorization cabeçalho do token de acesso nas saídas de gatilho baseadas em solicitação, revise Incluir cabeçalho 'Autorização' nas saídas de gatilho de solicitação e webhook HTTP.

As propriedades do fluxo de trabalho, como políticas, não aparecem na exibição de código do seu fluxo de trabalho no portal do Azure. Para acessar suas políticas programaticamente, chame a seguinte API por meio do Gerenciador de Recursos do Azure: 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. Certifique-se de substituir os valores de espaço reservado para sua ID de assinatura do Azure, nome do grupo de recursos e nome do fluxo de trabalho.

Incluir o cabeçalho 'Autorização' nas saídas de gatilho de webhook Request ou HTTP

Para aplicativos lógicos que habilitam o OAuth com ID do Microsoft Entra para autorizar chamadas de entrada para acessar gatilhos baseados em solicitação, você pode habilitar as saídas de gatilho Request ou HTTP Webhook para incluir o Authorization cabeçalho do token de acesso OAuth. Na definição JSON subjacente do gatilho, adicione e defina a operationOptions propriedade como IncludeAuthorizationHeadersInOutputs. Aqui está um exemplo para o gatilho Request :

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

Para obter mais informações, revise estes tópicos:

Gerar uma chave ou token de assinatura de acesso compartilhado (SAS)

Quando um fluxo de trabalho começa com um gatilho baseado em solicitação e você salva esse fluxo de trabalho pela primeira vez, os Aplicativos Lógicos do Azure criam um ponto de extremidade chamável nesse gatilho. Esse ponto de extremidade tem uma URL que pode receber chamadas de entrada ou solicitações para iniciar o fluxo de trabalho. A URL inclui uma Assinatura de Acesso Compartilhado (SAS), que é uma chave ou token que concede permissões, por exemplo, a serviços de armazenamento. Este URL de ponto de extremidade usa o seguinte formato:

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

Por exemplo, para exibir essa URL em um gatilho Request, localize a propriedade HTTP URL do disparador:

A captura de tela mostra o portal do Azure, o designer de fluxo de trabalho de consumo e a URL do ponto de extremidade do gatilho de solicitação.

O URL completo é semelhante ao seguinte exemplo:

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

O SAS na URL tem parâmetros de consulta, que a tabela a seguir descreve:

Parâmetro de consulta Description
sp Especifica permissões para os métodos HTTP permitidos a serem usados.
sv Especifica a versão SAS a ser usada para gerar a assinatura.
sig Especifica a assinatura a ser usada para autenticar o acesso ao gatilho. Essa assinatura é gerada usando o algoritmo SHA256 com uma chave de acesso secreta em todos os caminhos e propriedades de URL. Essa chave é mantida em segredo e criptografada, armazenada com o aplicativo lógico e nunca é exposta ou publicada. Seu aplicativo lógico autoriza apenas os gatilhos que contêm uma assinatura válida criada com a chave secreta.

Importante

Certifique-se de proteger sua chave SAS assim como você protege uma chave de conta contra uso não autorizado. Configure ou tenha um plano para revogar uma chave de acesso comprometida. Use a discrição ao distribuir URIs que usam chaves de acesso e distribua apenas esses URIs em uma conexão segura, como HTTPS. Certifique-se de executar apenas operações que usam uma chave de acesso em uma conexão HTTPS. Qualquer pessoa que tenha um URI com chave válida pode acessar o recurso associado. Para manter a segurança e proteger o acesso ao fluxo de trabalho do seu aplicativo lógico, regenere as chaves de acesso regularmente, pois elas podem precisar estar em conformidade com as políticas de segurança ou ficar comprometidas. Dessa forma, você pode ter certeza de que apenas solicitações autorizadas podem acionar seu fluxo de trabalho, o que protege seus dados e processos contra acesso não autorizado.

Se você usar uma chave SAS para acessar serviços de armazenamento, a Microsoft recomenda que você crie uma SAS de delegação de usuário, que é protegida com a ID do Microsoft Entra, em vez de uma chave de conta.

Para uma segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação sempre que possível. Esta opção fornece segurança superior sem ter que fornecer credenciais. O Azure gerencia essa identidade e ajuda a manter as informações de autenticação seguras para que você não precise gerenciar essas informações confidenciais. Para configurar uma identidade gerenciada para Aplicativos Lógicos do Azure, consulte Autenticar acesso e conexões com recursos do Azure com identidades gerenciadas em Aplicativos Lógicos do Azure.

As chamadas de entrada para o ponto de extremidade em um gatilho baseado em solicitação podem usar apenas um esquema de autorização, SAS ou OAuth 2.0 com ID do Microsoft Entra. Embora o uso de um esquema não desabilite o outro, se você usar os dois esquemas ao mesmo tempo, os Aplicativos Lógicos do Azure gerarão um erro porque o serviço não sabe qual esquema escolher.

Se você tiver um fluxo de trabalho de Consumo que comece com o gatilho Solicitação, poderá desabilitar a autenticação SAS. Essa opção funciona mesmo se você também restringir a autorização para usar apenas o OAuth 2.0 com o Microsoft Entra ID. Para fluxos de trabalho padrão, você pode usar outros tipos de autenticação sem desabilitar o SAS.

Para obter mais informações sobre segurança quando você usa uma chave SAS, consulte as seguintes seções neste guia:

Desativar a autenticação de assinatura de acesso compartilhado (SAS) (somente consumo)

Por padrão, um gatilho baseado em solicitação tem a autenticação SAS habilitada. A URL do ponto de extremidade do gatilho inclui uma SAS, começando com os parâmetros de consulta, sp-<permissions>sv-<SAS-version>sig=<signature>por exemplo:

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

Se o fluxo de trabalho de Consumo começar com o gatilho de Solicitação e você quiser usar o OAuth com o ID do Microsoft Entra, poderá desabilitar a autenticação SAS para evitar erros e problemas ao executar o fluxo de trabalho. Você também adiciona uma camada de segurança removendo a dependência de segredos, o que reduz o risco de ter segredos registrados ou vazados.

Essa opção funciona mesmo se você também habilitar o OAuth 2.0 com o Microsoft Entra ID como a única opção para chamar um ponto de extremidade baseado em solicitação. Para fluxos de trabalho padrão, você pode usar outros tipos de autenticação sem desabilitar o SAS.

Nota

Essa ação desabilita a autenticação SAS para solicitações de entrada e bloqueia o funcionamento de chaves ou assinaturas SAS existentes. No entanto, suas chaves ou assinaturas SAS permanecem válidas e ainda funcionam se você habilitar a autenticação SAS novamente. Para desativar chaves e assinaturas SAS criando novas versões, consulte Regenerar chaves de acesso.

Depois de desabilitar a autenticação SAS, a URL do ponto de extremidade para o gatilho Request não inclui mais a chave SAS, por exemplo:

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

Pré-requisitos

Para esta tarefa, você precisa de uma ferramenta para enviar chamadas de API REST, por exemplo:

Atenção

Para cenários em que você tem dados confidenciais, como credenciais, segredos, tokens de acesso, chaves de API e outras informações semelhantes, certifique-se de usar uma ferramenta que proteja seus dados com os recursos de segurança necessários, funcione offline ou localmente, não sincronize seus dados com a nuvem e não exija que você entre em uma conta online. Dessa forma, você reduz o risco de exposição de dados confidenciais ao público.

Verifique se há gatilhos com SAS ativado ou desativado

Quando a autenticação SAS está desativada, a URL do ponto de extremidade do gatilho não inclui mais a chave SAS. Além disso, a definição de fluxo de trabalho Consumption inclui o objeto JSON sasAuthenticationPolicy . Este objeto tem uma propriedade de estado definida como Disabled, por exemplo:

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

Para localizar fluxos de trabalho de Consumo em que o SAS está habilitado ou desabilitado, verifique se a definição do fluxo de trabalho inclui o objeto sasAuthenticationPolicy onde a propriedade state está definida como Disabled.

  1. Com sua ferramenta que envia chamadas de API REST, obtenha informações sobre seu fluxo de trabalho executando a operação Fluxos de trabalho - Obter usando a seguinte solicitação GET, por exemplo:

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

  2. Pegue a saída da operação Workflows - Get e verifique se o objeto sasAuthenticationPolicy existe onde a propriedade state está definida como Disabled.

Adicione a propriedade sasAuthenticationPolicy à sua definição de fluxo de trabalho

Para fluxos de trabalho de Consumo em que você deseja desabilitar a autenticação SAS, siga estas etapas:

  1. Se você ainda não tiver feito isso, obtenha informações sobre seu fluxo de trabalho executando a operação Fluxos de trabalho - Obter usando a seguinte solicitação GET, por exemplo:

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

  2. Pegue a saída da operação Fluxos de trabalho - Obter e adicione manualmente os seguintes elementos:

    1. properties No objeto, adicione um accessControl objeto que contenha um triggers objeto, se nenhum existir.

    2. triggers No objeto, adicione um sasAuthenticationPolicy objeto que contenha a state propriedade definida como Disabled.

    Quando terminar, a parte editada terá a seguinte aparência:

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

  3. Envie outra solicitação para atualizar seu fluxo de trabalho com a saída editada, que você usa como entrada no corpo da solicitação, executando a operação Fluxos de trabalho - Atualização usando a seguinte solicitação PUT, por exemplo:

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

  4. No portal do Azure, vá para o fluxo de trabalho de Consumo no designer e confirme se a URL do gatilho de Solicitação não inclui mais a SAS.

  5. Para habilitar o Oauth 2.0 com o Microsoft Entra ID, no nível de recurso do aplicativo lógico, adicione uma política de autorização para OAuth com o Microsoft Entra ID.

    Para obter mais informações, consulte Habilitar o OAuth 2.0 com o Microsoft Entra ID.

Regenerar chaves de acesso

Para manter a segurança e proteger o acesso ao fluxo de trabalho do seu aplicativo lógico, regenere as chaves de acesso regularmente, pois elas podem precisar estar em conformidade com as políticas de segurança ou ficar comprometidas. Dessa forma, você pode ter certeza de que apenas solicitações autorizadas podem acionar seu fluxo de trabalho, o que protege seus dados e processos contra acesso não autorizado.

Para gerar uma nova chave de acesso a qualquer momento, use a API REST do Azure ou o portal do Azure. Todos os URIs ou URLs gerados anteriormente que usam a chave antiga são invalidados e não têm mais autorização para acionar o fluxo de trabalho do aplicativo lógico. Os URIs recuperados após a regeneração são assinados com a nova chave de acesso.

  1. No portal do Azure, abra o recurso de aplicativo lógico que usa a chave que você deseja regenerar.

  2. No menu de recursos do aplicativo lógico, em Configurações, selecione Chaves de acesso.

  3. Selecione a chave que deseja regenerar e conclua o processo.

Importante

Certifique-se de proteger sua chave de acesso da mesma forma que protege uma chave de conta contra uso não autorizado. Configure ou tenha um plano para revogar uma chave de acesso comprometida. Use a discrição ao distribuir URIs que usam chaves de acesso e distribua apenas esses URIs em uma conexão segura, como HTTPS. Certifique-se de executar apenas operações que usam uma chave de acesso em uma conexão HTTPS. Qualquer pessoa que tenha um URI com chave válida pode acessar o recurso associado.

Se você usar uma chave SAS para acessar serviços de armazenamento, a Microsoft recomenda que você crie uma SAS de delegação de usuário, que é protegida com a ID do Microsoft Entra, em vez de uma chave de conta.

Para uma segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Esta opção fornece segurança superior sem ter que fornecer credenciais. O Azure gerencia essa identidade e ajuda a manter as informações de autenticação seguras para que você não precise gerenciar essas informações confidenciais. Para configurar uma identidade gerenciada para Aplicativos Lógicos do Azure, consulte Autenticar acesso e conexões com recursos do Azure com identidades gerenciadas em Aplicativos Lógicos do Azure.

Criar URLs de retorno de chamada expirando

Se você compartilhar a URL do ponto de extremidade para um gatilho baseado em solicitação com outras partes, poderá gerar URLs de retorno de chamada que usam chaves específicas e têm datas de validade. Dessa forma, você pode rolar teclas sem problemas ou restringir o acesso para acionar seu aplicativo lógico com base em um período de tempo específico. Para especificar uma data de expiração para uma URL, use a API REST dos Aplicativos Lógicos do Azure, por exemplo:

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

No corpo, inclua a NotAfter propriedade usando uma cadeia de caracteres de data JSON. Essa propriedade retorna uma URL de retorno de chamada válida somente até a data e a NotAfter hora.

Criar URLs com chave secreta primária ou secundária

Ao gerar ou listar URLs de retorno de chamada para um gatilho baseado em solicitação, você pode especificar a chave a ser usada para assinar a URL. Para gerar uma URL assinada por uma chave específica, use a API REST dos Aplicativos Lógicos do Azure, por exemplo:

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

No corpo, inclua a KeyType propriedade como ou Primary Secondary. Essa propriedade retorna uma URL assinada pela chave de segurança especificada.

Exponha seu fluxo de trabalho de aplicativo lógico com o Gerenciamento de API do Azure

Para obter mais protocolos e opções de autenticação, considere expor seu fluxo de trabalho de aplicativo lógico como uma API usando o Gerenciamento de API do Azure. Este serviço fornece recursos avançados de monitoramento, segurança, política e documentação para qualquer ponto de extremidade. O Gerenciamento de API pode expor um ponto de extremidade público ou privado para seu aplicativo lógico. Para autorizar o acesso a esse ponto de extremidade, você pode usar o OAuth com o Microsoft Entra ID, certificado de cliente ou outros padrões de segurança. Quando o Gerenciamento de API recebe uma solicitação, o serviço envia a solicitação para seu aplicativo lógico e faz as transformações ou restrições necessárias ao longo do caminho. Para permitir que apenas o Gerenciamento de API chame o fluxo de trabalho do aplicativo lógico, você pode restringir os endereços IP de entrada do aplicativo lógico.

Para obter mais informações, veja a seguinte documentação:

Restringir endereços IP de entrada

Junto com a Assinatura de Acesso Compartilhado (SAS), talvez você queira limitar especificamente os clientes que podem chamar seu fluxo de trabalho de aplicativo lógico. Por exemplo, se você gerenciar seu ponto de extremidade de solicitação usando o Gerenciamento de API do Azure, poderá restringir o fluxo de trabalho do aplicativo lógico para aceitar solicitações somente do endereço IP da instância de serviço de Gerenciamento de API que você criar.

Independentemente de quaisquer endereços IP especificados, você ainda pode executar um fluxo de trabalho de aplicativo lógico que tenha um gatilho baseado em solicitação usando a solicitação Workflow Triggers - Run operation ou usando o Gerenciamento de API. No entanto, esse cenário ainda requer autenticação na API REST do Azure. Todos os eventos aparecem no Log de Auditoria do Azure. Certifique-se de definir as políticas de controle de acesso de acordo.

Para restringir os endereços IP de entrada para o fluxo de trabalho do aplicativo lógico, siga as etapas correspondentes para o portal do Azure ou seu modelo do Azure Resource Manager. Um intervalo de IP válido usa estes formatos: x.x.x.x/x ou x.x.x.x-x.x.x.x

No portal do Azure, a restrição de endereço IP afeta gatilhos e ações, ao contrário da descrição no portal em Endereços IP de entrada permitidos. Para configurar esse filtro separadamente para gatilhos e ações, use o accessControl objeto em um modelo do Azure Resource Manager para seu recurso de aplicativo lógico ou a operação Fluxo de Trabalho - Criar ou Atualizar na API REST dos Aplicativos Lógicos do Azure.

Fluxos de trabalho de consumo

  1. No portal do Azure, abra seu aplicativo lógico de consumo no designer de fluxo de trabalho.

  2. No menu do aplicativo lógico, em Configurações, selecione Configurações do fluxo de trabalho.

  3. Na seção Configuração de controle de acesso, em Endereços IP de entrada permitidos, escolha o caminho para seu cenário:

    • Para tornar seu fluxo de trabalho chamável usando a ação interna dos Aplicativos Lógicos do Azure, mas apenas como um fluxo de trabalho aninhado, selecione Somente outros Aplicativos Lógicos. Essa opção funciona somente quando você usa a ação Aplicativos Lógicos do Azure para chamar o fluxo de trabalho aninhado.

      Essa opção grava uma matriz vazia no recurso do aplicativo lógico e exige que apenas chamadas de fluxos de trabalho pai que usam a ação interna Aplicativos Lógicos do Azure possam acionar o fluxo de trabalho aninhado.

    • Para tornar seu fluxo de trabalho chamável usando a ação HTTP, mas apenas como um fluxo de trabalho aninhado, selecione Intervalos de IP específicos. Quando a caixa Intervalos de IP para gatilhos for exibida, insira os endereços IP de saída do fluxo de trabalho pai. Um intervalo de IP válido usa estes formatos: x.x.x.x/x ou x.x.x.x-x.x.x.x

      Nota

      Se você usar a opção Somente outros aplicativos lógicos e a ação HTTP para chamar seu fluxo de trabalho aninhado, a chamada será bloqueada e você receberá um erro "401 não autorizado".

    • Para cenários em que você deseja restringir chamadas de entrada de outros IPs, quando a caixa Intervalos de IP para gatilhos for exibida, especifique os intervalos de endereços IP que o gatilho aceita. Um intervalo de IP válido usa estes formatos: x.x.x.x/x ou x.x.x.x-x.x.x.x

  4. Opcionalmente, em Restringir chamadas para obter mensagens de entrada e saída do histórico de execução para os endereços IP fornecidos, você pode especificar os intervalos de endereços IP para chamadas de entrada que podem acessar mensagens de entrada e saída no histórico de execução.

Fluxos de trabalho padrão

  1. No portal do Azure, abra seu recurso de aplicativo lógico padrão.

  2. No menu do aplicativo lógico, em Configurações, selecione Rede.

  3. Na seção Configuração de tráfego de entrada, ao lado de Acesso à rede pública, selecione Habilitado sem restrição de acesso.

  4. Na página Restrições de acesso, em Acesso ao aplicativo, selecione Habilitado em redes virtuais e endereços IP selecionados.

  5. Em Acesso ao site e regras, na guia Site principal, adicione uma ou mais regras para Permitir ou Negar solicitações de intervalos de IP específicos. Um intervalo de IP válido usa estes formatos: x.x.x.x/x ou x.x.x.x-x.x.x.x

    Para obter mais informações, consulte Bloqueando endereços IP de entrada nos Aplicativos Lógicos do Azure (Padrão).

Acesso a chamadas de saída a outros serviços e sistemas

Com base na capacidade do ponto de extremidade de destino, as chamadas de saída enviadas pelo gatilho HTTP ou ação HTTP suportam criptografia e são protegidas com Transport Layer Security (TLS) 1.0, 1.1 ou 1.2, anteriormente conhecido como Secure Sockets Layer (SSL). Os Aplicativos Lógicos do Azure negociam com o ponto de extremidade de destino usando a versão mais alta possível com suporte. Por exemplo, se o ponto de extremidade de destino suportar 1.2, o gatilho ou ação HTTP usará 1.2 primeiro. Caso contrário, o conector usa a próxima versão mais alta suportada.

Esta lista inclui informações sobre certificados autoassinados TLS/SSL:

  • Para fluxos de trabalho do aplicativo lógico de consumo no ambiente multilocatário dos Aplicativos Lógicos do Azure, as operações HTTP não permitem certificados TLS/SSL autoassinados. Se seu aplicativo lógico fizer uma chamada HTTP para um servidor e apresentar um certificado autoassinado TLS/SSL, a chamada HTTP falhará com um TrustFailure erro.

  • Para fluxos de trabalho de aplicativos lógicos padrão no ambiente de Aplicativos Lógicos do Azure de locatário único, as operações HTTP oferecem suporte a certificados TLS/SSL autoassinados. No entanto, você precisa concluir algumas etapas extras para esse tipo de autenticação. Caso contrário, a chamada falhará. Para obter mais informações, consulte Autenticação de certificado TLS/SSL para Aplicativos Lógicos do Azure de locatário único.

    Se você quiser usar o certificado de cliente ou OAuth com a ID do Microsoft Entra com o tipo de credencial de certificado , ainda precisará concluir algumas etapas adicionais para esse tipo de autenticação. Caso contrário, a chamada falhará. Para obter mais informações, consulte Certificado de cliente ou OAuth com ID do Microsoft Entra com o tipo de credencial "Certificado" para Aplicativos Lógicos do Azure de locatário único.

Aqui estão mais maneiras de ajudar a proteger pontos de extremidade que lidam com chamadas enviadas de seus fluxos de trabalho de aplicativos lógicos:

  • Adicione autenticação a solicitações de saída.

    Ao usar o gatilho ou ação HTTP para enviar chamadas de saída, você pode adicionar autenticação à solicitação enviada pelo seu aplicativo lógico. Por exemplo, você pode selecionar estes tipos de autenticação:

  • Restrinja o acesso a partir de endereços IP do fluxo de trabalho do aplicativo lógico.

    Todas as chamadas para pontos de extremidade de fluxos de trabalho de aplicativos lógicos são originadas de endereços IP designados específicos baseados nas regiões dos aplicativos lógicos. Você pode adicionar filtragem que aceita solicitações somente desses endereços IP. Para obter esses endereços IP, revise Limites e configuração para Aplicativos Lógicos do Azure.

  • Melhore a segurança de conexões com sistemas locais.

    As Aplicações Lógicas do Azure fornecem integração com estes serviços para ajudar a fornecer uma comunicação local mais segura e fiável.

    • Gateway de dados no local

      Muitos conectores gerenciados nos Aplicativos Lógicos do Azure facilitam conexões seguras com sistemas locais, como Sistema de Arquivos, SQL, SharePoint e DB2. O gateway envia dados de fontes locais em canais criptografados por meio do Barramento de Serviço do Azure. Todo o tráfego é originado como tráfego de saída seguro do agente de gateway. Saiba como funciona o gateway de dados local.

    • Conectar-se por meio do Gerenciamento de API do Azure

      O Gerenciamento de API do Azure fornece opções de conexão local, como rede virtual privada site a site e integração de Rota Expressa para proxy seguro e comunicação com sistemas locais. Se você tiver uma API que fornece acesso ao seu sistema local e tiver exposto essa API criando uma instância de serviço de Gerenciamento de API, poderá chamar essa API do fluxo de trabalho do seu aplicativo lógico selecionando a operação de Gerenciamento de API correspondente no designer de fluxo de trabalho.

      Nota

      O conector mostra apenas os serviços de Gerenciamento de API em que você tem permissões para exibir e se conectar, mas não mostra serviços de Gerenciamento de API baseados em consumo.

      Com base no tipo de recurso do aplicativo lógico, siga as etapas correspondentes:

      Fluxos de trabalho de consumo

      1. Com base no fato de você estar adicionando um gatilho ou ação de Gerenciamento de API, siga estas etapas:

        • Gatilho:

          1. No designer de fluxo de trabalho, selecione Adicionar um gatilho.

          2. Depois que o painel Adicionar um gatilho for aberto, na caixa de pesquisa, digite Gerenciamento de API.

          3. Na lista de resultados do gatilho, selecione Escolher um Gatilho de Gerenciamento de API do Azure.

        • Ação:

          1. No designer de fluxo de trabalho, selecione o sinal de adição (+) onde você deseja adicionar a ação.

          2. Depois que o painel Adicionar uma ação for aberto, na caixa de pesquisa, digite Gerenciamento de API.

          3. Na lista de resultados da ação, selecione Escolher uma ação de Gerenciamento de API do Azure.

        O exemplo a seguir mostra como localizar um gatilho de Gerenciamento de API do Azure:

        A captura de tela mostra o portal do Azure, o designer de fluxo de trabalho de Consumo e a localização de um gatilho de Gerenciamento de API.

      2. Na lista Instância de serviço de Gerenciamento de API, selecione sua instância de serviço de Gerenciamento de API criada anteriormente.

      3. Na lista de operações da API, selecione a operação da API a ser chamada e, em seguida, selecione Adicionar ação.

      Fluxos de trabalho padrão

      Para fluxos de trabalho padrão, você só pode adicionar ações de Gerenciamento de API, não gatilhos.

      1. No designer de fluxo de trabalho, selecione o sinal de adição (+) onde você deseja adicionar a ação.

      2. Depois que o painel Adicionar uma ação for aberto, na caixa de pesquisa, digite Gerenciamento de API.

      3. Na lista de resultados da ação, selecione Chamar uma API de Gerenciamento de API do Azure.

        A captura de tela mostra o portal do Azure, o designer de fluxo de trabalho padrão e a ação de Gerenciamento de API do Azure.

      4. Na lista Instância de serviço de Gerenciamento de API, selecione sua instância de serviço de Gerenciamento de API criada anteriormente.

      5. Na lista de operações da API, selecione a operação da API a ser chamada e, em seguida, selecione Criar nova.

        A captura de tela mostra o portal do Azure, o designer de fluxo de trabalho padrão e a API selecionada para chamar.

Adicionar autenticação a chamadas de saída

Os pontos de extremidade HTTP e HTTPS suportam vários tipos de autenticação. Em alguns gatilhos e ações que você usa para enviar chamadas ou solicitações de saída para esses pontos de extremidade, você pode especificar um tipo de autenticação. No designer de fluxo de trabalho, os gatilhos e ações que dão suporte à escolha de um tipo de autenticação têm uma propriedade Authentication . No entanto, essa propriedade nem sempre aparece por padrão. Nesses casos, no gatilho ou ação, abra a lista Parâmetros avançados e selecione Autenticação.

Importante

Para proteger informações confidenciais que o fluxo de trabalho do aplicativo lógico manipula, use parâmetros seguros e codifique dados conforme necessário. Para obter mais informações sobre como usar e proteger parâmetros, consulte Acesso a entradas de parâmetros.

Para uma segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Esta opção fornece segurança superior sem ter que fornecer credenciais. O Azure gerencia essa identidade e ajuda a manter as informações de autenticação seguras para que você não precise gerenciar essas informações confidenciais. Para configurar uma identidade gerenciada para Aplicativos Lógicos do Azure, consulte Autenticar acesso e conexões com recursos do Azure com identidades gerenciadas em Aplicativos Lógicos do Azure.

Autenticação básica

Para chamadas HTTP, a autenticação básica usa uma cadeia de caracteres codificada em base64 que contém um nome de usuário e senha para fazer uma solicitação. Esse método transmite credenciais sem criptografia e representa maiores riscos de segurança, a menos que você use essa opção com o protocolo HTTPS/SSL.

Importante

Para uma segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Esta opção fornece segurança superior sem ter que fornecer credenciais. O Azure gerencia essa identidade e ajuda a manter as informações de autenticação seguras para que você não precise gerenciar essas informações confidenciais. Para configurar uma identidade gerenciada para Aplicativos Lógicos do Azure, consulte Autenticar acesso e conexões com recursos do Azure com identidades gerenciadas em Aplicativos Lógicos do Azure.

Se a opção Basic estiver disponível e selecionada, especifique estes valores de propriedade:

Propriedade (designer) Propriedade (JSON) Necessário Valor Description
Autenticação type Sim Básica O tipo de autenticação a ser usado
Nome de utilizador username Sim <nome de utilizador> O nome de usuário para autenticar o acesso ao ponto de extremidade do serviço de destino
Palavra-passe password Sim <palavra-passe> A senha para autenticar o acesso ao ponto de extremidade do serviço de destino

Quando você usa parâmetros seguros para manipular e proteger informações confidenciais, por exemplo, em um modelo do Azure Resource Manager para automatizar a implantação, você pode usar expressões para acessar esses valores de parâmetro em tempo de execução. Este exemplo de definição de ação HTTP especifica a autenticação type como Basic e usa a função parameters() para obter os valores de parâmetro:

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

Autenticação de certificados de cliente

A autenticação de certificado de cliente permite ou exige que os usuários se autentiquem diretamente com certificados X.509 em sua ID do Microsoft Entra para aplicativos e entrada no navegador. Esse recurso ajuda você a adotar uma autenticação resistente a phishing e autenticar com um certificado X.509 em sua PKI (infraestrutura de chave pública).

Importante

Para uma segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Esta opção fornece segurança superior sem ter que fornecer credenciais. O Azure gerencia essa identidade e ajuda a manter as informações de autenticação seguras para que você não precise gerenciar essas informações confidenciais. Para configurar uma identidade gerenciada para Aplicativos Lógicos do Azure, consulte Autenticar acesso e conexões com recursos do Azure com identidades gerenciadas em Aplicativos Lógicos do Azure.

Se a opção Certificado de cliente estiver disponível e selecionada, especifique estes valores de propriedade:

Propriedade (designer) Propriedade (JSON) Necessário Valor Description
Autenticação type Sim Certificado do cliente
ou
ClientCertificate		 O tipo de autenticação a ser usado. Você pode gerenciar certificados com o Gerenciamento de API do Azure.

Nota: Os conectores personalizados não suportam autenticação baseada em certificado para chamadas de entrada e saída.
Pfx pfx Sim <encoded-pfx-file-content> O conteúdo codificado em base64 de um arquivo PFX (Personal Information Exchange)

Para converter o arquivo PFX em formato codificado em base64, você pode usar o PowerShell 7 seguindo estas etapas:

1. Salve o conteúdo do certificado em uma variável:

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

2. Converta o conteúdo do certificado usando a ToBase64String() função e salve esse conteúdo em um arquivo de texto:

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

Resolução de problemas: Se utilizar o cert mmc/PowerShell comando, poderá obter este erro:

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

Para resolver esse erro, tente converter o arquivo PFX em um arquivo PEM e volte novamente usando o openssl comando:

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

Depois, quando você obtém a cadeia de caracteres codificada em base64 para o arquivo PFX recém-convertido do certificado, a cadeia de caracteres agora funciona nos Aplicativos Lógicos do Azure.
Palavra-passe password Não <senha-para-pfx-file> A senha para acessar o arquivo PFX

Nota

Se você tentar autenticar com um certificado de cliente usando OpenSSL, você pode obter o seguinte erro:

BadRequest: Could not load private key

Para resolver este erro, siga estes passos:

  1. Desinstale todas as instâncias OpenSSL.
  2. Instale o OpenSSL versão 1.1.1t.
  3. Renuncie ao seu certificado usando a nova atualização.
  4. Adicione o novo certificado à operação HTTP ao usar a autenticação de certificado de cliente.

Quando você usa parâmetros seguros para manipular e proteger informações confidenciais, por exemplo, em um modelo do Azure Resource Manager para automatizar a implantação, você pode usar expressões para acessar esses valores de parâmetro em tempo de execução. Este exemplo de definição de ação HTTP especifica a autenticação type como ClientCertificate e usa a função parameters() para obter os valores de parâmetro:

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

Importante

Se você tiver um recurso de aplicativo lógico padrão em Aplicativos Lógicos do Azure de locatário único e quiser usar uma operação HTTP com um certificado TSL/SSL, certificado de cliente ou Autenticação Aberta de ID do Microsoft Entra (Microsoft Entra ID OAuth) com o Certificate tipo de credencial, conclua as etapas de configuração adicionais para esse tipo de autenticação. Caso contrário, a chamada falhará. Para obter mais informações, consulte Autenticação em ambiente de locatário único.

Para obter mais informações sobre como proteger serviços usando a autenticação de certificado de cliente, revise estes tópicos:

Plataforma Microsoft Entra

No gatilho Solicitação, você pode usar a plataforma Microsoft Entra para autenticar chamadas de entrada depois de configurar as políticas de autorização do Microsoft Entra para seu aplicativo lógico.

Importante

Para uma segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Esta opção fornece segurança superior sem ter que fornecer credenciais. O Azure gerencia essa identidade e ajuda a manter as informações de autenticação seguras para que você não precise gerenciar essas informações confidenciais. Para configurar uma identidade gerenciada para Aplicativos Lógicos do Azure, consulte Autenticar acesso e conexões com recursos do Azure com identidades gerenciadas em Aplicativos Lógicos do Azure.

Em todos os outros gatilhos e ações que suportam o tipo de autenticação OAuth (OAuth 2.0 com ID do Microsoft Entra), especifique estes valores de propriedade:

Propriedade (designer) Propriedade (JSON) Necessário Valor Description
Autenticação type Sim Ative Directory OAuth (OAuth 2.0 com ID do Microsoft Entra)
ou
ActiveDirectoryOAuth		 O tipo de autenticação a ser usado. Atualmente, os Aplicativos Lógicos do Azure seguem o protocolo OAuth 2.0.
Autoridade authority Não <URL-para-autoridade-token-issuer> A URL da autoridade que fornece a chave de acesso, como https://login.microsoftonline.com/ para regiões de serviço global do Azure. Para outras nuvens nacionais, consulte Pontos de extremidade de autenticação do Microsoft Entra - Escolhendo sua autoridade de identidade.
Inquilino tenant Sim <ID do locatário> A ID do locatário do Microsoft Entra
Público-alvo audience Sim <recurso para autorizar> O recurso que você deseja usar para autorização, por exemplo, https://management.core.windows.net/
ID de Cliente clientId Sim <ID do cliente> A ID do cliente para o aplicativo que solicita autorização
Tipo de credencial credentialType Sim Certidão
ou
Segredo		 O tipo de credencial que o cliente usa para solicitar autorização. Essa propriedade e esse valor não aparecem na definição subjacente do seu aplicativo lógico, mas determinam as propriedades que aparecem para o tipo de credencial selecionado.
Segredo secret Sim, mas apenas para o tipo de credencial "Secreto" <Segredo do cliente> O segredo do cliente para solicitar autorização
Pfx pfx Sim, mas apenas para o tipo de credencial "Certificado" <encoded-pfx-file-content> O conteúdo codificado em base64 de um arquivo PFX (Personal Information Exchange)
Palavra-passe password Sim, mas apenas para o tipo de credencial "Certificado" <senha-para-pfx-file> A senha para acessar o arquivo PFX

Quando você usa parâmetros seguros para manipular e proteger informações confidenciais, por exemplo, em um modelo do Azure Resource Manager para automatizar a implantação, você pode usar expressões para acessar esses valores de parâmetro em tempo de execução. Este exemplo de definição de ação HTTP especifica a autenticação type como ActiveDirectoryOAuth, o tipo de credencial como Secret, e usa a função parameters() para obter os valores de parâmetro:

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

Importante

Se você tiver um recurso de aplicativo lógico padrão em Aplicativos Lógicos do Azure de locatário único e quiser usar uma operação HTTP com um certificado TSL/SSL, certificado de cliente ou Microsoft Entra ID OAuth com o Certificate tipo de credencial, conclua as etapas de configuração adicionais para esse tipo de autenticação. Caso contrário, a chamada falhará. Para obter mais informações, consulte Autenticação em ambiente de locatário único.

Autenticação bruta

Se a opção Raw estiver disponível, você poderá usar esse tipo de autenticação quando precisar usar esquemas de autenticação que não sigam o protocolo OAuth 2.0. Com esse tipo, você cria manualmente o valor do cabeçalho de autorização que envia com a solicitação de saída e especifica esse valor de cabeçalho em seu gatilho ou ação.

Importante

Para uma segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Esta opção fornece segurança superior sem ter que fornecer credenciais. O Azure gerencia essa identidade e ajuda a manter as informações de autenticação seguras para que você não precise gerenciar essas informações confidenciais. Para configurar uma identidade gerenciada para Aplicativos Lógicos do Azure, consulte Autenticar acesso e conexões com recursos do Azure com identidades gerenciadas em Aplicativos Lógicos do Azure.

O exemplo a seguir mostra um cabeçalho de exemplo para uma solicitação HTTPS que segue o protocolo 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"

No gatilho ou ação que oferece suporte à autenticação bruta, especifique estes valores de propriedade:

Propriedade (designer) Propriedade (JSON) Necessário Valor Description
Autenticação type Sim Raw O tipo de autenticação a ser usado
Valor value Sim <authorization-header-value> O valor do cabeçalho de autorização a ser usado para autenticação

Quando você usa parâmetros seguros para manipular e proteger informações confidenciais, por exemplo, em um modelo do Azure Resource Manager para automatizar a implantação, você pode usar expressões para acessar esses valores de parâmetro em tempo de execução. Este exemplo de definição de ação HTTP especifica a autenticação type como Raw, e usa a função parameters() para obter os valores de parâmetro:

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

Autenticação de identidade gerida

Quando a opção de identidade gerenciada estiver disponível no gatilho ou ação que dá suporte à autenticação de identidade gerenciada, seu aplicativo lógico poderá usar essa identidade para autenticar o acesso aos recursos do Azure protegidos pela ID do Microsoft Entra, em vez de credenciais, segredos ou tokens do Microsoft Entra. O Azure gerencia essa identidade para você e ajuda você a proteger suas credenciais porque você não precisa gerenciar segredos ou usar diretamente os tokens do Microsoft Entra. Saiba mais sobre os serviços do Azure que suportam identidades gerenciadas para autenticação do Microsoft Entra.

  • Um recurso de aplicativo lógico de consumo pode usar a identidade atribuída pelo sistema ou uma única identidade atribuída pelo usuário criada manualmente.

  • Um recurso de aplicativo lógico padrão oferece suporte a ter a identidade gerenciada atribuída pelo sistema e várias identidades gerenciadas atribuídas pelo usuário habilitadas ao mesmo tempo, embora você ainda possa selecionar apenas uma identidade para usar a qualquer momento.

    Nota

    Por padrão, a identidade atribuída ao sistema já está habilitada para autenticar conexões em tempo de execução. Essa identidade difere das credenciais de autenticação ou da cadeia de conexão que você usa ao criar uma conexão. Se você desabilitar essa identidade, as conexões não funcionarão em tempo de execução. Para exibir essa configuração, no menu do aplicativo lógico, em Configurações, selecione Identidade.

  1. Antes que seu aplicativo lógico possa usar uma identidade gerenciada, siga as etapas em Autenticar o acesso aos recursos do Azure usando identidades gerenciadas nos Aplicativos Lógicos do Azure. Estas etapas habilitam a identidade gerenciada em seu aplicativo lógico e configuram o acesso dessa identidade ao recurso do Azure de destino.

  2. Antes que uma função do Azure possa usar uma identidade gerenciada, primeiro habilite a autenticação para funções do Azure.

  3. No gatilho ou ação que suporta o uso de uma identidade gerenciada, forneça estas informações:

    Gatilhos e ações integrados

    Propriedade (designer) Propriedade (JSON) Necessário Valor Description
    Autenticação type Sim Identidade Gerida
    ou
    ManagedServiceIdentity    		 O tipo de autenticação a ser usado
    Identidade Gerida identity Não <ID de identidade atribuída pelo usuário> A identidade gerenciada atribuída pelo usuário a ser usada. Nota: Não inclua essa propriedade ao usar a identidade gerenciada atribuída ao sistema.
    Público-alvo audience Sim <ID do recurso de destino> A ID do recurso de destino que você deseja acessar.

    Por exemplo, https://storage.azure.com/ torna os tokens de acesso para autenticação válidos para todas as contas de armazenamento. No entanto, você também pode especificar uma URL de serviço raiz, como https://fabrikamstorageaccount.blob.core.windows.net para uma conta de armazenamento específica.

    Observação: a propriedade Audience pode estar oculta em alguns gatilhos ou ações. Para tornar essa propriedade visível, no gatilho ou ação, abra a lista Parâmetros avançados e selecione Público.

    Importante: Certifique-se de que este ID de recurso de destino corresponde exatamente ao valor esperado pelo ID do Microsoft Entra, incluindo quaisquer barras à direita necessárias. Portanto, a ID do https://storage.azure.com/ recurso para todas as contas de Armazenamento de Blob do Azure requer uma barra à direita. No entanto, o ID do recurso para uma conta de armazenamento específica não requer uma barra à direita. Para encontrar essas IDs de recurso, consulte os serviços do Azure que oferecem suporte à ID do Microsoft Entra.

    Quando você usa parâmetros seguros para manipular e proteger informações confidenciais, por exemplo, em um modelo do Azure Resource Manager para automatizar a implantação, você pode usar expressões para acessar esses valores de parâmetro em tempo de execução. Por exemplo, esta definição de ação HTTP especifica a autenticação type como ManagedServiceIdentity e usa a função parameters() para obter os valores de parâmetro:

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

    Acionadores e ações do conector gerenciado

    Propriedade (designer) Necessário Valor Description
    Nome da ligação Sim <nome da conexão>
    Identidade gerida Sim Identidade gerenciada atribuída ao sistema
    ou
    <nome da identidade gerenciada pelo usuário>    		 O tipo de autenticação a ser usado

Bloquear a criação de ligações

Se sua organização não permitir a conexão a recursos específicos usando seus conectores nos Aplicativos Lógicos do Azure, você poderá bloquear a capacidade de criar essas conexões para conectores específicos em fluxos de trabalho de aplicativos lógicos usando a Política do Azure. Para obter mais informações, consulte Bloquear conexões criadas por conectores específicos nos Aplicativos Lógicos do Azure.

Documentação de orientação do isolamento para aplicações lógicas

Para obter mais informações sobre isolamento, consulte a seguinte documentação:

Conteúdos relacionados