Partager via


Planifier la segmentation du réseau de zone d’atterrissage

Cette section présente les principales recommandations pour la fourniture d’une segmentation du réseau interne hautement sécurisée à l’intérieur d’une zone d’atterrissage afin d’opérer une implémentation Confiance Zéro du réseau.

Considérations sur la conception

  • Le modèle Zero Trust part du principe d'un état considéré comme compromis et vérifie chaque requête comme si elle provenait d’un réseau non contrôlé.

  • Une implémentation avancée de réseau Zero Trust utilise des micro-périmètres d'entrée et de sortie cloud totalement distribués et une micro-segmentation plus approfondie.

  • Des groupes de sécurité réseau (NSG) peuvent utiliser des balises de service Azure pour faciliter la connectivité aux solutions PaaS (Platform as a Service) Azure.

  • Les groupes de sécurité d’application (ASG) ne fournissent pas et n’étendent pas de protection aux réseaux virtuels.

  • Utilisez les journaux de flux de réseau virtuel pour inspecter le trafic qui transite par des réseaux virtuels. Les journaux de flux de réseau virtuel fournissent des fonctionnalités similaires aux journaux de flux NSG, mais couvrent un plus large éventail de cas d’usage. L'étendue de la surveillance du trafic est également simplifiée, car vous pouvez activer la journalisation au niveau du réseau virtuel.

Remarque

Le 30 septembre 2027, les journaux de flux du groupe de sécurité réseau (NSG) seront supprimés. Dans le cadre de cette mise hors service, vous ne pourrez plus créer de journaux de flux de NSG à compter du 30 juin 2025. Nous vous recommandons de migrer vers des journaux de flux de réseau virtuel, ce qui permet de surmonter les limitations des journaux de flux NSG. Après la date de mise hors service, l’analytique du trafic activée avec les journaux de flux NSG n’est plus prise en charge, et les ressources de journaux de flux NSG existantes dans vos abonnements sont supprimées. Toutefois, les enregistrements des journaux de flux NSG ne seront pas supprimés et continueront de suivre leurs stratégies de rétention respectives. Pour plus d’informations, consultez l’avis de mise hors service.

Recommandations de conception

  • Déléguez la création de sous-réseau aux propriétaires de zone d’atterrissage. Cela permettra à ceux-ci de définir le mode de segmentation des charges de travail dans des sous-réseaux (par exemple, un seul grand sous-réseau, une application multiniveau ou une application injectée par réseau virtuel). L’équipe de plateforme peut utiliser Azure Policy pour s’assurer qu’un groupe de sécurité réseau avec des règles spécifiques (par exemple, refuser les connexions SSH entrantes ou les connexions RDP entrantes à partir d’Internet, ou autoriser/bloquer le trafic entre les zones d’atterrissage) est toujours associé aux sous-réseaux qui ont uniquement des stratégies de refus.

  • Utilisez des groupes de sécurité réseau pour protéger le trafic entre les sous-réseaux et le trafic est/ouest sur la plateforme (trafic entre les zones d’atterrissage).

  • L’équipe d’application doit utiliser des groupes de sécurité d’application dans les groupes de sécurité réseau au niveau du sous-réseau pour protéger des machines virtuelles multiniveaux au sein de leur zone d’atterrissage.

    Diagramme montrant comment fonctionne le groupe de sécurité des applications.Diagramme montrant comment fonctionne le groupe de sécurité des applications.

  • Utilisez des groupes de sécurité réseau et des groupes de sécurité d’application pour le trafic de micro-segment à l’intérieur de la zone d’atterrissage, et évitez d’utiliser une appliance virtuelle réseau centrale pour filtrer les flux de trafic.

  • Activez les journaux de flux du réseau virtuel et utilisez l'analyse du trafic pour obtenir des informations sur les flux de trafic d'entrée et de sortie. Activez les journaux de flux sur tous les réseaux et sous-réseaux virtuels stratégiques de vos abonnements (par exemple, des réseaux et sous-réseaux virtuels qui contiennent des contrôleurs de domaine Windows Server Active Directory, ou encore des magasins de données critiques). Par ailleurs, journaux de flux vous permettent de détecter et d'examiner les incidents de sécurité potentiels, la conformité et la surveillance, et d'optimiser l’utilisation.

  • Planifiez et migrez la configuration actuelle des journaux de flux NSG vers les journaux de flux de réseau virtuel. Consultez Migrer les journaux de flux NSG.

  • Utilisez des groupes de sécurité réseau pour autoriser de manière sélective la connectivité entre zones d’atterrissage.

  • Pour les topologies Virtual WAN, routez le trafic dans les zones d’atterrissage via le Pare-feu Azure si votre organisation requiert des fonctionnalités de filtrage et de journalisation pour le trafic circulant dans les zones d’atterrissage.

  • Si votre organisation décide d’implémenter le tunneling forcé (publier l’itinéraire par défaut) au niveau local, nous vous recommandons d’incorporer les règles NSG sortantes suivantes pour refuser le trafic de sortie des réseaux virtuels destiné directement à Internet en cas d’annulation de la session BGP.

Remarque

Les priorités des règles doivent être ajustées en fonction de votre ensemble de règles NSG existant.

Priorité Nom Source Destination Service Action Remarque
100 AllowLocal Any VirtualNetwork Any Allow Autorise le trafic pendant les opérations normales. Une fois le tunneling forcé activé, 0.0.0.0/0 est considéré comme faisant partie de l’étiquette VirtualNetwork tant que BGP l'annonce à la passerelle ExpressRoute ou VPN.
110 DenyInternet Any Internet Any Deny Bloquer le trafic réseau destiné directement à Internet si le chemin 0.0.0.0/0 est retiré des itinéraires publiés (par exemple, en raison d’une panne ou d’une mauvaise configuration).

Attention

Les services PaaS Azure qui peuvent être injectés dans un réseau virtuel peuvent ne pas être compatibles avec le tunneling forcé. Les opérations de plan de contrôle peuvent toujours nécessiter une connectivité directe à des adresses IP publiques spécifiques pour que le service fonctionne correctement. Il est recommandé de consulter la documentation de service spécifique pour connaître les exigences réseau et d’exempter éventuellement le sous-réseau de service de la propagation de route par défaut. Les étiquettes de service dans l’itinéraire défini par l’utilisateur peuvent être utilisées pour contourner l’itinéraire par défaut et rediriger le trafic du plan de contrôle uniquement si l’étiquette de service spécifique est disponible.