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

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

Dans cet article, vous allez découvrir 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 plus d’informations, consultez Vue d’ensemble de la 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. Trois niveaux d’accès principaux existent : Parties Prenantes, Basique, et Basique + Plans de Test. 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. Attribuez des autorisations aux groupes de sécurité 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é.
• Définissez des autorisations à différents niveaux : organisation/collection, projet ou objet.
• Gérez certaines autorisations 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.

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 :

• Disposez d’autorisations administratives étendues au sein d’une organisation ou d’une collection de projets.
• Gérez les paramètres, les stratégies et les processus de l’organisation.
• Créez et gérez des projets.

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.
• Gérez les autorisations pour les objets spécifiques que les contributeurs créent au sein du 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é)
• Rejeter (système)
• Non défini

Azure DevOps calcule les autorisations effectives des affectations directes, des appartenances aux groupes et des affectations héritées. Lorsque des attributions sont combinées au même niveau de portée, Deny prend généralement le pas sur Allow. Dans une hiérarchie d’objets, une attribution explicite sur un objet enfant peut remplacer la valeur héritée de son parent pour une même identité.

Héritage d'autorisations

Les autorisations suivent une hiérarchie. Vous pouvez donc hériter des autorisations d’un nœud parent ou les remplacer.

Héritage de groupe :

• Les utilisateurs reçoivent les autorisations combinées des groupes auxquels ils appartiennent.
• Dans la même étendue, un refus d’un groupe est généralement prioritaire sur une autorisation d’un autre groupe.
• Non défini n’accorde pas ou refuse une autorisation et ne remplace pas une affectation d’un autre groupe.

Héritage au niveau de l’objet :

Vous attribuez des autorisations au niveau de l’objet à 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. Ces autorisations sont héritées tout au long de la hiérarchie.

Règles de hiérarchie d’objets :

• 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 une identité sur un sous-nœud, la valeur héritée du parent pour cette identité ne s’applique pas au sous-nœud.
• Après avoir résolu la hiérarchie d’objets, Azure DevOps combine les affectations directes et de groupe applicables. Un Refus provenant d’un autre groupe dans l’étendue résultante peut toujours prévaloir sur une Autorisation.

Exemple :

• Refuser explicitement sur area-1 (nœud parent).
• Autoriser explicitement pour area-1/sub-area-1 (nœud enfant).
• Dans ce cas, l’utilisateur reçoit une autorisation Autoriser sur area-1/sub-area-1, qui remplace le refus hérité du nœud parent.

Pour comprendre pourquoi une autorisation est héritée, sélectionnez Pourquoi ? pour cette autorisation. Pour ouvrir une page Sécurité , consultez Afficher les autorisations.

Groupes de sécurité et appartenance

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

Lorsque vous créez une organisation, une collection ou un projet, Azure DevOps crée un ensemble de groupes de sécurité par défaut et attribue automatiquement des autorisations par défaut à ces groupes. Vous définissez d’autres groupes de sécurité à l’aide des actions suivantes :

• Création de 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)
• Ajout d’une équipe, qui crée un groupe de sécurité d’équipe

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é le 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’un accès pour gérer Azure Test Plans nécessitent des plans de base + test ou un avantage d’abonnement Visual Studio applicable.

Ajoutez des utilisateurs qui gèrent les fonctionnalités au niveau du projet au groupe Administrateurs de projet . Ces fonctionnalités incluent les équipes, les chemins de zone et d’itération, les référentiels, les hooks de service ainsi que les points de terminaison de service.

Ajoutez des utilisateurs qui gèrent les fonctionnalités au niveau de l’organisation ou du regroupement au groupe Administrateurs de regroupement de projets . Ces fonctionnalités incluent des projets, des stratégies, des processus, des stratégies de rétention, des pools d’agents et de déploiement et des extensions. 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 des licences et du rôle de l'utilisateur, les administrateurs attribuent le niveau d'accès Stakeholder, Basic, Basic + Test Plans ou le niveau d'accès correspondant à un abonnement Visual Studio.

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 sont basées sur l’objet, le projet, la collection ou le niveau du serveur auquel vous ajoutez des groupes.

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.

Groupes d’utilisateurs valides

Lorsque vous ajoutez des comptes d’utilisateur directement à un groupe de sécurité, les utilisateurs font automatiquement partie de l’un des groupes d’utilisateurs valides suivants.

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.

Pour accéder aux ressources de projet, un utilisateur a besoin d’afficher les informations au niveau du projet et toutes les autorisations requises pour la ressource spécifique. Les autorisations de chemin d’accès de zone contrôlent l’accès aux éléments de travail et aux artefacts de test au sein d’un projet ; ils ne contrôlent pas si un utilisateur peut accéder au projet. Ne modifiez pas les autorisations par défaut pour un groupe Utilisateurs valides. Refuser Afficher les informations au niveau du projet, Afficher les informations au niveau de la collection ou Afficher les informations au niveau de l’instance pour l’un de ces groupes peut empêcher tous ses membres d’accéder au niveau correspondant.

Autorisations basées sur les rôles

Avec des autorisations basées sur des rôles, vous attribuez des comptes d’utilisateur ou des groupes de sécurité à un rôle, et chaque rôle dispose d’une ou plusieurs autorisations. Les ressources suivantes prennent en charge les autorisations basées sur les rôles :

• Rôles de sécurité pour les flux d’artefacts ou de paquets
• Rôle de gestionnaire des extensions de la Place de marché
• Rôles de sécurité de pipeline
• Rôle d’administrateur d’équipe

Pour plus d'informations, voir À propos des rôles de sécurité du pipeline.

Les membres des groupes Administrateurs de projet ou Administrateurs de regroupement de projets gèrent tous les outils d’équipe pour toutes les équipes.

Fonctionnalités d'aperçu

Les fonctionnalités en préversion fournissent un accès anticipé aux fonctionnalités avant qu’elles ne soient généralement disponibles. Les utilisateurs peuvent gérer les fonctionnalités en préversion proposées au niveau de l’utilisateur. Les membres du groupe Administrateurs de collections Project peuvent gérer les fonctionnalités d’aperçu au niveau de l’organisation dans Azure DevOps Services et les fonctionnalités d’aperçu au niveau du regroupement dans Azure DevOps Server. Pour plus d’informations, consultez Gérer ou activer des fonctionnalités.

Étape suivante

Contenu connexe