Groupes de sécurité réseau et groupes de sécurité des applications

Un Network Security Group (NSG) joue le rôle d'un pare-feu virtuel pour les ressources Azure. Il contient une liste de règles de sécurité qui autorisent ou refusent le trafic réseau entrant et sortant en fonction de l'IP source, de l'IP de destination, du numéro de port et du protocole. Les NSG peuvent être associés à des sous-réseaux (ce qui affecte toutes les ressources du sous-réseau) ou à des interfaces réseau individuelles (ce qui affecte une seule VM). Lorsqu'un NSG de sous-réseau et un NSG de NIC sont tous deux présents, Azure les évalue tous les deux : pour le trafic entrant, le NSG du sous-réseau est appliqué en premier ; pour le trafic sortant, le NSG de la NIC est appliqué en premier.

Chaque règle NSG possède les propriétés suivantes : Priorité — un nombre compris entre 100 et 4096 ; les nombres les plus faibles sont évalués en premier. Source/Destination — une adresse IP, une plage CIDR, une balise de service ou un groupe de sécurité d'application. Port source/destination — des numéros ou des plages de ports spécifiques (par exemple, 80, 443, 3389 ou 1024-65535). Protocole — TCP, UDP, ICMP ou Any. Action — Allow ou Deny. Les règles sont évaluées dans l'ordre des priorités ; la première règle correspondante l'emporte. Si aucune règle ne correspond, les règles par défaut s'appliquent : refuser tout le trafic entrant et autoriser tout le trafic sortant.

Chaque NSG est fourni avec trois règles entrantes par défaut et trois règles sortantes par défaut, dont les priorités sont comprises entre 65000 et 65500 et qui ne peuvent pas être supprimées. Règles entrantes par défaut : AllowVnetInBound (autorise le trafic provenant du VNet), AllowAzureLoadBalancerInBound (autorise les sondes d'intégrité Azure), DenyAllInBound (refuse tout le reste). Règles sortantes par défaut : AllowVnetOutBound, AllowInternetOutBound, DenyAllOutBound. Vous pouvez remplacer les valeurs par défaut en ajoutant des règles ayant des numéros de priorité inférieurs (100 à 64999), qui prennent effet avant les règles par défaut.

Les balises de service sont des groupes prédéfinis de plages d'adresses IP pour les services Azure. Elles vous permettent d'écrire des règles NSG concises sans indiquer de longues listes d'adresses IP qui évoluent au fil du temps. Parmi les balises de service courantes figurent : Internet — toutes les adresses IP situées en dehors du VNet. VirtualNetwork — toutes les IP à l'intérieur du VNet. AzureLoadBalancer — l'adresse IP de l'équilibreur de charge de l'infrastructure Azure. Storage — les IP du service Azure Storage pour la région choisie. AzureActiveDirectory — les points de terminaison Entra ID. Microsoft gère automatiquement ces balises ; vos règles NSG restent donc exactes, même lorsque les IP des services changent.

Associer un NSG à un sous-réseau applique ses règles à toutes les ressources de ce sous-réseau, ce qui en fait la méthode la plus efficace pour appliquer des politiques réseau à grande échelle. Par exemple, associer un NSG « DenyRDP » à un sous-réseau de niveau données empêche toute VM de ce sous-réseau d'être accessible via RDP (port 3389) depuis l'extérieur, quelles que soient les autorisations des NSG au niveau de la NIC. Ce NSG au niveau du sous-réseau constitue la première ligne de défense, avant même que le trafic n'atteigne les différentes VM, et réduit la surface d'attaque à la limite du réseau.

Les Application Security Groups (ASG) vous permettent de regrouper les interfaces réseau de VM Azure selon leur rôle applicatif plutôt que selon leur adresse IP. Par exemple, vous créez les ASG nommés webServers, appServers et dbServers, puis vous affectez la NIC de chaque VM à l'ASG approprié. Dans vos règles NSG, vous pouvez alors écrire : « autoriser le trafic de webServers vers appServers sur le port 8080 », sans indiquer d'adresse IP. Lorsque vous ajoutez ou supprimez des VM, il vous suffit de mettre à jour leur appartenance aux ASG ; toutes les règles NSG s'appliquent alors automatiquement et correctement, sans modifier les règles.

Une fois les ASG définis et les VM affectées, vous écrivez des règles NSG qui font référence aux ASG comme source ou destination. Cette approche est beaucoup plus facile à gérer que les règles fondées sur les IP, car elle offre : aucune gestion des IP — vous n'avez pas besoin de connaître les IP des VM ; l'appartenance aux ASG assure la correspondance. Mise à l'échelle dynamique — les nouvelles VM héritent automatiquement des règles correctes lorsqu'elles sont ajoutées au bon ASG. Clarté sémantique — les règles se lisent naturellement (« webServers → appServers sur 8080 »), plutôt que comme des plages d'IP opaques. Les ASG sont particulièrement utiles dans les environnements dynamiques où les VM sont fréquemment ajoutées ou remplacées.

Les journaux de flux NSG enregistrent des informations sur tout le trafic IP traversant un NSG, notamment l'IP source et l'IP de destination, le port, le protocole, l'autorisation ou le refus du trafic, ainsi que le nombre d'octets transférés. Les journaux de flux sont écrits au format JSON dans un compte Azure Storage et peuvent être visualisés dans l'outil Traffic Analytics d'Azure Network Watcher. Ils sont précieux pour résoudre les problèmes de connectivité (« pourquoi ce trafic est-il bloqué ? »), mener des investigations de sécurité et produire des rapports de conformité nécessitant des preuves sur les schémas de trafic.

Trois erreurs NSG courantes provoquent des problèmes de connectivité : oublier l'ordre d'évaluation — si une règle Deny possède la priorité 100 et votre règle Allow la priorité 200, le trafic est refusé, car les numéros de priorité les plus faibles l'emportent. Bloquer les sondes d'intégrité Azure — les sondes d'intégrité de l'équilibreur de charge proviennent de l'IP 168.63.129.16 ; bloquer cette source fait apparaître les backends de l'équilibreur de charge comme non sains et interrompt la réception du trafic. Chevauchement des NSG de sous-réseau et de NIC — le trafic doit réussir les deux évaluations NSG ; une règle autorisant le trafic au niveau du NSG de sous-réseau sera tout de même bloquée si le NSG de la NIC le refuse.

Les NSG et Azure Firewall sont complémentaires, mais différents : NSG — décentralisés, associés aux sous-réseaux et aux NIC, filtrage de couche 3/4 (IP et port), aucune journalisation du trafic par défaut, inclus gratuitement avec chaque VNet. Azure Firewall — centralisé, service géré dans un VNet hub, filtrage de couche 3/4 ET de couche 7 (FQDN, URL, IDPS), journalisation complète via Azure Monitor et coût d'environ 1 000 $ ou plus par mois. Utilisez les NSG pour le périmètre de base et l'isolation des niveaux. Utilisez Azure Firewall lorsque vous avez besoin d'une application centralisée et vérifiable des règles d'accès à Internet sortant, avec filtrage FQDN, renseignements sur les menaces ou inspection TLS.

Lorsqu'un NSG est associé à la fois à un sous-réseau et à une NIC, il peut devenir difficile de savoir quelles règles sont réellement appliquées. Azure fournit, dans le portail, la vue Effective Security Rules pour la NIC de toute VM ; elle affiche le résultat combiné de toutes les règles NSG provenant du sous-réseau et de la NIC. Il s'agit de la liste définitive de ce qui est réellement autorisé ou refusé pour cette VM. L'outil IP flow verify d'Azure Network Watcher va plus loin : vous indiquez une IP et un port source ainsi qu'une IP et un port de destination, et il vous indique instantanément si le trafic serait autorisé ou refusé, ainsi que la règle précise qui en est responsable.

Vérifiez votre compréhension des concepts Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les NSG contiennent des règles Allow/Deny évaluées dans l'ordre des priorités, qui filtrent le trafic des sous-réseaux ou des interfaces réseau individuelles, que les balises de service simplifient les règles en représentant des groupes dynamiques de plages d'IP de services Azure, et que les Application Security Groups permettent de regrouper les VM par rôle afin de créer des règles NSG ne nécessitant aucune maintenance et évoluant avec votre environnement. Nous allons maintenant découvrir l'appairage de VNet et les points de terminaison de service pour connecter des ressources entre des VNets et aux services Azure.