Sécuriser vos pipelines Azure

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Les pipelines offrent des fonctionnalités puissantes pour l’exécution de scripts et le déploiement de code dans des environnements de production, mais il est essentiel d’équilibrer cette puissance avec la sécurité. Vous ne souhaitez jamais qu’un pipeline devienne un canal pour du code malveillant. L’équilibrage de la sécurité avec la flexibilité et la puissance requises par les équipes de développement est essentiel.

Cet article fournit une vue d’ensemble des configurations liées à la sécurité nécessaires pour protéger vos pipelines contre les menaces et les vulnérabilités.

Conditions préalables

Restreindre l’accès aux connexions de projet, de référentiel et de service

Pour améliorer la sécurité, envisagez de séparer vos projets, d’utiliser des stratégies de branche et d’ajouter des mesures de sécurité supplémentaires pour les fourches. Réduisez l’étendue des connexions de service et utilisez les méthodes d’authentification les plus sécurisées.

• Projets distincts : gérez chaque produit et chaque équipe dans des projets distincts. Cela empêche les pipelines d’un produit d’accéder par inadvertance aux ressources ouvertes d’un autre produit, ce qui réduit l’exposition latérale.
• Utilisez des identités au niveau du projet : utilisez une identité de build basée sur un projet pour les pipelines au lieu d’une identité au niveau de la collection. Les identités au niveau du projet peuvent uniquement accéder aux ressources au sein de leur projet associé, ce qui réduit le risque d’accès non autorisé par des acteurs malveillants. Pour plus d’informations, consultez l’étendue des identités de build et de l’étendue d’autorisation du travail.
• Utilisez des stratégies de branche : pour garantir des modifications sécurisées du code et du pipeline, appliquez des autorisations et des stratégies de branche. En outre, envisagez d’ajouter des autorisations de pipeline et des vérifications aux référentiels.
• Ajoutez une sécurité supplémentaire pour les forks : lorsque vous travaillez avec des référentiels publics sur GitHub, envisagez soigneusement votre approche des builds de forks. Les duplications provenant de l'extérieur de votre organisation présentent des risques particuliers.
  • Ne fournissez pas de secrets aux builds de duplication : par défaut, les pipelines sont configurés pour générer des duplications, mais les secrets et les ressources protégées ne sont pas automatiquement exposés aux travaux de ces pipelines. Il est essentiel de ne pas désactiver cette protection pour maintenir la sécurité.
  • Envisagez de déclencher manuellement des builds de fork : désactivez les builds de fork automatiques et utilisez des commentaires de requête d'extraction pour générer manuellement ces contributions. Ce paramètre vous donne la possibilité de passer en revue le code avant de déclencher une build. Pour plus d’informations, consultez Désactiver les builds de duplication automatique.
  • Ne fournissez pas de secrets pour les builds de forks : par défaut, les secrets associés à votre pipeline ne sont pas disponibles pour les validations des demandes de tirage (pull requests) des forks. N’activez pas l’option Rendre les secrets disponibles pour les builds de forks. Pour obtenir des instructions sur la recherche et la vérification de ce paramètre, consultez Contributions depuis des forks.
  • Envisagez de déclencher manuellement des builds de fork : désactivez les builds de fork automatiques et utilisez des commentaires de requête d'extraction pour générer manuellement ces contributions. Ce paramètre vous donne la possibilité de passer en revue le code avant de déclencher une build. Pour obtenir des instructions sur la procédure à suivre, consultez Désactiver les builds de duplication automatique.
  • Utilisez les agents hébergés par Microsoft pour les builds de forks : évitez d’exécuter des builds à partir de forks sur des agents auto-hébergés. Cela peut permettre aux organisations externes d’exécuter du code externe sur des machines au sein de votre réseau d’entreprise. Dans la mesure du possible, utilisez des agents hébergés par Microsoft.
  • Utilisez l’application GitHub Azure Pipelines pour la limitation de l’étendue des jetons : lorsque vous générez une demande de tirage par duplication GitHub, Azure Pipelines garantit que le pipeline ne peut pas modifier le contenu du référentiel GitHub. Cette restriction s’applique uniquement si vous utilisez l’application GitHub Azure Pipelines pour l’intégrer à GitHub.

Connexions de service sécurisées

• Réduisez l’étendue des connexions de service : les connexions de service doivent uniquement avoir accès aux ressources nécessaires. Lorsque vous créez une connexion de service Azure Resource Manager, choisissez toujours un groupe de ressources spécifique. Assurez-vous que le groupe de ressources contient uniquement les machines virtuelles ou ressources nécessaires à la construction. Pour obtenir des instructions sur la configuration des connexions de service, consultez Utiliser une connexion de service Azure Resource Manager.
• Utilisez la fédération des identités de charge de travail pour l’authentification : dans la mesure du possible, utilisez la fédération d’identité de charge de travail au lieu d’un principal de service pour votre connexion de service Azure. La fédération des identités de charge de travail utilise Open ID Connect (OIDC), une technologie standard pour faciliter l’authentification entre Azure et Azure DevOps sans compter sur des secrets. Pour obtenir des instructions sur la procédure à suivre, consultez Créer une connexion de service avec la fédération des identités de charge de travail (automatique).
• Réduire l’accès aux applications GitHub : lorsque vous configurez l’application GitHub sur Azure DevOps, accordez l’accès uniquement aux référentiels que vous envisagez de générer à l’aide de pipelines.
• Restreindre les connexions de service à des branches spécifiques : utilisez une vérification de contrôle de branche pour limiter les branches qui peuvent utiliser votre connexion de service. La vérification du contrôle de branche garantit que les connexions de service s’exécutent uniquement sur les branches autorisées et que toutes les ressources de pipeline liées sont générées à partir de branches autorisées.

Utiliser des pipelines YAML au lieu de pipelines classiques

Pour renforcer la sécurité et réduire le risque de mauvaises configurations accidentelles, utilisez des pipelines YAML plutôt que des pipelines classiques. Cette précaution empêche une préoccupation de sécurité découlant des pipelines YAML et classiques partageant les mêmes ressources, telles que les connexions de service. Si votre organisation utilise des pipelines classiques, migrez les pipelines vers YAML.

• YAML offre les avantages de l’infrastructure en tant que code : traitez les pipelines YAML comme tout autre code, car les étapes et les dépendances sont définies dans le code. Il existe également une visibilité claire des configurations de pipeline et un risque réduit de configurations incorrectes accidentelles.
• Les pipelines YAML peuvent être combinés avec des mesures de sécurité améliorées : par le biais de révisions de code et de demandes de tirage, utilisez des stratégies de branche pour configurer un processus de révision pour les demandes de tirage afin d’empêcher les fusions incorrectes.
• Gestion de l’accès aux ressources : les propriétaires de ressources contrôlent si un pipeline YAML peut accéder à des ressources spécifiques. Cette fonctionnalité de sécurité empêche les attaques telles que le vol d’un autre dépôt. Utilisez approbations et vérifications pour fournir le contrôle d’accès pour chaque exécution du pipeline.
  • Vérification des branches protégées : si vous avez des processus de révision de code manuels pour des branches spécifiques, vous pouvez étendre cette protection aux pipelines. Une vérification de la branche protégée pour une ressource empêche les pipelines de s'exécuter automatiquement sur des branches non autorisées.
  • Vérification manuelle de l’approbation : utilisez une vérification d’approbation manuelle pour empêcher les demandes de pipeline d’utiliser une ressource protégée jusqu’à ce qu’elles soient approuvées manuellement par les utilisateurs ou groupes spécifiés.
  • Vérification des heures d’ouverture : utilisez cette vérification pour vous assurer qu’un déploiement de pipeline démarre dans une fenêtre de jour et d’heure spécifiée.
• Désactiver la création de pipelines classiques : désactiver indépendamment la création de pipelines de build et de mise en production classiques. Lorsque les deux sont désactivés, aucun pipeline de build classique, pipeline de mise en production classique, groupes de tâches ou groupes de déploiement ne peut être créé via l’interface utilisateur ou l’API REST. Pour plus d’informations, consultez Désactiver la création de pipelines classiques.

Agents sécurisés

Pour sécuriser les conteneurs, marquez les volumes en lecture seule, définissez des limites de ressources, utilisez des images approuvées, recherchez des vulnérabilités et appliquez des stratégies de sécurité.

• Utilisez les agents hébergés par Microsoft au lieu d’agents auto-hébergés : les agents hébergés par Microsoft offrent une isolation et une machine virtuelle propre pour chaque exécution d’un pipeline. Utilisez des agents hébergés par Microsoft au lieu d’agents auto-hébergés. Pour plus d’informations, consultez les agents hébergés par Microsoft.
• Agents distincts pour chaque projet : pour atténuer le mouvement latéral et empêcher la contamination croisée entre les projets, maintenir des pools d’agents distincts, chacun dédié à un projet spécifique.
• Utilisez des comptes à faible privilège pour exécuter des agents : pour améliorer la sécurité du système, utilisez le compte avec privilèges le plus bas pour exécuter des agents auto-hébergés. Par exemple, envisagez d’utiliser votre compte d’ordinateur ou une identité de service managé. N’exécutez pas d’agent sous une identité avec un accès direct aux ressources Azure DevOps.
• Isoler les artefacts de production et les pools d’agents sensibles : utilisez différents pools d’agents pour éviter les problèmes de sécurité.
  • Utilisez un pool d’agents distinct pour les artefacts de production : isolez les artefacts de production à l’aide d’un pool d’agents distinct, ce qui empêche les déploiements accidentels de branches hors production.
  • Segmenter des pools sensibles : Créez des pools distincts pour les charges de travail sensibles et non sensibles. Autorisez uniquement les informations d’identification dans les définitions de build associées au pool approprié.
• Configurez des pare-feu restrictifs pour les agents auto-hébergés : configurez des pare-feu aussi restrictifs que possible tout en permettant aux agents de fonctionner, d’équilibrer la sécurité et la facilité d’utilisation.
• Mettez régulièrement à jour les pools d’agents auto-hébergés : conservez vos agents auto-hébergés à jour avec des mises à jour régulières pour vous assurer que le code vulnérable n’est pas en cours d’exécution, ce qui réduit le risque d’exploitation.

Utiliser en toute sécurité des variables et des paramètres

Utilisez en toute sécurité des variables et des paramètres dans vos pipelines en suivant les meilleures pratiques pour définir des secrets. Les meilleures pratiques incluent la restriction de l’utilisation du secret, l’utilisation de variables de temps d’attente et l’activation de la validation des arguments de tâche shell pour protéger votre pipeline contre les menaces et les vulnérabilités.

• Restreindre l’accès aux secrets : empêchez l'apparition de secrets ou de clés dans les pipelines. Passez à des méthodes d’authentification sans secret telles que la fédération d’identité de charge de travail ou définissez des secrets dans l’interface utilisateur, un groupe de variables ou un groupe de variables source à partir d’Azure Key Vault.
• Activer la validation des paramètres du shell : lorsque la configuration Activer la validation des arguments de tâches du shell est activée, un contrôle supplémentaire est effectué pour les caractères tels que les points-virgules, les guillemets et les parenthèses. Activez la validation des paramètres d'arguments des tâches shell au niveau de l’organisation ou du projet sous Paramètres>Pipelines>Paramètres.
• Limiter les variables qui peuvent être définies au moment de la file d’attente : empêchez les utilisateurs de définir de nouvelles variables au moment de la file d’attente en activant les variables de limite de paramètre qui peuvent être définies au moment de la file d’attente dans les paramètresdes pipelines> desparamètres> de l’organisation.
• Utilisez des paramètres au lieu de variables : contrairement aux variables, un pipeline en cours d’exécution ne peut pas modifier les paramètres du pipeline. Les paramètres ont des types de données tels que number et string, et ils peuvent être limités à des sous-ensembles de valeurs spécifiques. Cette restriction est utile lorsqu’un aspect configurable par l’utilisateur du pipeline ne doit accepter que les valeurs d’une liste prédéfinie, ce qui garantit que le pipeline n’accepte pas de données arbitraires.
• Référencer des secrets à partir de modèles : au lieu d’inclure des scripts inline avec des paramètres de secret directement dans votre yaML de pipeline, utilisez des modèles pour extraire les informations sensibles du pipeline principal. Pour implémenter cette approche, créez un fichier YAML distinct pour votre script, puis stockez ce script dans un dépôt distinct et sécurisé. Vous pouvez ensuite référencer le modèle et passer une variable secrète dans votre YAML en tant que paramètre. La variable sécurisée doit provenir d’Azure Key Vault, d’un groupe de variables ou de l’interface utilisateur du pipeline. Pour plus d’informations, consultez Utiliser des modèles.
• Limitez les secrets avec les stratégies de branche et les autorisations des groupes de variables : vous pouvez utiliser une combinaison d’autorisations de groupes de variables, d’insertion de tâches conditionnelles et de stratégies de branche pour vous assurer que les secrets sont attachés à la main branche. Pour plus d’informations, consultez Protéger les secrets.
• Utilisez setvariable pour limiter la définition des variables : utilisez l’attribut settableVariables pour configurer quelles variables les auteurs de pipelines sont autorisés à définir dans un pipeline. Sans ce paramètre, les auteurs de pipeline peuvent déclarer de nouvelles variables illimitées avec la commande de setvariable journalisation. Lorsque vous spécifiez une liste with settableVariablesvide, tous les paramètres de variable ne sont pas autorisés. Pour plus d’informations, consultez l’attributsettableVariables dans le schéma YAML.

La meilleure méthode pour protéger un secret est de ne pas avoir de secret en premier lieu. Évitez d’utiliser des secrets si possible, ne les stockez jamais dans des fichiers YAML et assurez-vous qu’ils ne sont pas enregistrés ou imprimés pour maintenir la sécurité.

• Évitez d’utiliser des secrets si possible : vérifiez si votre pipeline peut utiliser une méthode différente de celle d’un secret pour effectuer une tâche telle qu’une connexion de service avec une fédération d’identité de charge de travail ou une identité managée. Les identités managées permettent à vos applications et services de s’authentifier auprès d’Azure sans nécessiter d’informations d’identification explicites. Pour plus d’informations, consultez Utiliser des principaux de service et des identités managées. Ne placez pas de secrets dans YAML : ne stockez jamais de valeurs sensibles en texte clair dans un fichier Azure Pipelines .yml .
• Ne journalisez pas ou imprimez des secrets : évitez de faire écho aux secrets dans la console, en les utilisant dans les paramètres de ligne de commande ou en les connectant à des fichiers. Azure Pipelines tente d'éliminer les secrets des journaux dans la mesure du possible, mais il est impossible de détecter toutes les fuites de secrets.
• N’utilisez pas de données structurées comme JSON comme secrets : créez des secrets individuels pour chaque valeur sensible. Cette approche garantit une meilleure précision de la rédaction et réduit le risque d’exposer involontairement des données sensibles.

Auditer et alterner les secrets

Pour sécuriser vos pipelines, procédez régulièrement à un audit de la gestion des secrets dans les tâches et les journaux, examinez et supprimez les secrets inutiles, et renouvelez les secrets pour minimiser les risques de sécurité.

• Auditer la gestion des secrets dans les tâches et les journaux : vérifie si les secrets ne sont pas envoyés aux hôtes ou imprimés dans les journaux. Vérifiez qu’il n’existe aucun secret dans les fichiers journaux, y compris les journaux d’erreurs.
• Passez en revue les secrets inscrits : vérifiez que les secrets de votre pipeline sont toujours nécessaires et supprimez les éléments qui ne sont plus nécessaires pour réduire l’encombrement et les risques de sécurité potentiels.
• Changer les secrets : Changer régulièrement les secrets pour réduire la durée pendant laquelle un secret compromis peut être exploité.

Empêcher l’exécution de code malveillant

Pour vous assurer que seul le code testé et nettoyé s’exécute via votre pipeline, passez régulièrement en revue vos pipelines pour connaître les problèmes courants.

• Analyse du code : échappement de caractères spéciaux dans les arguments pour éviter l’injection de commandes de l’interpréteur de commandes. Vous pouvez utiliser GitHub Advanced Security pour Azure DevOps pour automatiser l’analyse du code.
• Validez les entrées et utilisez des paramètres : validez les paramètres d’entrée et les arguments pour empêcher le comportement inattendu. Utilisez des requêtes paramétrables dans des scripts pour empêcher l’injection SQL. Les paramètres d’exécution permettent d’éviter les problèmes de sécurité liés aux variables, telles que l’injection d’arguments.
• N’utilisez pas PATH dans les scripts : l’utilisation du paramètre de PATH l’agent est dangereuse, car elle peut être modifiée par un script ou un outil précédent. Utilisez toujours un chemin d'accès entièrement qualifié à la place.
• Contrôler les tâches disponibles : désactivez la possibilité d’installer et d’exécuter des tâches à partir de la Place de marché, ce qui vous permet de mieux contrôler le code qui s’exécute dans un pipeline.

Sécuriser les conteneurs

Découvrez comment sécuriser les conteneurs par le biais des modifications de configuration, de l’analyse et des stratégies.

• Marquer les volumes en lecture seule : les conteneurs incluent des montages de volumes fournis par le système pour permettre l’exécution des tâches, outils et composants externes nécessaires pour travailler avec l’agent hôte. Définissez externals, taskset tools pour lire uniquement pour une sécurité ajoutée.
• Définir des limites de ressources spécifiques au conteneur : définissez des limites sur le processeur et la mémoire pour empêcher les conteneurs de consommer des ressources excessives, ce qui peut entraîner un déni de service ou des vulnérabilités de sécurité.
• Utiliser des images approuvées : utilisez des images officielles et vérifiées à partir de sources réputées telles qu’Azure Container Registry ou Docker Hub. Spécifiez toujours une version ou une balise spécifique pour maintenir la cohérence et la fiabilité, plutôt que de vous appuyer sur la balise latest. Mettez régulièrement à jour les images de base pour inclure les derniers correctifs de sécurité et les correctifs de bogues.
• Analysez les conteneurs pour détecter les vulnérabilités et appliquez la protection contre les menaces au moment de l’exécution : utilisez des outils tels que Microsoft Defender pour Cloud pour surveiller et détecter les risques de sécurité. En outre, Azure Container Registry offre une analyse des vulnérabilités intégrée pour vous assurer que les images conteneur sont sécurisées avant le déploiement. Vous pouvez également intégrer des outils d’analyse tiers via des extensions Azure DevOps pour des vérifications de sécurité ajoutées.
• Implémentez des stratégies de sécurité pour empêcher l’escalade des privilèges et garantir que les conteneurs s’exécutent avec le moins de privilèges nécessaires : Par exemple, Azure Kubernetes Service (AKS),le contrôle d’accès en fonction du rôle et l’admission de sécurité pod vous permettent d’appliquer des stratégies qui limitent les privilèges de conteneur, de garantir l’exécution non racine et de limiter l’accès aux ressources critiques.
• Utiliser des stratégies réseau : les stratégies réseau peuvent être utilisées pour restreindre la communication entre les conteneurs, ce qui garantit que seuls les conteneurs autorisés peuvent accéder aux ressources sensibles au sein de votre réseau. En outre, Azure Policy pour AKS peut être appliqué pour appliquer les meilleures pratiques de sécurité des conteneurs, telles que la garantie que seules les images conteneur approuvées sont déployées.

Utiliser des modèles pour appliquer les meilleures pratiques

Commencez par un modèle minimal et appliquez progressivement les extensions. Cette approche garantit que lorsque vous implémentez des pratiques de sécurité, vous disposez d’un point de départ centralisé qui couvre tous les pipelines.

• Utiliser des modèles d'extension : Les modèles d'extension définissent la structure externe et offrent des points spécifiques pour les personnalisations ciblées. L’utilisation de modèles étendus peut empêcher le code malveillant d’infiltrer un pipeline.
• Restreindre l’accès : limitez l’accès réseau en faisant en sorte que les opérations comme le téléchargement de paquets soient exécutées sur un conteneur plutôt que sur l’hôte. Lorsque les étapes s’exécutent dans un conteneur, vous empêchez un acteur incorrect de modifier la configuration de l’agent ou de laisser du code malveillant pour une exécution ultérieure.

Articles connexes

• Cycle de vie du développement de sécurité Microsoft
• Centre de gestion de la confidentialité Azure