Groupes de sécurité réseau et groupes de sécurité d’application

Cet article explique comment contrôler le trafic réseau dans Azure réseaux virtuels à l’aide de groupes de sécurité réseau (NSG) pour le filtrage du trafic. Il couvre également les groupes de sécurité d’application (ASG) pour le regroupement logique d’interfaces réseau.

Présentation de cet article

Les groupes de sécurité réseau vous permettent de filtrer le trafic entrant et sortant pour les ressources d’un réseau virtuel Azure. Les groupes de sécurité d’application vous permettent de regrouper les interfaces réseau par rôle. Écrivez des règles de groupe de sécurité réseau qui référencent des groupes logiques au lieu d’adresses IP individuelles.

Qui a besoin de cet article

Lisez cet article si vous :

Déployez toute ressource qui se connecte à un réseau virtuel Azure.
Vous devez contrôler le trafic qui circule entre les sous-réseaux, les machines virtuelles ou les services Azure.
Vous souhaitez simplifier la gestion des règles pour les environnements où le nombre de machines virtuelles évolue fréquemment ou où les adresses IP changent fréquemment.
Créez une base de référence de sécurité pour une nouvelle charge de travail Azure.

Priorité au lift-and-shift : recréez vos règles de pare-feu et de segmentation locales sous forme de groupes de sécurité réseau entre les sous-réseaux, en reproduisant les flux entre niveaux déjà utilisés par vos applications.

Axe de modernisation : Utilisez des groupes de sécurité d’application pour définir des règles en fonction du rôle de la charge de travail plutôt qu’en fonction des adresses IP, et associez les NSG de sous-réseau à un pare-feu du hub et à des routes définies par l’utilisateur qui imposent l’inspection du trafic sortant.

Priorité aux environnements intercloud : reproduisez les règles des groupes de sécurité d'AWS et de Google Cloud dans les groupes de sécurité réseau Azure afin que la stratégie de trafic reste cohérente lorsque les charges de travail passent d'un cloud à l'autre.

Azure services et fonctionnalités

Le tableau suivant décrit les services et fonctionnalités utilisés pour le filtrage du trafic réseau dans Azure réseaux virtuels.

Service ou fonctionnalité	Ce qu’il fournit	Quand l′utiliser ?
Groupe de sécurité réseau (NSG)	Ensemble de règles de sécurité entrantes et sortantes appliquées à un sous-réseau ou à une interface réseau. Les règles sont évaluées par priorité : le nombre le plus bas gagne.	Contrôler le trafic au niveau du sous-réseau ou de la machine virtuelle individuelle. Appliquez à chaque charge de travail qui utilise un réseau virtuel.
Groupe de sécurité d’application (ASG)	Regroupement logique d’interfaces réseau. Utilisez des ASG comme source ou destination dans les règles NSG au lieu d’adresses IP.	Vous avez plusieurs machines virtuelles qui servent le même rôle (serveurs web, serveurs d’applications) et leurs adresses IP changent avec la mise à l’échelle. Toutes les cartes réseau groupées doivent se trouver dans le même réseau virtuel.
Étiquettes de service	Groupes nommés de préfixes d’adresses IP pour les services Azure, gérés et mis à jour automatiquement par Microsoft. Exemples : `AzureCloud`, `Storage`, `AzureLoadBalancer`, `Sql`.	Faites référence aux services Azure dans les règles NSG sans coder en dur des plages d’adresses IP. Microsoft met automatiquement à jour les plages d’adresses IP sous-jacentes. Vous ne pouvez pas créer de balises de service personnalisées.

Balises de service courantes

Le tableau suivant répertorie les balises de service les plus fréquemment utilisées dans les règles de groupe de sécurité réseau.

Balises de service	Description
`Internet`	Tout l’espace d’adressage IP public en dehors de votre réseau virtuel. Correspond à tout trafic provenant ou destiné à l’Internet public.
`VirtualNetwork`	Espace d'adressage de votre réseau virtuel, tous les espaces d'adressage connectés (réseaux virtuels appairés), réseaux locaux connectés via VPN/ExpressRoute et tous les points de terminaison de service. Inclut les itinéraires par défaut.
`AzureLoadBalancer`	Azure équilibreur de charge d’infrastructure. Correspond à l’adresse IP virtuelle de l’hôte d’où proviennent les sondes d’intégrité Azure. Utilisé dans les règles entrantes pour autoriser le trafic des sondes d'intégrité.
`Storage`	espace d’adressage IP du service stockage Azure Prend en charge les variantes régionales comme `Storage.WestUS2`. Permet d’autoriser ou de restreindre l’accès aux stockage Azure à partir du réseau virtuel.
`AzureCloud`	Toutes les adresses IP publiques du centre de données Azure. Prend en charge les variantes régionales comme `AzureCloud.EastUS`. Utile pour autoriser le trafic sortant vers Azure services en général.
`Sql`	Azure SQL Database, Azure Database pour MySQL, Azure Database pour PostgreSQL, Azure Database for MariaDB et Azure Synapse Analytics Préfixes d’adresse IP. Prend en charge les variantes régionales.
Règles de sécurité augmentées	Règles de groupe de sécurité réseau étendues qui acceptent plusieurs adresses IP, plages d’adresses IP et ports dans une seule règle. Réduisez le nombre de règles lorsque vous devez autoriser ou refuser le trafic pour de nombreuses adresses IP ou plages de ports. Prend en charge plusieurs adresses IP et plages de ports par règle, et jusqu’à 10 groupes de sécurité d’application, mais une seule balise de service par règle.

Comment choisir

Utilisez les conseils suivants pour sélectionner la construction de sécurité appropriée pour votre scénario.

Limites et quotas des NSG

Azure applique les limites par défaut suivantes sur les ressources NSG. Pour augmenter la plupart des limites, demandez une augmentation via support Azure.

Ressource	Limite par défaut	Limite maximale
Règles par NSG	2 000	2 000
Groupes de sécurité réseau par abonnement	5,000	5,000
Groupes de sécurité réseau par sous-réseau	1	1
NSGs par NIC	1	1
ASG par abonnements	3,000	3,000
Cartes réseau par ASG	Varie selon l’abonnement	Contactez le service support
Groupes de sécurité des applications référencés comme source ou destination par règle	10	10

Note

La limite de 2 000 règles pour chaque groupe de sécurité réseau inclut des règles personnalisées et des règles par défaut. Si vous approchez de cette limite, utilisez des règles de sécurité augmentées pour combiner plusieurs adresses IP ou plages de ports en moins de règles.

NSG et ASG : quand utiliser

Utilisez le tableau suivant pour déterminer la construction de sécurité qui correspond à votre scénario.

Scénario	Utilisation	Pourquoi
Contrôler le trafic pour toutes les machines virtuelles d’un sous-réseau	Groupe de sécurité réseau au niveau du sous-réseau	Un groupe de sécurité réseau s’applique à chaque ressource du sous-réseau. Plus simple à gérer pour les stratégies uniformes.
Contrôler le trafic d’une machine virtuelle spécifique indépendamment de son sous-réseau	Groupe de sécurité réseau au niveau de la NIC	Autorise les exceptions sans affecter d’autres machines virtuelles. Utile pour les jump box ou les hôtes Bastion.
De nombreuses machines virtuelles servent le même rôle et les adresses IP changent fréquemment	ASG	Ajoutez des machines virtuelles à un groupe par rôle (web, application, données). Définissez des règles pour le nom du groupe. Aucune mise à jour n’est nécessaire lorsque les machines virtuelles sont mises à l’échelle ou obtiennent de nouvelles adresses IP.
Référencer les services Azure (Stockage, SQL, Key Vault) comme source ou destination	NSG avec balises de service	Évitez de coder en dur les plages d’adresses IP que Microsoft peut être amené à mettre à jour. Les étiquettes de service restent actives automatiquement.

Le schéma suivant montre comment les ASG vous permettent de regrouper des machines virtuelles par rôle et de définir des règles de NSG entre des groupes logiques plutôt qu’entre des adresses IP individuelles.

Liste de contrôle de la posture de sécurité

Validez votre configuration de groupe de sécurité réseau par rapport à cette liste de contrôle avant le déploiement en production.

Requirement	Action	Reference
Posture de refus par défaut	Vérifiez que vous vous appuyez sur la règle par défaut `DenyAllInbound` (priorité 65500). Ne créez pas de règles d’autorisation étendues qui contournent le refus par défaut.	Sécurité
Aucun accès Internet sur les ports d’administration	Bloquer le trafic entrant à partir de `0.0.0.0/0` SSH (22) et RDP (3389). Utilisez Azure Bastion ou un VPN pour l’accès administratif.	Sécurité
Combiner avec Pare-feu Azure pour une inspection approfondie	Les groupes de sécurité réseau filtrent uniquement aux couches 3 et 4. Ajoutez Pare-feu Azure pour le filtrage de couche application (couche 7), l’inspection TLS et le renseignement sur les menaces.	Pare-feu Azure et segmentation du réseau
Activer les journaux de flux pour les diagnostics	Utilisez les journaux de flux de réseau virtuel pour capturer les données de trafic pour l’examen et la conformité de la sécurité.	Surveillance et diagnostics réseau

Ordre d’évaluation des règles

Les règles des groupes de sécurité réseau utilisent le principe de la première correspondance :

Azure évalue d’abord les règles dans l’ordre de priorité : nombre le plus bas (priorité la plus élevée).
Azure évalue chaque règle en fonction d'un quintuplet : source, port source, destination, port de destination et protocole.
Lorsque le trafic correspond à une règle, le traitement s’arrête. Azure n'évalue pas d'autres règles.
Si aucune règle personnalisée ne correspond, les règles par défaut s’appliquent. Vous ne pouvez pas supprimer les règles par défaut, mais vous pouvez les remplacer en créant des règles personnalisées avec des numéros de priorité compris entre 100 et 4096.

Règles par défaut (six totaux) :

Direction	Nom de la règle	Priority	Action
Inbound	AllowVNetInBound	65 000	Permettre
Inbound	AllowAzureLoadBalancerInBound	65 001	Permettre
Inbound	DenyAllInbound	65500	Deny
Outbound	AllowVnetOutBound	65 000	Permettre
Outbound	AllowInternetOutBound	65 001	Permettre
Outbound	DenyAllOutBound	65500	Deny

Contraintes ASG

Lorsque vous utilisez des groupes de sécurité d’application, tenez compte des contraintes suivantes :

Toutes les interfaces réseau d’un ASG doivent exister dans le même réseau virtuel que la première interface réseau affectée à l’ASG.
Si vous référencez des ASG dans la source et la destination d’une règle, les interfaces réseau des deux groupes doivent se trouver dans le même réseau virtuel.
Vous pouvez référencer jusqu’à 10 ASG dans la source ou la destination d’une règle.

Groupes de sécurité réseau au niveau du sous-réseau et de l'interface réseau combinés

Vous pouvez associer un NSG à la fois à un sous-réseau et à une interface réseau d’une machine virtuelle dans ce sous-réseau. Dans ce cas, Azure évalue les deux groupes de sécurité réseau et le trafic doit être autorisé par les deux. La combinaison la plus restrictive gagne.

Direction	Évalué pour la première fois	Évalué en second
Inbound	NSG de sous-réseau	NIC Groupe de sécurité réseau
Outbound	NSG de carte réseau	NSG de sous-réseau

Tip

Pour faciliter la résolution des problèmes, associez un groupe de sécurité réseau au sous-réseau ou à l’interface réseau, mais pas les deux. Si vous avez besoin des deux, documentez clairement l’interaction de règle prévue.

Exemple pratique : niveau web avec une zone de rebond

Considérez un sous-réseau avec un groupe de sécurité réseau au niveau du sous-réseau qui autorise le protocole HTTPS entrant (port 443) à partir d’Internet et refuse tout le reste. Une machine virtuelle jump box de ce sous-réseau dispose également d'un groupe de sécurité réseau au niveau de son interface réseau qui autorise le trafic SSH entrant (port 22) depuis une plage d'adresses IP d'administration spécifique.

Trafic web (port 443) : Le groupe de sécurité réseau du sous-réseau l’autorise. L’interface réseau NSG des VM web n’a aucune règle de refus pour le port 443 (autorisé par défaut AllowVNetInBound). Flux de trafic.
Connexion SSH à la jump box (port 22 depuis la plage d'adresses IP d'administration) : le groupe de sécurité réseau du sous-réseau refuse le trafic sur le port 22 en provenance d'Internet. Même si le groupe de sécurité réseau de l'interface réseau autorise SSH depuis la plage d'administration, le groupe de sécurité réseau du sous-réseau le bloque en premier. Résolution: Ajoutez une règle dans le groupe de sécurité réseau du sous-réseau pour autoriser le port 22 à partir de la plage d’adresses IP de gestion ou utilisez Azure Bastion pour contourner entièrement le chemin d’accès Internet public.

Cet exemple montre pourquoi deux groupes de sécurité réseau ajoutent de la complexité. Les deux doivent autoriser le trafic indépendamment.

Le schéma suivant montre le chemin d’évaluation du trafic entrant lorsque vous associez à la fois un NSG de sous-réseau et un NSG d’interface réseau. Le trafic doit être autorisé par les deux groupes de sécurité réseau. La combinaison la plus restrictive gagne.

Interaction avec Azure Virtual Network Manager

Si votre organisation utilise des règles d’administration de sécurité Azure Virtual Network Manager (AVNM), Azure évalue ces règles avant les règles du groupe de sécurité réseau. Les règles d'administration de sécurité peuvent être Autoriser (poursuivre l'évaluation des groupes de sécurité réseau), Toujours autoriser (contourner les groupes de sécurité réseau) ou Refuser (bloquer avant l'évaluation des groupes de sécurité réseau). Pour la gestion centralisée de la sécurité réseau, consultez Azure Virtual Network Manager et la gestion centralisée.

Considérations relatives à la conception

Priorité de conception des groupes de sécurité réseau et des groupes de sécurité des applications pour le lift-and-shift

Traduisez votre segmentation sur site en NSG au niveau du sous-réseau : autorisez uniquement les flux entre couches que votre application utilise déjà (par exemple, du web vers l’application et de l’application vers la base de données) et bloquez tout le reste.
Partez de votre ensemble actuel de règles de pare-feu et resserrez-les après la migration, à l’aide des journaux de flux NSG pour confirmer quels flux sont réellement nécessaires.
Appliquez d’abord les NSG au niveau du sous-réseau pour plus de simplicité ; ajoutez des règles au niveau de l’interface réseau uniquement lorsque certaines machines virtuelles nécessitent des exceptions.
Utilisez des balises de service (telles que VirtualNetwork et AzureLoadBalancer) au lieu d’adresses IP codées en dur afin que les règles survivent à la réadressage pendant la migration.

Moderniser l’orientation de conception des NSG et ASG

Utilisez des groupes de sécurité d’application pour regrouper les interfaces réseau par rôle (web, application, données) afin que les règles décrivent l’intention et s’adaptent automatiquement à la mise à l’échelle des instances.
Combinez des NSG de sous-réseau à un hub Pare-feu Azure : les NSG gèrent la microsegmentation entre les couches, tandis que le pare-feu inspecte le trafic qui traverse les frontières de confiance.
Autorisez uniquement le sous-réseau de point de terminaison privé à atteindre les services PaaS et forcez le trafic sortant via le pare-feu hub avec des itinéraires définis par l’utilisateur.
Si vous utilisez les règles d’administration de sécurité d’Azure Virtual Network Manager, planifiez leur ordre de priorité (elles sont évaluées avant les NSG) afin que les garde-fous à l’échelle de la plateforme n’entrent pas en conflit avec les NSG des charges de travail.

Priorité de conception des groupes de sécurité réseau et des groupes de sécurité des applications pour les environnements intercloud

Répliquez les règles de groupes de sécurité d’AWS et de Google Cloud dans les groupes de sécurité réseau (NSG) Azure afin que les niveaux équivalents appliquent la même stratégie après la migration.
Autorisez uniquement les ports et sources spécifiques requis pour les dépendances d’application multicloud et routez ce trafic via des tunnels IPsec inspectés.
Normaliser les noms des groupes de sécurité d’application entre les clouds afin que les équipes d’opérations puissent mettre en corrélation des charges de travail équivalentes lorsqu’elles résolvent les problèmes.
Associez des NSG à un pare-feu de hub Virtual WAN sécurisé afin que le trafic intercloud et le trafic des succursales soient à la fois filtrés par les NSG et inspectés par le pare-feu.

Prerequisites

Avant d’implémenter des NSG et des ASG, assurez-vous de disposer des éléments suivants :

Un réseau virtuel avec des sous-réseaux : Les groupes de sécurité réseau (NSG) s’associent aux sous-réseaux ou aux interfaces réseau au sein d’un réseau virtuel. Consultez les réseaux virtuels et les sous-réseaux pour obtenir des conseils de planification.
Un plan d’adressage IP : Les règles de groupe de sécurité réseau référencent les adresses IP et les plages. Un plan IP vous permet d’écrire des règles précises. Consultez la planification des adresses IP pour obtenir des conseils.
Liste des flux de trafic requis : Documentez les ressources nécessaires pour communiquer, sur quels ports et dans quelle direction avant d’écrire des règles.

Considérations relatives à la sécurité

Important

Le refus par défaut est la bonne approche. Les règles de trafic entrant par défaut dans Azure refuser tout le trafic Internet qui n'est pas explicitement autorisé. N’affaiblissez pas cette posture en créant des règles d’autorisation trop générales.

Ne jamais autoriser 0.0.0.0/0 sur les ports d’administration

Caution

Ne créez jamais de règle de groupe de sécurité réseau (NSG) qui autorise le trafic entrant depuis 0.0.0.0/0 (n’importe quelle source sur Internet) vers des ports d’administration tels que SSH (port 22) ou RDP (port 3389). Les attaquants analysent en permanence Internet pour rechercher les ports d’administration ouverts. Utilisez plutôt Azure Bastion, un VPN ou Azure Private Link pour accéder en toute sécurité aux machines virtuelles.

Combiner des NSG avec Pare-feu Azure

Les NSG fonctionnent à la couche 3 et à la couche 4 (réseau et transport). Ils filtrent en fonction des adresses IP, des ports et des protocoles, mais n’inspectent pas le contenu des paquets. Pour les charges de travail qui nécessitent un filtrage de couche application, une intelligence des menaces ou une inspection TLS, déployez Pare-feu Azure en même temps que les groupes de sécurité réseau. Consultez Pare-feu Azure et la segmentation du réseau.

Utiliser les journaux de flux VNet pour assurer la visibilité du trafic

Note

La mise hors service des journaux de flux des groupes de sécurité réseau est prévue pour le 30 septembre 2027. Aucun nouveau journal de flux NSG ne peut être créé après le 30 juin 2025. Migrez vers les journaux de flux de réseau virtuel, qui fournissent les mêmes fonctionnalités, ainsi que l’analytique du trafic au niveau du réseau virtuel.

Les journaux de flux de réseau virtuel capturent l’état par flux et les données de débit pour toutes les charges de travail d’un réseau virtuel. Utilisez-les pour :

Examen de la sécurité : identifier les modèles de trafic inattendus.
Audit de conformité : prouvez que les flux de trafic correspondent à la stratégie documentée.
Planification de la capacité : comprendre la consommation de bande passante entre les sous-réseaux.

Pour la configuration de la surveillance et des diagnostics, consultez surveillance et diagnostics réseau.

Erreurs courantes à éviter

Erreur	Pourquoi c’est un problème	Meilleure approche
Création de règles entrantes autorisant tout le trafic (priorité 100, source ``, destination ``)	Contourne la posture de refus par défaut et expose toutes les ressources au trafic Internet.	Autorisez uniquement des combinaisons source/destination/port spécifiques. Utilisez les numéros de priorité les plus élevés possibles pour les règles d’autorisation.
Oublier que le refus par défaut existe	Les équipes créent des règles d’autorisation pour le trafic connu, mais ne vérifient pas que tout le reste est bloqué. Les ports ouverts inattendus peuvent passer inaperçus.	Après avoir déployé les groupes de sécurité réseau, vérifiez à l'aide des journaux de flux des réseaux virtuels ou des diagnostics des groupes de sécurité réseau que seuls les flux de trafic attendus sont autorisés. Testez explicitement les chemins d’accès refusés.
Ne pas utiliser d’ASG pour les charges de travail dynamiques	Les règles basées sur IP s’arrêtent lorsque les machines virtuelles effectuent un scale-out ou obtiennent de nouvelles adresses IP. Les équipes finissent par mettre constamment à jour les règles.	Regrouper des machines virtuelles par rôle à l’aide d’ASG. Les règles référençant les asG restent valides lorsque les machines virtuelles sont ajoutées ou supprimées du groupe.
Ignorer les journaux de flux jusqu’à un incident de sécurité	Sans journaux de flux activés, vous n’avez pas de données de trafic historique pour les audits d’investigation ou de conformité.	Activez les journaux de flux des réseaux virtuels dès le premier jour. Configurez Traffic Analytics pour la visualisation et les alertes sur les anomalies.
Application de groupes de sécurité réseau au niveau du sous-réseau et de l'interface réseau sans documentation	La présence de deux groupes de sécurité réseau (NSG) crée des interactions confuses dans lesquelles le trafic est bloqué de façon inattendue. La résolution des problèmes devient fastidieuse.	Choisissez les groupes de sécurité réseau au niveau du sous-réseau ou de l’interface réseau comme norme. Si les deux sont nécessaires, documentez l’interaction prévue pour chaque sous-réseau.

Réseaux virtuels et sous-réseaux : emplacement d’application des NSG
Pare-feu Azure et segmentation réseau : inspection de niveau 7 pour compléter les groupes de sécurité réseau
Surveillance et diagnostics réseau : journaux de flux de réseau virtuel et diagnostics NSG
Azure Virtual Network Manager et la gestion centralisée : règles d’administration de sécurité et gestion NSG centralisée

Learn more

Étapes suivantes

Tip

Vous explorez vous-même ? Revenez au navigateur de vue d’ensemble pour trouver votre prochain article par fonctionnalité.

Étape suivante de votre parcours lift-and-shift :

Concevez votre topologie hub-and-spoke : centraliser les services partagés tels que DNS, pare-feu et passerelle VPN sur vos charges de travail migrées.

Ensuite, dans votre parcours de modernisation :

Concevez votre topologie hub-and-spoke : mettez en place une topologie à double hub avec des hubs gérés par l’équipe informatique et des spokes gérés par les équipes applicatives pour vos charges de travail PaaS.

Prochaine étape de votre parcours multi-cloud :

Configurez des tunnels chiffrés vers vos autres clouds : configurez des connexions passerelle VPN à la passerelle Virtual Private Gateway d’Amazon Web Services (AWS) et à Google Cloud VPN pour assurer un transit intercloud.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-07-06