Bonnes pratiques de sécurité

Article
08/14/2024

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

Supprimer les utilisateurs inactifs des comptes Microsoft (MSA) : supprimez directement les utilisateurs inactifs de votre organisation si vous utilisez des contrats MSA. Vous ne pouvez pas créer de requêtes pour les éléments de travail affectés à la suppression de comptes MSA.
Désactivez ou supprimez les comptes d’utilisateur Microsoft Entra : si vous êtes connecté à l’ID Microsoft Entra, désactivez ou supprimez le compte d’utilisateur Microsoft Entra tout en conservant le compte d’utilisateur Azure DevOps actif. Cette action 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 utilisateur existants pour garantir la gestion sécurisée de ces jetons d’authentification critiques.
Révoquer des autorisations spéciales accordées à des utilisateurs individuels : auditez et révoquez toutes les autorisations spéciales accordées aux utilisateurs individuels pour garantir l’alignement avec le principe du privilège minimum.
Réaffecter le travail des utilisateurs supprimés : avant de supprimer des utilisateurs, réaffectez leurs éléments de travail aux membres de l’équipe actuels pour distribuer efficacement la charge.

Utiliser Microsoft Entra ID

Établissez un système d’identité unifié : connectez Azure DevOps à Microsoft Entra ID pour créer un plan unique pour l’identité. Cette cohérence réduit la confusion et réduit les risques de sécurité à partir d’erreurs de configuration manuelles.
Implémentez une gouvernance affinée : utilisez l’ID Microsoft Entra pour attribuer différents rôles et autorisations à des groupes spécifiques dans différentes étendues de ressources. Cette action garantit l’accès contrôlé et s’aligne sur les meilleures pratiques de sécurité.
Améliorer les fonctionnalités de sécurité : activez d’autres fonctionnalités de sécurité avec l’ID Microsoft Entra, par exemple :
- Authentification multifacteur (MFA) : exiger plusieurs facteurs comme le mot de passe et la vérification par téléphone pour l’authentification utilisateur. Stratégies d’accès conditionnel : définissez des règles d’accès basées sur des conditions telles que l’emplacement, l’appareil ou le niveau de risque.

Pour plus d’informations, consultez les articles suivants :

Passer en revue les événements d’audit

Avec votre organisation connectée à Microsoft Entra, effectuez les tâches suivantes pour améliorer la sécurité et surveiller les modèles d’utilisation :

Activer l’audit : suivre et afficher les événements liés aux actions, autorisations et modifications des utilisateurs.
Passez en revue régulièrement les événements 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.

Configurer la liste verte IP : restreindre l’accès à des adresses IP spécifiques pour autoriser le trafic uniquement à partir de sources approuvées, ce qui réduit la surface d’attaque.
Utilisez le chiffrement : chiffrez toujours les données en transit et au repos. Sécuriser les canaux de communication à l’aide de protocoles tels que HTTPS.
Valider les certificats : vérifiez que les certificats sont valides et émis par les autorités approuvées lors de l’établissement de connexions.
Implémentez des pare-feu d’applications web (WAF) : filtrez, surveillez et bloquez le trafic web malveillant avec des wafs pour une couche supplémentaire de protection contre les attaques courantes.

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

Autorisations d’étendue

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, consultez la section sur l’héritage des autorisations

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

Autorisations au niveau du projet

Limiter l’accès aux projets et aux dépôts : réduisez le risque de fuite d’informations sensibles et de déploiement de code non sécurisé en limitant l’accès aux projets et référentiels. Utilisez des groupes de sécurité intégrés ou personnalisés pour gérer les autorisations.
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. Basculez la visibilité du projet du public au privé si nécessaire. Les utilisateurs qui ne se sont pas connectés ont un accès en lecture seule aux projets publics, tandis que les utilisateurs connectés peuvent accéder à des projets privés et apporter des modifications autorisées.
Restreindre la création de 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 s’il n’y a pas besoin pour l’entreprise.
Utilisez des e-mails distincts ou des UPN : utilisez différentes adresses e-mail ou noms d’utilisateur principaux (UPN) pour les comptes personnels et professionnels afin d’éliminer l’ambiguïté entre les comptes personnels et professionnels.
Regrouper les utilisateurs invités externes : placez tous les utilisateurs invités externes dans un seul groupe Microsoft Entra et 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.
Réévaluez régulièrement les règles : passez régulièrement en revue les règles sous l’onglet Règles de groupe de la page Utilisateurs. Envisagez les modifications apportées à l’appartenance à un groupe dans l’ID Microsoft Entra susceptibles d’affecter votre organisation. Microsoft Entra ID peut prendre jusqu’à 24 heures pour mettre à jour l’appartenance à un groupe dynamique, et 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. Pour plus d’informations, consultez Groupes d’utilisateurs valides.
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 . Par exemple, imaginez que vous disposez de deux groupes de sécurité dans votre projet Azure DevOps : développeurs et testeurs. Le groupe Développeurs dispose de l’autorisation de modifier les éléments de travail définis sur Autoriser. Mais assurez-vous que certains éléments de travail sensibles ne sont pas modifiés par n’importe qui, à l’exception de quelques personnes clés. Pour ce faire, créez un groupe de sécurité appelé Éditeurs d’éléments sensibles et définissez l’autorisation de modifier les éléments de travail à refuser pour ce groupe. Si un utilisateur est membre du groupe Développeurs et du groupe Éditeurs d’éléments sensibles, l’autorisation Refuser du groupe Éditeurs d’éléments sensibles est prioritaire sur l’autorisation Autoriser du groupe Développeurs. Par conséquent, cet utilisateur ne peut pas modifier les éléments de travail sensibles, même s’il dispose de l’autorisation Autoriser dans le groupe Développeurs . Ce comportement garantit que les autorisations de refus sont appliquées strictement, fournissant un niveau de sécurité et de contrôle plus élevé sur les actions sensibles au sein de votre environnement Azure DevOps.
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 indiquées comme Attribuer 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é.

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

Créez un groupe assignable de rôle dans l’ID Microsoft Entra.
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

Activez votre accès.
Actualisez vos autorisations dans Azure DevOps.
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

Créer des comptes de service à usage unique : chaque service doit avoir 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 de nommage et de documentation : utilisez des noms clairs et descriptifs pour les comptes de service et 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 pour isoler les autorisations et empêcher l’accès inutile.
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.
Tirer parti des connexions de service : utilisez les connexions de service chaque fois que cela est possible pour se connecter en toute sécurité 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 surveiller l’activité du compte de service.

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

Connexions de service d’étendue

Connexions de service d’étendue : limitez l’accès en définissant vos connexions de service Azure Resource Manager à des ressources et groupes spécifiques. Évitez d’accorder des droits de contributeur étendus sur l’ensemble de l’abonnement Azure.
Utiliser la fédération des identités de charge de travail : s’authentifier auprès des ressources Azure à l’aide d’OpenID Connect (OIDC) sans secrets. Créez automatiquement ou manuellement la fédération des identités de charge de travail si vous avez le rôle Propriétaire pour votre abonnement Azure, ne vous connectez pas aux environnements Azure Stack ou Azure US Government, ainsi que toutes les tâches d’extensions de la Place de marché que vous utilisez prennent en charge.
Groupes de ressources d’étendue : assurez-vous que les groupes de ressources contiennent uniquement les Machines Virtuelles (machines virtuelles) ou les ressources nécessaires au processus de génération.
Évitez les connexions de service classiques : optez pour les connexions de service Azure Resource Manager modernes au lieu d’une connexion classique, qui ne disposent pas d’options d’étendue.
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 pour maintenir la sécurité et le 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 et les identités managées
Utiliser les jetons d’accès personnels (PAT) avec parcimonie

Prendre en compte les principaux de service

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

Utiliser des 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. Configurez pour accéder aux ressources Azure, notamment Azure DevOps. Utile pour les applications nécessitant un accès et un contrôle spécifiques.
Utilisez des 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 pour la gestion transparente des détails de connexion.

Utiliser les PAT avec parcimonie

Étendue des PAT à des rôles spécifiques : attribuez uniquement les autorisations nécessaires pour des tâches spécifiques. Évitez d’accorder l’accès global à plusieurs organisations ou référentiels pour réduire 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 versions ou d’autres ressources critiques. La restriction de ces autorisations permet d’empêcher les actions involontaires susceptibles d’affecter vos pipelines ou déploiements.
Définissez les dates d’expiration et conservez le secret PAT : 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 PAT comme des mots de passe critiques, en les conservant confidentiels et en évitant le partage public ou le codage en dur dans le code de l’application.
Évitez les PAT de codage en dur dans le code d’application : au lieu d’incorporer des paTs directement dans votre code, utilisez des fichiers de configuration sécurisés ou des variables d’environnement pour stocker et récupérer dynamiquement des PAT. dynamiquement.
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, consultez Gérer les PAT avec des stratégies : pour les administrateurs et utiliser des paTs.

Sécuriser les artefacts Azure

Vérifiez que vous comprenez la différence entre les flux, les projets et les administrateurs de collection de projets. Pour plus d’informations, consultez Configurer les paramètres Azure Artifacts.
Définissez les autorisations de flux.

Sécuriser les Azure Boards

Configurez et personnalisez Azure Boards avant de personnaliser un processus.
Définir les autorisations de suivi du travail et de plan
Découvrir les autorisations par défaut et l’accès à Azure Boards
Définir les autorisations de requête

Sécuriser les pipelines Azure

Utilisez des modèles étendus.
Définir les autorisations des pipelines
Vue d’ensemble d’Azure Pipelines sécurisé.

Stratégies

Exiger des réviseurs externes : assurez-vous qu’au moins un réviseur en dehors du demandeur d’origine pour un processus de révision approfondi. L’approbateur partage la co-propriété des modifications et de la responsabilité pour tous les effets potentiels.
Exiger que la build CI passe : établissez une base de référence pour la qualité du code en exigeant que la build Intégration continue (CI) passe avant de fusionner une demande de tirage. Les vérifications CI incluent le linting du code, les tests unitaires et les analyses de sécurité.
Interdire l’auto-approbation : empêchez le demandeur de demande de tirage d’approuver ses propres modifications afin de garantir un processus d’examen non biaisé et d’éviter les conflits d’intérêts.
Interdire la saisie semi-automatique des demandes de tirage avec des votes « attendre » ou « rejeter » : empêchez la saisie semi-automatique même si certains réviseurs votent pour attendre ou rejeter, en encourageant l’adresse de tous les commentaires avant la fusion.
Réinitialiser les votes des réviseurs sur les modifications : réinitialisez les votes des réviseurs lorsque des modifications récentes sont envoyées à la demande de tirage pour garantir que les réviseurs réévaluent le code mis à jour.
Verrouiller les pipelines de mise en production : limitez les pipelines de mise en production à des branches spécifiques (généralement en production ou principale) pour éviter 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 empêcher 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 pour maintenir la cohérence et empêcher les modifications involontaires.

Agents

Accorder des autorisations avec parcimonie : limitez les autorisations au plus petit ensemble de comptes nécessaire pour réduire la surface d’attaque.
Configurez des pare-feu restrictifs pour les agents : configurez des pare-feu aussi restrictifs que possible tout en permettant aux agents de fonctionner, d’équilibrer la sécurité et la facilité d’utilisation.
Mettez régulièrement à jour les pools d’agents : maintenez votre parc d’agents à jour en mettant régulièrement à jour les agents pour vous assurer que le code vulnérable n’est pas en cours d’exécution, ce qui réduit le risque d’exploitation.
Utilisez un pool d’agents distinct pour les artefacts de production : isolez les artefacts de production à l’aide d’un pool d’agents distincts, ce qui empêche les déploiements accidentels de non branche de production es.
Segments de 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 : définissez des pipelines à l’aide de YAML (Encore un autre langage de balisage) pour améliorer la traçabilité et l’adhésion aux directives d’approbation et aux 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 pour réduire le risque de modifications accidentelles ou non autorisées.

Input

Incluez les vérifications des variables dans les scripts de génération : implémentez des vérifications au sein de vos scripts de build pour atténuer les attaques potentielles par injection de commandes par le biais de variables settables. Validez les valeurs d’entrée et empêchez les commandes involontaires ou malveillantes.
Limitez les variables de build « settable au moment de la mise en production » : réduisez le nombre de variables de build définies au moment de la mise en production pour réduire la surface d’attaque et simplifier 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 la journalisation des secrets : ne jamais enregistrer des informations sensibles, telles que des secrets ou des informations d’identification, dans vos journaux de build afin d’empêcher l’exposition involontaire et la compromission de 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 pour gérer et récupérer les secrets en toute sécurité.
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ésactiver l’héritage pour les autorisations de pipeline : les autorisations héritées peuvent être trop larges et peuvent ne pas refléter précisément vos besoins. Désactivez l’héritage et définissez explicitement les autorisations pour qu’elles s’alignent sur vos exigences de sécurité.
Limiter les étendues d’autorisation de travail : limitez toujours les étendues d’autorisation du 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 pour vous assurer que chaque demande de tirage reçoit des révisions d’au moins deux approbateurs, en favorisant une révision approfondie du code et la responsabilité.
Configurez des stratégies de sécurité spécifiques au référentiel : personnalisez les stratégies de sécurité à chaque référentiel ou branche au lieu de stratégies à l’échelle du projet afin de réduire les risques, d’appliquer des normes de gestion des modifications et d’améliorer 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 un coffre de clés Azure et limitez l’accès à une base de besoin de savoir pour maintenir la séparation des builds hors production.
Séparer les environnements de test de la production : évitez de mélanger les environnements de test avec la production pour vous assurer que les informations d’identification et les secrets ne sont pas utilisés dans des contextes de non-production.
Désactiver la duplication : la désactivation de la duplication permet de gérer la sécurité en empêchant la prolifération des duplications, ce qui facilite le suivi de la sécurité sur toutes les copies.
Évitez de fournir des secrets aux builds de fourche : évitez de partager des secrets avec des builds de fourche pour les garder confidentielles et non exposées aux fourches.
Envisagez de déclencher manuellement des builds de fourche : déclenchez manuellement des forks plutôt que d’autoriser les déclencheurs automatiques à mieux contrôler les contrôles de sécurité.
Utilisez des agents hébergés par Microsoft pour les builds de fourche : utilisez des agents hébergés par Microsoft pour les builds fork, car elles sont gérées et sécurisées.
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 référentiel Git de votre projet pour obtenir des informations d’identification ou des informations sensibles.
Configurez les vérifications de contrôle de branche pour le contexte de production : configurez les vérifications de contrôle de branche pour restreindre l’utilisation des connexions sensibles (par exemple, prod-connection) aux pipelines s’exécutant dans le contexte de l’branche de production, en garantissant une autorisation appropriée et en empêchant une 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 et optez pour le flux OAuth pour améliorer la sécurité et l’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 un administrateur ou un propriétaire de référentiels. Limitez les autorisations au niveau nécessaire.
Évitez les PAT GitHub à étendue complète : évitez d’utiliser un pat gitHub 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.

Partage via