Compartilhar via

Proteger o acesso e os dados para fluxos de trabalho nos Aplicativos Lógicos do Azure

  • Artigo

Os Aplicativos Lógicos do Azure dependem do armazenamento do Microsoft Azure para armazenar e criptografar os dados inativos automaticamente. Essa criptografia protege seus dados e ajuda a cumprir os compromissos de conformidade e segurança de sua organização. Por padrão, o armazenamento do Microsoft Azure usa chaves gerenciadas pela Microsoft para criptografar seus dados. Para obter mais informações, examine Criptografia do Armazenamento do Microsoft Azure para dados inativos.

Para controlar ainda mais o acesso e proteger dados confidenciais em Aplicativos Lógicos do Azure, você poderá configurar mais segurança adicional nestas áreas:

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

Acesso a operações de aplicativo lógico

Somente para aplicativos lógicos de Consumo, para 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 RBAC (controle de acesso baseado em função) do Azure. Também é possível configurar permissões para que somente usuários ou grupos específicos possam executar tarefas específicas, como gerenciar, editar e exibir aplicativos lógicos. Para controlar as 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, caso você tenha um fluxo de trabalho de aplicativo lógico de Consumo ou Standard:

fluxo de trabalho de Consumo
Função Descrição
Colaborador de Aplicativo Lógico É possível gerenciar fluxos de trabalho de aplicativo lógico, mas não é possível alterar o acesso a eles.
Operador de Aplicativo Lógico É possível ler, habilitar e desabilitar fluxos de trabalho de aplicativos lógicos, mas não é possível editá-los ou atualizá-los.
Colaborador Você tem acesso completo para gerenciar todos os recursos, mas não pode atribuir funções no Azure RBAC, gerenciar atribuições no Azure Blueprints nem compartilhar galerias de imagens.

Por exemplo, digamos que você tem que trabalhar com um fluxo de trabalho do aplicativo lógico que você não criou e autenticar conexões usadas pelo fluxo de trabalho do aplicativo lógico. Sua assinatura do Azure exige 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 o fluxo de trabalho do aplicativo lógico, você pode usar Bloqueio de recurso do Azure. Essa funcionalidade ajuda a evitar que outras pessoas alterem ou excluam recursos de produção. Para obter mais informações sobre a segurança da conexão, veja Configuração de conexão em Aplicativos Lógicos do Azure e Segurança e criptografia da conexão.

Fluxo de trabalho Standard

Observação

Esse recurso está em versão prévia e está sujeito aos Termos de uso suplementares para versões prévias do Microsoft Azure.

Função Descrição
Leitor Standard de Aplicativos Lógicos (versão prévia) Você tem acesso somente leitura a todos os recursos em um aplicativo lógico Standard e fluxos de trabalho, incluindo as execuções de fluxo de trabalho e seu histórico.
Operador Standard de Aplicativos Lógicos (versão prévia) Você tem acesso para habilitar, reenviar, desabilitar fluxos de trabalho e criar conexões com serviços, sistemas e redes de um aplicativo lógico Standard. A função Operador pode realizar tarefas de administração e suporte na plataforma de Aplicativos Lógicos do Azure, mas não tem permissões para editar fluxos de trabalho ou configurações.
Desenvolvedor Standard de Aplicativos Lógicos (versão prévia) Você tem acesso para criar e editar fluxos de trabalho, conexões e configurações para um aplicativo lógico Standard. 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. Não há suporte para Planos do Serviço de Aplicativo.
Colaborador Standard de Aplicativos Lógicos (versão prévia) Você tem acesso para gerenciar todos os aspectos de um aplicativo lógico Standard, mas não pode alterar o acesso ou a propriedade.

Acessar 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 protocolo TLS e em repouso. Quando seu aplicativo lógico terminar de ser executado, você poderá exibir o histórico dessa execução, incluindo as etapas que foram executadas, o status, a duração, as entradas e as saídas de cada ação. Esse alto nível de detalhes fornece informações sobre como seu aplicativo lógico foi executado e onde você pode começar a solucionar problemas que surjam.

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

Para controlar o acesso às entradas e saídas no histórico de execuções do 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 seu aplicativo lógico para que somente solicitações de intervalos de endereços IP específicos possam visualizar 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. Apenas uma pessoa com permissões de administrador pode remover essa restrição, o que dá a possibilidade de acesso "Just-In-Time" aos dados dos fluxos de trabalho do aplicativo lógico. Um intervalo IP válido usa estes formatos: 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 Standard no portal do Azure ou no modelo do Azure Resource Manager:

fluxo 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 de fluxo de trabalho.

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

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

Fluxo de trabalho Standard

  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 do Acesso à rede pública, selecione Habilitado sem restrição de acesso.

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

  5. Nas Regras e no acesso ao site, 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 de filtro de cabeçalho HTTP e as configurações de encaminhamento. Um intervalo IP válido usa estes formatos: x.x.x. ou x.x.x. x-x.x.x. x

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

Proteger dados no histórico de execuções usando ofuscação

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

Entradas seguras – Sem suporte Saídas seguras – Sem suporte
Acrescentar à variável de matriz
Acrescentar à variável de cadeia de caracteres
Diminuir variável
Para cada
Se
Incrementar variável
Inicializar variável
Recorrência
Escopo
Definir variável
Opção
Terminate
Até		 Acrescentar à variável de matriz
Acrescentar à variável de cadeia de caracteres
Compor
Diminuir variável
Para cada
Se
Incrementar variável
Inicializar variável
Analisar o JSON
Recorrência
Resposta
Escopo
Definir variável
Opção
Terminate
Até
Aguarde

Considerações ao proteger entradas e saídas

Antes de usar essas configurações para ajudá-lo a proteger esses dados, examine 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 a Análise de Logs do Azure. Além disso, não é possível adicionar propriedades rastreadas a esse gatilho ou ação para monitoramento.

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

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

  • Ative as Entradas Seguras ou Saídas Seguras nas ações de downstream em que você espera que o histórico de execuções oculte 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ções. Se uma ação de downstream usar explicitamente essas saídas protegidas como entradas, os Aplicativos Lógicos do Azure ocultarão as entradas dessa ação no histórico de execuções, mas não habilitarão a configuração de Entradas Seguras da ação.

    Saídas protegidas como entradas e impacto downstream na maioria das ações

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

    Saídas protegidas como entradas com impacto downstream em ações específicas

    Configuração de Entradas 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ções. Se uma ação de 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 de downstream no histórico de execuções, mas não habilitarão as Entradas Seguras nessa ação e não ocultarão as saídas dessa ação.

    Entradas protegidas e impacto downstream na maioria das ações

    Se as ações de Compor, Analisar JSON e Responder usarem explicitamente as saídas visíveis do gatilho ou da ação que tem as entradas protegidas, 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 de downstream usar explicitamente as saídas ocultas das ações de Compor, Analisar JSON ou Responder como entradas, os Aplicativos Lógicos do Azure não ocultarão as entradas ou saídas da ação de downstream.

    Entradas protegidas e impacto downstream em ações específicas

Proteger entradas e saídas no designer

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

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

  3. No painel de informações que é aberto, 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 ação com configurações abertas.

  4. Ative as Entradas Seguras, Saídas Seguras ou ambas.

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

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

    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 a saída protegida com o ícone de bloqueio.

  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ógico de Consumo ou no menu de fluxo de trabalho Standard.

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

    3. No painel histórico de execução do fluxo de trabalho, selecione as ações que você deseja examinar.

      Se você optar por ocultar as entradas e saídas, esses valores agora aparecerão ocultos.

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

Proteger entradas e saídas no modo de exibição de código

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

  • "inputs": Protege as entradas no histórico de execuções.
  • "outputs": Protege as saídas no histórico de execuções.
"<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âmetro

Se você implantar em ambientes diferentes, considere a possibilidade de parametrização dos valores na definição do fluxo de trabalho que variam de acordo com esses ambientes. Dessa forma, você pode evitar dados embutidos em código usando um modelo do Azure Resource Manager para implantar seu aplicativo lógico, proteger dados confidenciais definindo parâmetros protegidos e passar esses dados como entradas separadas por meio dos parâmetros do modelo usando um arquivo de parâmetro.

Por exemplo, se você autenticar ações HTTP usando o OAuth com o Microsoft Entra ID, poderá definir e ofuscar os parâmetros que aceitam a ID do cliente e o segredo do cliente que são usados para autenticação. Para definir esses parâmetros em seu aplicativo lógico, use a seção parameters na definição de fluxo de trabalho do aplicativo lógico e um modelo do Resource Manager para implantação. Para proteger valores de parâmetro que você não deseja mostrar ao editar seu aplicativo lógico ou exibir o histórico de execuções, você pode definir os parâmetros usando o tipo securestring ou secureobject e a codificação conforme necessário. 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 runtime, use a expressão @parameters('<parameter-name>') dentro de sua definição de fluxo de trabalho. Essa expressão é avaliada apenas em runtime e é descrita pela Linguagem de Definição do Fluxo de Trabalho.

Observação

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ções do fluxo de trabalho e a solicitação HTTP de saída. Defina também suas políticas de acesso de conteúdo adequadamente. Você também pode usar ofuscação para ocultar entradas e saídas em seu histórico de execuções. Por padrão, os cabeçalhosAuthorization não ficam visíveis durante as entradas e saídas. Portanto, se um segredo for usado lá, ele não será recuperável.

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

Se você automatizar a implantação para aplicativos lógicos usando modelos do Resource Manager, poderá definir os parâmetros de modelo seguros, que são avaliados na implantação, usando os tipos securestring e secureobject. Para definir parâmetros de modelo, use a seção de parameters de nível superior do modelo, que é separada e diferente da seção parameters da definição de fluxo de trabalho. Para fornecer os valores dos 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 protegidos que recuperem esses segredos do Azure Key Vault na implantação. Em seguida, você pode fazer referência ao cofre de chaves e ao segredo em seu arquivo de parâmetro. Para saber mais, confira os tópicos:

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

Importante

Para obter segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Essa opção fornece segurança superior sem precisar fornecer credenciais. O Azure gerencia esta 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 o acesso e as conexões aos recursos do Azure com identidades gerenciadas nos 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": {}
}

Proteger parâmetros em modelos de Azure Resource Manager (Fluxo de trabalho de Consumo)

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

Importante

Para obter segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Essa opção fornece segurança superior sem precisar fornecer credenciais. O Azure gerencia esta 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 o acesso e as conexões aos recursos do Azure com identidades gerenciadas nos Aplicativos Lógicos do Azure.

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

  • No nível superior do modelo, uma seção parameters 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. Você pode armazenar esses valores em um arquivo de parâmetro separado, o que torna a alteração desses valores mais fácil.

  • Dentro da definição de recurso do aplicativo lógico, mas fora de sua definição de fluxo de trabalho, uma seção parameters especifica os valores para os parâmetros da definição de fluxo de trabalho. Nessa 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 de sua definição de fluxo de trabalho, uma seção parameters define os parâmetros que seu aplicativo lógico usa em runtime. Em seguida, você pode fazer referência a esses parâmetros dentro do fluxo de trabalho do aplicativo lógico usando expressões de definição de fluxo de trabalho, que são avaliadas em runtime.

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

Nome do parâmetro Descrição
TemplatePasswordParam Um parâmetro de modelo que aceita uma senha que é passada para o parâmetro basicAuthPasswordParam definição de fluxo de trabalho
TemplateUsernameParam Um parâmetro de modelo que aceita um nome de usuário que é passado para o parâmetro basicAuthUserNameParam da definição de 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 com suporte para autenticação

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

Tipo de autenticação Aplicativo lógico e conectores com suporte
Basic Gerenciamento de API do Azure, Serviço de Aplicativo do Azure, HTTP, HTTP + Swagger, Webhook HTTP
Certificado do cliente Gerenciamento de API do Azure, Serviço de Aplicativo do Azure, HTTP, HTTP + Swagger, Webhook HTTP
OAuth do Active Directory (OAuth 2.0 com Microsoft Entra ID) - Consumo: Gerenciamento de API do Azure, Serviço de Aplicativo do Azure, Azure Functions, HTTP, HTTP + Swagger, Webhook HTTP

- Standard: 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, Webhook HTTP, SQL Server
Bruta Gerenciamento de API do Azure, Serviço de Aplicativo do Azure, Azure Functions, HTTP, HTTP + Swagger, Webhook HTTP
Identidade gerenciada Conectores internos:

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

- Standard: 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, Webhook HTTP, SQL Server

Observação: atualmente, a maioria dos conectores integrados e baseados em provedores de serviços não tem suporte para a 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 Blobs 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, Filas do Azure, Azure Resource Manager, Barramento de Serviço do Azure, Azure Sentinel, Armazenamento de Tabelas do Azure, VM do Azure, HTTP com Microsoft Entra ID, SQL Server

Importante

Para obter segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Essa opção fornece segurança superior sem precisar fornecer credenciais. O Azure gerencia esta 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 o acesso e as conexões aos recursos do Azure com identidades gerenciadas nos Aplicativos Lógicos do Azure.

Acesso para chamadas de entrada para gatilhos baseados em solicitação

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

Observação

Se você obtiver erros de handshake de TLS, use o TLS 1.2. Para mais informações, consulte Solucionar o problema do TLS 1.0.

Para chamadas de entrada, use os seguintes conjuntos de criptografia:

  • 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, no momento, os Aplicativos Lógicos do Azure dão suporte a alguns conjuntos de criptografia mais antigos. No entanto, não use conjuntos de criptografia mais antigos ao desenvolver novos aplicativos, pois esses conjuntos podem não ter suporte no futuro.

Por exemplo, você pode encontrar os seguintes conjuntos de criptografia se inspecionar as mensagens de handshake de TLS nos Aplicativos Lógicos do Azure ou ao usar uma ferramenta de segurança na URL do aplicativo lógico. Novamente, não use esses conjuntos mais antigos:

  • 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 mais formas de se limitar o acesso aos gatilhos que recebem chamadas de entrada para o fluxo de trabalho do aplicativo lógico, de forma que apenas clientes autorizados podem fazer chamadas para o seu fluxo de trabalho:

Habilitar o 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 do recurso do aplicativo lógico. Dessa forma, as chamadas de entrada usam tokens de acesso OAuth para autorização.

Quando seu 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 em cada política de autorização. Se houver uma correspondência entre as declarações do token e todas as declarações em pelo menos uma política, a autorização terá sucesso na 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 Standard que começa com o gatilho de Solicitação (mas não um gatilho de webhook), você pode usar o provisionamento do Azure Functions para autenticar chamadas de entrada enviadas para o ponto de extremidade criado pelo gatilho de Solicitação usando uma identidade gerenciada. Essa provisão também é conhecida como "Autenticação Fácil". Para obter mais informações, consulte Disparar fluxos de trabalho em Aplicativos lógicos Standard com o Easy Auth.

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

  • Para obter segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Essa opção fornece segurança superior sem precisar fornecer credenciais. O Azure gerencia esta 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 o acesso e as conexões aos recursos do Azure com identidades gerenciadas nos 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 pode usar apenas um esquema de autorização, o OAuth 2.0 com o Microsoft Entra ID ou SAS (Assinaturas de Acesso Compartilhado). Embora o uso de um esquema não desabilite o outro, se usar ambos os esquemas simultaneamente, os Aplicativos Lógicos do Azure gera um erro porque o serviço não sabe qual esquema escolher. Se o fluxo de trabalho de Consumo começar com o gatilho de Solicitação, você pode 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 Standard, você pode usar outros tipos de autenticação sem desabilitar a SAS.

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

  • Seu 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 declarações. Para obter mais informações, confira 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 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, Audiência e Emissor. Esta seção de conteúdo de exemplo para um token de acesso decodificado inclui os dois tipos de declaração em que aud é o valor público e iss é o valor do emissor:

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

Habilitar 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 OAuth 2.0 com o Microsoft Entra ID. Essa opção funciona mesmo se você também desabilitar a autenticação SAS (Assinatura de Acesso Compartilhado).

  1. Para seu fluxo de trabalho de Consumo, configure o 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 'Authorization' nas saídas do gatilho de Solicitação ou de Webhook HTTP.

    Observação

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

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

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

  4. Em Geral>Condições de 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')

    -ou-

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

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

Obter um token PoP (prova de posse)

As bibliotecas da MSAL (Biblioteca de Autenticação da Microsoft) 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.

Habilitar 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 lógico de Consumo, siga as etapas do portal do Azure ou do modelo do ARM:

  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 Autorização.

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

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

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

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

    Propriedade Obrigatório Type Descrição
    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 de portador ou AADPOP para tokens do tipo Prova de Posse.
    Declarações Sim String Um par chave-valor que especifica o tipo de declaração e o valor que o Gatilho de solicitação 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 declaração padrão disponíveis:

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

    Requisitos:

    No mínimo, a lista de Declarações deve incluir a declaração de Emissor, que tem um valor que começa com https://sts.windows.net/ ou https://login.microsoftonline.com/ como a 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 Função como o tipo e o Desenvolvedor como o valor. Você não pode ter uma declaração que tem a Função como o tipo e os valores definidos como Desenvolvedor e Gerenciador de Programas.

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

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

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

    Captura de tela que 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 e especifique o valor.

    • Para adicionar sua declaração, selecione Adicionar declaração personalizada. Para obter mais informações, examine Como fornecer declarações opcionais ao aplicativo. Sua declaração personalizada é então armazenada como parte da ID do 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 terminar, selecione Salvar.

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

As propriedades do fluxo de trabalho, como as políticas, não aparecem no modo de exibição de código do fluxo de trabalho no portal do Azure. Para acessar às suas políticas de forma programática, chame a seguinte API por meio do Azure Resource Manager: 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 'Authorization' nas saídas de gatilho de webhook de solicitação ou HTTP

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

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

Para saber mais, confira os tópicos:

Gerar um token ou chave SAS (Assinatura de Acesso Compartilhado)

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 que pode ser chamado nesse gatilho. Esse ponto de extremidade tem uma URL que pode receber solicitações ou chamadas de entrada para iniciar o fluxo de trabalho. A URL inclui uma SAS (Assinatura de Acesso Compartilhado), que é uma chave ou token que concede permissões, por exemplo, aos serviços de armazenamento. A URL do 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 de Solicitação, localize a propriedade URL HTTP do gatilho:

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.

A URL completa se parece com o exemplo a seguir:

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

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

Parâmetro de consulta Descrição
sp Especifica as permissões para os métodos HTTP permitidos para uso.
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 de URL e propriedades. Essa chave é mantida em segredo, criptografada, armazenada com o aplicativo lógico e nunca é exposta ou publicada. Seu aplicativo lógico autoriza somente gatilhos que contenham 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 SAS 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 aplicativo lógico, regenere as chaves de acesso em um agendamento regular, pois elas podem precisar estar em conformidade com as políticas de segurança ou ficar comprometidas. Dessa forma, você pode garantir que somente solicitações autorizadas possam disparar seu fluxo de trabalho, que protege seus dados e processos contra acesso não autorizado.

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

Para obter segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Essa opção fornece segurança superior sem precisar fornecer credenciais. O Azure gerencia esta 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 o acesso e as conexões aos recursos do Azure com identidades gerenciadas nos Aplicativos Lógicos do Azure.

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

Se o fluxo de trabalho de Consumo começar com o gatilho de Solicitação, você poderá desabilitar a autenticação SAS. Essa opção funciona mesmo se você restringir a autorização para usar apenas OAuth 2.0 com o Microsoft Entra ID. Para fluxos de trabalho Standard, você pode usar outros tipos de autenticação sem desabilitar a SAS.

Para obter mais informações sobre segurança ao usar uma chave SAS, consulte as seguintes seções neste guia:

Desabilitar a autenticação da SAS (Assinatura de Acesso Compartilhado) (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 OAuth com o Microsoft Entra ID, você poderá desabilitar a autenticação SAS para evitar erros e problemas ao executar seu 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ê 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 Standard, você pode usar outros tipos de autenticação sem desabilitar a SAS.

Observação

Essa ação desabilita a autenticação SAS para solicitações de entrada e impede que chaves ou assinaturas SAS existentes funcionem. No entanto, suas chaves ou assinaturas SAS permanecem válidos e ainda funcionarão se você habilitar a autenticação SAS novamente. Para desabilitar as chaves e assinaturas SAS criando outras versões, confira Regenerar chaves de acesso.

Depois de desabilitar a autenticação SAS, a URL do ponto de extremidade do gatilho de Solicitação 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 essa tarefa, você precisa de uma ferramenta para enviar chamadas à API REST, por exemplo:

Cuidado

Para cenários em que você tem dados confidenciais, como credenciais, segredos, tokens de acesso, chaves de API e outras informações semelhantes, use 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 expor dados confidenciais ao público.

Verificar se há gatilhos com SAS habilitados ou desabilitados

Quando a autenticação SAS está desabilitada, 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 de Consumo inclui o objeto JSON sasAuthenticationPolicy. Esse objeto tem uma propriedade de estado definida como Desabilitada, por exemplo:

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

Para localizar fluxos de trabalho de Consumo em que a SAS está habilitada ou desabilitada, verifique se a definição de fluxo de trabalho inclui o objeto sasAuthenticationPolicy em que a propriedade de estado está definida como Desabilitada.

  1. Com sua ferramenta que envia chamadas à API REST, obtenha informações sobre seu fluxo de trabalho executando a operação Workflows - Get 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. Use a saída da operação Workflows - Get e verifique se o objeto sasAuthenticationPolicy existe onde a propriedade de estado está definida como Desabilitada.

Adicionar 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 ainda não o fez, obtenha informações sobre seu fluxo de trabalho executando a operação Workflows - Get 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. Use a saída da operação Workflows - Get e adicione manualmente os seguintes elementos:

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

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

    Quando você terminar, a parte editada se parecerá com o seguinte exemplo:

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

  3. Envie outra solicitação para atualizar o fluxo de trabalho com a saída editada, que você usa como entrada no corpo da solicitação, executando a operação Workflows — Atualização usando a seguinte solicitação de 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, acesse 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 do recurso do aplicativo lógico, adicione uma política de autorização para OAuth com o Microsoft Entra ID.

    Para obter mais informações, confira 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 aplicativo lógico, regenere as chaves de acesso em um agendamento regular, pois elas podem precisar estar em conformidade com as políticas de segurança ou ficar comprometidas. Dessa forma, você pode garantir que somente solicitações autorizadas possam disparar seu fluxo de trabalho, 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 ou o portal do Azure. Todas as URLs ou URIs gerados anteriormente que usam a chave antiga são invalidadas e não estão mais autorizadas a disparar o fluxo de trabalho de aplicativo lógico. Os URIs que você recupera após a regeneração são assinadas com a nova chave de acesso.

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

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

  3. Selecione a chave que você quer regenerar e conclua o processo.

Importante

Certifique-se de proteger sua chave de acesso 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 SAS em uma conexão HTTPS. Qualquer pessoa que tenha um URI com chave válida pode acessar o recurso associado.

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

Para obter segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Essa opção fornece segurança superior sem precisar fornecer credenciais. O Azure gerencia esta 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 o acesso e as conexões aos recursos do Azure com identidades gerenciadas nos Aplicativos Lógicos do Azure.

Criar URLs de retorno de chamada prestes a expirar

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 reverter tranquilamente as chaves ou restringir o acesso para disparar seu aplicativo lógico com base em um período específico. Para especificar uma data de validade 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 propriedade NotAfter usando uma cadeia de caracteres de data JSON. Essa propriedade retorna uma URL de retorno de chamada válida somente até a data e hora NotAfter.

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 propriedade KeyType como Primary ou Secondary. Essa propriedade retorna uma URL assinada pela chave de segurança especificada.

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

Para obter mais protocolos de autenticação e opções, 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, o certificado do cliente ou outros padrões de segurança. Quando o Gerenciamento de API recebe uma solicitação, o serviço envia a solicitação ao aplicativo lógico, fazendo quaisquer transformações ou restrições necessárias ao longo do caminho. Para permitir que apenas o Gerenciamento de API chame seu fluxo de trabalho de aplicativo lógico, você pode restringir os endereços IP de entrada do aplicativo lógico.

Para saber mais, confira a seguinte documentação:

Restringir endereços IP de entrada

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

Independentemente de qualquer endereço IP que especificar, você ainda pode executar um fluxo de trabalho de aplicativo lógico que tenha um gatilho baseado em solicitação usando a solicitação de operação Workflow Triggers - Run ou usando o Gerenciamento de API. Porém, esse cenário ainda requer autenticação em relação à API REST do Azure. Todos os eventos aparecem no Log de Auditoria do Azure. Verifique se você definiu as políticas de controle de acesso de forma adequada.

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

No portal do Azure, a restrição de endereço IP afeta os gatilhos e as 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 objeto accessControl em um modelo do ARM para seu recurso do aplicativo lógico ou a operação Workflow - Create Or Update na API REST dos Aplicativos Lógicos do Azure.

fluxo de trabalho de Consumo

  1. No portal do Azure, abra o 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 de fluxo de trabalho.

  3. Na seção configuração do 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 internados 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 dos Aplicativos Lógicos do Azure para chamar o fluxo de trabalho aninhado.

      Essa opção grava uma matriz vazia em seu recurso de aplicativo lógico e requer que apenas chamadas de fluxos de trabalho pai que usam a ação interna de Aplicativos Lógicos do Azure possam disparar o aplicativo lógico 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ídado fluxo de trabalho pai. Um intervalo IP válido usa estes formatos: x.x.x. ou x.x.x. x-x.x.x. x

      Observação

      Se você usar a opção Somente outros Aplicativos Lógicos e a ação HTTP para chamar seu aplicativo lógico 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 IP válido usa estes formatos: x.x.x. ou x.x.x. x-x.x.x. x

  4. Como opção, 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.

Fluxo de trabalho Standard

  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 do Acesso à rede pública, selecione Habilitado sem restrição de acesso.

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

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

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

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

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

Essa lista inclui informações sobre certificado autoassinado TLS/SSL:

  • Para fluxos de trabalho de aplicativos lógicos 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 TLS/SSL autoassinado, a chamada HTTP falhará com um erro TrustFailure.

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

    Se você quiser usar o certificado do cliente ou o OAuth com o Microsoft Entra ID com o tipo de credencial de Certificado, você ainda precisará concluir algumas etapas adicionais para este tipo de autenticação. Caso contrário, a chamada falhará. Para obter mais informações, confira Certificado do cliente ou OAuth com o Microsoft Entra ID 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 seu fluxo de trabalho de aplicativo lógico:

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

    Quando você usa o gatilho ou a 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:

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

    Todas as chamadas para pontos de extremidade de fluxos de trabalho de aplicativos lógicos originam-se de endereços IP especificamente designados que se baseiam nas regiões dos seus aplicativos lógicos. Você pode adicionar filtragem que aceite solicitações somente de endereços IP. Para obter esses endereços IP, examine Limites e configuração para Aplicativos Lógicos do Azure.

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

    Os Aplicativos Lógicos do Azure fornecem integração com esses serviços para ajudar a fornecer uma comunicação local mais segura e confiável.

    • Gateway de dados local

      Muitos conectores gerenciados nos Aplicativos Lógicos do Azure facilitam conexões seguras com sistemas locais, como o Sistema de Arquivos, o SQL, o SharePoint e o 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 o gateway de dados local funciona.

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

      O Gerenciamento de API do Azure fornece opções de conexão locais, como rede privada virtual site a site e integração do ExpressRoute para proxy seguro e comunicação com sistemas locais. Se você tiver uma API que forneça 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 aplicativo lógico selecionando a operação de Gerenciamento de API correspondente no designer de fluxo de trabalho.

      Observação

      O conector mostra apenas os serviços de gerenciamento de API em que você tem permissões para exibir e 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:

      fluxo de trabalho de Consumo

      1. Determine se você está adicionando um gatilho ou ação do Gerenciamento de API e 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, insira Gerenciamento de API.

          3. Na lista de resultados do gatilho, selecione Escolher um gatilho do 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, insira 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 encontrar um gatilho do 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 do Gerenciamento de API.

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

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

      Fluxo de trabalho Standard

      Para fluxos de trabalho Standard, só é possível 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, insira Gerenciamento de API.

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

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

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

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

        A captura de tela mostra o portal do Azure, o designer de fluxo de trabalho Standard e a API selecionada a ser chamada.

Adicionar autenticação a solicitações de saída

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

Importante

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

Para obter segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Essa opção fornece segurança superior sem precisar fornecer credenciais. O Azure gerencia esta 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 o acesso e as conexões aos recursos do Azure com identidades gerenciadas nos 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 uma senha e um nome de usuário para fazer uma solicitação. Esse método transmite credenciais sem criptografia e apresenta riscos de segurança maiores, a menos que você use essa opção com o protocolo HTTPS/SSL.

Importante

Para obter segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Essa opção fornece segurança superior sem precisar fornecer credenciais. O Azure gerencia esta 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 o acesso e as conexões aos recursos do Azure com identidades gerenciadas nos Aplicativos Lógicos do Azure.

Se a opção Básica estiver disponível e selecionada, especifique esses valores de propriedade:

Propriedade (designer) Propriedade (JSON) Obrigatório Valor Descrição
Autenticação type Sim Basic O tipo de autenticação a ser usado
Nome de usuário username Sim <nome do usuário> O nome de usuário para autenticar o acesso ao ponto de extremidade de serviço de destino
Senha password Sim <'senha> A senha para autenticar o acesso ao ponto de extremidade de serviço de destino

Quando você usa parâmetros protegidos 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 runtime. Este exemplo de definição de ação HTTP especifica o type da autenticação 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 certificado do cliente

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

Importante

Para obter segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Essa opção fornece segurança superior sem precisar fornecer credenciais. O Azure gerencia esta 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 o acesso e as conexões aos recursos do Azure com identidades gerenciadas nos Aplicativos Lógicos do Azure.

Se a opção Certificado do Cliente estiver disponível e selecionada, especifique esses valores de propriedade:

Propriedade (designer) Propriedade (JSON) Obrigatório Valor Descrição
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.

Observação: os conectores personalizados não dão suporte à autenticação baseada em certificado para chamadas de entrada e de saída.
Pfx pfx Sim <conteúdo de arquivo pfx codificado> O conteúdo codificado na base64 do arquivo PFX (Troca de Informações Pessoais)

Para converter o arquivo PFX no 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 função ToBase64String() e salve esse conteúdo em um arquivo de texto:

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

Solução de problemas: se você usar o cert mmc/PowerShell comando, poderá obter esse 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 voltar novamente usando o comando openssl:

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

Posteriormente, quando você obtém a cadeia de caracteres codificada em base64 para o arquivo PFX recém convertido do certificado, a cadeia de caracteres passa a funcionar nos Aplicativos lógicos do Azure.
Senha password Não <senha para arquivo pfx> A senha para acessar o arquivo PFX

Observação

Se você tentar autenticar com um certificado de cliente usando o OpenSSL, poderá receber o seguinte erro:

BadRequest: Could not load private key

Para resolver esse erro, siga estas etapas:

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

Quando você usa parâmetros protegidos 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 runtime. Este exemplo de definição de ação HTTP especifica o type da autenticação 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 Standard em locatários únicos dos Aplicativos Lógicos do Azure, e quiser usar uma operação HTTP com certificado TSL/SSL, certificado de cliente ou autenticação aberta do Microsoft Entra ID (OAuth do Microsoft Entra ID), com o tipo de credencial Certificate, certifique-se de concluir as etapas de configuração extra para esse tipo de autenticação. Caso contrário, a chamada falhará. Para obter mais informações, consulte a Autenticação no ambiente de locatário único.

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

Plataforma do Microsoft Entra

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

Importante

Para obter segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Essa opção fornece segurança superior sem precisar fornecer credenciais. O Azure gerencia esta 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 o acesso e as conexões aos recursos do Azure com identidades gerenciadas nos Aplicativos Lógicos do Azure.

Em todos os outros gatilhos e ações que dão suporte ao tipo de autenticação OAuth do Active Directory (OAuth 2.0 com o Microsoft Entra ID), especifique esses valores de propriedade:

Propriedade (designer) Propriedade (JSON) Obrigatório Valor Descrição
Autenticação type Sim OAuth do Active Directory (OAuth 2.0 com Microsoft Entra ID)
ou
ActiveDirectoryOAuth		 O tipo de autenticação a ser usado. Os Aplicativos Lógicos do Azure atualmente seguem o protocolo OAuth 2.0.
Autoridade authority Não <URL-for-authority-token-issuer> A URL para a 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, examine Pontos de extremidade de autenticação do Microsoft Entra – Escolher da sua autoridade de identidade.
Locatário tenant Sim <tenant-ID> A ID do locatário do Microsoft Entra
Público-alvo audience Sim <resource-to-authorize> O recurso que você deseja usar para autorização, por exemplo, https://management.core.windows.net/
ID do Cliente clientId Sim <client-ID> A ID do cliente para o aplicativo solicitando a autorização
Tipo de Credencial credentialType Sim Certificado
ou
Segredo		 O tipo de credencial que o cliente usa para solicitar a autorização. Essa propriedade e o valor não aparecem na definição subjacente do aplicativo lógico, mas determinam as propriedades que aparecem para o tipo de credencial selecionado.
Segredo secret Sim, somente para o tipo de credencial "Segredo" <segredo do cliente> O segredo do cliente para solicitar autorização
Pfx pfx Sim, mas somente para o tipo de credencial "Certificado" <conteúdo de arquivo pfx codificado> O conteúdo codificado na base64 do arquivo PFX (Troca de Informações Pessoais)
Senha password Sim, mas somente para o tipo de credencial "Certificado" <senha para arquivo pfx> A senha para acessar o arquivo PFX

Quando você usa parâmetros protegidos 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 runtime. Este exemplo de definição de ação HTTP especifica o type da autenticação 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 Standard em locatários únicos dos Aplicativos Lógicos do Azure e quiser usar uma operação HTTP com certificado TSL/SSL, certificado do cliente ou OAuth do Microsoft Entra ID, com o tipo de credencial Certificate, certifique-se de concluir as etapas de configuração extra para esse tipo de autenticação. Caso contrário, a chamada falhará. Para obter mais informações, consulte a Autenticação no ambiente de locatário único.

Autenticação bruta

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

Importante

Para obter segurança ideal, a Microsoft recomenda o uso do Microsoft Entra ID com identidades gerenciadas para autenticação quando possível. Essa opção fornece segurança superior sem precisar fornecer credenciais. O Azure gerencia esta 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 o acesso e as conexões aos recursos do Azure com identidades gerenciadas nos Aplicativos Lógicos do Azure.

O exemplo a seguir mostra um exemplo de cabeçalho 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 na ação que dá suporte à autenticação bruta, especifique estes valores de propriedade:

Propriedade (designer) Propriedade (JSON) Obrigatório Valor Descrição
Autenticação type Sim Raw O tipo de autenticação a ser usado
Valor value Sim <valor do cabeçalho de autorização> O valor do cabeçalho de autorização a ser usado para autenticação

Quando você usa parâmetros protegidos 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 runtime. Este exemplo de definição de ação HTTP especifica o type da autenticação 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 gerenciada

Quando a opção de identidade gerenciada está disponível no gatilho ou na ação que dá suporte à autenticação de identidade gerenciada, seu aplicativo lógico pode usar essa identidade para autenticar o acesso aos recursos do Azure protegidos pelo Microsoft Entra ID, em vez de credenciais, segredos ou tokens do Microsoft Entra. O Azure gerencia essa identidade para você e ajuda a proteger as suas credenciais, para que você não precise gerenciar segredos nem usar diretamente os tokens do Microsoft Entra. Saiba mais sobre os serviços do Azure que dão suporte a identidades gerenciadas para a 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 Standard dá suporte à identidade gerenciada atribuída pelo sistema e a várias identidades gerenciadas atribuídas pelo usuário habilitadas ao mesmo tempo, ainda que você possa selecionar apenas uma identidade para usar a qualquer momento.

    Observação

    Por padrão, a identidade atribuída pelo sistema já está habilitada para autenticar conexões no 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 no runtime. 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. Essas etapas habilitam a identidade gerenciada em seu aplicativo lógico e configuram o acesso da identidade ao recurso de destino do Azure.

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

  3. No gatilho ou na ação que dá suporte ao uso de uma identidade gerenciada, forneça estas informações:

    Gatilhos e ações internos

    Propriedade (designer) Propriedade (JSON) Obrigatório Valor Descrição
    Autenticação type Sim Identidade Gerenciada
    ou
    ManagedServiceIdentity    		 O tipo de autenticação a ser usado
    Identidade gerenciada identity Não <user-assigned-identity-ID> A ser usado pela identidade gerenciada atribuída pelo usuário. Observação: não inclua essa propriedade ao usar a identidade gerenciada atribuída pelo 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/ cria os tokens de acesso para autenticação válidos em 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 Público pode estar oculta em alguns gatilhos ou ações. Para tornar essa propriedade visível, no gatilho ou na ação, abra a lista Parâmetros avançados e selecione Público.

    Importante: Verifique se a ID do recurso de destino corresponde exatamente ao valor que o Microsoft Entra ID espera, incluindo quaisquer barras invertidas necessárias ao final. Portanto, a ID de recurso https://storage.azure.com/ para todas as contas de armazenamento de BLOBs do Azure requer uma barra à direita. No entanto, a ID de recurso para uma conta de armazenamento específica não requer esse tipo de barra. Para encontrar essas IDs do recurso, confira os Serviços do Azure que dão suporte ao Microsoft Entra ID.

    Quando você usa parâmetros protegidos 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 runtime. Por exemplo, essa definição de ação HTTP especifica o type da autenticação 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": {}
}

    Gatilhos e ações de conector gerenciado

    Propriedade (designer) Obrigatório Valor Descrição
    Nome da conexão Yes <connection-name>
    Identidade gerenciada Yes Identidade gerenciada atribuída pelo sistema
    ou
    <nome-de-identidade-gerenciada-atribuído-ao-usuário>    		 O tipo de autenticação a ser usado

Bloquear a criação de conexões

Se sua organização não permitir a conexão com recursos específicos usando seus conectores em Aplicativos Lógicos do Azure, você poderá bloquear a funcionalidade de criar essas conexões para conectores específicos em fluxos de trabalho de aplicativo lógico usando o Azure Policy. Para mais informações, confira Bloquear conexões criadas por conectores específicos nos Aplicativos Lógicos do Azure.

Diretrizes de isolamento para aplicativos lógicos

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

Conteúdo relacionado