Bonnes pratiques de sécurité

  • Article

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

Lorsque vous utilisez des informations et des données, en particulier dans une solution cloud comme Azure DevOps Services, la priorité de la sécurité doit toujours être votre principale préoccupation. Bien que Microsoft conserve la sécurité de l’infrastructure cloud sous-jacente, il est de votre responsabilité de configurer la sécurité dans Azure DevOps.

Bien que ce ne soit pas obligatoire, l’incorporation des meilleures pratiques lors de l’utilisation d’Azure DevOps peut améliorer votre expérience et la sécuriser. Nous avons compilé les meilleures pratiques suivantes qui visent à sécuriser votre environnement Azure DevOps :

Sécuriser l’environnement Azure DevOps

Suppression d’utilisateurs

  • Si votre organization utilise des comptes MSA, supprimez les utilisateurs inactifs directement du organization, car vous n’avez pas d’autre moyen d’empêcher l’accès. Dans ce cas, vous ne pouvez pas créer de requête pour les éléments de travail affectés au compte d’utilisateur supprimé. Pour plus d’informations, consultez Supprimer des utilisateurs d’Azure DevOps.
  • Si votre organisation est connectée à l’ID Microsoft Entra, vous pouvez désactiver ou supprimer le compte d’utilisateur Microsoft Entra et laisser votre compte d’utilisateur Azure DevOps actif. De cette façon, vous pouvez continuer à interroger l’historique des éléments de travail à l’aide de votre ID utilisateur Azure DevOps.
  • Révoquer les pats utilisateur.
  • Révoquez toutes les autorisations spéciales qui peuvent avoir été accordées à des comptes d’utilisateur individuels.
  • Réaffecter le travail des utilisateurs que vous supprimez aux membres de l’équipe actuelle.

Utiliser Microsoft Entra ID

Intégrez Azure DevOps à l’ID Microsoft Entra pour avoir un plan unique pour l’identité. La cohérence et une seule source faisant autorité renforcent la clarté et réduisent les risques de sécurité liés aux erreurs humaines et à la complexité de la configuration. La clé de la gouvernance de bout en bout consiste à avoir plusieurs attributions de rôles (avec différentes définitions de rôles et différentes étendues de ressources aux mêmes groupes Microsoft Entra). Sans ID Microsoft Entra, vous êtes uniquement responsable du contrôle de l’accès de l’organisation.

L’utilisation de l’ID Microsoft Entra vous permet également d’accéder à d’autres fonctionnalités de sécurité, telles que l’authentification multifacteur ou d’autres stratégies d’accès conditionnel.

Pour plus d’informations, consultez les articles suivants :

Passer en revue les événements d’audit

Une fois que vous avez une organisation Microsoft Entra soutenue, vous pouvez activer l’audit dans vos stratégies de sécurité. Passez régulièrement en revue les événements d’audit pour surveiller et réagir aux modèles d’utilisation inattendus par les administrateurs et d’autres utilisateurs.

Sécuriser votre réseau

Voici quelques façons de procéder :

  • Configurez une liste d’autorisation pour restreindre des adresses IP spécifiques.
  • Utilisez toujours le chiffrement.
  • Validez les certificats.
  • Implémentez des pare-feu d’applications web afin qu’ils puissent filtrer, surveiller et bloquer tout trafic web malveillant vers et depuis Azure DevOps.
  • Pour plus d’informations, consultez ces conseils sur les meilleures pratiques de gestion des applications

Autorisations étendues

Le système gère les autorisations à différents niveaux (individuel, collection, projet et objet) et les affecte à un ou plusieurs groupes intégrés par défaut.

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.
  • 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 pour sélectionner des tâches.
  • Désactivez « Autoriser les projets publics » dans les paramètres de stratégie de votre organization pour empêcher chaque utilisateur organization de créer un projet public. Azure DevOps Services vous permet de changer la visibilité de vos projets du public au privé, et inversement. Si les utilisateurs ne se sont pas connectés à votre organization, ils disposent d’un accès en lecture seule à vos projets publics. Si les utilisateurs se sont connectés, ils peuvent se voir accorder l’accès à des projets privés et y apporter toutes les modifications autorisées.
  • N’autorisez pas les utilisateurs à créer de nouveaux projets.

Accès invité externe

  • Bloquer entièrement l’accès invité externe en désactivant la stratégie « Autoriser l’envoi d’invitations à n’importe quel domaine ». C’est une bonne idée de le faire s’il n’y a pas besoin pour l’entreprise.
  • Utilisez un autre e-mail ou nom d’utilisateur principal (UPN) pour vos comptes personnels et professionnels, même s’il est autorisé. Cette action élimine le défi de lever l’ambiguïté entre vos comptes professionnels et personnels lorsque l’e-mail/UPN est identique.
  • Placez tous les utilisateurs invités externes dans un seul groupe Microsoft Entra et gérez les autorisations de ce groupe de manière appropriée. Vous pouvez facilement gérer et auditer de cette façon.
    • Supprimez les affectations directes afin 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 les règles sous l’onglet Règles de groupe de la page Utilisateurs. Indiquez si les modifications apportées à l’appartenance à un groupe dans l’ID Microsoft Entra peuvent affecter votre organisation. L’ID Microsoft Entra peut prendre jusqu’à 24 heures pour mettre à jour l’appartenance à un groupe dynamique. Toutes les 24 heures et chaque fois qu’une règle de groupe change, les règles sont automatiquement réévaluées dans le système.
  • 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

Consultez les recommandations suivantes pour l’attribution d’autorisations aux groupes de sécurité et aux 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

Vous pouvez modifier la configuration de votre organisation ou projet si vous disposez d’un accès à Project Collection Administration istrator et Project Administration istrator. Pour protéger l’accès à ces groupes d’administrateurs intégrés, vous devez disposer d’un accès juste-à-temps à l’aide d’un groupe Microsoft Entra Privileged Identity Management (PIM).

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

Assurez-vous que tout utilisateur disposant d’un accès élevé à l’aide d’un groupe PIM dispose également d’un accès standard à l’organisation, afin qu’il puisse afficher la page pour actualiser ses autorisations.

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

  • Vérifiez que les comptes de service n’ont aucun droit de connexion interactive.
  • Limitez les privilèges de compte de service au strict minimum nécessaire.
  • Utilisez une identité différente pour le compte de lecteur de rapport, si vous utilisez des comptes de domaine pour vos comptes de service. Pour plus d’informations, consultez Comptes de service et dépendances.
  • Utilisez des comptes locaux pour les comptes d’utilisateur, si vous installez un composant dans un groupe de travail. Pour plus d’informations, consultez Configuration requise du compte de service.
  • Utilisez les connexions de service lorsque cela est possible. Les connexions de service fournissent un mécanisme sécurisé pour se connecter à des services assortis sans avoir à passer directement des variables secrètes à la build. - Limitez ces connexions à l’endroit spécifique où elles doivent être utilisées et rien de plus.
  • Surveillez l’activité des comptes de service et créez un streaming d’audit. L’audit vous permet de détecter les connexions et les activités suspectes et d’y réagir.
  • Pour plus d’informations, consultez Types de connexion de service courants.

Connexions de service d’étendue

  • Étendue d’Azure Resource Manager et d’autres connexions de service uniquement aux ressources et aux groupes auxquels ils ont besoin d’accéder. Les connexions de service ne doivent pas avoir de droits de contributeur étendus sur l’ensemble de l’abonnement Azure.
  • Utilisez la fédération des identités de charge de travail pour vos connexions de service Azure Resource Manager (ARM). La fédération des identités de charge de travail vous permet de créer des connexions de service sans secret dans Azure Pipelines vers Azure.
  • Ne donnez pas aux utilisateurs des droits génériques ou généraux contributeur sur l’abonnement Azure.
  • N’utilisez pas de connexions de service Azure Classic, car il n’existe aucun moyen d’étendre les autorisations.
  • Assurez-vous que le groupe de ressources contient uniquement des Machines Virtuelles (machines virtuelles) ou des ressources auxquelles la build doit accéder.
  • Utilisez un compte de service d’équipe spécifique pour authentifier une connexion de service.
  • 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 qui vous permettent d’utiliser des jetons Microsoft Entra pour accéder aux ressources Azure DevOps. Ces jetons présentent moins de risques en cas de fuite par rapport aux PAT et présentent des avantages tels que la gestion facile des informations d’identification.

Utiliser les PAT avec parcimonie

Si possible, nous vous recommandons de toujours utiliser les services d’identité pour l’authentification au lieu des clés de chiffrement, car la gestion sécurisée des clés avec le code d’application est difficile et peut entraîner des erreurs telles que la publication accidentelle de clés d’accès sensibles dans des dépôts de code publics comme GitHub. Toutefois, si vous devez utiliser des jetons d’accès personnels (PAT), tenez compte des instructions suivantes :

  • Les PAT doivent toujours être limités à des rôles spécifiques.

  • Les PAT ne doivent pas fournir un accès global à plusieurs organisations.

  • Les PAT ne doivent pas accorder d’autorisations d’écriture ou de gestion sur les builds ou les versions.

  • Les PAT doivent avoir une date d’expiration et être gardés secrets, car ils sont aussi critiques que les mots de passe.

  • Les PAT ne doivent jamais être codés en dur dans le code d’application, même s’il est tentant de le faire pour simplifier le code.

  • Administration istrators doivent régulièrement auditer tous les PAT à l’aide de LES API REST et révoquent les éléments qui ne répondent pas aux critères ci-dessus.

  • Gardez vos PATs un secret. Vos jetons sont aussi critiques que les mots de passe.

  • Stockez vos jetons dans un endroit sûr.

  • Ne codez pas les jetons en dur dans les applications. Il peut être tentant de simplifier le code pour obtenir un jeton pendant une longue période et le stocker dans votre application, mais ne le faites pas.

  • Donnez aux jetons une date d’expiration.

  • 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 au moins un réviseur en dehors du demandeur d’origine. L’approbateur partage la co-propriété des modifications et doit être tenu également responsable de tout impact potentiel.
  • Exiger la réussite de la build CI. Cette exigence est utile pour établir la qualité du code de référence, via le linting du code, les tests unitaires et les case activée de sécurité, comme les analyses de virus et d’informations d’identification.
  • Assurez-vous que le demandeur de tirage d’origine ne peut pas approuver la modification.
  • Interdire l’achèvement d’une demande de tirage (Pull Request), même si certains réviseurs votent pour attendre ou rejeter.
  • Réinitialisez les votes du réviseur de code lorsque des modifications récentes sont poussées.
  • Verrouillez les pipelines de mise en production en les exécutant uniquement sur des branches de production spécifiques.
  • Activez « Appliquer settable au moment de la file d’attente pour les variables » dans les paramètres de pipeline de votre organization.
  • N’autorisez pas « Autoriser les utilisateurs à remplacer cette valeur lors de l’exécution de ce pipeline » pour les variables définies dans l’éditeur.

Agents

  • Accordez des autorisations sur le plus petit nombre possible de comptes.
  • Disposez du pare-feu le plus restrictif qui laisse vos agents utilisables.
  • Mettez à jour les pools régulièrement pour vous assurer que le parc de build n’exécute pas de code vulnérable qu’un acteur malveillant peut exploiter.
  • Utilisez un pool d’agents distinct pour les artefacts de génération qui sont expédiés ou déployés en production.
  • Segmentez le pool « sensible » des pools non sensibles et autorisez uniquement l’utilisation d’informations d’identification dans les définitions de build qui sont verrouillées sur ce pool.

Définitions

  • Gérez les définitions de pipeline avec YAML (Encore un autre langage de balisage). YAML est la méthode préférée pour la gestion des définitions de pipeline, car il fournit la traçabilité des modifications et peut suivre les instructions d’approbation.
  • Sécuriser la définition de pipeline Modifier l’accès au nombre minimal de comptes.

Entrée

  • Incluez des vérifications d’intégrité pour les variables dans les scripts de build. Un case activée sain d’esprit peut atténuer une attaque par injection de commandes via les variables settables.
  • Définissez aussi peu de variables de build que possible sur « Settable au moment de la mise en production ».

Tâches

  • Évitez les ressources extraites à distance, mais, si nécessaire, utilisez le contrôle de version et la vérification de hachage.
  • Ne consignez pas les secrets.
  • Ne stockez pas de secrets dans des variables de pipeline, utilisez Azure Key Vault. Analysez régulièrement vos pipelines de build pour vous assurer que les secrets ne sont pas stockés dans les variables de pipeline de build.
  • Ne laissez pas les utilisateurs exécuter des builds sur des branches ou des balises arbitraires sur des pipelines critiques pour la sécurité.
  • Désactivez l’héritage sur le pipeline, car les autorisations héritées sont larges et ne reflètent pas précisément vos besoins en matière d’autorisations.
  • Limitez les étendues d’autorisation de travail dans tous les cas.

Référentiels et branches

  • Définissez la stratégie « Exiger un nombre minimal de réviseurs » sur activé, afin que chaque demande de tirage soit examinée par au moins deux approbateurs.
  • Configurez des stratégies de sécurité spécifiques à chaque dépôt ou branche, au lieu d’un projet à l’échelle du projet. Les stratégies de sécurité réduisent les risques, appliquent les normes de gestion des modifications et améliorent la qualité du code de votre équipe.
  • Stockez des secrets de production dans un coffre de clés distinct et assurez-vous que l’accès n’est accordé qu’en fonction d’un besoin de savoir pour conserver les builds hors production distinctes.
  • Ne mélangez pas les environnements de test avec la production, y compris l’utilisation des informations d’identification.
  • Désactivez la duplication. Plus il y a de duplications, plus il est difficile de suivre la sécurité de chaque fourche. En outre, un utilisateur peut facilement dupliquer une copie d’un dépôt vers son propre compte privé.
  • Ne fournissez pas de secrets pour les builds fork.
  • Envisagez de déclencher manuellement des builds de duplication.
  • Utilisez des agents hébergés par Microsoft pour les builds de duplication.
  • Pour Git, case activée vos définitions de build de production dans le dépôt Git du projet, afin qu’elles puissent être analysées à la recherche d’informations d’identification.
  • Configurez un contrôle de branche case activée afin que seuls les pipelines en cours d’exécution dans le contexte de la production branche puissent utiliser le prod-connection.
  • 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

  • Désactivez l’authentification basée sur un jeton d’accès personnel (PAT) afin que le flux OAuth soit utilisé avec la connexion de service GitHub.
  • N’authentifiez jamais les connexions de service GitHub en tant qu’identité administrateur ou propriétaire d’un référentiel.
  • N’utilisez jamais un jeton d’accès personnel (PAT) GitHub complet pour authentifier les connexions de service GitHub.
  • N’utilisez pas de compte GitHub personnel en tant que connexion de service avec Azure DevOps.