Toegezegde geheime bestanden

Wat is Toegezegde geheime bestanden?

Het hardcoderen van een geheim in de broncode is één probleem. Een heel bestand ervan vastleggen is iets anders. Een repository zonder .gitignore houdt .env-bestanden, privésleutels en serviceaccount-JSON bij vanaf de eerste commit, en zodra een bestand is bijgehouden, behoort het tot de geschiedenis, dus elke kloon heeft een kopie. U kloont een openbare repository, leest een vastgelegde .env en bereikt een live staging-omgeving. Vervolgens ontkoppel je de bestanden met git rm --cached, roteer je elke blootgestelde sleutel, voeg je een .gitignore toe, en installeer je een pre-commit hook die geheime bestandsnamen blokkeert.

Wat je leert in Toegezegde geheime bestanden

• Erken dat een ontbrekende of onvolledige .gitignore ervoor zorgt dat een heel geheim bestand, een .env, een privésleutel of een JSON van een serviceaccount, wordt vastgelegd en gevolgd vanaf de eerste vastlegging
• Begrijp waarom elke kloon van een openbare opslagplaats een kopie bevat van een bijgehouden geheim bestand, zodat de blootstelling niet ongedaan kan worden gemaakt door het bestand later te verwijderen
• Maak onderscheid tussen het vastleggen van een geheim BESTAND onder versiebeheer en het hardcoderen van een geheime letterlijke broncode, en weet dat beide buiten de repository moeten worden gehouden
• Pas de opruiming toe: verwijder de bestanden uit tracking met git rm --cached en roteer de blootgestelde sleutels, waarbij elk gepusht geheim als gecompromitteerd wordt behandeld
• Voorkom herhaling met een .gitignore die geheime bestanden afdekt, plus een pre-commit hook die bekende geheime bestandsnamen blokkeert voordat ze worden vastgelegd

Toegezegde geheime bestanden — Trainingsstappen

1. Maak het doel groter

   Vandaag richt Bob zich op Tavonn, een startup voor betalingsintegraties die een deel van zijn code openbaar verzendt. Hij begint bij de openbare repository en inventariseert wat het bedrijf beheert voordat hij op zoek gaat naar een manier om binnen te komen. Een openbare repository is een geschenk aan iemand als Bob: het hele project, elk bestand, downloadbaar in één opdracht.

2. Kloon de opslagplaats

   Bob kloont de repository naar zijn eigen machine, zodat hij elk bestand dat daarin wordt bijgehouden, offline en in zijn eigen tempo kan lezen. Wat de repo-tracks ook zijn, het komt met de kloon naar beneden. Als er ooit een geheim bestand is vastgelegd, staat het in de kopie die hij zojuist heeft opgehaald.

3. Maak een lijst van de bijgehouden bestanden

   Bob geeft een overzicht van alle tracks in de repository. Hij kijkt niet naar wat er op de schijf staat, hij vraagt ​​git welke bestanden feitelijk onder versiebeheer staan, omdat dat de bestanden zijn die elke kloon bij zich heeft.

4. Lees het geheime bestand

   Bob opent het vastgelegde omgevingsbestand. Dit is het verschil tussen dit lek en een enkele hardgecodeerde sleutel: het is niet één waarde die in een coderegel is geplakt, het is een heel bestand met geheimen onder versiebeheer. Alles wat de service nodig heeft, staat hier in platte tekst.

5. Bereik de stagingomgeving

   Een gelekte sleutel is slechts een theorie totdat hij iets opent. Bob heeft al alles wat hij nodig heeft van de kloon: de toegewijde .env gaf hem de API-basis-URL in PUBLIC_API_URL en een live sleutel, en de routes die hij in src/routes/payments.js heeft gekloond definiëren de betalingsfeed op /v1/transactions . Hij stelt het verzoek samen en draagt ​​de sleutel in een autorisatieheader, zoals een echte klant dat zou doen. Eindpunten waren nooit het geheim; ze zitten in de publieke bron. De sleutel was, en het vastgelegde bestand gaf hem er een, dus de server heeft geen reden om het verzoek af te wijzen.

6. De betalingsgegevens zijn geopend

   De server vertrouwde de sleutel en antwoordde. Bob leest de betalingsgegevens van Tavonn van buiten het bedrijf, zonder dat hij zelf een account heeft.

7. Kennis check

   Je hebt zojuist gezien hoe een openbare repository een buitenstaander de sleutels van een live-omgeving overhandigde. Leg vast waarom.

8. De waarschuwing komt binnen

   U bent eigenaar van Tavonn's betalingsservicerepository. Van de ene op de andere dag heeft de geheime scanner van het beveiligingsteam de openbare opslagplaats gemarkeerd en u een e-mail gestuurd. De bevinding is bot: een toegewijde .env met live-sleutels bevindt zich in de openbare repository, en er is geen .gitignore die soortgelijke bestanden buiten houdt.

9. Bijgehouden, zonder .gitignore

   Je eerste stap is om het zelf te zien. Je vermeldt wat git bijhoudt in de repository, en daar is het: de .env en de serviceaccountsleutel staan ​​onder versiebeheer, en er staat geen .gitignore in de lijst. Een bestand op schijf is één ding; een bestand dat git bijhoudt, wordt vastgelegd, in de geschiedenis en in elke kloon.

10. Ontgrendel de geheime bestanden

    Je voorkomt dat git de geheime bestanden bijhoudt met git rm --cached , waardoor ze uit de index worden verwijderd terwijl ze op schijf blijven staan, zodat de service nog steeds lokaal kan draaien. Je legt die wijziging vast en pusht deze, en de bestanden verdwijnen uit de huidige repository. Het voelt als de oplossing. Dat is niet zo, en de volgende stap laat zien waarom.