Cum să deconectați fișierele sensibile de la Git

Etapa fișiere, adăugați un mesaj de confirmare, push. Nu așteptați! Nu acel fișier. Și acum trebuie să începem să căutăm.

Fiecare dezvoltator a comis în mod accidental fișiere sensibile în trecut. Deci, cum rezolvăm situația și ne asigurăm că nu se va mai repeta?

În acest articol, voi explica ce trebuie să faceți atunci când comiteți accidental un fișier sensibil și includ comenzile Git necesare pentru a regla istoricul.

Controlul daunelor

Deci ați comis din greșeală un fișier sensibil. Să-i spunem .env. Există două întrebări importante de răspuns:

• Ați împins commit-ul către un depozit la distanță?
• Depozitul la distanță este public?

Nu este încă împins

Dacă nu ați împins încă, situația nu este deloc critică. Poti reveniți la o comitere anterioară:

git reset HEAD^ --soft

Fișierele dvs. vor rămâne în copia de lucru, astfel încât să puteți remedia fișierul / informațiile sensibile. Dacă doriți să păstrați confirmarea și eliminați doar fișierul sensibil, faceți:

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

Puteți utiliza --amend numai la ultima comitere. Dacă ați reușit să adăugați o grămadă de confirmări, utilizați:

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

Acest lucru vă va permite să remediați comiterea defectă și va relua toate comitetele rămase după corecție, astfel încât să nu le pierdeți.

Deja împins

Dacă ați făcut push, există o diferență importantă între depozitele publice și private.

Dacă depozitul dvs. este privat și nu există roboți sau persoane în care nu aveți încredere cu acces la acesta, puteți modifica cu ușurință ultima comitere folosind cele două comenzi de mai sus.

Dacă ați împins o grămadă de confirmări peste cea problematică, puteți utiliza în continuare filtru-ramură sau BFG repo clean la eliminați fișierul sensibil din istoricul git:

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

Dar rețineți două aspecte importante ale acestor schimbări:

• De fapt, schimbați istoria
  Dacă există alte persoane, alte ramuri, alte furci sau cereri de extragere deschisă care se bazează pe starea actuală a depozitului, le veți rupe. În aceste cazuri, tratați depozitul ca și cum ar fi fost public și evitați schimbarea istoricului.
• Trebuie să ștergeți memoria cache
  Trebuie întotdeauna să contactați asistența furnizorului dvs. de stocare Git și să le cereți să șteargă memoria cache a depozitului dvs. Chiar dacă ați remediat validarea problematică sau ați rescris istoricul, vechea validare cu fișierul sensibil rămâne în cache. Trebuie să-i cunoașteți ID-ul pentru a-l accesa, dar este încă accesibil până când ștergeți memoria cache.

Trebuie să regenerez tastele dacă sunt împins către un depozit public?

Pe scurt, da. Dacă depozitul dvs. este public sau nu credeți că este un loc sigur din orice alt motiv, trebuie să considerați că informațiile sensibile sunt compromise.

Chiar dacă eliminați datele din depozitul dvs., nu puteți face nimic despre roboți și alte furci ale repo. Deci, care sunt pașii următori?

• Dezactivați toate tastele și / sau parolele
  Faceți acest lucru ca primul pas. Odată ce dezactivați tastele, informațiile sensibile devin inutile.
• Reglați gitignore
  Adăugați toate fișierele sensibile la .gitignore pentru a vă asigura că git nu le va urmări.
• Eliminați fișierul sensibil
• Luați soluția cu o explicație semnificativă
  Nu încerca să ascunzi greșeala. Alți colaboratori și dvs., într-o lună, veți aprecia explicația a ceea ce s-a întâmplat și a ceea ce remedia acest angajament.

Cele mai bune practici la stocarea datelor sensibile în Git

Pentru a evita o astfel de situație în viitor, iată câteva sfaturi despre stocarea datelor sensibile:

Păstrați datele sensibile în fișierul .env (sau un fișier similar pe alte platforme)

Păstrați cheile API și alte date sensibile într-un singur fișier .env. În acest fel nu veți comite accidental o nouă cheie atunci când fișierul .env este deja exclus din git.

Un alt mare avantaj este că obțineți acces la toate cheile folosind un sistem global proces variabil.

Utilizați cheile API, dacă este posibil

Cheile API sunt ușor de generat și dezactivat dacă sunt compromise. Dacă este posibil, utilizați-le și evitați să folosiți acreditări / parole.

Adăugați chei API la instrumentul dvs. de construire

Cheile API sunt de obicei necesare în timpul compilărilor aplicațiilor. Instrumentele de construire precum Netlify vă permit să adăugați aceste chei în zonele sigure ale administrării lor. Aceste chei sunt injectate automat în aplicația dvs. prin intermediul global proces variabil.

Adăugați fișierul .env la gitignore

Asigurați-vă că Git nu urmărește fișierele care conțin informații sensibile.

Furnizați fișierul .env.template

Fișierul șablon instruiește alți colaboratori să adauge cheile API necesare fără a le cere să citească documente lungi.

Nu modificați istoricul la distanță

Folosiți acest lucru ca regulă generală. Dacă ați respectat regulile de mai sus, nu va trebui să schimbați istoricul.

Sper că aceste informații v-au ajutat să rămâneți în siguranță. Aveți o experiență personală cu neîncredere sau poate un bun Lecții învățate? Vorbește-mi pe Twitter 🙂