Partage via

Bonnes pratiques de sécurité

  • Article

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

Lorsque vous gérez des informations et des données, en particulier dans une solution cloud comme Azure DevOps Services, la sécurité doit être votre priorité absolue. Bien que Microsoft garantit la sécurité de l’infrastructure cloud sous-jacente, la configuration de la sécurité dans Azure DevOps est votre responsabilité.

Bien qu’il ne soit pas obligatoire, l’incorporation de bonnes pratiques peut améliorer considérablement votre expérience et renforcer la sécurité. Les recommandations suivantes sont conçues pour vous aider à maintenir un environnement Azure DevOps sécurisé.

Sécuriser votre environnement Azure DevOps

Utilisez les meilleures pratiques suivantes pour supprimer des utilisateurs, passer en revue les événements d’audit et intégrer à l’ID Microsoft Entra.

Supprimer des utilisateurs

  • Supprimez les utilisateurs inactifs des comptes MSA :
    • Si votre organisation utilise des comptes MSA, supprimez directement les utilisateurs inactifs de l’organisation.
    • Malheureusement, il n’existe aucun autre moyen d’empêcher l’accès pour ces utilisateurs.
    • N’oubliez pas que vous ne pouvez pas créer de requêtes pour les éléments de travail affectés à des comptes MSA supprimés.
  • Désactivez ou supprimez les comptes d’utilisateur Microsoft Entra :
    • Si votre organisation est connectée à l’ID Microsoft Entra, vous pouvez désactiver ou supprimer le compte d’utilisateur Microsoft Entra tout en conservant le compte d’utilisateur Azure DevOps actif.
    • Cette approche vous permet de continuer à interroger l’historique des éléments de travail à l’aide de votre ID utilisateur Azure DevOps.
  • Révoquer les PAT utilisateur :
    • Passez régulièrement en revue et révoquez tous les PAT d’utilisateurs existants.
    • Les PAT sont des jetons d’authentification critiques et la gestion sécurisée est essentielle.
  • Révoquer des autorisations spéciales accordées à des utilisateurs individuels :
    • Auditez et révoquez les autorisations spéciales qui ont été accordées à des comptes d’utilisateur individuels.
    • Assurez-vous que les autorisations s’alignent sur le principe du privilège minimum.
  • Réaffecter le travail des utilisateurs supprimés :
    • Avant de supprimer des utilisateurs, réaffectez tous les éléments de travail qu’ils géraient.
    • Distribuez la charge de travail entre les membres actuels de l’équipe.

Utiliser Microsoft Entra ID

  • Plan unique pour l’identité :
    • En connectant Azure DevOps à l’ID Microsoft Entra, vous établissez un système d’identité unifié.
    • La cohérence entre les services réduit la confusion et réduit les risques de sécurité résultant d’erreurs de configuration manuelles.
  • Gouvernance de bout en bout :
    • L’utilisation de l’ID Microsoft Entra vous permet d’implémenter une gouvernance affinée.
    • Attribuez différents rôles et autorisations à des groupes Microsoft Entra spécifiques dans différentes étendues de ressources.
    • Cette approche garantit un accès contrôlé et s’aligne sur les meilleures pratiques de sécurité.
  • Fonctionnalités de sécurité :
    • Microsoft Entra ID active des fonctionnalités de sécurité supplémentaires, telles que :
      • Authentification multifacteur (MFA) : améliorez l’authentification utilisateur en nécessitant plusieurs facteurs (par exemple, la vérification par mot de passe et par téléphone).
      • Stratégies d’accès conditionnel : définissez des règles d’accès en fonction de conditions (par exemple, emplacement, appareil ou niveau de risque).

Pour plus d’informations, consultez les articles suivants :

Passer en revue les événements d’audit

Une fois que votre organisation est soutenue par Microsoft Entra, effectuez les tâches suivantes pour améliorer la sécurité et surveiller les modèles d’utilisation :

  • Activer l’audit :
    • Dans vos stratégies de sécurité, activez l’audit.
    • L’audit permet de suivre et de journaliser les événements liés aux actions, autorisations et modifications des utilisateurs.
  • Passez régulièrement en revue les événements d’audit :
    • Passez régulièrement en revue le journal d’audit.
    • Recherchez des modèles d’utilisation inattendus, en particulier par les administrateurs et d’autres utilisateurs.

Sécuriser votre réseau

Les fonctions suivantes permettent d’améliorer la sécurité de votre réseau lorsque vous travaillez avec Azure DevOps.

  • Liste verte IP :
    • Configurez une liste verte pour restreindre l’accès à des adresses IP spécifiques.
    • Autorisez uniquement le trafic provenant de sources approuvées, ce qui réduit la surface d’attaque.
  • Chiffrement :
    • Utilisez toujours le chiffrement pour les données en transit et au repos.
    • Sécuriser les canaux de communication à l’aide de protocoles tels que HTTPS.
  • Validation du certificat :
    • Validez les certificats lors de l’établissement de connexions.
    • Vérifiez que les certificats sont valides et émis par les autorités approuvées.
  • Pare-feu d’applications web (WAF) :
    • Implémentez des fichiers WAF pour filtrer, surveiller et bloquer le trafic web malveillant.
    • Les wafs fournissent une couche supplémentaire de protection contre les attaques courantes.

Pour plus d’informations, consultez les meilleures pratiques de gestion des applications.

Autorisations étendues

Le système gère les autorisations à différents niveaux (individuels, collection, projet et objet) et les affecte à un ou plusieurs groupes intégrés par défaut. Pour améliorer la sécurité, procédez comme suit :

  • Fournir un accès au privilège minimum : donnez aux utilisateurs et aux services l’accès minimum nécessaire pour effectuer leurs fonctions métier.
  • Désactiver l’héritage :
    • Dans la mesure du possible, désactivez l’héritage.
    • L’héritage peut accorder par inadvertance l’accès ou les autorisations aux utilisateurs inattendus en raison de sa nature d’autorisation par défaut.
    • Pour plus d’informations, reportez-vous à la section sur l’héritage des autorisations

Pour plus d’informations sur les autorisations, consultez les articles suivants :

Autorisations au niveau du projet

  • Limitez l’accès aux projets et aux dépôts :
    • Pour réduire le risque de fuite d’informations sensibles et de déploiement de code non sécurisé en production, limitez l’accès aux projets et référentiels.
    • Utilisez les groupes de sécurité intégrés ou les groupes de sécurité personnalisés pour gérer les autorisations. Pour plus d’informations, consultez Accorder ou restreindre les autorisations à des tâches spécifiques.
  • Désactivez « Autoriser les projets publics » :
    • Dans les paramètres de stratégie de votre organisation, désactivez l’option permettant de créer des projets publics.
    • Azure DevOps Services vous permet de basculer la visibilité du projet du public au privé (et vice versa).
    • Les utilisateurs qui ne se sont pas connectés à votre organisation ont un accès en lecture seule aux projets publics.
    • Les utilisateurs connectés peuvent avoir accès à des projets privés et apporter des modifications autorisées.
  • Restreindre la création du projet :
    • Empêchez les utilisateurs de créer de nouveaux projets pour maintenir le contrôle sur votre environnement.

Accès invité externe

  • Bloquer l’accès invité externe :
    • Désactivez la stratégie « Autoriser l’envoi d’invitations à n’importe quel domaine » pour empêcher l’accès invité externe.
    • Envisagez cette étape s’il n’y a pas besoin d’entreprises pour les invités externes.
  • Utilisez un autre e-mail ou UPN pour vos comptes personnels et professionnels :
    • Même s’il est autorisé, utilisez des adresses e-mail distinctes ou des noms d’utilisateur principaux (UPN) pour les comptes personnels et professionnels.
    • Cette pratique élimine l’ambiguïté lors de l’ambiguïté entre vos comptes personnels et professionnels.
  • Regrouper les utilisateurs invités externes :
    • Placez tous les utilisateurs invités externes dans un seul groupe Microsoft Entra.
    • Gérez les autorisations pour ce groupe de manière appropriée.
    • Supprimez les affectations directes pour vous assurer que les règles de groupe s’appliquent à ces utilisateurs. Pour plus d’informations, consultez Ajouter une règle de groupe pour attribuer des niveaux d’accès.
    • Réévaluez régulièrement des règles sous l’onglet Règles de groupe de la page Utilisateurs. Envisagez les modifications apportées à l’appartenance au groupe dans l’ID Microsoft Entra susceptibles d’avoir un impact sur votre organisation. L’ID Microsoft Entra peut prendre jusqu’à 24 heures pour mettre à jour l’appartenance à un groupe dynamique. Les règles sont automatiquement réévaluées toutes les 24 heures et chaque fois qu’une règle de groupe change.

Pour plus d’informations, consultez les invités B2B dans l’ID Microsoft Entra.

Gérer les groupes de sécurité

Sécurité et groupes d’utilisateurs

Le tableau suivant présente des recommandations pour l’attribution d’autorisations à des groupes de sécurité et des groupes d’utilisateurs.

Faire Ne pas
Utilisez les groupes de sécurité Microsoft Entra ID, Active Directory ou Windows lorsque vous gérez un grand nombre d’utilisateurs. Ne modifiez pas les autorisations par défaut pour le groupe Utilisateurs valides du projet . Ce groupe peut accéder aux informations du projet et les afficher.
Lorsque vous ajoutez des équipes, tenez compte des autorisations que vous souhaitez attribuer aux membres de l’équipe qui doivent créer et modifier des chemins d’accès de zone, des chemins d’itération et des requêtes. N’ajoutez pas d’utilisateurs à plusieurs groupes de sécurité qui contiennent différents niveaux d’autorisation. Dans certains cas, un niveau d’autorisation Refuser peut remplacer un niveau d’autorisation Autoriser .
Lorsque vous ajoutez de nombreuses équipes, envisagez de créer un groupe personnalisé Administrateurs d’équipe dans lequel vous allouez un sous-ensemble des autorisations disponibles pour les administrateurs de projet. Ne modifiez pas les affectations par défaut effectuées aux groupes Utilisateurs valides du projet . Si vous supprimez ou définissez Afficher les informations de niveau instance sur Refuser pour l’un des groupes Utilisateurs valides du projet, aucun utilisateur du groupe ne peut accéder au projet, à la collection ou au déploiement sur lequel vous avez défini l’autorisation.
Envisagez d’accorder l’autorisation Contribuer aux dossiers de requête d’élément de travail aux utilisateurs ou groupes qui ont besoin de créer et de partager des requêtes d’élément de travail pour le projet. N’attribuez pas d’autorisations qui sont notées comme Affecter uniquement aux comptes de service aux comptes d’utilisateur.
Gardez les groupes aussi petits que possible. L’accès doit être restreint et les groupes doivent être fréquemment audités.
Tirez parti des rôles intégrés et attribuez par défaut le rôle de Contributeur aux développeurs. Les administrateurs sont affectés au groupe de sécurité Administrateurs de projet pour les autorisations élevées, ce qui leur permet de configurer des autorisations de sécurité.

Pour plus d’informations, consultez Groupes d’utilisateurs valides.

Accès juste-à-temps pour les groupes d’administration

Si vous disposez d’un accès Administrateur de collection de projets et Administrateur de projet, vous pouvez modifier la configuration de votre organisation ou projet. Pour renforcer la sécurité de ces groupes d’administrateurs intégrés, envisagez d’implémenter un accès juste-à-temps à l’aide d’un groupe Microsoft Entra Privileged Identity Management (PIM). Cette approche vous permet d’accorder des autorisations élevées uniquement si nécessaire, ce qui réduit le risque associé à l’accès permanent.

Configurer l’accès

  1. Créez un groupe assignable de rôle dans l’ID Microsoft Entra.
  2. Ajoutez votre groupe Microsoft Entra au groupe Azure DevOps.

Remarque

Lorsque vous configurez l’accès juste-à-temps à l’aide d’un groupe Microsoft Entra Privileged Identity Management (PIM), assurez-vous que tout utilisateur disposant d’un accès avec élévation de privilèges conserve également l’accès standard à l’organisation. De cette façon, ils peuvent afficher les pages nécessaires et actualiser leurs autorisations en fonction des besoins.

Utiliser l’accès

  1. Activez votre accès.
  2. Actualisez vos autorisations dans Azure DevOps.
  3. Effectuez l’action nécessitant un accès administrateur.

Remarque

Les utilisateurs disposent d’un accès élevé dans Azure DevOps pendant jusqu’à 1 heure après la désactivation de l’accès de leur groupe PIM.

Comptes de service d’étendue

  • Comprendre les comptes de service
  • Créez des comptes de service à usage unique :
    • Chaque service doit disposer de son compte dédié pour réduire les risques.
    • Évitez d’utiliser des comptes d’utilisateur standard en tant que comptes de service.
  • Suivez les conventions d’affectation de noms et de documentation :
    • Utilisez des noms clairs et descriptifs pour les comptes de service.
    • Documentez leur objectif et leurs services associés.
  • Identifiez et désactivez les comptes de service inutilisés :
    • Passez régulièrement en revue et identifiez les comptes qui ne sont plus utilisés.
    • Désactivez les comptes inutilisés avant d’envisager la suppression.
  • Restreindre les privilèges :
    • Limitez les privilèges de compte de service au minimum nécessaire.
    • Évitez les droits de connexion interactifs pour les comptes de service.
  • Utilisez des identités distinctes pour les lecteurs de rapports :
    • Si vous utilisez des comptes de domaine pour les comptes de service, utilisez une identité différente pour les lecteurs de rapports.
    • Isolez les autorisations pour empêcher l’accès inutile. Pour plus d’informations, consultez Comptes de service et dépendances.
  • Utilisez des comptes locaux pour les installations de groupe de travail :
    • Lors de l’installation de composants dans un groupe de travail, utilisez des comptes locaux pour les comptes d’utilisateur.
    • Évitez les comptes de domaine dans ce scénario. Pour plus d’informations, consultez Configuration requise du compte de service.
  • Tirez parti des connexions de service :
    • Utilisez les connexions de service dans la mesure du possible.
    • Ils offrent un moyen sécurisé de se connecter aux services sans passer directement des variables secrètes aux builds.
    • Limitez les connexions à des cas d’usage spécifiques.
  • Surveiller l’activité du compte de service :
    • Implémentez l’audit et créez des flux d’audit.

Pour plus d’informations, consultez Types de connexion de service courants.

Connexions de service d’étendue

  • Étendue des connexions de service Azure Resource Manager :
    • Pour limiter l’accès, limitez vos connexions de service à des ressources et groupes spécifiques. Évitez d’accorder des droits de contributeur étendus sur l’ensemble de l’abonnement Azure.
    • Utilisez la fédération des identités de charge de travail pour l’authentification. Cela permet des connexions de service sans secret dans Azure Pipelines.
  • Utilisez la fédération des identités de charge de travail :
    • La fédération des identités de charge de travail utilise OpenID Connect (OIDC) pour s’authentifier auprès des ressources Azure sans utiliser de secrets.
    • Vous pouvez créer automatiquement ou manuellement une fédération d’identité de charge de travail. Considérez cette approche si :
      • Vous disposez du rôle Propriétaire pour votre abonnement Azure.
      • Vous ne vous connectez pas à des environnements Azure Stack ou Azure US Government.
      • Toutes les tâches d’extensions de la Place de marché que vous utilisez prennent en charge la fédération des identités de charge de travail1.
  • Étendue du groupe de ressources :
    • Vérifiez que le groupe de ressources contient uniquement les Machines Virtuelles (machines virtuelles) ou les ressources nécessaires pour le processus de génération.
  • Évitez les connexions de service Azure Classic :
    • Les connexions de service classiques n’ont pas d’options d’étendue. Optez plutôt pour les connexions de service Azure Resource Manager modernes.
  • Utilisez des comptes de service d’équipe spécifiques à des fins :
    • Authentifiez les connexions de service à l’aide de comptes de service d’équipe spécifiques à des fins de gestion de la sécurité et du contrôle.

Pour plus d’informations, consultez Types de connexion de service courants.

Choisir la méthode d’authentification appropriée

Sélectionnez vos méthodes d’authentification à partir des sources suivantes :

Prendre en compte les principaux de service

Explorez des alternatives telles que les principaux de service et les identités managées :

  • Principaux de service :
    • Représenter des objets de sécurité au sein d’une application Microsoft Entra.
    • Définissez ce qu’une application peut faire dans un locataire donné.
    • Configurer pendant l’inscription de l’application dans le Portail Azure.
    • Configuré pour accéder aux ressources Azure, notamment Azure DevOps.
    • Utile pour les applications nécessitant un accès et un contrôle spécifiques.
  • Identités managées :
    • Similaire au principal de service d’une application.
    • Fournissez des identités pour les ressources Azure.
    • Autoriser les services prenant en charge l’authentification Microsoft Entra pour partager des informations d’identification.
    • Azure gère automatiquement la gestion et la rotation des informations d’identification.
    • Idéal lorsque vous souhaitez une gestion transparente des détails de connexion.

Utiliser les PAT avec parcimonie

  • Étendue des PAT à des rôles spécifiques :
    • Affectez uniquement les autorisations nécessaires pour des tâches spécifiques. Évitez d’accorder l’accès global à plusieurs organisations ou référentiels.
    • Les PAT exploratoires garantissent qu’ils disposent des privilèges minimaux nécessaires, ce qui réduit le risque d’utilisation abusive accidentelle.
  • Évitez d’écrire ou de gérer les autorisations sur les builds et les versions :
    • Les PAT ne doivent pas disposer d’autorisations d’écriture ou de gestion sur des builds, des mises en production ou d’autres ressources critiques.
    • La restriction de ces autorisations permet d’empêcher les actions involontaires susceptibles d’avoir un impact sur vos pipelines ou déploiements.
  • Définissez les dates d’expiration et conservez le secret PATs :
    • Définissez toujours une date d’expiration pour les PAT. Passez régulièrement en revue et renouvelez-les en fonction des besoins.
    • Traitez les TP comme critiques en tant que mots de passe. Conservez-les confidentielles et évitez de les partager publiquement ou en dur dans votre code d’application.
  • Évitez les PAT de codage en dur dans le code d’application :
    • Bien qu’il semble pratique, évitez d’incorporer des PAT directement dans votre code.
    • Utilisez plutôt des fichiers de configuration sécurisés ou des variables d’environnement pour stocker et récupérer dynamiquement des paTs.
  • Auditez et révoquez régulièrement les paT inutilisés :
    • Les administrateurs doivent examiner régulièrement tous les PAT à l’aide des API REST.
    • Révoquez les PAT qui ne sont plus nécessaires ou ne répondent pas aux critères recommandés.

Pour plus d’informations, case activée les articles suivants :

Sécuriser les artefacts Azure

Sécuriser les Azure Boards

Sécuriser les pipelines Azure

Stratégies

  • Exiger des réviseurs en dehors du demandeur d’origine :
    • Avoir au moins un réviseur en dehors du demandeur d’origine garantit un processus de révision plus approfondi.
    • L’approbateur partage la co-propriété des modifications et doit être tenu également responsable de tout impact potentiel.
  • Exiger la transmission de la build CI :
    • Exiger que la build Intégration continue (CI) passe avant de fusionner une demande de tirage établit une base de référence pour la qualité du code.
    • Les vérifications CI incluent le linting du code, les tests unitaires et les analyses de sécurité (par exemple, les vérifications de virus et d’informations d’identification).
  • Interdire l’auto-approbation par le demandeur d’origine :
    • Empêchez le demandeur de demande de tirage d’origine d’approuver ses propres modifications.
    • Cette action garantit un processus d’examen non biaisé et évite les conflits d’intérêts potentiels.
  • Interdire l’achèvement des demandes de tirage même avec des votes « wait » ou « reject » :
    • Même si certains réviseurs votent pour attendre ou rejeter, empêchez la saisie semi-automatique des demandes de tirage.
    • Cette action encourage l’adressage de tous les commentaires avant la fusion.
  • Réinitialisez les votes des réviseurs de code sur les modifications envoyées :
    • Lorsque les modifications récentes sont envoyées à la demande de tirage, réinitialisez les votes du réviseur.
    • Cette action garantit que les réviseurs réévaluent le code mis à jour.
  • Verrouillez les pipelines de mise en production vers des branche de production spécifiques :
    • Limitez les pipelines de mise en production à des branches spécifiques (généralement en production ou principale).
    • Évitez les déploiements accidentels d’autres branches.
  • Appliquer des variables settables au moment de la file d’attente :
    • Activez l’option « Appliquer settable au moment de la file d’attente » pour les variables de pipeline.
    • Cette action empêche les utilisateurs de remplacer les valeurs de variables pendant l’exécution du pipeline.
  • Interdire les remplacements de variables dans l’éditeur :
    • Pour les variables définies dans l’éditeur de pipeline, interdire les remplacements utilisateur.
    • Cette action maintient la cohérence et empêche les modifications involontaires.

Agents

  • Accordez des autorisations avec parcimonie :
    • Limitez les autorisations au plus petit ensemble de comptes nécessaire.
    • Évitez l’accès trop permissif, ce qui réduit la surface d’attaque.
  • Pare-feu restrictifs pour les agents utilisables :
    • Configurez les pare-feu pour qu’ils soient aussi restrictifs que possible tout en autorisant les agents à fonctionner.
    • Trouver un équilibre entre sécurité et facilité d’utilisation.
  • Mettez régulièrement à jour les pools d’agents :
    • Gardez votre flotte d’agents à jour en mettant régulièrement à jour les agents.
    • Cette action garantit que le code vulnérable n’est pas en cours d’exécution, ce qui réduit le risque d’exploitation.
  • Pool d’agents distinct pour les artefacts de production :
    • Utilisez un pool d’agents distinct pour les artefacts de build destinés à la production.
    • L’isolation des artefacts de production permet d’empêcher les déploiements accidentels de non-branche de production es.
  • Segmenter des pools sensibles :
    • Créez des pools distincts pour les charges de travail sensibles et non sensibles.
    • Autorisez uniquement les informations d’identification dans les définitions de build associées au pool approprié.

Définitions

  • Utilisez YAML pour les définitions de pipeline :
    • YAML (Yet Another Markup Language) est l’approche recommandée pour définir des pipelines.
    • Il offre une traçabilité pour les modifications, ce qui facilite le suivi des modifications au fil du temps.
    • En outre, les pipelines YAML peuvent respecter les directives d’approbation et les pratiques de contrôle de version.
  • Restreindre l’accès aux définitions de pipeline :
    • Limitez l’accès à la modification des définitions de pipeline aux comptes minimum nécessaires.
    • Ainsi, vous réduisez le risque de modifications accidentelles ou non autorisées.

Input

  • Incluez des vérifications d’intégrité pour les variables dans les scripts de génération :
    • Implémentez des contrôles d’intégrité dans vos scripts de build pour atténuer les attaques potentielles par injection de commandes via des variables settables.
    • Ces vérifications peuvent valider les valeurs d’entrée et empêcher les commandes involontaires ou malveillantes.
  • Limitez le nombre de variables de build « settable au moment de la mise en production » :
    • Définissez autant de variables de build que possible pour être « settable au moment de la mise en production ».
    • La réduction du nombre de ces variables réduit la surface d’attaque et simplifie la gestion de la configuration.

Tâches

  • Évitez les ressources extraites à distance :
    • Dans la mesure du possible, évitez d’extraire des ressources à partir d’URL externes pendant votre processus de génération.
    • Si des ressources distantes sont nécessaires, utilisez le contrôle de version et de hachage pour garantir l’intégrité.
  • Évitez de journaliser les secrets :
    • Ne consignez jamais les informations sensibles, telles que les secrets ou les informations d’identification, dans vos journaux de génération.
    • La journalisation des secrets peut les exposer involontairement et compromettre la sécurité.
  • Utilisez Azure Key Vault pour les secrets :
    • Au lieu de stocker des secrets directement dans des variables de pipeline, utilisez Azure Key Vault.
    • Key Vault offre un moyen sécurisé de gérer et de récupérer les secrets de manière centralisée.
  • Restreindre l’exécution des builds sur des branches ou des balises arbitraires :
    • Pour les pipelines critiques de sécurité, limitez les utilisateurs à exécuter des builds sur n’importe quelle branche ou étiquette.
    • Définissez des branches ou des balises autorisées spécifiques pour empêcher les exécutions accidentelles ou non autorisées.
  • Désactivez l’héritage pour les autorisations de pipeline :
    • Les autorisations héritées peuvent être trop larges et peuvent ne pas refléter avec précision vos besoins.
    • Désactivez l’héritage et définissez explicitement les autorisations pour qu’elles s’alignent sur vos exigences de sécurité.
  • Limitez les étendues d’autorisation de travail :
    • Limitez toujours les étendues d’autorisation de travail au minimum nécessaire.
    • Ajustez les autorisations en fonction des tâches spécifiques effectuées par chaque travail.

Référentiels et branches

  • Exiger un nombre minimal de réviseurs :
    • Activez la stratégie « Exiger un nombre minimal de réviseurs » pour vous assurer que chaque demande de tirage reçoit des révisions d’au moins deux approbateurs.
    • Cela favorise l’examen approfondi du code et la responsabilité.
  • Configurez des stratégies de sécurité spécifiques au référentiel :
    • Au lieu de stratégies à l’échelle du projet, personnalisez les stratégies de sécurité à chaque référentiel ou branche.
    • Les stratégies personnalisées réduisent les risques, appliquent les normes de gestion des modifications et améliorent la qualité du code.
  • Isoler les secrets de production dans un coffre de clés distinct :
    • Stockez les secrets de production séparément dans azure Key Vault.
    • Limitez l’accès à une base de besoin de savoir pour maintenir la séparation des builds hors production.
  • Séparez les environnements de test de la production :
    • Évitez de mélanger des environnements de test avec la production.
    • Vérifiez que les informations d’identification et les secrets ne sont pas utilisés dans des contextes hors production.
  • Désactiver l’écriture manuscrite :
    • La désactivation de la duplication manuscrite permet de gérer la sécurité.
    • Les fourches peuvent proliférer, ce qui complique le suivi de la sécurité sur toutes les copies.
  • Évitez de fournir des secrets aux builds de duplication :
    • Évitez de partager des secrets avec des builds forked.
    • Les secrets doivent rester confidentiels et ne doivent pas être exposés à des fourche.
  • Envisagez de déclencher manuellement des builds de duplication :
    • Déclenchez manuellement des forks plutôt que d’autoriser des déclencheurs automatiques.
    • Cela permet de mieux contrôler les contrôles de sécurité.
  • Utilisez les agents hébergés par Microsoft pour les builds de duplication :
    • Tirez parti des agents hébergés par Microsoft pour les builds forked.
    • Ces agents sont maintenus et sécurisés.
  • Analysez les définitions de build de production dans les référentiels Git :
    • Vérifiez régulièrement les définitions de build de production stockées dans le dépôt Git de votre projet.
    • Recherchez les informations d’identification ou les informations sensibles.
  • Configurer les vérifications de contrôle de branche pour le contexte de production :
    • Configurez les vérifications de contrôle de branche pour limiter l’utilisation des connexions sensibles (par exemple, prod-connection) aux pipelines s’exécutant dans le contexte de l’branche de production.
    • Cela garantit une autorisation appropriée et empêche toute mauvaise utilisation accidentelle.

Pour plus d’informations, consultez Autres considérations relatives à la sécurité.

Sécuriser les Azure Repos

Sécuriser les Azure Test Plans

Sécuriser les intégrations GitHub

  • Utilisez le flux OAuth au lieu de paTs :
    • Désactivez l’authentification basée sur le protocole PAT pour les connexions de service GitHub.
    • Optez pour le flux OAuth, qui offre une meilleure sécurité et intégration.
  • Évitez les identités d’administrateur ou de propriétaire :
    • N’authentifiez jamais les connexions de service GitHub à l’aide d’une identité qui est administrateur ou propriétaire d’un référentiel.
    • Limitez les autorisations au niveau nécessaire.
  • Évitez les PAT GitHub à étendue complète :
    • Évitez d’utiliser un protocole GitHub PAT complet pour authentifier les connexions de service.
    • Utilisez des jetons avec les autorisations minimales requises.
  • Évitez les comptes GitHub personnels en tant que connexions de service :
    • N’utilisez pas de comptes GitHub personnels en tant que connexions de service dans Azure DevOps.
    • Au lieu de cela, créez des comptes de service dédiés ou utilisez des comptes au niveau de l’organisation.