Recommandations pour la mise en réseau et la connectivité

Article
11/15/2023

S’applique à cette recommandation de liste de contrôle de sécurité Azure Well-Architected Framework :

SE :05	Isolez, filtrez et contrôlez le trafic réseau sur les flux d’entrée et de sortie. Appliquez les principes de défense en profondeur à l’aide de contrôles réseau localisés à toutes les limites réseau disponibles sur le trafic est-ouest et nord-sud.

Ce guide décrit les recommandations relatives à la conception du réseau. L’accent est mis sur les contrôles de sécurité qui peuvent filtrer, bloquer et détecter les adversaires qui franchissent les limites réseau à différentes profondeurs de votre architecture.

Vous pouvez renforcer vos contrôles d’identité en implémentant des mesures de contrôle d’accès basées sur le réseau. Avec le contrôle d’accès basé sur l’identité, la sécurité réseau est une priorité élevée pour la protection des ressources. Les contrôles de sécurité réseau appropriés peuvent fournir un élément de défense en profondeur qui peut aider à détecter et à contenir les menaces, et empêcher les attaquants d’entrer dans votre charge de travail.

Définitions

Terme	Définition
Trafic est-ouest	Trafic réseau qui se déplace à l’intérieur d’une limite approuvée.
Flux de sortie	Trafic de charge de travail sortant.
Réseau hostile	Réseau qui n’est pas déployé dans le cadre de votre charge de travail. Un réseau hostile est considéré comme un vecteur de menace.
Flux d’entrée	Trafic de charge de travail entrant.
Filtrage du réseau	Mécanisme qui autorise ou bloque le trafic réseau en fonction des règles spécifiées.
Segmentation ou isolation réseau	Stratégie qui divise un réseau en petits segments isolés, avec des contrôles de sécurité appliqués aux limites. Cette technique permet de protéger les ressources contre les réseaux hostiles, tels qu’Internet.
Transformation réseau	Mécanisme qui mute les paquets réseau pour les masquer.
Trafic nord-sud	Trafic réseau qui passe d’une limite approuvée à des réseaux externes potentiellement hostiles, et vice versa.

Stratégies de conception

La sécurité réseau utilise l’obscurité pour protéger les ressources de charge de travail des réseaux hostiles. Les ressources qui se trouvent derrière une limite réseau sont masquées jusqu’à ce que les contrôles de limite marquent le trafic comme étant sécurisé. La conception de la sécurité réseau repose sur trois stratégies main :

Segment. Cette technique isole le trafic sur des réseaux distincts en ajoutant des limites. Par exemple, le trafic à destination et en provenance d’une couche application passe une limite pour communiquer avec d’autres niveaux, qui ont des exigences de sécurité différentes. Les couches de segmentation actualisent l’approche de défense en profondeur.

La limite de sécurité la plus importante est la périphérie réseau entre votre application et les réseaux publics. Il est important de définir clairement ce périmètre afin d’établir une limite pour isoler les réseaux hostiles. Les contrôles sur ce bord doivent être très efficaces, car cette limite est votre première ligne de défense.

Les réseaux virtuels fournissent une limite logique. Par conception, un réseau virtuel ne peut pas communiquer avec un autre réseau virtuel, sauf si la limite a été intentionnellement rompue par le peering. Votre architecture doit tirer parti de cette mesure de sécurité forte fournie par la plateforme.

Vous pouvez également utiliser d’autres limites logiques, telles que des sous-réseaux découpés au sein d’un réseau virtuel. Un avantage des sous-réseaux est que vous pouvez les utiliser pour regrouper des ressources qui se trouvent dans une limite d’isolation et qui ont des garanties de sécurité similaires. Vous pouvez ensuite configurer des contrôles sur la limite pour filtrer le trafic.
Filtrez. Cette stratégie permet de garantir que le trafic qui entre dans une limite est attendu, autorisé et sécurisé. Du point de vue Zero-Trust, le filtrage vérifie explicitement tous les points de données disponibles au niveau du réseau. Vous pouvez placer des règles sur la limite pour case activée pour des conditions spécifiques.

Par exemple, au niveau de l’en-tête, les règles peuvent vérifier que le trafic provient d’un emplacement attendu ou a un volume attendu. Mais ces vérifications ne suffisent pas. Même si le trafic présente les caractéristiques attendues, la charge utile peut ne pas être sécurisée. Les vérifications de validation peuvent révéler une attaque par injection SQL.
Transformer. Mutez les paquets à la limite comme mesure de sécurité. Par exemple, vous pouvez supprimer les en-têtes HTTP pour éliminer le risque d’exposition. Vous pouvez également désactiver tls (Transport Layer Security) à un moment donné et le rétablir à un autre tronçon avec un certificat géré de manière plus rigoureuse.

Classifier les flux de trafic

La première étape de la classification des flux consiste à étudier un schéma de votre architecture de charge de travail. À partir du schéma, déterminez l’intention et les caractéristiques du flux en ce qui concerne l’utilité fonctionnelle et les aspects opérationnels de votre charge de travail. Utilisez les questions suivantes pour classer le flux :

Si la charge de travail doit communiquer avec des réseaux externes, quel doit être le niveau de proximité requis avec ces réseaux ?
Quelles sont les caractéristiques réseau du flux, telles que le protocole attendu et la source et la forme des paquets ? Existe-t-il des exigences de conformité au niveau de la mise en réseau ?

Il existe de nombreuses façons de classer les flux de trafic. Les sections suivantes traitent des critères couramment utilisés.

Visibilité à partir de réseaux externes

Public. Une charge de travail est accessible au public si son application et d’autres composants sont accessibles à partir de l’Internet public. L’application est exposée via une ou plusieurs adresses IP publiques et des serveurs DNS (Domain Name System) publics.
Privé. Une charge de travail est privée si elle est accessible uniquement via un réseau privé tel qu’un réseau privé virtuel (VPN). Il est exposé uniquement via une ou plusieurs adresses IP privées et potentiellement via un serveur DNS privé.

Dans un réseau privé, il n’y a aucune ligne de vue de l’Internet public vers la charge de travail. Pour la passerelle, vous pouvez utiliser un équilibreur de charge ou un pare-feu. Ces options peuvent fournir des garanties de sécurité.

Même avec des charges de travail publiques, essayez de garder autant de charges de travail privées que possible. Cette approche force les paquets à traverser une limite privée lorsqu’ils arrivent d’un réseau public. Une passerelle dans ce chemin d’accès peut fonctionner comme un point de transition en agissant comme un proxy inverse.

Direction du trafic

Entrée. L’entrée est un trafic entrant qui se dirige vers une charge de travail ou ses composants. Pour sécuriser l’entrée, appliquez l’ensemble de stratégies clés précédent. Déterminez quelle est la source de trafic et si elle est attendue, autorisée et sécurisée. Les attaquants qui analysent les plages d’adresses IP du fournisseur de cloud public peuvent réussir à pénétrer vos défenses si vous ne case activée pas d’entrée ou n’implémentez pas de mesures de sécurité réseau de base.
Sortie. La sortie est un trafic sortant qui s’écoule loin d’une charge de travail ou de ses composants. Pour case activée sortie, déterminez où se dirige le trafic et si la destination est attendue, autorisée et sûre. La destination peut être malveillante ou associée à des risques d’exfiltration de données.

Vous pouvez également déterminer votre niveau d’exposition en tenant compte de la proximité de votre charge de travail avec l’Internet public. Par exemple, la plateforme d’application sert généralement les adresses IP publiques. Le composant de charge de travail est le visage de la solution.

Étendue de l’influence

Nord-sud. Le trafic qui circule entre un réseau de charge de travail et des réseaux externes est du trafic nord-sud. Ce trafic traverse la périphérie de votre réseau. Les réseaux externes peuvent être l’Internet public, un réseau d’entreprise ou tout autre réseau qui échappe à votre contrôle.

L’entrée et la sortie peuvent toutes deux être du trafic nord-sud.

Par exemple, considérez le flux de sortie d’une topologie de réseau hub-spoke. Vous pouvez définir la périphérie réseau de votre charge de travail afin que le hub soit un réseau externe. Dans ce cas, le trafic sortant à partir du réseau virtuel du spoke est du trafic nord-sud. Mais si vous considérez le réseau hub dans votre sphère de contrôle, le trafic nord-sud est étendu au pare-feu dans le hub, car le tronçon suivant est Internet, qui est potentiellement hostile.
Est-Ouest. Le trafic qui circule au sein d’un réseau de charge de travail est un trafic est-ouest. Ce type de trafic se produit lorsque les composants de votre charge de travail communiquent entre eux. Un exemple est le trafic entre les niveaux d’une application à plusieurs niveaux. Dans les microservices, la communication de service à service est un trafic est-ouest.

Pour fournir une défense en profondeur, conservez un contrôle de bout en bout des affordances de sécurité incluses dans chaque tronçon ou que vous utilisez lorsque des paquets traversent des segments internes. Différents niveaux de risque nécessitent des méthodes de correction des risques différentes.

Le diagramme précédent illustre la défense réseau en profondeur dans le cloud privé. Dans ce diagramme, la frontière entre les espaces d’adressage IP publics et privés est beaucoup plus éloignée de la charge de travail que dans le diagramme de cloud public. Plusieurs couches séparent les déploiements Azure de l’espace d’adressage IP public.

Notes

L’identité est toujours le périmètre principal. La gestion des accès doit être appliquée aux flux réseau. Utilisez des identités managées lorsque vous utilisez le contrôle d’accès en fonction du rôle (RBAC) Azure entre les composants de votre réseau.

Après avoir classé les flux, effectuez un exercice de segmentation pour identifier les points d’injection de pare-feu sur les chemins de communication de vos segments réseau. Lorsque vous concevez la défense de votre réseau en profondeur sur tous les segments et tous les types de trafic, supposez une violation à tous les points. Utilisez une combinaison de différents contrôles réseau localisés à toutes les limites disponibles. Pour plus d’informations, consultez Stratégies de segmentation.

Appliquer des pare-feu à la périphérie

Le trafic de périphérie Internet est du trafic nord-sud et comprend l’entrée et la sortie. Pour détecter ou bloquer les menaces, une stratégie de périphérie doit atténuer autant d’attaques que possible vers et depuis Internet.

Pour la sortie, envoyez tout le trafic internet via un pare-feu unique qui offre une supervision, une gouvernance et un contrôle améliorés du trafic. Pour l’entrée, forcez tout le trafic d’Internet à passer par une Appliance virtuelle réseau (NVA) ou un pare-feu d’applications web.

Les pare-feu sont généralement des singletons déployés par région dans un organization. Par conséquent, ils sont partagés entre les charges de travail et appartiennent à une équipe centrale. Assurez-vous que toutes les appliances virtuelles réseau que vous utilisez sont configurées pour prendre en charge les besoins de votre charge de travail.
Nous vous recommandons d’utiliser autant que possible des contrôles natifs Azure.

En plus des contrôles natifs, vous pouvez également envisager des appliances virtuelles réseau partenaires qui fournissent des fonctionnalités avancées ou spécialisées. Les produits des fournisseurs de pare-feu d’applications web et de pare-feu partenaires sont disponibles dans Place de marché Azure.

La décision d’utiliser des fonctionnalités natives plutôt que des solutions partenaires doit être basée sur l’expérience et les exigences de votre organization.

Compromis : les fonctionnalités des partenaires fournissent souvent des fonctionnalités avancées qui peuvent protéger contre les attaques sophistiquées, mais généralement rares. La configuration des solutions partenaires peut être complexe et fragile, car ces solutions ne s’intègrent pas aux contrôleurs de structure du cloud. Du point de vue des coûts, le contrôle natif est préférable, car il est moins cher que les solutions partenaires.

Toutes les options technologiques que vous envisagez doivent fournir des contrôles de sécurité et une surveillance pour les flux d’entrée et de sortie. Pour voir les options disponibles pour Azure, consultez la section Sécurité Edge de cet article.

Concevoir la sécurité du réseau virtuel et du sous-réseau

L’objectif principal d’un cloud privé est de masquer les ressources de l’Internet public. Il existe plusieurs façons d’atteindre cet objectif :

Passez à des espaces d’adressage IP privés, ce que vous pouvez accomplir à l’aide de réseaux virtuels. Réduisez la visibilité du réseau, même au sein de vos propres réseaux privés.
Réduisez le nombre d’entrées DNS publiques que vous utilisez pour exposer moins de votre charge de travail.
Ajouter un contrôle de flux réseau d’entrée et de sortie. N’autorisez pas le trafic non approuvé.

Stratégie de segmentation

Pour réduire la visibilité du réseau, segmentez votre réseau et commencez par les contrôles réseau de privilèges minimum. Si un segment n’est pas routable, il n’est pas accessible. Élargissez l’étendue pour inclure uniquement les segments qui doivent communiquer entre eux via l’accès réseau.

Vous pouvez segmenter des réseaux virtuels en créant des sous-réseaux. Les critères de division doivent être intentionnels. Lorsque vous colocalisez des services à l’intérieur d’un sous-réseau, assurez-vous que ces services peuvent se voir.

Vous pouvez baser votre segmentation sur de nombreux facteurs. Par exemple, vous pouvez placer différents niveaux d’application dans des segments dédiés. Une autre approche consiste à planifier vos sous-réseaux en fonction de rôles et de fonctions courants qui utilisent des protocoles connus.

Pour plus d’informations, consultez Stratégies de segmentation.

Pare-feu de sous-réseau

Il est important d’inspecter le trafic entrant et sortant de chaque sous-réseau. Utilisez les trois stratégies main décrites plus haut dans cet article, dans Stratégies de conception clés. Vérifiez si le flux est attendu, autorisé et sûr. Pour vérifier ces informations, définissez des règles de pare-feu basées sur le protocole, la source et la destination du trafic.

Sur Azure, vous définissez des règles de pare-feu dans les groupes de sécurité réseau. Pour plus d’informations, consultez la section Groupes de sécurité réseau de cet article.

Pour obtenir un exemple de conception de sous-réseau, consultez Sous-réseaux Azure Réseau virtuel.

Utiliser des contrôles au niveau du composant

Après avoir réduit la visibilité de votre réseau, mapper vos ressources Azure du point de vue du réseau et évaluer les flux. Les types de flux suivants sont possibles :

Trafic planifié ou communication intentionnelle entre les services en fonction de la conception de votre architecture. Par exemple, vous avez planifié le trafic lorsque votre architecture recommande que Azure Functions extrait les messages de Azure Service Bus.
Trafic de gestion ou communication qui se produit dans le cadre des fonctionnalités du service. Ce trafic ne fait pas partie de votre conception et vous n’avez aucun contrôle sur celui-ci. La communication entre les services Azure de votre architecture et le plan de gestion Azure constitue un exemple de trafic managé.

La distinction entre le trafic planifié et le trafic de gestion vous aide à créer des contrôles localisés ou au niveau du service. Avoir une bonne compréhension de la source et de la destination à chaque tronçon. En particulier, comprenez comment votre plan de données est exposé.

Comme point de départ, déterminez si chaque service est exposé à Internet. Si c’est le cas, planifiez comment restreindre l’accès. Si ce n’est pas le cas, placez-le dans un réseau virtuel.

Pare-feu de service

Si vous vous attendez à ce qu’un service soit exposé à Internet, tirez parti du pare-feu de niveau de service disponible pour la plupart des ressources Azure. Lorsque vous utilisez ce pare-feu, vous pouvez définir des règles basées sur des modèles d’accès. Pour plus d’informations, consultez la section Pare-feu de service Azure de cet article.

Notes

Lorsque votre composant n’est pas un service, utilisez un pare-feu basé sur l’hôte en plus des pare-feu au niveau du réseau. Une machine virtuelle est un exemple de composant qui n’est pas un service.

Connectivité aux services PaaS (Platform as a Service)

Envisagez d’utiliser des points de terminaison privés pour sécuriser l’accès aux services PaaS. Un point de terminaison privé se voit attribuer une adresse IP privée à partir de votre réseau virtuel. Le point de terminaison permet à d’autres ressources du réseau de communiquer avec le service PaaS via l’adresse IP privée.

La communication avec un service PaaS est obtenue à l’aide de l’adresse IP publique et de l’enregistrement DNS du service. Cette communication se produit sur Internet. Vous pouvez rendre cette communication privée.

Un tunnel du service PaaS vers l’un de vos sous-réseaux crée un canal privé. Toutes les communications ont lieu à partir de l’adresse IP privée du composant vers un point de terminaison privé dans ce sous-réseau, qui communique ensuite avec le service PaaS.

Dans cet exemple, l’image de gauche montre le flux pour les points de terminaison exposés publiquement. À droite, ce flux est sécurisé à l’aide de points de terminaison privés.

Pour plus d’informations, consultez la section Points de terminaison privés de cet article.

Notes

Nous vous recommandons d’utiliser des points de terminaison privés conjointement avec des pare-feu de service. Un pare-feu de service bloque le trafic Internet entrant, puis expose le service en privé aux utilisateurs internes qui utilisent le point de terminaison privé.

Un autre avantage de l’utilisation de points de terminaison privés est que vous n’avez pas besoin d’ouvrir les ports sur le pare-feu pour le trafic sortant. Les points de terminaison privés verrouillent tout le trafic sortant sur le port pour l’Internet public. La connectivité est limitée aux ressources au sein du réseau.

Compromis : Azure Private Link est un service payant qui a des compteurs pour les données entrantes et sortantes traitées. Vous êtes également facturé pour les points de terminaison privés.

Protéger contre les attaques par déni de service distribué (DDoS)

Une attaque DDoS tente d’épuiser les ressources d’une application pour rendre l’application indisponible pour les utilisateurs légitimes. Les attaques DDoS peuvent cibler n’importe quel point de terminaison accessible publiquement via Internet.

Une attaque DDoS est généralement un abus massif, répandu et géographiquement dispersé des ressources de votre système, qui rend difficile l’identification et le blocage de la source.

Pour support Azure vous protéger contre ces attaques, consultez la section Protection Azure DDoS de cet article.

Animation Azure

Vous pouvez utiliser les services Azure suivants pour ajouter des fonctionnalités de défense en profondeur à votre réseau.

Réseau virtuel Azure

Réseau virtuel permet à vos ressources Azure de communiquer en toute sécurité entre elles, avec Internet et avec les réseaux locaux.

Par défaut, toutes les ressources d’un réseau virtuel peuvent effectuer des communications sortantes avec Internet. Mais la communication entrante est limitée par défaut.

Réseau virtuel offre des fonctionnalités de filtrage du trafic. Vous pouvez restreindre l’accès au niveau du réseau virtuel à l’aide d’un itinéraire défini par l’utilisateur (UDR) et d’un composant de pare-feu. Au niveau du sous-réseau, vous pouvez filtrer le trafic à l’aide de groupes de sécurité réseau.

Sécurité edge

Par défaut, l’entrée et la sortie transitent par des adresses IP publiques. Selon le service ou la topologie, vous définissez ces adresses ou Azure les attribue. D’autres possibilités d’entrée et de sortie incluent le passage du trafic via un équilibreur de charge ou une passerelle de traduction d’adresses réseau (NAT). Toutefois, ces services sont destinés à la distribution du trafic et pas nécessairement à la sécurité.

Les choix technologiques suivants sont recommandés :

Pare-feu Azure. Vous pouvez utiliser Pare-feu Azure à la périphérie du réseau et dans des topologies de réseau populaires, telles que les réseaux hub-spoke et les réseaux WAN virtuels. Vous déployez généralement Pare-feu Azure en tant que pare-feu de sortie qui joue le rôle de porte de sécurité finale avant que le trafic ne soit acheminé vers Internet. Pare-feu Azure pouvez acheminer le trafic qui utilise des protocoles non HTTP et non HTTPS, tels que rdp (Remote Desktop Protocol), SSH (Secure Shell Protocol) et FTP (File Transfer Protocol). L’ensemble de fonctionnalités de Pare-feu Azure comprend :
- Traduction d’adresses réseau de destination (DNAT) ou transfert de port.
- Détection des signatures du système de détection et de prévention des intrusions (IDPS).
- Règles de réseau de couche forte 3, de couche 4 et de nom de domaine complet (FQDN).
Notes

La plupart des organisations ont une stratégie de tunneling forcé qui force le trafic à transiter par une appliance virtuelle réseau.

Si vous n’utilisez pas de topologie de wan virtuel, vous devez déployer un UDR avec un NextHopType sur Internet l’adresse IP privée de votre appliance virtuelle réseau. Les UDR sont appliquées au niveau du sous-réseau. Par défaut, le trafic de sous-réseau à sous-réseau ne transite pas par l’appliance virtuelle réseau.

Vous pouvez également utiliser Pare-feu Azure simultanément pour l’entrée. Il peut acheminer le trafic HTTP et HTTPS. Dans les références SKU à niveau supérieur, Pare-feu Azure offre l’arrêt TLS afin que vous puissiez implémenter des inspections au niveau de la charge utile.

Les pratiques suivantes sont recommandées :
- Activez les paramètres diagnostics dans Pare-feu Azure pour collecter les journaux de flux de trafic, les journaux IDPS et les journaux des requêtes DNS.
- Soyez aussi précis que possible dans les règles.
- Lorsque cela est pratique, évitez les étiquettes de service FQDN. Toutefois, lorsque vous les utilisez, utilisez la variante régionale, qui permet la communication avec tous les points de terminaison du service.
- Utilisez des groupes d’adresses IP pour définir des sources qui doivent partager les mêmes règles pendant toute la durée de vie du groupe d’adresses IP. Les groupes IP doivent refléter votre stratégie de segmentation.
- Remplacez la règle d’autorisation du nom de domaine complet de l’infrastructure uniquement si votre charge de travail nécessite un contrôle de sortie absolu. Le remplacement de cette règle s’accompagne d’un compromis en matière de fiabilité, car les exigences de plateforme Azure changent sur les services.
Compromis : Pare-feu Azure peut avoir un impact sur vos performances. L’ordre des règles, la quantité, l’inspection TLS et d’autres facteurs peuvent entraîner une latence significative.

Il peut également y avoir un impact sur la fiabilité de votre charge de travail. Il peut rencontrer un épuisement du port de traduction d’adresses réseau (SNAT) source. Pour résoudre ce problème, ajoutez des adresses IP publiques en fonction des besoins.

Risque : Pour le trafic de sortie, Azure attribue une adresse IP publique. Cette affectation peut avoir un impact en aval sur votre porte de sécurité externe.
Azure Web Application Firewall. Ce service prend en charge le filtrage entrant et cible uniquement le trafic HTTP et HTTPS.

Il offre une sécurité de base pour les attaques courantes, telles que les menaces que l’Open Worldwide Application Security Project (OWASP) identifie dans le document OWASP Top 10. Azure Web Application Firewall fournit également d’autres fonctionnalités de sécurité axées sur la couche 7, telles que la limitation du débit, les règles d’injection de code SQL et les scripts intersites.

Avec Azure Web Application Firewall, l’arrêt TLS est nécessaire, car la plupart des vérifications sont basées sur des charges utiles.

Vous pouvez intégrer Azure Web Application Firewall à des routeurs, tels que Azure Application Gateway ou Azure Front Door. Les implémentations d’Azure Web Application Firewall pour ces types de routeurs peuvent varier.

Pare-feu Azure et azure Web Application Firewall ne sont pas des choix mutuellement exclusifs. Pour votre solution de sécurité de périphérie, différentes options sont disponibles. Pour obtenir des exemples, consultez Pare-feu et Application Gateway pour les réseaux virtuels.

Groupes de sécurité réseau

Un groupe de sécurité réseau est un pare-feu de couche 3 et de couche 4 que vous appliquez au niveau du sous-réseau ou de l’interface réseau carte (carte réseau). Les groupes de sécurité réseau ne sont pas créés ou appliqués par défaut.

Les règles de groupe de sécurité réseau agissent comme un pare-feu pour arrêter le trafic entrant et sortant sur le périmètre d’un sous-réseau. Un groupe de sécurité réseau a un ensemble de règles par défaut trop permissif. Par exemple, les règles par défaut ne définissent pas de pare-feu du point de vue de la sortie. Pour l’entrée, aucun trafic Internet entrant n’est autorisé.

Pour créer des règles, commencez par l’ensemble de règles par défaut :

Pour le trafic entrant ou l’entrée :
- Le trafic de réseau virtuel provenant de sources directes, appairées et de passerelle VPN est autorisé.
- Azure Load Balancer sondes d’intégrité sont autorisées.
- Tous les autres trafics sont bloqués.
Pour le trafic sortant ou sortant :
- Le trafic de réseau virtuel vers des destinations directes, appairées et de passerelle VPN est autorisé.
- Le trafic vers Internet est autorisé.
- Tous les autres trafics sont bloqués.

Tenez ensuite compte des cinq facteurs suivants :

Protocol
Adresse IP source
Port source
Adresse IP de destination
Port de destination

L’absence de prise en charge du nom de domaine complet limite les fonctionnalités du groupe de sécurité réseau. Vous devez fournir des plages d’adresses IP spécifiques pour votre charge de travail, et elles sont difficiles à gérer.

Toutefois, pour les services Azure, vous pouvez utiliser des balises de service pour résumer les plages d’adresses IP sources et de destination. L’un des avantages en matière de sécurité des étiquettes de service est qu’elles sont opaques pour l’utilisateur et que la responsabilité est déchargée vers Azure. Vous pouvez également affecter un groupe de sécurité d’application comme type de destination vers lequel acheminer le trafic. Ce type de groupe nommé contient des ressources qui ont des besoins d’accès entrant ou sortant similaires.

Risque : les plages d’étiquettes de service sont très larges afin qu’elles s’adressent à la plus large gamme possible de clients. Mises à jour aux étiquettes de service sont en retard par rapport aux modifications apportées au service.

Dans l’image précédente, les groupes de sécurité réseau sont appliqués à la carte réseau. Le trafic Internet et le trafic de sous-réseau à sous-réseau sont refusés. Les groupes de sécurité réseau sont appliqués avec la VirtualNetwork balise . Ainsi, dans ce cas, les sous-réseaux des réseaux appairés ont une ligne de vue directe. La définition large de la VirtualNetwork balise peut avoir un impact significatif sur la sécurité.

Lorsque vous utilisez des étiquettes de service, utilisez des versions régionales dans la mesure du possible, comme Storage.WestUS au lieu de Storage. En adoptant cette approche, vous limitez l’étendue à tous les points de terminaison d’une région particulière.

Certaines balises sont exclusivement destinées au trafic entrant ou sortant . D’autres sont pour les deux types. Les balises entrantes autorisent généralement le trafic provenant de toutes les charges de travail d’hébergement, telles que AzureFrontDoor.Backend, ou d’Azure pour prendre en charge les runtimes de service, tels que LogicAppsManagement. De même, les balises sortantes autorisent le trafic vers toutes les charges de travail d’hébergement ou à partir d’Azure pour prendre en charge les runtimes de service.

Limitez autant que possible les règles. Dans l’exemple suivant, la règle est définie sur des valeurs spécifiques. Tout autre type de trafic est refusé.

Informations	Exemple
Protocol	Protocole TCP (Transmission Control Protocol), UDP
Adresse IP source	Autoriser l’entrée vers le sous-réseau à partir de <la plage d’adresses> IP sources : 4575/UDP
Port source	Autoriser l’entrée dans le sous-réseau à partir de <service-tag> : 443/TCP
Adresse IP de destination	Autoriser la sortie du sous-réseau vers <destination-IP-address-range> : 443/TCP
Port de destination	Autoriser la sortie du sous-réseau vers <service-tag> : 443/TCP

Pour récapituler :

Soyez précis lorsque vous créez des règles. Autorisez uniquement le trafic nécessaire au fonctionnement de votre application. Refusez tout le reste. Cette approche limite la ligne de vision réseau aux flux réseau nécessaires pour prendre en charge le fonctionnement de la charge de travail. La prise en charge de flux réseau plus important que nécessaire entraîne des vecteurs d’attaque inutiles et étend la surface d’exposition.

La restriction du trafic n’implique pas que les flux autorisés dépassent le cadre d’une attaque. Étant donné que les groupes de sécurité réseau fonctionnent aux couches 3 et 4 sur la pile OSI (Open Systems Interconnection), ils contiennent uniquement des informations de forme et de direction. Par exemple, si votre charge de travail doit autoriser le trafic DNS vers Internet, vous devez utiliser un groupe de sécurité réseau de Internet:53:UDP. Dans ce cas, un attaquant peut être en mesure d’exfiltrer des données via UDP sur le port 53 vers un autre service.
Comprenez que les groupes de sécurité réseau peuvent différer légèrement les uns des autres. Il est facile d’ignorer l’intention des différences. Pour avoir un filtrage granulaire, il est plus sûr de créer des groupes de sécurité réseau supplémentaires. Configurez au moins un groupe de sécurité réseau.
- L’ajout d’un groupe de sécurité réseau déverrouille de nombreux outils diagnostics, tels que les journaux de flux et l’analytique du trafic réseau.
- Utilisez Azure Policy pour contrôler le trafic dans les sous-réseaux qui n’ont pas de groupes de sécurité réseau.
Si un sous-réseau prend en charge les groupes de sécurité réseau, ajoutez un groupe, même s’il a un impact minimal.

Pare-feu de service Azure

La plupart des services Azure offrent un pare-feu de niveau de service. Cette fonctionnalité inspecte le trafic d’entrée vers le service à partir de plages de routage inter-domaines (CIDR) sans classe spécifiées. Ces pare-feu offrent des avantages :

Ils fournissent un niveau de sécurité de base.
Il y a un impact tolérable sur les performances.
La plupart des services proposent ces pare-feu sans coût supplémentaire.
Les pare-feu émettent des journaux via Azure diagnostics, ce qui peut être utile pour analyser les modèles d’accès.

Mais il existe également des problèmes de sécurité associés à ces pare-feu, et il existe des limitations associées à la fourniture de paramètres. Par exemple, si vous utilisez des agents de build hébergés par Microsoft, vous devez ouvrir la plage d’adresses IP pour tous les agents de build hébergés par Microsoft. La plage est ensuite ouverte à votre agent de build, aux autres locataires et aux adversaires susceptibles d’abuser de votre service.

Si vous avez des modèles d’accès pour le service, qui peuvent être configurés en tant qu’ensembles de règles de pare-feu de service, vous devez activer le service. Vous pouvez utiliser Azure Policy pour l’activer. Veillez à ne pas activer l’option services Azure approuvés si elle n’est pas activée par défaut. Cela permet d’afficher tous les services dépendants qui font partie du champ d’application des règles.

Pour plus d’informations, consultez la documentation produit des services Azure individuels.

Instances Private Endpoint

Private Link vous permet de donner une instance PaaS à une adresse IP privée. Le service est alors inaccessible sur Internet. Les points de terminaison privés ne sont pas pris en charge pour toutes les références SKU.

Gardez à l’esprit les recommandations suivantes lorsque vous utilisez des points de terminaison privés :

Configurez les services liés à des réseaux virtuels pour contacter les services PaaS via des points de terminaison privés, même si ces services PaaS doivent également offrir un accès public.
Promouvoir l’utilisation de groupes de sécurité réseau pour les points de terminaison privés afin de restreindre l’accès aux adresses IP de point de terminaison privé.
Utilisez toujours des pare-feu de service lorsque vous utilisez des points de terminaison privés.
Si possible, si vous avez un service accessible uniquement via des points de terminaison privés, supprimez la configuration DNS de son point de terminaison public.
Tenez compte des problèmes de ligne de vue du runtime lorsque vous implémentez des points de terminaison privés. Mais tenez également compte des problèmes liés à DevOps et à la surveillance.
Utilisez Azure Policy pour appliquer la configuration des ressources.

Compromis : Les références SKU de service avec des points de terminaison privés sont coûteuses. Les points de terminaison privés peuvent compliquer les opérations en raison de l’obscurité du réseau. Vous devez ajouter des agents auto-hébergés, des jump box, un VPN et d’autres composants à votre architecture.

La gestion DNS peut être complexe dans les topologies réseau courantes. Vous devrez peut-être introduire des redirecteurs DNS et d’autres composants.

Injection sur le réseau virtuel

Vous pouvez utiliser le processus d’injection de réseau virtuel pour déployer certains services Azure dans votre réseau. Par exemple, Azure App Service, Functions, Azure Gestion des API et Azure Spring Apps. Ce processus isole l’application d’Internet, les systèmes dans les réseaux privés et d’autres services Azure. En fonction des règles du réseau, le trafic entrant et sortant de l'application est autorisé ou refusé.

Azure Bastion

Vous pouvez utiliser Azure Bastion pour vous connecter à une machine virtuelle à l’aide de votre navigateur et du Portail Azure. Azure Bastion améliore la sécurité des connexions RDP et SSH. Un cas d’usage classique inclut la connexion à un jump box dans le même réseau virtuel ou un réseau virtuel appairé. L’utilisation d’Azure Bastion supprime la nécessité pour la machine virtuelle d’avoir une adresse IP publique.

Protection DDoS dans Azure

Chaque propriété dans Azure est protégée par la protection de l’infrastructure Azure DDoS sans coût supplémentaire et sans ajout de configuration. Le niveau de protection est de base, mais la protection a des seuils élevés. Il ne fournit pas non plus de données de télémétrie ou d’alerte, et il est indépendant de la charge de travail.

Les références SKU de niveau supérieur de protection DDoS sont disponibles, mais ne sont pas gratuites. La mise à l’échelle et la capacité du réseau Azure déployé à l’échelle mondiale offrent une protection contre les attaques courantes de la couche réseau. Les technologies telles que la surveillance du trafic toujours actif et l’atténuation en temps réel fournissent cette fonctionnalité.

Pour plus d’informations, consultez Vue d’ensemble du service Azure DDoS Protection.

Exemple

Voici quelques exemples qui illustrent l’utilisation des contrôles réseau recommandés dans cet article.

Environnement informatique

Cet exemple s’appuie sur l’environnement informatique établi dans la base de référence de sécurité (SE :01). Cette approche fournit une compréhension générale des contrôles réseau appliqués à différents périmètres pour restreindre le trafic.

Personnages d’attaque réseau. Plusieurs personnages peuvent être pris en compte dans une attaque réseau, notamment les administrateurs, les employés, les clients du client et les attaquants anonymes.
Accès VPN. Un acteur défectueux peut accéder à l’environnement local via un VPN ou un environnement Azure connecté à l’environnement local via un VPN. Configurez avec le protocole IPSec pour activer la communication sécurisée.
Accès public à l’application. Disposer d’un pare-feu d’applications web (WAF) devant l’application pour la protéger sur la couche 7 de la couche OSI réseau.
Accès opérateur. L’accès à distance via la couche 4 des couches OSI réseau doit être sécurisé. Envisagez d’utiliser Pare-feu Azure avec les fonctionnalités IDP/IDS.
Protection DDOS. Disposez d’une protection DDoS pour l’ensemble de votre réseau virtuel.
Topologie réseau. Une topologie réseau, telle que hub-spoke, est plus sécurisée et optimise les coûts. Le réseau hub fournit une protection de pare-feu centralisée à tous les spokes appairés.
Points de terminaison privés : envisagez d’ajouter des services exposés publiquement à votre réseau privé à l’aide de points de terminaison privés. Celles-ci créent une carte réseau (NIC) dans votre réseau virtuel privé et se lient au service Azure.
Communication TLS. Protégez les données en transit en communiquant via TLS.
Groupe de sécurité réseau (NSG) : protégez les segments d’un réseau virtuel avec un groupe de sécurité réseau, une ressource gratuite qui filtre les communications entrantes et sortantes TCP/UDP en tenant compte des plages d’adresses IP et de ports. Une partie du groupe de sécurité réseau est le groupe de sécurité des applications (ASG) qui vous permet de créer des étiquettes pour les règles de trafic pour faciliter la gestion.
Log Analytics. Les ressources Azure émettent des données de télémétrie qui sont ingérées dans Log Analytics, puis utilisées avec une solution SIEM comme Microsoft Sentinel à des fins d’analyse.
Intégration de Microsoft Sentinel. Log Analytics est intégré à Microsoft Sentinel et à d’autres solutions telles que Microsoft Defender pour le cloud.
Microsoft Defender pour le cloud. Microsoft Defender pour le cloud fournit de nombreuses solutions de protection des charges de travail, notamment des recommandations réseau pour votre environnement.
Traffic Analytics : surveillez vos contrôles réseau avec Traffic Analytics. Il est configuré via Network Watcher, une partie d’Azure Monitor, et agrège les accès entrants et sortants dans vos sous-réseaux collectés par NSG.

Architecture d’une charge de travail conteneurisée

Cet exemple d’architecture combine les contrôles réseau décrits dans cet article. L’exemple n’affiche pas l’architecture complète. Au lieu de cela, il se concentre sur les contrôles d’entrée sur le cloud privé.

Application Gateway est un équilibreur de charge du trafic web que vous pouvez utiliser pour gérer le trafic vers vos applications web. Vous déployez Application Gateway dans un sous-réseau dédié qui a des contrôles de groupe de sécurité réseau et des contrôles de pare-feu d’applications web en place.

La communication avec tous les services PaaS s’effectue via des points de terminaison privés. Tous les points de terminaison sont placés dans un sous-réseau dédié. La protection DDoS permet de protéger toutes les adresses IP publiques configurées pour un niveau de protection par pare-feu de base ou supérieur.

Le trafic de gestion est restreint via Azure Bastion, qui permet de fournir une connectivité RDP et SSH sécurisée et transparente à vos machines virtuelles directement à partir du Portail Azure via TLS. Les agents de build sont placés dans le réseau virtuel afin d’avoir une vue réseau pour les ressources de charge de travail telles que les ressources de calcul, les registres de conteneurs et les bases de données. Cette approche permet de fournir un environnement sécurisé et isolé pour vos agents de build, ce qui renforce la protection de votre code et de vos artefacts.

Les groupes de sécurité réseau au niveau du sous-réseau des ressources de calcul limitent le trafic de sortie. Le tunneling forcé est utilisé pour acheminer tout le trafic via Pare-feu Azure. Cette approche permet de fournir un environnement sécurisé et isolé pour vos ressources de calcul, ce qui renforce la protection de vos données et applications.

Liste de contrôle de sécurité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de sécurité

Recommandations pour la mise en réseau et la connectivité