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

Article
04/13/2024

Cet article fournit une aide pour appliquer les principes de Confiance Zéro pour chiffrer la communication réseau vers, depuis et dans les environnements Azure des manières suivantes.

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.	Utilisation de stratégies d’accès conditionnel pour vos connexions de passerelle VPN Azure, et de SSH (Secure Shell) et RDP (Remote Desktop Protocol) pour vos connexions utilisateur-à-machine virtuelle.
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.	Configuration de vos appareils Microsoft Enterprise Edge (MSEE) pour utiliser la clé d’association de connectivité statique (CAK) pour Azure ExpressRoute avec des ports directs et utilisation d’une identité managée pour authentifier les ressources de circuit ExpressRoute.
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.	Protection du trafic réseau avec des méthodes et protocoles de chiffrement qui assurent la confidentialité, l’intégrité et l’authenticité de vos données en transit. Utilisation d’Azure Monitor pour fournir des métriques et des alertes de performances réseau ExpressRoute. Utilisation d’Azure Bastion pour gérer des sessions individuelles à partir du service Bastion et supprimer ou forcer une déconnexion.

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.

Les niveaux de chiffrement pour le trafic réseau sont les suivants :

Chiffrement de la couche réseau
- Sécuriser et vérifier la communication entre Internet ou votre réseau local et les réseaux virtuels et machines virtuelles Azure
- Sécuriser et vérifier la communication dans les réseaux virtuels Azure et entre
Chiffrement de la couche Application
- Protection pour les applications web Azure
Protection pour les charges de travail exécutées sur des machines virtuelles

Architecture de référence

Le diagramme suivant montre l’architecture de référence dans le cadre de l’application des principes Confiance Zéro avec une communication chiffrée entre les utilisateurs et les administrateurs locaux ou sur Internet et les composants dans l’environnement Azure pour les étapes décrites dans cet article.

Dans le diagramme, les chiffres correspondent aux étapes dans les sections suivantes.

Que contient cet article ?

Les principes Confiance Zéro sont appliqués dans l’architecture de référence, depuis les utilisateurs et administrateurs sur Internet ou votre réseau local jusqu’au cloud Azure. Le tableau suivant décrit les recommandations permettant de garantir le chiffrement du trafic réseau dans cette architecture.

Step	Task	Principe(s) de Confiance Zéro appliqué(s)
1	Implémenter le chiffrement de la couche réseau.	Vérifier explicitement Utiliser le droit d'accès minimal Supposer une violation
2	Sécuriser et vérifier la communication entre un réseau local et les réseaux virtuels Azure.	Vérifier explicitement Supposer une violation
3	Sécuriser et vérifier la communication dans les réseaux virtuels Azure et entre.	Supposer une violation
4	Implémenter le chiffrement de la couche Application.	Vérifier explicitement Supposer une violation
5	Utiliser Azure Bastion pour protéger les machines virtuelles Azure.	Supposer une violation

Étape 1 : Implémenter le chiffrement de la couche réseau

Le chiffrement de la couche réseau est essentiel lors de l’application des principes Confiance Zéro à votre environnement local et Azure. Lorsque le trafic réseau passe sur Internet, vous devez toujours partir du principe qu’une interception du trafic par des attaquants est possible et que vos données peuvent être exposées ou altérées avant qu’elles n’atteignent leur destination. Étant donné que les fournisseurs de services contrôlent la façon dont les données sont routées via Internet, vous souhaitez vous assurer que la confidentialité et l’intégrité de vos données sont conservées, du moment où elles quittent votre réseau local jusqu’à ce qu’elles arrivent dans le cloud de Microsoft.

Le diagramme suivant montre l’architecture de référence de l’implémentation du chiffrement de la couche réseau.

Dans les deux prochaines sections, nous abordons la sécurité du protocole Internet (IPsec) et Media Access Control Security (MACsec), quels services réseau Azure prennent en charge ces protocoles et comment vous assurer qu’ils sont utilisés.

IPsec

IPsec est un groupe de protocoles qui assure la sécurité des communications IP (Internet Protocol). Il authentifie et chiffre les paquets réseau à l’aide d’un ensemble d’algorithmes de chiffrement. IPSec est le protocole d’encapsulation de sécurité utilisé pour établir des réseaux privés virtuels (VPN). Un tunnel VPN IPsec se compose de deux phases. La phase 1 est appelée mode principal, tandis que la phase 2 est appelée mode rapide.

La phase 1 du protocole IPsec est l’établissement du tunnel, où les pairs négocient les paramètres pour l’association de sécurité IKE (Internet Key Exchange), comme le chiffrement, l’authentification, le hachage et les algorithmes Diffie-Hellman. Pour vérifier leurs identités, les homologues échangent une clé prépartagée. La phase 1 du protocole IPsec peut fonctionner sous deux modes : mode principal ou mode agressif. La passerelle VPN Azure prend en charge deux versions d’IKE, IKEv1 et IKEv2, et fonctionne uniquement en mode principal. Le mode principal garantit le chiffrement de l’identité de la connexion entre la passerelle VPN Azure et l’appareil local.

Dans la phase 2 du protocole IPsec, les homologues négocient les paramètres de sécurité pour la transmission des données. Dans cette phase, les deux homologues acceptent les algorithmes de chiffrement et d’authentification, la valeur de durée de vie de l’association de sécurité (SA) et les sélecteurs de trafic (TS) qui définissent le trafic chiffré sur le tunnel IPsec. Le tunnel créé à la phase 1 sert de canal sécurisé pour cette négociation. IPsec peut sécuriser les paquets IP à l’aide du protocole AH (Authentication Header) ou du protocole ESP (Encapsulating Security Payload). AH fournit l’intégrité et l’authentification, tandis qu’ESP assure aussi la confidentialité (chiffrement). La phase 2 du protocole IPsec peut fonctionner en mode transport ou en mode tunnel. En mode transport, seule la charge utile du paquet IP est chiffrée, tandis qu’en mode tunnel, le paquet IP entier est chiffré et un nouvel en-tête IP est ajouté. La phase 2 du protocole IPsec peut être établie sur IKEv1 ou IKEv2. L’implémentation actuelle d’IPsec de la passerelle VPN Azure prend uniquement en charge ESP en mode tunnel.

Parmi les services Azure qui prennent en charge IPsec, citons notamment :

Passerelle VPN Azure
- Connexions VPN de site à site
- Connexions de réseau virtuel à réseau virtuel
- Connexions point à site
Azure Virtual WAN
- Sites VPN
- Configurations de VPN utilisateur

Vous n’avez à modifier aucun paramètre pour activer IPsec pour ces services. Ils sont activés par défaut.

MACsec et Azure Key Vault

MACsec (IEEE 802.1AE) est une norme de sécurité réseau qui applique le principe Confiance Zéro Supposer une violation au niveau de la couche de liaison de données en fournissant l’authentification et le chiffrement sur une liaison Ethernet. MACsec suppose que tout trafic réseau, même dans le même réseau local, peut être compromis ou intercepté par des acteurs malveillants. MACsec vérifie et protège chaque trame à l’aide d’une clé de sécurité partagée entre deux interfaces réseau. Cette configuration ne peut être effectuée qu’entre deux appareils compatibles MACsec.

MACsec est configuré avec des associations de connectivité, qui constituent un ensemble d’attributs que les interfaces réseau utilisent pour créer des canaux de sécurité entrants et sortants. Une fois créé, le trafic sur ces canaux est échangé sur deux liaisons sécurisées MACsec. MACsec a deux modes d’association de connectivité :

Mode de clé d’association de connectivité (CAK) statique : Les liaisons sécurisées MACsec sont établies à l’aide d’une clé prépartagée qui comprend un nom de clé d’association de connectivité (CKN) et la clé CAK attribuée. Ces clés sont configurées aux deux extrémités de la liaison.
Mode CAK dynamique : Les clés de sécurité sont générées de façon dynamique à l’aide du processus d’authentification 802.1x, qui peut utiliser un appareil d’authentification centralisée tel qu’un serveur RADIUS (Remote Authentication Dial-In User Service).

Les appareils Microsoft Enterprise Edge (MSEE) prennent en charge la clé CAK statique en stockant la clé CAK et le nom CKN dans un coffre de clés Azure lorsque vous configurez Azure ExpressRoute avec des ports directs. Pour accéder aux valeurs dans le coffre de clés Azure, configurez l’identité managée pour authentifier la ressource de circuit ExpressRoute. Cette approche suit le principe Confiance Zéro Utiliser le droit d’accès minimal, car seuls les appareils autorisés peuvent accéder aux clés du coffre de clés Azure. Pour plus d’informations, consultez Configurer MACsec sur les ports ExpressRoute Direct.

Étape 2 : Sécuriser et vérifier la communication entre un réseau local et les réseaux virtuels Azure

À mesure que la migration cloud devient de plus en plus répandue dans les entreprises de différentes tailles, la connectivité hybride joue un rôle clé. Il est essentiel non seulement de sécuriser et de protéger, mais aussi de vérifier et de surveiller la communication réseau entre votre réseau local et Azure.

Le diagramme suivant montre l’architecture de référence pour sécuriser et vérifier la communication entre un réseau local et les réseaux virtuels Azure.

Azure propose deux options pour connecter votre réseau local aux ressources d’un réseau virtuel Azure :

La passerelle VPN Azure vous permet de créer un tunnel VPN site à site à l’aide d’IPsec pour chiffrer et authentifier la communication réseau entre votre réseau à votre siège ou vos filiales et un réseau virtuel Azure. Elle permet également à des clients individuels d’établir une connexion point à site pour accéder aux ressources d’un réseau virtuel Azure sans périphérique VPN. Pour adhérer à la Confiance Zéro, configurez l’authentification Microsoft Entra ID et les stratégies d’accès conditionnel pour vos connexions de passerelle VPN Azure afin de vérifier l’identité et la conformité des appareils connectés. Pour plus d’informations, consultez Utiliser une passerelle VPN Microsoft Tunnel avec des stratégies d’accès conditionnel.
Azure ExpressRoute fournit une connexion privée avec une bande passante élevée qui vous permet d’étendre votre réseau local à Azure avec l’aide d’un fournisseur de connectivité. Étant donné que le trafic réseau ne passe pas sur l’Internet public, les données ne sont pas chiffrées par défaut. Pour chiffrer votre trafic via ExpressRoute, configurez un tunnel IPsec. Toutefois, gardez à l’esprit que lors de l’exécution de tunnels IPsec sur ExpressRoute, la bande passante est limitée à la bande passante du tunnel et vous risquez de devoir exécuter plusieurs tunnels pour qu’elle corresponde à la bande passante du circuit ExpressRoute. Pour plus d’informations, consultez Connexions VPN site à site sur un peering privé ExpressRoute - Passerelle VPN Azure.

Si vous utilisez des ports ExpressRoute Direct, vous pouvez augmenter la sécurité réseau en activant l’authentification lors de l’établissement d’homologues BGP ou configurer MACsec pour sécuriser la communication de couche 2. MACsec fournit le chiffrement pour les trames Ethernet afin de garantir la confidentialité, l’intégrité et l’authenticité des données entre votre routeur de périphérie et le routeur de périphérie de Microsoft.

Azure ExpressRoute prend également en charge Azure Monitor qui fournit des métriques et des alertes de performances réseau.

Le chiffrement peut protéger vos données contre des interceptions non autorisées, mais il introduit aussi une couche supplémentaire de traitement pour le chiffrement et le déchiffrement du trafic réseau qui peut affecter les performances. Le trafic réseau qui transite sur Internet peut également être imprévisible, car il doit passer par plusieurs périphériques réseau qui peuvent introduire une latence réseau. Pour éviter les problèmes de performances, Microsoft recommande d’utiliser ExpressRoute parce qu’il offre des performances réseau fiables et une allocation de bande passante que vous pouvez personnaliser pour votre charge de travail.

Lorsque vous choisissez entre la passerelle VPN Azure ou ExpressRoute, tenez compte des questions suivantes :

À quels types de fichiers et d’applications accédez-vous entre votre réseau local et Azure ? Avez-vous besoin d’une bande passante avec une certaine régularité pour transférer de grands volumes de données ?
Avez-vous besoin d’une latence stable et faible pour que vos applications s’exécutent de manière optimale ?
Avez-vous besoin de surveiller les performances et l’intégrité du réseau de votre connectivité hybride ?

Si vous avez répondu oui à l’une de ces questions, vous avez tout intérêt à choisir Azure ExpressRoute comme méthode principale de connexion de votre réseau local à Azure.

Il existe deux scénarios courants où ExpressRoute et la passerelle VPN Azure peuvent coexister :

La passerelle VPN Azure peut être utilisée pour connecter vos filiales à Azure tandis que votre siège est connecté avec ExpressRoute.
Vous pouvez également utiliser la passerelle VPN Azure comme connexion de secours à Azure pour votre siège si votre service ExpressRoute est en panne.

Étape 3 : Sécuriser et vérifier la communication dans les réseaux virtuels Azure et entre

Le trafic au sein d’Azure a un niveau de chiffrement sous-jacent. Lorsque le trafic se déplace entre des réseaux virtuels dans différentes régions, Microsoft utilise MACsec pour chiffrer et authentifier le trafic de peering au niveau de la couche de liaison de données.

Le diagramme suivant montre l’architecture de référence pour sécuriser et vérifier la communication dans les réseaux virtuels Azure et entre.

Toutefois, le chiffrement seul n’est pas suffisant pour garantir une Confiance Zéro. Vous devez également vérifier et surveiller la communication réseau au sein des réseaux virtuels Azure et entre. Un chiffrement et une vérification supplémentaires entre les réseaux virtuels sont possibles avec l’aide de la passerelle VPN Azure ou des appliances virtuelles réseau (NVA), mais ce n’est pas une pratique courante. Microsoft recommande de concevoir votre topologie de réseau pour utiliser un modèle d’inspection du trafic centralisé qui peut appliquer des stratégies affinées et détecter des anomalies.

Pour réduire la surcharge de configuration d’une passerelle VPN ou d’une appliance virtuelle, activez la fonctionnalité de chiffrement de réseau virtuel pour certaines tailles de machine virtuelle afin de chiffrer et de vérifier le trafic entre les machines virtuelles au niveau de l’hôte, au sein d’un réseau virtuel et sur les peerings de réseaux virtuels.

Étape 4 : Implémenter le chiffrement au niveau de la couche Application

Le chiffrement de la couche Application joue un facteur clé dans la Confiance Zéro qui impose que toutes les données et communications soient chiffrées lorsque les utilisateurs interagissent avec des applications web ou des appareils. Le chiffrement de la couche Application garantit que seules les entités vérifiées et approuvées peuvent accéder aux applications web ou aux appareils.

Le diagramme suivant montre l’architecture de référence de l’implémentation du chiffrement au niveau de la couche Application.

L’un des exemples les plus courants de chiffrement au niveau de la couche Application est le protocole HTTPS (Hypertext Transfer Protocol Secure), qui chiffre les données entre un navigateur web et un serveur web. HTTPS utilise le protocole TLS (Transport Layer Security) pour chiffrer la communication client-serveur, ainsi qu’un certificat numérique TLS pour vérifier l’identité et la fiabilité du site web ou du domaine.

Un autre exemple de sécurité de la couche Application est SSH (Secure Shell) et RDP (Remote Desktop Protocol) qui chiffrent les données entre le client et le serveur. Ces protocoles prennent également en charge l’authentification multifacteur et les stratégies d’accès conditionnel pour s’assurer que seuls les utilisateurs ou appareils autorisés et conformes peuvent accéder aux ressources distantes. Consultez l’étape 5 pour obtenir des informations sur la sécurisation des connexions SSH et RDP aux machines virtuelles Azure.

Protection pour les applications web Azure

Vous pouvez utiliser Azure Front Door ou Azure Application Gateway pour protéger vos applications web Azure.

Azure Front Door

Azure Front Door est un service de distribution à l’échelle mondiale qui optimise la distribution de contenu aux utilisateurs finaux via les emplacements en périphérie de Microsoft. Avec des fonctionnalités, telles que Web Application Firewall (WAF) et le service Private Link, vous pouvez détecter et bloquer les attaques malveillantes sur vos applications web à la périphérie du réseau Microsoft tout en accédant en privé à vos origines à l’aide du réseau interne Microsoft.

Pour protéger vos données, le trafic vers les points de terminaison Azure Front Door est protégé à l’aide du protocole HTTPS avec TLS de bout en bout pour tout le trafic vers et depuis ses points de terminaison. Le trafic est chiffré du client vers l’origine et de l’origine vers le client.

Azure Front Door gère les requêtes HTTPS et détermine quel point de terminaison dans son profil a le nom de domaine associé. Ensuite, il vérifie le chemin d’accès et détermine quelle règle d’acheminement correspond au chemin d’accès de la requête. Si la mise en cache est activée, Azure Front Door vérifie son cache pour voir s’il existe une réponse valide. S’il n’existe aucune réponse valide, Azure Front Door sélectionne la meilleure origine qui peut servir le contenu demandé. Avant l’envoi de la requête à l’origine, un ensemble de règles peut être appliqué à la requête pour changer l’en-tête, la chaîne de requête ou la destination de l’origine.

Azure Front Door prend en charge le protocole TLS front-end et back-end. Le protocole TLS front-end chiffre le trafic entre le client et Azure Front Door. Le protocole TLS back-end chiffre le trafic entre Azure Front Door et l’origine. Azure Front Door prend en charge TLS 1.2 et TLS 1.3. Vous pouvez configurer Azure Front Door pour utiliser un certificat TLS personnalisé ou un certificat géré par Azure Front Door.

Remarque

Vous pouvez également utiliser la fonctionnalité Private Link pour la connectivité aux appliances virtuelles réseau afin qu’une inspection supplémentaire des paquets soit effectuée.

Application Gateway Azure

Azure Application Gateway est un équilibreur de charge régional qui fonctionne au niveau de la couche 7. Il achemine et distribue le trafic web en fonction des attributs d’URL HTTP. Il peut acheminer et distribuer le trafic à l’aide de trois approches différentes :

HTTP uniquement : Application Gateway reçoit et achemine les requêtes HTTP entrantes vers la destination appropriée sous une forme non chiffrée.
Terminaison SSL : Application Gateway déchiffre les requêtes HTTPS entrantes au niveau de l’instance, les inspecte et les achemine non chiffrées vers la destination.
TLS de bout en bout : Application Gateway déchiffre les requêtes HTTPS entrantes au niveau de l’instance, les inspecte et les rechiffre avant de les acheminer vers la destination.

TLS de bout en bout est la solution la plus sécurisée, car elle permet de chiffrer et de transmettre les données sensibles en exigeant l’utilisation de certificats d’authentification ou de certificats racines approuvés. Elle exige également de charger ces certificats sur les serveurs back-end et de s’assurer que ces serveurs back-end sont connus d’Application Gateway. Pour plus d’informations, consultez Configurer TLS de bout en bout avec Application Gateway.

De plus, les utilisateurs locaux ou les utilisateurs sur les machines virtuelles d’un autre réseau virtuel peuvent utiliser le front-end interne d’Application Gateway avec les mêmes fonctionnalités TLS. En plus du chiffrement, Microsoft vous recommande d’activer toujours WAF pour une plus grande protection front-end de vos points de terminaison.

Étape 5 : Utiliser Azure Bastion pour protéger les machines virtuelles Azure

Azure Bastion est un service PaaS managé qui vous permet de vous connecter en toute sécurité à vos machines virtuelles via une connexion TLS. Cette connectivité peut être établie depuis le portail Azure ou via un client natif à l’adresse IP privée sur la machine virtuelle. Les avantages d’utiliser Bastion comprennent :

Les machines virtuelles Azure n’ont pas besoin d’une adresse IP publique. Les connexions sont sur le port TCP 443 pour HTTPS et peuvent traverser la plupart des pare-feu.
Les machines virtuelles sont protégées contre l’analyse des ports.
La plateforme Azure Bastion est constamment mise à jour et protégée contre les attaques zero-day.

Avec Bastion, vous pouvez contrôler la connectivité RDP et SSH à votre machine virtuelle à partir d’un point d’entrée unique. Vous pouvez gérer des sessions individuelles à partir du service Bastion dans le portail Azure. Vous pouvez également supprimer ou forcer la déconnexion d’une session distante en cours si vous pensez qu’un utilisateur n’est pas censé se connecter à cette machine.

Le diagramme suivant montre l’architecture de référence pour utiliser Azure Bastion afin de protéger les machines virtuelles Azure.

Pour protéger votre machine virtuelle Azure, déployez Azure Bastion et commencez à utiliser RDP et SSH pour vous connecter à vos machines virtuelles avec leurs adresses IP privées.

Recommandé pour la formation

Étapes suivantes

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

Références

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

Partager via