Sécuriser vos dépôts et vos pipelines

8 minutes

Quand vous utilisez l’automatisation pour déployer votre infrastructure, votre pipeline et votre dépôt gagnent en puissance et en importance. Ils constituent en effet le seul moyen d’appliquer des modifications à vos environnements contrôlés.

De nombreuses parties de votre organisation Azure DevOps, du dépôt GitHub et des pipelines doivent être protégées. Le tableau suivant liste certains éléments importants à protéger et donne des exemples de vulnérabilités susceptibles de se produire si vous ne protégez pas ces éléments de manière adéquate.

Élément à protéger	Exemple de vulnérabilité
Organisation Azure DevOps ou dépôt GitHub, notamment les personnes qui y ont accès et ce qu’elles sont autorisées à faire.	Un ex-employé mécontent supprime votre dépôt de code.
Branches importantes de votre dépôt et ce qui doit se produire pour modifier le code sur ces branches.	Quelqu’un valide accidentellement du code Bicep non sécurisé dans la branche primaire de votre dépôt.
Code à l’intérieur de votre dépôt, y compris vos définitions d’infrastructure, tests et code d’application.	Quelqu’un oublie de tester le code qu’il a écrit, et il ne fonctionne pas correctement quand il est publié en production.
Définition du pipeline.	Quelqu’un ajoute par inadvertance une étape de pipeline qui écrit une chaîne de connexion de base de données dans le journal du pipeline.
Agents ou exécuteurs qui exécutent votre pipeline.	Un pipeline s’exécutant sur un brouillon de demande de tirage installe une vulnérabilité de sécurité sur l’agent, qui est ensuite utilisé pour un déploiement en production.
Tâches ou composants tiers pouvant s’exécuter dans votre pipeline.	Une tâche de pipeline tierce envoie les informations d’identification de votre principal de service à un site web malveillant.
Principaux de service que votre pipeline utilise pour accéder à Azure.	Un principal de service hors production modifie accidentellement votre environnement de production.
Secrets que votre pipeline utilise pour accéder à des systèmes externes.	Un membre de l’équipe écrit un nouveau fichier de définition de pipeline pour un prototype et le connecte accidentellement à votre environnement de production.

Découvrons maintenant quelques-unes des approches permettant d’appliquer la gouvernance et des contrôles autour de votre dépôt de code et de vos pipelines de déploiement, dans Azure DevOps et dans GitHub.

Gérer les utilisateurs et les autorisations

Réfléchissez à la façon dont vous allez accorder l’accès à votre organisation Azure DevOps ou à votre dépôt GitHub. Pensez aux personnes qui y ont accès et ce qu’elles peuvent faire.

Il est recommandé d’utiliser l’instance Microsoft Entra de votre organisation comme fournisseur d’identité de votre pipeline. Ainsi, chaque fois que quelqu’un rejoint ou quitte votre organisation, l’accès à votre pipeline est automatiquement accordé ou révoqué. Microsoft Entra ID vous permet également d’implémenter facilement des protections telles que l’accès conditionnel et l’authentification multifacteur.

Remarque

Pour utiliser l’intégration de Microsoft Entra à GitHub, votre organisation a besoin d’une licence GitHub Enterprise.

Vous pouvez également créer des équipes (dans GitHub) ou des groupes (dans Azure DevOps), qui représentent des ensembles d’utilisateurs auxquels des autorisations peuvent être accordées en même temps. De cette façon, vous n’avez pas besoin d’attribuer individuellement des autorisations. Vous pouvez facilement modifier les autorisations des utilisateurs en les ajoutant et en les supprimant d’une équipe ou d’un groupe.

Conseil

Azure DevOps utilise un modèle d’autorisation basé sur les privilèges minimums, qui est différent de celui utilisé par Azure. Dans Azure DevOps, les autorisations refuser remplacent les autorisations autoriser. Cela signifie que, si vous êtes affecté à plusieurs groupes avec différents ensembles d’autorisations, vous êtes uniquement autorisé à effectuer les actions permises par tous les groupes.

Veillez à comprendre comment les autorisations sont affectées, en particulier aux groupes.

Protéger les branches de code importantes

Vos pipelines et votre automatisation doivent être basés sur l’identification de branches de code spécifiques, comme la branche primaire. Le code sur ces branches désignées est généralement approuvé et autorisé à être déployé dans vos environnements de production. Appliquez des contrôles pour vérifier que le code se trouvant sur vos branches importantes a été vérifié et passé en revue.

Envisagez d’utiliser des règles de protection de branche (dans GitHub) ou des stratégies de branche (dans Azure Repos) pour empêcher les validations directes dans les branches de code importantes. Vous pouvez ensuite demander à votre équipe d’utiliser des demandes de tirage pour fusionner les modifications. Vous pouvez appliquer des contrôles automatisés et des processus de revue manuels pour vérifier la validité des modifications avant leur fusion.

Tester et passer en revue votre code

Vérifiez que votre équipe comprend vos attentes concernant la revue et le test de l’ensemble du code, y compris vos définitions d’infrastructure.

Vos définitions de pipeline étant des fichiers YAML, il s’agit donc d’une forme de code. Les modifications apportées à vos définitions de pipeline doivent être passées en revue et évaluées. Sinon, quelqu’un pourrait créer de manière accidentelle ou malveillante une étape de pipeline qui divulgue les informations d’identification de votre principal de service ou apporte une modification dangereuse à votre patrimoine Azure.

Toute modification apportée aux fichiers de définition de pipeline doit être soigneusement passée en revue. Assurez-vous que les membres de votre équipe comprennent que les pipelines ont des privilèges élevés et qu’ils nécessitent une attention particulière.

Protéger vos agents et exécuteurs de pipeline

Votre pipeline s’exécute sur des agents (pour Azure Pipelines) ou des exécuteurs (pour GitHub Actions). Vous pouvez considérer les agents et les exécuteurs comme des machines virtuelles. Votre définition de pipeline contrôle ces machines virtuelles en exécutant les tâches et les scripts que vous avez fournis.

Azure Pipelines et GitHub Actions fournissent tous deux des agents et des exécuteurs hébergés qui sont configurés et gérés par Microsoft ou GitHub. Le propriétaire de la plateforme configure les machines pour qu’elles soient conformes aux pratiques de sécurité recommandées. Les responsabilités du propriétaire de la plateforme incluent la mise à jour corrective des vulnérabilités du système d’exploitation.

Vous pouvez choisir d’utiliser à la place vos propres machines physiques ou virtuelles pour vos agents et exécuteurs. Les machines de ce type sont appelées « agents et exécuteurs auto-hébergés ». Si vous utilisez des agents et des exécuteurs auto-hébergés, il vous appartient de vérifier que les machines sont correctement configurées et protégées contre les menaces.

Les agents hébergés par Microsoft et les exécuteurs hébergés par GitHub sont éphémères. Toute modification de fichier ou de configuration apportée à un agent ou à un exécuteur est détruite à la fin de l’exécution d’un pipeline. Si vous auto-hébergez votre agent ou votre exécuteur, la même machine est susceptible d’être utilisée pour plusieurs pipelines ou environnements distincts, y compris les environnements de production et hors production. Supposons que quelqu’un crée une définition de pipeline qui modifie certains fichiers importants sur le système d’exploitation de l’agent et exécute le pipeline à partir d’une demande de tirage. La prochaine fois qu’un déploiement s’exécute sur votre environnement de production, il peut réutiliser l’agent. Désormais, vous n’avez aucun moyen de prédire l’impact du fichier endommagé sur votre environnement de production.

Pour ces raisons, il est recommandé d’utiliser des agents hébergés par Microsoft et des exécuteurs hébergés par GitHub chaque fois que vous le pouvez. Si vous devez utiliser des exécuteurs auto-hébergés, évaluez soigneusement les risques liés à leur configuration et à leur utilisation.

Évaluer les composants tiers qui s’exécutent dans votre pipeline

Si vous utilisez des extensions GitHub Actions ou Azure DevOps fournies par la communauté, renseignez-vous pour savoir qui les a créées et ce qu’elles font. Les composants de pipeline tiers peuvent avoir accès aux informations d’identification de votre principal de service et donc à l’ensemble de votre environnement dans Azure.

Dans Azure DevOps, l’administrateur de l’organisation approuve généralement chaque extension avant qu’elle puisse être utilisée. Si vous êtes l’administrateur de votre organisation, tenez compte du risque de sécurité associé à chaque composant que vous utilisez. Vous êtes responsable de vérifier qu’ils sont dignes de confiance et sans danger.

Chaque fois que vous utilisez une action ou une tâche tierce, vous spécifiez la version. Pensez à spécifier la version exacte que vous avez passée en revue. Le fait d’autoriser le pipeline à utiliser automatiquement une version ultérieure peut introduire un risque que vous n’avez pas envisagé.

Protéger les principaux de service de votre pipeline

Les pipelines utilisent des principaux de service pour accéder à Azure et à d’autres services. Il est important de protéger vos principaux de service et de s’assurer que leurs informations d’identification ne peuvent pas être utilisées de manière inappropriée. Envisagez d’appliquer plusieurs couches de protection.

Tout d’abord, vous pouvez protéger les informations d’identification de vos principaux de service :

Dans la mesure du possible, utilisez des identités managées ou des identités de charge de travail pour éviter de stocker entièrement les informations d’identification. Bien que vous ne puissiez pas utiliser des identités managées ou de charge de travail avec tous les pipelines, il est recommandé de le faire quand cela est possible.
Planifiez de manière régulière la modification ou la rotation des informations d’identification de votre principal de service. Par exemple, votre organisation peut définir une stratégie de rotation des informations d’identification tous les 90 ou 120 jours. Déterminez qui sera responsable de la rotation et comment vous mettrez à jour tous les emplacements où les informations d’identification sont utilisées.
Envisagez de désigner un opérateur de secrets dont le rôle est de gérer les secrets, les clés et les certificats afin qu’ils ne soient pas exposés à d’autres parties de l’organisation.

Réfléchissez ensuite aux autorisations que vous accordez aux principaux de service :

Appliquez des stratégies d’accès conditionnel Microsoft Entra aux principaux de service de votre pipeline. Ces stratégies permettent d’identifier les connexions et les comportements à risque. Par exemple, si vos principaux de service de pipeline se connectent toujours à partir d’une même région géographique, l’accès conditionnel peut détecter et empêcher les connexions provenant d’emplacements inattendus (ce qui peut indiquer que les informations d’identification ont été compromises).
Examinez attentivement les autorisations que vous accordez à chaque principal de service. Par exemple, supposons que vous avez un principal de service que vous utilisez pour lire la configuration d’une ressource partagée. Déterminez si vous pouvez accorder uniquement un accès Lecteur au principal de service, celui-ci n’ayant pas besoin d’effectuer des opérations nécessitant plus de privilèges.
Utilisez l’étendue minimale pour chaque autorisation que vous affectez à un principal de service. Par exemple, si votre principal de service doit effectuer un déploiement sur un seul groupe de ressources, définissez l’étendue de l’attribution du rôle à ce groupe de ressources plutôt qu’à l’abonnement entier.
Utilisez des principaux de service distincts pour chacun de vos environnements. De cette façon, même si les informations d’identification d’un principal sont compromises ou si quelqu’un obtient l’accès à un environnement, il ne peut pas accéder à d’autres environnements.

Protéger vos connexions de service et vos secrets

Une connexion de service (dans Azure Pipelines) ou un secret (dans GitHub) contient les informations d’identification du principal de service que le pipeline utilise pour accéder à votre environnement Azure. Il est important que vous protégiez vos connexions de service et vos secrets, et que vous contrôliez les pipelines qui utilisent chaque connexion de service et secret. Sinon, vous pouvez accidentellement autoriser un environnement hors production à utiliser un principal de service ayant accès aux ressources de production.

Dans Azure DevOps, quand vous créez une connexion de service, vous pouvez la configurer de manière à ce que tout nouveau pipeline ou environnement souhaitant l’utiliser soit soumis à votre approbation.

Azure DevOps vous permet également d’associer des vérifications à des connexions de service spécifiques. Les vérifications ajoutent une couche de protection supplémentaire. Par exemple, vous pouvez configurer une vérification sur une connexion de service de production pour vérifier qu’elle est uniquement utilisée sur le code de la branche primaire de votre dépôt. Cette vérification permet d’empêcher le déploiement de code non autorisé dans votre environnement de production.

Dans GitHub, vous pouvez configurer des secrets spécifiques à un environnement, de sorte que quand le flux de travail GitHub Actions travaille avec cet environnement, il fournit seulement la valeur des secrets. En utilisant des secrets spécifiques à un environnement et des contrôles d’environnement comme des approbations, vous pouvez réduire le risque qu’un déploiement hors production soit utilisé pour un déploiement dans votre environnement de production. Vous pouvez également utiliser des identités de charge de travail pour éviter d’utiliser des informations d’identification dans vos workflows GitHub Actions et éliminer le risque d’exposition de ces informations d’identification.

Utiliser les fonctionnalités de sécurité de GitHub

GitHub fournit des fonctionnalités de sécurité que nous vous conseillons d’évaluer et d’utiliser. Voici quelques fonctionnalités :

Dependabot : analyse les dépendances de votre code source à la recherche de vulnérabilités connues.
Analyse de secrets : identifie le texte dans votre dépôt qui ressemble à des clés ou à des informations d’identification. Le stockage des secrets dans un dépôt constitue une mauvaise pratique. Si vous êtes alerté de la présence d’un secret dans votre dépôt, vous devez présumer que la valeur du secret est compromise, puis révoquer ou modifier le secret.
Audit : permet de savoir qui a apporté des modifications à votre configuration GitHub.
Vue d’ensemble de la sécurité : consolide toutes vos alertes de sécurité dans les dépôts de votre organisation.

Utiliser les journaux d’audit Azure DevOps

Azure DevOps fournit des journaux d’audit pour vous aider à comprendre qui a apporté des modifications à vos pipelines, stratégies de branche, dépôts et autres ressources. Il est recommandé d’activer l’audit et de passer régulièrement en revue les journaux d’audit.

Protéger votre dépôt et votre pipeline

Nous avons abordé les contrôles importants que vous pouvez appliquer à votre dépôt et à votre pipeline. Examinons maintenant les contrôles que vous pouvez utiliser pour protéger chacun des éléments importants que nous avons listés précédemment dans cette unité :

Élément à protéger	Contrôles à appliquer
Organisation Azure DevOps ou dépôt GitHub, notamment les personnes qui y ont accès et ce qu’elles sont autorisées à faire.	Utilisez Microsoft Entra ID pour l’authentification. Utilisez des équipes et des groupes pour affecter des autorisations. Activez la journalisation d’audit et consultez régulièrement les journaux d’audit.
Branches importantes de votre dépôt et ce qui doit se produire pour modifier le code sur ces branches.	Appliquez des règles de protection de branche ou des stratégies de branche.
Code à l’intérieur de votre dépôt, y compris vos définitions d’infrastructure, tests et code d’application.	Exigez la revue du code. Ajoutez des tests automatisés ou manuels. Sur GitHub, utilisez Dependabot et l’analyse de secrets.
Définition du pipeline.	Exigez la revue du code.
Agents ou exécuteurs qui exécutent votre pipeline.	Sur Azure Pipelines, utilisez des agents hébergés par Microsoft. Sur GitHub Actions, utilisez des exécuteurs hébergés par GitHub.
Tâches ou composants tiers pouvant s’exécuter dans votre pipeline.	Passez en revue le risque de sécurité associé à toutes les extensions et tâches tierces.
Principaux de service que votre pipeline utilise pour accéder à Azure.	Utilisez des identités de charge de travail dans GitHub Actions. Pour Azure Pipelines, utilisez des principaux de service et procédez régulièrement à la rotation de leurs informations d’identification. Utilisez des principaux de service distincts pour chaque environnement. Appliquez des stratégies d’accès conditionnel.
Secrets que votre pipeline utilise pour accéder à des systèmes externes.	Sur Azure DevOps, utilisez des approbations et des contrôles sur les connexions de service. Sur GitHub, utilisez des identités de charge de travail et des secrets spécifiques à l’environnement.