Condividi tramite

Risolvere i problemi di sicurezza e controllo di accesso di Azure Data Factory e Synapse Analytics

  • Articolo

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Suggerimento

Provare Data Factory in Microsoft Fabric, una soluzione di analisi all-in-one per le aziende. Microsoft Fabric copre tutto, dallo spostamento dati al data science, all'analisi in tempo reale, alla business intelligence e alla creazione di report. Vedere le informazioni su come iniziare una nuova prova gratuita!

Questo articolo illustra i metodi di risoluzione dei problemi comuni per la sicurezza e il controllo di accesso in Azure Data Factory e nelle pipeline di Synapse Analytics.

Errori comuni e messaggi

Problema di connettività nell'attività di copia dell'archivio dati cloud

Sintomi

È possibile che vengano restituiti vari messaggi di errore quando si verificano problemi di connettività nell'archivio dati di origine o sink.

Causa

Questo problema è in genere dovuto a uno dei fattori seguenti:

  • L'impostazione proxy nel nodo runtime di integrazione self-hosted, se si usa un runtime di integrazione self-hosted.

  • L'impostazione del firewall nel nodo del runtime di integrazione self-hosted, se si usa un runtime di integrazione self-hosted.

  • Impostazione del firewall nell'archivio dati cloud.

Risoluzione

  • Per assicurarsi che si tratti di un problema di connettività, controllare i punti seguenti:

    • L'errore viene generato dai connettori di origine o sink.
    • L'errore si verifica all'inizio dell'attività di copia.
    • L'errore è coerente per Il runtime di integrazione di Azure o il runtime di integrazione self-hosted con un solo nodo, perché potrebbe trattarsi di un errore casuale in un runtime di integrazione self-hosted a più nodi se solo alcuni nodi presentano il problema.

  • Se si usa un runtime di integrazione self-hosted, controllare il proxy, il firewall e le impostazioni di rete, perché la connessione allo stesso archivio dati potrebbe avere esito positivo se si usa un runtime di integrazione di Azure. Per risolvere i problemi di questo scenario, vedere:

  • Se si usa un Azure IR, provare a disabilitare l'impostazione del firewall dell'archivio dati. Questo approccio può risolvere i problemi nelle due situazioni seguenti:

Se nessuno dei metodi precedenti funziona, contattare Microsoft per assistenza.

Il punto finale privato eliminato o rifiutato è visualizzato ancora come Approvato in Azure Data Factory

Sintomi

È stato creato un endpoint privato gestito da Azure Data Factory e si è ottenuto un endpoint privato approvato. Tuttavia, dopo l'eliminazione o il rifiuto dell'endpoint privato in un secondo momento, l'endpoint privato gestito in Azure Data Factory persiste e mostra "Approvato".

Causa

Attualmente, Azure Data Factory smette di eseguire il pull dello stato del punto finale privato dopo l'approvazione. Di conseguenza, lo stato visualizzato in Azure Data Factory non è aggiornato.

Risoluzione

È necessario eliminare il punto finale privato gestito in Azure Data Factory dopo che gli endpoint privati esistenti vengono rifiutati/eliminati dai set di dati di origine/sink.

Problema di chiave di autenticazione non valida o vuota dopo la disabilitazione dell'accesso alla rete pubblica

Sintomi

Dopo aver disabilitato l'accesso alla rete pubblica per il servizio, il runtime di integrazione self-hosted genera gli errori seguenti: The Authentication key is invalid or empty. o 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

Ciò è probabilmente causato da un problema di risoluzione DNS (Domain Name System), perché la disabilitazione della connettività pubblica e la definizione di un endpoint privato impediscono la riconnessione.

Per verificare se il nome di dominio completo (FQDN) del servizio viene risolto nell'indirizzo IP pubblico, eseguire le operazioni seguenti:

  1. Verificare di aver creato la macchina virtuale di Azure nella stessa rete virtuale dell'endpoint privato del servizio.

  2. Eseguire PsPing e Ping dalla macchina virtuale di Azure al nome di dominio completo del servizio:

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

    Nota

    È necessario specificare una porta per il comando PsPing. La porta 443 viene visualizzata qui ma non è obbligatoria.

  3. Verificare se entrambi i comandi vengono risolti in un indirizzo IP pubblico di Azure Data Factory basato su un'area specificata. L'IP deve essere specificato nel formato seguente: xxx.xxx.xxx.0

Risoluzione

Per risolvere il problema, eseguire le operazioni seguenti:

  • Come opzione, è consigliabile aggiungere manualmente un collegamento alla rete virtuale nella "Zona DNS collegamento privato" per il servizio. Per informazioni dettagliate, vedere l'articolo Collegamento privato di Azure. L'istruzione consiste nel configurare la zona DNS privato o il server DNS personalizzato per risolvere il nome di dominio completo del servizio in un indirizzo IP privato.

  • Tuttavia, se non si vuole configurare la zona DNS privato o il server DNS personalizzato, provare la soluzione temporanea seguente:

    1. Modificare il file host in Windows ed eseguire il mapping dell'indirizzo IP privato (endpoint privato del servizio) al nome di dominio completo del servizio.

      Nella macchina virtuale di Azure passare a C:\Windows\System32\drivers\etc e quindi aprire il file host nel Blocco note. Aggiungere la riga che esegue il mapping dell'IP privato al nome di dominio completo alla fine del file e salvare la modifica.

      Screenshot del mapping dell'indirizzo IP privato all'host.

    2. Eseguire nuovamente gli stessi comandi dei passaggi di verifica precedenti per controllare la risposta, che deve contenere l'indirizzo IP privato.

    3. Registrare nuovamente il runtime di integrazione self-hosted per vedere se il problema si risolve.

Sintomi

Non è possibile registrare la chiave di autenticazione del runtime di integrazione nella macchina virtuale self-hosted perché il collegamento privato è abilitato. Viene visualizzato il messaggio di errore seguente:

"Non è stato possibile ottenere il token di servizio dal servizio Azure Data Factory con chiave *************** e il costo in tempo è: 0,1250079 secondi, il codice errore è: InvalidGatewayKey, activityId è: XXXXXXX e il messaggio di errore dettagliato indica che l'indirizzo IP client non è valido. Data Factory non è in grado di accedere alla rete pubblica per effettuare una connessione corretta".

Causa

Il problema potrebbe essere causato dalla macchina virtuale in cui si sta tentando di installare il runtime di integrazione self-hosted. Per connettersi al cloud, assicurarsi che l'accesso alla rete pubblica sia abilitato.

Risoluzione

Soluzione 1

Per risolvere il problema, eseguire le operazioni seguenti:

  1. Passare alla pagina Factory - Aggiorna.

  2. In alto a destra selezionare il pulsante Prova.

  3. In Parametri completare le informazioni necessarie.

  4. In Corpo incollare la proprietà seguente:

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

  5. Selezionare Esegui per eseguire la funzione.

  6. In Parametri completare le informazioni necessarie.

  7. In Corpo incollare la proprietà seguente:

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

  8. Selezionare Esegui per eseguire la funzione.

  9. Verificare che venga visualizzato Codice di risposta: 200. La proprietà incollata dovrebbe essere visualizzata anche nella definizione JSON.

  10. Aggiungere di nuovo la chiave di autenticazione del runtime di integrazione nel runtime stesso.

Soluzione 2

Per risolvere il problema, passare a Collegamento privato di Azure.

Provare ad abilitare l'accesso alla rete pubblica nell'interfaccia utente, come illustrato nello screenshot seguente:

La zona DNS privata del servizio esegue l'override della risoluzione DNS di Azure Resource Manager, causando l'errore "Non trovato"

Causa

Sia Azure Resource Manager che il servizio usano la stessa zona privata, cosa che crea un potenziale conflitto nel DNS privato del cliente in uno scenario in cui i record di Azure Resource Manager non vengono trovati.

Risoluzione

  1. Trovare le zone DNS privato privatelink.azure.com nel portale di Azure. Screenshot della ricerca di zone DNS privato.
  2. Controllare se è presente un record A adf. Screenshot del record A.
  3. Passare a Collegamenti di rete virtuale ed eliminare tutti i record. Screenshot del collegamento di rete virtuale.
  4. Passare al servizio nel portale di Azure e ricreare l'endpoint privato per il portale. Screenshot della ricreazione dell'endpoint privato.
  5. Tornare alle zone DNS privato e verificare se è presente una nuova zona DNS privato privatelink.adf.azure.com. Screenshot del nuovo record DNS.

Errore di connessione nell'endpoint pubblico

Sintomi

Quando si copiano dati con l'accesso pubblico dell'account di Archiviazione BLOB di Azure, le esecuzioni della pipeline hanno casualmente esito negativo con l'errore seguente.

Ad esempio: il sink di Archiviazione BLOB di Azure usava Azure Integration Runtime (rete virtuale pubblica, non gestita) e l'origine del database SQL di Azure usava il runtime di integrazione della rete virtuale gestita. In alternativa, usare il runtime di integrazione di rete virtuale gestita solo con l'accesso pubblico all'archiviazione.

<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

Il servizio potrebbe comunque usare il runtime di integrazione di rete virtuale gestita, ma potrebbe verificarsi un errore simile perché l'endpoint pubblico nell'archiviazione BLOB di Azure nella rete virtuale gestita non è affidabile in base al risultato del test e l'Archiviazione BLOB di Azure e Azure Data Lake Gen2 non sono supportati per essere connessi tramite endpoint pubblico dalla rete virtuale gestita del servizio in base a Rete virtuale gestita ed endpoint privati gestiti.

Risoluzione

  • Verificare che l'endpoint privato sia abilitato nell'origine e anche sul lato sink quando si usa il runtime di integrazione di rete virtuale gestita.
  • Se si vuole comunque usare l'endpoint pubblico, è possibile passare solo al runtime di integrazione pubblico anziché usare il runtime di integrazione di rete virtuale gestita per l'origine e il sink. Anche se si torna al runtime di integrazione pubblico, il servizio potrà comunque usare il runtime di integrazione di rete virtuale gestita se il runtime di integrazione di rete virtuale gestita è ancora presente.

Errore interno durante il tentativo di eliminare una data factory o un'area di lavoro Synapse con chiave gestita dal cliente (CMK) e identità gestita assegnata dall'utente

Sintomi

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

Causa

Se si eseguono operazioni correlate alla chiave gestita dal cliente, è necessario completare prima tutte le operazioni correlate al servizio e quindi le operazioni esterne, ad esempio identità gestite o operazioni di Key Vault. Ad esempio, se si desidera eliminare tutte le risorse, è necessario eliminare prima l'istanza del servizio e quindi eliminare l'insieme di credenziali delle chiavi. Se si elimina prima l'insieme di credenziali delle chiavi, si verifica questo errore perché il servizio non riesce più a leggere gli oggetti necessari e non sarà più in grado di convalidare se l'eliminazione sia possibile o meno.

Risoluzione

Esistono tre modi possibili per risolvere il problema. Questi sono:

  • È stato revocato l'accesso del servizio all'insieme di credenziali delle chiavi in cui è stata archiviata la chiave CMK. È possibile riassegnare l'accesso alle autorizzazioni seguenti: Get, Unwrap Key e Wrap Key. Queste autorizzazioni sono necessarie per abilitare le chiavi gestite dal cliente. Fare riferimento a Concedere l'accesso alle chiavi gestite dal cliente. Dopo aver fornito l'autorizzazione, si dovrebbe poter eliminare il servizio.

  • Il cliente ha eliminato Key Vault/CMK prima di eliminare il servizio. La chiave gestita dal cliente nel servizio deve avere le opzioni "Eliminazione temporanea" e "Protezione da rimozione definitiva" abilitate con i criteri di conservazione predefiniti di 90 giorni. È possibile ripristinare la chiave eliminata.
    Esaminare Ripristinare una chiave eliminata e Valore della chiave eliminata

  • L'identità gestita assegnata dall'utente è stata eliminata prima del servizio. È possibile eseguire il ripristino usando le chiamate API REST. È possibile eseguire questa operazione in un client HTTP di propria scelta in qualsiasi linguaggio di programmazione. Se non è già stato configurato qualcosa per le chiamate API REST con l'autenticazione di Azure, il modo più semplice per eseguire questa operazione consiste nell'usare Fiddler. Attenersi alla procedura seguente.

    1. Effettuare una chiamata GET usando il metodo GET: URL GET come https://management.azure.com/subscriptions/YourSubscription/resourcegroups/YourResourceGroup/providers/Microsoft.DataFactory/factories/YourFactoryName?api-version=2018-06-01

    2. È necessario creare una nuova identità gestita dall'utente con un nome diverso (lo stesso nome potrebbe funzionare, ma è meglio usarne uno diverso da quello nella risposta GET)

    3. Modificare le proprietà encryption.identity e identity.userassignedidentities in modo che puntino all'identità gestita appena creata. Rimuovere clientId e principalId dall'oggetto userAssignedIdentity.

    4. Effettuare una chiamata PUT allo stesso URL passando il nuovo corpo. È importante passare qualsiasi elemento ottenuto nella risposta GET e modificare solo l'identità. In caso contrario, eseguirebbero l'override involontario di altre impostazioni.

    5. Al termine della chiamata, sarà possibile visualizzare nuovamente le entità e riprovare a eliminare.

Condivisione del runtime di integrazione self-hosted

La condivisione di un runtime di integrazione self-hosted da un tenant diverso non è supportata

Sintomi

È possibile notare altre data factory (in tenant diversi) durante il tentativo di condividere il runtime di integrazione self-hosted dall'interfaccia utente, ma non è possibile condividerle tra data factory in tenant diversi.

Causa

Il runtime di integrazione self-hosted non può essere condiviso tra tenant.

Contenuto correlato

Per altre informazioni sulla risoluzione dei problemi, provare le risorse seguenti: