Partage via

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

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL – Serveur flexible

Cet article décrit les concepts de connectivité et de réseau pour Azure Database pour PostgreSQL - Serveur flexible.

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

  • Accès privé avec intégration de réseau virtuel
  • Accès public (adresses IP autorisées) et le 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é avec intégration de réseau virtuel

Vous pouvez déployer un serveur flexible Azure Database pour PostgreSQL sur 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 dans 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 :

  • Connexion à partir de ressources Azure du même réseau virtuel à votre serveur flexible Azure Database pour PostgreSQL en utilisant des adresses IP privées.
  • Utilisation d’un VPN ou du service Azure ExpressRoute pour vous connecter à partir de ressources non-Azure à votre serveur flexible Azure Database pour PostgreSQL.
  • Garantie que le serveur flexible Azure Database pour PostgreSQL n’a pas de point de terminaison public accessible via Internet.

Diagramme montrant le fonctionnement de l’appairage entre réseaux virtuels, dont l’un comprend un service flexible Azure Database pour PostgreSQL.

Dans le diagramme ci-dessus :

  • Les serveurs flexibles Azure Database pour PostgreSQL sont injectés dans un sous-réseau 10.0.1.0/24 du réseau virtuel VNet-1.
  • Les applications qui sont déployées sur différents sous-réseaux au sein du même réseau virtuel peuvent accéder directement aux serveurs flexibles Azure Database pour PostgreSQL.
  • Les applications qui sont déployées sur un autre réseau virtuel (VNet-2) n’ont pas d’accès direct aux serveurs flexibles Azure Database pour PostgreSQL. Vous devez effectuer un appairage de réseaux virtuels pour une zone DNS privée avant qu’elles puissent accéder au 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 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 dans lesquels les ressources sont intégrées dans le réseau virtuel avec des serveurs flexibles 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 serveur flexible Azure Database pour PostgreSQL intégré au réseau virtuel doit se trouver dans un sous-réseau délégué. Autrement dit, seuls les serveurs flexibles Azure Database pour PostgreSQL peuvent utiliser ce sous-réseau. Aucun autre type de ressource Azure ne peut se trouver dans 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. Un seul serveur flexible Azure Database pour PostgreSQL doté de 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 avec la même plage d’adresses IP de destination que la plage de sous-réseaux du serveur flexible Azure Database pour PostgreSQL et le tronçon suivant 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.

  • Groupe de sécurité réseau (NSG) : les règles de sécurité dans les groupes de sécurité réseau permettent de filtrer le type de trafic réseau qui peut circuler vers et depuis les interfaces réseau et les sous-réseaux de réseau virtuel. 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.

    À ce stade, Azure Database pour PostgreSQL – Serveur flexible ne prend pas en charge les groupes de sécurité réseau dans lesquels un groupe de sécurité d’application fait partie de la règle. 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 d’Azure Database pour PostgreSQL – Serveur flexible nécessitent la capacité à envoyer/recevoir du trafic sur le port de destination 5432 au sein d’un sous-réseau de réseau virtuel Azure où Azure Database pour PostgreSQL – Serveur flexible est déployé, ainsi que sur Stockage Azure pour l’archivage des journaux. Si vous créez des groupes de sécurité réseau (NSG) pour refuser le trafic à destination ou en provenance du serveur flexible Azure Database pour PostgreSQL au sein du sous-réseau sur lequel il est déployé, autorisez le trafic vers le port de destination 5432 au sein du sous-réseau ainsi que vers Stockage en utilisant l’étiquette de service Stockage comme destination.

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

    Lorsque vous configurez des réplicas en lecture à travers des régions Azure, le serveur flexible Azure Database pour PostgreSQL exige la possibilité d’envoyer ou de recevoir du trafic vers le port de destination 5432 pour les serveurs principaux et les réplicas, ainsi que vers le Stockage Azure dans les régions principales et des réplicas, à partir des serveurs principaux et de réplicas. Le port TCP de destination requis pour Stockage est 443.

  • Intégration d’une zone DNS privée : l’intégration d’une 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 appairé dans la 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 l’accès au réseau privé avec un réseau virtuel Azure, la mise à disposition des informations de zone DNS privée est obligatoire pour pouvoir effectuer une résolution DNS. Pour créer un serveur flexible Azure Database pour PostgreSQL en utilisant un accès réseau privé, utilisez des zones DNS privées pour configurer des serveurs flexibles 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 du serveur flexible Azure Database pour PostgreSQL ne sera pas terminé.

Pour créer un nouveau serveur flexible Azure Database pour PostgreSQL en utilisant un accès réseau privé avec une API, un modèle Azure Resource Manager (modèle ARM) ou Terraform, vous devez créer des zones DNS privées. Puis, utilisez ces zones lors de la configuration de serveurs flexibles Azure Database pour PostgreSQL avec accès privé. Pour plus d’informations, consultez Spécifications de l’API REST pour Azure.

Si vous utilisez le portail Azure ou Azure CLI pour créer des serveurs flexibles Azure Database pour PostgreSQL, vous pouvez soit fournir un nom de zone DNS privée que vous avez créé précédemment dans le même abonnement ou un autre abonnement, soit 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 ou Terraform, créez des zones DNS privées qui se terminent par .postgres.database.azure.com. Utilisez ces zones lorsque vous configurez des serveurs flexibles Azure Database pour PostgreSQL avec 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 la forme [name].postgres.database.azure.com, le nom ne peut pas être celui que vous utilisez pour l’un de vos serveurs flexibles Azure Database pour PostgreSQL, sinon un message d’erreur s’affiche lors de l’approvisionnement. Pour plus d’informations, consultez Présentation des zones DNS privées.

Lorsque vous utilisez 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 au moment de créer votre serveur flexible Azure Database pour PostgreSQL vers une autre zone DNS privée du même abonnement ou d’un abonnement différent.

Important

La possibilité de modifier une zone DNS privée de celle vous avez fournie au moment de créer votre serveur flexible Azure Database pour PostgreSQL en 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 lier un réseau virtuel à celle-ci. 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 de serveurs pour Azure Database pour PostgreSQL - Serveur flexible avec mise en réseau privée. Lorsque vous créez un serveur via le portail, nous fournissons au client le choix de créer un lien lors de la création du serveur via la case à cocher Lier la zone de DNS privé à votre réseau virtuel dans le portail 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 FQDN d’Azure Database pour PostgreSQL – Serveur flexible. 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 voulez vous connecter au serveur flexible Azure Database pour PostgreSQL depuis un client approvisionné dans un autre réseau virtuel 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. Le nom de votre zone DNS ne peut pas être le même que celui de votre serveur flexible Azure Database pour PostgreSQL. Sinon, la résolution de noms échoue.

Pour mapper un nom de serveur à l’enregistrement DNS, vous pouvez exécuter la commande nslookup dans Azure Cloud Shell à l’aide d’Azure PowerShell ou de 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 spokes sont directement connectés entre eux : des appairages de réseaux virtuels ou des tunnels VPN sont créés entre les réseaux virtuels spoke pour établir une connectivité directe sans traverser le réseau virtuel hub.
  • Les spokes communiquent sur une appliance réseau : chaque réseau virtuel spoke est appairé à un Virtual WAN ou à un réseau virtuel hub. 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 rattachée au réseau hub et utilise des itinéraires définis par l’utilisateur : permet la communication entre les spokes.

Diagramme montrant l’architecture du réseau en étoile de base avec une connectivité hybride via Express Hub.

Utilisez Azure Virtual Network Manager pour créer des topologies de réseau virtuel en étoile (et intégrer les topologies existantes) pour la gestion centralisée des contrôles de connectivité et 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 dispose d’un serveur flexible Azure Database pour PostgreSQL et l’autre d’un client d’application) qui se trouvent dans différentes régions.

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

  • Appairage global de réseaux virtuels. 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.

Le serveur flexible Azure Database pour PostgreSQL offre deux méthodes de réplication : la réplication physique (c’est-à-dire en streaming) par le biais de la fonctionnalité de réplica en lecture intégrée 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é à travers les limites des réseaux virtuels régionaux. Elle peut être fournie grâce à l’appairage de réseaux virtuels ou dans des architectures de réseau en étoile par le biais d’une appliance réseau.

Par défaut, la résolution de noms DNS est limitée à un réseau virtuel. Aucun client d’un réseau virtuel (VNET1) ne peut résoudre le nom de domaine complet du serveur flexible Azure Database pour PostgreSQL dans un autre réseau virtuel (VNET2).

Pour résoudre ce problème, vous devez vérifier que les clients de VNET1 peuvent accéder à la zone DNS privée du serveur flexible Azure Database pour PostgreSQL. Ajoutez un lien de réseau virtuel à la zone DNS privée de votre 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’un serveur flexible Azure Database pour PostgreSQL est déployé sur un réseau virtuel et un sous-réseau virtuel, vous ne pouvez plus le déplacer vers un autre réseau ou sous-réseau virtuel. 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 voulez utiliser Private Link pour la mise en réseau privée, consultez Mise en réseau du serveur flexible Azure Database pour PostgreSQL avec Private Link.

Important

Azure Resource Manager prend en charge la capacité de verrouiller des ressources en tant que 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 l’un de ces types sur une zone DNS privée ou un jeu d’enregistrements individuel peut entraver la capacité du 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, veillez à ne pas utiliser de verrous d’enregistrement ni de zone DNS privée lorsque vous utilisez des fonctionnalités de haute disponibilité avec le serveur flexible Azure Database pour PostgreSQL.

Nom de l’hôte

Quelle que soit l’option de mise en réseau choisie, nous vous recommandons de toujours utiliser un FQDN comme nom d’hôte lorsque vous vous connectez à votre serveur flexible Azure Database pour PostgreSQL. Il n’est pas garanti que l’adresse IP du serveur reste statique. L’utilisation du nom de domaine complet 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