Planifier et implémenter des groupes de sécurité réseau (NSG) et des groupes de sécurité d’application (ASG)
Vous pouvez utiliser un groupe de sécurité réseau Azure pour filtrer le trafic réseau entre des ressources Azure dans un réseau virtuel Azure. Un groupe de sécurité réseau contient 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.
Groupes de sécurité réseau (NSG)
Règles de sécurité
Un groupe de sécurité réseau contient le nombre de règles souhaité, dans les limites de l’abonnement Azure. Chaque règle spécifie les propriétés suivantes :
| Propriété | Explication |
|---|---|
| Nom | Nom unique au sein du groupe de sécurité réseau. Le nom peut contenir jusqu’à 80 caractères. Il doit commencer par un caractère alphabétique et se terminer par un caractère alphabétique ou « _ ». Le nom peut contenir des caractères alphabétiques ou « . », « - », « _ ». |
| Priorité | Nombre compris entre 100 et 4096. Les règles sont traitées dans l’ordre croissant, car les nombres les plus faibles sont prioritaires. Une fois que le trafic correspond à une règle, le traitement s’arrête. Par conséquent, les règles avec des priorités plus faibles (des nombres plus élevés) et ayant les mêmes attributs que les règles de priorité supérieure ne sont pas traitées. Les règles de sécurité par défaut Azure reçoivent la priorité la plus basse pour s’assurer du traitement prioritaire des règles personnalisées. |
| Source ou destination | Une adresse IP, un bloc de routage CIDR (par exemple, 10.0.0.0/24), une balise de service ou un groupe de sécurité d’application. Si vous spécifiez une adresse pour une ressource Azure, spécifiez l’adresse IP privée assignée à la ressource. Les groupes de sécurité réseau sont traités une fois qu’Azure a converti une adresse IP publique en adresse IP privée pour le trafic entrant, et avant qu’Azure ne convertisse une adresse IP privée en une adresse IP publique pour le trafic sortant. Moins de règles de sécurité sont nécessaires lorsque vous spécifiez une plage, une étiquette de service ou un groupe de sécurité d’application. La possibilité de spécifier plusieurs adresses IP individuelles et plages (vous ne pouvez pas spécifier plusieurs balises de service ou groupes d’applications) dans une règle est désignée sous le nom de règles de sécurité augmentée. Les règles de sécurité augmentée peuvent uniquement être créées dans des groupes de sécurité réseau créés par le biais du modèle de déploiement du Gestionnaire de ressources. Vous ne pouvez pas spécifier plusieurs adresses IP et plages d’adresses IP dans les groupes de sécurité réseau créés par le biais du modèle de déploiement classique. |
| Protocol | TCP, UDP, ICMP, ESP, AH ou n’importe lequel. Les protocoles ESP et AH ne sont actuellement pas disponibles via le portail Azure, mais ils peuvent être utilisés via des modèles Azure Resource Manager. |
| Sens | Indique si la règle s’applique au trafic entrant ou sortant. |
| Plage de ports | Vous pouvez spécifier un port individuel ou une plage de ports. Par exemple, indiquez 80 ou 10000-10005. La spécification de plages vous permet de créer moins de règles de sécurité. Les règles de sécurité augmentée peuvent uniquement être créées dans des groupes de sécurité réseau créés par le biais du modèle de déploiement du Gestionnaire de ressources. Vous ne pouvez pas spécifier plusieurs ports ou plages de ports dans les groupes de sécurité réseau créés par le biais du modèle de déploiement classique. |
| Action | Autoriser ou refuser |
Les règles de sécurité sont évaluées et appliquées en fonction des informations de cinq tuples (1. source, 2. port source, 3. destination, 4. port de destination et 5. protocole). Vous ne pouvez pas créer deux règles de sécurité avec les mêmes priorité et direction. 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. L’enregistrement de flux permet d’obtenir un groupe de sécurité réseau avec état. Si vous spécifiez une règle de sécurité sortante vers n’importe quelle adresse sur le port 80, par exemple, 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, il n’est pas nécessaire de spécifier une règle de sécurité sortante pour répondre au trafic sur ce port.
Les connexions existantes peuvent ne pas être interrompues lorsque vous supprimez une règle de sécurité qui autorisait la connexion. La modification des règles du groupe de sécurité réseau n’affecte que les nouvelles connexions. Quand une règle est créée ou qu’une règle existante est mise à jour dans un groupe de sécurité réseau, elle s’applique uniquement aux nouvelles connexions. Les connexions existantes ne sont pas réévaluées en fonction des nouvelles règles.
Façon dont les groupes de sécurité réseau filtrent le trafic
Vous pouvez déployer des ressources à partir de plusieurs services Azure dans un réseau virtuel Azure. Vous pouvez associer zéro ou un groupe de sécurité réseau à chaque sous-réseau de réseau virtuel et interface réseau dans une machine virtuelle. Vous pouvez associer le même groupe de sécurité réseau à autant d’interfaces réseau individuelles et autant de sous-réseaux que vous le souhaitez. L’image suivante illustre les différents scénarios de déploiement des groupes de sécurité réseau afin d’autoriser le trafic réseau vers et à partir d’internet via le port TCP 80 :
Consultez l’image et le texte suivant pour comprendre comment Azure traite les règles du trafic entrant et sortant pour les groupes de sécurité réseau :
Trafic entrant
Pour le trafic entrant, Azure traite d’abord les règles dans un groupe de sécurité réseau associées à un sous-réseau, si elles existent, puis les règles dans un groupe de sécurité réseau associées à l’interface réseau, si elles existent. Ce processus inclut également un trafic intra-sous-réseau.
- VM1 : les règles de sécurité dans le NSG1 sont traitées dans la mesure où elles sont associées au sous-réseau 1 et que VM1 se trouve dans le sous-réseau 1. À moins que vous n’ayez créé une règle qui autorise le port 80 entrant, la règle de sécurité par défaut DenyAllInbound refuse le trafic. Le trafic n’est pas évalué par NSG2, car il est associé à l’interface réseau. Si NSG1 autorise le port 80 dans sa règle de sécurité, NSG2 traite le trafic. Pour autoriser le port 80 vers la machine virtuelle, NSG1 et NSG2 doivent disposer tous deux d’une règle autorisant l’accès au port 80 à partir d’Internet.
- VM2 : les règles dans NSG1 sont traitées car VM2 se trouve également dans Sous-réseau 1. Dans la mesure où VM2 ne dispose pas d’un groupe de sécurité réseau associé à son interface réseau, elle reçoit tout le trafic autorisé via NSG1 ou se voit refuser tout le trafic refusé par NSG1. Le trafic est soit autorisé, soit refusé à toutes les ressources dans le même sous-réseau lorsqu’un groupe de sécurité réseau est associé à un sous-réseau.
- VM3 : dans la mesure où il n’existe aucun groupe de sécurité réseau associé au Sous-réseau 2, le trafic est autorisé dans le sous-réseau et traité par NSG2, car NSG2 est associé à l’interface réseau attachée à VM3.
- VM4 : le trafic est autorisé vers VM4, car un groupe de sécurité réseau n’est pas associé à Sous-réseau 3 ni à l’interface réseau de la machine virtuelle. L’intégralité du trafic réseau est autorisée via une interface réseau et un sous-réseau si aucun groupe de sécurité réseau leur est associé.
Trafic sortant
Pour le trafic sortant, Azure traite d’abord les règles dans un groupe de sécurité réseau associées à une interface réseau, si elles existent, puis les règles dans un groupe de sécurité réseau associées au sous-réseau, si elles existent. Ce processus inclut également un trafic intra-sous-réseau.
- VM1 : les règles de sécurité dans NSG2 sont traitées. La règle de sécurité par défaut AllowInternetOutbound à la fois de NSG1 et de NSG2 autorise le trafic, sauf si vous avez créé une règle de sécurité qui refuse le port 80 sortant vers Internet. Si NSG2 refuse le port 80 dans sa règle de sécurité, il refuse le trafic et NSG1 ne l’évalue jamais. Pour refuser le port 80 à partir de la machine virtuelle, l’un au moins des groupes de sécurité réseau doit disposer d’une règle qui refuse l’accès à Internet par le port 80.
- VM2 : l’ensemble du trafic est envoyé au sous-réseau via l’interface réseau puisque l’interface réseau attachée à VM2 ne dispose pas d’un groupe de sécurité réseau associé. Les règles dans NSG1 sont traitées.
- VM3 : si NSG2 refuse le port 80 dans sa règle de sécurité, il refuse le trafic. Si NSG2 ne refuse pas le port 80, la règle de sécurité par défaut AllowInternetOutbound de NSG2 autorise le trafic, car aucun groupe de sécurité réseau n’est associé à Sous-réseau 2.
- VM4 : tout le trafic est autorisé à partir de VM4, car un groupe de sécurité réseau n’est pas associé à l’interface réseau attachée à la machine virtuelle ou à Sous-réseau 3.
Trafic intra-sous-réseau
Il est important de noter que les règles de sécurité dans un groupe de sécurité réseau (NSG) associé à un sous-réseau peuvent perturber la connectivité entre les machines virtuelles (VM) qui le composent. Par défaut, les machines virtuelles du même sous-réseau peuvent communiquer en fonction d’une règle de groupe de sécurité réseau par défaut autorisant le trafic intra-sous-réseau. Si vous ajoutez une règle à NSG1 qui refuse tout trafic entrant et sortant, VM1 et VM2 ne pourront pas communiquer l'un avec l'autre.
Vous pouvez facilement afficher des règles d’agrégation appliquées à une interface réseau en consultant les règles de sécurité efficaces relatives à une interface réseau. Vous pouvez également utiliser la fonctionnalité de vérification du flux IP dans Azure Network Watcher pour déterminer si la communication est autorisée vers ou à partir d’une interface réseau. Vous pouvez utiliser la vérification de flux IP pour déterminer si une communication est autorisée ou refusée. En outre, utilisez la vérification du flux IP pour faire apparaître l’identité de la règle de sécurité réseau responsable de l’autorisation ou du refus du trafic.
Les groupes de sécurité réseau sont associés à des sous-réseaux ou à des machines virtuelles et services cloud déployés dans le modèle de déploiement classique, et à des sous-réseaux ou des interfaces réseau dans le modèle de déploiement Resource Manager.
Sauf si vous avez une raison particulière, nous vous recommandons d’associer un groupe de sécurité réseau à un sous-réseau ou à une interface réseau, mais pas aux deux. Dans la mesure où les règles d’un groupe de sécurité réseau associées à un sous-réseau peut entrer en conflit avec des règles d’un groupe de sécurité réseau associées à une interface réseau, vous pourrez subir des problèmes de communication inattendus qui nécessiteront une intervention.
Groupes de sécurité d’application (ASG)
Les groupes de sécurité d'application permettent de configurer la sécurité réseau comme un prolongement naturel de la structure de l'application, et donc de regrouper les machines virtuelles et définir des stratégies de sécurité réseau basés sur ces groupes. Vous pouvez réutiliser votre stratégie de sécurité à grande échelle sans maintenance manuelle d'adresses IP explicites. La plateforme gère la complexité des adresses IP explicites et plusieurs ensembles de règles, ce qui vous permet de vous concentrer sur la logique métier. Pour mieux comprendre les groupes de sécurité d’application, prenons l’exemple suivant :
Dans l’image précédente, NIC1 et NIC2 sont membres du groupe de sécurité d’application AsgWeb. NIC3 est un membre du groupe de sécurité d’application AsgLogic. NIC4 est un membre du groupe de sécurité d’application AsgDb. Bien que chaque interface réseau (NIC) dans cet exemple soit membre d’un seul groupe de sécurité réseau, une interface réseau peut être membre de plusieurs groupes de sécurité d’application, dans le respect des limites 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 :
Allow-HTTP-Inbound-Internet
Cette règle est nécessaire pour autoriser le trafic internet vers les serveurs web. Étant donné que le trafic entrant à partir d’Internet est refusé par la règle de sécurité par défaut DenyAllInbound, aucune règle supplémentaire n’est nécessaire pour les groupes de sécurité d’application AsgLogic ou AsgDb.
| Priorité | Source | Ports source | Destination | Ports de destination | Protocole | y accéder |
|---|---|---|---|---|---|---|
| 100 | Internet | * | AsgWeb | 80 | TCP | Allow |
Deny-Database-All
Étant donné que la règle de sécurité par défaut AllowVNetInBound autorise toutes les communications entre les ressources dans le même réseau virtuel, cette règle est nécessaire pour refuser le trafic à partir de toutes les ressources.
| Priorité | Source | Ports source | Destination | Ports de destination | Protocole | y accéder |
|---|---|---|---|---|---|---|
| 120 | * | * | AsgDb | 1433 | Quelconque | Deny |
Allow-Database-BusinessLogic
Cette règle autorise le trafic du groupe de sécurité d’application AsgLogic vers le groupe de sécurité d’application AsgDb. Cette règle est prioritaire par rapport à la règle Deny-Database-All. Par conséquent, cette règle est traitée avant la règle Deny-Database-All, c’est pourquoi le trafic en provenance du groupe de sécurité d’application AsgLogic est autorisé, tandis que tout autre trafic est bloqué.
| Priorité | Source | Ports source | Destination | Ports de destination | Protocole | y accéder |
|---|---|---|---|---|---|---|
| 110 | AsgLogic | * | AsgDb | 1433 | TCP | Autoriser |
Les interfaces réseau membres du groupe de sécurité d’application appliquent les règles qui les spécifient comme source ou destination. Les règles n’affectent pas les autres interfaces réseau. 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.
Les groupes de sécurité d’application ont les contraintes suivantes :
Le nombre de groupes de sécurité d’application que vous pouvez avoir dans un abonnement, ainsi que d’autres paramètres relatifs aux groupes de sécurité d’application, sont limités.
Toutes les interfaces réseau affectées à un groupe de sécurité d’application doivent exister dans le même réseau virtuel que celui où se trouve la première interface réseau affectée au groupe de sécurité d’application. Par exemple, si la première interface réseau assignée à un groupe de sécurité d’application nommé AsgWeb se trouve dans le réseau virtuel nommé VNet1, toutes les interfaces réseau suivantes affectées àAsgWeb doivent exister dans VNet1. Vous ne pouvez pas ajouter d’interfaces réseau à partir de différents réseaux virtuels au même groupe de sécurité d’application.
Si vous spécifiez un groupe de sécurité d’application en tant que source et destination dans une règle de sécurité, les interfaces réseau dans les deux groupes de sécurité d’application doivent se trouver dans le même réseau virtuel.
- Exemple : AsgLogic a des interfaces réseau de VNet1 et AsgDb a des interfaces réseau de VNet2. Dans ce cas, il serait impossible de désigner AsgLogic comme source et AsgDb comme destination dans une règle. Toutes les interfaces réseau pour les groupes de sécurité d’application source et destination doivent exister dans le même réseau virtuel.
Pour réduire le nombre de règles de sécurité dont vous avez besoin et la nécessité de modifier les règles, planifiez les groupes de sécurité d’application dont vous avez besoin et créez des règles à l’aide de balises de service ou des groupes de sécurité d’application, plutôt que des adresses IP individuelles ou des plages d’adresses IP, chaque fois que c’est possible.