À propos de la sécurité, de l’authentification et de l’autorisation

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

Azure DevOps utilise de nombreux concepts de sécurité pour s’assurer que seuls les utilisateurs qui doivent avoir accès aux fonctionnalités, fonctions et données ont accès. Les comptes obtiennent l’accès à Azure DevOps via l’authentification de leurs informations d’identification de sécurité et l’autorisation de leurs droits de compte pour accéder à une fonctionnalité ou à une fonction.

Cet article s’appuie sur les informations fournies dans Prise en main des autorisations, des accès et des groupes de sécurité. Les administrateurs tirent parti de la compréhension des types de comptes, des méthodes d’authentification, des méthodes d’autorisation et des stratégies utilisées pour sécuriser Azure DevOps.

---

Types de comptes

• Utilisateurs
• Propriétaire de l'organisation
• Comptes de service
• Principaux de service ou identités managées
• Agents de travail

Authentification

• Informations d’identification de l’utilisateur
• Authentification Windows
• Authentification à deux facteurs (2FA)
• Authentification par clé SSH
• Jetons d'accès personnels
• Configuration Oauth
• Bibliothèque d’authentification Active Directory

Autorisation

• Appartenance au groupe de sécurité
• Contrôle d’accès en fonction du rôle
• Niveaux d'accès
• Indicateurs de fonctionnalités
• Espaces de noms de sécurité et autorisations

Stratégies

• URL de la politique de confidentialité
• Stratégies de sécurité et de connexion d’application
• Stratégies utilisateur
• Stratégies de dépôt et de branche Git

---

Important

Azure DevOps ne prend plus en charge l’authentification d’autres informations d’identification depuis le 2 mars 2020. Si vous utilisez toujours d’autres informations d’identification, nous vous encourageons vivement à passer à une méthode d’authentification plus sécurisée (par exemple, les jetons d’accès personnels). Plus d’informations

Notre service cloud, notre Azure DevOps Services et notre serveur local, Azure DevOps Server, prennent en charge les projets de développement de logiciels, de la planification au déploiement. Azure DevOps utilise l’infrastructure Platform as a Service de Microsoft Azure et de nombreux services Azure, y compris les bases de données Azure SQL, pour fournir un service fiable et disponible à l’échelle mondiale pour vos projets de développement.

Pour plus d’informations sur les étapes que Microsoft prend pour conserver vos projets en Azure DevOps Services sécurisés, disponibles, sécurisés et privés, consultez ce livre blanc, Azure DevOps Services Vue d’ensemble de la protection des données.

Comptes

Bien que les main types de comptes intéressants soient les comptes d’utilisateur humains que vous ajoutez à votre organization ou projet, Azure DevOps prend en charge d’autres types de comptes pour effectuer diverses opérations. Il s’agit notamment des types de comptes suivants.

• Propriétaire de l’organisation : créateur d’un Azure DevOps Services organization ou d’un propriétaire affecté. Pour savoir qui est le propriétaire d'organisation de votre organization, consultez Rechercher les propriétaire d'organisation.
• Comptes de service : comptes Azure DevOps internes utilisés pour prendre en charge un service spécifique, tel que le service de pool d’agents, PipelinesSDK. Pour obtenir une description des comptes de service, consultez Groupes de sécurité, comptes de service et autorisations.
• Principaux de service ou identités managées : applications Microsoft Entra ou identités managées qui ont été ajoutées à votre organisation pour effectuer des actions au nom d’une application tierce. Certains principaux de service font référence à des comptes Azure DevOps internes pour prendre en charge les opérations internes.
• Agents de travail : comptes internes utilisés pour exécuter des travaux spécifiques selon une planification régulière.
• Comptes tiers : comptes qui nécessitent un accès pour prendre en charge les web-hooks, les connexions de service ou d’autres applications tierces.

Dans ces documents, les utilisateurs peuvent faire référence à toutes les identités qui ont été ajoutées au hub d’utilisateurs, ce qui peut inclure des utilisateurs humains et des principaux de service.

Le moyen le plus efficace de gérer les comptes consiste à les ajouter à des groupes de sécurité.

Notes

Les propriétaire d'organisation et les membres du groupe Administrateurs de collection de projets bénéficient d’un accès complet à la plupart des fonctionnalités et fonctions.

Authentification

L’authentification vérifie une identité de compte en fonction des informations d’identification fournies lors de la connexion à Azure DevOps. Ces systèmes s’intègrent aux fonctionnalités de sécurité fournies par ces autres systèmes et s’appuient sur celles-ci :

• Microsoft Entra ID
• Compte Microsoft (MSA)
• Active Directory (AD)

Microsoft Entra ID et MSA prennent en charge l’authentification cloud. Nous vous recommandons d’utiliser Microsoft Entra ID lorsque vous devez gérer un grand groupe d’utilisateurs. Sinon, si vous avez une petite base d’utilisateurs qui accèdent à votre organization dans Azure DevOps, vous pouvez utiliser des comptes Microsoft. Pour plus d’informations, consultez À propos de l’accès à Azure DevOps avec l’ID Microsoft Entra.

Pour les déploiements locaux, AD est recommandé lors de la gestion d’un grand groupe d’utilisateurs. Pour plus d’informations, consultez Configurer des groupes à utiliser dans des déploiements locaux.

Méthodes d’authentification, intégration à d’autres services et applications

D’autres applications et services peuvent s’intégrer aux services et ressources dans Azure DevOps. Pour accéder à votre compte sans demander plusieurs fois les informations d’identification de l’utilisateur, les applications peuvent utiliser les méthodes d’authentification suivantes.

• Jetons d’accès personnels pour générer des jetons en votre nom pour :

  • Accéder à des ressources ou activités spécifiques, telles que des builds ou des éléments de travail
  • Les clients tels que Xcode et NuGet qui nécessitent des noms d’utilisateur et des mots de passe comme informations d’identification de base et ne prennent pas en charge les fonctionnalités de compte Microsoft et de Microsoft Entra comme l’authentification multifacteur
  • Accès aux API REST Azure DevOps

• OAuth Azure DevOps pour générer des jetons pour le compte des utilisateurs pour accéder aux API REST. Les API Comptes et profils prennent uniquement en charge OAuth.

• L’authentification SSH pour générer des clés de chiffrement pour vous-même lorsque vous utilisez Linux, macOS ou Windows exécutant Git pour Windows et que vous ne pouvez pas utiliser les gestionnaires d’informations d’identification Git ou les jetons d’accès personnels pour l’authentification HTTPS.

• Les principaux de service ou les identités managées pour générer des jetons Microsoft Entra pour le compte d’une application ou d’un service, qui automatisent généralement un flux de travail qui doit accéder aux ressources Azure DevOps. La plupart des actions effectuées traditionnellement par un compte de service et un PAT peuvent être effectuées à l’aide d’un principal de service ou d’une identité managée.

Par défaut, votre compte ou collection autorise l’accès à toutes les méthodes d’authentification. Vous pouvez limiter l’accès, mais vous devez restreindre spécifiquement l’accès pour chaque méthode. Lorsque vous refusez l’accès à une méthode d’authentification, aucune application ne peut utiliser cette méthode pour accéder à votre compte. Toute application ayant précédemment accès obtient une erreur d’authentification et ne peut pas accéder à votre compte.

Pour plus d’informations sur la façon dont nous stockons vos informations d’identification, consultez Stockage des informations d’identification pour Azure DevOps.

Pour plus d’informations sur le choix du mécanisme d’authentification approprié, consultez Conseils pour l’authentification.

Autorisation

L’autorisation vérifie que l’identité qui tente de se connecter dispose des autorisations nécessaires pour accéder à un service, une fonctionnalité, une fonction, un objet ou une méthode. L’autorisation intervient toujours après que l’authentification a réussi. Si une connexion n’est pas authentifiée, elle échoue avant même la vérification de l’autorisation. Si l’authentification d’une connexion réussit, une action spécifique peut toujours être refusée, car l’utilisateur ou le groupe n’avait pas l’autorisation d’effectuer cette action.

L’autorisation dépend des autorisations attribuées au compte. Les autorisations sont accordées soit directement à un compte, soit via l’appartenance à un groupe de sécurité ou à un rôle de sécurité. Les niveaux d’accès et les indicateurs de fonctionnalité peuvent également accorder ou restreindre l’accès à une fonctionnalité. Pour plus d’informations sur ces méthodes d’autorisation, consultez Bien démarrer avec les autorisations, l’accès et les groupes de sécurité.

Espaces de noms et autorisations de sécurité

Les espaces de noms de sécurité stockent des données qui déterminent le niveau d’accès dont disposent les comptes Azure DevOps pour effectuer une action spécifique sur une ressource spécifique. Chaque famille de ressources, comme les éléments de travail ou les dépôts Git, est sécurisée via un espace de noms unique. Chaque espace de noms de sécurité contient zéro ou plusieurs listes de contrôle d’accès (ACL). Chaque liste de contrôle d’accès contient un jeton, un indicateur hérite et un ensemble d’entrées de contrôle d’accès nulles ou plus. Chaque ACE contient un descripteur d’identité, un masque de bits d’autorisations autorisées et un masque de bits d’autorisations refusées.

Pour plus d’informations, consultez Espaces de noms de sécurité et informations de référence sur les autorisations.

Stratégies de sécurité

Pour sécuriser votre organization et votre code, vous pouvez définir de nombreuses stratégies. Plus précisément, vous pouvez activer ou désactiver les stratégies suivantes :

Général

• URL de la stratégie de confidentialité : spécifie une URL qui établit un lien vers votre document personnalisé qui décrit la façon dont vous gérez la confidentialité des données invité internes et externes. Pour plus d’informations, consultez Ajouter une URL de stratégie de confidentialité pour votre organization.

Stratégies de sécurité et de connexion d’application

Utilisez la stratégie de locataire Microsoft Entra pour restreindre la création de nouvelles organisations aux utilisateurs souhaités uniquement. Cette stratégie est désactivée par défaut et valide uniquement lorsque l’organisation est connectée à l’ID Microsoft Entra. Pour plus d’informations, vérifiez restreindre la création organization.

Les stratégies suivantes déterminent l’accès que vous souhaitez accorder aux utilisateurs et aux applications à vos organisations :

• Accès aux applications tierces via OAuth.
• Accès d’authentification SSH.
• Autoriser les projets publics : lorsque cette option est activée, les utilisateurs peuvent créer des projets publics qui autorisent les non-membres d’un projet et les utilisateurs qui ne sont pas connectés à un accès limité en lecture seule aux artefacts et services du projet. Pour en savoir plus, consultez Rendre votre projet public.
• Événements d’audit de journal : activez la possibilité de suivre les événements et flux d’audit pour votre organization.
• Activez la validation de la stratégie d’accès conditionnel (CAP) Microsoft Entra.

Stratégies utilisateur

• Accès invité externe (valide uniquement lorsque l’organisation est connectée à l’ID Microsoft Entra.) : lorsque cette option est activée, les invitations peuvent être envoyées à des comptes de messagerie d’utilisateurs qui ne sont pas membres de l’ID Microsoft Entra client via la page Utilisateurs . Pour plus d’informations, consultez Ajouter des utilisateurs externes à votre organization.
• Autoriser les administrateurs d’équipe et de projet à inviter de nouveaux utilisateurs : valide uniquement lorsque l’organisation est connectée à l’ID Microsoft Entra. Lorsque cette option est activée, les administrateurs d’équipe et de projet peuvent ajouter des utilisateurs via la page Utilisateurs . Pour plus d’informations, consultez Restreindre les invitations d’utilisateurs provenant des administrateurs de projet et d’équipe.
• Demander l’accès : valide uniquement lorsque l’organisation est connectée à l’ID Microsoft Entra. Lorsque cette option est activée, les utilisateurs peuvent demander l’accès à une ressource. Une demande entraîne une notification par e-mail aux administrateurs qui demandent une révision et un accès, selon les besoins. Pour plus d’informations, consultez Ajouter des utilisateurs externes à votre organization.
• Inviter des utilisateurs GitHub : valide uniquement lorsque l’organisation n’est pas connectée à l’ID Microsoft Entra. Lorsque cette option est activée, les administrateurs peuvent ajouter des utilisateurs en fonction de leurs comptes d’utilisateur GitHub à partir de la page Utilisateurs . Pour plus d’informations, consultez Les questions fréquentes (FAQ) sur l’authentification et l’invitation d’utilisateurs GitHub.

Project-Scoped groupe Utilisateurs

Par défaut, les utilisateurs ajoutés à un organization peuvent afficher toutes les informations et paramètres de organization et de projet. Cela inclut l’affichage de la liste des utilisateurs, de la liste des projets, des détails de facturation, des données d’utilisation, et bien plus encore, accessible via les paramètres de l’organisation.

Important

• Les fonctionnalités de visibilité limitée décrites dans cette section s’appliquent uniquement aux interactions via le portail web. Avec les API REST ou azure devops les commandes CLI, les membres du projet peuvent accéder aux données restreintes.
• Les utilisateurs invités qui sont membres du groupe limité avec un accès par défaut dans l’ID Microsoft Entra ne peuvent pas rechercher d’utilisateurs avec le sélecteur de personnes. Lorsque la fonctionnalité d’aperçu est désactivée pour l’organisation ou lorsque les utilisateurs invités ne sont pas membres du groupe limité, les utilisateurs invités peuvent rechercher tous les utilisateurs De Microsoft Entra, comme prévu.

Pour restreindre les utilisateurs sélectionnés, tels que les parties prenantes, les utilisateurs invités Microsoft Entra ou les membres d’un groupe de sécurité particulier, vous pouvez activer la visibilité et la collaboration des utilisateurs sur des projets spécifiques en préversion pour l’organisation. Une fois cette option activée, tous les utilisateurs ou groupes ajoutés au groupe Utilisateurs dans l’étendue du projet sont restreints des manières suivantes :

• Peut uniquement accéder aux pages Vue d’ensemble et Projets des paramètres de l’organisation.
• Peut uniquement se connecter et afficher les projets auxquels ils ont été ajoutés explicitement (voir Ajouter des utilisateurs à un projet ou à une équipe.
• Peut sélectionner uniquement les identités d’utilisateur et de groupe qui ont été ajoutées explicitement au projet auquel elles sont connectées.

Pour plus d’informations, consultez Gérer votre organisation, Limiter la visibilité des utilisateurs pour les projets et plus et gérer les fonctionnalités en préversion.

Avertissement

Lorsque la fonctionnalité Limiter la visibilité et la collaboration des utilisateurs à des projets spécifiques sont activées pour l’organisation, les utilisateurs délimités par le projet ne peuvent pas rechercher les utilisateurs qui ont été ajoutés à l’organisation par le biais de l’appartenance au groupe Microsoft Entra, plutôt que par le biais d’une invitation explicite à l’utilisateur. Il s’agit d’un comportement inattendu et une résolution est en cours de résolution. Pour résoudre ce problème, désactivez la fonctionnalité d’aperçu Limiter la visibilité et la collaboration des utilisateurs à des projets spécifiques pour le organization.

Stratégies de dépôt et de branche Git

• Configurer les stratégies et les paramètres du référentiel
• Configurer des stratégies de branche
• Configurer la stratégie de branche pour un service externe
• Utiliser Azure Functions pour créer des stratégies de branche personnalisées

sécurité Azure Repos et Azure Pipelines

Étant donné que les référentiels et les pipelines de build et de mise en production posent des défis de sécurité uniques, d’autres fonctionnalités sont utilisées au-delà des fonctionnalités décrites dans cet article. Pour plus d'informations, consultez les articles suivants.

• Sécurisation d’Azure Pipelines
• Planifier la sécurisation de vos pipelines YAML
• Protection des référentiels
• Ressources de pipeline
• Recommandations pour structurer de manière sécurisée les projets dans votre pipeline
• Sécurité via des modèles
• Comment utiliser de manière sécurisée des variables et des paramètres dans votre pipeline
• Recommandations pour sécuriser l’infrastructure partagée dans Azure Pipelines
• Autres considérations relatives à la sécurité

Étapes suivantes

Informations de référence sur les autorisations et les groupes

Articles connexes

• Autorisations et attributions d’accès par défaut
• Ajouter ou supprimer des utilisateurs à l’aide de Microsoft Entra ID
• Configurer des groupes à utiliser dans des déploiements locaux
• Configuration de HTTPS avec SSL (Secure Sockets Layer)
• Autorisations et attributions d’accès par défaut