Utilisez les points de terminaison et règles de services réseau virtuels pour Azure Synapse Analytics

S'applique à :Azure Synapse Analytics (pool SQL dédié uniquement)

Les règles de réseau virtuel sont une fonctionnalité de sécurité du pare-feu qui contrôle si le serveur logique de votre pool SQL dédié (anciennement SQL DW) dans Azure Synapse Analytics accepte les communications envoyées depuis certains sous-réseaux dans des réseaux virtuels. Cet article explique pourquoi les règles de réseau virtuel sont parfois la meilleure option pour permettre la communication sécurisée avec votre pool SQL dédié.

Pour créer une règle réseau virtuel, il doit d’abord y avoir un point de terminaison de service réseau virtuel auquel la règle peut se référer.

Créer une règle de réseau virtuel

Si vous souhaitez uniquement créer une règle de réseau virtuel, vous pouvez passer directement aux étapes et explications plus loin dans cet article.

Détails sur les règles du réseau virtuel

Cette section décrit plusieurs détails sur les règles de réseau virtuel.

Une seule région géographique

Chaque point de terminaison de service réseau virtuel s’applique à une seule région Azure. Le point de terminaison ne permet pas à d’autres régions d’accepter les communications provenant du sous-réseau.

Toute règle de réseau virtuel est limitée à la région à laquelle s’applique son point de terminaison sous-jacent.

Au niveau serveur, pas au niveau de la base de données

Chaque règle de réseau virtuel s’applique à l’ensemble de votre serveur, pas seulement à une base de données particulière sur le serveur. En d’autres termes, les règles du réseau virtuel s’appliquent au niveau serveur, et non au niveau de la base de données.

Rôles d’administration de la sécurité

Il y a une séparation des rôles de sécurité dans l’administration des points de terminaison de service de réseau virtuel. Des actions sont requises pour chacun des rôles suivants :

• Administrateur réseau (rôle de contributeur réseau ) : Activez le point de terminaison.
• Administrateur de base de données (rôle de contributeur SQL Server) : Mettez à jour la liste de contrôle d’accès (ACL) pour ajouter le sous-réseau donné au serveur.

Azure RBAC alternative

Les rôles d’administrateur réseau et d’administrateur de base de données offrent plus de capacités que nécessaire pour gérer les règles réseau virtuels. Seule une partie de leurs capacités est nécessaire.

Vous avez la possibilité d’utiliser le contrôle d’accès basé sur les rôles (RBAC) dans Azure pour créer un rôle personnalisé unique qui ne possède que le sous-ensemble de capacités nécessaire. Le rôle personnalisé pourrait être utilisé au lieu d’impliquer soit l’administrateur réseau, soit l’administrateur de base de données. Votre surface d’exposition en matière de sécurité est plus faible si vous ajoutez un utilisateur à un rôle personnalisé que si vous l’ajoutez aux deux autres rôles d’administrateur principaux.

Limitations

Pour les pools SQL dédiés autonomes, la fonctionnalité de règles réseau virtuels présente les limitations suivantes :

• Dans le pare-feu de votre serveur logique, chaque règle réseau virtuel fait référence à un sous-réseau. Tous les sous-réseaux référencés doivent être hébergés dans la même région géographique que le pool SQL dédié.
• Chaque serveur peut avoir jusqu’à 128 entrées ACL pour n’importe quel réseau virtuel.
• Les règles des réseaux virtuels s’appliquent uniquement aux réseaux virtuels Azure Resource Manager et non aux réseaux du modèle de déploiement classique.
• Sur le pare-feu, les plages d’adresses IP s’appliquent aux éléments réseau suivants, mais les règles du réseau virtuel ne s’appliquent pas :
  • Réseau privé virtuel (VPN) site-à-site (S2S)
  • Local via Azure ExpressRoute
• Les deux abonnements doivent être dans le même tenant Microsoft Entra.

Considérations lors de l’utilisation des points de terminaison de service

Lorsque vous utilisez des points de terminaison de service pour un pool SQL dédié, examinez les points suivants :

• L’accès sortant aux IP publiques d’Azure Synapse Analytics est requis. Les groupes de sécurité réseau (NSG) doivent permettre la connectivité aux adresses IP des services. Vous pouvez utiliser la Sql balise de service NSG .

ExpressRoute

Si vous utilisez ExpressRoute depuis vos locaux, pour le peering public ou Microsoft, vous devrez identifier les adresses IP NAT utilisées. Pour le peering public, chaque circuit ExpressRoute utilise par défaut deux adresses IP NAT appliquées au trafic de service Azure lorsque le trafic entre dans la dorsale réseau Microsoft Azure. Pour le peering Microsoft, les adresses IP NAT utilisées sont fournies soit par le client, soit par le fournisseur de services. Pour autoriser l’accès à vos ressources de votre service, vous devez autoriser ces adresses IP publiques dans le paramètre de pare-feu IP de ressource. Pour trouver vos adresses IP de circuits ExpressRoute en peering public, ouvrez un ticket de support auprès d’ExpressRoute via le portail Azure. Pour en savoir plus sur le NAT pour le peering public ExpressRoute et le peering Microsoft, consultez les exigences NAT pour le peering public Azure.

Pour permettre la communication de votre circuit vers Azure Synapse Analytics, vous devez créer des règles de réseau IP pour les adresses IP publiques de votre NAT.

Impact de l’utilisation de points de terminaison de service de réseau virtuel avec stockage Azure

Stockage Azure a implémenté la même fonctionnalité qui vous permet de limiter la connectivité à votre compte Stockage Azure. Si vous utilisez cette fonctionnalité avec un compte stockage Azure utilisé par Azure Synapse Analytics, vous pouvez rencontrer des problèmes.

Les sections suivantes traitent des fonctionnalités affectées d’Azure Synapse Analytics.

Azure Synapse Analytics PolyBase et instruction COPY

PolyBase et l’instruction COPY sont couramment utilisés pour charger des données dans Azure Synapse Analytics à partir de comptes stockage Azure pour une ingestion de données à haut débit. Si le compte stockage Azure depuis lequel vous chargez les données limite l'accès uniquement à un ensemble de sous-réseaux de réseau virtuel, la connectivité lorsque vous utilisez PolyBase et l'instruction COPY vers le compte de stockage sera interrompue. Pour permettre les scénarios d’importation et d’exportation en utilisant COPY et PolyBase, avec Azure Synapse Analytics connecté à stockage Azure sécurisé sur un réseau virtuel, suivez les étapes de cette section.

Prerequisites

• Installez Azure PowerShell. Pour plus d’informations, consultez Installer le module Azure Az PowerShell.
• Si vous avez un compte de stockage à usage général v1 ou un compte Stockage Blob Azure, vous devez d’abord mettre à niveau vers un compte de stockage à usage général v2 en suivant les étapes de Mettre à niveau vers un compte de stockage à usage général v2.
• Vous devez avoir activé Autoriser les services Microsoft approuvés à accéder à ce compte de stockage dans le menu des paramètres des pare-feux et des réseaux virtuels du compte stockage Azure. Activer cette configuration permettra à PolyBase et à l’instruction COPY de se connecter au compte de stockage en utilisant une authentification forte lorsque le trafic réseau reste sur l’infrastructure Azure. Pour plus d’informations, consultez ce guide.

Étapes

1. Si vous avez un pool SQL dédié autonome (anciennement SQL DW), enregistrez votre serveur SQL avec Microsoft Entra ID en utilisant PowerShell :

   Connect-AzAccount
   Select-AzSubscription -SubscriptionId <subscriptionId>
   Set-AzSqlServer -ResourceGroupName your-database-server-resourceGroup -ServerName your-SQL-servername -AssignIdentity
   

   Cette étape n'est pas nécessaire pour les pools SQL dédiés dans un espace de travail Azure Synapse Analytics. L’identité managée affectée par le système (SA-MI) de l’espace de travail est membre du rôle Administrateur Synapse, et dispose donc de privilèges élevés sur les pools SQL dédiés de l’espace de travail.

2. Créez un compte de stockage v2 universel en suivant les étapes décrites dans Créer un compte de stockage.

   • Si vous avez un compte à usage général v1 ou un compte Stockage Blob, vous devez d’abord effectuer une mise à niveau vers v2 en suivant les étapes de la mise à niveau vers un compte de stockage à usage général v2.
   • Pour les problèmes connus avec Azure Data Lake Storage Gen2, voir Problèmes connus avec Azure Data Lake Storage Gen2.

3. Sur la page de votre compte de stockage, sélectionnez Contrôle d’accès (IAM).

4. Sélectionnez Ajouter>Ajouter une attribution de rôle pour ouvrir la page Ajouter une attribution de rôle.

5. Attribuez le rôle suivant. Pour connaître les étapes détaillées, consultez Attribuer des rôles Azure à l’aide du portail Azure.

   Setting	Value
   Role	Contributeur aux données du Blob de stockage
   Attribuer l’accès à	Utilisateur, groupe ou principal de service
   Members	Serveur ou espace de travail hébergeant votre pool SQL dédié que vous avez enregistré auprès de Microsoft Entra ID

   

   Note

   Seuls les membres ayant le privilège de propriétaire sur le compte de stockage peuvent effectuer cette étape. Pour les différents rôles intégrés Azure, voir Azure built-in-roles.

6. Pour permettre la connectivité PolyBase au compte stockage Azure :

   1. Créez une clé principale de base de données si vous n’en avez pas déjà créée une.

      CREATE MASTER KEY [ENCRYPTION BY PASSWORD = '<password>'];
      

   2. Créez des informations d’identification incluses dans l’étendue de la base de données avec IDENTITY = 'Managed Service Identity' .

      CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Service Identity';
      

      • Il est inutile de spécifier SECRET avec la clé d’accès Stockage Azure, car ce mécanisme utilise l’identité managée en arrière-plan. Cette étape n'est pas nécessaire pour les pools SQL dédiés dans un espace de travail Azure Synapse Analytics. L’identité managée affectée par le système (SA-MI) de l’espace de travail est membre du rôle Administrateur Synapse, et dispose donc de privilèges élevés sur les pools SQL dédiés de l’espace de travail.

      • Le nom d’IDENTITY doit être « Managed Service Identity » pour que la connectivité PolyBase entre le compte Stockage Azure et le réseau virtuel fonctionne de manière sécurisée.

   3. Créez une source de données externe avec le protocole abfss:// pour vous connecter à votre compte de stockage v2 à usage général via PolyBase.

      CREATE EXTERNAL DATA SOURCE ext_datasource_with_abfss WITH (TYPE = hadoop, LOCATION = 'abfss://myfile@mystorageaccount.dfs.core.windows.net', CREDENTIAL = msi_cred);
      

      • Si vous avez déjà des tables externes associées à un compte à usage général v1 ou compte Stockage Blob, vous devriez d’abord supprimer ces tables externes. Ensuite, supprimez la source de données externe correspondante. Créez ensuite une source de données externe à l’aide du schéma abfss:// qui se connecte à un compte de stockage GPv2, comme indiqué précédemment. Ensuite, recréez toutes les tables externes en utilisant cette nouvelle source de données externe. Vous pourriez utiliser l’Assistant Générer et Publier des scripts pour générer des scripts de création pour toutes les tables externes plus facilement.
      • Pour plus d’informations concernant le schéma abfss://, consultez Utiliser l’URI d’Azure Data Lake Storage Gen2.
      • Pour plus d’informations sur les commandes T-SQL, voir CREATE EXTERNAL DATA SOURCE.

   4. Interrogez normalement en utilisant des tables externes.

Audit Azure Synapse Analytics vers le stockage Blob

L’audit Azure Synapse Analytics peut écrire des journaux d’audit SQL sur votre propre compte de stockage. Si ce compte de stockage utilise la fonctionnalité de points de terminaison de service de réseau virtuel, voyez comment écrire les journaux d’audit dans un compte de stockage derrière un VNet et un pare-feu.

Ajoutez une règle de pare-feu réseau virtuel au serveur SQL de votre pool SQL dédié

Il y a longtemps, avant que cette fonctionnalité ne soit améliorée, vous deviez activer les points de terminaison de service de réseau virtuel avant de pouvoir implémenter une règle de réseau virtuel dynamique dans le pare-feu. Les points de terminaison relient un sous-réseau réseau virtuel donné à un pool SQL dédié. Depuis janvier 2018, vous pouvez contourner cette exigence en définissant le drapeau IgnoreMissingVNetServiceEndpoint . Désormais, vous pouvez ajouter une règle de pare-feu de réseau virtuel à votre serveur sans activer les points de terminaison de service de réseau virtuel.

Se contenter de définir une règle de pare-feu n’aide pas à sécuriser le serveur. Vous devez également activer les points de terminaison de service de réseau virtuel pour que la sécurité soit appliquée. Lorsque vous activez les points de terminaison de service, votre sous-réseau réseau virtuel subit des interruptions jusqu’à ce qu’il termine la transition de désactivé à activé. Cette période de temps d’arrêt est particulièrement vraie dans le contexte de grands réseaux virtuels. Vous pouvez utiliser le drapeau IgnoreMissingVNetServiceEndpoint pour réduire ou éliminer les temps d’arrêt pendant la transition.

Vous pouvez définir le IgnoreMissingVNetServiceEndpoint flag en utilisant PowerShell. Pour plus d’informations, voir New-AzSqlServerVirtualNetworkRule.

Utilisez le portail Azure pour créer une règle de réseau virtuel

Dans cette section, découvrez comment utiliser le portail Azure pour créer une règle réseau virtuelle pour un pool SQL dédié autonome. La règle dit au serveur logique d’accepter la communication provenant d’un sous-réseau particulier qui a été identifié comme un point de terminaison de service de réseau virtuel.

Prerequisites

Vous devez déjà avoir un sous-réseau tagué avec le nom du type de terminaison de service réseau virtuel utilisé par Azure Synapse Analytics.

• Le nom pertinent du type de point de terminaison est Microsoft.Sql.
• Si votre sous-réseau pourrait ne pas être étiqueté avec le nom du type, voir Vérifier que le point de terminaison du service est activé.

Étapes dans le portail Azure

1. Connectez-vous au portail Azure.

2. Cherchez et sélectionnez des serveurs SQL, puis sélectionnez votre serveur. Sous Sécurité, sélectionnez Mise en réseau.

3. Dans l’onglet Accès public , assurez-vous que l’accès au réseau public est défini sur Sélectionner les réseaux, sinon les paramètres des réseaux virtuels sont masqués. Sélectionnez + Ajouter un réseau virtuel existant dans la section Réseaux virtuels .

4. Dans le nouveau volet Créer/Mettre à jour, remplissez les cases avec les noms de vos ressources Azure.

   Tip

   Vous devez inclure le préfixe d’adresse correct pour votre sous-réseau. Vous pouvez trouver la valeur de Préfixe de l’adresse dans le portail. Aller à toutes les ressources>Tous types>Réseaux virtuels. Le filtre affiche vos réseaux virtuels. Sélectionnez votre réseau virtuel, puis sélectionnez Sous-réseaux. La colonne INTERVALLE d’ADRESSES contient le préfixe d’adresse dont vous avez besoin.

5. Voir la règle du réseau virtuel résultante dans le panneau Pare-feu .

6. Définir Autoriser les services et ressources Azure à accéder à ce serveur sur Non.

   Important

   Si vous ne désélectionnez pas Autoriser les services et ressources Azure à accéder à ce serveur, votre serveur accepte les communications à partir de n’importe quel sous-réseau à l’intérieur de la limite Azure. C'est une communication qui provient d'une des adresses IP reconnues comme étant dans des plages définies pour les centres de données Azure. Du point de vue de la sécurité, le fait de laisser le contrôle activé peut avoir pour effet de multiplier excessivement les accès. La fonctionnalité de point de terminaison de service de réseau virtuel Microsoft Azure, associée aux règles de réseau virtuel Azure Synapse Analytics, peut réduire votre surface d’attaque.

7. Sélectionnez le bouton OK près du bas du volet.

Utilisez PowerShell pour créer une règle réseau virtuel

Un script peut également créer des règles de réseau virtuel en utilisant l’applet de commande PowerShell New-AzSqlServerVirtualNetworkRule ou az network vnet create. Pour plus d’informations, voir New-AzSqlServerVirtualNetworkRule.

Utilisez l’API REST pour créer une règle de réseau virtuel

En interne, les cmdlets PowerShell pour les actions de réseau virtuel Synapse SQL appellent les API REST. Vous pouvez appeler directement les API REST. Pour plus d’informations, voir Règles du réseau virtuel : Opérations.

Résolution des erreurs 40914 et 40615

L’erreur de connexion 40914 concerne les règles réseau virtuel, telles que spécifiées dans le volet Pare-feu du portail Azure.
L’erreur 40615 est similaire, sauf qu’elle concerne les règles d’adresse IP sur le pare-feu.

Erreur 40914

Texte du message : « Impossible d’ouvrir le serveur '[server-name]' demandé par le login. Le client n’est pas autorisé à accéder au serveur. »

Description de l’erreur : Le client se trouve dans un sous-réseau qui possède des points de terminaison de service de réseau virtuel. Mais le serveur n’a pas de règle de réseau virtuel qui accorde au sous-réseau le droit de communiquer avec la base de données.

Résolution des erreurs : Dans le panneau Pare-feu du portail Azure, utilisez le contrôle des règles réseau virtuels pour ajouter une règle réseau virtuel pour le sous-réseau.

Erreur 40615

Texte du message : Impossible d’ouvrir le serveur ’{0}’ demandé par la connexion. Le client avec l’adresse IP "{1}" n’est pas autorisé à accéder au serveur. »

Description de l’erreur : Le client essaie de se connecter depuis une adresse IP qui n’est pas autorisée à se connecter au serveur. Le pare-feu serveur n’a pas de règle d’adresse IP permettant à un client de communiquer depuis l’adresse IP donnée vers la base de données.

Résolution des erreurs : Saisissez l’adresse IP du client comme une règle IP. Utilisez le volet Pare-feu dans le portail Azure pour effectuer cette étape.

Contenu connexe

• Points de terminaison de service de réseau virtuel Azure
• Azure Synapse règles de pare-feu IP
• À utiliser New-AzSqlServerVirtualNetworkRule pour créer une règle de réseau virtuel
• Règles du réseau virtuel : Opérations