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

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:

• Acesso a operações de aplicativo lógico
• Acesso a entradas e saídas do histórico de execuções
• Acesso a entradas de parâmetro
• Tipos de autenticação para gatilhos e ações que dão suporte à autenticação
• Acesso para chamadas de entrada para gatilhos baseados em solicitação
• Acesso para chamadas de saída para outros serviços e sistemas
• Bloqueio da criação de conexões para conectores específicos
• Diretrizes de isolamento para aplicativos lógicos
• Linha de base de segurança do Azure para Aplicativos lógicos do Azure

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

• Visão geral da criptografia do Azure
• Criptografia de dados em repouso no Azure
• Microsoft Cloud Security Benchmark

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

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

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 pelo intervalo de endereços IP.

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

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

  Em muitos gatilhos e ações, você pode proteger as entradas, as saídas ou ambas no histórico de execuções 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 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:

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

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:

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.

  

  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.

  

  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.

  

  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.

  

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.

   

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

   

   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.

   

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.

      

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.

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

• Proteger parâmetros em definições de fluxo de trabalho
• Proteger dados no histórico de execuções usando ofuscação

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:

• Passar valores confidenciais na implantação usando o Azure Key Vault
• Proteger parâmetros em modelos de Azure Resource Manager mais adiante neste tópico

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.

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

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:

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

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.

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

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 com o Microsoft Entra ID
• Gerar chaves ou tokens SAS (Assinatura de Acesso Compartilhado)
• Desabilitar a autenticação da SAS (Assinatura de Acesso Compartilhado)
• Restringir endereços IP de entrada
• Expor seu aplicativo lógico com o Gerenciamento de API do Azure

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:

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

• SignedHttpRequest, também conhecido como PoP (Prova de Posse)

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:

"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 '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:

• Referência de esquema para tipos de ação e gatilho – gatilho de solicitação
• Referência de esquema para tipos de ação e gatilho – gatilho de HTTP Webhook
• Referência de esquema para tipos de ação e gatilho – opções de operação

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

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:

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

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.

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:

• Visual Studio Code com uma extensão do Visual Studio Marketplace
• Invoke-RestMethod do PowerShell
• Microsoft Edge – ferramenta Console de Rede
• Bruno
• curl

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.

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:

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

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

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

  • Autenticação Básica

  • Autenticação de certificado de cliente

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

  • Autenticação de identidade gerenciada

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

       

    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.

       

    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.

       

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.

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.

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

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

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

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

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

• Melhorar a segurança para APIs usando a autenticação de certificado de cliente no Gerenciamento de API do Azure
• Melhorar a segurança para serviços de back-end usando a autenticação de certificado de cliente no Gerenciamento de API do Azure
• Melhorar a segurança de seu serviço RESTfuL usando certificados de cliente
• Credenciais de certificado para autenticação de aplicativo
• Usar um certificado TLS/SSL no seu código no Serviço de Aplicativo do Azure

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.

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:

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

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.

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:

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

• Você pode usar os Aplicativos lógicos do Azure no Azure Governamental, dando suporte a todos os níveis de impacto nas regiões descritas pelas Diretrizes de isolamento nível 5 de impacto do Azure Governamental. Para atender a esses requisitos, os Aplicativos Lógicos do Azure dão 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.

• Com aplicativos lógicos Padrão, você pode se comunicar de forma privada e segura entre os fluxos de trabalho do aplicativo lógico e uma rede virtual do Azure, configurando pontos de extremidade privados para o tráfego de entrada, e usar a integração de rede virtual para o tráfego de saída. Para obter mais informações, consulte o 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 do seu aplicativo de funções de forma que atenda aos seus requisitos de isolamento.

  Por exemplo, para atender aos requisitos de impacto nível 5, crie seu aplicativo de funções com o plano do serviço de aplicativo usando o tipo de preço isolado junto com um ASE (ambiente do serviço de aplicativo) que também usa o tipo de preço isolado. Nesse ambiente, os aplicativos de funções são executados em máquinas virtuais do Azure dedicadas e em redes virtuais do Azure, que fornecem isolamento de rede sobre o isolamento de computação para seus aplicativos e capacidade máxima de expansão.

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

  • Planos do Serviço de Aplicativo do Azure
  • Opções de rede do Azure Functions
  • Hosts 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, confira a seguinte documentação:

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

Conteúdo relacionado

• Linha de base de segurança do Azure para Aplicativos lógicos do Azure
• Automatizar a implantação para Aplicativos Lógicos do Azure
• Monitorar aplicativos lógicos