À propos des autorisations et des groupes de sécurité

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

Dans cet article, découvrez les niveaux d’accès et les autorisations via l’héritage, les groupes de sécurité, les rôles et bien plus encore dans Azure DevOps.

Pour une vue d'ensemble des autorisations par défaut, voir Informations de référence rapides sur les autorisations par défaut. Pour obtenir une description de chaque groupe de sécurité par défaut, consultez les informations de référence sur les groupes de sécurité, les comptes de service et les autorisations.

Niveaux d’accès

Tous les utilisateurs ajoutés à Azure DevOps reçoivent un niveau d’accès, qui accorde ou restreint l’accès à certaines fonctionnalités du portail web.

Il existe trois niveaux d’accès principaux : Les parties prenantes, les plans de base et de base + test. L’accès des parties prenantes offre un accès gratuit à un nombre illimité d’utilisateurs à un ensemble limité de fonctionnalités. Pour plus d’informations, consultez Référence rapide sur l’accès de partie prenante.

Pour donner à un utilisateur l’accès aux fonctionnalités de gestion de portefeuille Agile ou de gestion des cas de test, modifiez les niveaux d’accès, et non les autorisations. Pour plus d’informations, consultez À propos des niveaux d’accès.

Autorisations

Tous les utilisateurs ajoutés à Azure DevOps sont ajoutés à un ou plusieurs groupes de sécurité par défaut. Les groupes de sécurité reçoivent des autorisations, qui autorisent ou refusent l’accès à une fonctionnalité ou à une tâche.

• Les membres d’un groupe de sécurité héritent des autorisations attribuées au groupe.
• Les autorisations sont définies à différents niveaux : organisation/collection, projet ou objet.
• D’autres autorisations sont gérées via des attributions basées sur des rôles, telles que l’administrateur d’équipe, la gestion des extensions et divers rôles de ressources de pipeline.
• Administration istrators peuvent définir des groupes de sécurité personnalisés pour gérer les autorisations pour différents domaines fonctionnels.

Lorsqu’il s’agit de gérer les autorisations dans Azure DevOps, il existe deux groupes clés impliqués : les Administration istrators de collection de projets et les Administration istrateurs project. Nous allons la décomposer :

Collection de projets Administration istrators :

• Ces personnes ont le niveau d’autorité le plus élevé au sein d’une organisation ou d’une collection de projets.
• Ils peuvent effectuer toutes les opérations pour l’ensemble de la collection.
• Leurs responsabilités incluent la gestion des paramètres, des stratégies et des processus pour l’organisation.
• En outre, ils peuvent créer et gérer tous les projets et extensions au sein de l’organisation.

Administration istrateurs de projet :

• Les Administration istrateurs de projet fonctionnent au niveau du projet.
• Ils gèrent les groupes de sécurité et les autorisations principalement à partir des paramètres du projet du portail web.
• Les contributeurs, d’autre part, gèrent les autorisations pour des objets spécifiques qu’ils créent dans le projet.

États d’autorisation

Vous pouvez attribuer des autorisations de la manière suivante, accorder ou restreindre l’accès, comme indiqué.

L’utilisateur ou le groupe dispose des autorisations nécessaires pour effectuer une tâche :

• Autoriser
• Autoriser (hérité)
• Autoriser (système)

L’utilisateur ou le groupe n’a pas l’autorisation d’effectuer une tâche :

• Deny
• Refuser (hérité)
• Refuser (système)
• Non défini

État de l’autorisation	Description
Autoriser	Accorde explicitement aux utilisateurs d’effectuer des tâches spécifiques et n’est pas hérité de l’appartenance au groupe.
Autoriser (hérité)	Accorde aux membres du groupe d’effectuer des tâches spécifiques.
Autoriser (système)	Accorde l’autorisation qui est prioritaire avant les autorisations utilisateur. Non modifiable et stocké dans une base de données de configuration, invisible pour les utilisateurs.
Deny	Empêche explicitement les utilisateurs d’effectuer des tâches spécifiques et n’est pas hérité de l’appartenance au groupe. Pour la plupart des groupes et presque toutes les autorisations, Refuser l’emporte sur Autoriser. Si un utilisateur appartient à deux groupes et qu’un d’entre eux a un jeu d’autorisations spécifique sur Refuser, cet utilisateur ne peut pas effectuer de tâches nécessitant cette autorisation même si elle appartient à un groupe dont l’autorisation est définie sur Autoriser.
Refuser (hérité)	Empêche les membres du groupe d’effectuer des tâches spécifiques. Remplace une autorisation explicite.
Refuser (système)	Limite l’autorisation qui est prioritaire avant les autorisations utilisateur. Non modifiable et stocké dans une base de données de configuration, invisible pour les utilisateurs.
Non défini	Refuse implicitement aux utilisateurs la possibilité d’effectuer des tâches qui nécessitent cette autorisation, mais autorise l’appartenance à un groupe disposant de cette autorisation à précédence, également appelée Autoriser (hérité) ou Refuser (hérité) .

Dans certains cas, les membres de la collection de projets Administration istrators ou des groupes Team Foundation Administration istrators peuvent toujours obtenir l’autorisation même s’ils sont refusés à cette autorisation dans un autre groupe. Dans d’autres cas, tels que la suppression d’éléments de travail ou les pipelines, être membre du groupe Collection de projets Administration istrators ne contourne pas le jeu d’autorisations Refuser un jeu d’autorisations ailleurs.

Avertissement

Lorsque vous modifiez une autorisation pour un groupe, elle affecte tous les utilisateurs de ce groupe. Même une modification d’autorisation unique peut avoir un impact sur des centaines d’utilisateurs. Il est donc essentiel de prendre en compte les effets potentiels avant d’effectuer des ajustements.

Héritage d'autorisations

Les autorisations suivent une hiérarchie, ce qui autorise l’héritage d’un parent ou en remplaçant.

• Héritage de groupe : les utilisateurs héritent des autorisations des groupes auxquels ils appartiennent. Si un utilisateur dispose d’une autorisation Autoriser directement ou via l’appartenance à un groupe, mais dispose également d’une autorisation Refuser via un autre groupe, l’autorisation Refuser est prioritaire. Toutefois, les membres de la collection de projets Administration istrators ou Team Foundation Administration istrators conservent la plupart des autorisations autorisées, même s’ils appartiennent à d’autres groupes qui refusent ces autorisations (à l’exception des opérations d’élément de travail).
• Héritage au niveau de l’objet : les autorisations au niveau de l’objet (affectées à des nœuds tels que des zones, des itérations, des dossiers de contrôle de version et des dossiers de requête d’élément de travail) sont héritées de la hiérarchie.

Par exemple, nous allons décomposer l’héritage des autorisations et les règles de spécificité et mémoriser, les autorisations explicites sont toujours prioritaires sur celles héritées :

• Quand les autorisations d’un utilisateur sont définies sur un nœud de niveau supérieur (zone-1), ces autorisations sont héritées par tous les sous-nœuds (area-1/sous-zone-1), sauf si elles sont remplacées explicitement.
• Si une autorisation n’est pas explicitement autorisée ou refusée pour un sous-nœud, elle hérite de l’autorisation de son parent.
• Toutefois, si une autorisation est explicitement définie pour un sous-nœud (zone-1/sous-zone-1), l’autorisation du parent n’est pas héritée, qu’elle soit autorisée ou refusée. Spécificité:
• Dans la hiérarchie d’objets, la spécificité trompe l’héritage. Cela signifie que si des autorisations en conflit existent, l’autorisation la plus spécifique est prioritaire.
• Par exemple, considérez un utilisateur :
  • Refuser explicitement sur « area-1 » (nœud parent).
  • Autorisez explicitement « area-1/sub-area-1 » (nœud enfant).
• Dans ce cas, l’utilisateur reçoit une autorisation sur « area-1/sub-area-1 », en remplaçant le refus hérité du nœud parent.

Pour comprendre pourquoi une autorisation est héritée, vous pouvez suspendre sur un paramètre d’autorisation, puis choisir Pourquoi ? Pour ouvrir une page Sécurité , consultez Afficher les autorisations.

Remarque

Pour activer la page d’aperçu des paramètres des autorisations de projet, consultez Activer les fonctionnalités d’aperçu.

Page de préversion

Une nouvelle boîte de dialogue s’ouvre qui affiche les informations d’héritage de cette autorisation.

Page active

Une nouvelle fenêtre affiche les informations d’héritage pour cette autorisation.

Groupes de sécurité et appartenance

Les groupes de sécurité attribuent des autorisations spécifiques à leurs membres.

Avec la création d’une organisation, d’une collection ou d’un projet, Azure DevOps crée un ensemble de groupes de sécurité par défaut, auxquels sont automatiquement attribuées des autorisations par défaut. D’autres groupes de sécurité sont définis avec les actions suivantes :

• Lorsque vous créez des groupes de sécurité personnalisés aux niveaux suivants :
  • Niveau projet
  • Au niveau de l’organisation ou de la collection
  • Au niveau du serveur (local uniquement)
• Lorsque vous ajoutez une équipe, un groupe de sécurité d’équipe est créé

Vous ne pouvez pas créer un groupe de sécurité au niveau de l’objet, mais vous pouvez affecter un groupe personnalisé à un niveau objet et attribuer des autorisations à ce niveau. Pour plus d’informations, consultez Définir des autorisations au niveau de l’objet.

Groupes de sécurité par défaut

La plupart des utilisateurs Azure DevOps sont ajoutés au groupe de sécurité Contributeurs et ont accordé un niveau d’accès de base . Le groupe Contributeurs fournit un accès en lecture et écriture aux référentiels , au suivi des travaux, aux pipelines, etc. L’accès de base permet d’accéder à toutes les fonctionnalités et tâches pour l’utilisation d’Azure Boards, d’Azure Repos, d’Azure Pipelines et d’Azure Artifacts. Les utilisateurs qui ont besoin d’accéder à la gestion des plans de test Azure doivent disposer d’un accès de base + Plan de test ou d’accès avancé .

Les groupes de sécurité suivants sont définis par défaut pour chaque projet et organisation. Vous ajoutez généralement des utilisateurs ou des groupes aux groupes Lecteurs, Contributeurs ou Project Administration istrateurs.

Project

Organisation ou collection

- Générer des Administration istrateurs -Contributeurs - Project Administration istrators - Projets utilisateurs valides -Lecteurs - Versions Administration istrateurs - TeamName Team

- Collection de projets Administration istrateurs - Build de collection de projets Administration istrators - Comptes de service de génération de regroupement de projets - Comptes de service proxy de regroupement de projets - Comptes de service de collecte de projets - Comptes de service de test de collecte de projets - Regroupement de projets utilisateurs valides - Utilisateurs dans l’étendue du projet - Groupe de services de sécurité

Pour obtenir une description de chacun de ces groupes, consultez groupes de sécurité, comptes de service et autorisations. Pour connaître les attributions d’autorisations par défaut effectuées sur les groupes de sécurité par défaut les plus courants, consultez Autorisations et accès par défaut.

Pour les utilisateurs chargés de gérer les fonctionnalités au niveau du projet( par exemple, les équipes, les chemins d’accès de zone et d’itération, les référentiels, les hooks de service et les points de terminaison de service), ajoutez-les au groupe Project Administration istrators.

Pour les utilisateurs chargés de gérer les fonctionnalités au niveau de l’organisation ou de la collection, telles que les projets, les stratégies, les processus, les stratégies de rétention, les pools d’agents et de déploiement et les extensions, ajoutez-les au groupe collection de projets Administration istrateurs. Pour plus d’informations, consultez À propos des paramètres utilisateur, équipe, projet et organisation.

Gestion des niveaux d’appartenance, d’autorisation et d’accès

Azure DevOps contrôle l’accès via ces trois zones fonctionnelles connectées :

• La gestion des appartenances prend en charge l'ajout de comptes d'utilisateur individuels et de groupes aux groupes de sécurité par défaut. Chaque groupe par défaut est associé à un jeu d'autorisations par défaut. Tous les utilisateurs ajoutés à n’importe quel groupe de sécurité sont ajoutés au groupe Utilisateurs valides. Un utilisateur valide est une personne pouvant se connecter à un projet, une collection ou une organisation.
• La gestion des autorisations contrôle l'accès aux tâches fonctionnelles spécifiques à différents niveaux du système. Les autorisations au niveau de l’objet définissent des autorisations sur un fichier, un dossier, un pipeline de build ou une requête partagée. Les paramètres d’autorisation correspondent à Autoriser, Refuser, Autoriser hérité, Refuser hérité, Autoriser le système, Refuser le système et Non défini.
• La gestion au niveau de l’accès contrôle l’accès aux fonctionnalités du portail web. En fonction de l’achat d’un utilisateur, les administrateurs définissent le niveau d’accès de l’utilisateur sur Les parties prenantes, Basic, Basic + Test ou Visual Studio Enterprise (précédemment Avancé).

Chaque zone fonctionnelle utilise des groupes de sécurité pour simplifier la gestion sur le déploiement. Vous ajoutez des utilisateurs et des groupes à travers le contexte d’administration web. Les autorisations sont automatiquement définies en fonction du groupe de sécurité auquel vous ajoutez des utilisateurs. Ou les autorisations s’appuient sur l’objet, le projet, la collection ou le niveau serveur auquel vous ajoutez des groupes.

L'appartenance à un groupe de sécurité peut être une combinaison d'utilisateurs, d'autres groupes et de groupes Microsoft Entra.

Groupes de sécurité Active Directory et Microsoft Entra

Vous pouvez remplir des groupes de sécurité en ajoutant des utilisateurs individuels. Toutefois, pour faciliter la gestion, il est plus efficace de remplir ces groupes à l’aide de l’ID Microsoft Entra pour Azure DevOps Services et Active Directory (AD) ou des groupes d’utilisateurs Windows pour Azure DevOps Server. Cette approche vous permet de gérer plus efficacement l’appartenance au groupe et les autorisations sur plusieurs ordinateurs.

Si vous n’avez besoin de gérer qu’un petit ensemble d’utilisateurs, vous pouvez ignorer cette étape. Toutefois, si vous prévoyez que votre organisation peut croître, envisagez de configurer Active Directory ou Microsoft Entra ID. En outre, si vous envisagez d’utiliser des services supplémentaires, il est essentiel de configurer l’ID Microsoft Entra pour une utilisation avec Azure DevOps pour prendre en charge la facturation.

Remarque

Sans ID Microsoft Entra, tous les utilisateurs Azure DevOps doivent se connecter à l’aide de comptes Microsoft, et vous devez gérer l’accès au compte par des comptes d’utilisateur individuels. Même si vous gérez l’accès au compte à l’aide de comptes Microsoft, configurez un abonnement Azure pour gérer la facturation.

Pour configurer l’ID Microsoft Entra à utiliser avec Azure DevOps Services, consultez Connecter votre organisation à l’ID Microsoft Entra.

Lorsque votre organisation est connectée à l’ID Microsoft Entra, vous pouvez définir et gérer différentes stratégies d’organisation pour améliorer la sécurité et simplifier l’accès aux applications. Pour plus d’informations, consultez À propos de la sécurité, des stratégies de sécurité.

Pour gérer l’accès organisationnel avec l’ID Microsoft Entra, consultez les articles suivants :

• Ajouter ou supprimer des utilisateurs à l’aide de Microsoft Entra ID
• Résoudre les problèmes d’accès avec l’ID Microsoft Entra

Azure DevOps inscrit les modifications apportées à un groupe Microsoft Entra dans un délai d’une heure après cette modification dans l’ID Microsoft Entra. Toutes les autorisations héritées via l’appartenance au groupe sont actualisées. Pour actualiser votre appartenance à Microsoft Entra et les autorisations héritées dans Azure DevOps, déconnectez-vous, puis reconnectez-vous ou déclenchez une actualisation pour réévaluer votre autorisation.

Groupes d’utilisateurs valides

Lorsque vous ajoutez des comptes d’utilisateurs directement à un groupe de sécurité, ils sont automatiquement ajoutés à l’un des groupes d’utilisateurs valides suivants.

• Utilisateurs valides de la collection de projets : tous les membres ajoutés à un groupe au niveau de l’organisation.
• Utilisateurs valides du projet : tous les membres ajoutés à un groupe au niveau du projet.

Les autorisations par défaut attribuées à ces groupes fournissent principalement un accès en lecture, comme afficher les ressources de génération, afficher les informations au niveau du projet et afficher les informations au niveau de la collection.

Tous les utilisateurs que vous ajoutez à un projet peuvent afficher les objets d’autres projets au sein d’une collection. Pour restreindre l’accès à la vue, vous pouvez définir des restrictions via le nœud de chemin d’accès de zone.

Si vous supprimez ou refusez l’autorisation Afficher les informations au niveau de l’instance pour l’un des groupes Utilisateurs valides, aucun membre du groupe ne peut accéder au projet, à la collection ou au déploiement, en fonction du groupe que vous avez défini.

Groupe d’utilisateurs dans l’étendue du projet

Par défaut, les utilisateurs ajoutés à un organization peuvent afficher toutes les informations et paramètres de organization et de projet. Ces paramètres incluent la liste des utilisateurs, la liste des projets, les détails de facturation, les données d’utilisation, etc. que vous pouvez accéder 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 des utilisateurs spécifiques, 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 activé, tout utilisateur ou groupe ajouté au groupe Utilisateurs délimités par le projet est limité à l’accès aux pages des paramètres de l’organisation, à l’exception de La vue d’ensemble et des projets. En outre, ils n’ont accès qu’aux projets auxquels ils sont ajoutés.

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 automatiquement ce problème, désactivez la fonctionnalité limiter la visibilité et la collaboration des utilisateurs à des projets spécifiques en préversion pour l’organisation.

Pour plus d’informations, consultez Gérer les fonctionnalités en préversion.

Remarque

Les groupes de sécurité appartiennent au niveau de l’organisation, même s’ils accèdent uniquement à un projet spécifique. Certains groupes peuvent être masqués dans le portail web en fonction des autorisations utilisateur. Vous trouverez tous les noms de groupe dans une organisation avec l’outil AZURE devops CLI ou nos API REST. Pour plus d’informations, consultez Ajouter et gérer des groupes de sécurité.

Autorisations basées sur les rôles

Avec les autorisations en fonction du rôle, vous attribuez des comptes d’utilisateur ou des groupes de sécurité à un rôle, chaque rôle ayant attribué une ou plusieurs autorisations. Voici les rôles principaux et les liens vers plus d’informations.

• Rôles de sécurité d’artefact ou de flux de package : les rôles prennent en charge différents niveaux d’autorisation pour modifier et gérer les flux de package.
• Rôle Gestionnaire d’extensions de la Place de marché : les membres du rôle Manager peuvent installer des extensions et répondre aux demandes d’installation des extensions.
• Rôles de sécurité de pipeline : plusieurs rôles sont utilisés pour gérer les ressources de bibliothèque, le niveau du projet et les ressources de pipeline au niveau du regroupement.
• Les administrateurs d’équipe peuvent gérer tous les outils d’équipe.

Pour plus d’informations, consultez À propos des rôles de sécurité.

L’image suivante montre comment les groupes de sécurité définis au niveau du projet et de la collection peuvent attribuer des autorisations à des objets, des projets et à l’organisation.

Les membres des groupes Project Administration istrators ou Project Collection Administration istrators peuvent gérer tous les outils d’équipe pour toutes les équipes.

Meilleures pratiques pour les autorisations

À faire :

• Utilisez les groupes de sécurité Microsoft Entra ID, Active Directory ou Windows lorsque vous gérez un grand nombre d’utilisateurs.
• Lorsque vous ajoutez une équipe, tenez compte des autorisations que vous souhaitez attribuer aux prospects d’équipe, aux maîtres de l’équipe et à d’autres membres de l’équipe. Considérez qui crée et modifie les chemins d’accès de zone, les chemins d’itération et les requêtes.
• Lorsque vous ajoutez de nombreuses équipes, envisagez de créer un groupe personnalisé d’Administration istrateurs d’équipe dans lequel vous pouvez allouer un sous-ensemble des autorisations disponibles pour Project Administration istrators.
• Envisagez d’accorder aux dossiers de requête d’élément de travail l’autorisation Contribuer aux utilisateurs ou aux groupes qui nécessitent la possibilité de créer et de partager des requêtes d’élément de travail pour le projet.

À ne pas faire :

• N’ajoutez pas d’utilisateurs à plusieurs groupes de sécurité, qui contiennent différents niveaux d’autorisation. Dans certains cas, un niveau d’autorisation Refuser peut remplacer un niveau d’autorisation Autoriser .
• Ne modifiez pas les affectations par défaut apportées aux groupes Utilisateurs valides. Si vous supprimez ou affectez à l’autorisation Afficher les informations au niveau de l’instance la valeur Refuser pour l’un des groupes d’utilisateurs valides, aucun utilisateur du groupe ne pourra accéder au projet, à la collection ou au déploiement, selon le groupe défini.
• N’affectez pas des autorisations notées comme « Affecter uniquement aux comptes de service » à des comptes d’utilisateur.

Fonctionnalités en version préliminaire

Les indicateurs de fonctionnalité contrôlent l’accès à la sélection, aux nouvelles fonctionnalités. Régulièrement, Azure DevOps introduit de nouvelles fonctionnalités en les plaçant derrière un indicateur de fonctionnalité. Les membres du projet et les propriétaire d’organisation peuvent activer ou désactiver les fonctionnalités en préversion. Pour plus d’informations, consultez Gérer ou activer des fonctionnalités.

Étapes suivantes

Autorisations et accès par défaut

Articles connexes

• Résoudre les problèmes d’accès et d’autorisation
• À propos de la sécurité, de l’authentification et de l’autorisation
• Informations de référence sur les autorisations et les groupes
• Outils de gestion de la sécurité et des autorisations
• Ajouter et gérer les groupes de sécurité