Réseau avec accès privé (intégration de réseau virtuel) pour Azure Database pour PostgreSQL

Cet article décrit les concepts de connectivité et de mise en réseau pour les instances de serveur flexible Azure Database pour PostgreSQL.

Lorsque vous créez une instance de serveur flexible Azure Database pour PostgreSQL, vous devez choisir l’une des options de mise en réseau suivantes :

• Accès privé (intégration d’un réseau virtuel)
• Accès public (adresses IP autorisées) et point de terminaison privé

Ce document décrit l’option de mise en réseau de l’accès privé (intégration au réseau virtuel).

Accès privé (intégration d’un réseau virtuel)

Vous pouvez déployer une instance de serveur flexible Azure Database pour PostgreSQL dans votre réseau virtuel Azure à l’aide de l’injection de réseau virtuel. Les réseaux virtuels Azure offrent des communications réseau privées et sécurisées. Les ressources d’un réseau virtuel peuvent communiquer via des adresses IP privées qui ont été attribuées sur ce réseau.

Choisissez cette option de mise en réseau si vous souhaitez bénéficier des capacités suivantes :

• Connectez-vous à partir de ressources Azure dans le même réseau virtuel à votre instance de serveur flexible Azure Database pour PostgreSQL à l’aide d’adresses IP privées.
• Utilisez un VPN ou Azure ExpressRoute pour vous connecter à partir de ressources non-Azure à votre instance de serveur flexible Azure Database pour PostgreSQL.
• Vérifiez que l’instance de serveur flexible Azure Database pour PostgreSQL n’a aucun point de terminaison public accessible via Internet.

Dans le diagramme ci-dessus :

• Les instances de serveur flexible Azure Database pour PostgreSQL sont injectées dans le sous-réseau 10.0.1.0/24 du réseau virtuel VNet-1.
• Les applications déployées sur différents sous-réseaux au sein du même réseau virtuel peuvent accéder directement aux instances de serveur flexible Azure Database pour PostgreSQL.
• Les applications déployées sur un autre réseau virtuel (VNet-2) n’ont pas d’accès direct aux instances de serveur flexible Azure Database pour PostgreSQL. Vous devez effectuer un peering de réseaux virtuels pour une zone DNS privée avant de pouvoir accéder à l’instance de serveur flexible.

Concepts de réseau virtuel

Un réseau virtuel Azure contient un espace d’adressage IP privé configuré pour votre usage. Votre réseau virtuel doit se trouver dans la même région Azure que votre instance de serveur flexible Azure Database pour PostgreSQL. Pour en savoir plus sur les réseaux virtuels, consultez la vue d’ensemble de Réseau virtuel Azure.

Voici quelques concepts à connaître lorsque vous utilisez des réseaux virtuels où les ressources sont intégrées à un réseau virtuel avec des instances de serveur flexible Azure Database pour PostgreSQL :

• Sous-réseau délégué : Un réseau virtuel contient des sous-réseaux. Les sous-réseaux vous permettent de segmenter votre réseau virtuel en espaces d’adressage plus petits. Les ressources Azure sont déployées sur des sous-réseaux spécifiques au sein d’un réseau virtuel.

  Votre instance de serveur flexible Azure Database pour PostgreSQL intégrée à un réseau virtuel doit se trouver dans un sous-réseau délégué. Autrement dit, seules les instances de serveur flexible Azure Database pour PostgreSQL peuvent utiliser ce sous-réseau. Aucun autre type de ressource Azure ne peut se trouver sur le sous-réseau délégué. Pour déléguer un sous-réseau, définissez sa propriété de délégation sur Microsoft.DBforPostgreSQL/flexibleServers.

  La plus petite plage CIDR que vous puissiez spécifier pour le sous-réseau est /28. Celle-ci fournit 16 adresses IP. La première et la dernière adresse d’un réseau ou d’un sous-réseau ne peuvent pas être attribuées à un hôte individuel. Azure réserve cinq adresses IP à utiliser en interne à des fins de mise en réseau Azure, incluant deux adresses IP qui ne peuvent pas être attibuées à l’hôte, comme mentionné ci-dessus. Il reste donc 11 adresses IP disponibles pour une plage CIDR /28. Une seule instance de serveur flexible Azure Database pour PostgreSQL avec des fonctionnalités de haute disponibilité utilise quatre adresses.

  Pour la réplication et les connexions Microsoft Entra, vérifiez que les tables de routage n’affectent pas le trafic. Un modèle courant consiste à router tout le trafic sortant via un Pare-feu Azure ou une appliance de filtrage réseau locale personnalisée.

  Si le sous-réseau a une table de routage associée à la règle pour acheminer tout le trafic vers une appliance virtuelle :

  • Ajoutez une règle avec l’étiquette de service de destination AzureActiveDirectory et le tronçonsuivant Internet.
  • Ajoutez une règle dont la plage d'adresses IP de destination est identique à la plage de sous-réseau de l'instance du serveur flexible Azure Database pour PostgreSQL et dont le prochain saut est Virtual Network.

  Important

  Les noms AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet et GatewaySubnet sont réservés à Azure. N’utilisez aucun de ces noms comme nom de sous-réseau. En outre, les réseaux virtuels ne doivent pas avoir d’espace d’adressage chevauche pour créer des réplicas inter-région.

• Groupe de sécurité réseau (NSG) : Les règles de sécurité des NSG vous permettent de filtrer le type de trafic réseau qui peut entrer et sortir des sous-réseaux de réseau virtuel et des interfaces réseau. Pour plus d’informations, consultez la présentation des groupes de sécurité réseau.

  Les groupes de sécurité d’application facilitent le contrôle de la sécurité de couche 4 en utilisant des groupes de sécurité réseau pour les réseaux plats. Vous pouvez rapidement :

  • Joindre des machines virtuelles à un groupe de sécurité d’application ou supprimer des machines virtuelles d’un groupe de sécurité d’application.
  • Appliquer dynamiquement des règles à ces machines virtuelles ou supprimer des règles de ces machines virtuelles.

  Pour plus d’informations, consultez la présentation des groupes de sécurité d’application.

  Pour le moment, nous ne prenons pas en charge les groupes de sécurité réseau (NSG) lorsqu'un groupe de sécurité d'application (ASG) fait partie de la règle avec les instances de serveur flexibles Azure Database pour PostgreSQL. Nous conseillons actuellement d’utiliser le filtrage de la source ou de la destination basé sur l’adresse IP dans un groupe de sécurité réseau.

  La haute disponibilité et d’autres fonctionnalités du serveur Azure Database pour PostgreSQL nécessitent la possibilité d’envoyer/recevoir du trafic vers le port de destination 5432 dans le sous-réseau de réseau virtuel Azure où une instance de serveur flexible Azure Database pour PostgreSQL est déployée et vers Stockage Azure pour l’archivage des journaux. Si vous créez des groupes de sécurité réseau (NSG) pour refuser le flux de trafic vers ou depuis votre instance de serveur flexible Azure Database pour PostgreSQL dans le sous-réseau où il est déployé, assurez-vous d'autoriser le trafic vers le port de destination 5432 au sein de ce même sous-réseau, ainsi qu'à destination du stockage, en utilisant l'étiquette de balisage de service Storage comme destination. Pour la haute disponibilité, la meilleure pratique consiste à ajouter un point de terminaison de service Microsoft.Storage, car il garantit un routage correct du trafic vers le compte de stockage Azure qui est utilisé pour charger des fichiers WAL (Write Ahead Log).

  Vous pouvez filtrer cette règle d'exception en ajoutant votre région Azure à l'étiquette, comme ceci us-east.storage. En outre, si vous choisissez d’utiliser l’authentification Microsoft Entra pour authentifier les connexions à votre instance de serveur flexible Azure Database pour PostgreSQL, autorisez le trafic sortant vers Microsoft Entra ID à l’aide d’une balise de service Microsoft Entra.

  Lorsque vous configurez des réplicas en lecture sur plusieurs régions Azure, votre instance de serveur flexible Azure Database pour PostgreSQL doit pouvoir envoyer ou recevoir du trafic vers le port de destination 5432 pour le serveur principal et le serveur de réplication, ainsi que vers Azure Storage dans les régions principales et de réplication, à partir des serveurs principaux et de réplication. Le port TCP de destination requis pour Stockage est 443.

• Intégration de zone DNS privée : l’intégration de zone DNS privée Azure vous permet de résoudre le DNS privé au sein du réseau virtuel actuel ou de tout réseau virtuel apparié dans la même région où la zone DNS privée est liée.

Utiliser une zone DNS privée

Azure Private DNS fournit un service DNS fiable et sécurisé pour votre réseau virtuel. Azure Private DNS gère et résout les noms de domaine dans le réseau virtuel sans nécessiter la configuration d’une solution DNS personnalisée.

Lorsque vous utilisez un accès réseau privé avec un réseau virtuel Azure, la fourniture des informations de zone DNS privée est obligatoire pour pouvoir effectuer la résolution DNS. Pour une nouvelle création d’instance de serveur flexible Azure Database pour PostgreSQL à l’aide d’un accès réseau privé, les zones DNS privées doivent être utilisées lors de la configuration des instances de serveur flexible Azure Database pour PostgreSQL avec un accès privé.

Important

Lors de l’utilisation d’une zone DNS privée dans un autre abonnement, cet abonnement doit également avoir le fournisseur de ressources Microsoft.DBforPostgreSQL inscrit, sinon votre déploiement d’une instance de serveur flexible Azure Database pour PostgreSQL ne se termine pas.

Pour la création d'une nouvelle instance de serveur flexible Azure Database pour PostgreSQL à l'aide d'un accès réseau privé avec une API, un modèle Azure Resource Manager (modèle ARM), Bicep ou Terraform, créez des zones DNS privées. Ensuite, utilisez-les pendant que vous configurez des instances de serveur flexible Azure Database pour PostgreSQL avec un accès privé. Pour plus d'informations, consultez les spécifications de l'API REST pour Azure.

Si vous utilisez le portail Azure ou l’interface de ligne de commande Azure pour créer des instances de serveur flexible Azure Database pour PostgreSQL, vous pouvez fournir un nom de zone DNS privé que vous avez créé précédemment dans le même abonnement ou un autre abonnement, ou une zone DNS privée par défaut est automatiquement créée dans votre abonnement.

Si vous utilisez une API Azure, un modèle ARM, Bicep ou Terraform, créez des zones DNS privées qui se terminent par .postgres.database.azure.com. Utilisez ces zones pendant que vous configurez des instances de serveur flexible Azure Database pour PostgreSQL avec un accès privé. Par exemple, utilisez le formulaire [name1].[name2].postgres.database.azure.com ou [name].postgres.database.azure.com. Si vous choisissez d’utiliser le formulaire [name].postgres.database.azure.com, le nom ne peut pas être le nom que vous utilisez pour l’une de vos instances de serveur flexible Azure Database pour PostgreSQL, ou vous obtiendrez un message d’erreur lors de l’approvisionnement. Pour plus d'informations, consultez la présentation des zones DNS privées.

Lorsque vous utilisez le portail Azure, les API, Azure CLI ou un modèle ARM, vous pouvez également modifier la zone DNS privée de celle que vous avez fournie lors de la création de votre instance de serveur flexible Azure Database pour PostgreSQL vers une autre zone DNS privée qui existe pour le même abonnement ou un autre abonnement.

Important

La possibilité de modifier une zone DNS privée de celle que vous avez fournie lors de la création de votre instance de serveur flexible Azure Database pour PostgreSQL vers une autre zone DNS privée est actuellement désactivée pour les serveurs avec la fonctionnalité de haute disponibilité activée.

Après avoir créé une zone DNS privée dans Azure, vous devez y associer un réseau virtuel. Les ressources hébergées dans ce réseau virtuel peuvent accéder à la zone DNS privée.

Important

Nous ne validons plus la présence de liaison de réseau virtuel lors de la création du serveur pour les instances de serveur flexible Azure Database pour PostgreSQL avec une mise en réseau privée. Lorsque vous créez un serveur via le portail, nous vous offrons la possibilité de créer un lien lors de la création du serveur en cochant la case Lier une zone DNS privée à votre réseau virtuel dans le Portail Microsoft Azure.

Les zones privées DNS résistent aux pannes régionales car les données de la zone sont disponibles au niveau mondial. Les enregistrements de ressources dans une zone privée sont répliqués automatiquement entre les régions. Azure DNS privé est un service de base redondant de zone de disponibilité. Pour plus d’informations, consultez Services Azure prenant en charge les zones de disponibilité.

Intégration avec un serveur DNS personnalisé

Si vous utilisez un serveur DNS personnalisé, vous devez utiliser un redirecteur DNS pour résoudre le nom de domaine complet de votre instance de serveur flexible Azure Database pour PostgreSQL. L’adresse IP du redirecteur doit être 168.63.129.16.

Le serveur DNS personnalisé doit se trouver à l’intérieur du réseau virtuel ou être accessible via le paramètre de serveur DNS du réseau virtuel. Pour en savoir plus, consultez Résolution de noms utilisant votre propre serveur DNS.

Zone DNS privée et appairage de réseaux virtuels

Les paramètres de zone DNS privée et l’appairage de réseaux virtuels sont indépendants les uns des autres. Si vous souhaitez vous connecter à l’instance de serveur flexible Azure Database pour PostgreSQL à partir d’un client approvisionné dans un autre réseau virtuel à partir de la même région ou d’une autre région, vous devez lier la zone DNS privée au réseau virtuel. Pour plus d’informations, consultez Lier le réseau virtuel.

Remarque

Seules les zones DNS privées dont le nom se termine par postgres.database.azure.com peuvent être liées. Votre nom de zone DNS ne peut pas être identique à vos instances de serveur flexible Azure Database pour PostgreSQL. Sinon, la résolution de noms échoue.

Pour associer un nom de serveur à un enregistrement DNS, vous pouvez exécuter la commande nslookup dans Azure Cloud Shell en utilisant Azure PowerShell ou Bash. Remplacez le nom de votre serveur par le paramètre <server_name> dans l’exemple ci-dessous :

nslookup -debug <server_name>.postgres.database.azure.com | grep 'canonical name'

Utiliser la conception de réseau privé en étoile

Hub-and-spoke est un modèle de réseau populaire qui permet de gérer efficacement les besoins courants en matière de communication ou de sécurité.

Le hub est un réseau virtuel qui joue le rôle d’emplacement central pour gérer la connectivité externe. Il héberge également les services utilisés par plusieurs charges de travail. Le hub coordonne toutes les communications vers et depuis les spokes. Les règles ou les processus informatiques comme la sécurité peuvent inspecter, acheminer et gérer de manière centralisée le trafic. Les spokes désignent des réseaux virtuels qui hébergent les charges de travail et se connectent au hub central à l’aide du peering de réseaux virtuels. Les services partagés sont hébergés dans leurs propres sous-réseaux pour être partagés avec les spokes. Un sous-réseau de périmètre fait ensuite office d’appliance de sécurité.

Les spokes sont aussi des réseaux virtuels dans Azure, utilisés pour isoler les charges de travail individuelles. Le flux de trafic entre le siège local et Azure est connecté via Azure ExpressRoute ou un VPN site à site connecté au réseau virtuel du hub. Les réseaux virtuels des spokes au hub sont appairés et permettent la communication avec les ressources locales. Vous pouvez implémenter le hub et chaque spoke dans des abonnements ou des groupes de ressources distincts.

Il existe trois modèles principaux pour connecter les réseaux virtuels spoke les uns aux autres :

• Les réseaux distants sont directement connectés entre eux : des interconnexions de réseaux virtuels ou des tunnels VPN sont créés entre les réseaux virtuels distants pour fournir une connectivité directe sans passer par le réseau virtuel central.
• Les réseaux distants communiquent via un dispositif réseau : chaque réseau virtuel distant est connecté à un WAN virtuel ou à un réseau virtuel central. Une appliance achemine le trafic de spoke en spoke. L’appliance peut être gérée par Microsoft (comme avec Virtual WAN) ou par vous-même.
• Une passerelle de réseau virtuel est connectée au réseau central et utilise des routes définies par l'utilisateur : elle permet la communication entre les réseaux périphériques.

Utilisez Azure Virtual Network Manager pour créer de nouvelles topologies de réseau virtuel en étoile (et intégrer celles existantes) pour la gestion centralisée de la connectivité et des contrôles de sécurité.

Communication avec des clients en réseau privé dans différentes régions

Les clients ont souvent besoin de se connecter à des clients dans différentes régions Azure. Plus précisément, cette question se résume généralement à la façon de connecter deux réseaux virtuels (dont l’un a une instance de serveur flexible Azure Database pour PostgreSQL et un autre a un client d’application) qui se trouvent dans différentes régions.

Il existe plusieurs façons d’obtenir une telle connectivité, notamment :

• Interconnexion de réseaux virtuels mondiaux. Cette méthodologie est la plus courante, car il s’agit du moyen le plus simple pour connecter des réseaux dans différentes régions. L’appairage de réseaux virtuels mondial crée une connexion sur le réseau principal Azure directement entre les deux réseaux virtuels appairés. Cette méthode offre le meilleur débit réseau et les latences les plus faibles pour la connectivité. Lorsque des réseaux virtuels sont appairés, Azure gère également le routage automatiquement pour vous. Ces réseaux virtuels peuvent communiquer avec toutes les ressources du réseau virtuel appairé qui sont établies sur une passerelle VPN.
• Connexion réseau à réseau. Une connexion entre réseaux virtuels (connexion réseau à réseau) est essentiellement un VPN entre les deux localisations Azure. Une connexion réseau à réseau est établie sur une passerelle VPN. Votre trafic entraîne deux tronçons de trafic supplémentaires par rapport à l’appairage de réseaux virtuels mondial. Il existe également une latence supplémentaire et une bande passante inférieure, comparé à cette méthode.
• Communication via une appliance réseau dans une architecture de réseau en étoile. Au lieu de connecter directement les réseaux virtuels spokes entre eux, vous pouvez utiliser des appliances réseau pour transférer le trafic entre les spokes. Les appliances réseau fournissent des services réseau supplémentaires tels que l’inspection approfondie des paquets et la segmentation ou le monitoring du trafic, mais elles peuvent introduire des goulots d’étranglement en termes de latence et de performances si elles ne sont pas correctement dimensionnées.

Réplication entre les régions Azure et les réseaux virtuels avec réseau privé

La réplication de base de données est le processus de copie de données d’un serveur central ou principal vers plusieurs serveurs appelés réplicas. Le serveur principal accepte les opérations de lecture et d’écriture, mais les réplicas traitent les transactions en lecture seule. Le serveur principal et les réplicas forment ensemble un cluster de base de données. L’objectif de la réplication de base de données est de garantir la redondance, la cohérence, la haute disponibilité et l’accessibilité des données, en particulier dans les applications stratégiques à fort trafic.

Azure Database pour PostgreSQL propose deux méthodes de réplication : la réplication physique (c’est-à-dire en flux continu) via la fonctionnalité intégrée Read Replica et la réplication logique. Chaque méthode convient à un cas d’usage particulier, et un utilisateur peut choisir l’une plutôt que l’autre en fonction de l’objectif final.

La réplication entre régions Azure, avec des réseaux virtuels distincts dans chaque région, nécessite une connectivité au-delà des limites des réseaux virtuels régionaux, qui peut être assurée par le biais d'un peering de réseaux virtuels ou, dans des architectures en étoile, par l'intermédiaire d'un dispositif réseau.

Par défaut, la résolution de noms DNS est limitée à un réseau virtuel. Tout client dans un réseau virtuel (VNET1) est incapable de résoudre le FQDN de l'instance de serveur flexible Azure Database pour PostgreSQL situé dans un autre réseau virtuel (VNET2).

Pour résoudre ce problème, vous devez vous assurer que les clients dans VNET1 peuvent accéder à la zone DNS privée de l’instance de serveur flexible Azure Database pour PostgreSQL. Ajoutez un lien de réseau virtuel à la zone DNS privée de votre instance de serveur flexible Azure Database pour PostgreSQL.

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

Voici quelques limitations à l’utilisation de réseaux virtuels créés par le biais d’une intégration au réseau virtuel :

• Une fois qu’une instance de serveur flexible Azure Database pour PostgreSQL est déployée sur un réseau virtuel et un sous-réseau, vous ne pouvez pas la déplacer vers un autre réseau virtuel ou sous-réseau. Vous ne pouvez pas déplacer le réseau virtuel vers 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 existent dans ce sous-réseau.
• Par défaut, les ressources injectées par réseau virtuel ne peuvent pas interagir avec Private Link. Si vous souhaitez utiliser Private Link pour la mise en réseau privée, consultez la mise en réseau Azure Database pour PostgreSQL avec Private Link.

Important

Azure Resource Manager prend en charge le verrouillage des ressources comme mesure de sécurité. Un verrou de ressource est appliqué à une ressource et le verrouillage de celle-ci s’étend à l’ensemble des utilisateurs et des rôles qui l’utilisent. Il existe deux types de verrous de ressource : CanNotDelete et ReadOnly. Ces types de verrous peuvent être appliqués à une zone DNS privée ou à un jeu d’enregistrements.

L’application d’un verrou de type à une zone DNS privée ou à un jeu d’enregistrements individuel peut interférer avec la capacité d’une instance de serveur flexible Azure Database pour PostgreSQL à mettre à jour les enregistrements DNS. Cela peut ainsi entraîner des problèmes lors d’opérations importantes sur le DNS, comme le basculement de haute disponibilité du principal vers le secondaire. Pour ces raisons, assurez-vous que vous n’utilisez pas de verrous de zone privée DNS ou d’enregistrement lorsque vous utilisez des fonctionnalités de haute disponibilité avec une instance de serveur flexible Azure Database pour PostgreSQL.

Nom de l’hôte

Quelle que soit l’option de mise en réseau que vous choisissez, nous vous recommandons d’utiliser toujours un nom de domaine complet comme nom d’hôte lorsque vous vous connectez à votre instance de serveur flexible Azure Database pour PostgreSQL. Il n’est pas garanti que l’adresse IP du serveur reste statique. L’utilisation du FQDN vous permet d’éviter d’apporter des modifications à votre chaîne de connexion.

Par exemple, hostname = servername.postgres.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).

Contenu connexe

• portail Azure
• Azure CLI