Partager via

Appliquer les principes Confiance Zéro à un déploiement Azure Virtual WAN

  • Article

Remarque

Livestream à venir Rejoignez l’équipe Azure FastTrack qui discutera de cet article. 9 octobre 2024 | 10:00 – 11:00 (UTC-07:00) Heure du Pacifique (États-Unis et Canada) Inscrivez-vous ici.

Avec l'évolution du cloud moderne, des appareils mobiles et d'autres points de terminaison, il n'est plus suffisant de s'appuyer uniquement sur les pare-feux et les réseaux de périmètre de l'entreprise. Une stratégie de Confiance Zéro de bout en bout suppose que les violations de sécurité sont inévitables. Cela signifie que vous devez vérifier chaque demande comme si elle provient d'un réseau non contrôlé. La mise en réseau joue toujours un rôle important dans Confiance Zéro pour connecter et protéger l'infrastructure, les applications et les données. Dans le modèle de confiance zéro, il existe trois objectifs clés en matière de sécurisation de vos réseaux :

  • Soyez prêt à gérer les attaques avant qu'elles ne se produisent.
  • Réduisez l'étendue des dommages et la vitesse à laquelle ils se propagent.
  • Augmentez la difficulté de compromettre votre empreinte cloud.

Azure Virtual WAN permet une architecture réseau de transit global en fournissant une connectivité omniprésente et universelle entre les groupes distribués mondialement de charges de travail cloud dans les réseaux virtuels, les sites de succursale, les applications SaaS et PaaS, et les utilisateurs. L'adoption d'une approche Confiance Zéro dans Azure Virtual WAN est essentielle pour garantir que votre réseau principal est sécurisé et protégé.

Cet article fournit des étapes pour appliquer les principes de Confiance Zéro à un déploiement Azure Virtual WAN de la manière suivante :

Principe de Confiance Zéro Définition Respecté par
Vérifier explicitement Toujours s'authentifier et autoriser en fonction de tous les points de données disponibles. Utilisez un pare-feu Azure avec l'inspection TLS (protocole TLS) pour vérifier les risques et les menaces en fonction de toutes les données disponibles. Les contrôles d'accès conditionnel sont destinés à fournir l'authentification et l'autorisation par divers points de données et le pare-feu Azure n'effectue pas l'authentification utilisateur.
Utiliser le droit d'accès minimal Limitez l'accès utilisateur avec l'accès juste-à-temps et juste suffisant (JIT/JEA), des stratégies adaptatives basées sur les risques et une protection des données. L'accès utilisateur dépasse le cadre des déploiements d'infrastructure réseau Azure. L'utilisation de solutions d'identité telles que Privileged Access Management, l'accès conditionnel et d'autres contrôles permet de respecter ce principe.
Supposer une violation Réduisez le rayon d'explosion et segmentez l'accès. Vérifiez le chiffrement de bout en bout et utilisez l'analytique pour obtenir de la visibilité, détecter les menaces et améliorer les défenses. Chaque réseau virtuel Spoke n'a pas accès aux autres réseaux virtuels Spoke, sauf si le trafic est acheminé à travers le pare-feu intégré dans chaque Hub Azure Virtual WAN. Le pare-feu est défini sur refuser par défaut, ce qui autorise uniquement le trafic autorisé par les règles spécifiées. En cas de compromission ou de violation d'une application/charge de travail, la capacité de propagation est limitée, car le pare-feu Azure inspecte le trafic et ne transmet que le trafic autorisé. Seules les ressources de la même charge de travail seraient exposées à la violation dans la même application.

Pour plus d'informations sur l'application des principes de Confiance Zéro dans un environnement IaaS Azure, consultez la vue d'ensemble Appliquer les principes de Confiance Zéro à Azure IaaS.

Pour une discussion sectorielle sur Confiance Zéro, consultez la publication spéciale NIST 800-207.

Azure Virtual WAN

Azure Virtual WAN est un service de mise en réseau qui combine un grand nombre de fonctionnalités de mise en réseau, de sécurité et de routage pour fournir une interface opérationnelle unique. Voici quelques-unes des fonctionnalités principales :

  • Fonctionnalités de routage avancées
  • Intégration de la sécurité « bump-in-the-wire » via le pare-feu Azure ou les appliances virtuelles réseau prises en charge dans le hub
  • ExpressRoute chiffré

Une approche Confiance Zéro pour Azure Virtual WAN nécessite la configuration de plusieurs services et composants sous-jacents à partir de la table de principe Confiance Zéro précédemment répertoriée. Voici une liste d'étapes et d'actions :

  • Déployez le pare-feu Azure ou un pare-feu de nouvelle génération (NGFW) pris en charge à l'intérieur de chaque hub Virtual WAN.
  • Configurez le routage entre réseaux virtuels et branche locale pour créer un environnement de Confiance Zéro en envoyant tout le trafic aux appliances de sécurité dans les hubs pour inspection. Configurez le routage pour fournir un filtrage et une protection pour les menaces connues.
  • Assurez-vous qu'aucune ressource dans les Spokes n'a accès direct à Internet.
  • Fournissez la micro-segmentation des applications dans les réseaux Spoke, ainsi qu'une stratégie de micro-périmètres d'entrée/sortie.
  • Fournissez une observabilité pour les événements de sécurité réseau.

Architecture de référence

Le diagramme suivant illustre une architecture de référence commune qui illustre un environnement couramment déployé et comment appliquer les principes de Confiance Zéro à Azure Virtual WAN.

Diagramme de l’architecture de référence pour Azure Virtual Desktop.

Azure Virtual WAN est déployable dans les types De base et Standard. L'application des principes de Confiance Zéro pour Azure Virtual WAN avec Pare-feu Azure ou un NGFW nécessite le type Standard.

L'architecture de référence Azure Virtual WAN avec hubs sécurisés inclut :

  • Un Virtual WAN logique unique.
  • Deux hubs virtuels sécurisés, un par région.
  • Un instance de Pare-feu Azure Premium déployée dans chaque hub.
  • Au moins une stratégie Premium de pare-feu Azure.
  • Passerelles VPN de point à site (P2S) et de site à site (S2S) et ExpressRoute.
  • Branches connectées à P2S, S2S et ExpressRoute.
  • Un réseau virtuel de services partagés contenant des ressources d'infrastructure principales qui ne peuvent pas être déployées dans un hub Virtual WAN, tel que des machines virtuelles DNS personnalisées ou Azure DNS Private Resolver, des contrôleurs de domaine Active Directory Domain Services [AD DS], Azure Bastion et d'autres ressources partagées.
  • Réseaux virtuels de charge de travail avec Azure Application Gateway, un pare-feu d'applications web Azure (WAF) et des points de terminaison privés si nécessaire.

Azure Virtual WAN prend en charge l'intégration d'un ensemble limité de pare-feux tiers à l'intérieur de ses hubs comme alternative au pare-feu Azure natif. Cet article décrit uniquement le pare-feu Azure. Ce qui est inclus dans les services partagés de réseau virtuel Spoke dans l'architecture de référence n'est qu'un exemple de ce que vous pouvez déployer. Microsoft gère les hubs Azure Virtual WAN et vous ne pouvez rien installer d'autre dans ces hubs, sauf ce que le pare-feu Azure et les appliances virtuelles réseau prises en charge autorisent explicitement.

Cette architecture de référence s'aligne sur les principes architecturaux décrits dans l'article Cloud Adoption Framework pour la topologie de réseau Virtual WAN.

Sécurité du routage

La sécurisation de la propagation et de l'isolation des itinéraires de l'environnement local est un élément de sécurité critique qui doit être géré.

En dehors de la segmentation du trafic, la sécurité du routage est une partie essentielle de toute conception de sécurité réseau. Les protocoles de routage font partie intégrante de la plupart des réseaux, notamment Azure. Vous devez protéger votre infrastructure contre les risques inhérents au routage des protocoles tels que des configurations incorrectes ou des attaques malveillantes. Le protocole BGP utilisé pour VPN ou ExpressRoute offre des possibilités très riches de protéger votre réseau contre les modifications de routage non souhaitées, ce qui peut inclure la publication d'itinéraires trop spécifiques ou d'itinéraires trop larges.

La meilleure façon de protéger votre réseau consiste à configurer vos appareils locaux avec des stratégies de routage et des cartes de routage appropriées pour vous assurer que seuls les préfixes autorisés sont propagés dans votre réseau à partir d’Azure. Par exemple, vous pouvez :

  • Bloquez les préfixes entrants trop génériques.

    Si, en raison d'une configuration incorrecte, Azure commence à envoyer des préfixes génériques tels que 0.0.0.0/0 ou 10.0.0.0/8, il peut attirer le trafic susceptible de rester dans votre réseau local.

  • Bloquez les préfixes entrants trop spécifiques.

    Dans certaines circonstances, vous pouvez obtenir des préfixes IPv4 longs d'Azure (longueur de préfixe réseau de 30 à 32), qui sont généralement inclus dans d'autres préfixes moins spécifiques et ne sont donc pas obligatoires. La suppression de ces préfixes empêche vos tables de routage locales de croître inutilement.

  • Bloquez les préfixes entrants qui ne se trouvent pas dans Azure, sauf si vous utilisez Azure comme un réseau de transit.

    Si vous n'utilisez pas Azure pour transporter le trafic entre vos emplacements locaux (par exemple, avec des technologies telles qu'ExpressRoute Global Reach), un préfixe local publié à partir d'Azure indique une boucle de routage. Le fait de ne prendre que des préfixes Azure dans vos routeurs locaux vous protégerait de ce type de boucles de routage.

  • Bloquez les préfixes sortants qui ne sont pas locaux.

    Si vous n'utilisez pas votre réseau local pour le transit entre les régions Azure, vous ne devez pas publier sur Azure un préfixe que vous n'utilisez pas sur site. Si ce n'est pas le cas, vous risquez de créer des boucles de routage, en particulier compte tenu du fait que les implémentations eBGP dans la plupart des routeurs publient à nouveau tous les préfixes sur les liens non préférés. Cela a pour effet d'envoyer des préfixes Azure à Azure, sauf si vous avez configuré un eBGP à plusieurs chemins.

Architecture logique

Azure Virtual WAN est une collection de hubs et de services disponibles dans un hub. Vous pouvez déployer autant de Virtual WAN que nécessaire. Dans un hub Virtual WAN, il existe plusieurs services tels que VPN, ExpressRoute, Pare-feu Azure ou une appliance virtuelle réseau intégrée tierce.

Le diagramme suivant montre l'architecture logique de l'infrastructure Azure pour un déploiement Azure Virtual WAN, comme illustré dans le Cloud Adoption Framework.

Diagramme des composants de la topologie Azure Virtual WAN et des abonnements Azure.

La majorité des ressources sont contenues dans l'abonnement de connectivité. Vous déployez toutes les ressources Virtual WAN dans un seul groupe de ressources dans l'abonnement de connectivité, y compris lorsque vous effectuez le déploiement sur plusieurs régions. Les Spokes de réseau virtuel Azure se trouvent dans les abonnements de zone d'atterrissage. Si vous utilisez la stratégie de pare-feu Azure d'héritage et de hiérarchie, la stratégie parent et la stratégie enfant doivent se trouver dans la même région. Vous pouvez toujours appliquer une stratégie que vous avez créée dans une région sur un hub sécurisé à partir d'une autre région.

Que contient cet article ?

Cet article décrit les étapes à suivre pour appliquer les principes de Confiance Zéro dans l'architecture de référence Azure Virtual WAN.

Step Task Principe(s) de Confiance Zéro appliqué(s)
1 Créez une stratégie de pare-feu Azure. Vérifier explicitement
Supposer une violation
2 Convertissez vos hubs Azure Virtual WAN en hubs sécurisés. Vérifier explicitement
Supposer une violation
3 Sécurisez votre trafic. Vérifier explicitement
Supposer une violation
4 Sécurisez vos réseaux virtuels Spoke. Supposer une violation
5 Passez en revue votre utilisation du chiffrement. Supposer une violation
6 Sécurisez vos utilisateurs P2S. Supposer une violation
7 Configurez la surveillance, l'audit et la gestion. Supposer une violation

Vous devez effectuer les étapes 1 et 2 dans l'ordre. Les autres étapes peuvent être effectuées dans n'importe quel ordre.

Étape 1 : créer une stratégie de pare-feu Azure

Pour les déploiements du pare-feu Azure autonomes dans une architecture de réseau en étoile classique, au moins une stratégie Azure doit être créée dans Azure Firewall Manager et associée aux hubs Azure Virtual WAN. Cette stratégie doit être créée et rendue disponible avant la conversion d'un hub. Une fois la stratégie définie, elle est appliquée aux instances de pare-feu Azure à l'étape 2.

Les stratégies du pare-feu Azure peuvent être organisées dans une hiérarchie parent-enfant. Pour un scénario de réseau en étoile classique ou un Azure Virtual WAN managé, vous devez définir une stratégie racine avec un ensemble commun de règles de sécurité à l'échelle de l'informatique pour autoriser ou refuser le trafic. Ensuite, pour chaque hub, une stratégie enfant peut être définie pour implémenter des règles spécifiques au hub via l'héritage. Cette étape est facultative. Si les règles qui doivent être appliquées à chaque hub sont identiques, une stratégie unique peut être appliquée.

Pour Confiance Zéro, une stratégie de pare-feu Azure Premium est requise et doit inclure les paramètres suivants :

  • Proxy DNS : vous devez configurer un pare-feu Azure en tant que serveur DNS personnalisé pour les réseaux virtuels Spoke qui protègent le DNS réel qui réside dans un service partagé Spoke ou localement. Les pare-feux Azure agissent en tant que proxy DNS, écoutent sur le port UDP 53 et transfèrent les requêtes DNS aux serveurs DNS spécifiés dans les paramètres de stratégie. Pour chaque Spoke, vous devez configurer un serveur DNS au niveau du réseau virtuel pointant vers l'adresse IP interne du pare-feu Azure dans le hub Virtual WAN. Vous ne devez pas accorder l'accès réseau à partir de Spokes et de branches au DNS personnalisé.

  • L'inspection TLS doit être activée pour ces scénarios :

    • Inspection TLS du trafic sortant : pour vous protéger contre le trafic malveillant envoyé depuis un client interne hébergé dans Azure vers Internet.

    • Inspection TLS Est-Ouest : pour inclure le trafic en provenance ou à destination de branches locales et entre les Spokes Virtual WAN. Vous protégerez ainsi vos charges de travail Azure contre le trafic malveillant potentiel envoyé à partir d’Azure.

  • Le système de détection et de prévention des intrusions (IDPS) doit être activé en mode « Alerter et refuser ».

  • La veille des menaces doit être activée en mode « Alerter et refuser ».

Dans le cadre de la création de stratégie, vous devez créer les règles DNAT (Destination Network Address Translation) nécessaires, les règles réseau et les règles d'application pour activer uniquement les flux réseau pour le trafic explicitement autorisé. Pour activer l'inspection TLS pour les cibles sélectionnées, la règle d'application correspondante doit avoir le paramètre « Inspection TLS » activé. Lors de la création de règles dans les collections de règles, vous devez utiliser les « Destination » et « Type de destination » les plus restrictifs.

Étape 2 : convertir vos hubs Azure Virtual WAN en hubs sécurisés

Au cœur de l'approche de Confiance Zéro pour Azure Virtual WAN est le concept de hub Virtual WAN sécurisé (hub sécurisé). Un hub sécurisé est un hub Azure Virtual WAN doté d'un pare-feu Azure intégré. L'utilisation des appliances de sécurité prises en charge par des tiers est prise en charge comme alternative au pare-feu Azure, mais n'est pas décrite dans cet article. Vous pouvez utiliser ces appliances virtuelles pour inspecter tout le trafic Nord-Sud, Est-Ouest et lié à Internet.

Nous vous recommandons d'utiliser le pare-feu Azure Premium pour Confiance Zéro et de le configurer avec la stratégie Premium décrite à l'étape 1.

Remarque

L'utilisation de la protection DDoS n'est pas prise en charge avec un hub sécurisé.

Pour plus d'informations, consultez Installer un pare-feu Azure dans un hub Virtual WAN.

Étape 3 : sécuriser votre trafic

Une fois que vous avez mis à niveau tous vos hubs Azure Virtual WAN en hubs sécurisés, vous devez configurer l'intention de routage et les stratégies pour les principes de Confiance Zéro. Cette configuration permet au pare-feu Azure de chaque hub d'attirer et d'inspecter le trafic entre les Spokes et les branches du même hub et entre les hubs distants. Vous devez configurer vos stratégies pour envoyer à la fois le « trafic Internet » et le « trafic privé » via la pare-feu Azure ou votre appliance virtuelle réseau tierce. L'option « Inter-Hub » doit également être activée. Voici un exemple.

Exemple de la stratégie de routage du pare-feu Azure.

Lorsque la stratégie de routage « Trafic privé » est activée, le trafic de réseau virtuel entrant et sortant du hub Virtual WAN, y compris le trafic inter-hub, est transféré vers le tronçon suivant du pare-feu Azure ou de l'appliance virtuelle réseau spécifiée dans la stratégie. Les utilisateurs disposant de privilèges de contrôle d'accès en fonction du rôle (RBAC) peuvent remplacer la programmation de routage Virtual WAN pour les réseaux virtuels Spoke et associer un itinéraire défini par l'utilisateur personnalisé (UDR) pour contourner le pare-feu du hub. Pour éviter cette vulnérabilité, les autorisations RBAC permettant d'attribuer des UDR aux sous-réseaux de réseaux virtuels Spoke doivent être limitées aux administrateurs réseau centraux et non déléguées aux propriétaires de zones d'atterrissage des réseaux virtuels Spoke. Pour associer un UDR à un réseau virtuel ou à un sous-réseau, un utilisateur doit avoir le rôle Contributeur réseau ou un rôle personnalisé avec l'action ou l'autorisation « Microsoft.Network/routeTables/join/action ».

Remarque

Dans cet article, le pare-feu Azure est principalement pris en compte pour le contrôle du trafic Internet et du trafic privé. Pour le trafic Internet, une appliance virtuelle réseau de sécurité tierce prise en charge peut être utilisée ou un fournisseur de sécurité en tant que service (SECaaS) tiers. Pour le trafic privé, les appliances virtuelles réseau de sécurité tierces prises en charge peuvent être utilisées comme alternative au pare-feu Azure.

Remarque

Les tables de routage personnalisées dans Azure Virtual WAN ne peuvent pas être utilisées conjointement avec l'intention et les stratégies de routage et ne doivent pas être considérées comme une option de sécurité.

Étape 4 : sécuriser vos réseaux virtuels Spoke

Chaque hub Azure Virtual WAN peut avoir un ou plusieurs réseaux virtuels connectés avec le peering de réseaux virtuels. En fonction du modèle de zone d'atterrissage dans le Cloud Adoption Framework, chaque réseau virtuel contient une charge de travail de zone d'atterrissage, des applications et des services prenant en charge une organisation. Azure Virtual WAN gère la connexion, la propagation et l'association des itinéraires, ainsi que le routage sortant et entrant, mais ne peut pas affecter la sécurité intra-VNet. Les principes de Confiance Zéro doivent être appliqués à l'intérieur de chaque réseau virtuel Spoke conformément aux instructions publiées dans Appliquez les principes de Confiance Zéro à un réseau virtuel Spoke et à d'autres articles en fonction du type de ressource, tel que les machines virtuelles et le stockage. Considérez les éléments suivants :

Étant donné que le hub dans Azure Virtual WAN est verrouillé et géré par Azure, les composants personnalisés ne peuvent pas y être installés ou activés. Certaines ressources qui sont normalement déployées à l'intérieur du hub, dans un modèle de réseau en étoile classique, doivent être placées dans un ou plusieurs Spokes qui jouent le rôle de réseaux de ressources partagés. Par exemple :

  • Azure Bastion : Azure Bastion prend en charge Azure Virtual WAN, mais doit être déployé à l’intérieur d’un réseau virtuel spoke, car le hub est limité et géré par Azure. À partir du Spoke Azure Bastion, les utilisateurs peuvent accéder aux ressources dans d'autres réseaux virtuels, mais il nécessite une connexion basée sur IP disponible avec la référence SKU Azure Bastion Standard.
  • Serveurs DNS personnalisés : les logiciels serveur DNS peuvent être installés sur n'importe quelle machine virtuelle et agir en tant que serveur DNS pour tous les Spokes dans Azure Virtual WAN. Le serveur DNS doit être installé dans un réseau virtuel Spoke qui sert tous les autres Spokes directement, ou via la fonctionnalité de proxy DNS proposée par le pare-feu Azure intégrée au hub Virtual WAN.
  • Programme de résolution de DNS privé Azure : le déploiement d'un programme de résolution de DNS privé Azure est pris en charge dans l'un des réseaux virtuels Spoke connectés aux hubs Virtual WAN. Le pare-feu Azure qui est intégré au hub Virtual WAN peut utiliser cette ressource en tant que DNS personnalisé lorsque vous activez la fonctionnalité de proxy DNS.
  • Points de terminaison privés : ce type de ressource est compatible avec Virtual WAN, mais doit être déployé à l'intérieur d'un réseau virtuel Spoke. Cela permet de se connecter à un autre réseau virtuel ou à une autre branche connectée au même Virtual WAN, si le pare-feu Azure intégré autorise le flux. Des instructions sur la manière de sécuriser le trafic vers les points de terminaison privés à l'aide du pare-feu Azure intégré dans un hub Virtual WAN peuvent être trouvées dans Sécuriser le trafic destiné aux points de terminaison privés dans Azure Virtual WAN.
  • Zone de DNS privé Azure (liens) : ce type de ressource ne vit pas à l'intérieur d'un réseau virtuel, mais doit être lié à ces ressources pour fonctionner correctement. Des zones DNS privées ne peuvent pas être liées à un hub Virtual WAN. Au lieu de cela, elles doivent être connectées au réseau virtuel Spoke contenant des serveurs DNS personnalisés ou un programme de résolution de DNS privé Azure (recommandé) ou directement aux réseaux virtuels Spoke qui nécessitent les enregistrements DNS de cette zone.

Étape 5 : passer en revue votre chiffrement

Azure Virtual WAN fournit certaines fonctionnalités de chiffrement du trafic via ses propres passerelles pour le trafic entrant dans le réseau Microsoft. Dans la mesure du possible, le chiffrement doit être activé, en fonction du type de passerelle. Tenez compte du comportement de chiffrement par défaut suivant :

  • La passerelle VPN Virtual WAN S2S fournit un chiffrement lors de l'utilisation de la connexion VPN IPsec/IKE (IKEv1 et IKEv2).

  • La passerelle VPN Virtual WAN P2S fournit un chiffrement lors de l'utilisation de la connexion VPN utilisateur sur OpenVPN ou IPsec/IKE (IKEv2).

  • La passerelle ExpressRoute Virtual WAN ne fournit pas de chiffrement. Par conséquent, les mêmes considérations relatives à ExpressRoute autonome s'appliquent.

    • Uniquement pour les circuits ExpressRoute approvisionnés sur ExpressRoute Direct, il est possible de tirer parti du chiffrement MACsec fourni par la plateforme pour sécuriser les connexions entre vos routeurs de périphérie et les routeurs de périphérie de Microsoft.

    • Le chiffrement peut être établit à l'aide d'une connexion VPN IPsec/IKE à partir de votre réseau local vers Azure sur le peering privé d'un circuit Azure ExpressRoute. L'intention et les stratégies de routage prennent désormais en charge cette configuration avec des étapes de configuration supplémentaires requises, comme expliqué dans ExpressRoute chiffré.

  • Pour les appareils et appliances virtuelles réseau WAN à définition logicielle (SD-WAN) tiers intégrés au hub Virtual WAN, des fonctionnalités de chiffrement spécifiques doivent être vérifiées et configurées conformément à la documentation du fournisseur.

Une fois le trafic entré dans l'infrastructure réseau Azure via l'une des passerelles ou une appliance virtuelle réseau /SD-WAN, il n'existe aucun service ou fonctionnalité Virtual WAN spécifique qui fournit le chiffrement réseau. Si le trafic entre un hub et son réseau virtuel et hub à hub n'est pas chiffré, vous devez utiliser le chiffrement au niveau de l'application si nécessaire.

Remarque

Les Spokes Virtual WAN ne prennent pas en charge le chiffrement de réseau virtuel à réseau virtuel à l'aide de la passerelle VPN Azure, car un Spoke est nécessaire pour utiliser la passerelle distante du hub Virtual WAN.

Étape 6 : sécuriser vos utilisateurs P2S

Azure Virtual WAN est un service de mise en réseau qui combine un grand nombre de fonctionnalités réseau, de sécurité et de routage pour fournir une interface opérationnelle unique. Du point de vue de l'identité de l'utilisateur, le seul contact avec Virtual WAN se trouve dans la méthode d'authentification utilisée pour autoriser un VPN P2S d'utilisateur. Plusieurs méthodes d'authentification sont disponibles, mais nous vous recommandons de suivre les principes généraux de Confiance Zéro pour l'authentification Microsoft Entra. Avec Microsoft Entra ID, vous pouvez exiger que l'authentification multifacteur (MFA) et l'accès conditionnel appliquent les principes de Confiance Zéro aux appareils clients et aux identités utilisateur.

Remarque

L'authentification Microsoft Entra est uniquement disponible pour les passerelles qui utilisent le protocole OpenVPN, qui est uniquement prise en charge pour les connexions de protocole OpenVPN et nécessite le client Azure VPN Client.

Azure Virtual WAN et le pare-feu Azure ne fournissent pas de routage et de filtrage du trafic en fonction des noms de compte d'utilisateur ou de groupe, mais il est possible d'affecter différents groupes d'utilisateurs à différents pools d'adresses IP. Vous pouvez ensuite définir des règles sur le pare-feu Azure intégré pour restreindre les utilisateurs ou les groupes en fonction de leur pool d'adresses IP P2S attribué.

Si vous divisez vos utilisateurs P2S en différents groupes en fonction des exigences d'accès réseau, nous vous recommandons de les différencier au niveau du réseau et de vous assurez qu'ils ne peuvent accéder qu'à un sous-réseau du réseau interne. Vous pouvez créer plusieurs pools d'adresses IP pour Azure Virtual WAN. Pour plus d'informations, consultez Configurer des groupes d'utilisateurs et des pools d'adresses IP pour les VPN d'utilisateur P2S.

Étape 7 : configurer la surveillance, l'audit et la gestion

Azure Virtual WAN fournit des fonctionnalités de surveillance et de diagnostic étendues avec Azure Monitor. Des détails et une topologie supplémentaires peuvent être obtenus à l'aide d'un tableau de bord de surveillance prioritaire, prédéfini dans le portail Azure nommé Azure Monitor Insights pour Virtual WAN. Ces outils de surveillance ne sont pas spécifiques à la sécurité. Le pare-feu Azure déployé à l'intérieur de chaque hub Virtual WAN fournit le point d'intégration pour la Confiance Zéro et la surveillance de la sécurité. Vous devez configurer les diagnostics et la journalisation pour le pare-feu Azure de la même manière que pour les pare-feux Azure en dehors de Virtual WAN.

Le pare-feu Azure fournit les outils de surveillance suivants que vous devez utiliser pour garantir la sécurité et l'application correcte des principes de Confiance Zéro :

  • L'analytique des stratégies du pare-feu Azure fournit des insights, une visibilité centralisée et un contrôle au pare-feu Azure. La sécurité exige que les règles de pare-feu appropriées soient en place et efficaces pour protéger l'infrastructure interne. Le portail Azure récapitule les détails sur les « sources malveillantes potentielles » générées par les fonctionnalités IDPS et de veille des menaces du moteur de pare-feu.

  • Le classeur Pare-feu Azure constitue un canevas flexible pour l'analyse de données du Pare-feu Azure. Vous pouvez en tirer des insights sur les événements Pare-feu Azure, en savoir plus sur vos règles d'application et de réseau et voir les statistiques des activités de pare-feu à travers plusieurs URL, ports et adresses. Nous vous recommandons vivement de réviser régulièrement les statistiques du journal IDPS et, à partir de l'onglet Enquêtes, de vérifier le trafic refusé, les flux source et de destination et le rapport de veille des menaces pour examiner et optimiser les règles de pare-feu.

Le pare-feu Azure intègre également Microsoft Defender pour le cloud et Microsoft Sentinel. Nous vous recommandons vivement de configurer correctement les deux outils et de les utiliser activement pour la Confiance Zéro de manière suivante :

  • Avec l'intégration Microsoft Defender pour le cloud, vous pouvez visualiser l'état global de l'infrastructure réseau et de la sécurité réseau à un seul endroit, y compris la sécurité réseau Azure sur tous les réseaux virtuels et les hubs virtuels répartis entre différentes régions dans Azure. En un seul coup d'œil, vous pouvez voir le nombre de pare-feux Azure, de stratégies de pare-feu et de régions Azure où les pare-feux Azure sont déployés.
  • Une solution Microsoft Sentinel pour une intégration transparente du pare-feu Azure fournit la détection et la prévention des menaces. Une fois déployée, la solution autorise la détection des menaces personnalisable intégrée en plus de Microsoft Sentinel. La solution contient également un classeur, des détections, des requêtes de repérage et des guides opérationnels.

Formation pour les administrateurs

Les modules de formation suivants aident votre équipe à obtenir les compétences nécessaires pour appliquer les principes de Confiance Zéro à votre déploiement Azure Virtual WAN.

Introduction à Azure Virtual WAN

Formation Introduction à Azure Virtual WAN
Décrivez comment créer un réseau étendu (WAN) à l'aide des services réseau Azure Virtual WAN à définition logicielle.

Début >

Présentation du Pare-feu Azure

Formation Présentation du Pare-feu Azure
Décrivez comment le pare-feu Azure protège les ressources du réseau virtuel Azure, notamment les fonctionnalités, règles et options de déploiement du Pare-feu Azure, ainsi que l'administration avec Azure Firewall Manager.

Début >

Introduction à Azure Firewall Manager

Formation Introduction à Azure Firewall Manager
Décrivez comment vous pouvez utiliser Azure Firewall Manager pour centraliser la gestion des routes et des stratégies de sécurité pour vos périmètres de sécurité basés sur le cloud. Évaluez si Azure Firewall Manager peut aider à sécuriser vos périmètres cloud.

Début >

Conception et implémentation de la sécurité réseau

Formation Conception et implémentation de la sécurité réseau
Vous allez apprendre à concevoir et à implémenter des solutions de sécurité réseau telles qu'Azure DDoS, les groupes de sécurité réseau, le pare-feu Azure et le pare-feu d'applications web.

Début >

Pour plus de formation sur la sécurité dans Azure, consultez ces ressources dans le catalogue Microsoft :
Sécurité dans Azure

Étapes suivantes

Consultez ces articles supplémentaires pour appliquer les principes de Confiance Zéro à Azure :

Références

Reportez-vous à ces liens pour en savoir plus sur les différents services et technologies mentionnés dans cet article.

Azure Virtual WAN

Bases de référence de sécurité

Révision Well-Architected Framework

Sécurité Azure

Illustrations techniques

Vous pouvez télécharger les illustrations utilisées dans cet article. Utilisez le fichier Visio pour modifier ces illustrations pour votre propre utilisation.

PDF | Visio

Pour obtenir des illustrations techniques supplémentaires, cliquez ici.