La sécurité des réseaux à l'ère des conteneurs

L'un des avantages d'être dans l'industrie depuis de nombreuses années est le fait que nous pouvons observer comment sécurité du réseau les tendances en matière de centres de données ont évolué et prédisent quelque peu ce qui va suivre, sur la base de modèles communs et d'intuitions.

Les limites du réseau et de la sécurité évoluent

Il y a 15 ans, la sécurité du réseau était assez simple dans les centres de données. Les protocoles de couche 2 étaient les rois absolus dans leur domaine et le pare-feu pouvait être placé à la périphérie pour protéger Internet ou une connexion WAN. Les serveurs d'une application donnée étaient tous connectés dans le même rack et la frontière entre les différents éléments de l'infrastructure était bien définie. La segmentation était assez simple.

Quelques années plus tard, afin de consolider tous ces serveurs et de simplifier la connectivité, les serveurs châssis et lames ont lentement gagné en popularité, créant ainsi un premier changement dans les limites du réseau et de la sécurité entre les personnes chargées de la gestion des serveurs et les personnes chargées du réseau et de la sécurité. Qui est responsable des modules de connectivité de ces châssis et où devons-nous insérer les appareils de sécurité ? La plupart du temps, le module réseau finissait par être le module le moins important du châssis et c'était toujours un cauchemar de se connecter au reste de l'infrastructure réseau et de sécurité.

Mais cette bataille a été bouleversée par une nouvelle technologie. ESX de VMware hyperviseur a rapidement démocratisé la possibilité de partager le même serveur matériel pour faire fonctionner de nombreux serveurs virtuels. Par conséquent, pour connecter ces serveurs virtuels entre eux, le réseau a dû à nouveau se déplacer vers un autre endroit : au sein de l'hyperviseur. Shifts a commencé par un simple commutateur virtuel, mais a rapidement été étendu aux services de couche 3 et, finalement, à la sécurité.

Et encore une fois, malgré l'évolution de l'infrastructure des centres de données, le cloud public a commencé son ascension pour offrir une gamme de services entièrement automatisés et extrêmement agiles au marché des entreprises. Les développeurs ont rapidement compris la valeur de cette nouvelle infrastructure abstraite capable de fournir un service évolutif et hautement disponible sans avoir à gérer la complexité de l'infrastructure.

Il y a quelques années, un nouveau type de charge de travail est apparu, léger, portable et facile à faire tourner ou à démonter en quelques secondes : les conteneurs. Avec la prolifération des conteneurs, les développeurs ont rapidement compris qu'il était nécessaire d'orchestrer ces ressources de calcul, ainsi que le réseau, pour s'assurer que les applications puissent évoluer à la hausse et à la baisse sans avoir à dépendre d'un réseau externe et d'une infrastructure de sécurité. Un cluster de conteneurs est un nouvel élément d'infrastructure qui mélange calcul, réseau et sécurité et crée, une fois de plus, un nouveau décalage dans les limites de sécurité du réseau.

Alors, qu'avons-nous appris en 15 ans ? Quel est le schéma commun de toutes ces évolutions ?

1. La limite de sécurité du réseau se déplace de plus en plus vers la couche de calcul, car les développeurs repoussent toujours les limites pour obtenir plus de flexibilité lors du développement et du test de leurs applications.
2. Les équipes chargées des réseaux et de la sécurité sont en retard et, au mieux, peuvent recommander des choix ou des solutions, mais la plupart du temps, elles héritent de ce qui a été décidé par les équipes chargées des applications ou du cloud.
3. La sécurisation des infrastructures est plus difficile lorsque les éléments n'ont pas été pensés et conçus dans un souci de sécurité, et cela crée généralement un niveau de complexité supplémentaire lorsqu'il est ajouté ultérieurement.

Quel est le problème avec les conteneurs ?

Les conteneurs et les clusters de conteneurs ne font pas exception à cette tendance qui consiste à déplacer de plus en plus le réseau vers les couches logicielles et informatiques. Comme décrit précédemment, cela se produit depuis de nombreuses années et il n'y a aucune raison pour que cela change si les équipes chargées du réseau et de la sécurité n'inversent pas cette tendance.

Du point de vue du réseau et de la sécurité, les conteneurs n'introduisent rien de nouveau ou d'inconnu, ils combinent simplement ce que nous connaissons déjà (adresses IP, sous-réseaux, DHCP/DNS, zones, segments, encapsulation, NAT, pare-feu ou équilibreurs de charge), mais tout se trouve dans le système d'exploitation lui-même, ce qui constitue un problème fondamental.

Les équipes informatiques adorent les limites, les responsabilités et la propriété, et c'est le contraire du mode de fonctionnement des clusters de conteneurs. Ils ont été conçus pour être autonomes, orchestrés et opaques du monde extérieur. D'une part, c'est une bonne nouvelle qu'une nouvelle infrastructure ne nécessite pas de longues sessions de conception pour être connectée et fonctionner. D'autre part, cela pose une véritable question de sécurité quant à la manière dont les flux d'applications peuvent être sécurisés si vous ne savez pas et ne comprenez pas ce qui se passe au sein de ces clusters.

Que peut-on faire pour changer cela ?

Idéalement, les développeurs devraient développer du code et le confier à une autre équipe pour le mettre en production, de manière entièrement testée et automatisée, sur une infrastructure conçue pour l'évolutivité et la disponibilité, et avec la sécurité en tête des priorités à chaque niveau de la pile.

Eh bien, il semble que dans de nombreuses organisations, nous n'en ayons pas encore atteint ce point. Les équipes DevOps sont connectées à leurs pairs en matière de développement, mais ce n'est pas toujours le cas pour les équipes chargées des réseaux et de la sécurité, et cela doit changer si nous voulons considérer les conteneurs comme une technologie de rupture sur le marché.

Les équipes chargées du réseau et de la sécurité devraient consacrer plus de temps à comprendre ce qui a été transporté et sécurisé par l'infrastructure. Ils devraient apprendre ce qu'est un pipeline CI/CD et avoir une opinion sur la façon dont les éléments sont construits au sein de l'application afin de pouvoir adapter les mécanismes de sécurité pour compléter ce que l'application n'est pas capable de réaliser. Cela nécessite d'acquérir de nouvelles compétences, d'accepter les différences et de faire preuve d'esprit critique mais ouvert à de nouveaux concepts qui, au premier abord, ne semblent pas être une bonne idée mais qui peuvent en fait être très efficaces.

Les conteneurs sont l'exemple parfait d'une technologie qui oblige les personnes de tous les domaines d'un service informatique à apprendre les unes des autres.

Dans le cas contraire, c'est la recette du désastre. Il n'y a pas de cluster de conteneurs sans réseau, il n'y a pas d'application conteneurisée en production sans sécurité et il n'y a pas d'infrastructure partagée sans segmentation. Les équipes chargées des réseaux et de la sécurité doivent profiter de cette opportunité pour découvrir de nouvelles façons de faire les choses, passer plus de temps à comprendre comment les choses peuvent être effectuées dans les logiciels et s'approprier le réseau et les couches de sécurité en proposant des conceptions simples, sécurisées et stables au service de la couche application.

Par où commencer ?

Il n'existe évidemment pas de solution miracle ou d'arme secrète qui puisse être la solution universelle. Mais voici quelques idées qui peuvent contribuer à la réussite de votre équipe :

Apprenez à connaître vos ennemis : Les développeurs et les équipes DevOps ne sont pas les ennemis des équipes chargées du réseau et de la sécurité. Ils ont tous le même objectif : le business. Mais si l'on ne sait pas ce que font les autres équipes, il est plus difficile de voir ce qui peut être fait pour s'améliorer en tant que groupe. La construction d'infrastructures complexes telles que des clusters de conteneurs nécessite des décisions étroitement liées pour réussir, notamment en matière de sécurité.

Acquérir les connaissances : Personne ne sait tout, mais tout le monde peut tout apprendre. Il est normal d'être léger dans certains domaines de votre infrastructure, mais il n'est certainement pas acceptable de ne pas vouloir apprendre comment les choses sont faites ou devraient être faites. Les conteneurs, les plateformes d'orchestration et les maillages de services ne sont pas faciles à aborder. Il faut du temps pour se sentir à l'aise avec une nouvelle terminologie ou de nouveaux concepts, mais c'est tellement gratifiant de franchir ce seuil de compréhension et de pouvoir transformer ces connaissances en actions.

Un réseau est un réseau et la sécurité est universelle : N'oubliez pas qu'un cluster de conteneurs est un ensemble d'adresses IP (associées à des conteneurs) qui communiquent entre elles. De plus, les applications ne sont pas destinées à vivre dans un cluster de conteneurs sans être exposées au monde. Il y aura donc un concept visant à ouvrir certaines portes sur le monde. Les ingénieurs réseau et sécurité sont responsables des flux allant d'un bout à l'autre d'un cluster, ainsi que de l'entrée et de la sortie des paquets de ce cluster. Si quelque chose est compromis au sein d'un cluster de conteneurs, il est de la responsabilité de l'équipe de sécurité du réseau de surveiller, de réagir et de réagir pour éviter la propagation d'une violation. Oui, les clusters de conteneurs ont une approche différente en matière de réseau et de sécurité, mais il s'agit tout de même d'un réseau qui doit être segmenté et sécurisé.

Cherchez la vérité : Il est important de comprendre le statu quo et de le remettre en question. Quand les choses ne fonctionnent pas comme vous le pensiez, c'est normal. Cela signifie que collectivement, en tant qu'équipe, vous devez rechercher la vérité et vous mettre d'accord sur celle-ci. Une technologie bien comprise est plus facile à déployer, à sécuriser et à dépanner.

Les conteneurs, les plateformes d'orchestration et les maillages de services gagnent en popularité dans les organisations informatiques d'aujourd'hui et il est extrêmement important qu'en tant qu'ingénieur réseau et sécurité, vous compreniez les concepts de ces technologies. Certains concepts vous sembleront très familiers, d'autres vous sembleront très étranges, mais pour sécuriser correctement les objets, vous devez savoir comment ils fonctionnent réellement !

Consultez notre page sur les conteneurs pour plus d'informations sur la manière de tirer parti d'Illumio pour la segmentation des conteneurs.