À 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

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.

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.

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

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.

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’utilisateurs directement à un groupe de sécurité, ils sont automatiquement ajoutés à 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.

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.

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

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

Articles connexes