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

Les violations, les piratages, le piratage, la perte de données et l'exfiltration sont tous des problèmes qui existent dans la plupart des architectures cloud pour une raison très simple : la plupart des technologies informatiques n'ont pas été conçues à l'origine avec la sécurité comme priorité. Les complexités liées au développement d'applications, aux systèmes d'exploitation des charges de travail, aux protocoles 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 elles doivent survivre aux défaillances des éléments de l'architecture globale, mais sécurisation ces éléments ont généralement été considérés après coup.

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

Quelle que soit la manière dont les applications sont développées, comment les différents systèmes d'exploitation sont créés et déployés, et quelle que soit la manière dont tout cela est virtualisé, abstrait et géré, la plupart de ces éléments doivent communiquer entre eux. S'il n'y a pas de réseau, chaque application est un îlot. Et la plupart des applications actuelles sont conçues pour être accessibles par des clients distants, via un réseau privé ou via Internet. Cela est requis dans tout type d'architecture cloud, et aucune architecture native du cloud ne fonctionnera tout simplement pas sans un réseau existant pour communiquer à travers elle. On peut donc affirmer que l'élément le plus critique de toute architecture cloud globale est en fait le réseau lui-même.

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

• Fiabilité (le réseau doit fonctionner)
• Résilience (la défaillance d'un ou de plusieurs périphériques réseau ne doit pas provoquer de panne à l'échelle du système)
• Ingénierie du trafic et qualité de service (les réseaux IP sont, de par leur conception, « sans connexion », mais il devrait y avoir des moyens de concevoir et de hiérarchiser les différents types de trafic)
• Mise à l'échelle (les réseaux devraient pouvoir évoluer sans atteindre un certain plafond de ressources)

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

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

Bref historique de la sécurité des réseaux

La sécurité étant toujours une priorité pour la plupart des architectures cloud, la sécurité et segmentation du réseau ont traditionnellement été mis en œuvre au niveau de la couche réseau. Le réseau étant l'infrastructure critique de l'architecture globale, il semblerait judicieux d'y appliquer des solutions de sécurité et de microsegmentation.

Si l'on remonte à plusieurs décennies, 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. Ainsi, lorsque les paquets arrivent à un routeur ou à un commutateur, ces listes de contrôle d'accès sont vérifiées pour prendre des décisions quant à l'autorisation ou au blocage du transfert d'un paquet.

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

Cependant, il est généralement facile de tromper un pare-feu basé sur des paquets. Il n'est pas trop difficile d' « usurper » des adresses et des numéros de port TCP/UDP dans un paquet IP, ce qui permet de créer un paquet qui peut facilement masquer le contenu de sa charge utile de données. Les pare-feux basés sur les sessions ont donc évolué pour se concentrer sur le mappage de tous les paquets d'un flux donné vers une session unique, et pour surveiller le comportement de cette session en fonction de l'application à laquelle elle « pense » être associée. Ces pare-feux n'offraient pas une visibilité complète sur chaque paquet, mais ils comparent le comportement de ces paquets et de ces sessions avec les comportements de base des applications, afin de détecter les anomalies.

Plus tard, des pare-feux dits de « nouvelle génération » sont apparus, qui utilisent beaucoup plus d'intelligence pour identifier le contenu d'un paquet, l'application à laquelle il est associé, l'utilisateur auquel il est associé et d'autres détails indiquant une faille de sécurité. Mais tous ces détails apparaissent en ligne dans le réseau, et non dans les charges de travail source ou de destination elles-mêmes. Les pare-feux n'ont aucune idée de ce qui se passe sur les 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, puis dirige le trafic sélectionné vers le pare-feu. Mais ce déploiement peut être complexe, de sorte que les pare-feux se contentent souvent de rester sur le réseau en attendant l'arrivée des paquets.

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

Parallèlement aux firewalls qui prennent des décisions concernant les paquets qui peuvent ou ne peuvent pas être transférés, les routeurs et les commutateurs ont leurs propres préoccupations en matière de sécurité, qui découlent du même problème fondamental : la sécurité n'était pas une préoccupation majeure lors de la conception initiale des protocoles réseau.

Les protocoles TCP/IP et de routage dynamique utilisés pour transférer des paquets, tels que BGP et OSPF, ont été conçus avec les mêmes objectifs fondamentaux que les applications et les charges de travail : fonctionnalité et résilience. La sécurité n'était pas une priorité au début de la mise en réseau. La sécurité et la microsegmentation sont devenues une priorité à un stade ultérieur de l'évolution du réseau, et des solutions de sécurité réseau ont été utilisées pour répondre aux problèmes de sécurité spécifiques au réseau. La sécurité ne concerne pas uniquement les charges de travail et les applications. Le réseau présente des problèmes de sécurité sur lesquels les charges de travail et les applications n'ont aucune visibilité.

Pour rappel, ce ne sont là que quelques exemples des problèmes de sécurité qui existent au niveau de la couche réseau de toute architecture cloud :

• Ingénierie du trafic
• Déni de service (DoS)
• Usurpation d'identité ARP
• Authentification BGP
• Redirection du trafic
• Attaques de type « Man-in-the-middle »
• Propagation d'itinéraires bidon
• Piratage d'un routeur au premier saut
• Piratage des cookies de session

Les éléments de cette courte liste concernent tous les problèmes de sécurité spécifiques au réseau, et non aux charges de travail ou aux applications. Par exemple, les défis liés à l'ingénierie du trafic sont relevés par des technologies telles que le 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 homologues de routage des FAI. L'usurpation ARP est un problème dans lequel les routeurs modifient leurs mappages entre les adresses de couche 3 et de couche 2, ce qui entraîne le détournement de la destination du trafic. L'authentification BGP nécessite quelque chose comme le RPKI pour crypter les informations échangées entre les pairs BGP, afin d'éviter les problèmes de routage sur 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é propres à la couche réseau de toute architecture cloud.

Ces exemples ne sont que quelques-unes des principales préoccupations de sécurité des architectures réseau, et non des architectures de charge de travail ou d'applications. 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, car 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 BGP est piraté d'une manière ou d'une autre entre les FAI du réseau. Les charges de travail et les applications concernent la charge de travail et la sécurité des applications, et non la sécurité du réseau.

Les solutions de sécurité réseau ne sont pas des solutions de sécurité des charges de travail

Cela signifie que les outils conçus pour relever les défis de sécurité des réseaux ne sont généralement pas les outils appropriés pour relever les défis de sécurité et de microsegmentation des charges de travail ou des applications. La sécurité des charges de travail nécessite souvent de ne pas être limitée par l'échelle : le déploiement de milliers de charges de travail sur plusieurs clouds ne doit pas dépendre d'un outil de couche réseau unique pour assurer une sécurité au niveau des applications à ces charges de travail.

Les charges de travail migrent souvent en direct au-delà des limites de la couche 3 ou entre les clouds, et les charges de travail ne devraient pas dépendre d'outils de couche réseau qui suivent ces migrations d'une manière ou d'une autre afin de les appliquer sécurité des charges de travail et 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 de microsegmentation et de sécurité de la charge de travail et des applications. 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 : automatisation, virtualisation, analyse du réseau, superpositions et tunneling réseau, et authentification entre les protocoles de routage dynamique. 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-feux (matériels ou instances virtualisées dans un hyperviseur) comme solutions aux exigences de sécurité de la charge de travail et des applications, en faisant valoir que les pare-feux de nouvelle génération offrent une visibilité complète du trafic réseau de niveau 7. Cependant, tout pare-feu n'est utile que lorsque les paquets l'atteignent. Les pare-feux n'ont pas la capacité d'influencer le comportement des applications ou des charges de travail à leur source. Ils attendent simplement que les paquets arrivent sur le port d'un pare-feu. Les pare-feux renforcent la sécurité du réseau et la microsegmentation lorsque le trafic est en transit — trafic nord-sud. Ils n'assurent pas la sécurité des applications ou des charges de travail à la source, à savoir le trafic est-ouest. Les deux solutions sont nécessaires pour une véritable Confiance zéro architecture à réaliser, mais une couche de l'architecture ne peut pas fournir une sécurité et une microsegmentation complètes à l'autre.

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

Les équipes réseau se concentrent sur les tâches réseau, qui sont différentes des tâches liées à la charge de travail ou aux applications. Ces tâches impliquent des termes pertinents pour ces équipes, tels que les mécanismes de traduction et de transfert des couches 2 et 3, les protocoles de routage tels que BGP et OSPF et la façon dont ils interagissent les uns avec les autres, et leurs propres mécanismes d'authentification. Les solutions aux problèmes de réseau de couche 2, tels que Spanning Tree et ECMP, ont également leurs propres priorités en matière de sécurité. Les outils réseau tels que le SDN et les appareils réseau virtualisés déployés dans les hyperviseurs sont axés sur des problèmes spécifiques aux priorités en matière de réseau. Dans aucune de ces solutions, les risques de sécurité liés à la charge de travail elle-même ne constituent une priorité.

Tout cela signifie que lors de la conception de solutions de sécurité et de microsegmentation pour les charges de travail, ces solutions doivent être déployées sur place : sur la charge de travail. Les priorités des outils réseau diffèrent en fonction de la charge de travail ou des applications. Des outils de sécurité réseau existeront toujours, axés 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 appareils réseau. La sécurité des charges de travail doit être déployée sur les charges de travail elles-mêmes, et celles-ci se concentreront sur l'application du trafic est-ouest, entre les charges de travail et entre les applications.

Le fait de concentrer chaque couche de l'architecture globale sur les priorités spécifiques à sa propre couche permettra à chacune d'être indépendante de l'autre, aucune des couches n'imposant de limites au mode de fonctionnement ou d'évolution de l'autre. Le résultat est une architecture Zero Trust entièrement réalisée.

De nombreuses architectures cloud natives suivent les meilleures pratiques 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 sont migrés des centres de données vers services cloud, l'approche traditionnelle consistant à utiliser des solutions réseau pour tenter de renforcer la sécurité des charges de travail sera également migrée, ce qui aboutira à une couche réseau qui ignore souvent les exigences de sécurité est-ouest entre les charges de travail et les applications. Le résultat n'est pas Zero Trust.

C'est là qu'Illumio s'intègre 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 charge de travail et à la sécurité des applications, ainsi qu'à la microsegmentation, de s'adapter et d'évoluer sans dépendre de leur emplacement 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 entre des fournisseurs de cloud.

Une architecture multicloud créera une structure réseau étendue, accessible à toutes les topologies réseau sous-jacentes. La sécurité et la microsegmentation doivent suivre les mêmes directives, fournissant une solution cohérente et évolutive sur la même structure réseau, de bout en bout. Zero Trust signifie que la limite de confiance en matière de sécurité est étendue à chaque charge de travail et à chaque application qui doivent être protégées, et cet objectif ne doit pas être limité en essayant de l'activer dans une couche différente de l'architecture cloud.

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

• Regardez cette vidéo de présentation rapide sur L'évolution de la segmentation
• Consultez ce webinaire à la demande : Débloquez la sécurité du réseau : la segmentation simplifiée