Partager via

Connectivité et concepts de réseau pour Azure Database pour MySQL – Serveur flexible

Cet article présente les concepts permettant de contrôler la connectivité à votre instance de serveur flexible Azure Database pour MySQL. Vous découvrez en détail les concepts de mise en réseau d’un Serveur flexible Azure Database pour MySQL afin de créer un serveur dans Azure et d’y accéder en toute sécurité.

Le serveur flexible Azure Database pour MySQL prend en charge trois méthodes pour configurer la connectivité à vos serveurs :

Note

Après avoir déployé un serveur avec un accès public ou privé (via l’intégration au réseau virtuel), vous ne pouvez pas modifier le mode de connectivité. Toutefois, en mode d’accès public, vous pouvez activer ou désactiver des points de terminaison privés selon les besoins et également désactiver l’accès public si nécessaire.

Choisir une option de réseau

Choisissez la méthode Accès public (adresses IP autorisées) et point de terminaison privé si vous souhaitez bénéficier des fonctionnalités suivantes :

  • Connexion à partir des ressources Azure sans prise en charge du réseau virtuel
  • Connexion à partir de ressources situées en dehors d’Azure qui ne sont pas connectées par un réseau privé virtuel (VPN) ou ExpressRoute
  • Le serveur flexible est accessible via un point de terminaison public et via des ressources Internet autorisées. L’accès public peut être désactivé si nécessaire.
  • Possibilité de configurer des points de terminaison privés pour accéder au serveur à partir d’hôtes sur un réseau virtuel (VNet)

Choisissez Accès privé (intégration au réseau virtuel) si vous souhaitez bénéficier des fonctionnalités suivantes :

  • Connexion à votre serveur flexible à partir de ressources Azure au sein du même réseau virtuel ou d’un réseau virtuel appairé sans avoir besoin de configurer un point de terminaison privé
  • Utilisation d’un VPN ou du service ExpressRoute pour vous connecter à partir de ressources non-Azure à votre serveur flexible
  • Aucun point de terminaison public

Les caractéristiques suivantes s’appliquent, que vous choisissiez d’utiliser l’option d’accès privé ou d’accès public :

  • Les connexions provenant d’adresses IP autorisées doivent s’authentifier auprès de l’instance de serveur flexible Azure Database pour MySQL avec des informations d’identification valides
  • Le chiffrement des connexions est disponible pour votre trafic réseau
  • Le serveur a un nom de domaine complet (FQDN). Nous vous recommandons d’utiliser le FQDN au lieu d’une adresse IP pour la propriété hostname dans les chaînes de connexion.
  • Les deux options contrôlent l’accès au niveau du serveur, pas au niveau de la base de données ni de la table. Vous pouvez utiliser les propriétés des rôles de MySQL pour contrôler l’accès aux bases de données, aux tables et autres objets.

Prise en charge des ports personnalisés

Azure MySQL prend désormais en charge la possibilité de spécifier un port personnalisé entre 250001 et 26000 lors de la création du serveur pour se connecter au serveur. Le port par défaut à connecter est 3306.

  • Un seul port personnalisé par serveur est pris en charge.
  • Scénarios pris en charge pour les ports personnalisés : création de serveurs, restauration (restauration inter-ports prise en charge), création de réplicas en lecture, activation de la haute disponibilité.
  • Limitations actuelles :
    • Le port personnalisé ne peut pas être mis à jour après la création du serveur.
    • La géorestauration et la création de géoréplicas avec un port personnalisé ne sont pas prises en charge.

Scénarios de réseau virtuel non pris en charge

  • Point de terminaison public (ou IP publique ou DNS) : un serveur flexible déployé sur un réseau virtuel ne peut pas avoir de point de terminaison public.
  • Une fois le Serveur flexible déployé sur un réseau et un sous-réseau virtuel, vous ne pouvez pas le déplacer vers un autre réseau ou sous-réseau virtuel.
  • Une fois que le serveur flexible est déployé, vous ne pouvez pas déplacer le réseau virtuel que le serveur flexible utilise dans un autre groupe de ressources ou un autre abonnement.
  • Il est impossible d’augmenter la taille d’un sous-réseau (espaces d’adressage) une fois que des ressources s’y trouvent.
  • Passer d’un accès public à un accès privé n’est pas autorisé après la création du serveur. La méthode recommandée consiste à utiliser une restauration à un instant dans le passé.

Note

Si vous utilisez le serveur DNS personnalisé, vous devez utiliser un redirecteur DNS pour résoudre le nom de domaine complet de l’instance de serveur flexible Azure Database pour MySQL. Consultez Résolution de noms utilisant votre serveur DNS si vous souhaitez en savoir plus.

Hostname

Quelle que soit votre option de réseau, nous vous recommandons d’utiliser le nom de domaine complet (FQDN) <servername>.mysql.database.azure.com dans les chaînes de connexion quand vous vous connectez à votre instance de serveur flexible Azure Database pour MySQL. Il n’est pas garanti que l’adresse IP du serveur reste statique. L’utilisation du FQDN vous permet d’éviter des modifications dans votre chaîne de connexion.

Par exemple, hostname = servername.mysql.database.azure.com utilise un FQDN comme nom d’hôte. Dans la mesure du possible, évitez d’utiliser hostname = 10.0.0.4 (adresse privée) ou hostname = 40.2.45.67 (adresse publique).

Note

Si votre serveur flexible Azure Database pour MySQL dispose à la fois d’un accès public et d’une liaison privée activées, les adresses IP publiques de votre instance sont mises à jour dans le cadre de la modification architecturale pour améliorer l’expérience réseau. Si vous utilisez ces adresses IP publiques dans votre chaîne de connexion, vous devez remplacer le nom de domaine complet avant le 9 septembre 2025 pour éviter toute interruption dans la connexion au serveur. (Remarque : l’adresse IP de liaison privée ou l’adresse IP d’intégration de réseau virtuel n’est pas affectée). Action requise : exécutez NSLookup à partir de votre réseau public pour obtenir l’adresse IP publique qui changera et vous devez mettre à jour sa référence dans la chaîne de connexion pour utiliser le nom de domaine complet à la place.

TLS et SSL

Le serveur flexible Azure Database pour MySQL prend en charge la connexion de vos applications clientes à l’instance de serveur flexible Azure Database pour MySQL en utilisant le chiffrement SSL (Secure Sockets Layer) avec le protocole TLS (Transport Layer Security). TLS est un protocole standard qui garantit la sécurité des connexions réseau entre votre serveur de base de données et vos applications clientes, ce qui vous permet de respecter la conformité requise.

Le serveur flexible Azure Database pour MySQL prend en charge par défaut les connexions chiffrées à l’aide du protocole TLS 1.2 (Transport Layer Security), donc toutes les connexions entrantes qui utilisent les protocoles TLS 1.0 et TLS 1.1 sont refusées par défaut. Vous pouvez configurer et modifier la configuration de la mise en œuvre de la connexion chiffrée ou de la version TLS sur votre serveur flexible.

Voici les différentes configurations des paramètres SSL et TLS que vous pouvez avoir pour votre serveur flexible :

Important

Selon la suppression de la prise en charge des protocoles TLS 1.0 et TLS 1.1, nous avons prévu précédemment de déprécier entièrement TLS 1.0 et 1.1 d’ici septembre 2024. Toutefois, en raison des dépendances identifiées par certains clients, nous avons décidé d’étendre la chronologie.

  • À compter du 31 août 2025, nous allons commencer la mise à niveau forcée pour tous les serveurs qui utilisent tls 1.0 ou 1.1. Après cette date, toutes les connexions qui s’appuient sur TLS 1.0 ou 1.1 peuvent cesser de fonctionner à tout moment. Pour éviter les interruptions de service potentielles, nous recommandons vivement aux clients d’effectuer leur migration vers TLS 1.2 avant le 31 août 2025.
  • À compter de septembre 2024, les nouveaux serveurs ne seront plus autorisés à utiliser TLS 1.0 ou 1.1, et les serveurs existants ne seront plus autorisés à passer à ces versions.

Nous recommandons vivement aux clients de mettre à jour leurs applications pour prendre en charge TLS 1.2 dès que possible pour éviter les interruptions de service.

Scenario Paramètres de serveur Description
Désactiver SSL (connexions chiffrées) require_secure_transport = OFF (désactiver le transport sécurisé) Si votre application héritée ne prend pas en charge les connexions chiffrées à l’instance de serveur flexible Azure Database pour MySQL, vous pouvez désactiver la mise en œuvre des connexions chiffrées à votre serveur flexible en définissant require_secure_transport=OFF.
Forcer l'utilisation de SSL avec la version < 1.2 de TLS (obsolète en septembre 2024) require_secure_transport = ON et tls_version = TLS 1.0 ou TLS 1.1 Si votre application héritée prend en charge les connexions chiffrées mais nécessite la version TLS < 1.2, vous pouvez activer les connexions chiffrées, mais configurez votre serveur flexible pour autoriser les connexions avec la version TLS (v1.0 ou v1.1) prises en charge par votre application
Appliquer le protocole SSL avec la version TLS = 1.2 (configuration par défaut) require_secure_transport = ON et tls_version = TLS 1.2 Il s’agit de la configuration par défaut recommandée pour un serveur flexible.
Appliquer le protocole SSL avec la version TLS = 1.3 (pris en charge avec MySQL v8.0 et ultérieur) require_secure_transport = ON et tls_version = TLS 1.3 Cela est utile et recommandé pour le développement de nouvelles applications

Note

Les modifications apportées au chiffrement SSL sur le serveur flexible ne sont pas prises en charge. La suite de chiffrement FIPS est appliquée par défaut lorsque tls_version est défini sur TLS version 1.2. Pour les versions TLS autres que la version 1.2, le chiffrement SSL est défini sur les paramètres par défaut qui sont fournis avec l’installation de MySQL Community.

Passez en revue la connexion à l’aide de SSL/TLS pour savoir comment identifier la version TLS que vous utilisez.

Contenu connexe

  • Last updated on