Configurer l’analyse des secrets

Les informations d’identification exposées dans les systèmes d’ingénierie offrent des opportunités facilement exploitables pour les attaquants. Pour vous défendre contre cette menace, GitHub Advanced Security pour Azure DevOps analyse les informations d’identification et d’autres contenus sensibles dans votre code source. La protection Push empêche également toute fuite d’informations d’identification. Vous avez besoin de GitHub Advanced Security pour Azure DevOps ou, si vous utilisez l’expérience autonome, GitHub Secret Protection pour Azure DevOps activé.

L’analyse des secrets de votre référentiel recherche tous les secrets qui peuvent déjà exister dans votre code source dans l’historique et la protection push empêche toute nouvelle exposition de secrets dans le code source.

GitHub Advanced Security pour Azure DevOps fonctionne avec Azure Repos. Pour utiliser GitHub Advanced Security avec des référentiels GitHub, consultez GitHub Advanced Security.

Conditions préalables

Pour plus d’informations sur les autorisations Advanced Security, consultez Gérer les autorisations Advanced Security.

À propos des alertes d’analyse des secrets

Lorsque vous activez Advanced Security ou Secret Protection spécifiquement, il analyse les dépôts pour les secrets émis par différents fournisseurs de services et génère des alertes d’analyse des secrets.

Si l’accès à une ressource nécessite des informations d’identification jumelées, l’analyse secrète crée une alerte uniquement lorsque les deux parties de la paire sont détectées dans le même fichier. Le jumelage garantit que les fuites les plus critiques ne sont pas masquées derrière des informations sur les fuites partielles. La création de paires permet également de réduire les faux positifs, car les deux éléments d’une paire doivent être utilisés ensemble pour accéder à la ressource du fournisseur.

L’onglet Sécurité avancée chez Repos>Advanced Security dans Azure DevOps est le hub pour afficher vos alertes de sécurité. Sélectionnez l’onglet Secrets pour afficher les alertes d’analyse des secrets. Vous pouvez filtrer par état et par type de secret. Accédez à une alerte pour plus d’informations, notamment des conseils de correction. Après avoir activé Advanced Security, une analyse démarre pour le référentiel sélectionné, y compris toutes les validations historiques. Au fil du temps, les alertes commencent à apparaître à mesure que l’analyse progresse.

Le changement de nom des branches n’affecte pas les résultats. Toutefois, l’affichage du nouveau nom peut prendre jusqu’à 24 heures.

Pour corriger les secrets exposés, invalidez les informations d’identification exposées et créez-en un à sa place. Le secret nouvellement créé doit ensuite être stocké en toute sécurité de manière à ne pas le renvoyer directement dans le code. Par exemple, le secret peut être stocké dans Azure Key Vault. La plupart des ressources ont à la fois des informations d’identification primaires et secondaires. La méthode permettant de restaurer des informations d’identification principales par rapport à des informations d’identification secondaires est identique, sauf indication contraire.

Gérer les alertes d’analyse des secrets

Affichage des alertes pour un dépôt

Sélectionnez l’onglet Secrets pour afficher toutes les alertes d’analyse des secrets.

Si Advanced Security a récemment été activé pour votre référentiel, vous pouvez voir une carte indiquant que Advanced Security analyse toujours votre référentiel.

Une fois l’analyse terminée, tous les résultats sont affichés. Une seule alerte est générée pour chaque information d’identification unique détectée, dans toutes les branches et l’historique de votre référentiel. Il n’existe aucun filtre de branche, car ils sont regroupés dans une alerte.

Les secrets non-fournisseurs sont visibles en sélectionnant « Autre » dans la liste déroulante de niveau de confiance sous l’onglet Analyse des secrets.

Détails de l’alerte

Lorsque vous accédez à une alerte, une vue d’alerte détaillée s’affiche et affiche plus de détails sur la recherche et fournit des conseils de correction spécifiques pour résoudre l’alerte.

Avec les secrets des non-fournisseurs, l’étiquette Confiance : autre apparaît également via le badge de gravité dans l’affichage des détails de l’alerte.

Correction des alertes d’analyse des secrets

Chaque secret a des étapes de correction uniques pour vous guider dans la façon de révoquer et de régénérer un nouveau secret à sa place. Le détail de l’alerte partage des étapes ou de la documentation spécifiques pour chaque alerte.

Une alerte d’analyse de secret reste ouverte jusqu’à ce qu’elle soit fermée. Pour attester qu’une alerte d’analyse de secret est corrigée :

1. Accédez à l’alerte que vous souhaitez fermer et sélectionnez l’alerte.
2. Sélectionnez la liste déroulante Fermer l’alerte.
3. Si ce n’est pas déjà fait, sélectionnez Correction.
4. Sélectionnez Fermer pour envoyer et fermer l’alerte.

Ignorer les alertes d’analyse des secrets

Pour ignorer une alerte, procédez comme suit :

1. Accédez à l’alerte que vous souhaitez fermer et sélectionnez-la.
2. Sélectionnez la liste déroulante Fermer l’alerte.
3. S’il n’est pas déjà sélectionné, sélectionnez Risque accepté ou Faux positif comme raison de fermeture.
4. Ajoutez un commentaire facultatif dans la zone de texte Commentaire.
5. Sélectionnez Fermer pour envoyer et fermer l’alerte.
6. L’état d’alerte passe d’Ouvert à Fermé et affiche le motif pour ignorer.

Vous pouvez ouvrir manuellement n’importe quelle alerte précédemment ignorée.

Sécuriser les secrets compromis

Une fois qu’un secret est validé dans un référentiel, le secret est compromis. Microsoft recommande les actions suivantes pour les secrets compromis :

• Pour un jeton d’accès personnel Azure DevOps compromis, supprimez le jeton compromis, créez un nouveau jeton et mettez à jour tous les services qui utilisent l’ancien jeton.
• Pour tous les autres secrets, vérifiez d’abord que le secret validé dans Azure Repos est valide. Si c’est le cas, créez un secret, mettez à jour tous les services qui utilisent l’ancien secret, puis supprimez l’ancien secret.
• Identifiez les actions effectuées par le jeton compromis sur les ressources de votre entreprise.

Lorsque vous mettez à jour un secret, stockez le nouveau secret en toute sécurité et assurez-vous qu’il n’est jamais stocké en texte brut. L’une des options consiste à utiliser Azure Key Vault ou d’autres solutions de gestion des secrets.

Protection push de secret

La protection Push vérifie les envois entrants pour les secrets à haut niveau de confiance et empêche le push de passer. Un message d’erreur affiche tous les secrets identifiés pour vous permettre de les supprimer ou de continuer à envoyer les secrets si nécessaire.

À propos des alertes de protection des poussées

Les alertes de protection push sont des alertes utilisateur qui sont signalées par la protection push. L’analyse des secrets en tant que protection Push analyse actuellement les référentiels des secrets émis par certains fournisseurs de services.

Si l’accès à une ressource nécessite des informations d’identification jumelées, l’analyse des secrets peut créer une alerte uniquement lorsque les deux parties de la paire sont détectées dans le même fichier. Le jumelage garantit que les fuites les plus critiques ne sont pas masquées derrière des informations sur les fuites partielles. La création de paires permet également de réduire les faux positifs, car les deux éléments d’une paire doivent être utilisés ensemble pour accéder à la ressource du fournisseur.

La protection push peut ne pas bloquer les versions antérieures de certains jetons, car ces jetons peuvent générer un nombre plus élevé de faux positifs que leur version la plus récente. La protection Push peut également ne pas bloquer les jetons hérités. Pour les jetons tels que les clés de stockage Azure, Advanced Security prend uniquement en charge les jetons récemment créés, et non les jetons qui correspondent aux modèles hérités.

Protection push à partir de la ligne de commande

La protection push est intégrée en mode natif dans Azure DevOps Git. Si vos validations contiennent un secret identifié, l’erreur suivante indique que votre envoi a été rejeté.

Protection push à partir de l’interface web

La protection Push fonctionne également à partir de l’interface web. Si un secret est identifié dans une validation, le bloc d’erreur suivant s’affiche, ce qui vous empêche d’envoyer (push) vos modifications :

Que faire si votre envoi a été bloqué

La protection push bloque les secrets trouvés dans des fichiers texte bruts qui sont généralement (mais pas limités à) des fichiers texte tels que le code source ou les fichiers de configuration JSON. Ces secrets sont stockés en texte brut. Si un acteur incorrect accède aux fichiers et qu’il est publié dans un référentiel public, les secrets sont utilisables par toute personne.

Supprimez le secret du fichier marqué, puis supprimez le secret de l'historique des commits. Si le secret marqué est un espace réservé ou un exemple de secret, mettez à jour le faux secret pour placer la chaîne Placeholder devant le faux secret.

Si le secret a été ajouté à votre commit précédent immédiat, modifiez le commit et créez-en un nouveau :

1. Supprimez le secret de votre code.
2. Validez les modifications à l’aide de git commit --amend
3. Envoyez à nouveau vos modifications.

Si le secret a été ajouté plus loin dans l’historique, modifiez vos commits à l’aide d’une nouvelle base interactive :

1. Utilisez git log pour déterminer le commit que vous avez validé pour la première fois le secret.
2. Effectuez un rebasement interactif : git rebase -i [commit ID before credential introduction]~1
3. Identifiez votre validation à modifier en passant pick à edit sur la première ligne du texte qui apparaît dans l’éditeur.
4. Supprimez le secret de votre code.
5. Validez la modification avec git commit --amend.
6. Terminez la relocalisation en exécutant git rebase --continue.

Envoyer un secret bloqué

Ne contournez pas les secrets marqués d’un indicateur, car cela peut mettre en danger la sécurité de votre entreprise. Si vous vérifiez qu’un secret identifié n’est pas un faux positif, supprimez le secret de l’historique de votre branche entière avant de tenter de pousser à nouveau vos modifications.

Si vous pensez qu’un secret bloqué est un faux positif ou sûr à envoyer, vous pouvez contourner la protection push. Incluez la chaîne skip-secret-scanning:true dans votre message de validation. Même si vous contournez la protection Push, une alerte d’analyse des secrets est générée dans l’expérience utilisateur de l’alerte une fois que le secret est poussé.

À propos des vérifications de validité

Les vérifications de validité des secrets vous aident à hiérarchiser les alertes en indiquant si un secret détecté est toujours utilisable. Pour les types de secrets pris en charge, GitHub Advanced Security pour Azure DevOps demande automatiquement au fournisseur émettrice si les informations d’identification sont actives, aucune bascule de fonctionnalité distincte n’est requise une fois l’analyse des secrets activée.

Le fait d’avoir l’offre groupée GitHub Advanced Security pour Azure DevOps ou la protection secrète active automatiquement les vérifications de validité.

Ce que vous obtenez

• Vérification automatique pour les types de secrets partenaires pris en charge (aucune configuration supplémentaire).
• État affiché dans la liste des alertes d’analyse des secrets et la fenêtre de détails.
• Filtrage par état de validation pour vous permettre de vous concentrer sur les secrets actifs.
• Vous pouvez éventuellement effectuer une vérification de validité « à la demande » pour le secret dans la vue d’alerte.

Significations de statut

Flux de travail classique

1. État de validation de filtre = Active pour exposer les alertes à risque le plus élevé.
2. Pour chaque secret actif, ouvrez l’alerte et suivez les étapes de recommandations et de correction fournies dans la vue d’alerte.
3. Utilisez la vérification à la demande après correction pour confirmer les modifications d’état.
4. Abordez les secrets inconnus : ensuite, réessayez la vérification à la demande ou traitez-les comme actifs si les données sont sensibles.
5. Fermez les alertes conformément à votre stratégie après avoir effectué les étapes de correction de l’alerte.

Vérification à la demande

Utilisez « vérifier le secret » (dans le détail de l’alerte) après avoir suivi ses recommandations et mesures correctives ou lorsqu’une tentative antérieure a retourné Inconnu. L’horodatage est mis à jour à l’achèvement.

Articles connexes

• Résoudre les problèmes d’analyse des secrets
• Découvrez les modèles d’analyse des secrets
• Configurer l’analyse du code
• Configurer l’analyse des dépendances
• En savoir plus sur GitHub Advanced Security pour Azure DevOps