Dépôts sécurisés et demandes de tirage

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

Sécurisez Azure Repos en combinant le contrôle d’accès, les stratégies de demande de tirage et les vérifications d’état sur vos branches les plus importantes. Cet article vous montre comment restreindre les modifications directes, exiger les réviseurs appropriés, appliquer les exigences d’élément de travail et de génération, et ajouter GitHub vérifications avancées de sécurité avant la fusion des demandes de tirage.

Menaces et contrôles

Utilisez les contrôles suivants ensemble pour réduire les risques de demande de tirage les plus courants.

Prerequisites

Avant de configurer une stratégie de branche :

• Vérifiez que le référentiel cible et la branche existent déjà.
• Déterminez quels groupes peuvent gérer les autorisations, contourner les stratégies et approuver les demandes de tirage.
• Si vous envisagez d’exiger la validation de build ou GitHub vérifications d’état Advanced Security, créez d’abord le pipeline de build.

Base de référence de sécurité pour la plupart des équipes

Pour une branche de production classique telle que main, commencez par cette ligne de base :

Étape 1 : Restreindre l’accès au référentiel et aux branches

Commencez par les autorisations. Les stratégies sont les plus efficaces quand seuls un petit ensemble d’utilisateurs peuvent les contourner.

Passer en revue les autorisations du référentiel

Utilisez des autorisations de référentiel pour contrôler qui peut lire, contribuer, administrer des paramètres ou contribuer aux demandes de tirage. Pour obtenir la référence d’autorisation détaillée, consultez Définir des autorisations de référentiel Git.

Utilisez le modèle suivant :

• Accordez aux contributeurs les autorisations dont ils ont besoin pour travailler dans les branches de fonctionnalités.
• Réservez l’administration du référentiel pour un petit groupe d’administration.
• Évitez les larges octrois d’autorisations de contournement de stratégie.

Limiter les autorisations de branche

Pour les branches protégées, passez en revue et limitez attentivement ces autorisations :

• Contourner les politiques lors de la finalisation des pull requests
• Contourner les stratégies lors du push
• Forcer le Push (réécrire l'historique, supprimer les branches et les balises)
• Modifier les stratégies
• Gérer les autorisations

Utilisez définir des autorisations de branche pour configurer ces paramètres.

Modèle recommandé pour main:

Étape 2 : Exiger une révision de demande de tirage forte

Exiger un nombre minimal de réviseurs

Utilisez Exiger un nombre minimal de réviseurs sur des branches importantes telles que main les branches de mise en production.

Paramètres recommandés :

• Réviseurs minimaux : 2 pour les branches partagées à valeur élevée
• Exiger au moins une approbation sur la dernière itération
• Autoriser les demandeurs à approuver leurs propres modifications : Off
• Interdire aux pusher les plus récents d’approuver leurs propres modifications : On lorsque vous souhaitez une séparation plus forte des tâches

Configurer la stratégie de réviseur minimale

az repos policy approver-count create \
  --blocking true \
  --branch main \
  --enabled true \
  --minimum-approver-count 2 \
  --creator-vote-counts false \
  --reset-on-source-push true \
  --repository-id <repository-id>

Vérifiez le résultat :

• La liste des stratégies de branche affiche la stratégie de réviseur activée.
• Les demandes de tirage dans la branche ne peuvent pas se terminer tant que le nombre d’approbations requis n’est pas présent.

Pour plus d’informations sur la stratégie, consultez Stratégies et paramètres de branche.

Inclure automatiquement des réviseurs pour les fichiers sensibles

Utilisez automatiquement les réviseurs inclus lorsque certains fichiers ou dossiers nécessitent l’approbation d’une personne ou d’une équipe spécifique.

Les candidats parfaits sont :

• déploiement et code d’infrastructure
• code d’authentification et d’autorisation
• dossiers respectant la conformité
• modèles de pipeline partagé

Configurer la stratégie de réviseurs inclus automatiquement

az repos policy required-reviewer create \
  --blocking true \
  --branch main \
  --enabled true \
  --message "Security review required for protected paths." \
  --path-filter "/.azure/*;/infra/*;/pipelines/*" \
  --repository-id <repository-id> \
  --required-reviewer-ids <reviewer-email-or-emails>

Vérifiez le résultat :

• Une demande de tirage qui modifie les fichiers correspondants ajoute automatiquement les réviseurs configurés.
• La demande de tirage ne peut pas se terminer tant que la stratégie de réviseur requise n’est pas satisfaite.

Pour plus d’informations, consultez Inclure automatiquement les réviseurs de code.

Étape 3 : Appliquer la traçabilité et la validation

Rechercher les éléments de travail liés

Activez l’activation de la vérification des éléments de travail liés lorsque votre équipe a besoin de modifier la traçabilité entre les demandes de tirage et le suivi du travail.

Configurer la stratégie d’éléments de travail liés

az repos policy work-item-linking create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id>

Vérifiez le résultat : les demandes de tirage sans éléments de travail liés affichent la stratégie comme non satisfaite.

Pour plus d’informations, consultez Rechercher les éléments de travail liés.

Validation de la build

Utilisez la validation de build pour exiger une exécution de pipeline réussie pour les demandes de tirage avant la fusion.

Paramètres recommandés pour les branches protégées :

• Déclencheur : automatique
• Exigence de stratégie : Required
• Expiration de la génération : choisissez une valeur qui correspond à la fréquence à laquelle la branche protégée change

Configurer la stratégie de validation de build

az repos policy build create \
  --blocking true \
  --branch main \
  --build-definition-id <pipeline-id> \
  --display-name "PR validation" \
  --enabled true \
  --manual-queue-only false \
  --queue-on-source-update-only true \
  --repository-id <repository-id> \
  --valid-duration 0

Vérifiez le résultat :

• L’ouverture ou la mise à jour d’une demande de tirage (pull request) met en file d’attente la build de validation configurée.
• La demande de tirage ne peut pas se terminer tant que la build requise n’est pas terminée.

Pour plus d’informations, consultez Validation de build.

Vérifier la résolution des commentaires

Utilisez La vérification de la résolution des commentaires pour vous assurer que les threads de révision sont résolus avant la fin de la demande de tirage.

Configurer la stratégie de résolution de commentaires

az repos policy comment-required create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id>

Vérifiez le résultat : les demandes de tirage avec des commentaires non résolus restent bloquées jusqu’à ce que les réviseurs ou les auteurs résolvent les threads.

Pour plus d’informations, consultez Rechercher la résolution des commentaires.

Limiter les types de fusion

Utilisez Limiter les types de fusion en tant que paramètre de gouvernance de l’historique des référentiels. Cette stratégie permet de normaliser la façon dont les validations de demande de tirage s’affichent après la fusion, mais ce n’est pas un contrôle de sécurité direct.

Choisissez une stratégie de fusion basée sur la façon dont votre équipe passe en revue, traces et historique des audits.

Exemple d’utilisation :

• Exiger des fusions de courge pour le travail de fonctionnalité de courte durée.
• Interdire la rebase ou la courge sur les branches où votre processus d’audit attend des validations de fusion.

Considérations relatives à l’audit et à la traçabilité :

• Squash crée un historique de branche cible plus propre, mais réduit plusieurs validations sources en une seule validation au moment de la fusion.
• Si votre modèle d’audit dépend de la conservation de la séquence de validation exacte d’une branche de fonctionnalité, préférez les stratégies de validation de fusion par rapport à la courge.
• Gardez votre stratégie cohérente avec la façon dont les développeurs inspectent et déboguent l’historique dans les demandes d’extraction et dans la branche cible.

exemple d’interface CLI Azure DevOps :

az repos policy merge-strategy create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id> \
  --allow-no-fast-forward true \
  --allow-rebase false \
  --allow-rebase-merge false \
  --allow-squash false

Pour plus d’informations, consultez Limiter les types de fusion.

Étape 4 : Ajouter GitHub vérifications d’état de sécurité avancée

GitHub vérifications d’état advanced security permettent d’empêcher la fusion des demandes de tirage lorsque de nouvelles vulnérabilités critiques ou de gravité élevée sont introduites.

Avant d’ajouter la stratégie de vérification d’état :

1. Activez GitHub Advanced Security sur le référentiel.
2. Configurez les tâches de pipeline Advanced Security requises.
3. Ajoutez une stratégie de validation de build pour la branche de demande d’extraction.
4. Wait for Processing: true Activez les tâches avancées de sécurité documentées.
5. Exécutez le pipeline avec succès au moins une fois afin que la vérification de l’état s’affiche dans la liste d’état à vérifier .

Commencez par AdvancedSecurity/NewHighAndCritical si le référentiel a déjà des alertes non résolues. Après avoir réduit le backlog, envisagez de passer à AdvancedSecurity/AllHighAndCritical.

Chemin d’accès du navigateur :

1. Ouvrez la branche cible sous Stratégies de branche.
2. Sous Vérifications d’état, sélectionnez +.
3. Définissez l’état surAdvancedSecurity/NewHighAndCritical.
4. Laissez les options avancées à leurs valeurs par défaut.
5. Enregistrez la stratégie.

Les vérifications d’état avancées de sécurité sont configurées à partir des vérifications d’état dans le navigateur après avoir activé l’analyse avancée de la sécurité et la validation de build pour le référentiel. Pour la configuration requise, consultez Configurer les vérifications d’état des demandes de tirage.

Vérifiez le résultat :

• Les demandes de tirage avec de nouveaux résultats élevés ou critiques montrent que la vérification de l’état a échoué.
• La stratégie de branche bloque l’achèvement jusqu’à ce que les résultats soient résolus ou que la stratégie soit rendue facultative.

Pour plus d’informations sur l’installation, consultez :

• Configurer les vérifications d’état des demandes de tirage (pull request)
• Vérifications de statut disponibles pour les pull requests

Exemples de plans de déploiement

Base de référence du référentiel à sensibilité inférieure

Si le référentiel a une sensibilité inférieure et que vous souhaitez un point de départ gérable :

1. Restreindre les autorisations de contournement de branche sur main.
2. Exiger au moins un ou deux réviseurs.
3. Activez les éléments de travail liés.
4. Ajoutez la validation de build.
5. Activez la résolution des commentaires.

Référentiel à haut niveau de confidentialité

Si le référentiel contient des ressources stratégiques de déploiement, d’identité ou de conformité :

1. Limitez les autorisations de contournement de stratégie aux administrateurs.
2. Exiger deux réviseurs sur main.
3. Ajoutez automatiquement des réviseurs pour les chemins protégés.
4. Exiger des éléments de travail liés.
5. Ajoutez la validation de build.
6. Ajoutez GitHub vérifications d'état Advanced Security si vous utilisez Azure DevOps Services.

Facultatif : Utiliser l’assistance IA pour passer en revue la configuration de la stratégie de branche

L’assistance ia est facultative. Vos autorisations de branche, stratégies et vérifications d’état appliquent des protections de référentiel que vous utilisiez ou non l’IA.

Vous pouvez utiliser ces invites pour passer en revue la configuration de la stratégie, identifier les lacunes et obtenir des recommandations de référence plus rapidement. Si vous configurez Azure DevOps serveur MCP, l’Assistant peut utiliser votre contexte Azure DevOps pour améliorer les réponses. Pour obtenir des conseils d’installation, consultez Activer l’assistance ia avec Azure DevOps serveur MCP.

Utilisez des invites comme suit pour commencer :

Validez toujours les commandes et recommandations générées par rapport aux autorisations de votre référentiel, aux paramètres de branche et à la documentation actuelle Azure DevOps avant de les appliquer.

Conseils de dépannage

Contenu connexe

• Définir les autorisations du dépôt Git
• Définir des autorisations de branche
• Stratégies et paramètres de branche
• Vérifications de statut disponibles pour les pull requests
• Configurer GitHub Advanced Security
• À propos des pull requests