Compartilhar via

Solucionar problemas de segurança e de controle de acesso no Azure Data Factory e no Synapse Analytics

  • Artigo

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Dica

Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange desde movimentação de dados até ciência de dados, análise em tempo real, business intelligence e relatórios. Saiba como iniciar uma avaliação gratuita!

Este artigo explora métodos comuns de solução de problemas de segurança e controle de acesso nos pipelines no Azure Data Factory e no Synapse Analytics.

Erros e mensagens comuns

Problema de conectividade na atividade de cópia do armazenamento de dados de nuvem

Sintomas

Várias mensagens de erro podem ser retornadas quando ocorrem problemas de conectividade no armazenamento de dados de origem ou no coletor.

Causa

O problema geralmente é causado por um dos fatores a seguir:

  • A configuração de proxy no nó do runtime de integração (IR) auto-hospedada, se você estiver usando um IR auto-hospedado.

  • A configuração de firewall no nó IR auto-hospedado, se você estiver usando um IR auto-hospedado.

  • A configuração de firewall no repositório de armazenamento de nuvem.

Resolução

  • Para garantir que esse é um problema de conectividade, verifique os seguintes pontos:

    • O erro é gerado a partir dos conectores de origem ou de coletor.
    • A falha está no início da atividade de cópia.
    • A falha é consistente para Azure IR ou o IR auto-hospedado com um nó, pois pode ser uma falha aleatória em um IR de vários nós hospedados automaticamente se apenas alguns dos nós tiverem o problema.

  • Se você estiver usando um IR auto-hospedado, verifique as configurações de proxy, firewall e rede, pois a conexão com o mesmo armazenamento de dados poderá ter sucesso se você estiver usando um Azure IR. Para solucionar este cenário, consulte:

  • Se você estiver usando uma Azure IR, tente desabilitar a configuração de firewall do armazenamento de dados. Essa abordagem pode resolver os problemas nas duas situações a seguir:

Se nenhum dos métodos anteriores funcionar, contate a Microsoft para obter ajuda.

O ponto de extremidade privado excluído ou rejeitado ainda mostra Aprovado no ADF

Sintomas

Você criou um ponto de extremidade privado gerenciado do ADF e obteve um ponto de extremidade privado aprovado. Mas, depois de excluir ou rejeitar o ponto de extremidade privado posteriormente, o ponto de extremidade privado gerenciado no ADF ainda persiste e mostra "Aprovado".

Causa

Atualmente, o ADF para de efetuar pull do status do ponto de extremidade privado após a aprovação. Portanto, o status mostrado no ADF é obsoleto.

Resolução

Você deve excluir o ponto de extremidade privado gerenciado no ADF depois que os pontos de extremidade privados existentes forem rejeitados/excluídos dos conjuntos de dados de origem/coletor.

Problema de chave de autenticação inválido ou vazio após o acesso à rede pública ser desabilitado

Sintomas

Depois de desabilitar o acesso à rede pública para o serviço, o runtime de integração auto-hospedada gera os seguintes erros: The Authentication key is invalid or empty. ou Cannot connect to the data factory. Please check whether the factory has enabled public network access or the machine is hosted in a approved private endpoint Virtual Network.

Causa

O problema é provavelmente causado por um problema de resolução de DNS (sistema de nomes de domínio), pois desabilitar a conectividade pública e estabelecer um ponto de extremidade privado impede a reconexão.

Para verificar se o FQDN (nome de domínio totalmente qualificado) do serviço é resolvido para o endereço IP público, faça o seguinte:

  1. Confirme que você criou a VM (máquina virtual) do Azure na mesma rede virtual que o ponto de extremidade privada do serviço.

  2. Execute PsPing e ping da VM do Azure para o FQDN do serviço:

    psping.exe <dataFactoryName>.<region>.datafactory.azure.net:443 ping <dataFactoryName>.<region>.datafactory.azure.net

    Observação

    Você deve especificar uma porta para o comando PsPing. A porta 443 é mostrada aqui, mas não é necessária.

  3. Verifique se ambos os comandos são resolvidos para um Azure Data Factory IP público com base em uma região especificada. O IP deve estar no seguinte formato: xxx.xxx.xxx.0

Resolução

Para resolver o problema, faça o seguinte:

  • Como opção, gostaríamos de sugerir que você adicione manualmente um "link de Rede Virtual do Microsoft Azure" nem"zona DNS de link privado" para o serviço. Para obter detalhes, consulte o artigo Link Privado do Azure. A instrução é para configurar a zona DNS privada ou o servidor DNS personalizado para resolver o serviço FQDN para um endereço IP privado.

  • No entanto, se você não quiser configurar a zona DNS privada ou o servidor DNS personalizado, tente a seguinte solução temporária:

    1. Altere o arquivo de host no Windows e mapeie o IP privado (o ponto de extremidade privado do serviço) para o FQDN do serviço.

      Na VM do Azure, vá para C:\Windows\System32\drivers\etc e abra o arquivo de host no bloco de notas. Adicione a linha que mapeia o IP privado ao FQDN no final do arquivo e salve a alteração.

      Screenshot of mapping the private IP to the host.

    2. Execute novamente os mesmos comandos das etapas de verificação anteriores para verificar a resposta, que deve conter o IP privado.

    3. Registre novamente o runtime de integração auto-hospedada, e o problema deve ser resolvido.

Sintomas

Não é possível registrar a chave de autenticação IR na VM auto-hospedada porque o link privado está habilitado. Você vê a seguinte mensagem de erro:

"Falha ao obter o token de serviço do serviço ADF com a chave *************** e o custo de tempo é: 0,1250079 segundo. O código de erro é: InvalidGatewayKey, activityId é: XXXXXXX. Detalhes do erro: o endereço IP do cliente não é um IP privado válido, pois o Data Factory não pôde acessar a rede pública, portanto, não é capaz de acessar a nuvem para fazer a conexão bem-sucedida."

Causa

O problema pode ser causado pela VM na qual você está tentando instalar o IR auto-hospedado. Para se conectar à nuvem, verifique se acesso à rede pública está habilitado.

Resolução

Solução 1

Para resolver o problema, faça o seguinte:

  1. Vá para a página fábricas – atualização.

  2. No canto superior direito, selecione o botão experimentar.

  3. Em parâmetros, conclua as informações necessárias.

  4. Em corpo, cole a seguinte propriedade:

    { "tags": { "publicNetworkAccess":"Enabled" } }

  5. Selecione executar para executar a função.

  6. Em parâmetros, conclua as informações necessárias.

  7. Em corpo, cole a seguinte propriedade:

    { "tags": { "publicNetworkAccess":"Enabled" } }

  8. Selecione executar para executar a função.

  9. Confirme se o código de resposta: 200 é exibido. A propriedade colada também deve ser exibida na definição de JSON.

  10. Adicione a chave de autenticação IR novamente no runtime de integração.

Solução 2

Para resolver o problema, vá para o Link Privado do Azure.

Tente habilitar o acesso à rede pública na interface do usuário, conforme mostrado na seguinte captura de tela:

A zona DNS privada do serviço substitui a resolução de DNS do Azure Resource Manager, causando o erro “Não encontrado”

Causa

O Azure Resource Manager e o serviço estão usando a mesma zona privada, criando um possível conflito no DNS privado do cliente em um cenário em que os registros do Azure Resource Manager não serão encontrados.

Resolução

  1. Localizar DNS privado zonas privatelink.Azure.com em portal do Azure. Screenshot of finding Private DNS zones.
  2. Verificar se existe um adf de registro A. Screenshot of A record.
  3. Vá para links de rede virtual, exclua todos os registros. Screenshot of virtual network link.
  4. Navegue até o serviço no portal do Azure e recrie o ponto de extremidade privado para o portal. Screenshot of recreating private endpoint.
  5. Volte às zonas DNS privado e verifique se há uma nova zona DNS privada privatelink.adf.Azure.com. Screenshot of new DNS record.

Erro de conexão no ponto de extremidade público

Sintomas

Ao copiar dados com acesso público à conta de Armazenamento de Blobs do Azure, as execuções de pipeline aleatoriamente falham com o seguinte erro.

Por exemplo: o coletor de Armazenamento de Blobs do Azure estava usando Azure IR (VNet pública, não gerenciada) e a origem do Banco de Dados SQL do Azure estava usando o IR de VNet gerenciado. Ou origem/coletor, use o IR para VNet Gerenciada somente com acesso público de armazenamento.

<LogProperties><Text>Invoke callback url with req: "ErrorCode=AzureBlobFailedToCreateContainer,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Unable to create Azure Blob container. Endpoint: XXXXXXX/, Container Name: test.,Source=Microsoft.DataTransfer.ClientLibrary,''Type=Microsoft.WindowsAzure.Storage.StorageException,Message=Unable to connect to the remote server,Source=Microsoft.WindowsAzure.Storage,''Type=System.Net.WebException,Message=Unable to connect to the remote server,Source=System,''Type=System.Net.Sockets.SocketException,Message=A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond public ip:443,Source=System,'","Details":null}}</Text></LogProperties>.

Causa

O serviço ainda pode usar o IR da VNet gerenciada, mas você pode encontrar esse erro porque o ponto de extremidade público para o Armazenamento de Blobs do Azure na VNet gerenciada não é confiável com base no resultado do teste, e o Armazenamento de Blobs do Azure e Azure Data Lake Gen2 não têm suporte para serem conectados por meio do ponto de extremidade público da rede virtual gerenciada pelo ADF de acordo com a rede virtual gerenciada & ponto de extremidade privados gerenciados.

Resolução

  • Ter um ponto de extremidade privado habilitado na origem e também o lado do coletor ao usar o IR da VNet gerenciada.
  • Se você ainda quiser usar o ponto de extremidade público, poderá alternar para o IR público somente em vez de usar o IR da VNet gerenciada para a origem e o coletor. Mesmo que você alterne de volta para o IR público, o serviço ainda poderá usar o IR da VNet gerenciada se o IR da VNet gerenciada ainda estiver lá.

Erro interno ao tentar excluir o workspace do Data factory ou Synapse com a CMK (chave gerenciada pelo cliente) e a UA-MI (identidade gerenciada atribuída pelo usuário)

Sintomas

{\"error\":{\"code\":\"InternalError\",\"message\":\"Internal error has occurred.\"}}

Causa

Se você estiver realizando qualquer operação relacionada à CMK, deverá fazer todas as operações relacionadas ao serviço primeiro e, em seguida, as operações externas (como identidades gerenciadas ou operações do Key Vault). Por exemplo, se você quiser excluir todos os recursos, precisará excluir a instância de serviço primeiro e, em seguida, excluir o cofre de chaves. Se você excluir o cofre de chaves primeiro, esse erro ocorrerá, pois o serviço não poderá mais ler os objetos necessários e não poderá validar se a exclusão for possível ou não.

Resolução

Há três maneiras possíveis de solucionar o problema. Elas são as seguintes:

  • Você revogou o acesso do serviço ao cofre de chaves em que a chave CMK foi armazenada. Você pode reatribuir o acesso seguindo as permissões: Get, Unwrap Key e Wrap Key. Essas permissões são obrigatórias para habilitar as chaves gerenciadas pelo cliente. Consulte Revogar o acesso a chaves gerenciadas pelo cliente. Depois que a permissão for fornecida, você deverá ser capaz de excluir o serviço.

  • O cliente excluiu o Key Vault/CMK antes de excluir o serviço. A CMK no serviço deve ter a “Exclusão temporária” habilitada e a “Proteção de limpeza” habilitada, que tem a política de retenção padrão de 90 dias. Você pode restaurar a chave excluída.
    Consulte Recuperar chave excluída e Valor de chave excluída

  • A identidade gerenciada atribuída pelo usuário (UA-MI) foi excluída antes do serviço. Você pode se recuperar disso usando chamadas à API REST ou pode fazer isso em um cliente http de sua escolha em qualquer linguagem de programação. Se você ainda não configurou nada para as chamadas à API REST com a autenticação do Azure, a maneira mais fácil de fazer isso seria usando POSTMAN/Fiddler. Siga as etapas a seguir.

    1. Faça uma chamada GET usando o método: obter URL como https://management.azure.com/subscriptions/YourSubscription/resourcegroups/YourResourceGroup/providers/Microsoft.DataFactory/factories/YourFactoryName?api-version=2018-06-01

    2. Você precisa criar uma nova identidade gerenciada pelo usuário com um nome diferente (o mesmo nome pode funcionar, mas apenas para ter certeza, é mais seguro usar um nome diferente daquele na resposta GET)

    3. Modifique a propriedade encryption.identity e identity.userassignedidentities para apontar para a identidade gerenciada recém-criada. Remova a clientId e a principalId do objeto userAssignedIdentity.

    4. Faça uma chamada PUT para a mesma URL do alocador passando o novo comando. É muito importante que você esteja passando tudo o que obteve na resposta GET e apenas modifique a identidade. Caso contrário, você substituirá outras configurações involuntariamente.

    5. Depois que a chamada for realizada com sucesso, você poderá ver as entidades novamente e tentar excluir novamente.

Compartilhar Runtime de Integração Auto-hospedada

Não há suporte para o compartilhamento de um IR auto-hospedado de um locatário diferente

Sintomas

Você pode detectar outros data factories (em locatários diferentes), enquanto tenta compartilhar o IR auto-hospedado na interface do usuário, mas não pode compartilhá-lo entre os data factories que estão em locatários diferentes.

Causa

O IR auto-hospedado não pode ser compartilhado entre locatários.

Conteúdo relacionado

Para obter mais ajuda com a solução de problemas, experimente os seguintes recursos: