Façon dont les groupes de sécurité réseau filtrent le trafic
Vous pouvez utiliser un groupe de sécurité réseau Azure pour filtrer le trafic réseau à destination et en provenance 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 rejettent le trafic réseau entrant et sortant vers différents types de ressources Azure. Pour chaque règle, vous pouvez spécifier la source et la destination, le port et le protocole.
Vous pouvez déployer des ressources à partir de plusieurs services Azure dans un réseau virtuel Azure. Pour une liste complète, consultez Services pouvant être déployés dans un réseau virtuel. 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 :
Référez-vous à l’image précédente ainsi qu’au texte suivant pour comprendre comment Azure traite les règles entrantes et sortantes 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 la sécurité dans NSG1 sont traitées dans la mesure où elles sont associées à Subnet1 et VM1 est dans Subnet1. À 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. Ce trafic ainsi bloqué n’a pas ensuite été évalué par NSG2, car il est associé à l’interface réseau. Si NSG1 autorise toutefois le port 80 dans sa règle de sécurité, alors 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 étant donné que VM2 se trouve également dans Subnet1. 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é à Subnet2, le trafic est autorisé dans un sous-réseau et traité par NSG2, car NSG2 est associé à l’interface réseau attachée à VM3.
VM4 : le trafic est bloqué vers VM4, car aucun groupe de sécurité réseau n’est associé à Subnet3 ou à l’interface réseau dans la machine virtuelle. L’intégralité du trafic réseau est bloquée via une interface réseau et un sous-réseau si aucun groupe de sécurité réseau ne 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 : tout le trafic est envoyé via l’interface réseau au sous-réseau, étant donné que 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é à Subnet2.
VM4 : L’ensemble du trafic réseau est autorisé depuis VM4, car aucun groupe de sécurité réseau n’est associé à Subnet3 ou à l’interface réseau associée à la machine virtuelle.
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.
Notes
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. Pour en savoir plus sur les modèles de déploiement Azure, consultez l’article Déploiement Azure Resource Manager et déploiement classique : comprendre les modèles de déploiement et l’état de vos ressources.
Conseil
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.
Étapes suivantes
Pour en savoir plus sur les ressources Azure pouvant être déployées dans un réseau virtuel et auxquelles des groupes de sécurité réseau peuvent être associées, consultez Intégration d’un réseau virtuel pour les services Azure.
Si vous n’avez jamais créé un groupe de sécurité réseau, vous pouvez suivre un tutoriel rapide pour vous entraîner.
Si vous êtes familier avec les groupes de sécurité réseau et que vous devez en gérer un, consultez Gérer un groupe de sécurité réseau.
Si vous rencontrez des problèmes de communication et que vous avez besoin résoudre les problèmes de groupes de sécurité réseau, consultez Diagnostiquer un problème de filtre de trafic réseau sur une machine virtuelle.
Découvrez comment activer les journaux de flux de groupe de sécurité réseau pour analyser le trafic réseau vers et à partir des ressources auxquelles un groupe de sécurité réseau est associé.