Suppression de données sensibles dans un dépôt

À propos de la suppression de données sensibles dans un référentiel

Lorsque vous modifiez l'historique de votre référentiel à l'aide d'outils tels que git filter-repo ou BFG Repo-Cleaner, il est essentiel de comprendre les implications, en particulier concernant les demandes de tirage ouvertes et les données sensibles.

L’outil git filter-repo et BFG Repo-Cleaner réécrivent l’historique de votre dépôt, ce qui change les SHA pour les commits existants que vous modifiez et tous les commits dépendants. Des SHA de commits modifiés peuvent affecter les demandes de tirage dans votre dépôt. Nous vous recommandons de fusionner ou de fermer toutes les demandes de tirage ouvertes avant de supprimer des fichiers de votre dépôt.

Vous pouvez supprimer le fichier du commit le plus récent avec git rm. Pour obtenir des informations sur la suppression d’un fichier ajouté avec le commit le plus récent, consultez « À propos des fichiers volumineux sur GitHub ».

À propos de l’exposition aux données sensibles

Cet article vous explique comment effectuer des commits avec des données sensibles inaccessibles aux branches ou étiquettes dans votre référentiel sur votre instance GitHub Enterprise Server. Cependant, ces commits peuvent encore être accessibles ailleurs :

• Dans tous les clones ou duplications de votre référentiel
• Directement via leurs hachages SHA-1 dans les vues mises en cache sur GitHub Enterprise Server
• Par le biais de toutes les demandes de tirage qui les référencent

Vous ne pouvez pas supprimer les données sensibles de clones d’autres utilisateurs de votre référentiel, mais vous pouvez supprimer définitivement les vues en cache et les références aux données sensibles dans les demandes de tirage sur GitHub Enterprise Server en contactant le votre administrateur de site.

Quand vous poussez (push) un commit sur GitHub Enterprise Server, vous devez considérer toutes les données sensibles figurant dans le commit comme compromises. Si vous avez validé un mot de passe, vous devez le modifier. Si vous avez validé une clé, générez-en une autre.

Si le commit qui a introduit les données sensibles existe dans une duplication, elles continueront d'y être accessibles. Vous devrez vous coordonner avec les propriétaires des duplications, en leur demandant de supprimer les données sensibles ou de supprimer entièrement la duplication.

Tenez compte de ces limitations et de ces problématiques dans votre décision de réécrire l’historique de votre dépôt.

Supprimer définitivement un fichier de l’historique de votre dépôt

Vous pouvez supprimer définitivement un fichier de l’historique de votre dépôt à l’aide de l’outil git filter-repo ou de l’outil open source BFG Repo-Cleaner.

Utilisation de BFG

BFG Repo-Cleaner est un outil conçu et géré par la communauté open source. Il offre une alternative plus rapide et plus simple à git filter-repo pour la suppression de données indésirables.

Par exemple, pour supprimer votre fichier contenant des données sensibles et laisser intact le dernier commit, exécutez :

bfg --delete-files YOUR-FILE-WITH-SENSITIVE-DATA

Pour remplacer tout le texte listé dans passwords.txt où qu’il se trouve dans l’historique de votre dépôt, exécutez :

bfg --replace-text passwords.txt

Après la suppression des données sensibles, vous devez forcer la poussée de vos modifications sur GitHub Enterprise Server. La poussée forcée réécrit l’historique du dépôt, ce qui supprime les données sensibles de l’historique des commits. Si vous forcez la poussée, les commits sur lesquelles d’autres personnes ont basé leur travail peuvent être remplacés.

git push --force

Pour obtenir des instructions complètes d’utilisation et de téléchargement, consultez la documentation de BFG Repo-Cleaner.

Utilisation de git filter-repo

Pour illustrer le fonctionnement de git filter-repo, nous allons vous montrer comment supprimer votre fichier contenant des données sensibles de l’historique de votre dépôt et comment l’ajouter à .gitignore pour garantir qu’il n’est pas recommité accidentellement.

1. Installez la dernière version de l’outil git filter-repo. Vous pouvez installer git-filter-repo manuellement ou en utilisant un gestionnaire de package. Par exemple, pour installer l’outil avec HomeBrew, utilisez la commande brew install.

   brew install git-filter-repo
   

   Pour plus d’informations, consultez INSTALL.md dans le dépôt newren/git-filter-repo.

2. Si vous ne disposez pas déjà d’une copie locale de votre dépôt avec des données sensibles dans son historique, clonez le dépôt sur votre ordinateur local.

   $ git clone https://HOSTNAME/YOUR-USERNAME/YOUR-REPOSITORY
   > Initialized empty Git repository in /Users/YOUR-FILE-PATH/YOUR-REPOSITORY/.git/
   > remote: Counting objects: 1301, done.
   > remote: Compressing objects: 100% (769/769), done.
   > remote: Total 1301 (delta 724), reused 910 (delta 522)
   > Receiving objects: 100% (1301/1301), 164.39 KiB, done.
   > Resolving deltas: 100% (724/724), done.
   

3. Accédez au répertoire de travail du dépôt.

   cd YOUR-REPOSITORY
   

4. Exécutez la commande suivante en remplaçant PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA par le chemin du fichier que vous voulez supprimer, et pas seulement par son nom de fichier. Ces arguments vont :

   • Forcer Git à traiter, mais pas à extraire, l’historique complet de chaque branche et chaque étiquette

   • Supprimer le fichier spécifié ainsi que tous les commits générés en tant que résultat

   • Supprimer certaines configurations comme l’URL distante, stockées dans le fichier .git/config Vous pouvez sauvegarder ce fichier avant pour le restaurer ultérieurement.

   • Remplacer vos étiquettes existantes

       $ git filter-repo --invert-paths --path PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA
       Parsed 197 commits
       New history written in 0.11 seconds; now repacking/cleaning...
       Repacking your repo and cleaning out old unneeded objects
       Enumerating objects: 210, done.
       Counting objects: 100% (210/210), done.
       Delta compression using up to 12 threads
       Compressing objects: 100% (127/127), done.
       Writing objects: 100% (210/210), done.
       Building bitmaps: 100% (48/48), done.
       Total 210 (delta 98), reused 144 (delta 75), pack-reused 0
       Completely finished after 0.64 seconds.
     

     Important

     Si le fichier avec des données sensibles était utilisé dans d’autres chemins (en raison du fait qu’il a été déplacé ou renommé), vous devez également exécuter cette commande sur ces chemins.

5. Ajoutez votre fichier avec des données sensibles à .gitignore pour garantir que vous ne le recommitez pas accidentellement.

   $ echo "YOUR-FILE-WITH-SENSITIVE-DATA" >> .gitignore
   $ git add .gitignore
   $ git commit -m "Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore"
   > [main 051452f] Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore
   >  1 files changed, 1 insertions(+), 0 deletions(-)
   

6. Vérifiez bien que vous avez supprimé tout ce que vous vouliez de l’historique de votre dépôt et que toutes vos branches sont extraites.

7. L’outil git filter-repo supprime automatiquement vos dépôts distants configurés. Utilisez la commande git remote set-url pour restaurer vos dépôts distants, en remplaçant OWNER et REPO grâce aux détails de votre référentiel. Pour plus d’informations, consultez « Création de dépôt distants ».

   git remote add origin https://github.com/OWNER/REPOSITORY.git
   

8. Une fois satisfait de l’état de votre référentiel, et que vous avez défini le dépôt distant approprié, forcez les modifications locales à remplacer votre référentiel sur votre instance GitHub Enterprise Server ainsi que toutes les branches que vous avez poussées. Une poussée forcée est nécessaire pour supprimer les données sensibles de votre historique des commits.

   $ git push origin --force --all
   > Counting objects: 1074, done.
   > Delta compression using 2 threads.
   > Compressing objects: 100% (677/677), done.
   > Writing objects: 100% (1058/1058), 148.85 KiB, done.
   > Total 1058 (delta 590), reused 602 (delta 378)
   > To https://HOSTNAME/YOUR-USERNAME/YOUR-REPOSITORY.git
   >  + 48dc599...051452f main -> main (forced update)
   

9. Pour supprimer le fichier sensible de vos versions étiquetées, vous devez également effectuer un envoi (push) forcé sur vos étiquettes Git :

   $ git push origin --force --tags
   > Counting objects: 321, done.
   > Delta compression using up to 8 threads.
   > Compressing objects: 100% (166/166), done.
   > Writing objects: 100% (321/321), 331.74 KiB | 0 bytes/s, done.
   > Total 321 (delta 124), reused 269 (delta 108)
   > To https://HOSTNAME/YOUR-USERNAME/YOUR-REPOSITORY.git
   >  + 48dc599...051452f main -> main (forced update)
   

Suppression complète des données de GitHub

Après avoir utilisé l’outil BFG ou git filter-repo pour supprimer les données sensibles et poussé vos modifications sur GitHub Enterprise Server, vous devez effectuer quelques étapes supplémentaires pour supprimer entièrement les données de GitHub Enterprise Server.

1. Contactez votre administrateur de site, et demandez-leur de supprimer les vues en cache et les références aux données sensibles dans les demandes de tirage sur GitHub Enterprise Server. Indiquez le nom du dépôt et/ou un lien vers le commit que vous devez supprimer. Pour plus d’informations sur la façon dont les administrateurs de site peuvent supprimer des objets Git inaccessibles, consultez « Utilitaires de ligne de commande ». Pour plus d’informations sur la façon dont les administrateurs de site peuvent identifier les validations accessibles, consultez «  Identification des validations accessibles ».

2. Dites à vos collaborateurs de rebaser et non de fusionner les branches qu’ils ont créées à partir de l’ancien historique de votre dépôt (compromis). Un commit de fusion pourrait réintroduire une partie ou l’ensemble de l’histoire compromis que vous vous êtes donné la peine de supprimer.

3. Si vous avez utilisé git filter-repo, vous pouvez ignorer cette étape.

   Si vous avez utilisé l’outil BFG, après la réécriture, vous pouvez nettoyer les références dans votre dépôt local vers l’ancien historique pour le déréférencer et le soumettre au récupérateur de mémoire avec les commandes suivantes (à l’aide de Git 1.8.5 ou version ultérieure) :

   $ git reflog expire --expire=now --all
   $ git gc --prune=now
   > Counting objects: 2437, done.
   > Delta compression using up to 4 threads.
   > Compressing objects: 100% (1378/1378), done.
   > Writing objects: 100% (2437/2437), done.
   > Total 2437 (delta 1461), reused 1802 (delta 1048)
   

   Note

   Pour cela, vous pouvez également pousser votre historique filtré sur un référentiel nouveau ou vide, puis générer un nouveau clone à partir de GitHub Enterprise Server.

Identification des validations accessibles

Pour supprimer entièrement les données indésirables ou sensibles d’un référentiel, la validation qui a introduit les données doit d’abord être complètement non référencée dans les branches, les balises, les demandes de tirage et les duplications. Une référence unique n’importe où empêche le garbage collection de pouvoir vider complètement les données.

Vous pouvez rechercher des références existantes à l’aide des commandes suivantes lors de la connexion à l’appliance via SSH. Vous aurez besoin de SHA de la validation qui a introduit initialement les données sensibles.

ghe-repo OWNER/REPOSITORY -c 'git ref-contains COMMIT_SHA_NUMBER'
ghe-repo OWNER/REPOSITORY -c 'cd ../network.git && git ref-contains COMMIT_SHA_NUMBER'

Si l’une de ces commandes retourne des résultats, vous devez supprimer ces références avant que la validation puisse être correctement récupérée. La deuxième commande identifie les références qui existent dans les duplications du référentiel (si le référentiel n’a pas de fourche, vous pouvez ignorer son exécution).

• Les résultats commençant refs/heads/ par ou refs/tags/ indiquant des branches et des balises, qui contiennent toujours des références à la validation incriminée, suggèrent que le référentiel modifié n’a pas été entièrement nettoyé de la validation, ou qu’il n’a pas été envoyé par force.
• Résultats commençant par refs/pull/ ou refs/__gh__/pull indiquant des demandes de tirage qui font référence à la validation incriminé. Ces demandes de tirage doivent être supprimées pour permettre à la validation d’être récupérée par le garbage collect. Une demande de tirage (pull request) peut être supprimée dans le tableau de bord administrateur du site à https://HOSTNAME/stafftools/repositories/OWNER/REPOSITORY/PULL_REQUESTS/<PULL-REQUEST-NUMBER>, en remplaçant <PULL-REQUEST-NUMBER> par le numéro de demande de tirage.

Si des références sont trouvées dans des fourches, les résultats ressemblent, mais commencent par refs/remotes/NWO/. Pour identifier le dupliquer (fork) par nom, vous pouvez exécuter la commande suivante.

ghe-nwo NWO

La même procédure à l’aide de l’outil BFG ou git filter-repo peut être utilisée pour supprimer les données sensibles des fourches de référentiel. Vous pouvez également supprimer complètement les duplications et, si nécessaire, le dépôt peut être redimensionné une fois le nettoyage du référentiel racine terminé.

Une fois que vous avez supprimé les références de la validation, réexécutez les commandes pour double-vérifier.

S’il n’existe aucun résultat de l’une des commandes ref-contains, vous pouvez exécuter garbage collection avec l’indicateur --prune pour supprimer les validations non référencées en exécutant la commande suivante.

ghe-repo-gc -v --prune OWNER/REPOSITORY

Une fois que le garbage collection a correctement supprimé la validation, vous souhaiterez accéder au tableau de bord d’administration du site du référentiel sur https://HOSTNAME/stafftools/repositories/OWNER/REPOSITORY, sélectionnez Réseau, puis cliquez sur Invalider le cache Git pour supprimer les données en cache.

Éviter les commits accidentels à l’avenir

En empêchant les contributeurs d’effectuer des commits accidentels, vous contribuez à empêcher l’exposition des informations sensibles. Pour plus d’informations, consultez « Bonnes pratiques pour empêcher les fuites de données dans votre organisation ».

Vous pouvez éviter les commits accidentels en suivant quelques astuces simples :

• Utilisez un programme visuel comme GitHub Desktop ou gitk pour commiter les modifications. Généralement, les programmes visuels permettent de voir plus facilement les fichiers exacts qui seront ajoutés, supprimés et modifiés avec chaque commit.
• Évitez les commandes génériques git add . et git commit -a dans la ligne de commande : utilisez plutôt git add filename et git rm filename pour indexer les fichiers individuellement.
• Utilisez git add --interactive pour vérifier et indexer les modifications dans chaque fichier.
• Utilisez git diff --cached pour vérifier les modifications que vous avez indexées pour le commit. Il s’agit de la différence exacte que git commit produira tant que vous n’utilisez pas l’indicateur -a.
• Activez la protection Push pour votre référentiel afin de détecter et d’empêcher les envois qui contiennent des secrets codés en dur d’être validés dans votre codebase. Pour plus d’informations, consultez « À propos de la protection push ».

Pour aller plus loin

• Page man git filter-repo
• Pro Git : Git Tools - Rewriting History (Outils Git - Réécriture de l’historique)
• « À propos de l’analyse des secrets »