Appliquer les principes Confiance Zéro visant à segmenter la communication réseau basée sur Azure

Cet article fournit de l’aide sur l’application des principes de Confiance Zéro pour segmenter des réseaux dans des environnements Azure. Voici les principes de Confiance Zéro.

Cet article fait partie d’une série d’articles qui expliquent comment appliquer les principes de la Confiance Zéro au réseau Azure.

À mesure que les organisations évoluent de petites entreprises en grandes entreprises, elles doivent souvent passer d’un seul abonnement Azure à plusieurs abonnements pour séparer les ressources de chaque service. Il est important de planifier soigneusement la segmentation de votre réseau pour créer des limites logiques et une isolation entre les environnements.

Chaque environnement, généralement reflétant un service distinct de votre organisation, doit disposer de ses propres autorisations d’accès et stratégies pour des charges de travail spécifiques. Par exemple, les utilisateurs de votre abonnement de développeur de logiciels internes ne doivent pas avoir accès à la gestion et au déploiement de ressources réseau dans l’abonnement de connectivité. Toutefois, ces environnements ont toujours besoin d’une connectivité réseau pour obtenir les fonctionnalités requises pour les services de base, tels que DNS, la connectivité hybride et être en mesure d’atteindre d’autres ressources sur différentes réseaux virtuels Azure.

La segmentation de votre infrastructure Azure fournit non seulement l’isolation, mais peut également créer des limites de sécurité qui empêchent un attaquant de se déplacer entre les environnements et d’infliger des dommages supplémentaires (la supposer une violation principe de Confiance Zéro).

Architecture de référence

Vous pouvez utiliser différents niveaux de segmentation dans Azure pour protéger vos ressources contre l’accès non autorisé ou les attaques malveillantes. Ces niveaux de segmentation commencent au niveau de l’abonnement et descendent jusqu’aux applications s’exécutant sur des machines virtuelles. La segmentation crée une limite qui sépare un environnement d’un autre, chacune avec ses propres règles et stratégies. Avec l’hypothèse que les violations peuvent se produire, vous devez segmenter vos réseaux pour empêcher leur propagation.

La mise en réseau Azure utilise les niveaux de segmentation suivants :

• Abonnements

  Un abonnement Azure est un conteneur logique utilisé pour provisionner des ressources dans Azure. Il est lié à un compte Azure dans un locataire Microsoft Entra ID et sert d’unité de facturation unique pour les ressources Azure affectées à l’abonnement. Un abonnement Azure est également une limite logique pour l’accès aux ressources contenues dans l’abonnement. L’accès entre les ressources dans différents abonnements nécessite des autorisations explicites.

• Réseaux virtuels

  Un réseau virtuel Azure est un réseau privé isolé qui permet par défaut à toutes les machines virtuelles qu’il contient de communiquer entre elles. Par défaut, les réseaux virtuels ne peuvent pas communiquer avec d’autres réseaux virtuels, sauf si vous créez des connexions entre eux via le peering, les connexions VPN ou ExpressRoute. Les réseaux virtuels individuels peuvent être utilisés comme limite d’approbation qui divise différentes applications, charges de travail, services ou organisations.

  Azure Virtual Network Manager (AVNM) est un service de gestion réseau qui permet à une équipe d’administration unique de gérer les réseaux virtuels et d’appliquer des règles de sécurité sur plusieurs abonnements à l’échelle mondiale. Vous pouvez utiliser AVNM pour définir des groupes de réseaux pour déterminer les réseaux virtuels qui peuvent communiquer entre eux. Vous pouvez également utiliser AVNM pour surveiller les modifications de configuration réseau.

• Charges de travail au sein d’un réseau virtuel

  Pour les charges de travail au sein d’un VNet, telles que les machines virtuelles ou les services PaaS qui prennent en charge l’intégration VNet, comme Azure Databricks et App Service, la communication est autorisée par défaut car elles sont contenues dans le même VNet et doivent être sécurisées davantage à l’aide de groupes de sécurité réseau. Les outils et services pour la segmentation au sein d’un réseau virtuel incluent les éléments suivants :

  • Pare-feu Azure

    Le Pare-feu Azure est un service déployé dans un réseau virtuel pour filtrer le trafic entre les ressources cloud, localement et Internet. Avec le Pare-feu Azure, vous pouvez définir des règles et des stratégies pour autoriser ou refuser le trafic sur les couches réseau et application. Vous pouvez également bénéficier des fonctions avancées de protection contre les menaces fournies par le Pare-feu Azure, telles que le système de détection et de prévention des intrusions (IDPS), l’inspection de la couche de transport (TLS) et le filtrage basé sur la veille des menaces.

  • Groupe de sécurité réseau

    Un groupe de sécurité réseau est un mécanisme de contrôle d’accès qui filtre le trafic réseau entre les ressources Azure, telles que les machines virtuelles au sein d’un réseau virtuel. Un groupe de sécurité réseau contient des règles de sécurité qui autorisent ou refusent le trafic au niveau du sous-réseau ou de la machine virtuelle dans un réseau virtuel. Une utilisation courante des groupes de sécurité réseau consiste à segmenter les ensembles de machines virtuelles dans différents sous-réseaux.

  • Groupe de sécurité d’application

    Un groupe de sécurité d’application est une extension d’un groupe de sécurité réseau qui vous permet de regrouper les interfaces réseau des machines virtuelles en fonction de leurs rôles et fonctions. Vous pouvez ensuite utiliser les groupes de sécurité d’application dans un groupe de sécurité réseau à grande échelle sans avoir à définir les adresses IP des machines virtuelles.

  • Azure Front Door

    Azure Front Door est le cloud réseau de distribution de contenu moderne de Microsoft (CDN) qui offre un accès rapide, fiable et sécurisé entre vos utilisateurs et le contenu web statique et dynamique de vos applications dans le monde entier.

Le diagramme suivant montre l’architecture de référence pour les niveaux de segmentation.

Dans le diagramme, les lignes rouges solides indiquent des niveaux de segmentation entre :

1. Abonnements Azure
2. VNets dans un abonnement
3. Sous-réseaux d’un réseau virtuel
4. Internet et un réseau virtuel

Le diagramme montre également un ensemble de réseaux virtuels gérés par AVNM qui peuvent s’étendre sur les abonnements Azure.

Que contient cet article ?

Les principes de Confiance Zéro sont appliqués dans l’architecture de référence dans le cloud Azure. Le tableau suivant décrit les recommandations pour segmenter les réseaux dans cette architecture afin d’adhérer au principe Supposer une violation principe de Confiance Zéro.

Étape 1 : Segmentez vos réseaux virtuels individuels

Dans un seul réseau virtuel d’un abonnement Azure, vous utilisez des sous-réseaux pour obtenir la séparation et la segmentation des ressources. Par exemple, dans un réseau virtuel, il peut y avoir un sous-réseau pour les serveurs de base de données, une autre pour les applications web et un sous-réseau dédié pour un Pare-feu Azure ou Azure Application Gateway avec un pare-feu d’applications web. Par défaut, toutes les communications entre les sous-réseaux sont activées au sein d’un réseau virtuel.

Pour créer une isolation entre les sous-réseaux, vous pouvez appliquer des groupes de sécurité réseau ou des groupes de sécurité d’application pour autoriser ou refuser un trafic réseau spécifique en fonction des adresses IP, des ports ou des protocoles. Toutefois, la conception et la gestion des groupes de sécurité réseau et des groupes de sécurité d’application peuvent également créer une surcharge de gestion.

Cette illustration montre une configuration courante et recommandée d’une application à trois niveaux avec des sous-réseaux distincts pour chaque niveau et l’utilisation de groupes de sécurité réseau et de groupes de sécurité d’application pour créer des limites segmentées entre chaque sous-réseau.

Vous pouvez également obtenir une segmentation des ressources en acheminant le trafic entre sous-réseaux à l’aide d’itinéraires définis par l’utilisateur pointant vers un Pare-feu Azure ou une appliance virtuelle réseau tierce( NVA). Le Pare-feu Azure et les appliances virtuelles réseau ont également la possibilité d’autoriser ou de refuser le trafic à l’aide des contrôles de couche 3 à couche 7. La plupart de ces services offrent des fonctionnalités de filtrage avancées.

Pour plus d’informations, consultez les instructions de Modèle 1 :Rréseau virtuel unique.

Étape 2 : Connecter plusieurs VNets avec le peering

Par défaut, il n’existe aucune communication autorisée entre les réseaux virtuels avec un seul abonnement Azure ou sur plusieurs abonnements. Plusieurs réseaux virtuels, chacun appartenant à différentes entités, ont leurs propres contrôles d’accès. Ils peuvent se connecter les uns aux autres ou à un réseau virtuel hub centralisé à l’aide du peering de réseaux virtuels, où un Pare-feu Azure ou une appliance virtuelle réseau tierce inspecte tout le trafic.

Cette illustration montre une connexion de peering de réseaux virtuels entre deux réseaux virtuels et l’utilisation du Pare-feu Azure à chaque fin de la connexion.

Un réseau virtuel hub contient généralement des composants partagés tels que des pare-feu, des fournisseurs d’identité et des composants de connectivité hybride, entre autres. La gestion des UDR devient plus simple, car l’ajout d’UDR spécifiques pour la micro-segmentation n’est nécessaire que si le trafic intra-VNet est requis. Toutefois, étant donné que le réseau virtuel a ses propres limites, les contrôles de sécurité sont déjà en place.

Pour plus d'informations, consultez le guide suivant :

• Pare-feu et Application Gateway pour réseaux virtuels
• Modèle 2 : plusieurs réseaux virtuels reliés par un Peering
• Appliquer les principes Confiance Zéro à un réseau virtuel spoke dans Azure
• Appliquer les principes Confiance Zéro à un réseau virtuel hub dans Azure

Étape 3 : Connecter plusieurs VNets dans une configuration en étoile.

Pour plusieurs réseaux virtuels dans une configuration hub-and-spoke, vous devez prendre en compte la façon de segmenter votre trafic réseau pour ces limites :

• Limite Internet
• Limite du réseau local
• Limites aux services Azure globaux

Limite Internet

La sécurisation du trafic Internet est une priorité fondamentale dans la sécurité réseau, ce qui implique la gestion du trafic d’entrée à partir d’Internet (non approuvé) et le trafic de sortie dirigé vers Internet (approuvé) à partir de vos charges de travail Azure.

Microsoft recommande que le trafic d’entrée à partir d’Internet dispose d’un point d’entrée unique. Microsoft encourage vivement le trafic d’entrée à traverser une ressource PaaS Azure, comme le Pare-feu Azure, Azure Front Door ou Azure Application Gateway. Ces ressources PaaS offrent plus de fonctionnalités qu’une machine virtuelle avec une adresse IP publique.

Pare-feu Azure

Cette illustration montre comment le Pare-feu Azure dans son propre sous-réseau agit comme un point d’entrée central et une limite de segmentation pour le trafic entre Internet et une charge de travail à trois niveaux dans un réseau virtuel Azure.

Pour plus d’informations, consultez Pare-feu Azure de Microsoft Azure Well-Architected Framework.

Azure Front Door

Azure Front Door peut agir comme une limite entre Internet et les services hébergés dans Azure. Azure Front Door prend en charge liaison privée connectivité aux ressources telles que l’équilibrage de charge interne (ILB) pour l’accès au réseau virtuel, les comptes de stockage pour les sites web statiques et le stockage d’objets blob et les services Azure App. Azure Front Door est généralement effectué pour les déploiements à grande échelle.

Azure Front Door est plus qu’un service d’équilibrage de charge. L’infrastructure Azure Front Door dispose d’une protection DDoS intégrée. Lorsque la mise en cache est activée, le contenu peut être récupéré à partir d’emplacements de point de présence (POP) plutôt que d’accéder constamment aux serveurs principaux. Lorsque le cache expire, Azure Front Door récupère la ressource demandée et met à jour le cache. Au lieu que les utilisateurs finaux accèdent à leurs serveurs, Azure Front Door utilise Split TCP pour deux connexions distinctes. Cela améliore non seulement l’expérience utilisateur final, mais empêche les acteurs malveillants d’accéder directement aux ressources.

Cette illustration montre comment Azure Front Door fournit une segmentation entre les utilisateurs Internet et les ressources Azure, qui peuvent se trouver dans des comptes de stockage.

Pour plus d’informations, consultez Azure Front Door dans Azure Well-Architected Framework.

Application Gateway Azure

Le point d’entrée Internet peut également être une combinaison de points d’entrée. Par exemple, le trafic HTTP/HTTPS peut entrer via une passerelle Application Gateway protégée par un pare-feu d’applications web ou Azure Front Door. Le trafic non HTTP/HTTPS tel que RDP/SSH peut entrer via le Pare-feu Azure ou une appliance virtuelle réseau. Vous pouvez utiliser ces deux éléments en tandem pour une inspection plus approfondie et contrôler le flux de trafic à l’aide des UDR.

Cette illustration montre le trafic d’entrée Internet et l’utilisation d’une passerelle Application Gateway avec un Pare-feu d’applications web pour le trafic HTTP/HTTPS et un pare-feu Azure pour tous les autres trafics.

Deux scénarios couramment recommandés sont les suivants :

• Placez un Pare-feu Azure ou une appliance virtuelle réseau en parallèle avec une passerelle Application Gateway.
• Placez un Pare-feu Azure ou une appliance virtuelle réseau après une passerelle Application Gateway pour une inspection supplémentaire du trafic avant d’atteindre la destination.

Pour plus d’informations, consultez Application Gateway Azure de Microsoft Azure Well-Architected Framework.

Voici des modèles courants supplémentaires pour les flux de trafic Internet.

Trafic d’entrée à l’aide de plusieurs interfaces

Une approche implique l’utilisation de plusieurs interfaces réseau sur des machines virtuelles lors de l’utilisation d’appliances virtuelles réseau : une interface pour le trafic non approuvé (externe) et une autre pour le trafic approuvé (accessible en interne). En termes de flux de trafic, vous devez router le trafic d’entrée de l’appliance virtuelle locale vers l’appliance virtuelle réseau à l’aide des UDR. Le trafic d’entrée provenant d’Internet reçu par l’appliance virtuelle réseau doit être acheminé vers la charge de travail de destination sur le réseau virtuel ou le sous-réseau approprié par une combinaison d’itinéraires statiques dans l’appliance de système d’exploitation invité et les UDR.

Trafic de sortie et UDRs

Pour le trafic qui quitte votre réseau virtuel pour Internet, vous pouvez appliquer un UDR à l’aide d’une table de routage avec l’appliance virtuelle réseau choisie comme tronçon suivant. Pour réduire la complexité, vous pouvez déployer un Pare-feu Azure ou une appliance virtuelle réseau à l’intérieur de votre hub Azure Virtual WAN et activer sécurité Internet avec l’intention de routage. Cela garantit que le trafic nord-sud (entrant et sortant d’une étendue réseau) et le trafic est-ouest (entre les appareils d’une étendue réseau) destiné aux adresses IP virtuelles non-Azure (ADRESSES IP virtuelles) sont inspectés.

Trafic de sortie et itinéraire par défaut

Certaines méthodes impliquent la gestion d’un itinéraire par défaut (0.0.0.0/0) avec différentes méthodes. En règle générale, il est recommandé que le trafic de sortie provenant d’Azure utilise des points de sortie et une inspection avec le Pare-feu Azure ou les appliances virtuelles réseau en raison de la quantité de débit que l’infrastructure Azure peut gérer, ce qui, dans la plupart des cas, peut être beaucoup plus grand et plus résilient. Dans ce cas, la configuration d’un itinéraire par défaut dans les UDR des sous-réseaux de charge de travail peut forcer le trafic vers ces points de sortie. Vous préférerez peut-être également acheminer le trafic de sortie d’un emplacement local vers Azure en tant que point de sortie. Dans ce cas, utilisez Serveur de routes Azure en combinaison avec une appliance virtuelle réseau pour publier un itinéraire par défaut vers un emplacement local à l’aide du protocole BGP (Border Gateway Protocol).

Il existe des cas spéciaux lorsque vous avez besoin que tout le trafic de sortie soit routé vers l’emplacement local en publiant un itinéraire par défaut sur BGP. Cela force le trafic en laissant le réseau virtuel être tunnelisé via votre réseau local vers un pare-feu à des fins d’inspection. Cette dernière approche est la moins souhaitée en raison d’une latence accrue et d’un manque de contrôles de sécurité fournis par Azure. Cette pratique est largement adoptée par les secteurs gouvernementaux et bancaires qui ont des exigences spécifiques pour l’inspection du trafic dans leur environnement local.

En termes d’échelle :

• Pour un seul réseau virtuel, vous pouvez utiliser des groupes de sécurité réseau, qui respectent strictement la sémantique de couche 4, ou vous pouvez utiliser un Pare-feu Azure qui respecte la sémantique de couche 4 et de couche 7.
• Pour plusieurs réseaux virtuels, un seul Pare-feu Azure peut toujours être utilisé s’il est accessible, ou vous pouvez déployer un pare-feu Azure dans chaque réseau virtuel et diriger le trafic avec des UDR.

Pour les grands réseaux distribués d’entreprise, vous pouvez toujours utiliser le modèle hub-and-spoke et diriger le trafic avec des UDR. Toutefois, cela peut entraîner une surcharge de gestion et des limites de peering de réseaux virtuels. Pour faciliter l’utilisation, Azure Virtual WAN peut le faire si vous déployez un Pare-feu Azure dans le hub virtuel et activez l’intention de routage pour la sécurité Internet. Cela permet d’injecter des itinéraires par défaut dans tous les réseaux des rayons et des succursales et d’envoyer le trafic Internet vers le Pare-feu Azure pour inspection. Le trafic privé destiné aux blocs d’adresses RFC 1918 est envoyé au Pare-feu Azure ou à l’appliance virtuelle réseau comme tronçon suivant désigné dans le hub Azure Virtual WAN.

Limite du réseau local

Dans Azure, les principales méthodes permettant d’établir une connectivité avec des réseaux locaux incluent des tunnels IPsec (Internet Protocol), des tunnels ExpressRoute ou des tunnels SD-WAN (Software-defined WAN). En règle générale, vous utilisez une connexion VPN site à site Azure (S2S) pour les charges de travail plus petites qui nécessitent moins de bande passante. Pour les charges de travail nécessitant un chemin de service dédié et des besoins de débit plus élevés, Microsoft recommande ExpressRoute.

Cette illustration montre les différents types de méthodes de connexion entre un environnement Azure et un réseau local.

Bien que les connexions VPN Azure puissent prendre en charge plusieurs tunnels, ExpressRoute est souvent configuré pour les réseaux d’entreprise plus volumineux qui nécessitent une bande passante plus élevée et des connexions privées via un partenaire de connectivité. Pour ExpressRoute, il est possible de connecter le même réseau virtuel à plusieurs circuits, mais à des fins de segmentation, cela n’est souvent pas idéal, car il permet aux réseaux virtuels de ne pas communiquer entre eux.

Une méthode de segmentation implique de choisir de ne pas utiliser une passerelle distante sur des réseaux virtuels spoke ou de désactiver la propagation de routage BGP si vous utilisez des tables de routage. Vous pouvez toujours segmenter les hubs connectés à ExpressRoute avec des appliances virtuelles réseau et des pare-feu. Pour les rayons qui sont connectés à des concentrateurs, vous pouvez choisir de ne pas utiliser la passerelle distante dans les propriétés d’interconnexion VNet. De cette manière, les rayons ne connaissent que les concentrateurs qui leur sont directement connectés, et non les itinéraires sur site.

Une autre approche émergente pour segmenter le trafic vers et à partir d’un site local est l’utilisation des technologies SD-WAN. Vous pouvez étendre vos emplacements de branche dans Azure SD-WAN à l’aide d’appliances virtuelles réseau tierces dans Azure pour créer une segmentation basée sur des tunnels SD-WAN provenant de différentes branches à l’intérieur des appliances NVA. Vous pouvez utiliser Serveur de routes Azure pour injecter les préfixes d’adresse pour les tunnels SD-WAN dans la plateforme Azure pour une topologie hub-and-spoke.

Pour une topologie virtual WAN, vous pouvez avoir une intégration directe de l’appliance virtuelle réseau SD-WAN tierce à l’intérieur du hub virtuel. Vous pouvez également utiliser des points de terminaison BGP pour autoriser l’utilisation de solutions SD-WAN, créant des tunnels à partir de l’appliance virtuelle réseau intégrée au hub virtuel.

Pour les deux modèles, vous pouvez utiliser ExpressRoute pour segmenter la connectivité privée ou publique sous-jacente avec le peering privé ou le peering Microsoft. Pour la sécurité, une pratique courante consiste à publier un itinéraire par défaut sur ExpressRoute. Cela oblige tout le trafic quittant le VNet à être acheminé vers le réseau de l’entreprise pour y être inspecté. De même, le trafic provenant à la fois d’un VPN et d’ExpressRoute peut être envoyé à une appliance virtuelle réseau pour une inspection plus approfondie. Cela s’applique également au trafic sortant d’Azure. Ces méthodes sont simples lorsque l’environnement est plus petit, comme une ou deux régions.

Pour les réseaux distribués volumineux, vous pouvez également utiliser Azure Virtual WAN en activant l’inspection du trafic privé à l’aide de l’intention de routage. Cela dirige tout le trafic destiné à une adresse IP privée de l’appliance virtuelle réseau à des fins d’inspection. Comme avec les méthodes ci-dessus, cela est beaucoup plus facile à gérer lorsque votre environnement s’étend sur plusieurs régions.

L’autre approche avec Azure Virtual WAN consiste à utiliser des tables de routage personnalisées pour les limites d’isolation. Vous pouvez créer des itinéraires personnalisés et associer et propager uniquement les réseaux virtuels que vous souhaitez utiliser pour ces tables de routage. Toutefois, cette fonctionnalité ne peut pas être combinée avec l’intention de routage aujourd’hui. Pour isoler les branches, vous pouvez affecter des étiquettes pour associer des branches à cette étiquette. Vous pouvez également désactiver la propagation vers l’étiquette par défaut par hub. Actuellement, vous ne pouvez pas isoler des branches individuelles dans Azure séparément sur un seul hub. Par exemple, vous ne pouvez pas isoler SD-WAN d’ExpressRoute. Mais sur un hub entier, vous pouvez désactiver la propagation vers l’étiquette par défaut.

Limites aux services Azure globaux

Dans Azure, la plupart des services sont accessibles par défaut via le WAN global Azure. Cela s’applique également à l’accès public aux services PaaS Azure. Par exemple, Stockage Azure dispose d’un pare-feu intégré qui peut restreindre l’accès aux réseaux virtuels et bloquer l’accès public. Toutefois, il est souvent nécessaire de contrôler plus granulairement. La préférence classique consiste à se connecter aux adresses IP virtuelles Azure en privé, plutôt que d’utiliser les adresses IP publiques par défaut fournies.

La méthode la plus courante pour restreindre l’accès aux ressources PaaS consiste à utiliser Azure Private Link. Lorsque vous créez un point de terminaison privé, il est injecté dans votre réseau virtuel. Azure utilise cette adresse IP privée pour tunneliser vers la ressource PaaS en question. Azure mappe un enregistrement DNS A au point de terminaison privé à l’aide de zones DNS privées Azure et mappe un enregistrement CNAME à la ressource PaaS de liaison privée.

Les points de terminaison de service offrent une autre méthode pour la connexion aux adresses IP virtuelles PaaS. Vous pouvez sélectionner des balises de service pour autoriser les connexions à toutes les ressources PaaS au sein de cette balise et fournir une connectivité privée à la ressource PaaS.

Une autre méthode courante implique l’utilisation du Peering Microsoft pour ExpressRoute. Si vous souhaitez vous connecter à des adresses IP virtuelles PaaS à partir d’un site local, vous pouvez configurer le Peering Microsoft. Vous pouvez choisir la communauté BGP pour que les adresses IP virtuelles soient consommées et cela est publié sur le chemin d’accès de peering Microsoft.

Pour plus d'informations, consultez le guide suivant :

• Pare-feu et Application Gateway pour réseaux virtuels
• Modèle 3 : Plusieurs réseaux virtuels dans un modèle hub-and-spoke

Résumé de segmentation

Ce tableau récapitule les différents niveaux de segmentation et de méthodes de sécurité.

Entraînement recommandé

• Configurer et gérer des réseaux virtuels pour les administrateurs Azure
• Présentation du pare-feu d’applications web Azure
• Sécuriser et isoler l’accès aux ressources Azure en utilisant des groupes de sécurité réseau et des points de terminaison de service
• Introduction à Azure Front Door
• Introduction à Azure Application Gateway
• Présentation d’Azure Private Link
• Introduction à Azure Virtual WAN
• Connecter votre réseau local à Azure avec une passerelle VPN

Étapes suivantes

Pour plus d’informations sur la mise en application de la Confiance Zéro aux réseaux Azure, consultez :

• Chiffrer les communications réseau basées sur Azure
• Gagner de la visibilité sur votre trafic réseau
• Interrompre les technologies de sécurité réseau héritées
• Sécuriser les réseaux avec la Confiance Zéro
• Réseaux virtuels Spoke dans Azure
• Réseaux virtuels Hub dans Azure
• Réseaux virtuels Spoke avec les services PaaS Azure
• Azure Virtual WAN

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 Network Manager
• Pare-feu Azure
• Groupes de sécurité réseau
• Groupes de sécurité d’application
• Azure Front Door
• Application Gateway Azure
• Pare-feu d’applications web
• Azure Private Link
• Azure Virtual WAN
• Sécurité Internet avec l’intention de routage
• Connexion VPN Azure Site-to-Site (S2S)
• Serveur de routes Azure