Autres considérations relatives à la sécurité pour Azure Pipelines

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

Lorsqu’il s’agit de sécuriser Azure Pipelines, il existe plusieurs autres considérations à prendre en compte, comme la protection de l’infrastructure partagée, des référentiels, des projets, etc.

Protéger l’infrastructure partagée

Les ressources protégées dans Azure Pipelines sont une abstraction de l’infrastructure réelle. Suivez ces recommandations pour protéger l’infrastructure sous-jacente.

Utiliser les pools hébergés par Microsoft

Les pools hébergés par Microsoft offrent une isolation et une machine virtuelle propre pour chaque exécution d’un pipeline. Si possible, utilisez des pools hébergés par Microsoft plutôt que des pools auto-hébergés.

Agents distincts pour chaque projet

Un agent ne peut être associé qu’à un seul pool. Vous pouvez partager des agents entre des projets en associant le pool à plusieurs projets. Dans la pratique, plusieurs projets peuvent utiliser le même agent consécutivement. Bien que rentable, cette approche peut présenter des risques de mouvement latéral.

Pour atténuer le mouvement latéral et empêcher la contamination croisée entre les projets, conservez des pools d’agents distincts, chacun dédié à un projet spécifique.

Utiliser des comptes à faible privilège pour exécuter des agents

Bien que vous soyez tenté, l’exécution de l’agent sous une identité avec un accès direct aux ressources Azure DevOps peut être risquée. Cette configuration est répandue dans les organisations utilisant l’ID Microsoft Entra, mais présente des risques. Si vous exécutez l’agent sous une identité sauvegardée par l’ID Microsoft Entra, il peut accéder directement aux API Azure DevOps sans compter sur le jeton d’accès du travail. Pour une meilleure sécurité, envisagez d’exécuter l’agent à l’aide d’un compte local non privilégié, tel que le service réseau.

Important

Dans Azure DevOps, il existe un groupe appelé Comptes de service de collecte de projets, ce qui peut être trompeur. Par héritage, les membres des comptes de service de regroupement de projets sont également considérés comme membres des administrateurs de regroupement de projets. Certains clients exécutent leurs agents de build à l’aide d’une identité sauvegardée par l’ID Microsoft Entra, et ces identités peuvent faire partie des comptes de service de collecte de projets. Toutefois, si des adversaires exécutent un pipeline sur l’un de ces agents de build, ils peuvent éventuellement contrôler l’ensemble de l’organisation Azure DevOps.

Il existe des instances où les agents auto-hébergés opèrent sous des comptes hautement privilégiés. Ces agents utilisent souvent ces comptes privilégiés pour accéder aux secrets ou aux environnements de production. Toutefois, si les adversaires exécutent un pipeline compromis sur l’un de ces agents de build, ils accèdent à ces secrets. Ensuite, les adversaires peuvent se déplacer par la suite via d’autres systèmes accessibles via ces comptes.

Pour améliorer la sécurité du système, nous vous recommandons d’utiliser le compte privilégié 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é. En outre, confiez à Azure Pipelines l’accès aux secrets et aux environnements.

Réduire l’étendue des connexions de service

Vérifiez que les connexions de service ont accès uniquement aux ressources nécessaires. Chaque fois que cela est possible, envisagez d’utiliser la fédération d’identité de charge de travail à la place 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.

Vérifiez que votre connexion de service Azure est limitée pour accéder uniquement aux ressources nécessaires. Évitez d’accorder des droits de contributeur étendus pour l’ensemble de l’abonnement Azure aux utilisateurs.

Lorsque vous créez une connexion de service Azure Resource Manager, choisissez toujours un groupe de ressources spécifique. Vérifiez que le groupe de ressources contient uniquement les machines virtuelles ou ressources nécessaires pour la build. De même, lorsque vous configurez l’application GitHub, accordez l’accès uniquement aux référentiels que vous envisagez de créer à l’aide d’Azure Pipelines.

Protéger les projets

Au-delà des ressources individuelles, il est essentiel d’envisager des groupes de ressources dans Azure DevOps. Les ressources sont organisées par des projets d’équipe et comprennent ce que votre pipeline peut accéder en fonction des paramètres du projet et de l’isolement est essentiel.

Chaque travail de votre pipeline reçoit un jeton d’accès avec les autorisations nécessaires pour lire les ressources ouvertes. Dans certains cas, les pipelines peuvent également mettre à jour ces ressources. Cela signifie que même si votre compte d’utilisateur n’a peut-être pas accès direct à une ressource, des scripts et des tâches spécifiques exécutés dans votre pipeline peut toujours y accéder. En outre, le modèle de sécurité d’Azure DevOps permet d’accéder à ces ressources à partir d’autres projets au sein de l’organisation. Si vous décidez de restreindre l’accès au pipeline à certaines ressources, cette décision s’applique à tous les pipelines au sein d’un projet. Les pipelines spécifiques ne peuvent pas être accordés de manière sélective à des ressources ouvertes.

Projets distincts

Compte tenu de la nature des ressources ouvertes, envisagez de gérer chaque produit et équipe dans des projets distincts. Ainsi, vous empêchez 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. Toutefois, lorsque plusieurs équipes ou produits partagent un projet, l’isolation granulaire de leurs ressources devient difficile.

Si votre organisation Azure DevOps a été créée avant août 2019, les exécutions peuvent toujours avoir accès aux ressources ouvertes dans tous les projets de votre organisation. Votre administrateur d’organisation doit passer en revue un paramètre de sécurité critique dans Azure Pipelines qui permet l’isolation du projet pour les pipelines.

Vous trouverez ce paramètre dans les paramètres de l’organisation Les paramètres>des pipelines>, ou directement : . https://dev.azure.com/Organization_Name/_settings/pipelinessettings

Protéger les référentiels

Dans les référentiels de contrôle de version, vous pouvez stocker le code source, le fichier YAML du pipeline et les scripts et outils nécessaires. Pour garantir des modifications sécurisées du code et du pipeline, il est essentiel d’appliquer 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.

En outre, passez en revue les paramètres de contrôle d’accès par défaut pour vos référentiels.

N’oubliez pas que la conception de Git signifie que la protection au niveau des branches présente des limitations. Les utilisateurs disposant de accès de poussée à un référentiel peuvent généralement créer de nouvelles branches. Si vous travaillez avec des projets open source GitHub, toute personne disposant d’un compte GitHub peut forkr votre dépôt et proposer des contributions. Étant donné que les pipelines sont associés à un référentiel (et non à des branches spécifiques), il est essentiel de traiter le code et les fichiers YAML comme potentiellement non approuvés.

Fourches

Lorsque vous travaillez avec des référentiels publics à partir de GitHub, il est essentiel de prendre soigneusement en compte votre approche des builds de fourche. Les duplications, provenant de l’extérieur de votre organisation, présentent des risques particuliers. Pour protéger vos produits contre le code potentiellement non approuvé, prenez en compte les recommandations suivantes

Remarque

Ces recommandations s’appliquent principalement à la création de dépôts publics à partir de GitHub.

Ne fournissez pas de secrets aux builds forks

Par défaut, vos 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é.

Remarque

Lorsque vous activez les builds de duplication pour accéder aux secrets, Azure Pipelines limite le jeton d’accès utilisé par défaut. Ce jeton a un accès limité aux ressources ouvertes par rapport à un jeton d’accès standard. Pour accorder aux builds du fork les mêmes autorisations que les builds régulières, activez les builds Make fork avec les mêmes autorisations que le paramètre de build standard.

Envisagez de déclencher manuellement les builds de duplication

Vous pouvez désactiver des builds de duplication (fork) automatiques et utiliser à la place des commentaires de demandes de tirage (pull request) comme moyen 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.

Utiliser des agents hébergés par Microsoft pour les builds de duplication

Évitez d’exécuter des builds à partir de duplications 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. Pour les agents auto-hébergés, implémentez l’isolation réseau et assurez-vous que les agents ne conservent pas leur état entre les travaux.

Passer en revue les modifications du code

Avant d’exécuter votre pipeline sur une demande de tirage dupliqué, examinez attentivement les modifications proposées et assurez-vous que vous êtes à l’aise pour l’exécuter.

La version du pipeline YAML que vous exécutez est celle de la demande de tirage. Par conséquent, prêtez une attention particulière aux modifications apportées au code YAML et au code qui s’exécute lorsque le pipeline s’exécute, comme les scripts de ligne de commande ou les tests unitaires.

Limitation de l’étendue des jetons GitHub

Lorsque vous générez une demande de tirage dupliqué 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 à intégrer dans GitHub. Si vous utilisez d’autres formes d’intégration GitHub, par exemple l’application OAuth, la restriction n’est pas appliquée.

Branches d’utilisateur

Les utilisateurs de votre organisation disposant des autorisations appropriées peuvent créer de nouvelles branches contenant du code nouveau ou mis à jour. Ce code peut s’exécuter via le même pipeline que vos branche protégée es. Si le fichier YAML dans la nouvelle branche est modifié, le yaML mis à jour est utilisé pour exécuter le pipeline. Bien que cette conception offre une grande flexibilité et le libre-service, toutes les modifications ne sont pas sécurisées (qu’elles soient effectuées de manière malveillante ou non).

Si votre pipeline consomme du code source ou est défini dans Azure Repos, vous devez comprendre entièrement le modèle d’autorisations Azure Repos. En particulier, un utilisateur disposant de l’autorisation Create Branch au niveau du référentiel peut introduire du code dans le référentiel, même si cet utilisateur n’a pas l’autorisation Contribuer .

Autres considérations relatives à la sécurité

Il existe la poignée suivante d’autres éléments à prendre en compte lors de la sécurisation des pipelines.

S’appuyer sur PATH

Il est dangereux de s’appuyer sur le paramètre de l’agent PATH. Il peut ne pas pointer là où vous pensez qu’il le fait, car il a été potentiellement modifié par un script ou un outil précédent. Pour les scripts et les fichiers binaires critiques de sécurité, utilisez toujours un chemin d’accès complet au programme.

Secrets de journal

Azure Pipelines tente de nettoyer les secrets des journaux dans la mesure du possible. Ce filtrage se fait du mieux possible, mais ne peut pas intercepter toutes les façons dont les secrets peuvent être divulgués. Évitez de renvoyer des secrets à la console, de les utiliser dans des paramètres de ligne de commande ou de les journaliser dans des fichiers.

Verrouiller les conteneurs

Les conteneurs ont un mappage de montages de volume fournis par le système dans les tâches, l’espace de travail et les composants externes requis pour communiquer avec l’agent hôte. Vous pouvez marquer tout ou partie de ces volumes en lecture seule.

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

En règle générale, la plupart des gens doivent définir les trois premiers répertoires en lecture seule et laisser work en lecture-écriture. Si vous n’écrivez pas dans le work répertoire dans un travail ou une étape spécifique, n’hésitez pas à effectuer work une lecture seule. Toutefois, si vos tâches de pipeline impliquent une auto-modification, vous devrez peut-être conserver tasks en lecture-écriture.

Contrôler les tâches disponibles

Vous pouvez désactiver 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. Vous pouvez également désactiver toutes les tâches in-the-box (à l’exception de l’extraction, qui est une action spéciale sur l’agent). Nous vous recommandons de ne pas désactiver les tâches prédéfinies dans la plupart des cas.

Les tâches installées directement avec tfx sont toujours disponibles. Une fois ces deux fonctionnalités activées, seules ces tâches sont disponibles.

Utiliser le service d’audit

De nombreux événements de pipeline sont enregistrés dans le service d’audit. Passez régulièrement en revue le journal d’audit pour vous assurer qu’aucune modification malveillante n’est passée. Rendez-vous sur https://dev.azure.com/ORG-NAME/_settings/audit pour commencer.

Étapes suivantes

Passer en revue la vue d’ensemble de la sécurité