Si vous débutez dans cette série, vous souhaiterez peut-être commencer par le début :
Notions de base sur la sécurité des conteneurs : Introduction
À l’ère du capital applicatif, le pipeline CI/CD est un élément essentiel sur lequel repose la vitesse et la sécurité des applications qu’il crée et fournit.
Il s’agit d’un système complexe d’outils, intégrés via des API et invoqués par des scripts ou des plugins qui représentent numériquement le processus que vous suivez pour créer et finalement livrer des applications conteneurisées. Cela signifie qu’il existe de multiples points à partir desquels un mauvais acteur pourrait compromettre le système. Même si cela peut paraître tiré par les cheveux, n’oubliez pas qu’un grand nombre d’organisations profitent aujourd’hui du cloud, ce qui implique nécessairement un accès à distance.
Cela signifie qu’il y a deux éléments liés à la sécurité du pipeline : premièrement, la sécurité du pipeline lui-même. Deuxièmement, la sécurité du pipeline.
1. L'authentification n'est pas facultative
Si vous utilisez des outils et des services dans le cadre de votre pipeline dans le cloud ou en tant que service hébergé, ils sont exposés aux attaques. Si vous autorisez l’accès des développeurs ou des opérations distants aux outils et services hébergés en interne, ils sont exposés aux attaques. Avant de rejeter cette inquiétude, n’oublions pas le nombre de violations survenues ces dernières années en raison de l’ouverture des systèmes à l’accès externe. La meilleure attitude à adopter en matière de sécurité des pipelines est que oui, ils sont accessibles aux mauvais acteurs.
Cela signifie que la première tâche à accomplir est de sécuriser l’accès. L’authentification forte n’est pas facultative. L'utilisation du contrôle d'accès est fortement recommandée pour affiner l'accès aux systèmes critiques. Même si vous pensez que les systèmes ne sont accessibles qu’en interne. Il existe d’autres systèmes sur votre réseau par lesquels des acteurs malveillants peuvent accéder.
Une fois que vous avez abordé l’authentification, la prochaine étape est l’autorisation. L'autorisation spécifie ce qu'un utilisateur authentifié peut faire dans le système. Il est important de distinguer les privilèges en fonction des rôles, car moins il y a d'informations d'identification avec accès aux composants critiques, mieux vous vous en sortirez.
Chaque composant du pipeline doit nécessiter une authentification et une autorisation. Cela signifie tout, depuis les référentiels jusqu'aux outils utilisés pour créer des applications et des conteneurs.
2. Sécurisation des composants du pipeline
Il n’est malheureusement pas rare d’entendre des rapports selon lesquels des attaquants ont découvert d’immenses trésors (identifiants et autres secrets) en analysant des référentiels publics. Voir le numéro un pour un rappel sur la nécessité d'exiger une authentification sur les référentiels.
La réalité des pipelines d’aujourd’hui est qu’ils constituent une chaîne intégrée d’outils, chacun d’entre eux devant nécessiter une authentification. De ce fait, les informations d’identification et les secrets (clés) finissent souvent par être stockés dans des scripts qui appellent les outils et services qui composent le pipeline. Il s’agit d’une très mauvaise chose™, en particulier lorsqu’elle est associée à de mauvaises pratiques d’authentification sur les référentiels où ces scripts peuvent être stockés.
Les informations d’identification sont des actifs essentiels qui doivent être protégés. Soyez conscient de l’endroit où ils se trouvent, où ils sont stockés et comment ils sont sécurisés. HashiCorp Vault est un outil utile pour gérer la « prolifération des secrets ». Vault stocke en toute sécurité les secrets dans un emplacement central.
3. Maintenir une nomenclature
Avant de pouvoir sécuriser un système – ou un composant du système – vous devez savoir qu’il existe. Il est important de maintenir une liste complète des matériaux pour vous assurer de savoir ce qui se trouve dans votre environnement. Plus précisément, vous devez vous assurer de savoir ce qui devrait figurer dans votre environnement – et inversement, ce qui ne devrait pas y figurer.
Un inventaire bien tenu peut aider à protéger contre les tentatives d’insertion de composants contaminés ou compromis dans le pipeline. La standardisation sur un seul conteneur de base ou au moins sur une poignée de conteneurs gérables peut considérablement améliorer votre capacité à détecter les problèmes potentiels. Les écarts devraient donc déclencher une alerte qui peut faire l’objet d’une enquête. Par exemple, comparer les hachages et, si disponibles, valider les signatures numériques des images de conteneurs est une étape importante. Si vous effectuez une extraction à partir d'un référentiel distant, il est possible qu'il ait été compromis.
Ce fut le cas lorsque DockerHub a subi une violation et a exposé les informations d’identification et les jetons de 190 000 de ses utilisateurs. En utilisant ces informations, les attaquants auraient pu compromettre des images qui leur auraient ensuite donné accès à d’autres systèmes.
Ne vous arrêtez pas aux images de conteneurs. N’oubliez pas que les composants d’application provenant de sources externes sont susceptibles d’être compromis. Un exemple concret est l' insertion d'un logiciel de crypto mining dans un flux d'événements de package NodeJS NPM .
La standardisation de l’inventaire maintenu des images et des composants rationalise également la correction des vulnérabilités lorsque – et non si – des vulnérabilités apparaissent. La mise à jour d’une seule couche de base du système d’exploitation est beaucoup plus facile à gérer que d’essayer de mettre à jour un ensemble disparate de conteneurs.
4. Analyser et corriger
Il existe une multitude de façons par lesquelles les environnements de conteneurs peuvent être compromis ou devenir vulnérables aux attaques. Le plus souvent, nous pensons aux vulnérabilités des logiciels dans une image de conteneur. Même si vous devez y prêter attention (analyser et mettre à jour/corriger), il existe également des problèmes liés à la configuration qui sont moins souvent détectés et traités. Bon nombre d’entre eux pourraient être évités grâce à une configuration adéquate. Votre pipeline doit inclure des outils capables de détecter les compromis ou d’alerter sur les configurations non sécurisées.
Aqua Security propose des outils qui peuvent aider à numériser et à évaluer les conteneurs et les configurations. Kube-bench et kube-hunter sont d'excellentes ressources pour identifier les erreurs de configuration courantes (mais critiques) dans les environnements Kubernetes.
Toutes les analyses du monde ne contribueront pas à empêcher une compromission ou une violation si vous n'agissez pas. L'état de la sécurité des conteneurs 2019 de Tripwire a révélé que près d'une organisation sur cinq (17 %) était consciente des vulnérabilités des images de conteneurs, mais les déployait quand même. Étant donné cela, il n’est probablement pas surprenant que l’enquête ait révélé que plus de la moitié (60 %) des organisations avaient connu un incident de sécurité lié aux conteneurs au cours des douze mois précédents.
Ce point ne peut être suffisamment souligné ni réitéré : si vous intégrez des analyses de sécurité dans votre pipeline (et vous devriez le faire), il est important de suivre les résultats. L’exécution d’une analyse ne contribue en rien à améliorer la sécurité si vous ne prenez pas de mesures correctives.
Nous le répétons : exécuter une analyse ne contribue en rien à améliorer la sécurité si vous ne prenez pas de mesures correctives.
La sécurité des pipelines est un problème à multiples facettes qui peut constituer un défi. Le pipeline doit être traité comme n'importe quel autre ensemble d'applications car, en fin de compte, c'est de cela qu'il s'agit, bien qu'il soit opérationnel. N’ignorez pas la sécurité du pipeline lorsque vous intégrez la sécurité dans le pipeline.
Lisez le prochain blog de la série :
Notions de base sur la sécurité des conteneurs : Orchestration