Qu'est-ce que la sécurité des conteneurs ?

La sécurité des conteneurs consiste à protéger les applications conteneurisées et leur infrastructure tout au long de leur cycle de vie, du développement au déploiement et à l'exécution. Il englobe l'analyse des vulnérabilités, la gestion de la configuration, le contrÎle d'accÚs, la segmentation du réseau et la surveillance. La sécurité des conteneurs vise à maximiser les avantages intrinsÚques de l'isolation des applications tout en minimisant les risques liés au partage des ressources et à la surface d'attaque potentielle. En adhérant aux meilleures pratiques et en utilisant des outils de sécurité spécialisés, les organisations peuvent protéger leur environnement de conteneurs contre les accÚs non autorisés et les violations de données tout en restant en conformité avec les réglementations du secteur.

 

La sécurité des conteneurs expliquée

Les conteneurs nous permettent de tirer parti des architectures de microservices et d'opérer avec une plus grande rapidité et une plus grande portabilité. Les conteneurs présentent également des avantages intrinsÚques en matiÚre de sécurité. L'isolation de la charge de travail, l'abstraction des applications et la nature immuable des conteneurs sont en fait des facteurs déterminants pour leur adoption.

Kubernetes offre Ă©galement des fonctions de sĂ©curitĂ© intĂ©grĂ©es. Les administrateurs peuvent dĂ©finir des politiques de contrĂŽle d'accĂšs basĂ©es sur les rĂŽles (RBAC) afin de se prĂ©munir contre les accĂšs non autorisĂ©s aux ressources de la grappe. Ils peuvent configurer des politiques de sĂ©curitĂ© du pod et des politiques de rĂ©seau pour empĂȘcher certains types d'abus sur les pods et le rĂ©seau qui les relie. Les administrateurs peuvent imposer des quotas de ressources afin d'attĂ©nuer les perturbations causĂ©es par un attaquant qui compromet une partie d'un cluster. Avec des quotas de ressources en place, par exemple, un attaquant ne pourra pas exĂ©cuter une attaque par dĂ©ni de service en privant le reste de la grappe des ressources nĂ©cessaires Ă  son fonctionnement.

Mais comme vous l'avez peut-ĂȘtre devinĂ©, aucune technologie n'est Ă  l'abri des activitĂ©s malveillantes. La sĂ©curitĂ© des conteneurs, c'est-Ă -dire les technologies et les pratiques mises en Ɠuvre pour protĂ©ger non seulement vos applications, mais aussi votre environnement conteneurisĂ© - des hĂŽtes, des runtimes et des registres aux plateformes d'orchestration et aux systĂšmes sous-jacents - est vitale.

Vidéo : Détectez les vulnérabilités dans les images du conteneur et assurez la sécurité et la conformité tout au long du cycle de développement grùce à l'analyse des conteneurs.

Contexte

La sécurité des conteneurs reflÚte la nature changeante de l'architecture informatique. L'essor du cloud-native computing a fondamentalement modifié la façon dont nous créons des applications. L'évolution de la technologie exige que nous adaptions notre approche de la sécurisation.

Dans le passé, la cybersécurité consistait à protéger un seul périmÚtre. Les conteneurs rendent ce concept obsolÚte, ayant ajouté de multiples couches d'abstraction qui nécessitent des outils spécialisés pour interpréter, surveiller et protéger nos environnements conteneurisés.

L'Ă©cosystĂšme des conteneurs peut ĂȘtre difficile Ă  comprendre, Ă©tant donnĂ© la plĂ©thore d'outils et les problĂšmes uniques qu'ils rĂ©solvent par rapport aux plateformes traditionnelles. Dans le mĂȘme temps, l'adoption gĂ©nĂ©ralisĂ©e des technologies de conteneurs nous donne l'occasion d'opĂ©rer un virage Ă  gauche - en sĂ©curisant les conteneurs dĂšs les premiĂšres Ă©tapes du pipeline CI/CD jusqu'au dĂ©ploiement et Ă  l'exĂ©cution.

Mais avant de plonger dans les détails de la sécurité des conteneurs, il est nécessaire de comprendre les plateformes utilisées pour gérer les conteneurs. Nous nous concentrerons sur l'une des plateformes les plus importantes et les plus connues, Kubernetes.

Qu'est-ce que Kubernetes ?

Kubernetes est l'une des principales plateformes d'orchestration qui permet d'optimiser et de mettre en Ɠuvre une infrastructure basĂ©e sur des conteneurs. Plus prĂ©cisĂ©ment, il s'agit d'une plateforme open-source utilisĂ©e pour gĂ©rer des charges de travail conteneurisĂ©es en automatisant des processus tels que le dĂ©veloppement, le dĂ©ploiement et la gestion d'applications.

En tant que plateforme open-source largement adoptĂ©e, la sĂ©curisation de Kubernetes est cruciale pour les organisations qui dĂ©ploient des applications conteneurisĂ©es. Les organisations doivent mettre en place un environnement sĂ©curisĂ©, en particulier lorsqu'elles intĂšgrent du code source ouvert dans des applications tierces. Kubernetes, avec son Ă©cosystĂšme Ă©tendu et ses nombreuses intĂ©grations pour gĂ©rer les conteneurs, permet de crĂ©er des processus automatisĂ©s et systĂ©matiques qui intĂšgrent la sĂ©curitĂ© au cƓur de son pipeline de construction et de dĂ©ploiement. En tirant parti des fonctionnalitĂ©s natives de Kubernetes, telles que le RBAC, les politiques de sĂ©curitĂ© des conteneurs et les politiques de rĂ©seau, les organisations peuvent mettre en place et maintenir une posture de sĂ©curitĂ© solide avec une infrastructure d'orchestration de conteneurs rĂ©siliente.

Avantages des conteneurs

En clair, les conteneurs facilitent plus que jamais la création, le déploiement et la mise à l'échelle des applications Cloud Native. Pour les développeurs d'applications Cloud Native, les avantages les plus évidents des conteneurs sont les suivants :

  1. Éliminer les frottements: Les dĂ©veloppeurs Ă©vitent une grande partie des frictions liĂ©es au dĂ©placement du code d'application des tests Ă  la production, puisque le code d'application progiciel sous forme de conteneurs peut s'exĂ©cuter n'importe oĂč.
  2. Source unique de vérité pour le développement d'applications: Toutes les dépendances associées à l'application sont incluses dans le conteneur. L'application peut ainsi s'exécuter facilement et à l'identique sur des machines virtuelles, des serveurs bare metal et le cloud public.
  3. Des temps de construction plus rapides: La flexibilité et la portabilité des conteneurs permettent aux développeurs de réaliser des gains de productivité jusqu'alors inaccessibles.
  4. Confiance pour les dĂ©veloppeurs: Les dĂ©veloppeurs peuvent dĂ©ployer leurs applications en toute confiance, sachant que leur application ou leur plateforme fonctionnera de la mĂȘme maniĂšre sur tous les systĂšmes d'exploitation.
  5. Collaboration renforcée: Plusieurs équipes utilisant des conteneurs peuvent travailler sur des parties individuelles d'une appli ou d'un service sans perturber le code progiciel dans d'autres conteneurs.

Comme toute architecture informatique, les applications Cloud Native ont besoin de sĂ©curitĂ©. Les environnements de conteneurs s'accompagnent d'une sĂ©rie de dĂ©fis de cybersĂ©curitĂ© ciblant leurs images, conteneurs, hĂŽtes, runtimes, registres et plateformes d'orchestration - qui doivent tous ĂȘtre pris en compte.

 

Comprendre la surface d'attaque

Considérez le cadre tentaculaire et multicouche de Kubernetes. Chaque couche - du code et des conteneurs aux clusters et aux services cloud tiers - pose un ensemble distinct de défis en matiÚre de sécurité.

SĂ©curiser les dĂ©ploiements Kubernetes exige de sĂ©curiser l'infrastructure sous-jacente (nƓuds, Ă©quilibreurs de charge, etc.), les composants configurables et les applications qui s'exĂ©cutent dans le cluster - notamment en maintenant la posture des nƓuds sous-jacents et en contrĂŽlant l'accĂšs Ă  l'API et Ă  Kubelet. Il est Ă©galement important d'empĂȘcher les charges de travail malveillantes de s'exĂ©cuter dans le cluster et d'isoler la communication des charges de travail grĂące Ă  des contrĂŽles de rĂ©seaustricts.

Les moteurs d'exĂ©cution des conteneurs peuvent prĂ©senter des dĂ©fauts de codage qui permettent une escalade des privilĂšges Ă  l'intĂ©rieur d'un conteneur. Le serveur API de Kubernetes pourrait ĂȘtre mal configurĂ©, donnant aux attaquants la possibilitĂ© d'accĂ©der Ă  des ressources supposĂ©es ĂȘtre verrouillĂ©es. Des vulnĂ©rabilitĂ©s permettant des attaques par escalade de privilĂšges pourraient exister au sein d'une application conteneurisĂ©e ou des systĂšmes d'exploitation fonctionnant sur les nƓuds Kubernetes.

Anatomie de la surface d'attaque d'un conteneur

Figure 1 : Anatomie de la surface d'attaque d'un conteneur

Dans ce systÚme, un problÚme à une couche est amplifié lorsqu'une autre couche présente un problÚme de sécurité.

Et les conteneurs peuvent, bien sĂ»r, abriter des vulnĂ©rabilitĂ©s. Dans le mĂȘme temps, les conteneurs peuvent masquer la visibilitĂ©. Imaginez une seule image non sĂ©curisĂ©e instanciĂ©e de nombreuses fois en tant que conteneurs distincts en cours d'exĂ©cution. Ce qui n'Ă©tait qu'une simple fissure est dĂ©sormais un vaste rĂ©seau de fissures dans la forteresse.

L'impératif de maintenir la visibilité sur les opérations et la sécurité du systÚme alors que vous déployez de plus en plus de conteneurs devient de plus en plus difficile. Et il ne s'agit là que de maintenir la visibilité, l'un des innombrables objectifs.

La figure 1, avec des détails plus poussés décrits dans le tableau 1, offre un point de départ pour comprendre la surface d'attaque des applications conteneurisées.

Il est important de noter que la représentation est simplifiée. En réalité, les attaquants ont de nombreuses voies à explorer pour tenter d'exploiter les vulnérabilités des applications conteneurisées. Défendre cette pile de technologies n'est pas nécessairement plus difficile que de sécuriser d'autres environnements et technologies. La conteneurisation présente simplement des considérations de sécurité uniques que les organisations doivent prendre en compte pour une infrastructure sécurisée et résiliente.

Surface d'attaque Vecteur d'attaque Description Exemple
Via le rĂ©seau Trafic de rĂ©seaux malveillants Exploiter les vulnĂ©rabilitĂ©s ou les Configurations erronĂ©es du rĂ©seau pour accĂ©der Ă  l'environnement du conteneur. Recherche de ports ouverts et exploitation des Configurations erronĂ©es pour accĂ©der aux nƓuds de travail.
Configuration de l'hÎte SystÚme hÎte mal configuré Exploiter les Configurations erronées du systÚme d'exploitation hÎte pour accéder à l'environnement du conteneur. Découverte d'autorisations de fichiers non sécurisées permettant d'accéder à des fichiers sensibles, tels que les fichiers de configuration des conteneurs.
VulnĂ©rabilitĂ©s de l'hĂŽte VulnĂ©rabilitĂ©s de l'hĂŽte non corrigĂ©es Exploitation des vulnĂ©rabilitĂ©s du systĂšme d'exploitation hĂŽte pour accĂ©der Ă  l'environnement du conteneur. Identifier et exploiter les vulnĂ©rabilitĂ©s non corrigĂ©es du noyau pour obtenir les privilĂšges de la racine sur les nƓuds de travail.
VulnĂ©rabilitĂ©s des applications hĂŽtes VulnĂ©rabilitĂ©s non corrigĂ©es dans les applications hĂŽtes Exploitation des vulnĂ©rabilitĂ©s des applications hĂŽtes pour accĂ©der Ă  l'environnement du conteneur. Cibler les anciennes versions de Docker avec des vulnĂ©rabilitĂ©s pour obtenir des privilĂšges root sur les nƓuds de travail.
Vulnérabilités et erreurs d'orchestration des conteneurs Configurations erronées de l'orchestration des conteneurs Exploiter les Configurations erronées du systÚme d'orchestration de conteneurs pour accéder à l'environnement de conteneurs. Profiter des politiques de contrÎle d'accÚs non sécurisées dans les clusters Kubernetes pour accéder aux pods et aux services.
Images du conteneur compromises Un attaquant accÚde au processus de construction des images du conteneur Compromettre le processus de construction des images du conteneur pour injecter du code malveillant dans les images du conteneur. Exploitation de vulnérabilités dans les Pipelines CI/CD pour injecter du code malveillant pendant le processus de construction de l'image conteneur.
VulnĂ©rabilitĂ©s et erreurs de configuration des conteneurs VulnĂ©rabilitĂ©s des conteneurs non corrigĂ©es Exploiter les vulnĂ©rabilitĂ©s du conteneur lui-mĂȘme pour accĂ©der Ă  l'environnement du conteneur. Cibler des vulnĂ©rabilitĂ©s non corrigĂ©es dans des applications populaires fonctionnant dans des conteneurs afin d'obtenir un accĂšs.
Évasion de conteneurs L'attaquant obtient un accĂšs privilĂ©giĂ© au conteneur Sortir de l'isolement du conteneur et accĂ©der au systĂšme hĂŽte. L'exploitation de vulnĂ©rabilitĂ©s dans le runtime du conteneur ou l'abus de Configurations erronĂ©es du systĂšme hĂŽte pour obtenir des privilĂšges root sur le systĂšme hĂŽte.

Tableau 1 : Décomposer la surface d'attaque des conteneurs

Heureusement, chaque couche de la surface d'attaque peut ĂȘtre fortifiĂ©e grĂące Ă  des considĂ©rations de conception et de processus, ainsi qu'Ă  des options de sĂ©curitĂ© natives et tierces pour rĂ©duire le risque de charges de travail compromises. Vous aurez besoin d'une stratĂ©gie Ă  multiples facettes, mais notre objectif dans cette section du guide est de vous fournir exactement cela.

Figure 2: Container security spans the full software development lifecycle

Figure 2: Container security spans the full software development lifecycle

 

Comment sécuriser les conteneurs ?

Les utilisateurs de conteneurs doivent s'assurer qu'ils disposent d'une full-stack security conçue à cet effet pour répondre aux exigences de gestion des vulnérabilités, de conformité, de protection de l'exécution et de sécurité du réseau de leurs applications conteneurisées.

Sécurité du réseau des conteneurs

Les applications conteneurisĂ©es sont confrontĂ©es aux mĂȘmes risques que les apps en bare metal et en VM, comme le cryptojacking, les ransomwares et le BotNet C2. La sĂ©curitĂ© du rĂ©seau conteneurs restreint de maniĂšre proactive les communications indĂ©sirables et empĂȘche les menaces d'attaquer vos applications via une multitude de stratĂ©gies. Les composants clĂ©s de la sĂ©curitĂ© du rĂ©seau impliquent la microsegmentation, le contrĂŽle d'accĂšs, le cryptage et les politiques visant Ă  maintenir un environnement sĂ©curisĂ© et rĂ©silient. La surveillance constante, la journalisation et les audits rĂ©guliers permettent d'identifier et de rectifier les Ă©ventuelles failles de sĂ©curitĂ©, tout comme les correctifs apportĂ©s en temps voulu pour maintenir vos plateformes et votre infrastructure Ă  jour.

Alors que les outils de sĂ©curitĂ© de type shift-left offrent une protection en temps de dĂ©ploiement contre les vulnĂ©rabilitĂ©s connues, les containerized next-gen firewalls se prĂ©munissent contre les vulnĂ©rabilitĂ©s inconnues et non corrigĂ©es. En effectuant une inspection de la couche 7 en profondeur et en analysant tout le trafic autorisĂ©, ils identifient et empĂȘchent les logiciels malveillants de pĂ©nĂ©trer et de se propager au sein du cluster et bloquent les connexions sortantes malveillantes utilisĂ©es pour l'exfiltration de donnĂ©es et les attaques de commandement et de contrĂŽle (C2). La microsegmentation basĂ©e sur l'identitĂ© permet de restreindre la communication entre les applications aux niveaux 3 et 4.

Sécurité des conteneurs en cours d'exécution

La sécurité des conteneurs Cloud-native runtime security consiste à identifier les nouvelles vulnérabilités dans les conteneurs en cours d'exécution et à sécuriser l'application contre celles-ci. Les organisations qui utilisent des conteneurs doivent tirer parti de la protection de l'exécution renforcée pour établir les lignes de base comportementales sur lesquelles repose la détection des anomalies. La sécurité du temps d'exécution permet d'identifier et de bloquer les processus, les fichiers et les comportements de réseau malveillants qui s'écartent d'une ligne de base.

En utilisant une stratĂ©gie de dĂ©fense intĂ©grĂ©e pour prĂ©venir les attaques de couche 7, comme le Top 10 de l'OWASP, les organisations devraient mettre en Ɠuvre une protection de l'exĂ©cution avec la sĂ©curitĂ© des applications web et des API en plus de la sĂ©curitĂ© du rĂ©seau des conteneurs via des pare-feu nouvelle gĂ©nĂ©ration conteneurisĂ©s.

Sécurité des conteneurs

Intégrer la sécurité dans la phase de construction des conteneurs signifie se décaler à gauche au lieu de réagir au moment de l'exécution. La sécurité de la phase de construction doit se concentrer sur la suppression des vulnérabilités, des logiciels malveillants et du code non sécurisé. Les conteneurs étant constitués de bibliothÚques, de binaires et de code d'application, il est essentiel de sécuriser les registres de vos conteneurs.

La premiĂšre Ă©tape de la sĂ©curitĂ© des conteneurs consiste Ă  Ă©tablir un registre de conteneurs officiel pour votre organisation. Il ne fait aucun doute qu'un ou plusieurs registres existent dĂ©jĂ . C'est Ă  l'Ă©quipe de sĂ©curitĂ© qu'il incombe de les trouver et de veiller Ă  ce qu'elles soient correctement sĂ©curisĂ©es, ce qui implique la mise en place de normes et de protocoles de sĂ©curitĂ©. L'objectif principal des normes de sĂ©curitĂ© des conteneurs devrait ĂȘtre la crĂ©ation d'images de confiance. À cette fin, DevOps et les Ă©quipes de sĂ©curitĂ© doivent s'aligner sur des politiques qui, avant tout, empĂȘchent les conteneurs d'ĂȘtre dĂ©ployĂ©s Ă  partir de registres non fiables.

Les intrusions ou les vulnérabilités dans le registre constituent une ouverture facile pour compromettre les applications en cours d'exécution. La surveillance constante des registres pour détecter les changements de statut des vulnérabilités reste une exigence fondamentale en matiÚre de sécurité. Parmi les autres exigences, citons le verrouillage du serveur qui héberge le registre et l'utilisation de politiques d'accÚs sécurisées.

Sécurité des conteneurs

La sĂ©curitĂ© de l'orchestration de conteneurs est le processus qui consiste Ă  Ă©dicter des mesures de contrĂŽle d'accĂšs appropriĂ©es pour prĂ©venir les risques liĂ©s aux comptes surprivilĂ©giĂ©s, aux attaques sur le rĂ©seau et aux mouvements latĂ©raux indĂ©sirables. En tirant parti de la gestion des accĂšs aux identitĂ©s (IAM) et de l' accĂšs au niveau le moins privilĂ©giĂ©, oĂč l'activitĂ© de Docker et de Kubernetes est explicitement inscrite sur la liste blanche, les Ă©quipes de sĂ©curitĂ© et d'infrastructure peuvent s'assurer que les utilisateurs n'exĂ©cutent que des commandes basĂ©es sur les rĂŽles appropriĂ©s.

En outre, les organisations doivent protĂ©ger les communications entre pods, limiter les dĂ©gĂąts en empĂȘchant les attaquants de se dĂ©placer latĂ©ralement dans leur environnement et sĂ©curiser tous les services frontaux contre les attaques.

Sécurité du systÚme d'exploitation hÎte (OS)

La sĂ©curitĂ© de l'OS hĂŽte est la pratique qui consiste Ă  sĂ©curiser votre systĂšme d'exploitation (OS) contre une cyberattaque. À mesure que la technologie de dĂ©veloppement d'apps Cloud Native se dĂ©veloppe, il en va de mĂȘme pour la nĂ©cessitĂ© d'assurer la sĂ©curitĂ© de l'hĂŽte.

Le systĂšme d'exploitation qui hĂ©berge votre environnement de conteneurs est peut-ĂȘtre la couche la plus importante en matiĂšre de sĂ©curitĂ©. Une attaque qui compromet l'environnement hĂŽte peut permettre aux intrus d'accĂ©der Ă  toutes les autres zones de votre pile. C'est pourquoi les hĂŽtes doivent ĂȘtre analysĂ©s pour dĂ©tecter les vulnĂ©rabilitĂ©s, renforcĂ©s pour rĂ©pondre aux critĂšres du CIS et protĂ©gĂ©s contre les contrĂŽles d'accĂšs faibles (commandes Docker, commandes SSH, commandes sudo, etc.)

 

Solutions de sécurité des conteneurs

La sécurisation de votre environnement conteneurisé exige une approche à plusieurs niveaux pour faire face aux vulnérabilités et menaces potentielles. Ces derniÚres années, les solutions de sécurité des conteneurs sur lesquelles les organisations peuvent compter pour protéger leurs applications et infrastructures conteneurisées tout au long des étapes de développement, de déploiement et d'exécution ont gagné en sophistication et en capacités. Les outils de sécurité modernes minimisent efficacement les risques de brÚches et de fuites de données, en favorisant la conformité et en maintenant des environnements sécurisés tout en accélérant l'adoption de DevSecOps .

Surveillance des conteneurs

La possibilité de surveiller votre registre à la recherche de vulnérabilités est essentielle pour maintenir la sécurité des conteneurs. Parce que les développeurs arrachent et remplacent constamment les conteneurs, les outils de surveillance qui permettent aux équipes de sécurité d'appliquer des timbres de séries temporelles aux conteneurs sont essentiels lorsqu'ils tentent de déterminer ce qui s'est passé dans un environnement conteneurisé.

Parmi les outils populaires pour la surveillance des conteneurs, citons Prometheus, Grafana, Sumo Logic et Prisma Cloud. Prisma Cloud propose une détection des menaces et une analyse des anomalies au moment de l'exécution pour les applications cloud-natives et traditionnelles. Il s'appuie sur l'apprentissage automatique et l'analyse comportementale pour identifier les activités suspectes tout au long du cycle de vie des conteneurs, de la création à l'exécution.

Outils d'analyse des conteneurs

Les conteneurs doivent ĂȘtre constamment analysĂ©s pour dĂ©tecter les vulnĂ©rabilitĂ©s, Ă  la fois avant d'ĂȘtre dĂ©ployĂ©s dans un environnement de production et aprĂšs leur remplacement. Il est trop facile pour les dĂ©veloppeurs d'inclure par erreur une bibliothĂšque dans un conteneur dont les vulnĂ©rabilitĂ©s sont connues. Il est Ă©galement important de se rappeler que de nouvelles vulnĂ©rabilitĂ©s sont dĂ©couvertes presque quotidiennement. Cela signifie que ce qui peut sembler ĂȘtre une image du conteneur parfaitement sĂ»re aujourd'hui pourrait devenir le vĂ©hicule par lequel toutes sortes de logiciels malveillants seront distribuĂ©s demain. C'est pourquoi le maintien de la confiance des images du conteneur est un Ă©lĂ©ment central des outils d'analyse des conteneurs.

Les outils d'analyse des conteneurs comprennent Aqua Security, Anchore, Clair et Prisma Cloud. Prisma Cloud fournit une analyse de vulnérabilité en couche profonde pour les images du conteneur dans les registres et pendant les pipelines CI/CD. Il détecte les vulnérabilités connues, les Configurations erronées et les logiciels malveillants, vous aidant ainsi à construire des conteneurs sécurisés dÚs le départ.

Outils de sécurité du réseau des conteneurs

Une fois dĂ©ployĂ©s, les conteneurs doivent ĂȘtre protĂ©gĂ©s contre les tentatives constantes de vol de donnĂ©es propriĂ©taires ou de ressources de calcul. Les pare-feu de nouvelle gĂ©nĂ©ration conteneurisĂ©s, la sĂ©curitĂ© des applications web et des API (WAAS)et les outils de microsegmentation inspectent et protĂšgent l'ensemble du trafic entrant et sortant des conteneurs (nord-sud et est-ouest), accordant une visibilitĂ© et un contrĂŽle complets de la couche 7 sur l'environnement Kubernetes. En outre, les pare-feu conteneurisĂ©s Ă©voluent dynamiquement en fonction de l'Ă©volution rapide de la taille et des demandes de l'infrastructure des conteneurs, garantissant ainsi la sĂ©curitĂ© et la bande passante pour les opĂ©rations commerciales.

Les outils de sĂ©curitĂ© rĂ©seau comprennent Calico, Flannel, les plugins CNI (par exemple, Istio, Cilium), Kubernetes NetworkPolicy et Prisma Cloud. Prisma Cloud s'intĂšgre aux plateformes d'orchestration de conteneurs comme Kubernetes pour assurer la dĂ©tection des menaces sur le rĂ©seau. Il sĂ©curise le trafic est-ouest entre les conteneurs et empĂȘche les mouvements latĂ©raux non autorisĂ©s au sein de votre environnement.

Moteurs politiques

Les outils modernes permettent aux équipes de sécurité du cloud de définir des politiques qui déterminent essentiellement qui et quoi est autorisé à accéder à un microservice donné. Les organisations ont besoin d'un cadre pour définir ces politiques et s'assurer qu'elles sont maintenues de maniÚre cohérente dans un environnement d'applications conteneurisées hautement distribué.

Parmi les moteurs de politiques populaires, citons Cilium, OPA Gatekeeper, Neutrino, Kubernetes Network Policy API et Prisma Cloud. Prisma Cloud applique des politiques de sécurité à l'ensemble de vos déploiements de conteneurs, notamment le contrÎle d'accÚs au réseau, la limitation des ressources et la signature des images. Cela garantit une posture de sécurité cohérente et la conformité avec les normes de votre organisation.

Choisir les bonnes solutions

Lorsque vous choisissez une solution pour sĂ©curiser votre environnement conteneurisĂ©, tenez compte des besoins de votre organisation et des zones de risque. Avez-vous besoin d'une dĂ©tection avancĂ©e des menaces, d'une gestion de la vulnĂ©rabilitĂ© ou d'une application stricte des politiques ? Évaluer l'intĂ©gration avec vos outils et votre infrastructure existants. L'intĂ©gration transparente avec les pipelines de dĂ©veloppement, les plateformes d'orchestration et les systĂšmes SIEM change la donne.

N'oubliez pas qu'une sĂ©curitĂ© des conteneurs efficace va au-delĂ  des outils individuels. La mise en Ɠuvre d'une approche par couches avec une surveillance continue, une analyse proactive, des politiques solides et une sĂ©curitĂ© rĂ©seau fiable amĂ©liorera considĂ©rablement la rĂ©silience de votre environnement conteneurisĂ© face aux menaces.

 

FAQ sur la sécurité des conteneurs

Un moteur de politiques est un composant logiciel qui permet aux équipes DevSecOps de définir, gérer et appliquer des politiques régissant l'accÚs et l'utilisation des ressources, telles que les applications, les réseaux et les données. 

Les moteurs de politiques évaluent les demandes entrantes en fonction de rÚgles et de conditions prédéfinies et prennent des décisions basées sur ces politiques. Ils contribuent à assurer la conformité, à renforcer la sécurité et à maintenir le contrÎle des ressources. Dans le contexte des environnements conteneurisés, les moteurs de politique jouent un rÎle crucial dans le maintien cohérent des politiques d'accÚs et de sécurité dans les applications distribuées et les microservices, en aidant à gérer et à automatiser l'application des politiques dans des infrastructures complexes et dynamiques.

L'expression "Common Vulnerabilities and Exposures" (CVE) désigne un systÚme normalisé permettant d'identifier, de cataloguer et de partager des informations sur les vulnérabilités et les expositions connues du public en matiÚre de cybersécurité. Les entrées CVE se composent d'un identifiant unique, d'une description et d'une note de gravité. Ce systÚme, géré par la MITRE Corporation, vise à faciliter le suivi, la gestion et la communication des vulnérabilités entre différentes bases de données, outils et organisations. En fournissant une référence commune pour les vulnérabilités, CVE aide les professionnels de la sécurité, les chercheurs et les développeurs à mieux comprendre les risques potentiels, à prioriser les efforts de remédiation et à améliorer le niveau de sécurité global des logiciels et des systÚmes.

La matrice ATT&CK de MITRE est une base de connaissances complÚte et accessible dans le monde entier sur les tactiques et les techniques des cyberadversaires. Il est développé et mis à jour par MITRE, une organisation à but non lucratif qui gÚre des centres de recherche et de développement parrainés par le gouvernement américain. ATT&CK signifie Adversarial Tactics, Techniques, and Common Knowledge (tactiques, techniques et connaissances communes adverses).

La matrice sert de cadre pour comprendre, classer et documenter les différentes méthodes utilisées par les cyberadversaires pour compromettre les systÚmes, les réseaux et les applications. Il est conçu pour aider les équipes de sécurité, les chercheurs et les organisations à différentes étapes du cycle de vie de la cybersécurité, notamment la détection des menaces, la prévention, la réponse et l'atténuation.

La matrice ATT&CK de MITRE est organisée en un ensemble de catégories, appelées tactiques, représentant les différentes étapes du cycle de vie de l'attaque d'un adversaire. Chaque tactique contient plusieurs techniques que les adversaires utilisent pour atteindre leurs objectifs au cours de cette étape. Les techniques sont ensuite divisées en sous-techniques, qui fournissent des informations plus détaillées sur des méthodes et des outils spécifiques utilisés dans les cyberattaques.

Un contexte de sécurité est un ensemble d'attributs ou de propriétés liés aux paramÚtres de sécurité d'un processus, d'un utilisateur ou d'un objet au sein d'un systÚme informatique. Dans le cadre des environnements conteneurisés, un contexte de sécurité définit les paramÚtres de sécurité et de contrÎle d'accÚs pour les conteneurs et les pods, tels que les autorisations des utilisateurs et des groupes, l'accÚs au systÚme de fichiers, les niveaux de privilÚge et d'autres configurations liées à la sécurité.

Kubernetes vous permet de définir des contextes de sécurité au niveau du pod ou du conteneur. En configurant les contextes de sécurité, vous pouvez contrÎler les paramÚtres de sécurité et les restrictions pour vos applications conteneurisées, en veillant à ce qu'elles s'exécutent avec les autorisations appropriées et de maniÚre sécurisée.

Voici quelques-uns des attributs clĂ©s qui peuvent ĂȘtre dĂ©finis dans un contexte de sĂ©curitĂ© :

  • User ID (UID) et group ID (GID): Ces paramĂštres dĂ©terminent l'utilisateur et le groupe sous lesquels un conteneur ou un module fonctionnera, contrĂŽlant ainsi l'accĂšs aux ressources et aux capacitĂ©s du systĂšme.
  • ContrĂŽle de l'escalade des privilĂšges: Ce paramĂštre dĂ©termine si un processus au sein d'un conteneur peut obtenir des privilĂšges supplĂ©mentaires, tels que l'exĂ©cution en tant qu'utilisateur root. En dĂ©sactivant l'escalade des privilĂšges, vous pouvez limiter l'impact potentiel d'un conteneur compromis.
  • AccĂšs au systĂšme de fichiers: Les contextes de sĂ©curitĂ© vous permettent de dĂ©finir comment les conteneurs peuvent accĂ©der au systĂšme de fichiers, notamment en lecture seule ou en montant des volumes avec des autorisations spĂ©cifiques.
  • CapacitĂ©s Linux: Ces paramĂštres contrĂŽlent les capacitĂ©s spĂ©cifiques qu'un conteneur peut utiliser, telles que les liaisons rĂ©seau, les paramĂštres temporels du systĂšme ou les tĂąches d'administration.
  • Contexte SELinux: Les contextes de sĂ©curitĂ© peuvent ĂȘtre utilisĂ©s pour dĂ©finir le contexte SELinux d'un conteneur ou d'un pod, en appliquant des politiques de contrĂŽle d'accĂšs obligatoires et en isolant davantage le conteneur du systĂšme hĂŽte.

En configurant correctement les contextes de sécurité dans Kubernetes, vous pouvez renforcer la sécurité de vos applications conteneurisées, appliquer le principe du moindre privilÚge et protéger votre systÚme global contre les risques de sécurité potentiels.

La sĂ©curitĂ© du code fait rĂ©fĂ©rence aux pratiques et processus mis en Ɠuvre pour garantir que le code du logiciel est Ă©crit et maintenu en toute sĂ©curitĂ©. Il s'agit notamment d'identifier et d'attĂ©nuer les vulnĂ©rabilitĂ©s potentielles et de suivre les meilleures pratiques de codage sĂ©curisĂ© pour prĂ©venir les risques de sĂ©curitĂ©. La sĂ©curitĂ© des codes englobe diffĂ©rents aspects, tels que :

  • Test statique de la sĂ©curitĂ© des applications (SAST): Analyse du code source, du bytecode ou du code binaire afin d'identifier les failles de sĂ©curitĂ© potentielles sans exĂ©cuter le code.
  • Test dynamique de la sĂ©curitĂ© des applications (DAST): Test d'applications en cours d'exĂ©cution afin d'identifier les failles de sĂ©curitĂ© en simulant des attaques et en analysant le comportement de l'application.
  • Analyse de la composition des logiciels: Analyse et surveillance des dĂ©pendances (bibliothĂšques, cadres, etc.) utilisĂ©es dans votre code afin d'identifier les vulnĂ©rabilitĂ©s connues et de s'assurer qu'elles sont Ă  jour.
  • Pratiques de codage sĂ©curisĂ©es: Suivre les lignes directrices et les meilleures pratiques (par exemple, OWASP Top Ten Project) pour Ă©crire un code sĂ©curisĂ© et Ă©viter d'introduire des vulnĂ©rabilitĂ©s.

Les politiques sont des rĂšgles et des directives de sĂ©curitĂ© spĂ©cifiques utilisĂ©es pour appliquer les exigences de sĂ©curitĂ© dans un environnement Kubernetes, tandis que l'IaC est une pratique plus large de gestion et d'approvisionnement des ressources d'infrastructure Ă  l'aide de code. Les deux peuvent ĂȘtre utilisĂ©s ensemble pour amĂ©liorer la sĂ©curitĂ©, la cohĂ©rence et l'automatisation au sein de votre environnement Kubernetes. 

Grùce à l'IaC, vous pouvez définir et gérer des configurations de sécurité telles que des stratégies de réseau, des rÚgles de pare-feu et des contrÎles d'accÚs dans le cadre de la définition de votre infrastructure. Par exemple, vous pouvez inclure des politiques de réseau Kubernetes, des configurations d'entrée et de sortie et des politiques de contrÎle d'accÚs basé sur les rÎles (RBAC) dans vos manifestes Kubernetes, qui sont ensuite gérés en tant qu'infrastructure as code.

Des outils comme Terraform, CloudFormation et les manifestes Kubernetes vous permettent de gérer les ressources d'infrastructure et les configurations de sécurité de maniÚre cohérente et automatisée. En intégrant des mesures de sécurité dans vos définitions d'IaC, vous pouvez améliorer la sécurité globale de votre environnement de conteneurs et de Kubernetes et garantir le respect des meilleures pratiques et des exigences de conformité.

Policy as code (PaC) implique l'encodage et la gestion des politiques d'infrastructure, de la conformité et des rÚgles de sécurité sous forme de code au sein d'un systÚme à version contrÎlée. Le PaC permet aux organisations d'automatiser l'application et l'audit de leurs politiques, garantissant ainsi que leur infrastructure est construite et maintenue selon les exigences requises. En intégrant ces politiques dans le processus "policy as code" ou dans le cadre de la construction de l'infrastructure, les organisations peuvent s'assurer que leur outillage s'aligne sur les normes et les meilleures pratiques nécessaires.

La disposition des alertes est une mĂ©thode permettant de spĂ©cifier votre prĂ©fĂ©rence quant au moment oĂč vous souhaitez qu'une alerte vous informe d'une anomalie. Les paramĂštres sont conservateurs, modĂ©rĂ©s et agressifs. Les prĂ©fĂ©rences sont basĂ©es sur la gravitĂ© des problĂšmes - faible, moyenne, Ă©levĂ©e. 

  • Le conservateur gĂ©nĂšre des alertes de gravitĂ© Ă©levĂ©e.
  • ModĂ©rĂ© gĂ©nĂšre des alertes de gravitĂ© Ă©levĂ©e et moyenne.
  • Agressif gĂ©nĂšre des alertes de gravitĂ© Ă©levĂ©e, moyenne et faible.
Grùce à la personnalisation des paramÚtres d'anomalie, vous pouvez contrÎler le critÚre selon lequel les alertes sont générées pour les politiques d'anomalie. Les utilisateurs peuvent modifier les paramÚtres d'anomalie pour changer le seuil d'entraßnement du modÚle, personnaliser la disposition des alertes et ajouter des listes de confiance d'anomalie pour supprimer les alertes provenant de ressources de confiance.
Les seuils de formation des modÚles d'anomalies se réfÚrent à une méthode permettant de définir différents seuils pour la formation des modÚles de détection d'anomalies pour l'UEBA et les anomalies du réseau. Vous pouvez définir le seuil du modÚle d'entraßnement sur faible, moyen ou élevé. Ces seuils sont utilisés pour déterminer le volume (par exemple, un minimum de 100 événements d'utilisateur) et la durée des données utilisées (par exemple, 30 jours) pour l'entraßnement des modÚles.
Une liste de confiance des anomalies est une méthode permettant de supprimer des ressources spécifiques pour lesquelles vous ne souhaitez pas générer d'alertes. Par exemple, si vous utilisez certaines adresses IP pour effectuer des tests de pénétration, vous pouvez les ajouter à une liste de confiance afin de supprimer leurs alertes.
L'événement d'audit fait référence à un ensemble de politiques basées sur RQL qui surveille les événements d'audit dans votre environnement afin de détecter d'éventuelles violations des politiques. Vous créez des politiques d'audit pour signaler les événements sensibles tels que les activités de root ou les changements de configuration qui peuvent potentiellement mettre votre environnement cloud en danger.
Les politiques d'anomalie du réseau sont des politiques d'anomalie qui surveillent constamment les journaux du réseau à la recherche de trafic réseau malveillant à l'aide de l'apprentissage automatique, ainsi que la mise en correspondance des IP avec AutoFocus. Les politiques d'anomalie du réseau peuvent détecter diverses menaces telles que les attaques de botnets, de ransomwares et de vers.
L'autorisation consiste Ă  accorder aux utilisateurs authentifiĂ©s l'accĂšs aux ressources ou aux fonctions du systĂšme sur la base de politiques prĂ©dĂ©finies. Dans Kubernetes, ce concept est connu sous le nom de contrĂŽle d'accĂšs basĂ© sur les rĂŽles (RBAC). Le systĂšme RBAC permet Ă  des groupes d'utilisateurs, tels que les dĂ©veloppeurs, d'interagir avec des ressources ou des fonctions spĂ©cifiques en fonction de leurs exigences professionnelles. La mise en Ɠuvre de politiques d'autorisation des utilisateurs solides et cohĂ©rentes permet de s'assurer que les utilisateurs ne disposent que des privilĂšges minimums nĂ©cessaires, ce qui rĂ©duit le risque d'accĂšs non autorisĂ© et d'escalade des privilĂšges.

Le stockage sécurisé des identités fait référence aux solutions et mécanismes conçus pour stocker en toute sécurité des informations sensibles, telles que des mots de passe, des clés cryptographiques, des jetons d'API et d'autres secrets, d'une maniÚre hautement protégée et chiffrée. Les coffres-forts secrets et les modules de sécurité matériels (HSM) sont deux exemples courants de stockage sécurisé des identités.

Les chambres fortes secrÚtes sont des systÚmes de stockage sécurisés basés sur des logiciels conçus pour gérer, stocker et protéger les données sensibles. Ils utilisent des mécanismes de cryptage et de contrÎle d'accÚs pour garantir que seuls les utilisateurs ou applications autorisés peuvent accéder aux secrets stockés. HashiCorp Vault, Azure Key Vault et AWS Secrets Manager sont des exemples de chambres fortes secrÚtes. 

Caractéristiques de la chambre forte secrÚte

  • Chiffrement au repos et en transit
  • ContrĂŽle d'accĂšs prĂ©cis
  • Enregistrement et suivi des audits
  • Rotation et versionnement des clĂ©s
  • IntĂ©gration avec les systĂšmes existants de gestion des identitĂ©s et des accĂšs (IAM)

Les modules de sécurité matériels (HSM) sont des dispositifs physiques dédiés, inviolables et hautement sécurisés qui protÚgent et gÚrent les clés cryptographiques, effectuent des opérations de cryptage et de décryptage et fournissent un environnement sécurisé pour l'exécution de fonctions cryptographiques sensibles. Les HSM sont conçus pour se protéger contre les attaques physiques et logiques, en garantissant l'intégrité et la confidentialité des clés stockées. Parmi les exemples de HSM, citons SafeNet Luna HSM, nCipher nShield et AWS CloudHSM.

Principales caractéristiques des HSM

  • Certification FIPS 140-2 de niveau 3 ou supĂ©rieur (norme du gouvernement amĂ©ricain pour les modules cryptographiques)
  • GĂ©nĂ©ration, stockage et gestion sĂ©curisĂ©s des clĂ©s
  • GĂ©nĂ©ration de nombres alĂ©atoires basĂ©e sur le matĂ©riel
  • DĂ©tection et protection contre les manipulations
  • Prise en charge d'une large gamme d'algorithmes cryptographiques

Les chambres fortes et les HSM visent tous deux à fournir une solution de stockage d'identité sécurisée, réduisant le risque d'accÚs non autorisé, de violation de données et d'autres incidents de sécurité. Le choix de l'un ou l'autre dépend de facteurs tels que les exigences de sécurité, le budget et les besoins d'intégration.

L'UEBA désigne un ensemble de politiques d'anomalies permettant d'identifier les activités déviantes des utilisateurs, telles qu'un utilisateur se connectant à partir d'un lieu inconnu, des tentatives de connexion successives à partir de lieux géographiques éloignés, et la création d'un nombre généralement élevé de ressources informatiques.