À 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 différents concepts de sécurité pour s’assurer que seuls les utilisateurs autorisés peuvent accéder aux fonctionnalités, aux fonctions et aux données. Les utilisateurs accèdent à Azure DevOps par le biais de l’authentification de leurs informations d’identification de sécurité et de l’autorisation de leurs droits de compte pour accéder à des fonctionnalités ou fonctions spécifiques.

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 peuvent tirer 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 pas en charge l’authentification d’autres informations d’identification. Si vous utilisez toujours d’autres informations d’identification, nous vous encourageons vivement à passer à une méthode d’authentification plus sécurisée.

Azure DevOps Services (cloud) et Azure DevOps Server (local) prennent en charge le développement de logiciels de la planification au déploiement. Ils tirent parti de l’infrastructure et des services Platform as a Service de Microsoft Azure, y compris les bases de données Azure SQL, pour fournir un service fiable et globalement disponible pour vos projets.

Pour plus d’informations sur la façon dont Microsoft garantit que vos projets Azure DevOps Services sont sécurisés, disponibles, sécurisés et privés, consultez la vue d’ensemble de la protection des données Azure DevOps Services.

Comptes

Bien que les comptes d’utilisateurs humains soient le principal objectif, Azure DevOps prend également en charge différents types de comptes pour différentes 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 trouver le propriétaire de votre organisation, consultez Rechercher le propriétaire d’organisation.
• Comptes de service : organisation Azure DevOps interne utilisée 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 ajoutées à votre organisation pour effectuer des actions pour le compte d’une application tierce. Certains principaux de service font référence à l’organisation Azure DevOps interne 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 nos articles relatifs à la sécurité, les « utilisateurs » font référence à toutes les identités ajoutées au hub d’utilisateurs, qui peuvent inclure des utilisateurs humains et des principaux de service.

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

Remarque

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

Authentification

L’authentification vérifie l’identité d’un compte en fonction des informations d’identification fournies lors de la connexion à Azure DevOps. Ces systèmes s’intègrent et s’appuient sur les fonctionnalités de sécurité des autres systèmes suivants :

• 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 l’ID Microsoft Entra pour gérer un grand groupe d’utilisateurs. Pour une petite base d’utilisateurs accédant à votre organisation Azure DevOps, les comptes Microsoft sont suffisants. 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é pour gérer 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 à Azure DevOps. Pour accéder à votre compte sans demander à plusieurs reprises des informations d’identification utilisateur, les applications peuvent utiliser les méthodes d’authentification suivantes :

• Jetons d’accès personnels (PAT) pour générer des jetons pour votre compte :

  • 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 multi-facteur
  • Accès aux API REST Azure DevOps

• Azure DevOps OAuth pour générer des jetons au nom 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 vous-même des clés de chiffrement lorsque vous utilisez Linux, macOS ou Windows exécutant Git pour Windows et ne peut pas utiliser les gestionnaires d’informations d’identification Git ou les PAT pour l’authentification HTTPS.

• Principaux de service ou identités managées pour générer des jetons Microsoft Entra pour le compte d’une application ou d’un service, en général en automatisant les flux de travail qui doivent 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 en limitant spécifiquement 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 qui avait précédemment accès reçoit une erreur d’authentification et ne peut pas accéder à votre compte.

Pour plus d’informations, consultez les articles suivants :

• Stockage des informations d’identification pour Azure DevOps.
• 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 d’effectuer des vérifications d’autorisation. Même si l’authentification réussit, une action spécifique peut toujours être interdite si l’utilisateur ou le groupe n’a pas d’autorisation.

L’autorisation dépend des autorisations attribuées à l’utilisateur, directement ou 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 gérer l’accès à des fonctionnalités spécifiques. 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é déterminent les niveaux d’accès utilisateur pour des actions spécifiques sur les ressources.

• Chaque famille de ressources, telle que les éléments de travail ou les référentiels Git, a un espace de noms unique.
• Chaque espace de noms contient zéro ou plusieurs listes de contrôle d’accès (ACL).
  • Chaque liste de contrôle d’accès inclut un jeton, un indicateur d’héritage et des entrées de contrôle d’accès (ACL).
  • Chaque ACE dispose d’un descripteur d’identité, d’un masque de bits d’autorisations autorisé et d’un masque de bits d’autorisations refusé.

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 organisation et votre code, vous pouvez définir différentes 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, consultez Restreindre la création de l’organisation.

Les stratégies suivantes déterminent l’accès accordé aux utilisateurs et aux applications au sein de vos organisations :

• Accès aux applications non-Microsoft 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 plus d’informations, 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.) : lorsqu’elle 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 du locataire 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 Se connecter à GitHub/FAQ.

Project-Scoped groupe Utilisateurs

Par défaut, les utilisateurs ajoutés à une organisation peuvent afficher toutes les informations et paramètres de l’organisation, notamment les listes d’utilisateurs, les listes de projets, les détails de facturation, les données d’utilisation, etc.

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 certains utilisateurs, tels que les parties prenantes, les utilisateurs invités Microsoft Entra ou les membres d’un groupe de sécurité spécifique, 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 délimités par le projet sont limités de la manière suivante :

• 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.
• Peut uniquement sélectionner des identités d’utilisateur et de groupe ajoutées explicitement au projet auquel ils sont connectés.

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

L’activation de la visibilité et de la collaboration de l’utilisateur pour des projets spécifiques empêche les utilisateurs à portée de projet de rechercher des utilisateurs ajoutés à l’organisation via 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. Pour résoudre ce problème, désactivez la visibilité de l’utilisateur limite et la collaboration avec des projets spécifiques en préversion pour l’organisation.

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 présentent des défis de sécurité uniques, d’autres fonctionnalités au-delà des fonctionnalités décrites dans cet article sont utilisées. Pour plus d’informations, voir 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