Endiguement et sécurité du réseau

La sécurité réseau a toujours été au cœur des efforts de sécurité d’entreprise. Toutefois, le cloud computing ayant entraîné la nécessité de rendre les périmètres de réseau plus poreux, bon nombre d’attaquants ont su maîtriser l’art des attaques dirigées contre des éléments du système d’identité (qui permettent presque toujours de contourner des contrôles réseau). Ces facteurs ont accru la nécessité de se concentrer principalement sur des contrôles d’accès basés sur les identités pour protéger les ressources, plutôt que sur des contrôles d’accès basés sur le réseau.

Les contrôles d’accès basés sur les identités réduisent le rôle des contrôles de sécurité réseau, mais ne les éliminent pas entièrement. Si la sécurité réseau n’est plus l’objectif principal pour sécurisation de ressources cloud, elle reste largement prioritaire pour le vaste portefeuille de ressources héritées (qui ont été créées en partant du principe qu’un périmètre basé sur un pare-feu réseau était en place). De nombreux attaquants utilisent toujours des méthodes d’analyse et d’exploitation de failles de sécurité de plages d’adresses IP de fournisseur de cloud public, pénétrant dans les défenses de ceux qui ne respectent pas l’hygiène de sécurité réseau de base. Des contrôles de sécurité réseau apportent également une dimension de défense en profondeur à votre stratégie, en aidant à protéger, détecter, contenir et évincer des attaquants qui se fraient un chemin dans vos déploiements cloud.

Dans le domaine de l’endiguement et de la sécurité du réseau, nos recommandations concernant les meilleures pratiques sont les suivantes :

  • Aligner la segmentation du réseau sur une stratégie globale

  • Centraliser la gestion et la sécurité du réseau

  • Élaborer une stratégie d’endiguement de réseau

  • Définir une stratégie de périmètre Internet

Centraliser la gestion et la sécurité du réseau

Centralisez la responsabilité de l’organisation en matière de gestion et de sécurité des fonctions de réseau de base, telles que les liaisons intersites, la mise en réseau virtuelle, les sous-réseaux et les schémas d’adresse IP, ainsi que des éléments de sécurité réseau tels que les appliances de réseau virtuel, le chiffrement d’activité de réseau virtuel et de trafic intersite dans le cloud, les contrôles d’accès basés sur le réseau et d’autres composants de sécurité réseau traditionnels.

Lorsque vous centralisez la gestion et la sécurité du réseau, vous réduisez la probabilité de stratégies incohérentes susceptibles de créer des risques de sécurité exploitables par un assaillant potentiel. Étant donné que tous les départements des organisations informatiques et de développement n’ont pas le même niveau de connaissance et de sophistication en matière de gestion et de sécurité de réseau, les organisations tirent parti de l’expertise et des outils de l’équipe réseau centralisée.

Microsoft Defender pour cloud peut être utilisé pour centraliser la gestion de la sécurité réseau.

Aligner la segmentation du réseau avec la stratégie de segmentation d’entreprise

Alignez votre modèle de segmentation de réseau avec le modèle de segmentation d’entreprise de votre organisation (défini dans la section Gouvernance, risque et conformité).

Cela réduira la confusion et les défis qui en résultent avec différentes équipes techniques (mise en réseau, identités, applications, etc.) qui développent leurs propres modèles de segmentation et de délégation qui ne s’alignent pas les uns avec les autres. Cela conduit à une stratégie de sécurité simple et unifiée qui permet de réduire le nombre de problèmes dus à une erreur humaine et à l’incapacité d’accroître la fiabilité par le biais de l’automatisation.

Comparez les images dans Endiguement et sécurité du réseau.

image showing hybrid cloud infrastructure-network architecture

Faire évoluer la sécurité au-delà des contrôles de réseau

Assurez-vous que les contrôles techniques peuvent efficacement empêcher, détecter et traiter les menaces en dehors des réseaux que vous contrôlez.

À mesure que les organisations évoluent vers des architectures modernes, de nombreux services et composants requis pour les applications font l’objet d’un accès via Internet ou des réseaux de fournisseur de cloud, souvent par des appareils mobiles et d’autres appareils hors réseau. Les contrôles de réseau traditionnels basés sur un approche d’intranet approuvé ne sont pas en mesure de fournir efficacement des garanties de sécurité pour ces applications. Ce paysage changeant est bien reflété dans les principes documentés par le Forum Jericho et les approches de « Confiance Zéro ».

Créez une stratégie d’endiguement des risques basée sur une combinaison de contrôles réseau et de contrôles des applications, des identités et autres.

  • Vérifiez que le regroupement des ressources et les privilèges d’administration s’alignent sur le modèle de segmentation (voir la figure XXXX)

  • Veillez à concevoir des contrôles de sécurité qui identifient et permettent le trafic, les demandes d’accès et d’autres communications d’applications entre segments attendus. Surveillez les communications entre segments pour identifier les communications inattendues, afin de pouvoir déterminer s’il faut définir des alertes ou bloquer le trafic pour limiter les risques de franchissement malveillant des limites de segmentation.

Élaborer une stratégie d’endiguement de sécurité

Créez une stratégie d’endiguement des risques qui combine des approches éprouvées, à savoir :

  • contrôles et pratiques de sécurité réseau existants ;

  • contrôles de sécurité natifs disponibles dans Azure ;

  • Approches de confiance zéro

L’endiguement de vecteurs d’attaque au sein d’un environnement est critique. En revanche, pour être efficace dans des environnements cloud, certains approches traditionnelles peuvent s’avérer inadaptées et les organisations de sécurité doivent faire évoluer leurs méthodes.

  • La cohérence des contrôles dans l’infrastructure, tant locale que cloud, est importante, mais les défenses sont plus efficaces et gérables en tirant parti des fonctionnalités natives offertes par un fournisseur de services cloud, des approches dynamiques juste-à-temps (JIT) et des contrôles d’identité et de mot de passe intégrés, comme ceux recommandés par les approches de validation continue et de Confiance Zéro.

  • Une meilleure pratique en matière de sécurité réseau consiste à s’assurer qu’il existe des contrôles d’accès réseau entre constructions réseau. Ces constructions peuvent représenter des réseaux virtuels ou des sous-réseaux au sein de ces réseaux virtuels. Cela permet de protéger et de contenir le trafic Est-Ouest au sein de votre infrastructure réseau cloud.

  • Une décision importante en matière de conception de sécurité réseau consiste à utiliser ou non des pare-feu basés sur l’hôte. Des pare-feu basés sur l’hôte prennent en charge une stratégie complète de défense en profondeur. Toutefois, pour être utiles, ils nécessitent une gestion conséquente. Si votre organisation les a jugés efficaces pour vous aider à protéger et à détecter des menaces par le passé, vous pouvez envisager de les utiliser pour vos ressources cloud. Si vous découvrez qu’ils n’ont pas ajouté de valeur significative, cessez de les utiliser et explorez des solutions natives disponibles sur la plateforme de votre fournisseur de services cloud offrant une valeur similaire.

Une meilleure pratique naissante en pleine évolution consiste à adopter une stratégie de Confiance Zéro basée sur les identités d’utilisateur, d’appareil et d’application. Contrairement aux contrôles d’accès réseau basés sur des éléments tels que les adresses IP source et de destination, des protocoles et des numéros de port, la Confiance Zéro applique et valide un contrôle d’accès au « moment de l’accès ». Cela évite d’avoir à faire des prédictions pour un déploiement, un réseau ou un sous-réseau entier. Seule la ressource de destination doit fournir les contrôles d’accès nécessaires.

  • Les groupes de sécurité réseau Azure peuvent être utilisés pour les contrôles d’accès de base de couche 3 & et 4, entre les réseaux virtuels Azure, leurs sous-réseaux et Internet.

  • Azure Web Application Firewall et le Pare-feu Azure permettent d’effectuer des contrôles d’accès réseau plus avancés qui nécessitent la prise en charge de la couche Application.

  • La solution de mot de passe d’administrateur local (LAPS) ou une solution tierce de gestion des accès privilégiés peut définir des mots de passe d’administrateur local forts et un accès juste-à-temps à ces derniers

En outre, des tiers proposent des approches de micro-segmentation susceptibles d’améliorer vos contrôles réseau en appliquant des principes de Confiance Zéro aux réseaux que vous contrôlez avec les ressources héritées sur ceux-ci.

Définir une stratégie de périmètre Internet

Indiquez si vous souhaitez utiliser des contrôles du fournisseur de services cloud natifs ou des appliances de réseau virtuel pour la sécurité de périmètre Internet.

Le trafic de périmètre Internet (parfois appelé « trafic Nord-Sud ») représente la connectivité réseau entre vos ressources dans le cloud et Internet. Les charges de travail héritées nécessitent une protection à partir des points de terminaison Internet, car elles ont été créées en partant du principe qu’un pare-feu Internet les protégeait contre ces attaques. Une stratégie de périmètre Internet vise à contrer les attaques à partir d’Internet qu’il est raisonnablement possible de détecter ou de bloquer.

Deux options principales peuvent fournir des contrôles et une surveillance de la sécurité de périmètre Internet :

  • Contrôles natifs du fournisseur de services cloud (Pare-feu Azure + [Pare-feu d’applications web (WAF)]/azure/application-gateway/waf-overview))

  • Appliances de réseau virtuel partenaires (fournisseurs de pare-feu et de WAF disponibles sur la Place de marché Azure)

  • Les contrôles natifs du fournisseur de services cloud offrent généralement une sécurité de base suffisante pour des attaques courantes, comme les 10 principales vulnérabilités identifiées par OWASP.

  • Par ailleurs, des capacités de partenaires du fournisseur de services cloud fournissent souvent des fonctionnalités bien plus avancées qui peuvent vous protéger contre des attaques sophistiquées (mais souvent rares). Les solutions de partenaires sont invariablement plus onéreuses que les contrôles natifs. De plus, la configuration de solutions de partenaires peut s’avérer très complexe et plus fragile que des contrôles natifs, car elles ne s’intègrent pas avec les contrôleurs d’infrastructure du cloud.

La décision d’utiliser des contrôles natifs ou des contrôles de partenaires doit être basée sur l’expérience et les exigences de votre organisation. Si les fonctionnalités des solutions de pare-feu avancées n’offrent pas un retour sur investissement suffisant, vous pouvez envisager d’utiliser les fonctionnalités natives spécialement conçues pour être faciles à configurer et à mettre à l’échelle.

Interrompre la technologie de sécurité réseau héritée

Interrompez l’utilisation des systèmes de détection et prévention des intrusions réseau (NIDS/NIPS) basés sur des signatures, ainsi que de prévention des fuites/pertes de données réseau (DLP).

Les principaux fournisseurs de services cloud filtrent déjà les paquets mal formés et les attaques de la couche Réseau courantes. Il n’est donc pas nécessaire d’utiliser une solution NIDS/NIPS pour les détecter. De plus, les solutions NIDS/NIPS classiques sont généralement pilotées par des approches basées sur des signatures (qui sont considérées comme obsolètes). Elles sont facilement contournées par les attaquants et produisent généralement un taux élevé de faux positifs.

Une solution DLP basée sur le réseau est de moins en moins efficace pour identifier des pertes de données tant involontaires que délibérées. Cela est dû au fait que la plupart des attaquants et des protocoles modernes utilisent un chiffrement au niveau du réseau pour les communications entrantes et sortantes. La seule solution de contournement viable pour ce problème est le « pontage SSL autorisé », lequel fournit un « intercepteur autorisé » qui met fin aux connexions réseau chiffrées puis les rétablit. L’approche de pontage SSL a été délaissée en raison du niveau de confiance nécessaire pour le partenaire exécutant la solution et des technologies utilisées.

En nous basant sur cette logique, nous vous recommandons de cesser d’utiliser ces technologies de sécurité réseau héritées. Toutefois, s’il ressort de l’expérience de votre organisation que ces technologies ont eu une incidence concrète sur la prévention et la détection des attaques réelles, vous pouvez envisager de les déplacer vers votre environnement cloud.

Concevoir la sécurité des sous-réseaux de réseau virtuel

Concevez des réseaux virtuels et des sous-réseaux pour la croissance.

La plupart des organisations finissent par ajouter à leurs réseaux plus de ressources que celles initialement prévues. Dans ce cas, les schémas d’adressage IP et de sous-réseau doivent être refactorisés en fonction des ressources supplémentaires. Ce processus est laborieux. La création d’un très grand nombre de petits sous-réseaux, puis la tentative de mapper des contrôles d’accès réseau (tels que des groupes de sécurité) à chacun d’eux apporte une valeur de sécurité limitée.

Nous vous recommandons de planifier vos sous-réseaux sur la base de rôles et fonctions courants qui utilisent des protocoles courants. Cela vous permet d’ajouter des ressources au sous-réseau sans avoir à apporter des modifications aux groupes de sécurité qui appliquent les contrôles d’accès au niveau du réseau.

N’utilisez pas de règles « tout ouvert » pour le trafic entrant et sortant des sous-réseaux. Adoptez une approche de « privilège minimum» et n’autorisez que des protocoles appropriés. Cela réduira la surface d’attaque du réseau global sur le sous-réseau.

Des règles « tout ouvert » (autorisant le trafic entrant/sortant échangé avec 0.0.0.0-255.255.255.255) donnent un faux sentiment de sécurité, car elles n’appliquent aucune sécurité.

Il existe cependant une exception à cela si vous souhaitez utiliser des groupes de sécurité uniquement pour la journalisation réseau. Bien que cette option ne soit pas recommandée, elle est praticable si une autre solution de contrôle d’accès réseau est en place.

Des sous-réseaux de réseau virtuel Azure peuvent être conçus de cette manière.

Contrer les attaques DDoS

Activez des protections contre les attaques pas déni de service distribué (DDoS) pour tous les services et applications web stratégiques.

De telles attaques sont courantes et faciles à mettre en œuvre par des attaquants peu sophistiqués. Des solutions de « DDoS en tant que service » sont même disponibles sur le « dark net ». Des attaques DDoS peuvent être très invalidantes et bloquer complètement l’accès à vos services, voire les annihiler, en fonction du type d’attaque.

Les principaux fournisseurs de services cloud offrent une protection DDoS des services présentant d’une efficacité et d’une capacité variables. Les fournisseurs de services cloud fournissent généralement deux options de protection DDoS :

  • Protection DDoS au niveau de l’infrastructure réseau cloud : tous les clients du fournisseur de services cloud bénéficient de ces protections. La protection est généralement concentrée au niveau du réseau (couche 3).

  • Le service Protection DDoS à des niveaux supérieurs qui profilent vos services : ce type de protection sous-tend vos déploiements, puis utilise des techniques de machine learning pour détecter tout trafic anormal et établir une protection de manière proactive sur la base de la protection avant la dégradation des services

Nous vous recommandons d’adopter une protection avancée pour tous les services dont l’indisponibilité aurait une incidence négative sur l’activité.

Un exemple de protection DDoS avancée est le service Azure DDoS Protection.

Décider d’une stratégie d’entrée/sortie Internet

Choisissez d’acheminer le trafic destiné à Internet via des dispositifs de sécurité locaux ou d’autoriser une connectivité Internet via des dispositifs de sécurité réseau basés sur le cloud.

Le routage du trafic Internet via des dispositifs de sécurité réseau locaux est également appelé « tunneling forcé ». Dans un scénario de tunneling forcé, toute la connectivité à Internet est acheminée vers des dispositifs de sécurité réseau locaux via une liaison de réseau étendu (WAN) intersite. L’objectif est de fournir aux équipes en charge de la sécurité réseau une sécurité et une visibilité du trafic Internet. Même lorsque vos ressources dans le cloud tentent de répondre à des demandes entrantes à partir d’Internet, les réponses sont acheminées via des dispositifs de sécurité réseau locaux.

Par ailleurs, le tunneling forcé est conforme au paradigme d’ « expansion de centre de développement » , et peut fonctionner assez bien pour une preuve de concept rapide, mais sa mise à l’échelle est médiocre en raison de la charge de trafic, de la latence et des coûts accrus.

L’approche recommandée pour l’utilisation en entreprise de production consiste à autoriser les ressources cloud à initier et traiter les demandes Internet directement via des dispositifs de sécurité réseau cloud définis par votre stratégie de périmètre Internet.

L’approche de l’Internet direct correspond au nième paradigme de centre de données (par exemple, les centres de centres de données Azure font partie intégrante de mon entreprise). Cette approche convient bien mieux pour un déploiement d’entreprise, car elle supprime les tronçons qui augmentent la charge, la latence et les coûts.

Nous vous recommandons d’éviter le tunneling forcé pour les raisons précitées.

Améliorer la visibilité du réseau

Vous devez activer une visibilité réseau améliorée en intégrant des journaux réseau dans une solution SIEM (Security Information and Event Management) telle que Microsoft Sentinel ou une troisième solution partenaire telle que Splunk, QRadar ou ArcSight ESM.

L’intégration des journaux de vos appareils réseau, voire du trafic réseau brut, vous offre une meilleure visibilité des menaces de sécurité potentielles en circulation. Ces informations de journal peuvent être intégrées dans des solutions SIEM avancées ou d’autres plateformes d’analytique. Les plateformes modernes d’analytique basée sur l’apprentissage automatique prennent en charge l’ingestion de très grandes quantités d’informations, et peuvent analyser très rapidement des jeux de données volumineux. En outre, ces solutions peuvent être réglées pour réduire considérablement les alertes de faux positifs.

Voici quelques exemples de journaux réseau qui offrent une visibilité :

Étapes suivantes

Pour obtenir des conseils de sécurité supplémentaires de Microsoft, consultez Documentation Microsoft sur la sécurité.