À 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.

Si vous souhaitez obtenir plus d’informations, consultez Meilleures pratiques en matière de sécurité.

Niveaux d’accès

Tous les utilisateurs d’Azure DevOps ont un niveau d’accès, qui accorde ou limite l’accès à des fonctionnalités spécifiques 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 d’Azure DevOps appartiennent à un ou plusieurs groupes de sécurité par défaut. Les groupes de sécurité obtiennent des autorisations attribuées qui autorisent ou refusent l’accès aux fonctionnalités ou aux tâches.

• Les membres héritent des autorisations affectées à leur groupe de sécurité.
• Les autorisations sont définies à différents niveaux : organisation/collection, projet ou objet.
• Certaines autorisations sont gérées via des attributions basées sur des rôles (par exemple, administrateur d’équipe, gestion des extensions ou rôles de ressources de pipeline).
• Les administrateurs peuvent définir des groupes de sécurité personnalisés pour gérer les autorisations pour différents domaines fonctionnels.

Pour plus d’informations, consultez Meilleures pratiques de sécurité, Sécurité et groupes d’utilisateurs.

La gestion des autorisations dans Azure DevOps implique deux groupes clés : administrateurs de regroupement de projets et administrateurs de projet.

Administrateurs de collection de projets :

• Conservez l’autorité la plus élevée au sein d’une organisation ou d’une collection de projets.
• Effectuez toutes les opérations pour l’ensemble de la collection.
• Gérez les paramètres, les stratégies et les processus de l’organisation.
• Créez et gérez tous les projets et extensions.

Administrateurs de projet :

• Fonctionne au niveau du projet.
• Gérez les groupes de sécurité et les autorisations à partir des paramètres du projet dans le portail web.
• Les contributeurs gèrent les autorisations pour des objets spécifiques qu’ils créent dans le projet.

État de l’autorisation

Attribuez des autorisations pour accorder ou restreindre l’accès :

L’utilisateur ou le groupe dispose d’autorisations :

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

L’utilisateur ou le groupe n’a pas d’autorisation :

• 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é) .

Les membres des groupes Administrateurs de collection de projets ou Administrateurs Team Foundation peuvent toujours recevoir des autorisations même s’ils sont refusés dans un autre groupe. Les exemples suivants expliquent ce scénario plus loin :

• Un utilisateur peut toujours accéder aux paramètres du projet ou gérer les utilisateurs. Toutefois, pour les tâches telles que la suppression d’éléments de travail ou la gestion des pipelines, être membre du groupe Administrateurs de collection de projets ne remplace pas le jeu d’autorisations Refuser un jeu d’autorisations ailleurs.
• Si un utilisateur est autorisé à supprimer des éléments de travail dans un projet spécifique, il ne peut pas supprimer d’éléments de travail même s’il fait partie du groupe Administrateurs de collection de projets. De même, si les autorisations de pipeline sont refusées, elles ne peuvent pas gérer ou exécuter des pipelines malgré leur rôle d’administration.

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 à partir d’un nœud parent ou la substitue.

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 par le biais de l’appartenance à un groupe, mais dispose également d’une autorisation Refuser via un autre groupe, l’autorisation Refuser est prioritaire.
• Les membres des administrateurs de collection de projets ou administrateurs Team Foundation 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.

Règles d’héritage d’autorisation et de spécificité :

• Les autorisations explicites sont toujours prioritaires sur les autorisations héritées.
• Les autorisations définies sur un nœud de niveau supérieur sont héritées par tous les sous-nœuds, 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.
• Si une autorisation est explicitement définie pour un sous-nœud, 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. L’autorisation la plus spécifique est prioritaire si des autorisations en conflit existent.

Exemple :

• 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 sélectionner 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 Administrateurs de projet.

Project

Organisation ou collection

- Générer des administrateurs -Contributeurs - Administrateurs de projet - Projets utilisateurs valides -Lecteurs - Administrateurs de mise en production - TeamName Team

- Administrateurs de collection de projets - Administrateurs de build de collection de projets - 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 Administrateurs de projet.

Pour les utilisateurs chargés de gérer les fonctionnalités au niveau de l’organisation ou des regroupements, 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 Administrateurs de collection de projets. 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 collection de projets : Tous les membres ajoutés à un groupe au niveau de l’organisation.
• Utilisateurs valides de 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

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.

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

Remarque

Les groupes de sécurité sont gérés au niveau de l’organisation, même s’ils sont utilisés pour des projets spécifiques. Selon les autorisations utilisateur, certains groupes peuvent être masqués dans le portail web. Pour afficher tous les noms de groupe au sein d’une organisation, vous pouvez utiliser 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 Administrateurs de projet ou Administrateurs de regroupement de projets peuvent gérer tous les outils d’équipe pour toutes les équipes.

Fonctionnalités de préversion

Les indicateurs de fonctionnalité contrôlent l’accès aux nouvelles fonctionnalités. Azure DevOps introduit régulièrement de nouvelles fonctionnalités 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
• En savoir plus sur la sécurité, l’authentification et l’autorisation
• Autorisations et groupes de référence
• Ajouter et gérer les groupes de sécurité