Les conteneurs ont révolutionné le processus de développement, agissant comme la pierre angulaire des initiatives DevOps. Mais les conteneurs présentent des risques de sécurité complexes qui ne sont pas toujours évidents.
Les organisations qui n’atténuent pas ces risques sont vulnérables aux attaques.
Comment les conteneurs ont contribué au développement agile ? Quels risques de sécurité les conteneurs apportent dans l’image ? Qu’est-ce que les organisations peuvent faire pour sécuriser les charges de travail conteneurisées, allant au-delà de DevOps pour atteindre DevSecOps ?
Pourquoi les conteneurs se sont-ils répandus si vite ?
Les conteneurs sont, à bien des égards, l’évolution de la virtualisation. L’objectif était d’accélérer le processus de développement, en créant une voie plus agile du développement aux tests et à la mise en œuvre : une méthode plus légère que l’utilisation de machines virtuelles complètes.
Au cœur de ce problème se trouve : la compatibilité des applications. Les applications nécessitent certaines versions de bibliothèques, ce qui pourrait entrer en conflit avec les exigences d’autres applications. Les conteneurs ont résolu ce problème et se sont bien reliés aux processus de développement et à l’infrastructure de gestion qui pilote ces processus.
Les conteneurs font leur travail en faisant passer la virtualisation au niveau supérieur.
La virtualisation fait abstraction de la couche matérielle, tandis que les conteneurs font abstraction de la couche du système d’exploitation, virtualisant essentiellement le rôle du système d’exploitation. La conteneurisation fonctionne en empaquetant les applications dans des « conteneurs » qui incluent toutes les bibliothèques nécessaires pour faire fonctionner une application, tout en gardant les applications ignorantes les unes des autres. Chaque application pense qu’elle a le système d’exploitation pour elle-même.
Fonctionnellement, les conteneurs sont assez simples :
- Un conteneur est juste un fichier texte avec une description décrivant les composants qui doivent être inclus dans une instance.
- Cette simplicité et la nature plus légère d’un conteneur facilitent l’utilisation des outils d’automatisation (orchestration) pour le déploiement tout au long du cycle de développement.
DevOps pour la victoire… mais la sécurité compte aussi !
Les conteneurs ont le pouvoir d’augmenter considérablement l’efficacité du développement – agissant comme les clés qui déverrouillent DevOps. C’est, probablement, l’une des principales raisons pour lesquelles les conteneurs se sont répandus si largement. Gartner estime que d’ici 2023 70 % des organisations exécuteront des charges de travail conteneurisées.
Le processus de développement, de test et de déploiement d’applications était auparavant rempli d’obstacles, avec un va-et-vient constant entre les développeurs et les équipes chargées de l’infrastructure. Aujourd’hui, grâce aux conteneurs, les développeurs peuvent créer et tester dans un environnement qui fonctionne et expédier simplement le code fini avec une spécification qui définit cet environnement.
Du côté opérationnel, les équipes se contentent d’exécuter cette spécification pour créer un environnement correspondant prêt à l’emploi. « Oui, mais ça marche sur ma machine… » n’a jamais aidé à résoudre le problème – mais aujourd’hui, c’est une expression que les développeurs n’ont plus besoin d’utiliser car il n’y a pas de problèmes environnementaux à déboguer.
Donc, oui, DevOps signifie développement rapide. Mais il manque un élément : la sécurité.
C’est pourquoi nous entendons de plus en plus parler de DevSecOps à mesure qu’il évolue à partir de DevOps, car les développeurs ont remarqué que le modèle DevOps seul ne répond pas suffisamment aux problèmes de sécurité.
Les conteneurs présentent plusieurs risques de sécurité
Les conteneurs simplifient le processus de développement, mais introduisent de la complexité dans l’image de la sécurité.
Lorsque vous emballez étroitement un environnement d’exploitation entier dans un conteneur uniquement pour le distribuer largement, vous augmentez également la surface d’attaque et ouvrez la porte à différents vecteurs d’attaque. Toutes les bibliothèques vulnérables fournies avec le conteneur propageront ces vulnérabilités sur d’innombrables charges de travail.
Il existe plusieurs risques :
- Une « attaque de la chaîne d’approvisionnement » où un acteur malveillant monte une attaque non pas en jouant avec votre application, mais en modifiant l’un des packages ou composants fournis avec votre application. Ainsi, les équipes chargées des efforts de développement doivent évaluer l’application qu’elles développent et chaque bibliothèque intégrée en tant que dépendance par la configuration du conteneur.
- Les risques pour la sécurité des conteneurs impliquent également les outils qui activent les conteneurs – des Dockers aux outils d’orchestration tels que Kubernetes, car ces outils doivent être surveillés et protégés. Vous ne devriez pas, par exemple, autoriser les administrateurs système à exécuter des conteneurs Docker en tant que root. De même, vous devez surveiller de près vos registres de conteneurs pour vous assurer qu’ils ne sont pas compromis.
La sécurité du noyau au cœur de la sécurité des conteneurs
Certains des risques de sécurité liés aux conteneurs sont moins visibles que d’autres. Chaque conteneur a besoin d’accéder à un noyau – après tout, les conteneurs ne sont qu’un type d’isolation de processus avancé. Mais il est facile de passer à côté du fait que tous les conteneurs reposent sur le même noyau – peu importe que les applications à l’intérieur des conteneurs soient séparées les unes des autres.
Une application dans un conteneur voit le même noyau dont dépend l’hôte pour s’exécuter. Cela pose quelques problèmes :
- Si le noyau hôte qui prend en charge le conteneur est vulnérable, la vulnérabilité pourrait être exploitée en lançant une attaque depuis l’application à l’intérieur du conteneur.
- Le fait que le noyau soit partagé par tous les conteneurs sur l’hôte signifie que les noyaux défectueux doivent être corrigés rapidement, sinon tous les conteneurs seront bientôt affectés par la vulnérabilité.
Encore une fois, il s’agit de bricoler…
La mise à jour du noyau hôte est une étape importante pour garantir des opérations de conteneur sûres et fiables.
Non seulement le noyau doit être corrigé, mais le correctif doit être appliqué à la bibliothèque tirée par le conteneur. Mais, comme nous le savons, appliquer des correctifs de manière cohérente est plus facile à dire qu’à faire. C’est probablement la raison pour laquelle une étude a révélé que 75 % des conteneurs scannés contenaient des vulnérabilités classées comme critiques ou à haut risque.
Par exemple : ces vulnérabilités pourraient conduire à des attaques d’évasion, dans lesquelles les attaquants s’appuient sur des bibliothèques défectueuses dans le conteneur pour exécuter du code en dehors du conteneur. En compromettant un conteneur, les attaquants peuvent potentiellement atteindre leur cible, que ce soit le système hôte ou une application dans un autre conteneur.
Dans le contexte des conteneurs, la maintenance d’une bibliothèque de sécurité peut être un véritable casse-tête :
- Quelqu’un doit suivre les nouvelles vulnérabilités ainsi que celles corrigées et non corrigées.
- Le processus est laborieux, mais il nécessite également des compétences spécialisées, que vous devriez acquérir si votre organisation ne les possède pas déjà.
Compte tenu de la valeur d’un correctif régulier et cohérent, ces raisons ne devraient pas être suffisantes pour conduire au type de routine de correctif aléatoire que nous voyons, mais – en particulier lorsque l’on considère le noyau du système d’exploitation – les pannes qui nécessitent des redémarrages et la nécessité de maintenir des fenêtres de temps d’arrêt peuvent retarder les réparations. Les correctifs de noyau en direct aident à atténuer ce problème, mais n’ont pas encore été déployés par toutes les organisations.
Toujours inclure des cibles de sécurité dans les opérations de conteneur
Il est courant que les technologies avancées introduisent de nouvelles complexités dans la sécurité de l’information.
De nouveaux outils mènent souvent à de nouveaux exploits. Il en va de même pour les conteneurs, et bien que cela n’affecte pas la valeur globale de l’utilisation de conteneurs dans vos charges de travail, cela signifie que vous devez porter une attention particulière aux risques que posent les conteneurs.
- La formation de vos développeurs et administrateurs système aux vulnérabilités de sécurité courantes des conteneurs et aux meilleures pratiques pour les atténuer est un début.
- Le patching est un autre aspect important.
- Prendre les mesures appropriées pour atténuer les failles de cybersécurité contribuera à protéger votre organisation et permettra à vos équipes de bénéficier de cette technologie de pointe sans souffrir de nuits blanches.