Meilleures pratiques de configuration du réseau pour les charges de travail migrées vers Azure

Lorsque vous envisagez et concevez un projet de migration, l’une des étapes les plus importantes, au-delà de la migration proprement dite, réside dans la conception et l’implémentation du réseau Azure. Cet article décrit les bonnes pratiques de mise en réseau lorsque vous migrez vers des implémentations IaaS (Infrastructure as a service) et PaaS (Platform as a service ) dans Azure.

Important

Les meilleures pratiques et opinions décrites dans cet article sont basées sur la plateforme Azure et les fonctionnalités disponibles au moment de la rédaction. Les fonctionnalités et les capacités changent au fil du temps. Il est possible que certaines recommandations ne s’appliquent pas à votre déploiement. Par conséquent, choisissez celles qui vous conviennent.

Concevoir des réseaux virtuels

Azure fournit des réseaux virtuels dotés des fonctionnalités suivantes :

  • Les ressources Azure communiquent entre elles en privé, directement et de manière sécurisée via des réseaux virtuels.
  • Vous pouvez configurer des connexions de point de terminaison sur des réseaux virtuels pour les machines virtuelles et les services qui nécessitent une communication Internet.
  • Un réseau virtuel est une isolation logique du cloud Azure qui est dédié à votre abonnement.
  • Vous pouvez implémenter plusieurs réseaux virtuels au sein de chaque abonnement et région Azure.
  • Chaque réseau privé est isolé des autres réseaux virtuels.
  • Les réseaux virtuels peuvent contenir les adresses IP privées et publiques définies dans RFC 1918, exprimées en notation de routage CIDR (Classless InterDomain Routing). Les adresses IP publiques spécifiées dans l’espace d’adressage d’un réseau virtuel ne sont pas directement accessibles à partir d’Internet.
  • Les réseaux virtuels peuvent être connectés entre eux par l’intermédiaire du peering de réseaux virtuels. Les réseaux virtuels connectés peuvent se trouver dans la même région ou dans des régions différentes. Les ressources d’un réseau virtuel peuvent se connecter aux ressources d’autres réseaux virtuels.
  • Par défaut, les routes Azure se chargent de l’acheminement entre les sous-réseaux d’un réseau virtuel, les réseaux virtuels connectés, les réseaux locaux et Internet.

Quand vous planifiez votre topologie de réseau virtuel, vous devez penser à la manière dont organiser les espaces d’adressage IP, implémenter une topologie de réseau hub-and-spoke, segmenter les réseaux virtuels en sous-réseaux tout en configurant un serveur DNS et en implémentant les Zones de disponibilité Azure.

Bonne pratique : Planifier l’adressage IP

Lorsque vous créez des réseaux virtuels dans le cadre de votre migration, il est important de planifier l’espace d’adressage IP de vos réseaux virtuels.

Pour chaque réseau virtuel, vous devez attribuer un espace d’adressage qui ne dépasse pas une plage CIDR de /16. Les réseaux virtuels permettent l’utilisation de 65 536 adresses IP. Si vous attribuez un préfixe inférieur à /16, par exemple /15, qui comporte 131 072 adresses, vous ne pouvez pas utiliser ailleurs les adresses IP excédentaires. Il est important de ne pas gaspiller les adresses IP, même si elles se trouvent dans les plages privées définies par la RFC 1918.

Voici d’autres conseils pour la planification :

  • L’espace d’adressage de réseaux virtuels ne doit pas chevaucher les plages du réseau local.
  • Le chevauchement des adresses peut être à l’origine de problèmes de connexion aux réseaux et de dysfonctionnement du routage.
  • Si des réseaux se chevauchent, vous devez reconcevoir le réseau.
  • Si vous ne pouvez absolument pas reconcevoir le réseau, la traduction d’adresses réseau (NAT) peut être utile, mais doit être évitée ou limitée autant que possible.

En savoir plus :

Bonne pratique : Implémenter une topologie de réseau hub-and-spoke

Une topologie de réseau hub-and-spoke isole des charges de travail tout en partageant des services, tels que l’identité et la sécurité. Le hub est un réseau virtuel Azure qui agit comme point central de connectivité. Les spokes sont des réseaux virtuels qui se connectent au réseau virtuel du hub au moyen d’un appairage. Les services partagés sont déployés dans le hub, tandis que les charges de travail individuelles sont déployées en tant que rayons.

Tenez compte des éléments suivants :

  • L’implémentation d’une topologie hub-and-spoke dans Azure permet de centraliser les services communs, tels que les connexions à des réseaux locaux, les pare-feu et l’isolation entre les réseaux virtuels. Le réseau virtuel du hub fournit un point central de connectivité aux réseaux locaux, et offre un emplacement pour héberger des services utilisés par les charges de travail qui sont hébergées dans les réseaux virtuels spokes.
  • La configuration hub-and-spoke est généralement utilisée par les grandes entreprises. Les réseaux plus modestes peuvent envisager une conception plus simple pour économiser sur les coûts et la complexité.
  • Vous pouvez utiliser les réseaux virtuels spokes pour isoler les charges de travail, chaque spoke étant géré séparément des autres spokes. Chaque charge de travail peut inclure plusieurs niveaux, avec plusieurs sous-réseaux connectés à l’aide d’équilibreurs de charge Azure.
  • Vous pouvez implémenter les réseaux virtuels hub-and-spoke dans des groupes de ressources différents, voire dans des abonnements différents. Quand vous appairez des réseaux virtuels de différents abonnements, les abonnements peuvent être associés au même locataire Azure Active Directory (Azure AD) ou à un locataire différent. Cela permet de décentraliser la gestion de chaque charge de travail, tout en partageant les services gérés dans le réseau hub.

Diagramme de la topologie hub-and-spoke Figure 1 : topologie hub-and-spoke.

En savoir plus :

Bonne pratique : conception des sous-réseaux

Pour garantir une forme d’isolation à l’intérieur d’un réseau virtuel, vous devez le segmenter en un ou plusieurs sous-réseaux et allouer une partie de l’espace d’adressage du réseau virtuel à chaque sous-réseau.

  • Vous pouvez créer plusieurs sous-réseaux au sein de chaque réseau virtuel.
  • Par défaut, Azure achemine le trafic réseau entre tous les sous-réseaux d’un réseau virtuel.
  • Vos décisions en matière de sous-réseau dépendent de vos exigences techniques et organisationnelles.
  • Vous devez utiliser la notation CIDR pour créer des sous-réseaux.

Lorsque vous décidez de la plage réseau de vos sous-réseaux, tenez compte du fait qu’Azure conserve cinq adresses IP de chaque sous-réseau qu’il n’est pas possible d’utiliser. Par exemple, si vous créez le plus petit sous-réseau disponible de /29 (avec huit adresses IP), Azure conservera cinq adresses. Dans ce cas, vous ne disposez que de trois adresses utilisables pouvant être attribuées aux hôtes sur le sous-réseau. Dans la plupart des cas, utilisez /28 comme plus petit sous-réseau.

Exemple :

Le tableau présente un exemple de réseau virtuel doté d’un espace d’adressage de 10.245.16.0/20 segmenté en sous-réseaux, dans le cadre d’une migration planifiée.

Subnet CIDR Adresses Usage
DEV-FE-EUS2 10.245.16.0/22 1019 Machines virtuelles front-end ou de couche web
DEV-APP-EUS2 10.245.20.0/22 1019 Machines virtuelles de couche Application
DEV-DB-EUS2 10.245.24.0/23 507 Machines virtuelles de base de données

En savoir plus :

Bonne pratique : sélection d’un serveur DNS

Azure ajoute par défaut un serveur DNS lorsque vous déployez un réseau virtuel. Cela vous permet de créer des réseaux virtuels et de déployer des ressources rapidement. Toutefois, ce serveur DNS fournit uniquement des services aux ressources qui se trouvent sur ce réseau virtuel. Si vous souhaitez connecter plusieurs réseaux virtuels entre eux, ou vous connecter à un serveur local à partir de réseaux virtuels, vous avez besoin de fonctionnalités de résolution de noms supplémentaires. Par exemple, vous devrez peut-être utiliser Active Directory pour résoudre les noms DNS entre des réseaux virtuels. Pour ce faire, vous devez déployer votre propre serveur DNS personnalisé dans Azure.

  • Les serveurs DNS d’un réseau virtuel peuvent transférer des requêtes DNS vers le programme de résolution récursive dans Azure. Cela vous permet de résoudre les noms d’hôte au sein de ce réseau virtuel. Par exemple, un contrôleur de domaine qui s’exécute dans Azure peut répondre aux requêtes DNS concernant ses propres domaines, et transférer toutes les autres requêtes vers Azure.

  • Le transfert DNS permet aux machines virtuelles de voir vos ressources locales (par le biais du contrôleur de domaine) et les noms d’hôte fournis par Azure (à l’aide du redirecteur). Vous pouvez accéder aux programmes de résolution récursifs dans Azure au moyen de l’adresse IP virtuelle 168.63.129.16.

  • Le transfert DNS permet aussi la résolution DNS entre réseaux virtuels, et offre la possibilité à vos machines locales de résoudre les noms d’hôte fournis par Azure.

    • Pour résoudre le nom d’hôte d’une machine virtuelle, la machine virtuelle du serveur DNS doit résider dans le même réseau virtuel et être configurée pour rediriger les requêtes de nom d’hôte vers Azure.
    • Comme le suffixe DNS est différent dans chaque réseau virtuel, vous pouvez utiliser des règles de redirection conditionnelles pour envoyer les requêtes DNS au réseau virtuel approprié en vue de la résolution.
  • Lorsque vous utilisez vos propres serveurs DNS, vous pouvez spécifier plusieurs serveurs DNS pour chaque réseau virtuel. Vous pouvez également spécifier plusieurs serveurs DNS par interface réseau (pour Azure Resource Manager) ou par service cloud (pour le modèle de déploiement classique).

  • Les serveurs DNS spécifiés pour une interface réseau ou un service cloud ont la priorité sur les serveurs DNS spécifiés pour le réseau virtuel.

  • Dans Azure Resource Manager, vous pouvez spécifier des serveurs DNS pour un réseau virtuel et une interface réseau, mais la bonne pratique consiste à utiliser le paramètre uniquement sur les réseaux virtuels.

    Capture d’écran des serveurs DNS d’un réseau virtuel. Figure 2 : Serveurs DNS d’un réseau virtuel.

En savoir plus :

Bonne pratique : Configurer des Zones de disponibilité

Les Zones de disponibilité augmentent la haute disponibilité de manière à protéger les applications et les données contre les défaillances de centre de données. Les Zones de disponibilité sont des emplacements physiques uniques au sein d’une région Azure. Chaque zone de disponibilité est composée d’un ou de plusieurs centres de données équipés d’une alimentation, d’un système de refroidissement et d’un réseau indépendants. Pour garantir la résilience, un minimum de trois zones distinctes sont activées dans toutes les régions. La séparation physique des Zones de disponibilité dans une région protège les applications et les données des défaillances dans le centre de données.

Voici quelques points supplémentaires à prendre en compte lorsque vous configurez des zones de disponibilité :

  • Les services redondants interzone répliquent vos applications et vos données entre des Zones de disponibilité pour les protéger contre des points de défaillance uniques.

  • Avec les zones de disponibilité, Azure propose des contrats de niveau de service qui garantissent une durée de bon fonctionnement des machines virtuelles de 99,99 %.

    Diagramme de zones de disponibilité au sein d’une région Azure.

    Figure 3 : Zones de disponibilité.

  • Vous pouvez planifier et générer une haute disponibilité dans votre architecture de migration par la colocalisation de vos ressources de calcul, de stockage, de mise en réseau et de données dans une zone et une réplication de ces ressources dans d’autres zones. Les services Azure qui prennent en charge les Zones de disponibilité sont classés en deux catégories :

    • Services zonaux : Vous associez une ressource à une zone spécifique, comme des machines virtuelles, des disques managés ou des adresses IP.
    • Services redondants interzone : La ressource est répliquée automatiquement entre les zones, comme le stockage redondant interzone ou Azure SQL Database.
  • Pour assurer une tolérance de panne zonale, vous pouvez déployer une instance Azure Load Balancer standard avec les couches Application ou les charges de travail sur Internet.

    Diagramme d’un équilibreur de charge Azure standard Figure 4 : équilibreur de charge.

En savoir plus :

Conception d’une mise en réseau de cloud hybride

Pour une migration réussie, il est essentiel de connecter les réseaux d’entreprise locaux à Azure. Ceci permet de créer une connexion permanente, appelée réseau de cloud hybride, dans laquelle les services sont fournis aux utilisateurs de l’entreprise depuis le cloud Azure. Il existe deux manières de créer ce type de réseau :

  • VPN de site à site : la connexion VPN de site à site est établie entre votre appareil VPN local compatible et une passerelle VPN Azure déployée dans un réseau virtuel. Les ressources locales autorisées peuvent alors accéder aux réseaux virtuels. Les communications de site à site sont envoyées via un tunnel chiffré sur Internet.
  • Azure ExpressRoute : la connexion Azure ExpressRoute est établie entre votre réseau local et Azure via un partenaire ExpressRoute. Cette connexion est privée et le trafic ne passe par Internet.

En savoir plus :

Bonne pratique : implémentation d’un VPN de site à site à haute disponibilité

Pour implémenter un VPN de site à site, vous devez configurer une passerelle VPN dans Azure.

  • Une passerelle VPN est un type spécifique de passerelle de réseau virtuel. Elle envoie du trafic chiffré entre un réseau virtuel Azure et un emplacement local via l’Internet public.
  • Une passerelle VPN peut également envoyer du trafic chiffré entre les réseaux virtuels dans Azure sur le réseau Microsoft.
  • Chaque réseau virtuel ne peut posséder qu’une seule passerelle VPN.
  • Vous pouvez créer plusieurs connexions à la même passerelle VPN. Lorsque vous créez plusieurs connexions, tous les tunnels VPN partagent la bande passante de passerelle disponible.

Chaque passerelle VPN Azure comprend deux instances dans une configuration de type actif/passif :

  • En cas de maintenance planifiée ou d’interruption non planifiée au niveau de l’instance active, le basculement se produit et l’instance de secours prend automatiquement le relais. Cette instance reprend la connexion site à site ou réseau à réseau.
  • Le basculement entraîne une brève interruption.
  • Dans le cadre d’une maintenance planifiée, la connectivité doit être restaurée dans les 10 à 15 secondes.
  • En cas de problèmes non planifiés, la récupération de la connexion est plus longue et peut atteindre 1 min 30 sec dans le pire des cas.
  • Les connexions client VPN point à site vers la passerelle sont interrompues et les utilisateurs doivent se reconnecter à partir des machines clientes.

Lors de la configuration d’une connexion VPN site à site :

  • Vous avez besoin d’un réseau virtuel dont la plage d’adresses ne chevauche pas le réseau local auquel se connecte le VPN.
  • Vous devez créer un sous-réseau de passerelle dans le réseau.
  • Vous devez créer une passerelle VPN, spécifier le type de passerelle (VPN) et indiquer si la passerelle est basée sur un routage ou sur une stratégie. Un VPN basé sur le routage est considéré comme ayant de meilleures capacités et comme étant plus durable.
  • Vous devez créer une passerelle de réseau local en local et configurer votre appareil VPN local.
  • Vous devez créer une connexion VPN de site à site pour le basculement entre la passerelle de réseau virtuel et l’appareil en local. L’utilisation d’un VPN basé sur un routage autorise les connexions actif/passif ou actif/actif vers Azure. L’option par routage prend aussi en charge simultanément les connexions site à site (depuis n’importe quel ordinateur) et point à site (depuis un seul ordinateur).
  • Vous devez spécifier la référence SKU de la passerelle que vous souhaitez utiliser. Cela dépend de vos exigences en matière de charge de travail, de votre débit, de vos fonctionnalités et de vos contrats de niveau de service (SLA).
  • Le protocole BGP (Border Gateway Protocol) est une fonctionnalité facultative. Vous pouvez l’utiliser avec Azure ExpressRoute et vos passerelles VPN basées sur le routage pour propager vos routes BGP locales sur vos réseaux virtuels.

Diagramme de réseau VPN site à site. Figure 5 : réseau VPN site à site.

En savoir plus :

Bonne pratique : Configuration d’une passerelle pour les passerelles VPN

Lorsque vous créez une passerelle VPN dans Azure, vous devez utiliser un sous-réseau spécial nommé GatewaySubnet. Lorsque vous créez ce sous-réseau, tenez compte de ces bonnes pratiques :

  • GatewaySubnet peut avoir une longueur de préfixe maximale de 29 (par exemple, 10.119.255.248/29). Il est actuellement recommandé d’utiliser une longueur de préfixe de 27 (par exemple, 10.119.255.224/27).
  • Lorsque vous définissez l’espace d’adressage du sous-réseau de passerelle, utilisez la toute dernière partie de l’espace d’adressage des réseaux virtuels.
  • Lorsque vous utilisez le sous-réseau de passerelle Azure, ne déployez jamais vos machines virtuelles ou d’autres appareils, tels qu’Azure Application Gateway, sur le sous-réseau de passerelle.
  • N’affectez pas de groupe de sécurité réseau (NSG) à ce sous-réseau. Cela entraînerait une interruption de la passerelle.

Bonne pratique : implémentation d’Azure Virtual WAN pour les succursales

Dans le cas de plusieurs connexions VPN, le service réseau Azure Virtual WAN offre une connectivité de branche à branche optimisée et automatisée via Azure.

  • Virtual WAN vous permet de vous connecter et de configurer des appareils de branche pour communiquer avec Azure. Vous pouvez effectuer cette opération manuellement ou à l’aide d’appareils du fournisseur de votre choix, via un partenaire Azure Virtual WAN.
  • L’utilisation d’appareils de fournisseur permet une utilisation facile, une meilleure connectivité et une bonne gestion de la configuration.
  • Le tableau de bord intégré Azure Virtual WAN fournit des informations de dépannage en temps réel qui peuvent vous faire gagner du temps et vous permettre de suivre sans peine la connectivité de site à site, à grande échelle.

En savoir plus : En savoir plus sur Azure Virtual WAN.

Bonne pratique : Implémentation d’ExpressRoute pour les connexions stratégiques

Le service Azure ExpressRoute étend votre infrastructure locale dans le cloud Microsoft en créant des connexions privées entre le centre de données virtuel Azure et des réseaux locaux. Voici quelques détails de l’implémentation :

  • Les connexions ExpressRoute peuvent être établies sur un réseau universel (VPN IP), sur un réseau Ethernet point à point, ou via un fournisseur de connectivité. Elles ne transitent pas par l’Internet public.
  • Les connexions ExpressRoute offrent une sécurité, une fiabilité et des vitesses supérieures (allant jusqu’à 10 Gbits/s), avec une latence constante.
  • Le service ExpressRoute se révèle d’une grande utilité pour les centres de données virtuels, car les clients ExpressRoute peuvent bénéficier des règles de conformité associées aux connexions privées.
  • Avec ExpressRoute Direct, vous pouvez vous connecter directement aux routeurs Microsoft à 100 Gbits/s si vous avez besoin d’une plus grande quantité de bande passante.
  • ExpressRoute utilise le protocole BGP pour échanger des itinéraires entre des réseaux locaux, les instances Azure et les adresses publiques Microsoft.

Le déploiement de connexions ExpressRoute implique généralement la souscription d’un engagement auprès d’un fournisseur de services ExpressRoute. Pour un démarrage rapide, il est courant de commencer par utiliser un VPN site à site pour établir la connectivité entre le centre de données virtuel et les ressources locales. Ensuite, vous migrez vers une connexion ExpressRoute quand une interconnexion physique avec votre fournisseur de services est établie.

En savoir plus :

Bonne pratique : optimisation du routage ExpressRoute avec les communautés BGP

En présence de plusieurs circuits ExpressRoute, vous pouvez vous connecter à Microsoft par le biais de plusieurs chemins d’accès. Par conséquent, le routage peut ne pas être optimal et votre trafic peut emprunter un chemin d’accès plus long pour atteindre Microsoft ; Microsoft peut faire de même pour atteindre votre réseau. Plus le chemin d’accès réseau est long, plus la latence est élevée. La latence affecte directement les performances d’application ainsi que l’expérience utilisateur.

Exemple :

Examinons un exemple :

  • Vous disposez de deux bureaux aux États-Unis, un à Los Angeles et un à New York.
  • Vos bureaux sont connectés sur un réseau étendu, qui peut être votre propre réseau principal ou le VPN IP de votre fournisseur de services.
  • Vous avez deux circuits ExpressRoute, l’un dans la région West US et l’autre dans la région East US, également connectés sur le WAN. Vous avez bien évidemment deux chemins d’accès pour vous connecter au réseau Microsoft.

Problème :

Imaginez à présent que vous ayez déployé un service Azure (par exemple, Azure App Service) dans les régions West US et East US.

  • Vous souhaitez que les utilisateurs de chaque bureau puissent accéder aux services Azure les plus proches pour bénéficier d’une expérience optimale.
  • Vous voulez donc connecter les utilisateurs de Los Angeles à la région Azure West US, et les utilisateurs de New York à la région Azure East US.
  • Cela fonctionne pour les utilisateurs de la côte Est, mais pas pour ceux résidant sur la côte Ouest. Le problème est le suivant :
    • Sur chaque circuit ExpressRoute, nous publions les préfixes dans la région Azure East US(23.100.0.0/16) et dans la région Azure West US (13.100.0.0/16).
    • Sans connaître le préfixe associé à chaque région, les préfixes ne sont pas traités de manière différente.
    • Votre réseau WAN peut supposer que les deux préfixes sont plus proches de la région East US que de la région West US, et donc acheminer les utilisateurs des deux bureaux vers le circuit ExpressRoute de la région East US. L’expérience des utilisateurs du bureau de Los Angeles s’en trouve détériorée.

Diagramme du VPN avec un chemin de routage passant par un circuit incorrect. Figure 6 : connexion non optimisée des communautés BGP.

Solution :

Pour optimiser le routage des deux bureaux, vous devez savoir faire la différence entre le préfixe de la région Azure West US et celui de la région Azure East US. Vous pouvez encoder ces informations à l’aide des valeurs de communauté BGP.

  • Vous affectez une valeur de communauté BGP unique à chaque région Azure. Par exemple, 12076:51004 pour East US; 12076:51006 pour West US.
  • Maintenant que vous savez quel préfixe est associé à chaque région Azure, vous pouvez configurer un circuit ExpressRoute préférentiel.
  • Étant donné que vous utilisez le protocole BGP pour échanger des informations de routage, vous pouvez utiliser les préférences locales du protocole BGP pour influencer le routage.
  • Dans notre exemple, vous attribuez une valeur de préférence locale supérieure à 13.100.0.0/16 dans la région West US par rapport à la région East US. De même, vous attribuez une valeur de préférence locale supérieure à 23.100.0.0/16 dans la région East US par rapport à la région West US.
  • Avec cette configuration, dès lors que les deux chemins à Microsoft sont disponibles, les utilisateurs de Los Angeles se connecteront à la région West US en empruntant le circuit de l’ouest, et les utilisateurs de New York se connecteront à la région East US en suivant le circuit de l’est.

Diagramme de VPN avec un chemin de routage passant par un circuit correct. Figure 7 : connexion optimisée des communautés BGP.

En savoir plus :

Sécuriser les réseaux virtuels

Microsoft partage avec vous la responsabilité de la sécurisation des réseaux virtuels. Microsoft fournit de nombreuses fonctionnalités de mise en réseau, ainsi que des services conçus pour aider à sécuriser les ressources. Lorsque vous concevez la sécurité de réseaux virtuels, il est préférable d’implémenter un réseau de périmètre, d’utiliser le filtrage et les groupes de sécurité, de sécuriser l’accès aux ressources et aux adresses IP, et d’implémenter un mécanisme de protection contre les attaques.

En savoir plus :

Bonne pratique : implémentation d’un réseau de périmètre Azure

Bien que Microsoft investisse fortement dans la protection de l’infrastructure cloud, vous devez également protéger vos services cloud et vos groupes de ressources. Une approche multicouche de la sécurité constitue la meilleure défense. La mise en place d’un réseau de périmètre constitue une partie importante de cette stratégie de défense.

  • Un réseau de périmètre protège les ressources réseau internes d’un réseau non approuvé.
  • Il représente la couche la plus éloignée exposée à Internet. Il se situe généralement entre Internet et l’infrastructure d’entreprise, avec généralement une certaine forme de protection des deux côtés.
  • Dans une topologie de réseau d’entreprise classique, l’infrastructure centrale est puissamment fortifiée sur les périmètres, avec plusieurs couches d’appareils de sécurité. La limite de chaque couche se compose d’appareils et de points d’application de stratégies.
  • Chaque couche peut comporter une combinaison de solutions de sécurité réseau, telles que des pare-feu, la prévention DoS (Denial of Service), des systèmes IDS (détection d’intrusion) / IPS (protection contre les intrusions) et des appareils VPN.
  • L’application de stratégies sur le réseau de périmètre peut prendre la forme de stratégies de pare-feu, de listes de contrôle d’accès (ACL) ou de routage spécifique.
  • À mesure que le trafic entrant arrive par Internet, il est intercepté et géré par diverses solutions de défense combinées. Les solutions bloquent les attaques et le trafic dangereux, tout en autorisant les demandes légitimes d’accès au réseau.
  • Le trafic entrant peut être directement acheminé vers les ressources du réseau de périmètre. La ressource du réseau de périmètre peut ensuite communiquer davantage avec les autres ressources du réseau, en autorisant le trafic dans le réseau après validation.

Voici un exemple de réseau de périmètre à sous-réseau unique dans un réseau d’entreprise, avec deux limites de sécurité.

Diagramme de déploiement d’un réseau de périmètre de réseau virtuel Azure. Figure 8 : déploiement d’un réseau de périmètre.

En savoir plus :

Bonne pratique : filtrage du trafic de réseau virtuel avec des groupes de sécurité réseau

Les groupes de sécurité réseau (NSG) contiennent plusieurs règles de sécurité de trafic entrant et sortant qui filtrent la circulation entre les ressources. Le filtrage peut se faire par source et par adresse IP de destination, par port et par protocole.

  • Les groupes de sécurité réseau contiennent des règles de sécurité qui autorisent ou refusent le trafic réseau entrant ou sortant en direction/à partir des différents types de ressources Azure. Pour chaque règle, vous pouvez spécifier la source et la destination, le port et le protocole.
  • Les règles des groupes de sécurité réseau sont évaluées par priorité, selon un tuple à cinq éléments (source, port source, destination, port de destination et protocole), pour autoriser ou refuser le trafic.
  • Un enregistrement de flux est créé pour les connexions existantes. La communication est autorisée ou refusée en fonction de l’état de connexion de l’enregistrement de flux.
  • Un enregistrement de flux permet de configurer un groupe de sécurité réseau avec état. Par exemple, si vous spécifiez une règle de sécurité sortante vers n’importe quelle adresse sur le port 80, il n’est pas nécessaire d’indiquer une règle de sécurité entrante pour la réponse au trafic sortant. Vous devez uniquement spécifier une règle de sécurité entrante si la communication est établie en externe.
  • Le contraire est également vrai. Si le trafic entrant est autorisé sur un port, vous n’avez pas lieu de spécifier une règle de sécurité sortante pour répondre au trafic sur ce port.
  • Les connexions existantes ne sont pas interrompues quand vous supprimez une règle de sécurité ayant activé le flux. Les flux de trafic sont interrompus quand les connexions sont arrêtées et qu’aucun trafic ne transite dans un sens ou dans l’autre pendant au moins quelques minutes.
  • Lorsque vous créez des groupes de sécurité réseau, créez-en aussi peu que possible, mais autant que nécessaire.

Bonne pratique : sécurisation du trafic nord/sud et est/ouest

Pour sécuriser les réseaux virtuels, prenez en compte les vecteurs d’attaque. Notez les points suivants :

  • L’utilisation seule de groupes de sécurité réseau simplifie votre environnement, mais sécurise uniquement le trafic sur votre sous-réseau. C’est ce que l’on appelle le trafic nord/sud.
  • Le trafic entre des machines virtuelles sur le même sous-réseau est appelé « trafic est/ouest ».
  • Il est important d’utiliser les deux formes de protection, de sorte que si un pirate parvient à accéder au trafic de l’extérieur, il puisse être intercepté lorsqu’il tente de se connecter à des machines situées dans le même sous-réseau.

Utiliser des balises de service sur les groupes de sécurité réseau

Une balise de service représente un groupe de préfixes d’adresses IP. L’utilisation d’une balise de service permet de réduire la complexité associée à la création de règles de groupes de sécurité réseau.

  • Vous pouvez utiliser des balises de service à la place des adresses IP spécifiques lorsque vous créez des règles.
  • Microsoft gère les préfixes d’adresse associés à une balise de service et met à jour automatiquement la balise de service quand les adresses changent.
  • Vous ne pouvez pas créer votre propre balise de service, ni spécifier les adresses IP incluses dans une balise.

Les balises de service permettent d’automatiser l’attribution d’une règle à des groupes de services Azure. Par exemple, si vous souhaitez autoriser un sous-réseau dans lequel des serveurs web accèdent à une base de données Microsoft Azure SQL Database, vous pouvez créer une règle de trafic sortant sur le port 1433 et utiliser la balise de service Sql.

  • Cette balise Sql désigne les préfixes d’adresses des services Azure SQL Database et Azure SQL Data Warehouse.
  • Si vous spécifiez Sql comme valeur, le trafic vers SQL est autorisé ou refusé.
  • Si vous souhaitez uniquement autoriser l’accès à Sql dans une région spécifique, vous pouvez préciser cette région. Par exemple, si vous souhaitez autoriser l’accès à Azure SQL Database uniquement dans la région USA Est, vous pouvez spécifier Sql.EastUS comme balise de service.
  • La balise représente le service, mais pas des instances du service. Par exemple, la balise représente le service Azure SQL Database, mais pas une base de données ou un serveur SQL spécifique.
  • Tous les préfixes d’adresse représentés par cette balise sont également représentés par la balise Internet.

En savoir plus :

Bonne pratique : utilisation de groupes de sécurité d’application

Les groupes de sécurité d’application vous permettent de configurer la sécurité réseau comme le prolongement naturel d’une structure d’application.

  • Vous pouvez regrouper des machines virtuelles et définir des stratégies de sécurité réseau basés sur des groupes de sécurité d’application.
  • Les groupes de sécurité d’application vous permettent de réutiliser votre stratégie de sécurité à grande échelle, sans maintenance manuelle d’adresses IP explicites.
  • Les groupes de sécurité réseau gèrent la complexité des adresses IP explicites et plusieurs ensembles de règles, ce qui vous permet de vous concentrer sur la logique métier.

Exemple :

Diagramme d’un exemple de groupe de sécurité d’application. Figure 9 : exemple de groupe de sécurité d’application.

interface réseau Groupe de sécurité d’application
NIC1 AsgWeb
NIC2 AsgWeb
NIC3 AsgLogic
NIC4 AsgDb

Dans notre exemple, chaque interface réseau appartient à un seul groupe de sécurité d’application, mais une interface peut en réalité appartenir à plusieurs groupes, dans les limites imposées par Azure. Aucune de ces interfaces réseau ne dispose d’un groupe de sécurité réseau associé. NSG1 est associé aux deux sous-réseaux, et contient les règles suivantes :

Nom de la règle Objectif Détails
Allow-HTTP-Inbound-Internet Autoriser le trafic internet vers les serveurs web. Le trafic entrant en provenance d’internet est refusé par la règle de sécurité par défaut DenyAllInbound, donc aucune règle supplémentaire n’est nécessaire pour les groupes de sécurité d’application AsgLogic ou AsgDb. Priorité : 100

Source : internet

Port source : *

Destination : AsgWeb

Port de destination : 80

Protocole : TCP

Accès : Allow
Deny-Database-All La règle de sécurité par défaut AllowVNetInBound autorise toutes les communications entre les ressources du même réseau virtuel. Cette règle est nécessaire pour refuser le trafic de toutes les ressources. Priorité : 120

Source : *

Port source : *

Destination : AsgDb

Port de destination : 1433

Protocole : All

Accès : Deny
Allow-Database-BusinessLogic Autoriser le trafic du groupe de sécurité d’application AsgLogic vers le groupe de sécurité d’application AsgDb. Cette règle étant prioritaire par rapport à la règle Deny-Database-All, elle est traitée en premier. Par conséquent, le trafic en provenance du groupe de sécurité d’application AsgLogic est autorisé et tout le trafic restant est bloqué. Priorité : 110

Source : AsgLogic

Port source : *

Destination : AsgDb

Port de destination : 1433

Protocole : TCP

Accès : Allow

Les règles spécifiant un groupe de sécurité d’application en tant que source ou destination sont appliquées uniquement aux interfaces réseau qui sont membres du groupe de sécurité d’application. Si l’interface réseau n’est pas membre d’un groupe de sécurité d’application, la règle n’est pas appliquée à l’interface réseau, même si le groupe de sécurité réseau est associé au sous-réseau.

En savoir plus :

Bonne pratique : sécurisation de l’accès à PaaS en utilisant des points de terminaison de service de réseau virtuel

Les points de terminaison de service de réseau virtuel étendent l’espace d’adressage IP privé et l’identité de votre réseau virtuel aux services via une connexion directe.

  • Les points de terminaison vous permettent de sécuriser des ressources de service Azure critiques pour vos réseaux virtuels uniquement. Le trafic allant de votre réseau virtuel au service Azure demeure toujours sur le réseau principal Azure.
  • L’espace d’adressage privé du réseau virtuel peut se recouper, et ne permet donc pas d’identifier de façon unique le trafic en provenance d’un réseau virtuel.
  • Après avoir activé les points de terminaison de service dans votre réseau virtuel, vous pouvez sécuriser les ressources du service Azure en ajoutant une règle de réseau virtuel aux ressources du service. Ainsi, votre sécurité est améliorée grâce à la suppression complète de l’accès Internet public aux ressources, et à l’autorisation du trafic uniquement à partir de votre réseau virtuel.

Diagramme des points de terminaison de service. Figure 10 : Points de terminaison de service.

En savoir plus :

Bonne pratique : contrôle des adresses IP publiques

Les adresses IP publiques dans Azure peuvent être associées à des machines virtuelles, à des équilibreurs de charge, à des passerelles d’application et à des passerelles VPN.

  • Les adresses IP publiques permettent aux ressources Internet de communiquer avec les ressources Azure et aux ressources Azure de communiquer avec Internet.
  • Les adresses IP publiques sont créées à l’aide d’une référence SKU De base ou Standard. Les références SKU Standard peut être affectées à n’importe quel service, mais elles sont généralement configurées sur des machines virtuelles, des équilibreurs de charge et des passerelles applicatives.
  • Dans le cas d’une adresse IP publique De base, aucun groupe de sécurité réseau n’est configuré automatiquement. Vous devez configurer votre propre groupe, et affecter des règles pour en contrôler l’accès. Les adresses IP standard se voient attribuer par défaut un groupe de sécurité réseau et des règles.
  • Les meilleures pratiques consistent à ne pas configurer de machines virtuelles avec une adresse IP publique.
    • Si vous avez besoin d’un port ouvert, utilisez de préférence les ports dédiés aux services web, tels que les ports 80 ou 443.
    • L’accès aux ports de gestion à distance standard, tels que SSH (22) et RDP (3389), de même que tous les autres ports, doit être refusé par le biais des groupes de sécurité réseau.
  • L’idéal est de placer les machines virtuelles derrière Azure Load Balancer ou Azure Application Gateway. Si vous avez par la suite besoin d’un accès aux ports de gestion à distance, vous pouvez utiliser un accès juste-à-temps aux machines virtuelles dans Azure Security Center.

En savoir plus :

Tirer parti des fonctionnalités de sécurité Azure pour la mise en réseau

Azure offre des fonctionnalités de sécurité au niveau de la plateforme, notamment le Pare-feu Azure, Azure Web Application Firewall (WAF) et Network Watcher.

Bonne pratique : déploiement du Pare-feu Azure

Le pare-feu Azure est un service de sécurité réseau, informatique et managé qui permet de protéger vos ressources de réseau virtuel. Il s’agit d’un pare-feu managé, avec état intégral, doté d’une haute disponibilité intégrée et d’une scalabilité illimitée dans le cloud.

Diagramme du pare-feu Azure. Figure 11 : Pare-feu Azure.

Voici quelques points à prendre en compte si vous déployez le service :

  • Le pare-feu Azure peut créer, appliquer et consigner des stratégies de connectivité réseau et d’application de façon centralisée entre les abonnements et les réseaux virtuels.
  • Le service Pare-feu Azure utilise une adresse IP publique, statique pour vos ressources de réseau virtuel. Les pare-feu externes peuvent ainsi identifier le trafic provenant de votre réseau virtuel.
  • Le Pare-feu Azure est totalement intégré à Azure Monitor pour la journalisation et les analyses.
  • Lorsque vous créez des règles de pare-feu Azure, il est préférable d’utiliser les étiquettes de nom de domaine complet (FQDN).
    • Une balise FQDN représente un groupe de noms de domaine complets (FQDN) associés à des services Microsoft bien connus.
    • Vous pouvez utiliser une balise FQDN pour autoriser le trafic sortant requis via votre pare-feu.
  • Par exemple, pour autoriser manuellement le trafic Windows Update via votre pare-feu, vous devez créer plusieurs règles d’application. En vous servant des étiquettes de nom de domaine complet, vous pouvez créer une règle d’application, et inclure l’étiquette Windows Update. Avec cette règle en place, le trafic réseau acheminé vers les points de terminaison Microsoft Windows Update peut traverser votre pare-feu.

En savoir plus :

Bonne pratique : déploiement du pare-feu d’applications web

Les applications Web sont de plus en plus la cible d’attaques malveillantes qui exploitent des vulnérabilités connues. L’injection de code SQL et les attaques de script site à site (XSS) sont des exemples d’attaques courantes. Empêcher ces attaques dans le code d’application peut se révéler difficile et nécessiter une maintenance rigoureuse, des mises à jour correctives ainsi que la supervision à différentes couches de la topologie de l’application.

Fonctionnalité d’Azure Application Gateway, le pare-feu d’applications web (WAF) facilite grandement la gestion de la sécurité, et permet aux administrateurs de l’application de se prémunir contre les menaces ou les intrusions. Vous pouvez réagir plus rapidement à une menace de sécurité en corrigeant des vulnérabilités connues dans un emplacement central, plutôt que de sécuriser individuellement les applications web. Vous pouvez facilement convertir les passerelles d’application existantes en Application Gateway qui est activé pour le pare-feu d’applications web.

Voici quelques remarques supplémentaires sur WAF :

  • WAF protège de manière centralisée vos applications web contre les vulnérabilités et attaques courantes.
  • Vous n’avez pas besoin de modifier votre code pour utiliser WAF.
  • Il peut protéger plusieurs applications web en même temps, derrière Application Gateway.
  • WAF est intégré avec Azure Security Center.
  • Vous pouvez personnaliser les règles de pare-feu d’applications web et les groupes de règles en fonction des besoins de votre application.
  • En tant que bonne pratique, il est recommandé d’utiliser un pare-feu d’applications web face aux applications accessibles sur le web, y compris les applications hébergées sur des machines virtuelles Azure ou dans Azure App Service.

En savoir plus :

Meilleure pratique : implémentation de Network Watcher

Network Watcher fournit des outils permettant de superviser les ressources et les communications dans un réseau virtuel Azure. Par exemple, vous pouvez surveiller les communications entre une machine virtuelle et un point de terminaison, tel qu’une autre machine virtuelle ou un nom de domaine complet. Vous pouvez également afficher les ressources et les relations des ressources dans un réseau virtuel, ou diagnostiquer les problèmes de trafic réseau.

Capture d’écran d’Azure Network Watcher.

Capture d’écran de Network Watcher. Figure 12 : Network Watcher.

Voici quelques informations supplémentaires :

  • Network Watcher vous permet de superviser et de diagnostiquer les problèmes réseau sans ouvrir de session sur vos machines virtuelles.
  • Vous pouvez déclencher la capture de paquets en définissant des alertes et bénéficiez d’un accès à des informations en temps réel sur le niveau de performance au niveau du paquet. Quand vous identifiez un problème, vous pouvez l’examiner en détail.
  • Il est recommandé d’utiliser Network Watcher pour passer en revue les journaux de flux NSG.
    • Les journaux de flux NSG de Network Watcher permettent d’afficher des informations sur le trafic IP entrant et sortant via un groupe de sécurité réseau.
    • Ces journaux de flux sont écrits au format JSON.
    • Les journaux de flux affichent les flux entrants et sortants en fonction de la règle, et l’interface réseau à laquelle le flux s’applique. Ils affichent également des informations de 5-tuple sur le flux (adresse IP source/de destination, port source/de destination et protocole) et indiquent si le trafic a été autorisé ou refusé.

En savoir plus :

Utiliser des outils partenaires dans Place de marché Azure

Pour les topologies de réseau plus complexes, vous pouvez utiliser des produits de sécurité proposés par des partenaires de Microsoft, et notamment des appliances virtuelles réseau (NVA).

  • Une NVA est une machine virtuelle qui exécute une fonction réseau, telle qu’un pare-feu, l’optimisation du WAN ou une autre fonction réseau.
  • Les appliances virtuelles réseau renforcent les fonctions réseau et de sécurité du réseau virtuel. Elles peuvent être déployées pour des éléments à haute disponibilité, tels que les pare-feu, la prévention d’intrusion, la détection d’intrusion, les WAF, l’optimisation du réseau étendu, le routage, l’équilibrage de charge, le VPN, la gestion des certificats, Active Directory et l’authentification multifacteur.
  • Les appliances virtuelles réseau sont disponibles auprès de nombreux fournisseurs dans Place de marché Azure.

Bonne pratique : implémentation de pare-feu et d’appliances virtuelles réseau dans des réseaux hub

Dans le hub, vous gérez normalement le réseau de périmètre (avec un accès à Internet) par le biais du pare-feu Azure, d’une batterie de pare-feu ou d’un WAF. Le tableau suivant fournit des comparaisons entre ces solutions.

Type de pare-feu Détails
WAF Les applications web sont courantes et ont tendance à être sujettes à des vulnérabilités et à des attaques potentielles. Les WAF sont conçus pour détecter les attaques contre les applications web (HTTP/HTTPS). Contrairement à la technologie de pare-feu classique, les WAF intègrent un ensemble de fonctionnalités spécifiques pour protéger les serveurs web internes contre les menaces.
Pare-feu Azure À l’instar des batteries de pare-feu d’appliance de réseau virtuel, le pare-feu Azure utilise un mécanisme d’administration commune et un ensemble de règles de sécurité pour protéger les charges de travail hébergées dans les réseaux spoke. Le pare-feu Azure permet également de contrôler l’accès aux réseaux locaux. Le pare-feu Azure dispose d’une scalabilité intégrée.
Pare-feu NVA Comme le pare-feu Azure, les batteries de pare-feu d’appliance de réseau virtuel utilisent un mécanisme d’administration commune et un ensemble de règles de sécurité pour protéger les charges de travail hébergées dans les réseaux spoke. Les pare-feu d’appliance de réseau virtuel permettent également de contrôler l’accès aux réseaux locaux. Les pare-feu NVA peuvent être mis à l’échelle manuellement derrière un équilibreur de charge.

Bien qu’une batterie de pare-feu soit équipée de logiciels moins spécialisés qu’un WAF, elle dispose d’un plus vaste champ d’application permettant de filtrer et d’inspecter n’importe quel type de trafic en entrée et en sortie.

Nous vous recommandons d’utiliser un ensemble de Pare-feu Azure (ou d’appliances virtuelles réseau) pour le trafic provenant d’Internet, et un autre ensemble pour le trafic émanant du niveau local. L’utilisation d’un seul ensemble de pare-feu pour ces deux types de trafics réseau constitue un risque pour la sécurité, car elle n’offre aucun périmètre de sécurité entre les deux. L’utilisation de couches de pare-feu distinctes simplifie la vérification des règles de sécurité et permet d’identifier clairement les règles auxquelles correspondent les différentes requêtes réseau entrantes.

En savoir plus :

Étapes suivantes

Passez en revue d’autres meilleures pratiques :