Comment supprimer des fichiers sensibles d'un référentiel Git

Les fichiers sont indexés, le message de validation est écrit, les données sont envoyées au serveur ... Et du coup, vous avez envie de revenir en arrière. Le commit contient un fichier qui ne devrait pas être là. Lorsque cela se produit, il est temps d'aller sur un moteur de recherche.



Chaque développeur a en même temps enregistré des fichiers contenant des informations confidentielles dans le référentiel public par erreur. Comment faire face à un tel problème? Comment s'assurer que rien de tel ne se reproduira?



Dans cet article, je vais vous dire quoi faire si un fichier entre accidentellement dans le référentiel qui n'a absolument rien à y faire. Ici, je vais fournir des commandes Git qui vous permettront de corriger l'historique, et partager quelques recommandations pour organiser le travail en toute sécurité avec des informations confidentielles.

Suppression de fichiers sensibles du référentiel Git ( grande image )

Minimiser les dommages

Ainsi, vous avez accidentellement commis un fichier contenant des informations confidentielles. Appelons ce fichier .env. Immédiatement après cela, vous devez vous poser quelques questions:

• Le commit a-t-il été poussé vers le référentiel distant?
• Le référentiel distant est-il accessible au public?

▍Commit n'a pas encore été envoyé au référentiel distant

Si vous n'avez pas encore envoyé de commit au référentiel, alors, en général, la situation qui s'est produite ne pose aucune menace. Pour tout réparer, il vous suffit de revenir au commit précédent:

git reset HEAD^ --soft

Les fichiers resteront dans la copie de travail du référentiel, vous pouvez apporter les modifications nécessaires au projet.



Si vous souhaitez conserver le commit et qu'il vous suffit d'en supprimer certains fichiers, procédez comme suit:

git rm .env --cached
git commit --amend

Ce paramètre --amendne peut être utilisé qu'avec le commit le plus récent. Si vous en avez ajouté quelques autres après un échec de validation, utilisez cette commande:

git rebase -i HEAD~{    ?}

Cela corrigera le mauvais commit et vous aidera à ne pas perdre les modifications apportées au projet par d'autres commits.

▍Commit a été envoyé au référentiel distant

Si vous avez déjà poussé un commit vers un référentiel distant, vous devez tout d'abord connaître la différence entre les référentiels publics et privés.



Si votre référentiel est privé et n'est pas accessible aux bots ou aux personnes en qui vous n'avez pas confiance, vous pouvez simplement modifier le dernier commit en utilisant quelques commandes ci-dessus.



Si vous avez poussé d'autres commits dans le référentiel après un commit problématique, cela ne vous empêchera pas de supprimer les fichiers sensibles de votre historique Git à l'aide de la commande git filter-branch ou de l'outil BFG Repo-Cleaner .



Voici un exemple d'utilisation git filter-branch:

git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --all

Mais en faisant cela, gardez à l'esprit deux aspects importants de ces modifications apportées au référentiel:

• Git. , - , , PR, . .
• . , , . , , , , . , ID, , .

Dois-je créer de nouvelles clés secrètes si leurs versions actuelles se trouvent dans le référentiel public?

Si vous répondez brièvement à la question dans le titre, alors - c'est nécessaire. Si votre référentiel est accessible au public ou si, pour une raison quelconque, vous pensez qu'il ne s'agit pas d'un endroit pour stocker des données sensibles, vous devrez considérer les données confidentielles qui y sont entrées comme compromises.



Même si vous avez supprimé ces données du référentiel, vous ne pouvez rien faire avec les bots et les fourchettes de référentiel. La façon de procéder?

• Désactivez toutes les clés ou mots de passe. Cela doit être fait en premier. Après avoir désactivé les clés, les informations confidentielles qui sont devenues publiques deviennent inutiles.
• Personnalisez le fichier .gitignore. Prendre les .gitignoreenregistrements des fichiers contenant des informations sensibles sur Git ne surveillerait pas l'état de ces fichiers.
• Préparez un commit qui ne contient pas de fichiers sensibles.
• Soumettez les modifications au référentiel, fournissez au commit des explications sur la situation. N'essayez pas de cacher l'erreur. Tous les programmeurs travaillant sur le projet, vous y compris, apprécieront la présence dans le référentiel d'un commit avec une explication de la situation et une description de ce qui a été exactement corrigé avec ce commit.

Meilleures pratiques pour conserver les fichiers sensibles dans les projets qui utilisent Git pour le contrôle de version

Afin d'éviter les fuites d'informations confidentielles, vous devez respecter les recommandations suivantes.

▍ Stocker les données sensibles dans un fichier .env (ou autre fichier similaire)

Conservez les clés API et les informations similaires dans un seul fichier .env. Avec cette approche, si Git ne garde pas trace de l'état du fichier .env, en ajoutant une nouvelle clé à ce fichier, vous ne la pousserez pas accidentellement vers le référentiel.



Un autre avantage de cette approche est que vous aurez ainsi accès à toutes les clés via une variable globale process.

▍Utilisez des clés API si possible

Les clés API compromises sont faciles à désactiver et à recréer. Si possible, utilisez-les, et non quelque chose comme les connexions et les mots de passe.

▍Storez les clés API à l'aide de votre outil de construction

Les clés API sont généralement nécessaires lors de la création d'applications. Des outils de création comme Netlify vous permettent de conserver les clés dans des coffres-forts sécurisés. Ces clés sont automatiquement injectées dans l'application à l'aide d'une variable globale process.





Gestion des variables d'environnement

▍Ajoutez une entrée de fichier .env au fichier .gitignore

Empêchez Git de suivre les fichiers sensibles.

▍Préparez un fichier modèle .env.template

Avoir un tel fichier de modèle aide ceux qui travaillent sur le projet à ajouter des clés API au projet, éliminant ainsi le besoin de lire la documentation.

▍Ne modifiez pas l'historique Git dans les référentiels distants

Essayez de vous en tenir strictement à cette règle. Si vous avez suivi les instructions ci-dessus, vous n'aurez pas besoin de modifier votre historique Git.

Résultat

J'espère que mon matériel vous aidera à travailler en toute sécurité avec des données confidentielles.



Avez-vous déjà soumis quelque chose à un référentiel public qui ne devrait pas y aller?