Générateur de règles NSG Azure

Le Générateur de règles Azure NSG crée des règles de Network Security Group à partir d'une entrée CSV structurée. Saisissez vos règles sous forme de lignes avec les colonnes direction, priorité, nom, source, destination, protocole, plage de ports et action, et obtenez des commandes Azure CLI, des commandes PowerShell ou du JSON de template ARM pour des déploiements de sécurité réseau automatisés et reproductibles dans Azure.

Comprendre les Azure Network Security Groups

Si vous déployez des charges de travail sur Azure, les Network Security Groups (NSG) sont l'outil principal de filtrage du trafic réseau vers et depuis vos machines virtuelles, sous-réseaux et interfaces réseau. Un NSG contient une liste de règles de sécurité qui autorisent ou refusent le trafic en fonction de la source, de la destination, du port et du protocole. Contrairement aux AWS security groups, les Azure NSG supportent les règles deny explicites et utilisent un modèle d'évaluation basé sur la priorité, vous offrant un contrôle plus granulaire sur les flux de trafic.

Le système de priorité est ce qui rend les Azure NSG à la fois puissants et potentiellement déroutants. Chaque règle a un numéro de priorité entre 100 et 4096, et les règles sont évaluées du numéro le plus bas (priorité la plus haute) au numéro le plus haut (priorité la plus basse). La première règle correspondante détermine l'action. Cela signifie qu'une règle Allow de haute priorité peut outrepasser une règle Deny de priorité plus basse, et inversement. Si vous définissez la priorité 100 pour autoriser HTTPS et la priorité 200 pour refuser tout le trafic de la même source, le trafic HTTPS passe car la priorité 100 est évaluée en premier. Obtenir le bon ordre des priorités est essentiel pour votre posture de sécurité.

Azure fournit également des service tags -- des groupes nommés de plages d'IP que Azure gère automatiquement. Au lieu de suivre manuellement les plages d'IP de Microsoft pour des services comme Azure Storage, Azure SQL ou les sondes de santé du Load Balancer Azure, vous référencez des tags comme Storage, Sql ou AzureLoadBalancer. Lorsque Microsoft met à jour ces plages, vos règles NSG s'appliquent automatiquement aux nouvelles adresses. C'est un avantage opérationnel significatif par rapport aux listes CIDR maintenues manuellement, surtout pour les services Azure PaaS dont les plages d'IP changent régulièrement.

Comment générer des règles Azure NSG à partir d'un CSV

1. Préparez vos données de règles au format CSV avec les colonnes : direction, priorité, nom, source, destination, protocole, plage de ports et action.
2. Collez ou importez le CSV dans le générateur.
3. Sélectionnez le format de sortie : Azure CLI, PowerShell ou template ARM.
4. Saisissez le nom du NSG et le resource group.
5. Copiez les commandes ou le template générés pour le déploiement.

Format d'entrée CSV et sortie générée

Entrée CSV

direction,priority,name,source,destination,protocol,port,action
Inbound,100,AllowHTTPS,*,*,Tcp,443,Allow
Inbound,110,AllowSSH,10.0.0.0/8,*,Tcp,22,Allow
Inbound,200,DenyScannersIn,198.51.100.0/24,*,*,*,Deny
Outbound,100,AllowSQL,*,10.1.0.0/16,Tcp,1433,Allow
Inbound,120,AllowHTTP,Internet,*,Tcp,80,Allow

Sortie Azure CLI

az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --name AllowHTTPS \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --destination-port-ranges 443 \
  --source-address-prefixes '*' \
  --destination-address-prefixes '*'

az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --name AllowSSH \
  --priority 110 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --destination-port-ranges 22 \
  --source-address-prefixes '10.0.0.0/8' \
  --destination-address-prefixes '*'

Sortie PowerShell

$rule1 = New-AzNetworkSecurityRuleConfig `
  -Name "AllowHTTPS" `
  -Priority 100 `
  -Direction Inbound `
  -Access Allow `
  -Protocol Tcp `
  -DestinationPortRange 443 `
  -SourceAddressPrefix '*' `
  -DestinationAddressPrefix '*' `
  -SourcePortRange '*'

$rule2 = New-AzNetworkSecurityRuleConfig `
  -Name "AllowSSH" `
  -Priority 110 `
  -Direction Inbound `
  -Access Allow `
  -Protocol Tcp `
  -DestinationPortRange 22 `
  -SourceAddressPrefix '10.0.0.0/8' `
  -DestinationAddressPrefix '*' `
  -SourcePortRange '*'

Types de sources et destinations Azure NSG

Fonctionnement de la priorité dans les Azure NSG

Les règles Azure NSG sont évaluées par numéro de priorité du plus bas (priorité la plus haute) au plus haut (priorité la plus basse). La première règle correspondante détermine l'action.

Règles de priorité clés :

• Plage valide : 100 à 4096
• Numéro plus bas = priorité plus haute (évalué en premier)
• Les valeurs de priorité doivent être uniques au sein d'une direction (Inbound ou Outbound)
• Azure réserve les priorités 65000-65500 pour les règles par défaut

Quand utiliser le générateur de règles Azure NSG

• Déploiement de VNet -- générer des règles NSG pour de nouveaux réseaux virtuels à partir d'un tableur d'exigences de sécurité.
• Applications multi-tiers -- créer des règles pour les tiers web, application et base de données avec les contrôles d'accès inter-tiers appropriés.
• Migration inter-cloud -- convertir des règles AWS Security Group ou des règles de firewall on-premises au format Azure NSG.
• Infrastructure as Code -- générer des templates ARM ou des scripts Azure CLI pour des déploiements NSG versionnés et reproductibles.
• Standardisation de la conformité -- appliquer des configurations NSG de référence cohérentes sur l'ensemble des abonnements et resource groups.

Différences entre les Azure NSG et les AWS Security Groups

Conseils pratiques pour la configuration des Azure NSG

Le plus grand piège avec les priorités des Azure NSG est de laisser des écarts trop petits. Si vous assignez les priorités 100, 101, 102 pour vos trois premières règles, vous n'avez plus de place pour insérer une règle entre elles sans renuméroter. Utilisez des incréments de 10 ou 20 (100, 110, 120, ...) pour pouvoir toujours insérer de nouvelles règles entre les existantes. Ce générateur valide que vos priorités ne sont pas en conflit, mais il ne peut pas imposer un bon espacement -- c'est une décision de conception que vous devez prendre dès le départ.

Lorsque vous travaillez avec des architectures multi-tiers sur Azure, appliquez les NSG au niveau du sous-réseau plutôt qu'au niveau NIC autant que possible. Les NSG au niveau sous-réseau sont plus faciles à gérer car ils s'appliquent uniformément à toutes les ressources du sous-réseau, et vous n'avez pas à vous souvenir d'attacher le NSG à chaque nouvelle VM que vous déployez. Les NSG au niveau NIC sont utiles pour les exceptions -- quand une VM dans un sous-réseau a besoin de règles différentes des autres -- mais ils ajoutent de la complexité et sont une source courante de sessions de dépannage du type "pourquoi cette VM ne peut-elle pas se connecter ?".

Les service tags sont l'une des meilleures fonctionnalités d'Azure pour la sécurité réseau, mais ils sont fréquemment sous-utilisés. Au lieu de maintenir une liste de plages IP d'Azure Storage pour vos règles NSG, utilisez le service tag Storage. Au lieu de rechercher les plages IP d'Azure SQL, utilisez le tag Sql. Pour des restrictions spécifiques à une région, ajoutez le nom de la région : Storage.EastUS. Azure maintient automatiquement ces plages, donc vos règles ne deviennent jamais obsolètes. Le seul bémol est que les service tags ne sont pas disponibles dans les Network ACL (uniquement dans les NSG), planifiez donc votre architecture de sécurité réseau en conséquence.

Questions fréquentes

Que se passe-t-il si deux règles ont des actions conflictuelles à des priorités différentes ? La règle avec le numéro de priorité le plus bas (priorité la plus haute) l'emporte. Par exemple, si la priorité 100 autorise HTTPS et la priorité 200 refuse tout le trafic de la même source, le trafic HTTPS est autorisé car la priorité 100 est évaluée en premier.

Peut-on utiliser plusieurs plages de ports dans une seule règle NSG ? Oui. Azure supporte plusieurs plages de ports dans une seule règle en utilisant des valeurs séparées par des espaces : --destination-port-ranges 80 443 8080-8090. Cela réduit le nombre total de règles nécessaires.

Que sont les service tags et quand les utiliser ? Les service tags sont des groupes de plages d'IP gérés par Azure pour les services Azure. Au lieu de suivre manuellement les plages d'IP de Microsoft, utilisez des tags comme Storage, Sql ou AzureActiveDirectory. Azure met automatiquement à jour les plages d'IP sous-jacentes. C'est particulièrement utile pour autoriser le trafic vers les services Azure PaaS.

Comment vérifier que les numéros de priorité ne sont pas en conflit ? Le générateur vérifie les doublons de priorité au sein de la même direction (Inbound ou Outbound) et signale les conflits avant de produire la sortie. Les priorités doivent être uniques par direction au sein d'un NSG.

Quel est le nombre maximal de règles dans un Azure NSG ? La limite par défaut est de 1000 règles par NSG (incluant les règles par défaut). C'est substantiellement plus élevé que les AWS security groups (60 par direction). Vous pouvez demander une augmentation de limite via le support Azure si nécessaire, mais atteindre 1000 règles indique généralement que la conception de votre NSG devrait être restructurée.

Comment migrer des AWS security groups vers les Azure NSG ? Les principales différences sont que les Azure NSG nécessitent des priorités explicites (AWS évalue toutes les règles de manière égale) et supportent les règles deny explicites. Mappez chaque règle allow AWS vers une règle Allow Azure avec une priorité croissante, ajoutez les règles deny dont vous avez besoin (qu'AWS ne peut pas exprimer), et remplacez les prefix lists AWS par des service tags Azure lorsque c'est applicable.

Outils associés

• AWS Security Group Rule Generator - Générer des règles AWS Security Group à partir d'un CSV
• iptables Rule Generator - Générer des règles iptables à partir d'un CSV
• nftables Rule Generator - Générer des règles nftables à partir d'un CSV
• Rule Conflict Finder - Trouver les règles de firewall dupliquées, masquées ou en conflit
• Allowlist Builder - Construire une allowlist CIDR minimale à partir d'une liste d'IP