Azure Private Link pour Azure SQL Database et Azure Synapse Analytics

S’applique à :Azure SQL DatabaseAzure Synapse Analytics (pools SQL dédiés uniquement)

Liaison privée vous permet de vous connecter à différents services PaaS dans Azure par le biais d’un point de terminaison privé. Pour obtenir la liste des services PaaS prenant en charge la fonctionnalité Liaison privée, accédez à la page Documentation sur Liaison privée. Un point de terminaison privé est une adresse IP privée au sein d’un réseau virtuel et d’un sous-réseau spécifiques.

Important

Cet article s’applique à la fois à Azure SQL Database et au pool SQL dédié (anciennement SQL DW) dans Azure Synapse Analytics. Ces paramètres s’appliquent à toutes les bases de données SQL Database et bases de données de pool SQL dédié (anciennement SQL DW) associées au serveur. Pour simplifier, le terme « base de données » fait référence aux bases de données dans Azure SQL Database et Azure Synapse Analytics. De même, toute référence à un « serveur » fait référence au serveur logique qui héberge Azure SQL Database et le pool SQL dédié (anciennement SQL DW) dans Azure Synapse Analytics. Cet article ne s’applique pas à Azure SQL Managed Instance ni aux pools SQL dédiés dans les espaces de travail Azure Synapse Analytics.

Processus de création

Vous pouvez créer des points de terminaison privés avec le portail Azure, PowerShell ou l’interface Azure CLI :

Processus d’approbation

Une fois que l’administrateur réseau a créé le point de terminaison privé (PE), l’administrateur SQL peut gérer la connexion de point de terminaison privé (PEC) à la base de données.

  1. Accédez à la ressource serveur dans le Portail Azure.

  2. Dans le volet gauche, sélectionnez Réseaux.

  3. Sélectionnez l’onglet Accès privé. La page affiche les éléments suivants :

    • Une liste de toutes les connexions de point de terminaison privé (PEC)
    • Points de terminaison privés (PE) créés

    Screenshot that shows how to locate the list of private endpoint connections for the server resource.

  4. S’il n’existe aucun point de terminaison privé, créez-en un à l’aide du bouton Créer un point de terminaison privé. Autrement, choisissez un PEC individuel dans la liste en le sélectionnant.

    Screenshot that shows how to select a private endpoint connection in the Azure portal.

  5. L’administrateur SQL peut choisir d’approuver ou de rejeter un PEC. Il peut aussi ajouter une brève réponse sous forme de texte.

    Screenshot that shows how to approve a PEC in the Azure portal.

  6. Après approbation ou rejet, la liste reflète l’état approprié et le texte de réponse.

    Screenshot that shows the PEC in the Approved state after approval by the admin.

  7. Enfin, sélectionnez le nom du point de terminaison privé

    Screenshot showing PEC details with the endpoint name.

    Vous accédez à la page de présentation du point de terminaison privé. Sélectionnez le lien Interfaces réseau pour obtenir les détails de l’interface réseau pour la connexion du point de terminaison privé.

    Screenshot that shows the NIC details for the private endpoint connection.

    La page Interface réseau affiche l’adresse IP privée pour la connexion du point de terminaison privé.

    Screenshot that shows the Private IP address for the private endpoint connection.

Important

Lorsque vous ajoutez une connexion de point de terminaison privé, le routage public vers votre serveur logique n’est pas bloqué par défaut. Dans le volet Pare-feu et réseaux virtuels, le paramètre Refuser l’accès au réseau public n’est pas sélectionné par défaut. Pour désactiver l’accès au réseau public, veillez à sélectionner Refuser l’accès au réseau public.

Désactiver l’accès public à votre serveur logique

Pour ce scénario, supposons que vous souhaitez désactiver tout accès public à votre serveur logique et autoriser uniquement les connexions à partir de votre réseau virtuel.

Tous d’abord, veillez à ce que vos connexions de point de terminaison privé soient activées et configurées. Ensuite, pour désactiver l’accès public à votre serveur logique :

  1. Accédez à la page Mise en réseau de votre serveur logique.

  2. Cochez la case Refuser l’accès au réseau public.

    Screenshot that shows how to disable public network access for the private endpoint connection.

Tester la connectivité à SQL Database à partir d’une machine virtuelle Azure dans le même réseau virtuel

Pour ce scénario, supposons que vous avez créé une machine virtuelle Azure exécutant une version récente de Windows dans le même réseau virtuel que le point de terminaison privé.

  1. Démarrez une session Bureau à distance (RDP) et connectez-vous à la machine virtuelle.

  2. Vous pouvez ensuite procéder à des vérifications de base de la connectivité pour confirmer que la machine virtuelle se connecte à SQL Database par le biais du point de terminaison privé à l’aide des outils suivants :

    • Telnet
    • PsPing
    • Nmap
    • SQL Server Management Studio (SSMS)

Vérifier la connectivité à l’aide de Telnet

Telnet Client est une fonctionnalité Windows que vous pouvez utiliser pour tester la connectivité. Selon la version de votre système d’exploitation Windows, vous devrez peut-être activer cette fonctionnalité de manière explicite.

Après avoir installé Telnet, ouvrez une fenêtre d’invite de commandes. Exécutez la commande Telnet et spécifiez l’adresse IP et le point de terminaison privé de la base de données dans SQL Database.

telnet 10.9.0.4 1433

Quand Telnet parvient à se connecter, fenêtre commandes affiche un écran vide semblable à celui de l’image suivante :

Diagram of the Telnet window with blank screen.

Utiliser la commande PowerShell pour vérifier la connectivité :

Test-NetConnection -computer myserver.database.windows.net -port 1433

Vérifier la connectivité à l’aide de PsPing

PsPing peut être utilisé comme suit pour vérifier que le point de terminaison privé écoute les connexions sur le port 1433.

Exécutez PsPing comme suit en fournissant le FQDN de votre SQL Server logique et le port 1433 :

PsPing.exe mysqldbsrvr.database.windows.net:1433

Ceci est un exemple de la sortie attendue :

TCP connect to 10.9.0.4:1433:
5 iterations (warmup 1) ping test:
Connecting to 10.9.0.4:1433 (warmup): from 10.6.0.4:49953: 2.83ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49954: 1.26ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49955: 1.98ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49956: 1.43ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49958: 2.28ms

La sortie indique que PsPing a réussi à effectuer un test ping sur l’adresse IP privée associée au point de terminaison privé.

Vérifier la connectivité à l’aide de Nmap

Nmap (Network Mapper) est un outil gratuit et open source que vous povez utiliser pour découvrir des réseaux et auditer la sécurité. Pour obtenir plus d’informations et le lien de téléchargement, consultez https://Nmap.org. Vous pouvez utiliser cet outil pour vérifier que le point de terminaison privé écoute les connexions sur le port 1433.

Exécutez Nmap comme suit en fournissant la plage d’adresses du sous-réseau qui héberge le point de terminaison privé.

Nmap -n -sP 10.9.0.0/24

Ceci est un exemple de la sortie attendue :

Nmap scan report for 10.9.0.4
Host is up (0.00s latency).
Nmap done: 256 IP addresses (1 host up) scanned in 207.00 seconds

Le résultat indique qu’une adresse IP est active : il s’agit de l’adresse IP du point de terminaison privé.

Vérifier la connectivité à l’aide de SSMS (SQL Server Management Studio)

Notes

Utilisez le nom de domaine complet (FQDN) du serveur dans les chaînes de connexion de vos clients (<server>.database.windows.net). Toute tentative de connexion directe à l’adresse IP ou utilisant le nom de domaine complet de la liaison privée (<server>.privatelink.database.windows.net) échouera. Ce comportement est normal dans la mesure où le point de terminaison privé route le trafic vers la passerelle SQL dans la région et où le nom de domaine complet correct doit être spécifié pour que les connexions réussissent.

Suivez les étapes décrites ici afin d’utiliser SSMS pour vous connecter à la base de données SQL. Une fois que vous êtes connecté à SQL Database à l’aide de SSMS, la requête suivante doit refléter client_net_address, ce qui correspond à l’adresse IP privée de la machine virtuelle Azure à partir de laquelle vous vous connectez :

SELECT client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Utiliser la stratégie de connexion de redirection avec des points de terminaison privés

Nous recommandons aux clients d'utiliser la liaison privée avec la stratégie de connexion de redirection pour réduire la latence et améliorer le débit. Pour que les connexions utilisent ce mode, les clients doivent répondre aux conditions préalables suivantes :

  • Autoriser la communication entrante du VNET hébergeant le point de terminaison privé vers la plage de ports 1433 à 65535.

  • Autoriser la communication sortante depuis le VNET hébergeant le client vers la plage de ports 1433 à 65535.

  • Utiliser la dernière version des pilotes qui intègrent la prise en charge de la redirection. La prise en charge de la redirection est incluse dans les pilotes ODBC, OLEDB, NET SqlClient Data Provider, Core .NET SqlClient Data Provider et JDBC (version 9.4 ou ultérieure). Les connexions provenant de tous les autres pilotes sont mandatées.

Une fois les conditions préalables remplies, les clients doivent choisir explicitement la stratégie de connexion de redirection.

S'il n'est pas possible de modifier les paramètres du pare-feu pour autoriser l'accès sortant sur la plage de ports 1433-65535, une autre solution consiste à changer la stratégie de connexion en Proxy.

Les points de terminaison privés existants utilisant la stratégie de connexion par défaut soumis à un proxy, c'est-à-dire qu'ils utilisent la stratégie de connexion proxy avec le port 1433. La raison de cette opération est d'éviter toute interruption du trafic du client d'atteindre Sql Database en raison des plages de ports requises pour la redirection qui n'est pas ouverte.

Connectivité locale sur un appairage privé

Quand des clients se connectent au point de terminaison public à partir de machines locales, leur adresse IP doit être ajoutée au pare-feu IP à l’aide d’une règle de pare-feu au niveau du serveur. Bien que ce modèle fonctionne bien pour autoriser l’accès à des machines individuelles pour des charges de travail de développement ou de test, il est difficile à gérer dans un environnement de production.

Grâce à Liaison privée, les clients peuvent activer l’accès entre différents locaux au point de terminaison privé en utilisant ExpressRoute, un appairage privé ou un tunneling VPN. Les clients peuvent ensuite désactiver tout accès par le biais du point de terminaison public et s’abstenir d’utiliser le pare-feu IP pour autoriser les adresses IP.

Les clients peuvent se connecter au point de terminaison privé depuis le même réseau virtuel, le même réseau virtuel appairé dans la même région, ou via un réseau virtuel sur une connexion de réseau virtuel entre des régions. Les clients peuvent également se connecter localement avec ExpressRoute, un appairage privé ou un tunneling VPN. Le diagramme simplifié suivant montre les cas d’utilisation courants.

Diagram of connectivity option.

En outre, les services qui ne s’exécutent pas directement dans le réseau virtuel, mais qui y sont intégrés (par exemple, App Service Web Apps ou Functions) peuvent également obtenir une connectivité privée à la base de données. Pour plus d’informations sur ce cas d’usage spécifique, consultez le scénario d’architecture Application web avec connectivité privée à une base de données Azure SQL.

Connexion à partir d’une machine virtuelle Azure dans un réseau virtuel appairé

Configurez l’appairage de réseau virtuel pour établir la connectivité à la base de données dans SQL Database, à partir d’une machine virtuelle Azure dans un réseau virtuel appairé.

Connexion à partir d’une machine virtuelle Azure dans un réseau virtuel à un environnement de réseau virtuel

Configurez un réseau virtuel à une connexion de passerelle VPN de réseau virtuel pour établir la connectivité à une base de données dans SQL Database, à partir d’une machine virtuelle Azure dans une autre région ou un autre abonnement.

Connexion à partir d’un environnement local sur un VPN

Pour établir la connectivité entre un environnement local et la base de données dans SQL Database, choisissez et implémentez l’une des options suivantes :

Envisageons également les scénarios de configuration DNS, car le nom de domaine complet du service peut être résolu sur l’adresse IP publique.

Connexion à partir d’Azure Synapse Analytics à Stockage Azure à l’aide de PolyBase et de l’instruction COPY

La technologie PolyBase et l’instruction COPY sont couramment utilisées pour charger des données dans Azure Synapse Analytics à partir de comptes Stockage Azure. Si le compte de stockage Azure à partir duquel vous chargez des données limite l’accès uniquement à un ensemble de sous-réseaux de réseau virtuel par le biais de points de terminaison privés, de points de terminaison de service ou de pare-feu IP, la connectivité de PolyBase et l’instruction COPY au compte sera interrompue. Pour autoriser les scénarios d’importation et d’exportation dans lesquels Azure Synapse Analytics se connecte de manière sécurisée au stockage Azure sur un réseau virtuel, suivez les étapes indiquées ici.

Prévention de l’exfiltration de données

L’exfiltration de données dans Azure SQL Database se produit quand un utilisateur, tel qu’un administrateur de base de données, extrait des données d’un système et les déplace vers un autre emplacement ou système en dehors de l’organisation. C’est par exemple le cas quand un utilisateur déplace des données vers un compte de stockage détenu par un tiers.

Imaginez un scénario selon lequel un utilisateur exécute SSMS (SQL Server Management Studio) à l’intérieur d’une machine virtuelle Azure se connectant à une base de données dans SQL Database. Cette base de données se trouve dans le centre de données USA Ouest. L’exemple suivant montre comment utiliser des contrôles d’accès réseau pour limiter l’accès à SQL Database par le biais de points de terminaison publics.

  1. Désactivez tout le trafic des services Azure à destination de la base de données SQL par le biais du point de terminaison public en affectant OFF à l’option Autoriser les services Azure. Vérifiez qu’aucune adresse IP n’est autorisée dans les règles de pare-feu au niveau du serveur et de la base de données. Pour plus d’informations, consultez Contrôles d’accès réseau Azure SQL Database et Azure Synapse Analytics.
  2. Autorisez uniquement le trafic à destination de la base de données dans SQL Database à l’aide de l’adresse IP privée de la machine virtuelle. Pour plus d’informations, consultez les articles sur le Point de terminaison de service et les Règles de pare-feu du réseau virtuel.
  3. Sur la machine virtuelle Azure, limitez l'étendue de la connexion sortante à l'aide de groupes de sécurité réseau (NSG) et d'étiquettes de service comme suit.
    • Spécifiez une règle NSG pour autoriser le trafic pour Service Tag = SQL.WestUs (autorise uniquement la connexion à la SQL Database dans USA Ouest).
    • Spécifiez une règle NSG avec une priorité plus élevée pour refuser le trafic pour Service Tag = SQL (refuse les connexions à la SQL Database dans toutes les régions).

À la fin de cette configuration, la machine virtuelle Azure peut uniquement se connecter à une base de données dans SQL Database de la région USA Ouest. Toutefois, la connectivité n’est pas limitée à une seule base de données dans SQL Database. La machine virtuelle peut toujours se connecter à n’importe quelle base de données de la région USA Ouest, même si elle ne fait pas partie de l’abonnement. Bien que nous ayons réduit l’étendue de l’exfiltration de données dans le scénario ci-dessus à une région spécifique, nous ne l’avons pas encore totalement éliminée.

Grâce à Liaison privée, les clients peuvent désormais configurer des contrôles d’accès réseau comme des groupes de sécurité réseau pour restreindre l’accès au point de terminaison privé. Les ressources Azure PaaS individuelles sont ensuite mappées à des points de terminaison privés spécifiques. Un utilisateur interne malveillant peut uniquement accéder à la ressource PaaS mappée (par exemple, une base de données dans SQL Database). Il n’a accès à aucune autre ressource.