Optimiser les permissions afin d’améliorer les performances

Azure DevOps Services

Les vérifications d’autorisation font partie de nombreuses opérations de Azure DevOps Services. À grande échelle, de nombreuses attributions d’autorisations explicites, exceptions au niveau des ressources et appartenances aux groupes peuvent ralentir l’évaluation et les mises à jour des autorisations. Les listes de contrôle d’accès volumineuses nécessitent également que le service récupère et résolve davantage de données et d’identités d’autorisation.

Utilisez les recommandations de cet article pour réduire la quantité de données d’autorisations traitées par Azure DevOps Services.

Limites souples de performance

Utilisez les limites suivantes comme cibles de planification pour les grandes organisations. Azure DevOps Services n'applique pas ces limites ou bloque les modifications d'autorisation qui les dépassent. Toutefois, le fait de les dépasser augmente le risque de requêtes d’autorisation plus lentes, d’évaluations plus lentes et de mises à jour de l’appartenance.

Une entrée de contrôle d’accès (ACE) stocke les autorisations attribuées à un utilisateur ou un groupe. Pour les groupes imbriqués, tenez compte de l’appartenance effective totale lors de l’utilisation des instructions de taille de groupe.

Pratiques recommandées

Attribution d’autorisations à des groupes

Utilisez des groupes de sécurité intégrés ou personnalisés Azure DevOps pour représenter des rôles, des équipes et des cohortes d’accès. L’attribution d’une autorisation à un groupe crée un ACE. L’attribution de la même autorisation directement à de nombreux utilisateurs crée un ACE pour chaque utilisateur.

• Préférez les groupes intégrés tels que lecteurs, contributeurs et administrateurs Project lorsque leurs autorisations correspondent à l’accès requis.
• Créez un groupe personnalisé lorsqu’un groupe intégré ne correspond pas à l’accès requis.
• Ne remplacez pas un groupe par des centaines ou des milliers d’attributions directes à des utilisateurs.

Utiliser l’étendue et l’héritage correspondants les plus larges

Définissez une autorisation une seule fois, au niveau du périmètre pris en charge le plus élevé qui correspond à l’accès requis. Laissez les ressources enfants hériter de l’autorisation et conserver l’héritage activé, sauf si une ressource enfant nécessite un accès différent.

Par exemple:

Évitez de définir des autorisations identiques séparément sur chaque référentiel, branche, pipeline ou autre ressource enfant. Pour les référentiels Git, les dépôts individuels héritent des autorisations de l’entrée de référentiels Git de niveau supérieur.

Désactivez l’héritage uniquement lorsqu’une ressource a besoin d’un accès différent de son parent. La désactivation de l’héritage sur de nombreuses ressources nécessite généralement des affectations plus explicites.

Utilisez « Deny » uniquement pour les exceptions

Accordez l’accès via un groupe et laissez les autorisations comme non définies pour les identités qui ne doivent pas recevoir l’octroi. Au lieu d’accorder un accès étendu, puis d’ajouter de nombreuses entrées Deny , créez un groupe avec les autorisations exactes requises.

Utilisez Refuser uniquement lorsque vous devez remplacer une autorisation héritée pour une exception spécifique. Une seule entrée Refuser n’est pas intrinsèquement un problème de performances. Toutefois, de nombreuses exceptions ajoutent des ACE et nécessitent souvent des attributions d’autorisations supplémentaires au niveau de l’objet.

Utiliser des groupes d’identités de taille appropriée

Utilisez des groupes qui s’alignent sur les exigences d’accès, telles qu’une unité commerciale, un projet, un produit ou une fonction de travail. Ni les groupes Entra ni les groupes Azure DevOps offrent de meilleures performances. Appliquez les mêmes instructions de taille et d’imbrication aux deux types de groupe.

• Évitez d’ajouter un groupe à l’échelle du locataire ou de l’entreprise, tel qu’un groupe Tous les employés .
• Évitez d’imbriquer ou de modifier fréquemment les structures de groupe lorsqu’un groupe plus simple fournit le même accès.
• Fractionnez un très grand groupe en cohortes d’accès plus petites lorsque ses membres ne nécessitent pas tous le même accès.
• Si chaque membre a besoin du même accès, assignez un groupe unique à un niveau parent hérité au lieu d’utiliser des affectations individuelles ou des groupes dupliqués.

Les groupes avec plus de 10 000 membres sont un risque de performances. L’imbrication, les changements fréquents d’appartenance et l’accès à de nombreuses ressources soumises à des autorisations peuvent accroître l’impact. Réduisez les appartenances inutiles et fractionnez le groupe en cohortes d’accès plus petites, le cas échéant.

Équilibrer les ressources entre les projets et les organisations

Évitez de concentrer des milliers de référentiels et la plupart des ressources protégées par autorisation dans un projet, tandis que d’autres projets ne contiennent que quelques-uns. Les opérations qui découvrent des ressources accessibles peuvent avoir besoin d’évaluer les autorisations sur l’ensemble entier.

Distribuez de grands ensembles de référentiels et d’autres ressources entre les projets avant l’accumulation d’un trop grand nombre de ressources dans un projet. Ne créez pas un projet par dépôt ; le nombre de projets présente également des limites de performances pratiques.

À l’échelle de l’entreprise extrême, plusieurs organisations plus petites peuvent effectuer mieux qu’une organisation qui contient la plupart des ressources d’entreprise et des données d’autorisation. Fractionnez les organisations le long des limites stables du produit ou de l’entreprise pour distribuer la charge des ressources et des autorisations. Utilisez cette approche uniquement lorsque l’avantage de mise à l’échelle dépasse la surcharge liée à la gestion des ressources dans des organisations distinctes.

Réduire les changements fréquents dans l’automatisation des autorisations

Si vous gérez des autorisations via des scripts, des API REST ou des workflows de configuration en tant que code :

• Appliquez uniquement les modifications requises pour atteindre l’état prévu. Ne supprimez pas et ne recréez pas les attributions d’autorisations inchangées à chaque exécution.
• Définissez des permissions au niveau d’une portée parente au lieu de générer des entrées équivalentes pour chaque ressource enfant.
• Effectuez les modifications par lots lorsque cela est pris en charge et suivez les bonnes pratiques de l’API REST d’Azure DevOps.
• Évitez les boucles de synchronisation des autorisations à haute fréquence.
• Évitez de créer et de supprimer régulièrement un grand nombre de projets ou de ressources autorisées.
• Supprimez les affectations explicites obsolètes pour réduire la liste de contrôle d’accès (ACL) et le volume ACE.

Voir aussi

• À propos des autorisations et des groupes de sécurité
• À propos des projets et de la mise à l’échelle de votre organisation
• Limites du suivi du travail, des processus et des projets
• bonnes pratiques relatives à l’API REST Azure DevOps