Partilhar via

Autenticar ligações de workflow a recursos Azure protegidos usando identidades geridas no Azure Logic Apps

Aplica-se a: Azure Logic Apps (Consumption + Standard)

Configura uma identidade gerida quando quiser autenticar ligações de workflows do Logic App para recursos do Azure protegidos pela Microsoft Entra. Esta identidade acede a recursos protegidos em nome da sua aplicação lógica e elimina a necessidade de armazenar e gerir credenciais, segredos ou tokens de acesso. Devido a este comportamento, recomenda-se uma identidade gerida para autenticação. O Azure gere esta identidade para ajudar a manter os seus dados de autenticação seguros.

No Azure Logic Apps, muitos conectores suportam ambos os tipos de identidade geridos:

  • Identidade atribuída ao sistema
  • Identidade atribuída pelo utilizador

Este guia mostra como concluir as seguintes tarefas:

  • Configura a identidade atribuída ao sistema no recurso da tua aplicação lógica.
  • Crie e configure uma identidade atribuída pelo utilizador no recurso da sua aplicação lógica.

Este guia fornece passos para o portal Azure e o modelo Azure Resource Manager (modelo ARM). Para Azure PowerShell, Azure CLI e Azure REST API, veja:

Ferramenta Documentação
Azure PowerShell - Atribuído pelo sistema
- Atribuído pelo utilizador
Azure CLI - Atribuído pelo sistema
- Atribuído pelo utilizador
API REST do Azure - Atribuído pelo sistema
- Atribuído pelo utilizador

Para obter mais informações, consulte:

Prerequisites

Considerações para a utilização de identidades geridas

Antes de configurar e usar uma identidade gerida com uma aplicação lógica, reveja as seguintes considerações:

  • O recurso da tua aplicação lógica tem apenas uma identidade única atribuída pelo sistema.

    Por defeito, as aplicações de lógica padrão ativam automaticamente a identidade atribuída pelo sistema.

  • O recurso da tua app lógica pode ter a identidade atribuída pelo sistema e uma ou mais identidades atribuídas pelo utilizador ativadas ao mesmo tempo.

    • A tua aplicação lógica pode usar a identidade atribuída pelo sistema ou uma atribuída pelo utilizador, mas não ambas ao mesmo tempo.

    • A sua aplicação de lógica só pode usar uma identidade atribuída pelo utilizador de cada vez.

  • O recurso da tua aplicação lógica pode partilhar a mesma identidade atribuída pelo utilizador entre outros recursos da aplicação lógica.

  • Podes usar uma identidade gerida ao nível do recurso da aplicação lógica e ao nível da ligação.

  • Para aplicações de lógica padrão, a opção de implementação híbrida não suporta autenticação de identidade gerida. Em vez disso, precisa de criar e usar um registo de aplicações.

Para obter mais informações, consulte:

Conectores que suportam identidades geridas

Para que operações de conectores incorporadas e geridas no Azure Logic Apps suportem autenticação de identidade gerida, devem suportar OAuth com Microsoft Entra.

As tabelas seguintes mostram conectores de exemplo que suportam autenticação de identidade gerida, com base no tipo de aplicação lógica.

Tipo de conector Conectores suportados
Integrado - Gerenciamento de API do Azure
- Serviços de Aplicativo do Azure
- Azure Functions
- HTTP
- HTTP + Webhook

Nota: As operações HTTP podem autenticar ligações a contas Azure Storage atrás de firewalls Azure usando a identidade atribuída ao sistema. No entanto, as operações HTTP não suportam a identidade atribuída pelo usuário para autenticar as mesmas conexões.
Gerido - Serviço de Aplicativo do Azure
- Automação Azure
- Armazenamento de Blobs do Azure
- Instância de contêiner do Azure
- Azure Cosmos DB
- Azure Data Explorer
- Azure Data Factory
- Azure Data Lake
- Gêmeos Digitais do Azure
- Azure Event Grid
- Hubs de Eventos do Azure
- Azure IoT Central V2
- Cofre de Chaves do Azure
-Azure Monitor Logs
- Filas do Azure
- Azure Resource Manager
- Barramento de Serviço do Azure
- Microsoft Sentinel
- Armazenamento de Tabelas do Azure
- VM do Azure
- SQL Server

Para uma lista mais completa, veja:

Ativar identidade atribuída ao sistema (portal)

Com base no tipo da sua aplicação lógica, siga os passos correspondentes para o portal Azure:

Num recurso de aplicação lógica de consumo, ative manualmente a identidade atribuída pelo sistema.

  1. No portal do Azure, abra o recurso da aplicação lógica de Consumo.

  2. Na barra lateral da app Logic, em Definições, seleciona Identidade.

  3. Na página de Identidade, em Atribuído pelo sistema, selecione Ligado e depois selecione Guardar. Para confirmar, selecione Sim.

    Captura de ecrã que mostra o portal do Azure, a aplicação lógica de consumo, a página de identidade e o separador atribuído pelo sistema com opções selecionadas, Ativo e Guardar.

    Seu recurso de aplicativo lógico agora pode usar a identidade atribuída ao sistema. Essa identidade é registrada com a ID do Microsoft Entra e é representada por uma ID de objeto.

    A captura de ecrã mostra a página de identidade da aplicação lógica de consumo e o identificador do objeto para a identidade atribuída pelo sistema.

    Propriedade Valor Descrição
    ID do objeto (principal) < identidade-recurso-ID> Um GUID (Identificador Global Exclusivo) que representa a identidade atribuída pelo sistema para seu aplicativo lógico em um locatário do Microsoft Entra.

  4. Dar à identidade acesso ao recurso protegido

Ativar identidade atribuída ao sistema (modelo ARM)

Para automatizar a criação e implementação de recursos de aplicações lógicas, use um modelo ARM.

No seu modelo, ao nível raiz, a definição de recurso da sua aplicação lógica requer um identity objeto com a type propriedade definida em SystemAssigned, por exemplo:

{
   "apiVersion": "2016-06-01",
   "type": "Microsoft.logic/workflows",
   "name": "[variables('logicappName')]",
   "location": "[resourceGroup().location]",
   "identity": {
      "type": "SystemAssigned"
   },
   "properties": {},
   <...>
}

Quando o Azure cria a definição do recurso da sua aplicação lógica, o identity objeto recebe as seguintes principalId propriedades e tenantId características:

"identity": {
   "type": "SystemAssigned",
   "principalId": "<principal-ID>",
   "tenantId": "<Entra-tenant-ID>"
}
Propriedade (JSON) Valor Descrição
principalId < ID principal> O Identificador Globalmente Único (GUID) que a Microsoft Entra utiliza para gerir o objeto principal do serviço para a sua identidade gerida no tenant Microsoft Entra. Este GUID por vezes aparece como um "ID de objeto" ou objectID.
tenantId < Microsoft-Entra-tenant-ID> O GUID (Identificador Globalmente Exclusivo) que representa o inquilino do Microsoft Entra do qual a aplicação lógica é agora membro. Dentro do locatário do Microsoft Entra, o principal de serviço tem o mesmo nome que a instância do Logic App.

Criar identidade atribuída pelo utilizador (portal)

Tens de criar a identidade como um recurso Azure separado antes de poderes ativar a identidade atribuída pelo utilizador numa aplicação de Consumo ou Lógica Standard.

  1. Na caixa de pesquisa do portal Azure , introduza managed identities. Na lista de resultados, selecione Identidades gerenciadas.

    A captura de tela mostra o portal do Azure com a opção selecionada chamada Identidades Gerenciadas.

  2. Na barra de ferramentas da página Identidades Gerenciadas , selecione Criar.

  3. Introduza a informação de identidade gerida, por exemplo:

    A captura de tela mostra a página chamada Create User Assigned Managed Identity, com detalhes de identidade gerenciada.

    Propriedade Obrigatório Valor Descrição
    Subscription Yes < nome-de-subscrição-do-Azure> O nome da subscrição Azure.
    Grupo de recursos Yes < nome-do-grupo-de-recursos-do-Azure> O nome do grupo de recursos do Azure. Crie um novo grupo ou selecione um grupo existente. Este exemplo cria um novo grupo chamado fabrikam-managed-identities-RG.
    Region Yes < Azure-region> A região do Azure onde armazenar informações sobre seu recurso. Este exemplo utiliza West US.
    Name Yes `<identidade-atribuída-ao-utilizador-nome>` O nome a atribuir à identidade atribuída ao utilizador. Este exemplo utiliza Fabrikam-user-assigned-identity.
    Âmbito de Isolamento Não - Nenhum (padrão)
    - Região    		 O âmbito efetivo da identidade gerida.

  4. Quando terminar, selecione Revisão + criação.

    Depois que o Azure valida as informações, o Azure cria sua identidade gerenciada. Agora você pode adicionar a identidade atribuída pelo usuário ao recurso do aplicativo lógico.

Adicionar identidade atribuída pelo utilizador à aplicação Logic (portal)

Depois de criar a identidade atribuída pelo utilizador, adicione essa identidade ao recurso da sua aplicação lógica, seja do tipo Consumo ou Padrão.

  1. No portal do Azure, abra o recurso do aplicativo de Lógica de Consumo.

  2. Na barra lateral da app Logic, em Definições, seleciona Identidade.

  3. Na página Identidade , selecione Usuário atribuído e, em seguida, selecione Adicionar.

    Captura de ecrã que mostra uma aplicação Lógica de Consumo e uma página de Identidade com a opção selecionada para Adicionar.

  4. No painel Adicionar identidade gerenciada atribuída ao usuário , siga estas etapas:

    1. Na lista Selecione uma assinatura , selecione sua assinatura do Azure.

    2. Na lista de identidades geridas, selecione a identidade atribuída ao utilizador que deseja.

      Para filtrar a lista, na caixa de pesquisa de identidades geridas atribuídas pelo utilizador , insira o nome da identidade ou grupo de recursos, por exemplo:

      Captura de ecrã que mostra uma aplicação lógica de consumo e uma identidade selecionada atribuída pelo utilizador.

    3. Quando terminar, selecione Adicionar.

    Seu aplicativo lógico agora está associado à identidade atribuída pelo usuário.

    A captura de ecrã mostra uma aplicação de lógica de consumo com a identidade atribuída pelo utilizador associada.

  5. Conceder acesso da identidade ao recurso protegido.

Criar identidade atribuída pelo utilizador (modelo ARM)

Para automatizar a criação e implementação de recursos de aplicações lógicas, use um modelo ARM. Esses modelos oferecem suporte a identidades atribuídas pelo usuário para autenticação.

Na secção resources do modelo, a definição do recurso da aplicação lógica requer os seguintes itens:

  • Um identity objeto com a type propriedade definida como UserAssigned.
  • Um objeto filho userAssignedIdentities que especifica o recurso e o nome atribuídos pelo utilizador.

O exemplo seguinte mostra uma definição de recurso e fluxo de trabalho de uma aplicação Lógica de Consumo para um pedido HTTP PUT com um objeto não parametrizado identity . A resposta ao PUT pedido e à operação subsequente GET inclui também este identity objeto.

Um recurso de aplicação Lógica de Consumo pode ativar e ter tanto a identidade atribuída pelo sistema como múltiplas identidades atribuídas pelo utilizador definidas.

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {<template-parameters>},
   "resources": [
      {
         "apiVersion": "2016-06-01",
         "type": "Microsoft.logic/workflows",
         "name": "[variables('logicappName')]",
         "location": "[resourceGroup().location]",
         "identity": {
            "type": "UserAssigned",
            "userAssignedIdentities": {
               "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-assigned-identity-name>": {}
            }
         },
         "properties": {
            "definition": {<logic-app-workflow-definition>}
         },
         "parameters": {},
         "dependsOn": []
      },
   ],
   "outputs": {}
}

Se o seu template incluir a definição de recurso da identidade gerida, pode parametrizar o identity objeto. O exemplo seguinte mostra como o userAssignedIdentities objeto filho faz referência a uma userAssignedIdentityName variável que defines na secção do variables teu modelo. Esta variável faz referência ao identificador de recurso para a sua identidade atribuída pelo utilizador.

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {
      "Template_LogicAppName": {
         "type": "string"
      },
      "Template_UserAssignedIdentityName": {
         "type": "securestring"
      }
   },
   "variables": {
      "logicAppName": "[parameters('Template_LogicAppName')]",
      "userAssignedIdentityName": "[parameters('Template_UserAssignedIdentityName')]"
   },
   "resources": [
      {
         "apiVersion": "2016-06-01",
         "type": "Microsoft.logic/workflows",
         "name": "[variables('logicAppName')]",
         "location": "[resourceGroup().location]",
         "identity": {
            "type": "UserAssigned",
            "userAssignedIdentities": {
               "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', variables('userAssignedIdentityName'))]": {}
            }
         },
         "properties": {
            "definition": {<logic-app-workflow-definition>}
         },
         "parameters": {},
         "dependsOn": [
            "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', variables('userAssignedIdentityName'))]"
         ]
      },
      {
         "apiVersion": "2018-11-30",
         "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
         "name": "[parameters('Template_UserAssignedIdentityName')]",
         "location": "[resourceGroup().location]",
         "properties": {}
      }
  ]
}

Quando o modelo cria a definição de recurso da sua aplicação lógica, o objeto identity inclui as seguintes propriedades principalId e clientId.

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<resource-ID>": {
            "principalId": "<principal-ID>",
            "clientId": "<client-ID>"
        }
    }
}
Propriedade (JSON) Valor Descrição
principalId < ID principal> O Identificador Globalmente Único (GUID) que a Microsoft Entra utiliza para administrar o objeto principal de serviço para a sua identidade gerida no tenant Microsoft Entra. Este GUID por vezes aparece como um "ID de objeto" ou objectID. No tenant Microsoft Entra, o principal de serviço tem o mesmo nome que a instância da aplicação lógica.
clientId < ID do cliente> O Identificador Globalmente Único (GUID) que representa a identidade da aplicação lógica e especifica a identidade a usar durante chamadas em tempo de execução.

Para mais informações sobre templates do Azure Resource Manager e identidades geridas para Azure Functions, consulte template ARM - Azure Functions.

Conceder acesso de um recurso a uma identidade

Antes de poderes usar a identidade gerida para autenticação, precisas de conceder à identidade acesso ao recurso Azure protegido. A forma como configura o acesso pode variar consoante o recurso alvo, por exemplo:

Acesso de identidade gerida a recursos de nível superior

Se uma identidade gerida tiver acesso a um recurso na mesma subscrição, a identidade só pode aceder a esse recurso, não a outros recursos na hierarquia pai desse recurso. No designer de workflow, alguns gatilhos e ações exigem que primeiro selecione uma subscrição ou grupo de recursos antes de poder selecionar o recurso alvo. Se a identidade não tiver acesso a esses recursos de nível superior, o designer não mostra o recurso alvo.

Para resolver este problema, dê à identidade acesso a cada recurso superior que primeiro precisa ser selecionado.

Noutros casos, a identidade também precisa de acesso ao recurso onde ativaste a identidade. Por exemplo, suponha que tem uma ação de fluxo de trabalho que atualiza as definições da aplicação na aplicação lógica principal do workflow. Se a ação usar uma identidade gerida para aceder a estas definições, dê à identidade acesso à aplicação lógica pai.

Atribuir acesso baseado em funções a uma identidade gerida (portal)

Para recursos Azure que exigem que atribua um papel à sua identidade gerida, siga estes passos:

  1. No portal Azure, abre o recurso onde a identidade precisa de acesso.

    Este exemplo utiliza uma conta de armazenamento como recurso alvo do Azure.

  2. Na barra lateral de recursos, selecione Controlo de Acesso (IAM).

  3. Na barra de ferramentas de página de controlo de acesso (IAM ), selecione Adicionar>atribuição de funções.

    Nota

    Se não conseguires selecionar Adicionar atribuição de funções, não tens permissões para atribuir funções. Precisas de permissões de administrador do Microsoft Entra para poderes atribuir funções a identidades geridas.

  4. Para atribuir o papel necessário à sua identidade gerida, siga estes passos:

    1. No separador Funções , encontre e selecione o papel incorporado do Microsoft Entra que dá à sua identidade o acesso necessário ao recurso atual, e depois selecione Próximo.

      Este exemplo seleciona a função chamada Storage Blob Data Contributor. Esta função concede acesso de escrita ao conteúdo de blobs num contentor de armazenamento do Azure.

      Para mais informações, consulte Funções que acedem ao conteúdo blob num contentor de armazenamento Azure.

    2. No separador Membros , siga estes passos para selecionar a identidade gerida:

      1. Em Atribuir acesso a, selecione Identidade gerenciada.

      2. Para adicionar membros, selecione + selecione membros.

      3. No painel Selecionar identidades geridas , selecione a sua subscrição Azure.

      4. Com base na sua identidade gerida, selecione o tipo de identidade gerida e depois selecione a sua identidade gerida.

        Tipo de identidade gerida Descrição
        Identidade gerenciada atribuída pelo usuário Visualize e selecione uma identidade gerida atribuída pelo utilizador ativada em qualquer recurso Azure.
        Todas as identidades geridas pelo sistema Visualize e selecione uma identidade gerida atribuída ao sistema ativada em qualquer recurso Azure.
        Aplicativo lógico Visualize e selecione uma identidade gerida ativada apenas nos recursos da aplicação Logic.

      5. Quando terminares de, seleciona Selecionar.

    Para obter mais informações, consulte:

  5. Autentique o seu gatilho ou ação usando a identidade gerida.

Criar uma política de acesso no portal Azure

Para recursos Azure onde pretende criar uma política de acesso para a sua identidade gerida, siga estes passos:

  1. No portal Azure, abre o recurso onde a identidade precisa de acesso.

    Este exemplo usa um cofre de chaves como o recurso do Azure de destino.

  2. Na barra lateral de recursos, selecione Políticas de Acesso.

    Nota

    Se o recurso não tiver a opção de políticas de Acesso , atribui um papel em vez disso.

  3. Na barra de ferramentas da página, selecione Criar para abrir o painel Criar uma política de acesso .

    A captura de ecrã mostra o portal Azure e um exemplo de cofre de chaves com painel aberto chamado Criar uma política de acesso.

  4. No separador Permissões , selecione as permissões que a identidade necessita para aceder ao recurso alvo.

    Por exemplo, para utilizar a identidade com a ação List secrets do conector gerido do Azure Key Vault, a identidade necessita das permissões List. Neste cenário, na coluna Permissões Secretas , selecione Lista.

    A captura de ecrã mostra o separador Permissões com permissões selecionadas para a Lista.

  5. Quando terminar, selecione Avançar.

  6. No separador Principal , selecione a identidade gerida.

    Este exemplo seleciona uma identidade atribuída pelo utilizador.

  7. Pule a etapa opcional de Aplicação, selecione Avançar e conclua a criação da política de acesso.

  8. Autentique o seu gatilho ou ação usando a identidade gerida.

Autenticar o acesso usando a identidade gerida

Esta secção mostra como usar uma identidade gerida para autenticar o acesso a um gatilho ou ação de fluxo de trabalho que suporta autenticação de identidade gerida. O exemplo continua a partir do qual configuras o acesso para uma identidade gerida usando RBAC e uma conta de armazenamento Azure. Embora o teu recurso Azure possa ser diferente, os passos gerais são maioritariamente semelhantes.

Importante

Se você tiver uma função do Azure onde deseja usar a identidade atribuída ao sistema, primeiro habilite a autenticação para o Azure Functions.

Os passos seguintes mostram como usar a identidade gerida utilizando o portal Azure. Para usar a identidade gerida na definição JSON subjacente usando o editor de código, veja Autenticação de identidade gerida.

  1. No portal do Azure, abra o recurso da aplicação lógica de Consumo.

  2. Adiciona o gatilho ou ação que suporta identidades geridas, se ainda não o fizeste.

  3. Na ocorrência de um gatilho ou ação, siga estes passos:

    • Operações integradas

      Estes passos usam a ação HTTP como exemplo.

      1. Na lista de parâmetros avançados , selecione o parâmetro de Autenticação .

        A captura de ecrã mostra um fluxo de trabalho de Consumo com ação HTTP incorporada e uma lista aberta chamada Parâmetros Avançados, com opção selecionada para Autenticação.

        Tanto o parâmetro de Autenticação como a lista de tipos de Autenticação aparecem, por exemplo:

        A captura de ecrã mostra a secção de parâmetros avançados com a propriedade de Autenticação e a lista de tipos de Autenticação.

      2. Na lista de tipos de autenticação , selecione Identidade Gerida.

        Captura de ecrã mostra um fluxo de trabalho com uma ação incorporada, abriu a lista de tipos de autenticação e selecionou a opção para Identidade Gerida.

        A seção Autenticação agora mostra as seguintes opções:

        Parâmetro Descrição
        Identidade gerenciada A identidade gerida que será utilizada.
        Audiência Aparece em gatilhos e ações específicas para que possas definir o ID de recurso para o recurso ou serviço alvo do Azure.

        Por defeito, o parâmetro Audience usa o https://management.azure.com/ ID de recurso, que é o ID de recurso do Azure Resource Manager.

      3. Da lista Identidade Gerida, selecione a identidade pretendida, por exemplo:

        A captura de tela mostra a seção Autenticação com a lista Tipo de Autenticação e a propriedade Audiência.

        Nota

        Por defeito, a identidade gerida atribuída pelo sistema é a opção selecionada, mesmo quando não ativas identidades geridas. No entanto, para usar com sucesso a identidade gerida, deve primeiro ativar essa identidade na sua aplicação lógica. As aplicações de lógica de consumo não ativam automaticamente a identidade do sistema, ao contrário das aplicações de lógica padrão.

      Para obter mais informações, consulte Exemplo: autenticar um gatilho ou uma ação integrada com uma identidade gerida.

    • Operações de ligação geridas

      1. No painel Criar ligação , na lista de Autenticação , selecione Identidade Gerida, por exemplo:

        A captura de tela mostra o fluxo de trabalho de Consumo com a ação do Azure Resource Manager e a opção selecionada para Identidade Gerenciada.

      2. No painel seguinte, para Nome da Ligação, introduza um nome para usar na ligação.

      3. Com base no seu conector, escolha uma das seguintes opções:

        • Autenticação única: esses conectores suportam apenas um tipo de autenticação, que é a identidade gerenciada neste caso.

          Os passos seguintes usam uma ação Azure Resource como exemplo:

          1. Na lista Identidade gerenciada , selecione a identidade gerenciada habilitada no momento.

          2. Selecione Criar novo.

        • Multiautenticação: esses conectores suportam vários tipos de autenticação, mas você pode selecionar e usar apenas um tipo de cada vez.

          Os seguintes passos usam uma ação Azure Blob Storage como exemplo:

          1. Na lista Tipo de autenticação , selecione Identidade gerenciada de aplicativos lógicos.

            A captura de tela mostra o fluxo de trabalho de consumo, a caixa de criação de conexão e a opção selecionada para Identidade gerenciada de aplicativos lógicos.

          2. Selecione Criar novo.

          Para obter mais informações, consulte Exemplo: autenticar gatilho ou ação do conector gerenciado com uma identidade gerenciada.

Exemplo: autenticar gatilho ou ação interna com uma identidade gerenciada

O gatilho ou ação HTTP incorporado pode usar a identidade atribuída pelo sistema que você ativa no recurso dos seus aplicativos lógicos. Em geral, o gatilho ou ação HTTP utiliza as seguintes propriedades para especificar o recurso ou entidade a que pretende aceder:

Propriedade Obrigatório Descrição
Method Yes O método HTTP para a operação que pretende executar
URI Yes O URL do ponto de extremidade para aceder ao recurso ou à entidade de destino do Azure. A sintaxe do URI geralmente inclui a ID do recurso para o recurso ou serviço do Azure de destino.
Headers Não Quaisquer valores de cabeçalho que você precise ou queira incluir na solicitação de saída, como o tipo de conteúdo
Queries Não Quaisquer parâmetros de consulta que você precise ou queira incluir na solicitação. Por exemplo, parâmetros de consulta para uma operação específica ou para a versão da API da operação que você deseja executar.
Authentication Yes O tipo de autenticação a ser usado para autenticar o acesso ao recurso ou serviço de destino do Azure

Como um exemplo específico, suponha que você queira executar a operação de Blob de Instantâneo em um blob na conta de Armazenamento do Azure onde você configurou anteriormente o acesso para sua identidade. No entanto, o conector de Armazenamento de Blob do Azure não oferece atualmente essa operação. Em vez disso, você pode executar essa operação usando a ação HTTP ou outra operação da API REST do Serviço de Blob.

Importante

Para acessar contas de armazenamento do Azure atrás de firewalls usando o conector de Armazenamento de Blob do Azure e identidades gerenciadas, certifique-se de que você também configurou sua conta de armazenamento com a exceção que permite o acesso por serviços confiáveis da Microsoft.

Para executar a operação Snapshot Blob, a ação HTTP especifica as seguintes propriedades:

Propriedade Obrigatório Valor de exemplo Descrição
URI Yes https://<storage-account-name>/<folder-name>/{name} O ID de recurso para um ficheiro Azure Blob Storage no ambiente Azure Global (público), que utiliza esta sintaxe.
Method Yes PUT O método HTTP que a operação Snapshot Blob utiliza.
Headers Para o Armazenamento do Azure x-ms-blob-type = BlockBlob

x-ms-version = 2024-05-05

x-ms-date = formatDateTime(utcNow(),'r')		 Os valores de cabeçalho x-ms-blob-type, x-ms-version, e x-ms-date são necessários para operações de Armazenamento do Azure.

Importante: Nos pedidos de ativação e ação HTTP para o Azure Storage, o cabeçalho requer a propriedade x-ms-version e a versão da API para a operação que deseja realizar. O x-ms-date valor deve ser a data atual. Caso contrário, o fluxo de trabalho falhará devido a um erro 403 FORBIDDEN. Para obter a data atual no formato necessário, você pode usar a expressão no valor de exemplo.

Para mais informações, consulte:

- Cabeçalhos de solicitação - Blob de instantâneo
- Controle de versão para serviços de Armazenamento do Azure
Queries Somente para a operação de Blob de Instantâneo comp = snapshot O nome e o valor do parâmetro de consulta para a operação.

  1. No designer de fluxo de trabalho, adicione qualquer gatilho desejado e adicione a ação HTTP .

    O exemplo seguinte mostra uma ação HTTP de exemplo com todos os valores de propriedade previamente descritos para usar na operação Snapshot Blob:

    A captura de tela mostra o portal do Azure, o fluxo de trabalho de Consumo e a ação HTTP configurada para acessar recursos.

  2. Na ação HTTP , da lista de parâmetros avançados , selecione Autenticação.

    A captura de tela mostra o fluxo de trabalho de consumo com ação HTTP e a lista de parâmetros avançados aberta com a propriedade selecionada chamada Autenticação.

    A secção Autenticação aparece na sua ação HTTP .

  3. Na lista de tipos de autenticação , selecione Identidade Gerida.

    A captura de tela mostra o fluxo de trabalho de consumo, a ação HTTP e a propriedade Tipo de autenticação com a opção selecionada para Identidade gerenciada.

  4. Da lista de Identidade Gerida, selecione entre as opções disponíveis com base no seu cenário.

    • Se você configurar a identidade atribuída ao sistema, selecione Identidade gerenciada atribuída ao sistema.

      A captura de ecrã mostra o fluxo de trabalho de Consumo, a ação HTTP e a propriedade de identidade gerida com a opção selecionada para identidade gerida atribuída ao sistema.

    • Se você configurar a identidade atribuída pelo usuário, selecione essa identidade.

      A captura de ecrã mostra o fluxo de trabalho de consumo, a ação HTTP e a propriedade de identidade gerida com a identidade atribuída pelo utilizador selecionada.

    Este exemplo continua com a identidade gerenciada atribuída ao sistema.

  5. Alguns gatilhos e ações mostram o parâmetro Audience para que possas introduzir o ID de recurso do recurso ou serviço alvo do Azure.

    Por exemplo, para autenticar o acesso a um recurso Key Vault na cloud Azure global, defina o parâmetro Audienceexatamente com o seguinte ID de recurso: https://vault.azure.net

    Caso contrário, por defeito, o parâmetro Audience usa o https://management.azure.com/ ID de recurso, que é o ID de recurso do Azure Resource Manager.

    Importante

    O ID de recurso alvo deve corresponder exatamente ao valor que o ID Microsoft Entra espera. Caso contrário, pode receber um erro 400 de Pedido Mau ou um erro 401 Não Autorizado . Se o ID do recurso incluir barras finais, inclua-as. Se não, não os incluas.

    Por exemplo, o ID de recurso para todas as contas de Armazenamento de Blob do Azure requer uma barra final. No entanto, o ID do recurso para uma conta de armazenamento específica não requer uma barra final. Verifique as IDs de recurso para os serviços do Azure que suportam a ID do Microsoft Entra.

    O exemplo seguinte define o parâmetro Audience como https://storage.azure.com/. Este valor significa que os tokens de acesso para autenticação são válidos para todas as contas de armazenamento. Para uma conta de armazenamento específica, especifique o URL do serviço raiz . https://<your-storage-account>.blob.core.windows.net

    A captura de tela mostra o fluxo de trabalho de consumo e a ação HTTP com a propriedade Audience definida como ID do recurso de destino.

    Para obter mais informações, consulte:

  6. Continua a construir o fluxo de trabalho com base no teu cenário.

Exemplo: Autenticar o acionamento ou execução do conector gerido usando uma identidade gerida

O conector gerido Azure Resource Manager tem uma ação chamada Ler um recurso que pode usar a identidade gerida que você ativa no recurso da sua lógica. Este exemplo mostra como usar a identidade gerenciada atribuída ao sistema com um conector gerenciado.

  1. No designer de fluxo de trabalho, adicione a ação do Azure Resource Manager chamada Ler um recurso.

  2. No painel Criar ligação , na lista de Autenticação , selecione Identidade Gerida e depois selecione Iniciar sessão.

    Nota

    Em alguns conectores, a lista de Tipos de Autenticação mostra em vez disso a Identidade Gerida das Aplicações Lógicas . Se o seu cenário mostrar esta opção, selecione esta opção.

    A captura de tela mostra o fluxo de trabalho de Consumo, a ação do Gerenciador de Recursos do Azure, a lista de Autenticação aberta e a opção selecionada para Identidade Gerenciada.

  3. Introduz um nome para a ligação e selecione a identidade gerida que deseja.

    Se você habilitou a identidade atribuída ao sistema, a lista Identidade gerenciada selecionará automaticamente a identidade gerenciada atribuída ao sistema. Se, em vez disso, você tiver habilitado uma identidade atribuída pelo usuário, a lista selecionará automaticamente a identidade atribuída pelo usuário.

    Neste exemplo, a identidade gerenciada atribuída ao sistema é a única seleção disponível.

    A captura de tela mostra o fluxo de trabalho de Consumo e a ação do Gerenciador de Recursos do Azure com o nome da conexão inserido e a opção selecionada para a identidade gerenciada atribuída pelo sistema.

    Nota

    Se não ativares a identidade gerida quando tentares criar ou alterar a ligação, ou se removeres a identidade gerida enquanto ainda existe uma ligação habilitada pela identidade gerida, recebes um erro que diz que tens de ativar a identidade e conceder acesso ao recurso alvo.

  4. Quando terminar, selecione Criar novo.

    Depois de criar a ligação, o designer pode obter quaisquer valores dinâmicos, conteúdos ou esquemas usando autenticação de identidade gerida.

  5. Continua a construir o fluxo de trabalho com base no teu cenário.

Ligações com identidades geridas nas definições de recursos de aplicações lógicas

Um tipo de ligação autenticada com identidade gerida é um tipo de ligação especial que funciona apenas com uma identidade gerida. No tempo de execução do fluxo de trabalho, a ligação utiliza a identidade gerida ativada no recurso da Logic App. O Azure Logic Apps verifica se alguma operação de conectores geridos no fluxo de trabalho utiliza a identidade gerida e se existem todas as permissões necessárias para usar a identidade gerida para aceder aos recursos alvo correspondentes. Se esta verificação for aprovada com sucesso, o Azure Logic Apps recebe o token Microsoft Entra associado à identidade gerida, usa essa identidade para autenticar o acesso aos recursos Azure de destino e realiza as operações correspondentes no fluxo de trabalho.

Num recurso de aplicação Lógica de Consumo, guarda a configuração da ligação no objeto da parameters definição do recurso. Este objeto contém o objeto $connections que inclui ponteiros para o ID de recurso da ligação, bem como o ID de recurso da identidade gerida quando ativares a identidade atribuída pelo utilizador.

O exemplo seguinte mostra o parameters objeto quando a identidade atribuída pelo sistema é ativada numa aplicação lógica:

"parameters": {
   "$connections": {
      "value": {
         "<action-name>": {
            "connectionId": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>",
            "connectionName": "<connector-name>",
            "connectionProperties": {
               "authentication": {
                  "type": "ManagedServiceIdentity"
               }
            },
            "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/<managed-connector-type>"
         }
      }
   }
}

O exemplo seguinte mostra o parameters objeto quando a identidade gerida atribuída pelo utilizador é ativada numa aplicação lógica:

"parameters": {
   "$connections": {
      "value": {
         "<action-name>": {
            "connectionId": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>",
            "connectionName": "<connector-name>",
            "connectionProperties": {
               "authentication": {
                  "type": "ManagedServiceIdentity",
                  "identity": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/microsoft.managedidentity/userassignedidentities/<managed-identity-name>"
               }
            },
            "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/<managed-connector-type>"
         }
      }
   }
}

Modelo ARM para conexões de API e identidades gerenciadas

Se usar um modelo ARM para automatizar a implementação, e o seu fluxo de trabalho incluir uma ligação API criada por um conector gerido e usar uma identidade gerida, precisa de dar um passo extra.

Num modelo ARM, a definição do recurso do conector subjacente difere consoante o uso de um recurso de aplicação de lógica Consumo ou Padrão e se o conector apresenta opções de autenticação única ou múltipla.

Os exemplos seguintes aplicam-se aos recursos da aplicação Lógica de Consumo. Mostram como a definição de recurso subjacente do conector difere entre um conector de autenticação única e um conector multiautenticação.

Autenticação única

Este exemplo mostra a definição subjacente do recurso de ligação para uma ação de conector que suporta apenas um tipo de autenticação e utiliza uma identidade gerida num fluxo de trabalho de aplicação lógica de consumo. A definição inclui os seguintes atributos:

  • A kind propriedade está definida para V1 um fluxo de trabalho de Consumo.

  • A propriedade parameterValueType está definida como Alternative.

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_<connector-name>_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues": {},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), '<connector-name>')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_<connector-name>_name')]",
        "parameterValueSet": {},
        "parameterValueType": "Alternative"
    }
},

Múltiplos métodos de autenticação

Este exemplo mostra a definição subjacente do recurso de ligação para uma ação de conector que suporta múltiplos tipos de autenticação e utiliza uma identidade gerida num fluxo de trabalho de uma aplicação de lógica de consumo. A definição inclui os seguintes atributos:

  • A propriedade kind está definida para V1 um fluxo de trabalho de Consumo.

  • O parameterValueSet objeto inclui uma name propriedade definida como managedIdentityAuth e uma values propriedade definida como um objeto vazio.

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_<connector-name>_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues": {},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), '<connector-name>')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_<connector-name>_name')]",
        "parameterValueSet": {
            "name": "managedIdentityAuth",
            "values": {}
        }
    }
}

Configurar controlo avançado para autenticação de ligação API

Quando o seu fluxo de trabalho de uma aplicação lógica Standard utiliza uma ligação API que um conector gerido cria, o Azure Logic Apps utiliza duas ligações para comunicar com o recurso de destino, como a sua conta de email ou o cofre de chaves.

O diagrama conceitual mostra a primeira conexão com a autenticação entre o aplicativo lógico e o repositório de tokens, além da segunda conexão entre o repositório de tokens e o recurso de destino.

  • A Conexão #1 está configurada com autenticação para o repositório interno de tokens.

  • A conexão #2 é configurada com autenticação para o recurso de destino.

No entanto, quando um fluxo de trabalho de uma aplicação de lógica de consumo usa uma ligação API, não pode visualizar ou configurar a ligação #1. Se usares um recurso de aplicação de lógica padrão, ganhas mais controlo sobre a tua aplicação de lógica e os fluxos de trabalho. Por defeito, a ligação #1 usa a identidade atribuída pelo sistema.

Se o seu cenário exigir um controlo mais preciso sobre a autenticação das ligações API, altere a autenticação da ligação #1 da identidade atribuída pelo sistema por padrão para uma identidade atribuída pelo utilizador que adicione à sua logic app. Essa autenticação se aplica a cada conexão de API, para que você possa misturar identidades atribuídas ao sistema e ao usuário em diferentes conexões com o mesmo recurso de destino.

No ficheiro connections.json da sua aplicação de lógica Standard, que armazena informação sobre cada ligação à API, cada definição de ligação tem dois authentication objetos, por exemplo:

"keyvault": {
   "api": {
      "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity",
   },
   "connection": {
      "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

  • O primeiro authentication objeto corresponde à ligação #1.

    Este objeto descreve a autenticação usada para comunicar com o armazenamento interno de tokens. No passado, a type propriedade estava sempre definida para ManagedServiceIdentity uma aplicação que se implantava no Azure e não tinha opções configuráveis.

  • O segundo authentication objeto corresponde à ligação #2.

    Este objeto descreve a autenticação usada para comunicar com o recurso alvo e pode variar consoante o tipo de autenticação que seleciona para essa ligação.

Por que alterar a autenticação para o armazenamento de tokens?

Em alguns cenários, pode querer partilhar e usar a mesma ligação API entre múltiplos recursos da aplicação lógica, mas não quer adicionar a identidade atribuída pelo sistema para cada recurso da aplicação lógica à política de acesso do recurso alvo.

Noutros cenários, pode não querer configurar a identidade atribuída ao sistema na sua aplicação lógica. Para usar uma identidade atribuída pelo utilizador, pode alterar a autenticação para uma identidade atribuída pelo utilizador e desativar completamente a identidade atribuída pelo sistema.

Alterar o método de autenticação para o armazenamento de tokens

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

  2. Na barra lateral de recursos, em Workflows, selecione Connections.

  3. No painel Conexões , selecione Exibição JSON.

    Captura de ecrã a mostrar o portal do Azure, recurso de aplicação lógica padrão, painel Ligações com Vista JSON selecionada.

  4. No editor JSON, encontre o objeto managedApiConnections. Este objeto contém as ligações da API em todos os fluxos de trabalho do seu recurso de aplicação lógica.

  5. Encontre a conexão onde você deseja adicionar uma identidade gerenciada atribuída pelo usuário.

    Por exemplo, suponha que seu fluxo de trabalho tenha uma conexão do Cofre da Chave do Azure:

    "keyvault": {
   "api": {
      "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity"
   },
   "connection": {
      "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

  6. Na definição da ligação, siga estes passos:

    1. Encontra o primeiro authentication objeto. Se não existir nenhuma identity propriedade neste authentication objeto, a aplicação lógica utiliza implicitamente a identidade atribuída ao sistema.

    2. Adicione uma identity propriedade usando o exemplo nesta etapa.

    3. Defina o valor da propriedade como o identificador de recurso para a identidade atribuída pelo utilizador.

    "keyvault": {
   "api": {
      "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity",
      // Add "identity" property here
      "identity": "/subscriptions/<Azure-subscription-ID>/resourcegroups/<resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-resource-ID>"
   },
   "connection": {
      "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

  7. No portal do Azure, vá para o recurso de destino e dê acesso à identidade gerenciada atribuída pelo usuário, com base nas necessidades do recurso de destino.

    Por exemplo, para o Cofre de Chaves do Azure, adicione a identidade às políticas de acesso do cofre de chaves. Para o Armazenamento de Blobs do Azure, atribua a função necessária para a identidade à conta de armazenamento.

Desativar identidade gerenciada

Para deixar de usar a identidade gerida para autenticação, siga estes passos:

  1. Remova o acesso da identidade ao recurso alvo.

  2. No recurso da tua aplicação lógica, desativa a identidade atribuída pelo sistema ou remove a identidade atribuída pelo utilizador.

Quando desligas a identidade gerida no recurso da tua aplicação lógica, removes a capacidade dessa identidade de pedir acesso aos recursos Azure onde a identidade tinha acesso.

Nota

Se desativares a identidade atribuída ao sistema, todas as ligações que usam essa identidade nos fluxos de trabalho da app lógica deixam de funcionar em tempo de execução, mesmo que atives imediatamente a identidade novamente.

Este comportamento ocorre porque, ao desativar a identidade, o ID do objeto é excluído. Cada vez que você habilita a identidade, o Azure gera a identidade com uma ID de objeto diferente e exclusiva. Para resolver este problema, recrie as ligações para que usem o ID de objeto atual para a identidade atual atribuída pelo sistema.

Evite desativar ao máximo a identidade atribuída pelo sistema. Para remover o acesso da identidade aos recursos Azure, remova a atribuição de funções da identidade do recurso alvo. Se você excluir seu recurso de aplicativo lógico, o Azure removerá automaticamente a identidade gerenciada da ID do Microsoft Entra.

As secções seguintes mostram como desativar a identidade gerida usando o portal Azure e o modelo Azure Resource Manager (template ARM). Para Azure PowerShell, Azure CLI e Azure REST API, veja:

Ferramenta Documentação
Azure PowerShell 1. Remova a atribuição de função.
2. Exclua a identidade atribuída pelo usuário.
Azure CLI 1. Remova a atribuição de função.
2. Exclua a identidade atribuída pelo usuário.
API REST do Azure 1. Remova a atribuição de função.
2. Exclua a identidade atribuída pelo usuário.

Para obter mais informações, consulte Remover atribuições de função do Azure.

Desabilitar identidade gerenciada no portal do Azure

Para remover o acesso à identidade gerenciada, remova a atribuição de função da identidade do recurso de destino e desabilite a identidade gerenciada.

Remover atribuição de função

As etapas a seguir removem o acesso ao recurso de destino da identidade gerenciada:

  1. No portal do Azure, vá para o recurso do Azure de destino onde você deseja remover o acesso para a identidade gerenciada.

  2. Na barra lateral de recursos de destino, selecione controlo de acesso (IAM). Na barra de ferramentas, selecione Atribuições de função.

  3. Na lista de funções, selecione as identidades gerenciadas que você deseja remover. Na barra de ferramentas, selecione Remover.

    Nota

    Se a opção Remover estiver desativada, é provável que não tenha permissões. Para obter mais informações sobre as permissões que permitem gerenciar funções para recursos, consulte Permissões de função de administrador na ID do Microsoft Entra.

Desabilitar identidade gerenciada no recurso de aplicativo lógico

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

  2. Na barra lateral de recursos da aplicação lógica, em Definições, selecione Identidade e siga os passos para a sua identidade:

    • Selecione Sistema atribuído>Desativar>salvar. Quando o Azure solicitar a confirmação, selecione Sim.

    • Selecione Usuário atribuído e a identidade gerenciada e, em seguida, selecione Remover. Quando o Azure solicitar a confirmação, selecione Sim.

Desabilitar identidade gerenciada em um modelo ARM

Se você criou a identidade gerenciada do aplicativo lógico usando um modelo ARM, defina a identity propriedade filho do type objeto como None.

"identity": {
   "type": "None"
}

Conteúdo relacionado

  • Last updated on