Résoudre les problèmes de sécurité et de contrôle d'accès dans Azure Data Factory et Synapse Analytics

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Cet article présente des méthodes couramment employées pour résoudre les problèmes de sécurité et de contrôle d'accès dans les pipelines Azure Data Factory et Synapse Analytics.

Erreurs et messages courants

Problème de connectivité dans l’activité de copie du magasin de données cloud

Symptômes

Divers messages d’erreur peuvent être renvoyés en cas de problèmes de connectivité dans le magasin de données source ou récepteur.

Cause

Le problème est-il généralement dû à l'un des facteurs suivants ?

• Paramètre de proxy dans le nœud Runtime d’intégration auto-hébergé (IR), si vous utilisez un IR auto-hébergé.

• Paramètre de pare-feu dans le nœud Runtime d’intégration auto-hébergé, si vous utilisez un IR auto-hébergé.

• Paramètre de pare-feu dans le magasin de données cloud.

Résolution

• Pour vous assurer qu’il s’agit d’un problème de connectivité, vérifiez les points suivants :

  • L’erreur est générée à partir des connecteurs source ou récepteur.
  • L’échec se produit au début de l’activité de copie.
  • L’échec est cohérent pour Azure IR ou le runtime d’intégration auto-hébergé avec un nœud, car il peut s’agir d’un échec aléatoire dans un Runtime d’intégration auto-hébergé à plusieurs nœuds si seuls certains nœuds ont le problème.

• Si vous utilisez un runtime d'intégration auto-hébergé, vérifiez vos paramètres de proxy, de pare-feu et réseau, car la connexion au même magasin de données peut être réussie si vous utilisez un Azure IR. Pour résoudre les problèmes de ce scénario, consultez :

  • Ports et pare-feu pour le runtime d’intégration auto-hébergé
  • Connecteur Azure Data Lake Storage

• Si vous utilisez un Azure IR, essayez de désactiver le paramètre de pare-feu du magasin de données. Cette approche peut résoudre les problèmes dans les deux situations suivantes :

  • Les adresses IP Azure IR ne figurent pas dans la liste verte.
  • La fonctionnalité Autoriser les services Microsoft approuvés à accéder à ce compte de stockage est désactivée pour Stockage Blob Azure et Azure Data Lake Storage Gen 2.
  • Le paramètre Autoriser l’accès aux services Azure n’est pas activé pour Azure Data Lake Storage Gen1.

Si aucune des méthodes précédentes ne fonctionne, contactez Microsoft pour obtenir de l’aide.

Le point de terminaison privé supprimé ou rejeté affiche toujours Approuvé dans ADF

Symptômes

Vous avez créé un point de terminaison privé managé à partir d’ADF et obtenu un point de terminaison privé approuvé. Cependant, après avoir supprimé ou rejeté plus tard le point de terminaison privé, le point de terminaison privé managé dans ADF continue d’exister et apparaît avec l’indication « Approuvé ».

Cause

Actuellement, ADF cesse d’extraire l’état du point de terminaison privé après son approbation. Par conséquent, l’état indiqué dans ADF est obsolète.

Résolution

Vous devez supprimer le point de terminaison privé managé dans ADF une fois que les points de terminaison privés existants sont rejetés/supprimés des jeux de données source/de récepteur.

Problème de clé d’authentification vide ou non valide après la désactivation de l’accès au réseau public

Symptômes

Une fois que vous avez désactivé l’accès au réseau public pour le service, le runtime d’intégration auto-hébergé génère l’erreur 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.

Cause

Le problème est probablement dû à une erreur de résolution DNS (Domain Name System), car la désactivation de la connectivité publique et l’établissement d’un point de terminaison privé ne permettent pas la reconnexion.

Pour vérifier si le nom de domaine complet (FQDN) du service est résolu en adresse IP publique, procédez comme suit :

1. Vérifiez que vous avez créé la machine virtuelle Azure dans le même réseau virtuel que le point de terminaison privé du service.

2. Exécutez PsPing et Ping à partir de la machine virtuelle Azure dans le nom de domaine complet du service :

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

   Notes

   Vous devez spécifier un port pour la commande PsPing. Le port 443 est illustré ici, mais n’est pas obligatoire.

3. Vérifiez si les deux commandes correspondent à une adresse IP publique Azure Data Factory basée sur une région spécifiée. L’adresse IP doit respecter le format suivant : xxx.xxx.xxx.0

Résolution

Pour résoudre ce problème, procédez comme suit :

• En option, nous vous proposons d'ajouter manuellement une « liaison de réseau virtuel » sous la « zone DNS de liaison privée » du service. Pour plus d'informations, consultez l'article Azure Private Link. L'instruction consiste à configurer la zone DNS privée ou le serveur DNS privé pour résoudre le nom de domaine complet du service en adresse IP privée.

• Toutefois, si vous ne voulez pas configurer la zone DNS privée ou le serveur DNS privé, essayez la solution temporaire suivante :

  1. Modifiez le fichier hôte dans Windows et mappez l'adresse IP privée (le point de terminaison privé du service) au nom de domaine complet du service.

     Dans la machine virtuelle Azure, accédez à C:\Windows\System32\drivers\etc, puis ouvrez le fichier hôte dans le Bloc-notes. Ajoutez la ligne qui mappe l’adresse IP privée au nom de domaine complet à la fin du fichier, puis enregistrez la modification.

     

  2. Réexécutez les mêmes commandes que dans les étapes de vérification précédentes pour vérifier la réponse, qui doit contenir l’adresse IP privée.

  3. Réinscrivez le runtime d’intégration auto-hébergé et le problème devrait être résolu.

Impossible d’inscrire la clé d’authentification de l’IR sur les machines virtuelles auto-hébergées en raison d’une liaison privée

Symptômes

Vous ne pouvez pas inscrire la clé d’authentification IR sur la machine virtuelle auto-hébergée, car le lien privé est activé. Vous recevez le message d’erreur suivant :

« Échec de l’obtention du jeton de service du service ADF avec la clé *************** et le coût du temps est : 0,1250079 seconde, le code d’erreur est : InvalidGatewayKey, activityId est : XXXXXXX et le message d’erreur détaillé est L’adresse IP du client n’est pas une adresse IP privée valide, car la fabrique de données n’a pas pu accéder au réseau public et ne peut donc pas atteindre le cloud pour établir la connexion. »

Cause

Le problème peut être dû à la machine virtuelle dans laquelle vous tentez d’installer le runtime d’intégration auto-hébergé. Pour vous connecter au cloud, assurez-vous que l’accès au réseau public est activé.

Résolution

Solution 1

Pour résoudre ce problème, procédez comme suit :

1. Accédez à la page Fabriques - Mettre à jour.

2. En haut à droite, sélectionnez le bouton Essayer.

3. Sous Paramètres, renseignez les informations requises.

4. Sous Corps, collez la propriété suivante :

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

5. Sélectionnez Exécuter pour exécuter la fonction.

6. Sous Paramètres, renseignez les informations requises.

7. Sous Corps, collez la propriété suivante :

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

8. Sélectionnez Exécuter pour exécuter la fonction.

9. Vérifiez que Code de réponse : 200 s'affiche. La propriété que vous avez collée doit également s’afficher dans la définition JSON.

10. Ajoutez de nouveau la clé d’authentification IR dans le runtime d’intégration.

Solution 2

Pour résoudre le problème, accédez à Azure Private Link.

Essayez d’activer l’accès au réseau public sur l’interface utilisateur, comme illustré dans la capture d’écran suivante :

La zone DNS privée du service remplace la résolution DNS d’Azure Resource Manager, entraînant une erreur « Introuvable »

Cause

Azure Resource Manager et le service utilisent la même zone privée, ce qui crée un conflit potentiel sur le DNS privé du client avec un scénario dans lequel les enregistrements Azure Resource Manager sont introuvables.

Résolution

1. Recherchez des zones DNS privées privatelink.Azure.com dans le portail Azure.
2. Vérifiez s’il existe un enregistrement A adf.
3. Accédez à Liens de réseau virtuel, puis supprimez tous les enregistrements.
4. Accédez à votre service dans le portail Azure et recréez le point de terminaison privé pour le portail.
5. Revenez à Zones DNS privées et vérifiez s’il existe une nouvelle zone DNS privée privatelink.adf.azure.com.

Erreur de connexion dans un point de terminaison public

Symptômes

Lorsque vous copiez des données avec un accès public au compte de Stockage Blob Azure, les exécutions du pipeline échouent de façon aléatoire avec l’erreur suivante.

Par exemple : le récepteur de Stockage Blob Azure utilisait Azure IR (réseau virtuel public non géré) et, la source Azure SQL Database utilisait le runtime d’intégration de réseau virtuel managé. Ou bien la source ou le récepteur utilisent le runtime d’intégration de réseau virtuel managé uniquement avec un accès public au stockage.

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

Cause

Le service peut toujours utiliser le runtime d'intégration de réseau virtuel managé, mais vous pouvez rencontrer une telle erreur parce que le point de terminaison public pour le Stockage Blob Azure dans un réseau virtuel managé n'est pas fiable compte tenu du résultat du test, et le Stockage Blob Azure et Azure Data Lake Gen2 ne sont pas pris en charge pour être connectés via un point de terminaison public à partir du réseau virtuel managé du service comme expliqué dans Réseau virtuel managé et points de terminaison privés managés.

Résolution

• Le point de terminaison privé étant activé sur la source et également côté récepteur lors de l’utilisation du runtime d’intégration de réseau virtuel managé.
• Si vous souhaitez toujours utiliser le point de terminaison public, vous pouvez basculer vers le runtime d’intégration public uniquement au lieu d’utiliser le runtime d’intégration de réseau virtuel managé pour la source et le récepteur. Même si vous revenez au runtime d'intégration public, le service peut continuer à utiliser le runtime d'intégration de réseau virtuel managé si le runtime d'intégration de réseau virtuel managé est toujours présent.

Erreur interne lors de la tentative de suppression d'une fabrique de données ou d'un espace de travail Synapse avec une clé gérée par le client (CMK) et une identité managée attribuée par l'utilisateur (UA-MI)

Symptômes

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

Cause

Si vous effectuez une opération liée à CMK, vous devez d'abord terminer toutes les opérations du service associées, puis les opérations externes (telles que les identités managées ou les opérations Key Vault). Par exemple, si vous souhaitez supprimer toutes les ressources, vous devez d’abord supprimer l’instance de service, puis supprimer le coffre de clés. Si vous supprimez le coffre de clés en premier, cette erreur se produit car le service ne peut plus lire les objets requis, et il ne peut pas valider si la suppression est possible ou non.

Résolution

Il existe trois moyens possibles de résoudre ce problème. Les voici :

• Vous avez révoqué l'accès du service au coffre de clés dans lequel la clé CMK a été stockée. Vous pouvez réattribuer l'accès avec les autorisations suivantes : Obtenir, Ne pas inclure la clé et Inclure la clé. Ces autorisations sont requises pour activer des clés gérées par le client. Consultez Révoquer l'accès aux clés gérées par le client. Une fois l'autorisation fournie, vous devez pouvoir supprimer le service.

• Le client a supprimé le coffre de clés/CMK avant de supprimer le service. CMK dans le service doit disposer des options « Suppression réversible » et « Protection contre la purge » activées présentant par défaut la stratégie de rétention de 90 jours. Vous pouvez restaurer la clé supprimée.
  Consultez Récupérer une clé supprimée et Valeur de la clé supprimée

• L'identité managée attribuée par l'utilisateur (UA-MI) a été supprimée avant le service. Vous pouvez effectuer une récupération à partir de cette opération à l’aide d’appels d’API REST. Vous pouvez ce faire en utilisant le client http de votre choix dans n’importe quel langage de programmation. Si vous n’avez pas encore configuré d’appels d’API REST avec l’authentification Azure, le plus simple consiste à utiliser Fiddler. Suivez les étapes suivantes.

  1. Effectuez un appel GET à l’aide de la méthode : GET Url comme https://management.azure.com/subscriptions/YourSubscription/resourcegroups/YourResourceGroup/providers/Microsoft.DataFactory/factories/YourFactoryName?api-version=2018-06-01

  2. Vous devez créer une identité managée par l’utilisateur avec un nom différent (le même nom peut fonctionner, mais il est plus sûr d’opter pour un autre nom que celui de la réponse GET)

  3. Modifiez les propriétés encryption.identity et identity.userassignedidentities de manière à ce qu’elles pointent vers l’identité managée nouvellement créée. Supprimez clientId et principalId de l’objet userAssignedIdentity.

  4. Effectuez un appel PUT vers la même URL transmettant le nouveau corps. Il est important que vous transmettiez ce que vous avez obtenu dans la réponse GET et ne modifiiez que l’identité. Dans le cas contraire, ces éléments remplaceront d’autres paramètres.

  5. Lorsque l’appel aboutit, vous pouvez voir les entités à nouveau et retenter la suppression.

Utilisation du runtime d’intégration auto-hébergé

Le partage de l’IR auto-hébergé à partir d’un autre locataire n’est pas pris en charge

Symptômes

Vous pouvez remarquer d'autres fabriques de données (sur différents locataires) lors de la tentative de partage du runtime d'intégration auto-hébergé à partir de l'interface utilisateur, mais vous ne pouvez pas le partager entre les fabriques de données qui se trouvent sur des locataires différents.

Cause

L’IR auto-hébergé ne peut pas être partagé entre plusieurs locataires.

Contenu connexe

Pour plus d’informations sur la résolution des problèmes, essayez les ressources suivantes :

• Private Link pour Data Factory
• Blog Data Factory
• Demandes de fonctionnalités Data Factory
• Vidéos Azure
• Page Microsoft Q&A
• Forum Stack Overflow pour Data Factory
• Informations de X sur Data Factory