La sécurité du réseau n'est pas la sécurité de la charge de travail

Les violations, les piratages, les détournements, les pertes de données et les exfiltrations sont autant de problèmes qui existent dans la plupart des architectures en nuage, et ce pour une raison très simple : la plupart des technologies informatiques n'ont pas été conçues à l'origine en faisant de la sécurité une priorité. Les complexités liées au développement d'applications, aux systèmes d'exploitation des charges de travail, aux protocoles de mise en réseau et à la gestion globale des processus ont toutes été conçues en fonction de priorités différentes : fonctionnalité et résilience. Ces tâches doivent toutes fonctionner et survivre aux défaillances des éléments de l'architecture globale, mais la sécurisation de ces éléments n'a généralement été envisagée qu'après coup.

Le réseau étant l'infrastructure critique de l'architecture globale, il semblerait logique d'y appliquer des solutions de sécurité et de microsegmentation.

Indépendamment de la manière dont les applications sont développées, dont les différents systèmes d'exploitation sont construits et déployés, et dont tous ces éléments sont virtualisés, abstraits et gérés, la plupart de ces éléments doivent communiquer entre eux. S'il n'y a pas de réseau, chaque application est une île. De plus, la plupart des applications sont aujourd'hui conçues pour être accessibles à des clients distants, via un réseau privé ou l'internet. Cela est nécessaire dans tout type d'architecture en nuage, et toute architecture native en nuage ne fonctionnera tout simplement pas sans un réseau déjà existant pour communiquer à travers elle. On peut donc affirmer que l 'élément le plus critique de toute architecture en nuage est en fait le réseau lui-même.

En raison de la nature critique de l'infrastructure de réseau dans toute architecture en nuage, certains défis et priorités sont spécifiques à la seule couche réseau de toutes les architectures. Le réseau a des préoccupations qui sont totalement indépendantes des charges de travail et des applications, qui dépendent du réseau. Voici quelques exemples de ces problèmes de réseau :

• Fiabilité (le réseau doit fonctionner)
• Résilience (la défaillance d'un ou de plusieurs dispositifs du réseau ne doit pas entraîner une défaillance de l'ensemble du système)
• Ingénierie du trafic et qualité de service (les réseaux IP sont, par conception, "sans connexion", mais il devrait y avoir des moyens d'ingénierie et de hiérarchisation des différents types de trafic).
• Évolution (les réseaux doivent pouvoir évoluer sans se heurter à un plafond de ressources)

Les applications et les charges de travail ne devraient pas avoir besoin de connaître ces détails pour utiliser le réseau.

Qu'est-ce que cela signifie pour la sécurisation du réseau et des charges de travail ? Il y a des considérations distinctes que j'explorerai, en particulier le contraste entre la sécurité du réseau et les solutions basées sur le réseau et la sécurité de la charge de travail et les solutions telles que la microsegmentation.

Brève histoire de la sécurité des réseaux

La sécurité étant toujours un élément tardif dans la plupart des architectures en nuage, la sécurité et la segmentation du réseau ont traditionnellement été mises en œuvre au niveau de la couche réseau. Le réseau étant l'infrastructure critique de l'architecture globale, il semblerait logique d'y appliquer des solutions de sécurité et de microsegmentation.

Si vous remontez plusieurs décennies en arrière, la sécurité des réseaux IP prenait à l'origine la forme de listes de contrôle d'accès ("ACL") sur les routeurs et les commutateurs. Les périphériques réseau traitent généralement le trafic par paquet, de sorte que lorsque les paquets arrivent à un routeur ou à un commutateur, ces listes de contrôle d'accès sont vérifiées pour décider d'autoriser ou de bloquer le transfert d'un paquet.

Cette approche a ensuite été confiée à des dispositifs de réseau dédiés - les pare-feu - qui utilisaient à l'origine la même approche de base. Comme tous les paquets IP contiennent des informations dans leurs en-têtes qui indiquent leur source et leur destination, en plus des numéros TCP ou UDP qui indiquent quel type de données est présent dans la charge utile du paquet, un pare-feu utilise ces informations pour prendre des décisions de transfert basées sur leurs propres listes de contrôle d'accès. Comme le réseau traite les paquets, il était logique de le laisser s'occuper également de la sécurité et de la microsegmentation, ce qui permettait aux équipes chargées du développement des applications et des systèmes de se concentrer sur d'autres questions.

Cependant, il est généralement facile de tromper un pare-feu basé sur les paquets. Il n'est pas très difficile d'usurper les adresses et les numéros de port TCP/UDP dans un paquet IP, ce qui permet de masquer facilement le contenu des données. Les pare-feu basés sur les sessions ont donc évolué pour se concentrer sur la mise en correspondance de tous les paquets d'un flux donné avec une session unique, et pour surveiller le comportement de cette session en fonction de l'application à laquelle elle "pense" être associée. Ces pare-feu ne disposent pas d'une visibilité totale sur chaque paquet, mais ils comparent le comportement de ces paquets et de ces sessions avec les comportements de base des applications, à la recherche d'anomalies.

Plus tard sont apparus les pare-feu dits de "nouvelle génération", qui appliquent beaucoup plus d'intelligence à l'identification du contenu d'un paquet, de l'application à laquelle il est associé, de l'utilisateur auquel il est associé et d'autres détails indiquant une violation de la sécurité. Mais tous ces détails se produisent en ligne dans le réseau, et non dans les charges de travail de la source ou de la destination elles-mêmes. Les pare-feu n'ont aucune idée de ce qui se passe au niveau des charges de travail qui envoient et reçoivent ces paquets, à moins qu'ils ne communiquent d'une manière ou d'une autre avec un outil central qui surveille également les charges de travail et les applications et dirige ensuite le trafic sélectionné vers le pare-feu. Mais ce déploiement peut s'avérer complexe, de sorte que les pare-feu sont souvent simplement installés sur le réseau, attendant que les paquets arrivent.

La sécurité du réseau est différente de la sécurité de la charge de travail

Parallèlement aux pare-feu qui décident quels paquets peuvent ou ne peuvent pas être transmis, les routeurs et les commutateurs ont leurs propres problèmes de sécurité, qui résultent du même problème de base : la sécurité n'était pas une préoccupation majeure lorsque les protocoles de mise en réseau ont été conçus à l'origine.

Le protocole TCP/IP et les protocoles de routage dynamique utilisés pour transmettre les paquets, tels que BGP et OSPF, ont été conçus avec les mêmes objectifs de base que les applications et les charges de travail : fonctionnalité et résilience. La sécurité n'était pas une priorité lors de la création des réseaux. La sécurité et la microsegmentation sont devenues une priorité à un stade ultérieur de l'évolution des réseaux, et les solutions de sécurité des réseaux ont été utilisées pour répondre aux problèmes de sécurité spécifiques aux réseaux. La sécurité ne concerne pas seulement les charges de travail et les applications. Le réseau pose des problèmes de sécurité sur lesquels les charges de travail et les applications n'ont aucune visibilité.

Pour rappel, il ne s'agit là que de quelques exemples de problèmes de sécurité qui se posent au niveau de la couche réseau de toute architecture en nuage :

• Ingénierie du trafic
• Déni de service (DoS)
• Usurpation d'adresse ARP
• Authentification BGP
• Redirection du trafic
• Attaques de type "Man-in-the-middle
• Propagation d'itinéraires erronés
• Détournement du routeur de premier saut
• Détournement de cookie de session

Les éléments de cette courte liste sont tous des problèmes de sécurité spécifiques aux réseaux, et non aux charges de travail ou aux applications. Par exemple, les défis de l'ingénierie du trafic sont traités par des technologies telles que MPLS et la fiabilité des protocoles de distribution d'étiquettes. Le déni de service est un problème important qui est souvent résolu par l'utilisation de communautés BGP échangées avec les pairs de routage des FAI. L'usurpation d'adresse ARP est un problème dans lequel les routeurs modifient leurs correspondances entre les adresses de la couche 3 et de la couche 2, ce qui entraîne le détournement de la destination du trafic. L'authentification BGP nécessite quelque chose comme RPKI pour crypter les informations échangées entre les pairs BGP, afin d'éviter les problèmes de routage sur l'internet. Et ainsi de suite. La mise en réseau possède son propre vocabulaire spécialisé pour traiter les problèmes de sécurité qui sont propres à la couche réseau de toute architecture en nuage.

Ces exemples ne représentent que quelques-uns des principaux problèmes de sécurité liés aux architectures de réseau, et non aux architectures de charge de travail ou d'application. Les équipes chargées du développement des applications et des systèmes n'ont généralement aucune visibilité sur ces problèmes de sécurité du réseau, parce qu'elles ne devraient pas en avoir besoin. Lorsque le système d'exploitation d'une charge de travail utilise iptables, par exemple, pour envoyer ou recevoir un paquet, il n'a pas besoin de savoir si le protocole BGP est détourné d'une manière ou d'une autre entre les fournisseurs d'accès au réseau. Les charges de travail et les applications sont concernées par la sécurité des charges de travail et des applications, et non par la sécurité du réseau.

Les solutions de sécurité des réseaux ne sont pas des solutions de sécurité de la charge de travail

Cela signifie que les outils conçus pour relever les défis de la sécurité des réseaux ne sont généralement pas les outils appropriés pour relever les défis de la sécurité et de la microsegmentation au niveau des charges de travail ou des applications. La sécurité des charges de travail exige souvent de ne pas être limité par l'échelle : le déploiement de milliers de charges de travail dans plusieurs nuages ne doit pas dépendre d'un seul outil de couche réseau pour assurer d'une manière ou d'une autre la sécurité au niveau de l'application de ces charges de travail.

Les charges de travail migrent souvent en direct à travers les frontières de la couche 3, ou entre les nuages, et les charges de travail ne devraient pas dépendre des outils de la couche réseau pour suivre d'une manière ou d'une autre ces migrations afin d'appliquer la sécurité de la charge de travail et la microsegmentation. Les applications reposent sur des dépendances entre les charges de travail, et ces dépendances ne sont souvent pas visibles pour les outils de la couche réseau. La définition d'une clôture autour des applications ne doit donc pas être limitée par le manque de visibilité du réseau sur l'ensemble des dépendances des applications.

Certains fournisseurs de réseaux proposeront leurs solutions SDN pour répondre aux exigences en matière de sécurité des charges de travail et des applications et de microsegmentation. Mais ces outils résident dans les couches réseau ou hyperviseur, et ils ont été conçus pour répondre aux priorités de ces couches : telles que l'automatisation, la virtualisation, l'analyse des réseaux, les superpositions de réseaux et les tunnels, et l'authentification entre les protocoles de routage dynamiques. Les outils SDN n'ont pas été conçus pour assurer la sécurité et la microsegmentation des charges de travail et des applications à grande échelle.

Ils peuvent également proposer des pare-feu - matériels ou instances virtualisées dans un hyperviseur - comme solutions aux exigences de sécurité des charges de travail et des applications, en faisant valoir que les pare-feu de nouvelle génération offrent une visibilité complète de la couche 7 sur le trafic du réseau. Cependant, tout pare-feu n'est utile qu'une fois que les paquets l'atteignent. Les pare-feu n'ont pas la capacité d'influencer le comportement des applications ou des charges de travail à leur source, mais se contentent d'attendre que les paquets arrivent au port du pare-feu. Les pare-feu assurent la sécurité du réseau et la microsegmentation lorsque le trafic est en transit (trafic nord-sud). Ils ne renforcent pas la sécurité des applications ou des charges de travail à la source - trafic est-ouest. Les deux solutions sont nécessaires à la réalisation d'une véritable architecture de confiance zéro, mais une couche de l'architecture ne peut pas fournir une sécurité totale et une microsegmentation à l'autre.

Les équipes chargées de la mise en réseau ne devraient pas être chargées de la sécurité de la charge de travail ou des applications.

Les équipes de réseau se concentrent sur les tâches de réseau, qui sont différentes des tâches de charge de travail ou d'application. Ces tâches impliquent des termes pertinents pour ces équipes, tels que les traductions et les mécanismes de transfert des couches 2 et 3, les protocoles de routage tels que BGP et OSPF et la manière dont ils s'appuient les uns sur les autres, ainsi que leurs propres mécanismes d'authentification. Les solutions aux problèmes de réseau de la couche 2, telles que spanning tree et ECMP, ont également leurs propres priorités en matière de sécurité. Les outils de mise en réseau tels que le SDN et les appareils de réseau virtualisés déployés dans les hyperviseurs se concentrent sur les questions spécifiques aux priorités de mise en réseau. Dans aucune de ces solutions, les risques de sécurité au sein d'une charge de travail ne constituent une priorité.

Cela signifie que lorsque vous concevez des solutions de sécurité et de microsegmentation pour les charges de travail, ces solutions doivent être déployées à cet endroit : sur la charge de travail. Les outils de réseau ont des priorités différentes de celles des charges de travail ou des applications. Les outils de sécurité des réseaux existeront toujours et se concentreront sur l'application du trafic nord-sud, à l'intérieur et à l'extérieur de la structure globale du réseau. Ces outils de mise en réseau seront déployés sur des dispositifs de mise en réseau. La sécurité de la charge de travail doit être déployée sur les charges de travail elles-mêmes et se concentrera sur l'application du trafic est-ouest, entre les charges de travail et entre les applications.

Le fait que chaque couche de l'architecture globale se concentre sur les priorités qui lui sont propres permettra à chacune d'être agnostique par rapport à l'autre, aucune couche n'imposant de limites au fonctionnement ou à l'évolution de l'autre. Le résultat est une architecture "zéro confiance" entièrement réalisée.

De nombreuses architectures "cloud native" suivent les meilleures pratiques en matière de sécurité et déploient des solutions de sécurité des charges de travail sur les charges de travail elles-mêmes. Mais les vieilles habitudes ont la vie dure, et souvent, lorsque les environnements informatiques existants migrent des centres de données vers les services en nuage, l'approche traditionnelle consistant à utiliser des solutions de mise en réseau pour tenter d'appliquer la sécurité de la charge de travail sera également migrée, avec pour résultat une couche réseau qui est souvent aveugle aux exigences de sécurité est-ouest entre les charges de travail et les applications. Le résultat n'est pas la confiance zéro.

C'est ici qu'Illumio s'inscrit dans l'architecture de sécurité globale. Contrairement aux approches traditionnelles de segmentation du réseau, Illumio permet d'appliquer la sécurité et la microsegmentation directement à l'entité que vous essayez de sécuriser et de segmenter : la charge de travail elle-même. Cela permet à la sécurité des charges de travail et des applications, ainsi qu'à la microsegmentation, de s'adapter et d'évoluer sans dépendre de l'endroit où elles se trouvent sur le réseau. Cela permet aux charges de travail de résider ou de migrer n'importe où dans des centres de données sur site ou chez des fournisseurs de services en nuage.

Une architecture multi-cloud créera une vaste structure de réseau, avec une accessibilité à travers toutes les topologies de réseau sous-jacentes. La sécurité et la microsegmentation devraient suivre la même ligne directrice, en fournissant une solution cohérente et évolutive sur la même structure de réseau, de bout en bout. La confiance zéro signifie que la limite de confiance en matière de sécurité est étendue à chaque charge de travail et à chaque application qui doit être protégée, et cet objectif ne doit pas être limité en essayant de l'atteindre dans une couche différente de l'architecture en nuage.

Pour en savoir plus sur ces sujets et sur la façon dont Illumio résout les problèmes de sécurité des charges de travail et des applications :

• Regardez cette vidéo rapide sur l 'évolution de la segmentation
• Consultez ce webinaire à la demande : Débloquez la sécurité du réseau : La segmentation en toute simplicité