Sådan frigøres følsomme filer fra Git

Iscenesæt filer, tilføj en meddelelse, tryk. Nej - vent! Ikke den fil. Og nu er vi nødt til at starte googling.

Hver udvikler har ved et uheld begået følsomme filer tidligere. Så hvordan løser vi situationen og sikrer, at den ikke sker igen?

I denne artikel forklarer jeg, hvad jeg skal gøre, når du ved en fejltagelse begår en følsom fil og inkluderer de nødvendige Git-kommandoer til at justere historikken.

Skade kontrol

Så du begik ved en fejltagelse en følsom fil. Lad os kalde det .env . Der er to vigtige spørgsmål at besvare:

  • Har du skubbet forpligtelsen til et eksternt lager?
  • Er fjernlageret offentligt?

Ikke skubbet endnu

Hvis du ikke skubbede endnu, er situationen slet ikke kritisk. Du kan vende tilbage til en tidligere forpligtelse :

git reset HEAD^ --soft

Dine filer forbliver i arbejdskopien, så du kan rette den følsomme fil / info. Hvis du vil beholde forpligtelsen og bare fjerne den følsomme fil , skal du gøre:

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

Du kan bruge det --amendeneste på den seneste forpligtelse. Hvis det lykkedes dig at tilføje en masse forpligtelser oven på det, skal du bruge:

git rebase -i HEAD~{how many commits to go back?}

Dette giver dig mulighed for at rette den defekte forpligtelse, og den vil afspille alle de resterende forpligtelser efter rettelsen, så du ikke mister dem.

Allerede skubbet

Hvis du skubbede, er der en vigtig forskel mellem offentlige og private arkiver.

Hvis dit arkiv er privat, og der ikke er bots eller personer, som du ikke stoler på med adgang til det, kan du nemt ændre det sidste engagement ved hjælp af de to kommandoer ovenfor.

Hvis du skubbede en masse forpligtelser oven på den problematiske, kan du stadig bruge filtergren eller BFG repo-renser til at fjerne den følsomme fil fra git-historikken :

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

Men husk to vigtige aspekter af disse ændringer:

  • Du ændrer faktisk historien

    Hvis der er andre mennesker, andre grene, andre gafler eller åbne trækanmodninger, der er afhængige af lagerets aktuelle tilstand, bryder du dem. I disse tilfælde skal du behandle arkivet som om det var offentligt og undgå at ændre historikken.

  • Du skal rydde cachen

    Du skal altid kontakte supporten fra din Git-lagerudbyder og bede dem om at rydde cachen i dit lager. Selvom du har rettet den problematiske forpligtelse eller omskrevet historikken, forbliver den gamle forpligtelse med den følsomme fil i cachen. Du har brug for at kende dets id for at få adgang til det, men det er stadig tilgængeligt, indtil du rydder cachen.

Skal jeg gendanne nøgler, hvis jeg skubber dem til et offentligt lager?

Kort sagt ja. Hvis dit arkiv er offentligt, eller du ikke tror, ​​det er et sikkert sted af anden grund, skal du overveje, at de følsomme oplysninger er kompromitteret.

Selv hvis du fjerner dataene fra dit arkiv, kan du ikke gøre noget ved bots og andre gafler i repoen. Så hvad er de næste trin?

  • Deaktiver alle taster og / eller adgangskoder

    Gør dette som det første skridt. Når du deaktiverer tasterne, bliver følsomme oplysninger ubrugelige.

  • Juster gitignore

    Føj alle følsomme filer til .gitignore for at sikre, at git ikke sporer dem.

  • Fjern den følsomme fil
  • Foretag løsningen med en meningsfuld forklaring

    Forsøg ikke at skjule fejlen. Andre samarbejdspartnere og dig om en måned vil sætte pris på forklaringen på, hvad der skete, og hvad dette løser.

Bedste fremgangsmåder ved lagring af følsomme data i Git

For at undgå en situation som denne i fremtiden er her et par tip til lagring af følsomme data:

Opbevar følsomme data i .env-filen (eller lignende filer på andre platforme)

Gem API-nøgler og andre følsomme data i en enkelt .env-fil. På den måde vil du ikke ved en fejltagelse begå en ny nøgle, når .env-filen allerede er ekskluderet fra git.

En anden stor fordel er, at du får adgang til alle nøgler ved hjælp af en global procesvariabel .

Brug API-nøgler, hvis det er muligt

API-nøgler er nemme at generere og deaktivere, hvis de er kompromitterede. Hvis det er muligt, skal du bruge dem og undgå at bruge legitimationsoplysninger / adgangskoder.

Føj API-nøgler til dit buildværktøj

API-nøgler er normalt nødvendige under applikationsbygninger. Byg værktøjer som Netlify giver dig mulighed for at tilføje disse nøgler i de sikre områder i deres administration. Disse nøgler injiceres automatisk i din app via den globale procesvariabel .

Føj .env-fil til gitignore

Sørg for, at Git ikke sporer filer, der indeholder følsomme oplysninger.

Angiv .env.template-fil

Skabelonfilen beder andre samarbejdspartnere om at tilføje de nødvendige API-nøgler uden at kræve, at de læser lange dokumenter.

Du må ikke ændre historikken på fjernbetjeningen

Brug dette som en tommelfingerregel. Hvis du fulgte ovenstående regler, behøver du ikke ændre historikken.

Jeg håber, at disse oplysninger hjalp dig med at forblive på den sikre side. Har du en personlig oplevelse med uforpligtende eller måske en god lektion ? Tal med mig på Twitter :-)