À 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.
Note
Si des données sensibles se trouvent dans un fichier identifié comme étant un fichier binaire, vous devrez supprimer le fichier de l'historique, car vous ne pourrez pas le modifier pour supprimer ou remplacer les données.
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
Warning
Si vous exécutez git filter-repo
après avoir remisé (stash) des modifications, vous ne pourrez pas récupérer vos modifications avec d’autres commandes stash. Avant d’exécuter git filter-repo
, nous vous recommandons de déremiser les modifications que vous avez apportées. Pour déremiser le dernier ensemble de modifications que vous avez remisées, exécutez git stash show -p | git apply -R
. Pour plus d’informations, consultez Git Tools - Stashing and Cleaning (Outils Git - remiser et nettoyer).
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.
-
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 commandebrew install
.brew install git-filter-repo
Pour plus d’informations, consultez INSTALL.md dans le dépôt
newren/git-filter-repo
. -
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.
-
Accédez au répertoire de travail du dépôt.
cd YOUR-REPOSITORY
-
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.
-
-
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(-)
-
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.
-
L’outil
git filter-repo
supprime automatiquement vos dépôts distants configurés. Utilisez la commandegit remote set-url
pour restaurer vos dépôts distants, en remplaçantOWNER
etREPO
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
-
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)
-
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.
-
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 qui doit être supprimé. 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 ».
-
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.
-
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.
É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 .
etgit commit -a
dans la ligne de commande : utilisez plutôtgit add filename
etgit 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 quegit 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 »