Les pipeline CI/CD (intégration continue/livraison continue) sont au cœur des approches DevOps. Cette chaîne qui donne beaucoup d’agilité et permet d’innover en permanence soulève de nombreuses questions de sécurisation auxquelles les entreprises doivent apporter des réponses. La sécurité des pipelines CI/CD est un casse-tête mais il existe des bonnes pratiques et des outils pour vous guider et renforcer la résilience des chaînes DevOps.

En Janvier dernier, la plateforme DevOps CircleCI dévoilait avoir été victime d’une cyberattaque ayant compromis ses infrastructures. Tout est parti d’une attaque ciblée mi-décembre contre l’ordinateur portable d’un employé. Grâce à un logiciel malveillant, les cyberattaquants ont pu voler un cookie de session et dès lors contourner l’authentification MFA mise en place. Ils se sont alors servi de cet ordinateur comme passerelle pour accéder au SI de CircleCI et dérober des jetons de sécurité, des clés de chiffrement, des identifiants et même des données clients (qu’ils ont pu déchiffrer grâce aux clés dérobées). L’éditeur a rapidement réagi et révoqué les clés compromises.

A la lumière de cette attaque CircleCI, suggéraient fortement à tous ses clients :

– De faire immédiatement tourner tous les secrets stockés dans CircleCI.

– D’examiner les logs internes de leurs systèmes pour détecter tout accès non autorisé du 21 décembre 2022 au 4 janvier 2023, ou à la date à laquelle la rotation des secrets dans CircleCI a été faite.

L’équipe de CircleCI a également invalidé tous les jetons API du projet et a informé les utilisateurs qu’ils devaient être remplacés.

Cette annonce peut servir de point d’inflexion pour toute équipe s’appuyant sur une infrastructure CI/CD et être l’occasion de revoir la sécurité de son pipeline.

Bien que les mesures proposées par l’équipe de CircleCI soient solides, il s’agit de réactions à un événement. Mais les équipes DevOps peuvent aussi prendre certaines mesures pour devenir plus proactives.

Gestion des identités et contrôle d’accès en CI/CD

Un pipeline d’intégration continue/livraison continue (CI/CD) est un moyen de fournir des applications par le biais d’un processus automatisé cohérent. Les développeurs déposent leur code dans des référentiels tels que GitHub, GitLab, Azure DevOps ou BitBucket, ce qui lance les processus automatisés de construction de l’application, de test et enfin de déploiement du code en production. Si les pipelines CI/CD permettent aux équipes de travailler plus rapidement et avec moins de risques d’erreurs manuelles, ils présentent également une nouvelle surface d’attaque que les acteurs malveillants peuvent exploiter.

L’un des meilleurs moyens de s’assurer que les attaquants ne peuvent pas exploiter les pipelines de CD/CD est de verrouiller qui peut accéder à quels outils et ressources. Fondamentalement, si une personne ne se voit pas accorder explicitement des privilèges d’accès, elle ne doit pas être en mesure d’y accéder. Il peut s’agir de mots de passe, de clés d’accès et d’autres mécanismes de contrôle d’accès, qui doivent être mis en œuvre de manière aussi granulaire que possible.

S’il peut être pratique d’accorder un accès à tous les membres des équipes DevOps, aux développeurs et aux ingénieurs, c’est une très mauvaise idée, car cela augmente considérablement les chances qu’un seul compte ayant fait l’objet d’une violation permette aux attaquants d’accéder à tous les systèmes connexes.

Il est donc préférable d’appliquer l’authentification unique, SSO, ou d’utiliser des contrôles d’accès basés sur les rôles, RBAC, chaque fois que cela est possible. Ces contrôles peuvent aider à restreindre l’accès afin de n’accorder aux bonnes personnes que l’accès aux systèmes pertinents.

Sécuriser l’accès des non-humains

Après les aspects liés à l’accès humain, il est également essentiel de définir et de gérer correctement l’accès des services et outils tiers. Lorsque l’on déploie un élément du pipeline CI/CD, il faut savoir exactement quels systèmes et services enverront des requêtes et où iront les réponses. En d’autres mots, si un code malveillant se fraie un chemin dans le pipeline, il faut s’assurer qu’il ne peut pas téléphoner chez lui ou communiquer avec des utilisateurs non autorisés.

Lorsque l’on s’appuie sur des systèmes basés sur des conteneurs, il faut veiller à utiliser des authentificateurs pour vérifier l’identité de la machine. Un authentificateur vérifie les attributs d’un conteneur et n’accorde le niveau d’accès que s’il est approuvé.

Une dernière remarque sur l’accès non humain : il faut éliminer tout actif inutilisé dès que possible. Cela signifie détruire les conteneurs et les machines virtuelles lorsqu’ils ne sont plus nécessaires et bloquer l’accès aux outils tiers s’ils ne sont pas activement utilisés.

Ne pas dévoiler les secrets de votre pipeline CI/CD

L’une des premières choses que les attaquants recherchent dans tout système est un moyen d’obtenir un accès supplémentaire, à savoir des informations d’identification codées en dur, également appelées secrets. Bien qu’il puisse sembler évident que l’on ne doit pas stocker ses secrets en clair, cela se produit plus souvent qu’on ne le pense. Étant donné la complexité des pipelines CI/CD et la vitesse à laquelle ils évoluent, c’est souvent la solution la plus facile et la plus rapide à laquelle les développeurs se tournent lorsqu’ils sont pressés de respecter les délais. Il est également facile de négliger la façon dont les secrets sont présentés dans les journaux du pipeline, où ils peuvent apparaître s’ils ne sont pas correctement expurgés.

Heureusement, la plupart des fournisseurs de CI/CD proposent des solutions intégrées qui permettent de stocker les informations d’identification, puis de les appeler programmatiquement en cas de besoin. Alternativement, la plupart des solutions offrent des chemins pour intégrer des gestionnaires de clés comme Hashicorp Vault dans ses pipelines.

Une étape essentielle pour éloigner les informations d’identification en clair de ses pipelines consiste à mettre en œuvre la détection des secrets le plus tôt possible. Dans le meilleur des cas, les développeurs détectent les secrets codés en dur avant de les livrer, ce qu’ils peuvent faire sur leur machine locale avec des hooks de pré-commit ou un hook de pré-push, dans un hook de pré-réception ou dans un environnement CI.

Automatiser la rotation des secrets

Un autre élément important de la gestion des secrets est le contrôle de la durée de vie de chaque justificatif d’identité. Plus un secret reste valide longtemps, plus il est probable qu’il puisse être trouvé et utilisé par un attaquant. L’une des principales raisons de la longévité des informations d’identification est la difficulté à faire une rotation manuelle des clés et la crainte de perturber les systèmes de production. C’est là que la rotation automatique des clés prend tout son sens.

La plupart des fournisseurs de plates-formes comme AWS, Google Cloud et Azure DevOps proposent ou fournissent des moyens simples de programmer la rotation automatique des clés. Cette opération peut être exécutée manuellement ou selon un calendrier fixe. L’automatisation de la rotation des clés tranquilliser tout le monde en cas d’urgence, en permettant de tester le processus d’invalidation et de remplacement en dehors d’un incident.

Lorsque l’on automatise la création de secrets, il ne faut pas oublier d’adapter ces informations d’identification à leur tâche. Suivre toujours le principe du moindre privilège, en limitant l’accès aux seules données et systèmes nécessaires à la réalisation de la tâche à accomplir.

Surveillance active des comportements suspects

La recherche d’activités suspectes après un événement peut aider à identifier ce qui a mal tourné ou qui a accédé à quels systèmes pendant une attaque. Mais il n’est pas nécessaire d’attendre que quelque chose de grave se produise pour exploiter ses logs !

Lorsque la plupart des gens pensent à monitorer activement le CI/CD, c’est dans l’intention de surveiller la consommation ou la disponibilité des ressources. Cependant, il est possible de configurer des alertes en cas d’activité suspecte, comme l’ajout inattendu d’un rôle privilégié ou les tentatives de connexion à un service non autorisé.

Honeytokens pour la détection d’intrusion

Une autre façon de protéger ses pipelines CI/CD consiste à poser des pièges que les intrus peuvent déclencher dans votre environnement. Ces pièges sont communément appelés « honeytokens ». Les honeytokens sont des identifiants qui ressemblent à de vrais secrets mais qui ne sont valables pour aucun service. Lorsqu’ils sont utilisés, ils déclenchent une alerte et un rapport sur l’adresse de l’utilisateur.

Une façon de déployer systématiquement les honeytokens est de les intégrer dans les constructions automatisées de son environnement, en utilisant des outils comme Terraform et un projet open-source tel que ggcanary.
Les jetons Canary peuvent être créés et déployés dans les pipelines CI/CD, ainsi que dans les dépôts de code ou les systèmes de gestion de projet.

La sécurité CI/CD est une responsabilité partagée

L’une des principales attentes des utilisateurs vis-à-vis de leurs fournisseurs de services est qu’ils assurent la sécurité de leur plateforme. La réalité est que les attaquants malveillants continueront à pénétrer et à exploiter toutes les cibles, y compris les fournisseurs de CI/CD. En fin de compte, la sécurisation des pipelines est un effort conjoint de tous les acteurs impliqués, y compris l’équipe de l’entreprise.

 

Cet article ne présente que quelques-uns des moyens de sécuriser un pipeline CI/CD. Pour en savoir plus sur la sécurité CI/CD : Top 10 des risques de sécurité CI/CD de l’OWASP.
____________________________

Par Dwayne McDaniel – Security Advocate chez GitGuardian

 

À lire également :

Pipelines de CI : 5 risques à évaluer.

Développeurs, savez-vous garder un secret ?

Dropbox subit une violation de données due à une attaque par hameçonnage

Sécurité applicative : le nouveau segment de la détection de secrets.

La startup française GitGuardian lève 11 millions d’euros