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

L'un des avantages d'être dans le secteur depuis de nombreuses années est que nous pouvons observer l'évolution des tendances en matière de sécurité des réseaux dans les centres de données et prédire dans une certaine mesure ce qui se passera ensuite, sur la base de modèles communs et de l'intuition.

Les frontières des réseaux et de la sécurité évoluent

Il y a quinze ans, la sécurité des réseaux était assez simple dans les centres de données. Les protocoles de la couche 2 étaient les rois absolus dans leur domaine et le pare-feu pouvait être placé à la périphérie pour protéger l'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 a été assez simple.

Quelques années plus tard, afin de consolider tous ces serveurs et de simplifier la connectivité, les châssis et les serveurs lames se sont peu à peu imposés, créant le premier changement dans les frontières du réseau et de la sécurité entre les personnes qui gèrent les serveurs et celles qui sont chargées du réseau et de la sécurité. Qui est responsable des modules de connectivité dans ces châssis, et où devons-nous insérer les dispositifs de sécurité ? La plupart du temps, le module réseau s'est avéré être le module le moins important du châssis et a toujours été un cauchemar à connecter au reste du réseau et de l'infrastructure de sécurité.

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

Une fois encore, malgré l'évolution de l'infrastructure des centres de données, le nuage public a commencé son ascension pour offrir une gamme de services au marché des entreprises, entièrement automatisés et extrêmement agiles. Il n'a pas fallu longtemps aux développeurs pour comprendre la valeur de cette nouvelle infrastructure abstraite qui peut 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 à mettre en place ou à démonter en quelques secondes : les conteneurs. Avec la prolifération des conteneurs, les développeurs ont rapidement réalisé 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 comme à 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 le calcul, le réseau et la sécurité et crée, une fois de plus, un autre déplacement de la frontière de la sécurité du réseau.

Qu'avons-nous donc appris en 15 ans ? Quel est le schéma commun à toutes ces évolutions ?

1. La frontière de la sécurité des réseaux se déplace de plus en plus vers la couche informatique, 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é arrivent tardivement et, dans le meilleur des cas, 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 de l'informatique en nuage.
3. La sécurisation des infrastructures est plus difficile lorsque les choses n'ont pas été pensées et conçues en tenant compte de la sécurité, et crée généralement un niveau de complexité supplémentaire lorsqu'elle est ajoutée ultérieurement.

Quel est le problème avec les conteneurs ?

Les conteneurs et les grappes de conteneurs ne font pas exception à cette tendance qui consiste à intégrer de plus en plus le réseau dans les couches logicielles et informatiques. Comme nous l'avons vu plus haut, cette situation dure depuis de nombreuses années et il n'y a aucune raison pour qu'elle change si les équipes chargées du réseau et de la sécurité n'inversent pas la tendance.

Du point de vue du réseau et de la sécurité, les conteneurs n'introduisent rien de nouveau ou d'inconnu, ils ne font que combiner ce que nous connaissons déjà (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, et c'est là un problème fondamental.

Les équipes informatiques aiment les limites, les responsabilités et la propriété, ce qui est à l'opposé du fonctionnement des grappes de conteneurs. Elles ont été conçues pour être autosuffisantes, orchestrées et opaques au monde extérieur. D'une part, le fait qu'un nouvel élément d'infrastructure ne nécessite pas de longues séances de conception pour être connecté et opérationnel est une excellente nouvelle. D'autre part, cela pose un réel problème 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 ?

Dans l'idéal, les développeurs devraient mettre au point le code et le confier à une autre équipe pour qu'elle le mette en production - d'une manière testée et automatisée, sur une infrastructure conçue pour l'échelle et la disponibilité, et avec la sécurité en tête des priorités à chaque couche de l'empilement.

Il semble que dans de nombreuses organisations, nous n'ayons pas encore atteint ce stade. Les équipes DevOps sont connectées à leurs pairs dans le domaine du développement, mais ce n'est pas toujours le cas pour les équipes réseau et sécurité, et cela doit changer si nous voulons que les conteneurs soient une technologie disruptive sur le marché.

Les équipes chargées des réseaux et de la sécurité devraient consacrer plus de temps à comprendre ce qui a été transporté et sécurisé par l'infrastructure. Ils doivent apprendre ce qu'est un pipeline CI/CD et avoir une opinion sur la façon dont les choses sont construites dans l'application afin d'adapter les mécanismes de sécurité pour compléter ce que l'application n'est pas en mesure de réaliser. Cela nécessite d'apprendre de nouvelles compétences, d'accepter les différences et d'être critique mais ouvert d'esprit face à de nouveaux concepts qui, à première vue, 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 secteurs d'un département informatique à apprendre les unes des autres.

Sinon, c'est la porte ouverte à tous les désastres. 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 occasion pour apprendre de nouvelles façons de faire, passer plus de temps à comprendre comment les choses peuvent être faites dans les logiciels, et s'approprier les couches réseau et sécurité en proposant des conceptions simples, sûres et stables pour servir la couche application.

Par où commencer ?

Il n'existe évidemment pas de solution miracle ou d'arme secrète qui pourrait constituer une réponse unique. 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 réseau et sécurité. Ils servent tous le même objectif : l'entreprise. Mais sans savoir ce que font les autres équipes, il est plus difficile de voir ce que l'on peut faire pour être meilleur en tant que groupe. La mise en place d'infrastructures complexes telles que les clusters de conteneurs nécessite des décisions interdépendantes pour réussir, en particulier en matière de sécurité.

Acquérir des connaissances : Personne ne sait tout, mais tout le monde peut apprendre quelque chose. Il est acceptable d'être léger dans certains domaines de votre infrastructure, mais il n'est absolument pas acceptable de ne pas vouloir apprendre comment les choses sont faites ou devraient être faites. Les conteneurs, les plateformes d'orchestration et les réseaux 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 il 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 : Gardez à l'esprit qu'un cluster de conteneurs est un ensemble d'adresses IP (associées à des conteneurs) qui communiquent entre elles. En outre, 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 d'ouverture de certaines portes au monde. Les ingénieurs réseau et sécurité sont responsables des flux allant d'un bout à l'autre d'une grappe, ainsi que de l'entrée et de la sortie des paquets de cette grappe. Si quelque chose est compromis dans un groupe de conteneurs, il incombe à l'équipe chargée de la sécurité du réseau de surveiller, de réagir et de répondre afin d'éviter la propagation d'une brèche. Certes, les grappes de conteneurs ont une approche différente en matière de réseau et de sécurité, mais il s'agit toujours d'un réseau qui doit être segmenté et sécurisé.  

Recherchez la vérité : il est important de comprendre et de remettre en question le statu quo. Lorsque les choses ne se passent pas comme vous l'aviez prévu, ce n'est pas grave. 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 réseaux de services gagnent beaucoup de terrain dans les organisations informatiques de nos jours et il est extrêmement important, en tant qu'ingénieur réseau et sécurité, que vous compreniez les concepts de ces technologies. Certains concepts vous sembleront très familiers, d'autres très étranges, mais pour sécuriser correctement les choses, vous devez savoir comment elles fonctionnent réellement !  

Consultez notre page sur les conteneurs pour plus d'informations sur la façon de tirer parti d'Illumio pour la segmentation des conteneurs.