Fichiers secrets validés

Qu'est-ce que Fichiers secrets validés?

Le codage en dur d'un secret dans la source est un problème. En commettre un dossier entier en est une autre. Un référentiel sans .gitignore suit les fichiers .env, les clés privées et le compte de service JSON depuis la première validation, et une fois qu'un fichier est suivi, il appartient à l'historique, donc chaque clone en porte une copie. Vous clonerez un référentiel public, lirez un .env validé et atteindrez un environnement de test en direct. Ensuite, vous supprimerez le suivi des fichiers avec git rm --cached, ferez pivoter chaque clé exposée, ajouterez un .gitignore et installerez un hook de pré-validation qui bloque les noms de fichiers secrets.

Ce que vous apprendrez dans Fichiers secrets validés

• Reconnaître qu'un .gitignore manquant ou incomplet permet à un fichier secret entier, un .env, une clé privée ou un JSON de compte de service, d'être validé et suivi dès la première validation
• Comprendre pourquoi chaque clone d'un dépôt public contient une copie d'un fichier secret suivi, de sorte que l'exposition ne peut pas être annulée en supprimant le fichier ultérieurement
• Faites la distinction entre la validation d'un FICHIER secret sous contrôle de version et le codage en dur d'un littéral secret dans le code source, et sachez que les deux doivent être tenus à l'écart du référentiel.
• Appliquez le nettoyage : supprimez les fichiers du suivi avec git rm --cached et faites pivoter les clés exposées, en traitant tout secret poussé comme compromis
• Empêchez la récidive avec un .gitignore qui couvre les fichiers secrets et un hook de pré-validation qui bloque les noms de fichiers secrets connus avant qu'ils ne soient validés.

Fichiers secrets validés — Étapes de la formation

1. Évaluez la cible

   Aujourd'hui, Bob cible Tavonn, une startup d'intégration de paiements qui publie une partie de son code de manière ouverte. Il commence par le référentiel public, évaluant ce que l'entreprise gère avant de chercher un moyen d'y accéder. Un dépôt public est un cadeau pour quelqu'un comme Bob : l'intégralité du projet, chaque fichier, téléchargeable en une seule commande.

2. Cloner le dépôt

   Bob clone le référentiel sur sa propre machine afin de pouvoir lire chaque fichier suivi, hors ligne et à son propre rythme. Quelles que soient les pistes du repo, cela dépend du clone. Si un fichier secret a déjà été enregistré, il se trouve dans la copie qu'il vient d'extraire.

3. Lister les fichiers suivis

   Bob répertorie tout ce que le référentiel suit. Il ne regarde pas ce qui se trouve sur le disque, il demande à git quels fichiers sont réellement sous contrôle de version, car ce sont ceux que transporte chaque clone.

4. Lire le dossier secret

   Bob ouvre le fichier d'environnement validé. C'est la différence entre cette fuite et une seule clé codée en dur : il ne s'agit pas d'une valeur collée dans une ligne de code, c'est tout un fichier de secrets sous contrôle de version. Tout ce dont le service a besoin pour fonctionner se trouve ici, en texte brut.

5. Atteindre l'environnement de préparation

   Une clé divulguée n'est qu'une théorie jusqu'à ce qu'elle ouvre quelque chose. Bob a déjà tous les éléments dont il a besoin du clone : le .env engagé lui a donné l'URL de base de l'API dans PUBLIC_API_URL et une clé en direct, et les routes qu'il a clonées dans src/routes/payments.js définissent le flux de paiement dans /v1/transactions . Il assemble la demande et transporte la clé dans un en-tête Autorisation comme le ferait un vrai client. Les points finaux n’ont jamais été un secret ; ils siègent dans la source publique. La clé était là, et le fichier validé lui en a remis une, le serveur n'a donc aucune raison de rejeter la demande.

6. Les données de paiement sont ouvertes

   Le serveur a fait confiance à la clé et a répondu. Bob lit les relevés de paiement de Tavonn depuis l'extérieur de l'entreprise, sans aucun compte personnel.

7. Contrôle des connaissances

   Vous venez de regarder un dépôt public remettre à un étranger les clés d'un environnement en direct. Verrouillez pourquoi.

8. L'alerte débarque

   Vous possédez le dépôt de services de paiement de Tavonn. Du jour au lendemain, le scanner secret de l'équipe de sécurité a signalé le référentiel public et vous a envoyé un e-mail. La conclusion est brutale : un .env validé avec des clés actives se trouve dans le dépôt public, et aucun .gitignore ne conserve des fichiers comme celui-ci.

9. Suivi, sans .gitignore

   Votre premier geste est de le constater par vous-même. Vous répertoriez ce que git suit dans le dépôt, et le voilà : le .env et la clé du compte de service sont sous contrôle de version, et aucun .gitignore n'est dans la liste. Un fichier présent sur le disque est une chose ; un fichier que git suit est validé, dans l'historique et dans chaque clone.

10. Découvrez les fichiers secrets

    Vous empêchez git de suivre les fichiers secrets avec git rm --cached , qui les supprime de l'index tout en les laissant sur le disque afin que le service puisse toujours s'exécuter localement. Vous validez et poussez cette modification, et les fichiers disparaissent du dépôt actuel. Cela ressemble à la solution. Ce n’est pas le cas, et l’étape suivante montre pourquoi.