Points de terminaison privés Azure pour les zones de préparation internes¶

Vue d’ensemble¶

Les points de terminaison privés Azure et Azure Private Link peuvent être combinés pour fournir une connectivité sécurisée aux zones de préparation internes Snowflake. Cette configuration garantit que les opérations de chargement et de déchargement des données vers des zones de préparation internes Snowflake utilisent le réseau interne Azure et non l’Internet public.

Avant la prise en charge des points de terminaison privés par Microsoft pour accéder aux zones de préparation internes, il était nécessaire de créer une ferme de proxy dans Azure VNet pour faciliter l’accès sécurisé aux zones de préparation internes Snowflake. Avec la prise en charge des points de terminaison privés pour les zones de préparation internes Snowflake, les utilisateurs et les applications client peuvent désormais y accéder par le biais du réseau privé Azure. Le diagramme suivant résume cette nouvelle prise en charge :

Remarques concernant les chiffres dans le diagramme BEFORE :

• Les utilisateurs ont deux options pour se connecter à une zone de préparation interne Snowflake :

  • L’option A permet une connexion sur site directe à la zone de préparation interne, comme illustré par le chiffre 1.

  • L’option B permet une connexion à la zone de préparation interne par le biais d’une ferme de proxy, comme illustré par les chiffres 2 et 3.

• En choisissant une ferme de proxy, les utilisateurs peuvent également se connecter directement à Snowflake comme illustré par le chiffre 4.

Remarques concernant les chiffres dans le diagramme AFTER :

• Pour plus de clarté, le diagramme montre un seul point de terminaison privé d’un VNet Azure pointant vers une seule zone de préparation interne de Snowflake (6 et 7).

  Notez qu’il est possible de configurer plusieurs points de terminaison privés, chacun dans un VNet différent, qui pointent vers la même zone de préparation interne de Snowflake.

• Les mises à jour de cette fonctionnalité suppriment la nécessité de se connecter à Snowflake ou à une zone de préparation interne Snowflake par le biais d’une ferme de proxy.

• Un utilisateur sur site peut se connecter directement à Snowflake comme illustré par le chiffre 5.

• Pour se connecter à une zone de préparation interne Snowflake, l’utilisateur sur site se connecte à un point de terminaison privé, chiffre 6, et utilise ensuite Azure Private Link pour se connecter à la zone de préparation interne Snowflake comme illustré par le chiffre 7.

Dans Azure, chaque compte Snowflake possède un compte de stockage dédié à utiliser comme zone de préparation interne. Les URIs de compte de stockage varient en fonction de si la connexion au compte de stockage utilise une connectivité privée ou non (par exemple Azure Private Link). L’URL de connectivité privée inclut un segment privatelink dans l’URL.

URI de compte de stockage public:

<nom_compte_de_stockage>.blob.core.windows.net

Connectivité privée URI de compte de stockage:

<nom_compte_de_stockage>.privatelink.blob.core.windows.net

Avantages¶

L’implémentation de points de terminaison privés pour accéder aux zones de préparation internes Snowflake apporte les avantages suivants :

• Les données de la zone de préparation interne ne transitent pas par l’Internet public.

• Les applications client et SaaS, par exemple Microsoft PowerBI, exécutées en dehors d’Azure VNet peuvent se connecter à Snowflake de manière sécurisée.

• Les administrateurs n’ont pas besoin de modifier les paramètres de pare-feu pour accéder aux données de la zone de préparation interne.

• Les administrateurs peuvent assurer une sécurité et une surveillance cohérentes concernant la connexion des utilisateurs aux comptes de stockage.

Limitations¶

Microsoft Azure définit la manière dont un point de terminaison privé peut interagir avec Snowflake :

• Un seul point de terminaison privé peut communiquer avec un seul point de terminaison de service Snowflake. Vous pouvez avoir plusieurs configurations une à une qui se connectent à la même zone de préparation interne Snowflake.

• Le nombre maximal de points de terminaison privés de votre compte de stockage qui peuvent se connecter à une zone de préparation interne Snowflake est fixe. Pour des informations détaillées, voir Limites de compte de stockage standards.

Configuration de points de terminaison privés pour accéder à des zones de préparation internes Snowflake¶

Pour configurer des points de terminaison privés pour accéder aux zones de préparation internes Snowflake, il est nécessaire d’être assisté par les trois rôles suivants dans votre organisation :

1. L’administrateur de compte Snowflake (par exemple un utilisateur avec le rôle système ACCOUNTADMIN).

2. L’administrateur Microsoft Azure.

3. L’administrateur réseau.

Selon l’organisation, il peut être nécessaire de coordonner les efforts de configuration avec plus d’une personne ou équipe pour implémenter les étapes de configuration suivantes.

Exécutez les étapes suivantes pour configurer et implémenter l’accès sécurisé aux zones de préparation internes Snowflake par le biais de points de terminaison privés Azure :

1. Vérifiez que votre abonnement Azure est inscrit auprès du gestionnaire de ressources Azure Storage. Cette étape vous permet de vous connecter à la zone de préparation interne à partir d’un point de terminaison privé.

2. En tant qu’administrateur de compte Snowflake, exécutez les instructions suivantes dans votre compte Snowflake et enregistrez le ResourceID du compte de stockage de la zone de préparation interne défini par la clé privatelink_internal_stage. Pour plus d’informations, voir ENABLE_INTERNAL_STAGES_PRIVATELINK et SYSTEM$GET_PRIVATELINK_CONFIG.

   use role accountadmin;
   alter account set ENABLE_INTERNAL_STAGES_PRIVATELINK = true;
   select key, value from table(flatten(input=>parse_json(system$get_privatelink_config())));
   

   Copy

3. En tant qu’administrateur Azure, créez un point de terminaison privé par le biais du portail Azure.

   Visualisez les propriétés du point de terminaison privé et enregistrez la valeur ID de la ressource. Cette valeur sera la valeur privateEndpointResourceID dans l’étape suivante.

   Vérifiez que la valeur Target sub-resource est définie sur blob.

   Pour plus d’informations, voir la documentation Microsoft Azure Private Link.

4. En tant qu’administrateur de Snowflake, appelez la fonction SYSTEM$AUTHORIZE_STAGE_PRIVATELINK_ACCESS en utilisant la valeur privateEndpointResourceID comme argument de fonction. Cette étape autorise l’accès à la zone de préparation interne Snowflake par le biais du point de terminaison privé.

   use role accountadmin;
   select system$authorize_stage_privatelink_access('<privateEndpointResourceID>');
   

   Copy

   Si nécessaire, effectuez ces étapes pour révoquer l’accès à la zone de préparation interne.

5. En tant qu’administrateur réseau, mettez à jour les paramètres DNS pour résoudre les URLs comme suit :

   <nom_compte_de_stockage>.blob.core.windows.net à <nom_compte_de_stockage>.privatelink.blob.core.windows.net

   En cas d’utilisation d’une zone DNS privée dans un VNet Azure, créez l’enregistrement d’alias pour <nom_compte_de_stockage>.privatelink.blob.core.windows.net.

   Pour plus d’informations, consultez Configuration du DNS du point de terminaison privé Azure.

   Astuce

   • Utilisez un compte séparé Snowflake pour les tests et configurez une zone DNS privée dans un VNet de test pour tester la fonctionnalité afin de ne pas perturber les autres charges de travail.

   • Si vous ne pouvez pas utiliser de compte Snowflake séparé, utilisez un utilisateur test pour accéder à Snowflake à partir d’un VPC de test où les modifications DNS sont effectuées.

   • Pour effectuer des tests à partir d’applications sur site, utilisez le transfert de DNS pour rediriger les requêtes vers le DNS privé Azure dans le VNet où les réglages du DNS sont effectués. Exécutez la commande suivante à partir de la machine client pour vérifier que l’adresse IP renvoyée correspond à l’adresse IP privée du compte de stockage :

     dig <storage_account_name>.blob.core.windows.net
     

     Copy

Blocage de l’accès public (facultatif)¶

Une fois que vous avez configuré des points de terminaison privés pour accéder à la zone de préparation interne via Azure Private Link, vous pouvez éventuellement bloquer les requêtes provenant d’adresses IP publiques vers la zone de préparation interne. Une fois l’accès public bloqué, tout le trafic doit passer par le point de terminaison privé.

Le contrôle de l’accès public à une zone de préparation interne Azure est différent du contrôle de l’accès public au service Snowflake. Vous utilisez la fonction SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS et non une politique réseau pour bloquer les requêtes vers la zone de préparation interne. Contrairement aux politiques réseau, cette fonction ne peut pas bloquer certaines adresses IP publiques tout en en autorisant d’autres. Lorsque vous appelez SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS, toutes les adresses IP publiques sont bloquées.

La fonction SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS applique ses restrictions en modifiant les paramètres Networking du compte de stockage Azure où se trouve la zone de préparation interne. Ces paramètres Azure sont communément appelés « paramètres du pare-feu du compte de stockage ». L’exécution de la fonction Snowflake permet d’effectuer les opérations suivantes dans Azure :

• Définition du champ Public network access sur Enabled from selected virtual networks and IP addresses.

• Ajout d’identifiants de sous-réseau VNet Snowflake à la section Virtual Networks.

• Effacement de toutes les adresses IP de la section Firewall.

Pour bloquer tout le trafic des adresses IP publiques vers la zone de préparation interne, exécutez :

SELECT SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS();

L’exécution de la fonction peut prendre quelques minutes.

Révocation de points de terminaison privés pour accéder à des zones de préparation internes Snowflake¶

Effectuez les étapes suivantes pour révoquer l’accès à des zones de préparation internes de Snowflake par le biais de points de terminaison privés Microsoft Azure :

1. En tant qu’administrateur Snowflake, définissez le paramètre ENABLE_INTERNAL_STAGES_PRIVATELINK sur FALSE et appelez la fonction SYSTEM$REVOKE_STAGE_PRIVATELINK_ACCESS pour révoquer l’accès au point de terminaison privé, en utilisant la même valeur privateEndpointResourceID que celle utilisée à l’origine pour autoriser l’accès au point de terminaison privé.

   use role accountadmin;
   alter account set enable_internal_stages_privatelink = false;
   select system$revoke_stage_privatelink_access('<privateEndpointResourceID>');
   

   Copy

2. En tant qu’administrateur Azure, supprimez le point de terminaison privé par le biais du portail Azure.

3. En tant qu’administrateur réseau, supprimez les enregistrements et alias DNS qui ont été utilisés pour résoudre les URLs des comptes de stockage.

À ce stade, l’accès au point de terminaison privé est maintenant révoqué et le résultat de la requête de l’appel de la fonction SYSTEM$GET_PRIVATELINK_CONFIG ne doit pas renvoyer la clé privatelink_internal_stage et sa valeur.

Dépannage¶

Les applications Azure accédant aux zones de préparation Snowflake via l’Internet public et utilisant aussi un service DNS privé pour résoudre les noms d’hôte de service ne peuvent pas accéder aux zones de préparation Snowflake si une connexion de point de terminaison privé est établie avec la zone de préparation, comme décrit dans la présente rubrique.

Dès qu’une connexion de point de terminaison privé est créée, Microsoft Azure crée automatiquement un enregistrement CNAME dans le service DNS public qui dirige l’hôte de compte de stockage vers son équivalent Azure Private Link (par exemple .privatelink.blob.core.windows.net). Si une application a configuré une région DNS privée pour le même domaine, alors Microsoft Azure essaie de résoudre l’hôte de compte de stockage en interrogeant le service DNS privé. Si l’entrée du compte de stockage est introuvable dans le service DNS privé, une erreur de connexion survient.

Il existe deux méthodes pour résoudre ce problème :

1. Supprimez et retirez la région DNS privée de l’application.

2. Créez un enregistrement CNAME pour le nom d’hôte privé du compte de stockage (par exemple <nom_compte_de_stockage>.privatelink.blob.core.windows.net) dans le service DNS privé et dirigez-le vers le nom d’hôte spécifié par la sortie de cette commande :

   dig CNAME <storage_account_name>.privatelink.blob.core.windows.net
   

   Copy