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

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 il controllo di sicurezza e accesso in Azure Data Factory e nelle pipeline di Analitica Synapse.

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

Il problema è in genere causato da 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 tratta 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 le impostazioni di proxy, firewall e 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:

  • Porte e firewall del runtime di integrazione self-hosted
  • Connettore di Azure Data Lake Storage

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

  • Gli indirizzi IP del runtime di integrazione di Azure non sono inclusi nell'elenco elementi consentiti .
  • La funzionalità Consenti all'servizi Microsoft attendibile di accedere a questo account di archiviazione è disattivata per Archiviazione BLOB di Azure e Azure Data Lake Storage Gen 2.
  • L'impostazione Consenti l'accesso ai servizi di Azure non è abilitata per Azure Data Lake Storage Gen1.

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

Il punto finale privato eliminato o rifiutato visualizza ancora 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 valido o vuoto 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

Il problema è probabilmente causato da un problema di risoluzione DNS (Domain Name System), perché la disabilitazione della connettività pubblica e la definizione di un endpoint privato impedisce 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 (VM) 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'indirizzo IP deve essere nel formato seguente: xxx.xxx.xxx.0

Risoluzione

Per risolvere il problema, eseguire le operazioni seguenti:

• Come opzione, è consigliabile aggiungere manualmente un collegamento "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 privata 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 privata 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\etce 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.

     

  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 e il problema deve essere risolto.

Non è possibile registrare la chiave di autenticazione del runtime di integrazione nelle macchine virtuali self-hosted a causa del collegamento privato

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 del tempo è: 0.1250079 secondo, il codice di errore è: InvalidGatewayKey, activityId è: XXXXXXX e il messaggio di errore dettagliato è che l'indirizzo IP client non è valido. Data factory non è in grado di accedere alla rete pubblica in modo da non riuscire a connettersi correttamente".

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 il codice di risposta: 200 . Anche la proprietà incollata deve essere visualizzata nella definizione JSON.

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

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:

Azure Data Factory

Synapse Analytics

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 creando un potenziale conflitto nel DNS privato del cliente con uno scenario in cui i record di Azure Resource Manager non vengono trovati.

Risoluzione

1. Trovare DNS privato zone privatelink.azure.com in portale di Azure.
2. Controllare se è presente un record A.
3. Passare a Collegamenti di rete virtuale, eliminare tutti i record.
4. Passare al servizio in portale di Azure e ricreare l'endpoint privato per il portale.
5. Tornare alle zone di DNS privato e verificare se è presente una nuova zona DNS privata privatelink.adf.azure.com.

Errore di connessione nell'endpoint pubblico

Sintomi

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

Ad esempio: il sink Archiviazione BLOB di Azure usava il runtime di integrazione di Azure (pubblico, non la rete virtuale gestita) e l'origine 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 per Archiviazione BLOB di Azure nella rete virtuale gestita non è affidabile in base al risultato del test e Archiviazione BLOB di Azure e Azure Data Lake Gen2 non sono supportati per essere connessi tramite endpoint pubblico dal servizio gestito Rete virtuale secondo Rete virtuale gestita e endpoint privati gestiti.

Risoluzione

• Se l'endpoint privato è 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 al runtime di integrazione pubblico solo 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 può 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 della chiave gestita, è 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, questo errore si verifica perché il servizio non riesce più a leggere gli oggetti necessari e non sarà più in grado di convalidare se l'eliminazione è 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, è necessario essere in grado di eliminare il servizio.

• Il cliente ha eliminato Key Vault/CMK prima di eliminare il servizio. La chiave cmk nel servizio deve avere "Eliminazione temporanea" abilitata e "Ripulisci protezione" abilitata con i criteri di conservazione predefiniti di 90 giorni. È possibile ripristinare la chiave eliminata.
  Rivedere Recuperare la chiave eliminata e il 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 nulla per le chiamate API REST con l'autenticazione di Azure, il modo più semplice per eseguire questa operazione consiste nell'usare Fiddler. Seguire questa procedura.

  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 solo per essere sicuri che sia più sicuro usare un nome diverso da quello nella risposta GET)

  3. Modificare la proprietà encryption.identity e identity.userassignedidentities in modo che punti 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 involontaria 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:

• collegamento privato per Data Factory
• Blog di Data Factory
• Richieste di funzionalità di Data Factory
• Video di Azure
• Pagina Microsoft Q&A
• Forum Stack Overflow per Data Factory
• Informazioni su X su Data Factory