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

S’applique à cette recommandation de liste de contrôle azure Well-Architected Framework Security :

Ce guide décrit les recommandations relatives à la conception du réseau. Le focus est mis sur les contrôles de sécurité qui peuvent filtrer, bloquer et détecter les adversaires qui franchissent les limites du 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. En plus du 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 des menaces, et empêcher les attaquants d’entrer dans votre charge de travail.

Définitions

Stratégies de conception

La sécurité réseau utilise l’obscurité pour protéger les ressources de charge de travail contre les 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 sûr pour avancer. La conception de la sécurité réseau repose sur trois stratégies principales :

• Segment. Cette technique isole le trafic sur des réseaux distincts en ajoutant des limites. Par exemple, le trafic vers et à partir 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 grande est la périphérie réseau entre votre application et vos 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 et 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.

• Filtre. Cette stratégie permet de s’assurer que le trafic entrant dans une limite est attendu, autorisé et sécurisé. Du point de vue de la confiance zéro, 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 vérifier 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 d’un volume attendu. Mais ces vérifications ne sont pas suffisantes. Même si le trafic présente des 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 en tant que mesure de sécurité. Par exemple, vous pouvez supprimer des en-têtes HTTP pour éliminer le risque d’exposition. Vous pouvez également désactiver le protocole TLS (Transport Layer Security) à un moment donné et le rétablir à un autre tronçon avec un certificat géré plus rigoureusement.

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’utilitaire fonctionnel et les aspects opérationnels de votre charge de travail. Utilisez les questions suivantes pour vous aider à classifier le flux :

• Si la charge de travail doit communiquer avec des réseaux externes, quel est le niveau de proximité requis pour 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 réseau ?

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

Visibilité à partir de réseaux externes

• Public. Une charge de travail est publique 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 serveurs DNS (Domain Name System).

• 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 n’est exposé qu’à l’aide d’une ou plusieurs adresses IP privées et potentiellement via un serveur DNS privé.

  Dans un réseau privé, il n’existe aucune ligne de vue entre l’Internet public et 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 les charges de travail publiques, essayez de conserver autant de charge de travail privée que possible. Cette approche force les paquets à traverser une limite privée lorsqu’ils arrivent à partir d’un réseau public. Une passerelle dans ce chemin peut fonctionner comme un point de transition en agissant comme un proxy inverse.

Direction du trafic

• Entrée. L’entrée est le trafic entrant qui transite vers une charge de travail ou ses composants. Pour sécuriser l’entrée, appliquez l’ensemble précédent de stratégies clés. Déterminez la source du trafic et indiquez s’il est attendu, autorisé et sécurisé. Les attaquants qui analysent les plages d’adresses IP du fournisseur de cloud public peuvent pénétrer correctement vos défenses si vous ne vérifiez pas l’entrée ou implémentez des mesures de sécurité réseau de base.

• Sortie. La sortie est le trafic sortant qui s’éloigne d’une charge de travail ou de ses composants. Pour vérifier la sortie, déterminez où le trafic est dirigé et si la destination est attendue, autorisée et sécurisée. 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’applications sert généralement des 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 le 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 extérieur à votre portée de contrôle.

  L’entrée et la sortie peuvent tous 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 du réseau virtuel du spoke est le trafic nord-sud. Mais si vous envisagez 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 dans un réseau de charge de travail est le trafic est-ouest. Ce type de trafic se produit lorsque les composants de votre charge de travail communiquent entre eux. Par exemple, le trafic entre les niveaux d’une application multiniveau. Dans les microservices, la communication de service à service est le trafic est-ouest.

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

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

Une fois les flux classés, 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 votre défense réseau en profondeur sur tous les segments et tous les types de trafic, supposons 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 un trafic nord-sud et inclut 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 lié à Internet via un seul pare-feu 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 une organisation. Par conséquent, ils sont partagés entre les charges de travail et appartenant à une équipe centrale. Assurez-vous que 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 les contrôles natifs Azure autant que possible.

  Outre les 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 du fournisseur de pare-feu d’applications web et de pare-feu d’applications partenaires sont disponibles dans Place de marché Azure.

  La décision d’utiliser des fonctionnalités natives par opposition aux solutions partenaires doit être basée sur l’expérience et les exigences de votre organisation.

  Compromis : les fonctionnalités des partenaires fournissent souvent des fonctionnalités avancées qui peuvent se protéger contre des 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éré, 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 afficher les options disponibles pour Azure, consultez la section sécurité Edge de cet article.

Concevoir un réseau virtuel et une sécurité de sous-réseau

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

• Passez à des espaces d’adressage IP privés, que vous pouvez accomplir à l’aide de réseaux virtuels. Réduisez la ligne de vue 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.

• Ajoutez 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 des contrôles réseau avec 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 s’afficher les uns les autres.

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 des rôles et 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 principales stratégies décrites plus haut dans cet article, dans les stratégies de conception clés. Vérifiez si le flux est attendu, autorisé et sécurisé. 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 des 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 Azure Réseau virtuel sous-réseaux.

Utiliser des contrôles au niveau du composant

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

• Trafic planifié ou communication intentionnelle entre les services en fonction de votre conception d’architecture. Par exemple, vous avez planifié le trafic lorsque votre architecture recommande qu’Azure Functions extrait les messages d’Azure Service Bus.

• Trafic de gestion ou communication qui se produit dans le cadre de la fonctionnalité du service. Ce trafic ne fait pas partie de votre conception et vous n’avez aucun contrôle sur celui-ci. Un exemple de trafic managé est la communication entre les services Azure dans votre architecture et le plan de gestion Azure.

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

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

Pare-feu de service

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

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é reçoit 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 dans l’un de vos sous-réseaux crée un canal privé. Toutes les communications se produisent à 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 à gauche affiche 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.

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 aux 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 une attaque massive, répandue et dispersée géographiquement des ressources de votre système qui rend difficile l’identification et le blocage de la source.

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

Facilitation via 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 aide vos ressources Azure à communiquer en toute sécurité entre elles, internet et réseaux locaux.

Par défaut, toutes les ressources d’un réseau virtuel peuvent s’engager dans la communication sortante avec Internet. Toutefois, la communication entrante est limitée par défaut.

Réseau virtuel offre des fonctionnalités pour le 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 circulent sur les adresses IP publiques. Selon le service ou la topologie, vous définissez ces adresses ou Azure les assigne. D’autres possibilités d’entrée et de sortie incluent le passage du trafic par le biais d’un équilibreur de charge ou d’une passerelle NAT (Network Address Translation). Toutefois, ces services sont destinés à la distribution du trafic et ne sont pas nécessairement destinés à 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 les topologies réseau populaires, telles que les réseaux hub-spoke et les réseaux locaux 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 passe à Internet. Pare-feu Azure pouvez router le trafic qui utilise des protocoles non HTTP et non HTTPS, tels que rdp (Remote Desktop Protocol), Secure Shell Protocol (SSH) et FTP (File Transfer Protocol). L’ensemble de fonctionnalités de Pare-feu Azure inclut :

  • Traduction d’adresses réseau de destination (DNAT) ou transfert de port.
  • Détection des intrusions et détection des signatures du système de prévention des intrusions (IDPS).
  • Règles de réseau de couche 3, de couche 4 et de nom de domaine complet (FQDN).

  Remarque

  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 virtual WAN, vous devez déployer un UDR avec une NextHopType adresse IP privée de Internet 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 router le trafic HTTP et HTTPS. Dans les références SKU à plusieurs niveaux supérieurs, Pare-feu Azure offre une terminaison TLS afin de pouvoir implémenter des inspections au niveau de la charge utile.

  Les pratiques suivantes sont recommandées :

  • Activez les paramètres de diagnostic dans Pare-feu Azure pour collecter les journaux de flux de trafic, les journaux IDPS et les journaux de requête DNS.

  • Soyez aussi spécifique que possible dans les règles.

  • Là où il est pratique, évitez les balises de service FQDN. Toutefois, lorsque vous les utilisez, utilisez la variante régionale, qui autorise la communication avec tous les points de terminaison du service.

  • Utilisez des groupes IP pour définir des sources qui doivent partager les mêmes règles sur la durée de vie du groupe 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. La substitution de cette règle est fournie avec un compromis 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 importante.

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

  Risque : Pour le trafic de sortie, Azure affecte une adresse IP publique. Cette affectation peut avoir un impact en aval sur votre porte de sécurité externe.

• Pare-feu d’applications web Azure. 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 le projet OWASP (Open Worldwide Application Security Project) identifie dans le document OWASP Top 10. Le Pare-feu d’applications web Azure fournit également d’autres fonctionnalités de sécurité axées sur la couche 7, telles que la limitation de débit, les règles d’injection sql et les scripts intersites.

  Avec le pare-feu d’applications web Azure, l’arrêt TLS est requis, car la plupart des vérifications sont basées sur des charges utiles.

  Vous pouvez intégrer Azure Web Application Firewall à des routeurs, tels qu’Azure Application Gateway ou Azure Front Door. Les implémentations du Pare-feu d’applications web Azure pour ces types de routeurs peuvent varier.

Pare-feu Azure et le pare-feu d’applications web Azure ne sont pas mutuellement exclusifs. Pour votre solution de sécurité edge, 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 4 que vous appliquez au niveau de la carte d’interface réseau ou du sous-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 en tant que pare-feu pour arrêter le trafic entrant et sortant au périmètre d’un sous-réseau. Un groupe de sécurité réseau a un ensemble de règles par défaut qui est trop permissif. Par exemple, les règles par défaut ne définissent pas de pare-feu du point de vue de 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 à partir de sources de passerelle VPN directes, appairées et appairées est autorisé.
  • Les sondes d’intégrité Azure Load Balancer sont autorisées.
  • Tous les autres trafics sont bloqués.
• Pour le trafic sortant ou la sortie :
  • Le trafic de réseau virtuel vers des destinations de passerelle VPN directes, appairées et appairées est autorisé.
  • Le trafic vers Internet est autorisé.
  • Tous les autres trafics sont bloqués.

Considérez ensuite les cinq facteurs suivants :

• Protocol
• Une adresse IP source
• Port source
• Adresse IP de destination
• Port de destination

Le manque de prise en charge du nom de domaine complet limite la fonctionnalité de 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 synthétiser les plages d’adresses IP sources et de destination. L’avantage de sécurité des balises de service est qu’elles sont opaques pour l’utilisateur et que la responsabilité est déchargée sur Azure. Vous pouvez également affecter un groupe de sécurité d’application en tant que type de destination pour acheminer le trafic vers. 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 prennent en charge la plus large gamme possible de clients. Mises à jour des balises de service retardent les modifications dans le 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 générale de la balise peut avoir un impact significatif sur la VirtualNetwork sécurité.

Lorsque vous utilisez des balises de service, utilisez des versions régionales si 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 destinés aux deux types. Les balises entrantes autorisent généralement le trafic 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 les règles autant que possible. Dans l’exemple suivant, la règle est définie sur des valeurs spécifiques. Tout autre type de trafic est refusé.

Pour résumer :

• Soyez précis lorsque vous créez des règles. Autorisez uniquement le trafic nécessaire pour que votre application fonctionne. Refuser tout le reste. Cette approche limite la ligne de vue réseau aux flux réseau nécessaires pour prendre en charge l’opération de la charge de travail. La prise en charge d’un plus grand nombre de flux réseau 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 la portée d’une attaque. Étant donné que les groupes de sécurité réseau fonctionnent aux couches 3 et 4 de la pile OSI (Open Systems Interconnexion), 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 de ne pas oublier 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 de diagnostic, 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 au niveau du 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 sur les performances tolérable.
• La plupart des services offrent ces pare-feu sans frais supplémentaires.
• Les pare-feu émettent des journaux via des diagnostics Azure, 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, à d’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 que jeux de règles de pare-feu de service, vous devez activer le service. Vous pouvez utiliser Azure Policy pour l’activer. Vérifiez que vous n’activez pas l’option de services Azure approuvés si elle n’est pas activée par défaut. Cela amène tous les services dépendants qui se trouvent dans l’étendue 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 aux 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 disposez d’un service accessible uniquement via des points de terminaison privés, supprimez la configuration DNS de son point de terminaison public.

• Prenez en compte les problèmes de ligne de vue d’exécution lorsque vous implémentez des points de terminaison privés. Mais tenez également compte des préoccupations de DevOps et de 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 zones de rebond, 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. Parmi ces services, citons Azure App Service, Functions, Azure Gestion des API et Azure Spring Apps. Ce processus isole l’application de l’Internet, des systèmes dans des 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 à une zone de rebond 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.

Azure DDoS Protection

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

Les références SKU hiérarchisation supérieures de la 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 de couche réseau courantes. Les technologies telles que la surveillance du trafic always-on 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 (Information Technology) établi dans la base de référence de sécurité (SE :01). Cette approche fournit une compréhension étendue des contrôles réseau appliqués à différents périmètres pour restreindre le trafic.

1. Personas d’attaque réseau. Plusieurs personnes peuvent être prises en compte dans une attaque réseau, notamment les administrateurs, les employés, les clients du client et les attaquants anonymes.

2. Accès VPN. Un acteur incorrect 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.

3. 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 du réseau OSI.

4. Accès de l’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.

5. Protection DDOS. Disposez d’une protection DDoS pour l’ensemble de votre réseau virtuel.

6. Topologie du 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.

7. 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 avec le service Azure.

8. Communication TLS. Protégez les données en transit en communiquant via TLS.

9. Groupe de sécurité réseau (NSG) : protégez les segments au sein d’un réseau virtuel avec NSG, 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 balises pour les règles de trafic pour faciliter la gestion.

10. Log Analytics. Les ressources Azure émettent des données de télémétrie ingérées dans Log Analytics, puis utilisées avec une solution SIEM comme Microsoft Sentinel pour l’analyse.

11. Intégration de Microsoft Sentinel. Log Analytics est intégré à Microsoft Sentinel et à d’autres solutions comme Microsoft Defender pour le cloud.

12. 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.

13. Traffic Analytics : surveillez vos contrôles réseau avec Traffic Analytics. Cela 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 le groupe de sécurité réseau.

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 ne montre 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 de 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 est effectuée 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 de base ou supérieur du pare-feu.

Le trafic de gestion est limité 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 qu’ils disposent d’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 améliore 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 améliore la protection de vos données et applications.

Liens connexes

• Recommandations pour la conception de stratégies de segmentation
• Sous-réseaux Azure Réseau virtuel
• Réseau virtuel Azure
• Pare-feu Azure
• Pare-feu d’applications web Azure
• Pare-feu et Application Gateway pour réseaux virtuels
• Groupes de sécurité réseau
• Balises de service
• Azure Private Link
• Points de terminaison privés
• Azure Bastion
• Vue d’ensemble d’Azure DDoS Protection

Liste de contrôle de sécurité

Reportez-vous à l’ensemble complet de recommandations.