Azure Private Link pour Azure SQL Database et Azure Synapse Analytics
S’applique à : 
Azure SQL Database Azure Synapse Analytics (pools SQL dédiés uniquement)
Azure Private Link 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.
Comment configurer Private Link
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.
Accédez à la ressource serveur dans le Portail Azure.
Accédez à la page d’approbation du point de terminaison privé :
- Dans la ressource SQL Server, sous Sécurité, sélectionnez Réseau. Sélectionnez l’onglet Accès privé.
- Dans l’espace de travail Synapse, sous Sécurité dans le menu de ressources, sélectionnez Connexions de point de terminaison 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
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.
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.
Après approbation ou rejet, la liste reflète l’état approprié et le texte de réponse.
Enfin, sélectionnez le nom du point de terminaison privé
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é.
La page Interface réseau affiche l’adresse IP privée pour la connexion du point de terminaison privé.
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
Dans la Azure SQL Database logical SQL server, supposez que vous souhaitez désactiver tout accès public à votre serveur logique Azure SQL 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 :
Accédez à la page Mise en réseau de votre serveur logique.
Cochez la case Refuser l’accès au réseau public.
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é.
Démarrez une session Bureau à distance (RDP) et connectez-vous à la machine virtuelle.
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 :
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 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.
Remarque
Pour les pools SQL dédiés, la stratégie de connexion lors de l’utilisation de points de terminaison privés est toujours Proxy. La modification du paramètre n’affecte pas les pools SQL dédiés lors de l’utilisation de points de terminaison privés.
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.
Cas d’usage de Liaison privée pour Azure SQL Database
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.
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 une entité non Microsoft.
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.
- 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.
- 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.
- 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.