Devops - Sécuriser l'accès à votre gestionnaire de version de codes

Je continue mon étude de la sécurisation de la supply chain. Nous allons voir dans ce billet quelques règles permettant de sécuriser l’accès à votre gestionnaire de versions de code.

Introduction

Dans le premier billet, on avait découvert le Framework SLSA. Parmi les sources de compromissions décrites, le premier est de permettre la soumission du code malveillant. Pour y arriver un attaquant doit pouvoir s’authentifier sur votre gestionnaire de version de code. Pour cela, il va exploiter la moindre des failles présentes. Mais attention, il peut cibler tous les outils intervenant dans vos pipelines CI/CD et qui utilisent un moyen d’identification pour se connecter à celui-ci.

Tous ces accès créent de la complexité qu’il faut correctement gérer pour empêcher l’accès à votre supply chain à des personnes malveillantes.

Quelques conseils et règles

Les accès au gestionnaire de versions de code

Voyons quelques conseils et règles pour configurer correctement votre gestionnaire de code. Ces conseils et règles peuvent être en générales activées unitairement.

Ne pas exposer publiquement son gestionnaire de versions de code ?

L’exposition d’un service sur Internet crée des défis du point de vue de la sécurité qui rendront obligatoire une grande partie des conseils qui vont suivre.

Dans sauf exception éviter d’exposer votre gestionnaire de code sur internet. Limiter l’accès au seul réseau de votre entreprise. Pour les accès externes, en télétravail par exemple, mettez en place un accès via un VPN.

Limiter l’accès à des adresses IP spécifiques

Par défaut, les utilisateurs autorisés peuvent accéder aux ressources de votre serveur à partir de n’importe quelle adresse IP. Vous pouvez restreindre l’accès en autorisant l’accès à une liste d’adresses IP clairement identifiées.

Désactiver l’auto-enregistrement

Limiter l’enregistrement automatique via un email à un domaine particulier n’est pas suffisant. Vous devez le désactiver pour éviter l’enrôlement de personnes malveillantes qui aurait réussi à accéder à un compte mail de manière frauduleuse. Le process de création de comptes doit être de votre fait.

Renforcer les méthodes d’authentification

En général, les méthodes d’authentification par défaut des serveurs de gestion de code se font avec un nom d’utilisateur et un mot de passe. Étant donné que le nom d’utilisateur est souvent public ou généré automatiquement à partir des nom et prénom, il est fortement recommandé de mettre en œuvre un système d’authentification plus sécurisé. En effet, une fois votre compte identifié par des attaquants, il ne restera à ceux-ci que trouver un moyen de récupérer le mot de passe.

Utiliser un gestionnaire d’identités externe

Même si votre gestionnaire de code permet de créer des comptes locaux, privilégier une authentification via un IdP externe (Identity Provider): OpenLDAP, , Zentyal, FreeIPA, Active Directory,…

Activer l’authentification à deux facteurs

Si vous n’utilisez pas de fournisseurs d’identité, il est important d’activer l’authentification à 2 facteurs. L’authentification à 2 facteurs (2FA) est une méthode de sécurité basée sur la gestion des identités et accès qui impose deux formes d’identification pour accéder aux ressources et données.

Gérer le départ de vos utilisateurs

Il est important de couper les accès à des personnes qui viennent de quitter votre organisation. Même si ces personnes ne sont pas malveillantes, leurs informations d’authentifications peuvent être récupérées à un moment donné et utilisé par des personnes qui seront bien moins bienveillantes.

Principe de moindre privilège

Le principe de moindre privilège est un principe qui stipule, selon l'ANSSI1, qu’une tâche ne doit bénéficier que de privilèges strictement nécessaires à l’exécution du code menant à bien ses fonctionnalités. En d’autres termes, une tâche ne devrait avoir la possibilité de mener à bien que les actions dont l’utilité fonctionnelle est avérée.

Ce principe suppose alors que chaque utilisateur ne doit posséder que les privilèges et ressources nécessaires à l’exécution de son travail, et rien de plus. Ainsi en cas de compromissions de compte, les dommages ne peuvent pas dépasser ce qui est autorisé par ses privilèges et aux ressources autorisés.

Par extension un administrateur doit toujours utiliser son compte utilisateur normal lorsqu’il n’a pas besoin de configurer une application.

Autre exemple, dans le cas où une application a besoin d’accéder en écriture sur des dépôts de code, limiter les accès aux seuls projets nécessaires avec des droits très restreints. On voit bien trop souvent des tokens ayant tous les droits sur tous les projets. Je vous laisse imaginer si ce genre de TOKEN venait à être divulgué.

Mettre en place un outil d’audits des comptes et des accès

Effectuez une analyse et une cartographie continues de tous les comptes sur l’ensemble des outils composant votre supply chain. Cette analyse doit vous permettre d’identifier et de supprimer les autorisations non nécessaires pour chacune des identités.

Les accès aux projets

Pour éviter de pourrir tous vos projets en cas de compromissions, il est important de limiter autant que possibles les accès aux seules personnes en ayant besoin.

De même, mettez en place une politique de gestion des comptes et des groupes

Protection de la branche principale

Si une personne arrive à s’introduire, il faut limiter la possibilité de soumettre du code dans la branche principale. Pour cela, il est conseillé de mettre en place une revue de code par deux acteurs.

Auditer les activités sur vos projets

Si votre gestionnaire de code possède un outil d’audit, examiner périodiquement tous les événements d’audit afin de vous assurer qu’il n’y a pas d’activités anormales ou suspectes.

Signer les commits

La signature des commits permet de vérifier l’identité de la personne qui les soumet.

Stockage des secrets

Les hackers apprécient toutes les informations d’identification donnant accès à des ressources sensibles, leur offrant ainsi des opportunités de déployer du code et des artefacts malveillants. Ces informations, que nous appellerons secrets peuvent être exposés de nombreuses façons dans le pipeline CI/CD.

Si elles sont présentes dans votre code, elles pourront être lues par toute personne ayant accès au référentiel. La meilleure des pratiques est d’utiliser des informations d’identifications temporaires au lieu de statiques. Attention aussi à ne pas les intégrer dans vos artefacts.

Pour les serveurs de gestion de versions de code auto-hébergés

Durcir la configuration des serveurs

Les configurations des serveurs par défaut peuvent être une source importante de risque. Les attaquants peuvent par exemple tirer de mauvaises configurations permettant de gagner des privilèges d’administrateur.

Vous pouvez utiliser des outils d’analyse de vulnérabilités et de vérification de la conformité de configuration. Ces process de vérification doivent être exécuté régulièrement. Parmi ces outils, je vous ai déjà parlé d'OpenScap.

Activer la journalisation des activités

Il est fortement conseillé d’activer et de configurer le système auditd. Pour rappel, cette suite génère des journaux d’événements de toutes les actions qui sont réalisées sur vos serveurs. Que ce soit des accès aux fichiers en passant par les processus exécutés par les administrateurs.

Mettre à jour régulièrement votre gestionnaire de code

Plus vous tardez de mettre à jour votre gestionnaire de code, plus vous vous exposez à des attaques. En effet, les hackers surveillent la moindre publication d’exploits pour tenter de s’introduire dans votre gestionnaire de code.

Plus loin

J’ai essayé d’être le plus exhaustif possible pour aider à protéger le premier maillon de votre supply chain. Si j’ai oublié quelque chose, faites-moi signe, je me ferais une obligation de l’ajouter !

Pour ceux qui utilisent GitLab, je prévois d’écrire un billet permettant de mettre en place toutes ces recommandations.

Un dernier petit rappel, les menaces ne sont pas forcément qu’externes.

Sources :

• OWASP Top 10 CI/CD Security Risks