Depuis quelques années, les attaques à la supply chain gagnent en fréquence et en ampleur. Derrière cette tendance se cachent des cybercriminels à la recherche de moyens furtifs d’apporter des modifications malveillantes ou d’injecter des malwares dans les logiciels avant leur déploiement. Pour ce faire, la compromission d’identifiants de développeurs ou de privilèges administratifs d’un outil de développement est souvent considérée comme une étape clé du cycle de l’attaque.
En effet, dès lors qu’un mot de passe ou une clé à hauts privilèges est dérobé, il devient facile de manipuler une bibliothèque logicielle ou de modifier des paramètres de registre d’images via des méthodes qui sont généralement extrêmement difficiles à détecter.
Le défi de la sécurisation des identités dans un pipeline DevOps
Les cybercriminels ciblent les développeurs pour deux raisons essentielles.
La première est l’exploitation des privilèges élevés dont les développeurs ont besoin pour accéder à un large éventail d’applications et de plateformes au sein de l’entreprise étendue. Les développeurs bénéficient en effet de bien plus de privilèges que les autres utilisateurs car les entreprises modernes misent sur eux pour rester compétitives. Or, plus le développeur doit endosser la responsabilité de bout en bout du cycle de vie des applications, plus il est susceptible de disposer d’un contrôle accru sur les environnements IT.
La seconde raison réside dans l’opportunité offerte de découvrir autant de secrets applicatifs que possible au sein du code, des variables d’environnement ou de tout autre emplacement non sécurisé. Ainsi, lors de la compromission de Codecov en avril 2021, les cybercriminels ont eu accès à un identifiant à la suite d’une faille dans le processus de création d’images Docker de l’entreprise. Ils ont utilisé cet identifiant pour modifier le script Bash Uploader de Codecov puis récupérer les identifiants et les secrets exposés provenant de nombreux environnements CI/CD de clients.
La difficulté consiste donc à trouver un moyen de garantir la création et le déploiement d’applications en toute sécurité sans ralentir le processus de développement. La sécurité doit ainsi faire partie du processus global d’assurance qualité déjà en place, afin de constituer une base sur laquelle les développeurs peuvent s’appuyer pour faciliter leur quotidien.
Fort heureusement, à mesure que les organisations adhèrent aux meilleures pratiques DevSecOps, elles prennent conscience de la vulnérabilité des chaînes logistiques logicielles et de ce qui peut être fait pour intégrer une sécurité transparente. Néanmoins, les organisations ne peuvent pas attendre que les développeurs maîtrisent eux-mêmes toutes les nuances de la cybersécurité ou qu’ils tiennent dûment compte des pratiques de cyber-hygiène en vigueur.
Sécuriser les postes de travail et les outils des développeurs
Parfois, les développeurs ont besoin d’escalader les privilèges de leurs outils pour écrire et valider du code. De nombreuses organisations résolvent ce problème en leur accordant des droits d’administration locaux complets. Mais cette solution ne devrait jamais être retenue par défaut, et le principe du moindre privilège devrait être systématiquement appliqué.
Il est également important de se protéger contre le vol d’identifiants dans les navigateurs où des secrets applicatifs d’accès à des référentiels peuvent être stockés, ou encore dans les outils dotés d’interfaces en ligne de commande (CLI) où ces mêmes secrets peuvent être stockés dans des fichiers de configuration.
La clé de cette approche consiste à tirer parti de solutions qui ne reposent pas sur des politiques obsolètes de listes d’applications autorisées ou interdites, mais qui fournissent des contrôles proactifs et prédictifs.
Sécuriser l’automatisation
Un autre vecteur de menace concerne les technologies d’automatisation que les développeurs utilisent désormais couramment pour coder l’infrastructure, ainsi que les nombreux outils de développement utilisés sur l’ensemble du pipeline.
Il est en effet tout aussi important de gérer et de mettre en rotation les secrets utilisés par ces outils et plateformes, ainsi que de veiller à ce que les applications et les processus s’authentifient de manière sécurisée pour récupérer les secrets gérés.
De nombreux outils et services proposés par les fournisseurs de cloud et les plateformes de gestion de conteneurs intègrent des fonctions de gestion des secrets. Cependant, chaque fournisseur propose une approche de sécurité différente – offrant un niveau de maturité et d’expérience variable et utilisant des interfaces différentes – établissant de fait son propre « îlot de sécurité ». Le recours à ces capacités natives de gestion des secrets est certes préférable à une absence totale de sécurité ; mais disposer d’un référentiel centralisé permet d’identifier les lacunes des stratégies de sécurité et de favoriser les changements beaucoup plus rapidement qu’en assurant la liaison avec des outils et des fournisseurs disparates.
Déterminer qui a vraiment besoin d’accéder à quoi
L’étape suivante consiste à déterminer qui précisément dans les équipes de développement a besoin de valider du code source et d’élever des binaires dans le cadre d’un workflow DevOps. Tous les membres de ces équipes n’ont pas à disposer de droits d’administration complets sur tous les systèmes et outils qui composent le pipeline. Concrètement, les contrôles d’accès à privilèges juste-à-temps peuvent donner aux développeurs concernés la possibilité d’accéder à ce dont ils ont besoin, quand ils en ont besoin, en fonction de leur rôle. Lorsqu’il est nécessaire d’élever les privilèges, les équipes de cybersécurité doivent alors surveiller les ressources auxquelles l’accès est accordé et qui y a accès.
Sécuriser l’accès aux ressources et aux machines virtuelles de production
Les développeurs ne devraient pas avoir non plus un accès direct aux machines virtuelles dans les environnements de production. Le cas échéant, leurs sessions devraient être centralisées à l’aide d’un serveur de rebond ou d’une passerelle d’accès Web sécurisée, afin de limiter les risques. Ces exceptions devront faire l’objet d’un niveau d’approbation et d’examen plus élevé, et en aucun cas être permises de manière permanente. Il convient donc de mettre en place un processus strict d’approbation de l’affectation et de l’activation des politiques dans l’ensemble du workflow DevOps.
En outre, les stratégies de moindre privilège, ainsi que les processus d’isolation et de surveillance des sessions qui sont appliqués dans un environnement sur site, doivent être étendus au cloud ; en prévoyant notamment une évaluation continue de la manière dont les entités humaines et non humaines obtiennent des autorisations, ainsi que des possibilités accrues qu’offre le cloud.
Sécuriser l’accès des développeurs mais aussi l’accès au code et au pipeline de développement
La sécurisation du pipeline de développement, soit le cœur de la supply chain numérique, n’est finalement pas un processus ponctuel. Sa protection doit en effet évoluer continuellement et être traitée par phases hiérarchisées en fonction des risques. Les équipes chargées de la sécurité et de la gestion des identités et des accès (IAM) doivent donc constamment réévaluer les autorisations et partir du principe qu’il ne faut faire confiance à aucune identité – personne ou machine – dans le cadre d’une approche plus large de la sécurité fondée sur le Zero Trust. En parallèle, les secrets sont à sécuriser soigneusement ; grâce à un coffre-fort qui les chiffre et protège leur accès, constituant la dernière ligne de défense de toute chaîne logistique logicielle.
___________________
Par Ketty Cassamajor, Responsable Avant-Vente Europe du Sud chez CyberArk
puis