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

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:

• Acesso a operações lógicas de aplicativos
• Acesso a entradas e saídas do histórico de execução
• Acesso a entradas de parâmetros
• Tipos de autenticação para gatilhos e ações que suportam autenticação
• Acesso para chamadas de entrada a acionadores baseados em pedidos
• Acesso a chamadas de saída a outros serviços e sistemas
• Bloquear a criação de conexões para conectores específicos
• Documentação de orientação do isolamento para aplicações lógicas
• Linha de base de segurança do Azure para Aplicativos Lógicos do Azure

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

• Descrição geral da encriptação do Azure
• Encriptação Inativa de Dados do Azure
• Referência da segurança da cloud da Microsoft

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

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

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:

• Restrinja o acesso por intervalo de endereços IP.

  Esta opção ajuda a proteger o acesso ao histórico de execução com base nas solicitações de um intervalo de endereços IP específico.

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

  Em muitos gatilhos e ações, você pode proteger as entradas, saídas ou ambas no histórico de execução de um aplicativo lógico.

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:

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {<workflow-definition>},
            "parameters": {},
            "accessControl": {
               "contents": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     },
                     {
                        "addressRange": "2001:0db8::/64"
                     }
                  ]
               }
            }
         }
      }
   ],
   "outputs": {}
}

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

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:

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.

  

  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.

  

  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.

  

  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.

  

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.

   

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

   

   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.

   

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.

      

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.

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

• Parâmetros seguros em definições de fluxo de trabalho
• Proteja os dados no histórico de execução usando ofuscação

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:

• Passe valores confidenciais na implantação usando o Azure Key Vault
• Parâmetros seguros em modelos do Azure Resource Manager mais adiante neste tópico

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.

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

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:

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

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.

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

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:

• Habilitar o OAuth com o Microsoft Entra ID
• Gerar chaves ou tokens de assinatura de acesso compartilhado (SAS)
• Desativar a autenticação de assinatura de acesso compartilhado (SAS)
• Restringir endereços IP de entrada
• Exponha seu aplicativo lógico com o Gerenciamento de API do Azure

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:

• Um aplicativo de console de daemon do .NET Core chamando uma API da Web protegida com sua própria identidade

• SignedHttpRequest, também conhecido como PoP (Proof of Possession)

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:

"resources": [
   {
      // Start logic app resource definition
      "properties": {
         "state": "<Enabled-or-Disabled>",
         "definition": {<workflow-definition>},
         "parameters": {<workflow-definition-parameter-values>},
         "accessControl": {
            "triggers": {
               "openAuthenticationPolicies": {
                  "policies": {
                     "<policy-name>": {
                        "type": "AAD",
                        "claims": [
                           {
                              "name": "<claim-name>",
                              "value": "<claim-value>"
                           }
                        ]
                     }
                  }
               }
            },
         },
      },
      "name": "[parameters('LogicAppName')]",
      "type": "Microsoft.Logic/workflows",
      "location": "[parameters('LogicAppLocation')]",
      "apiVersion": "2016-06-01",
      "dependsOn": [
      ]
   }
   // End logic app resource definition
],

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:

• Referência de esquema para tipos de gatilho e ação - Gatilho de solicitação
• Referência de esquema para tipos de gatilho e ação - HTTP Webhook trigger
• Referência de esquema para tipos de gatilho e ação - Opções de operação

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:

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:

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:

• Regenerar chaves de acesso
• Criar URLs de retorno de chamada expirando
• Criar URLs com chave primária ou secundária

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.

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:

• Código do Visual Studio com uma extensão do Visual Studio Marketplace
• PowerShell Invoke-RestMethod
• Microsoft Edge - Ferramenta Network Console
• Adriano
• ondulação

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 PATCH, por exemplo:

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

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:

• Sobre a Gestão de API
• Proteger um back-end de API Web no Gerenciamento de API do Azure usando a autorização OAuth 2.0 com a ID do Microsoft Entra
• APIs seguras usando autenticação de certificado de cliente no Gerenciamento de API
• Políticas de autenticação da Gestão de API

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

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               <workflow-definition>
            },
            "parameters": {
            },
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": []
               },
               "actions": {
                  "allowedCallerIpAddresses": []
               },
               // Optional
               "contents": {
                  "allowedCallerIpAddresses": []
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               <workflow-definition>
            },
            "parameters": {
            },
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     }
                  ]
               },
               "actions": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     }
                  ]
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

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:

  • Autenticação básica

  • Autenticação de certificado de cliente

  • Autenticação OAuth do Ative Directory (OAuth 2.0 com ID do Microsoft Entra)

  • Autenticação de identidade gerenciada

• 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:

       

    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.

       

    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.

       

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.

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.

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

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

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

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

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

• Melhorar a segurança das APIs usando a autenticação de certificado de cliente no Gerenciamento de API do Azure
• Melhorar a segurança dos serviços back-end usando a autenticação de certificado de cliente no Gerenciamento de API do Azure
• Melhore a segurança do seu serviço RESTfuL usando certificados de cliente
• Credenciais de certificado para autenticação de aplicativos
• Utilizar um certificado TLS/SSL no código no Serviço de Aplicações do Azure

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.

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:

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

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.

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:

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

• Pode utilizar as Aplicações Lógicas do Azure no Azure Government suportando todos os níveis de impacto nas regiões descritas pelas Orientações de Isolamento de Nível 5 de Impacto do Governo do Azure. Para atender a esses requisitos, os Aplicativos Lógicos do Azure oferecem suporte à capacidade de criar e executar fluxos de trabalho em um ambiente com recursos dedicados para que você possa reduzir o impacto no desempenho de outros locatários do Azure em seus aplicativos lógicos e evitar compartilhar recursos de computação com outros locatários.

• Os fluxos de trabalho de aplicativos lógicos padrão podem se comunicar de forma privada e segura com uma rede virtual do Azure por meio de pontos de extremidade privados que você configura para tráfego de entrada e integração de rede virtual para tráfego de saída. Para obter mais informações, consulte Tráfego seguro entre redes virtuais e Aplicativos Lógicos do Azure de locatário único usando pontos de extremidade privados.

• Para executar seu próprio código ou executar a transformação XML, crie e chame uma função do Azure, em vez de usar o recurso de código embutido ou fornecer assemblies para usar como mapas, respectivamente. Além disso, configure o ambiente de hospedagem para seu aplicativo de função para cumprir com seus requisitos de isolamento.

  Por exemplo, para atender aos requisitos de Nível de Impacto 5, crie seu aplicativo de função com o plano do Serviço de Aplicativo usando a camada de preço Isolado junto com um Ambiente do Serviço de Aplicativo (ASE) que também usa o nível de preço Isolado. Nesse ambiente, os aplicativos de função são executados em máquinas virtuais dedicadas do Azure e redes virtuais dedicadas do Azure, que fornecem isolamento de rede além do isolamento de computação para seus aplicativos e recursos máximos de expansão.

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

  • Planos do Serviço de Aplicativo do Azure
  • Opções de rede das Funções do Azure
  • Anfitriões Dedicados do Azure para máquinas virtuais
  • Isolamento de máquina virtual no Azure
  • Implantar serviços dedicados do Azure em redes virtuais

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

• Isolamento na nuvem pública do Azure
• Segurança para aplicativos IaaS altamente confidenciais no Azure

Conteúdos relacionados

• Linha de base de segurança do Azure para Aplicativos Lógicos do Azure
• Automatize a implantação dos Aplicativos Lógicos do Azure
• Monitorizar aplicações lógicas