Partager via

Modifier la connexion d’application et les stratégies de sécurité pour votre organisation

  • Article

Important

Azure DevOps ne prend pas en charge l’authentification d’autres informations d’identification. Si vous utilisez toujours d’autres informations d’identification, nous vous encourageons vivement à passer à une méthode d’authentification plus sécurisée.

Cet article explique comment gérer les stratégies de sécurité de votre organisation qui déterminent comment les applications peuvent accéder aux services et aux ressources de votre organisation. Vous pouvez accéder à la plupart de ces stratégies dans les paramètres de l’organisation.

Prérequis

Autorisations : être membre du groupe Administrateurs de collection de projets. Les propriétaires d’organisation sont automatiquement membres de ce groupe.

Gérer une stratégie

Pour modifier la connexion d’application, la sécurité et les stratégies utilisateur pour votre organisation, procédez comme suit.

  1. Connectez-vous à votre organisation (https://dev.azure.com/{yourorganization}).

  2. Sélectionnez Icône d’engrenage Paramètres de l’organisation.

    Capture d’écran du bouton Paramètres de l’organisation, page d’aperçu.

  3. Sélectionnez Stratégies, puis activez ou désactivez votre stratégie en fonction des besoins.

Capture d’écran de la sélection de la stratégie, puis activation ou désactivation.

Modifier les stratégies de connexion d’application

Pour permettre un accès transparent à votre organisation sans demander à plusieurs reprises les informations d’identification de l’utilisateur, les applications utilisent souvent les méthodes d’authentification suivantes :

  • OAuth : Générez des jetons pour accéder aux API REST pour Azure DevOps. Toutes les API REST acceptent des jetons OAuth, ce qui en fait la méthode d’intégration préférée par rapport aux jetons d’accès personnels (PAT). Les API de gestion des organisations, des profils et des PAT prennent uniquement en charge OAuth. Vous pouvez également utiliser des jetons OAuth avec l’ID Microsoft Entra pour fournir une authentification sécurisée et transparente pour les utilisateurs au sein de votre organisation.

  • SSH : Générez des clés de chiffrement à utiliser avec Linux, macOS et Windows exécutant Git pour Windows. Vous ne pouvez pas utiliser les gestionnaires d’informations d’identification Git ou les PAT pour l’authentification HTTPS avec SSH.

  • PATs : Générer des jetons pour :

    • Accès à des ressources ou activités spécifiques, telles que des builds ou des éléments de travail.
    • Les clients tels que Xcode et NuGet qui nécessitent des noms d’utilisateur et des mots de passe en tant qu’informations d’identification de base et ne prennent pas en charge les fonctionnalités de compte Microsoft Entra, telles que l’authentification multifacteur.
    • Accès aux API REST pour Azure DevOps.

Par défaut, votre organisation autorise l’accès à toutes les méthodes d’authentification.

Vous pouvez limiter l’accès aux clés OAuth et SSH en désactivant ces stratégies de connexion d’application :

  • Application non-Microsoft via OAuth : activez les applications non-Microsoft pour accéder aux ressources de votre organisation via OAuth. Cette stratégie est désactivée par défaut pour toutes les nouvelles organisations. Si vous souhaitez accéder à des applications non-Microsoft, activez cette stratégie pour vous assurer que ces applications peuvent accéder aux ressources de votre organisation.
  • Authentification SSH : permettre aux applications de se connecter aux dépôts Git de votre organisation via SSH.

Lorsque vous refusez l’accès à une méthode d’authentification, aucune application ne peut accéder à votre organisation via cette méthode. Toute application qui avait précédemment accès rencontre des erreurs d’authentification et perd l’accès.

Pour supprimer l’accès aux PAT, révoquez-les.

Modifier les stratégies d’accès conditionnel

L’ID Microsoft Entra permet aux locataires de définir les utilisateurs qui peuvent accéder aux ressources Microsoft via leur fonctionnalité DE stratégie d’accès conditionnel (CAP). Les administrateurs de locataires peuvent définir des conditions que les utilisateurs doivent respecter pour obtenir l’accès. Par exemple, l’utilisateur doit :

  • Être membre d’un groupe de sécurité spécifique
  • Appartenir à un certain emplacement et/ou réseau
  • Utiliser un système d’exploitation spécifique
  • Utiliser un appareil activé dans un système de gestion

Selon les conditions remplies par l’utilisateur, vous pouvez ensuite exiger l’authentification multifacteur, définir des vérifications supplémentaires pour obtenir l’accès ou bloquer complètement l’accès.

Prise en charge de CAP sur Azure DevOps

Lorsque vous vous connectez au portail web d’une organisation microsoft Entra id-backed, l’ID Microsoft Entra effectue toujours la validation pour toutes les stratégies d’accès conditionnel définies par les administrateurs clients.

Azure DevOps peut également effectuer une validation CAP supplémentaire une fois que vous êtes connecté et que vous accédez à une organisation Microsoft Entra sauvegardée par ID :

  • Si la stratégie d’organisation « Activer la validation de stratégie d’accès conditionnel IP » est activée, nous vérifions les stratégies de délimitation IP sur des flux web et non interactifs, comme les flux clients non-Microsoft comme l’utilisation d’un pater avec des opérations git.
  • Les stratégies de connexion peuvent également être appliquées pour les PAT. L’utilisation de paTs pour effectuer des appels d’ID Microsoft Entra nécessite l’adhésion à toutes les stratégies de connexion définies. Par exemple, si une stratégie de connexion exige qu’un utilisateur se connecte tous les sept jours, vous devez également vous connecter tous les sept jours pour continuer à utiliser des PAT pour les demandes d’ID Microsoft Entra.
  • Si vous ne souhaitez pas qu’aucune autorité de certification ne soit appliquée à Azure DevOps, supprimez Azure DevOps en tant que ressource pour le CAP. Nous n’appliquons pas les fournisseurs de certification sur Azure DevOps sur une base organisation par organisation.

Nous prenons uniquement en charge les stratégies MFA sur les flux web. Pour les flux non interactifs, s’ils ne répondent pas à la stratégie d’accès conditionnel, l’utilisateur n’est pas invité à entrer l’authentification multifacteur et est bloqué à la place.

Conditions basées sur IP

Nous prenons en charge les stratégies d’accès conditionnel de délimitation IP pour les adresses IPv4 et IPv6. Si votre adresse IPv6 est bloquée, assurez-vous que l’administrateur client a configuré les adresses IP client pour autoriser votre adresse IPv6. En outre, envisagez d’inclure l’adresse Mappée IPv4 pour toute adresse IPv6 par défaut dans toutes les conditions CAP.

Si les utilisateurs accèdent à la page de connexion Microsoft Entra via une adresse IP différente de celle utilisée pour accéder aux ressources Azure DevOps (communes au tunneling VPN), vérifiez votre configuration VPN ou votre infrastructure réseau. Veillez à inclure toutes les adresses IP utilisées dans les adresses IP de votre administrateur client.