Hogyan lehet visszavonni az érzékeny fájlokat a Git-től

Állítsa be a fájlokat, adjon hozzá kötelezettségvállalási üzenetet, nyomja meg Nincs várakozás! Nem az a fájl. És most el kell kezdenünk a guglizást.

Minden fejlesztő véletlenül kénytelen fájlokat követett el a múltban. Tehát hogyan javítsuk ki a helyzetet, és biztosítsuk, hogy ez ne forduljon elő újra?

Ebben a cikkben elmagyarázom, mi a teendő, ha véletlenül elkövet egy érzékeny fájlt, és belefoglalom az előzmények beállításához szükséges Git parancsokat.

Kárelhárítás

Tehát véletlenül elkövett egy érzékeny fájlt. Nevezzük .env-nek . Két fontos kérdésre kell válaszolni:

  • Távoli adattárhoz tolta az elkötelezettséget?
  • Nyilvános a távoli adattár?

Még nem tolta

Ha még nem nyomta, a helyzet egyáltalán nem kritikus. Akkor menj az előző elkövetni :

git reset HEAD^ --soft 

A fájlok a munkapéldányban maradnak, így javíthatja az érzékeny fájlt / információkat. Ha meg akarja tartani az elkötelezettséget és csak eltávolítja az érzékeny fájlt , tegye a következőket:

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

Használhatja a --amendcsak a legújabb elkövetni. Ha ezen felül sikerült egy csomó kötelezettségvállalást hozzáadni, használja:

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

Ez lehetővé teszi a hibás elkötelezettség kijavítását, és a javítás után visszajátszja az összes hátralévő elkötelezettséget, így nem veszíted el őket.

Már tolt

Ha mégis nyomta, fontos különbség van az állami és a magán tárolók között.

Ha az adattárad privát, és nincsenek olyan robotok vagy személyek, akikben nem bíznál meg a hozzáférésben, akkor könnyedén módosíthatod az utolsó elkötelezettséget a fenti két paranccsal.

Ha egy csomó elkötelezettséget tett a problematikus tetejére, továbbra is használhatja a filter-branch vagy a BFG repo cleanert az érzékeny fájl eltávolításához a git előzményekből :

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

De ne feledje e változások két fontos szempontját:

  • Valójában megváltoztatja a történelmet

    Ha vannak más személyek, más ágak, más villák vagy nyitott húzási kérelmek, amelyek a lerakat aktuális állapotára támaszkodnak, akkor azokat meg fogja bontani. Ezekben az esetekben kezelje a tárat úgy, mintha nyilvános lenne, és kerülje az előzmények megváltoztatását.

  • Törölnie kell a gyorsítótárat

    Mindig kapcsolatba kell lépnie a Git tárhely szolgáltatójával, és fel kell kérnie őket, hogy töröljék a tárház gyorsítótárát. Annak ellenére, hogy kijavította a problémás elkötelezettséget, vagy átírta az előzményeket, a régi elkötelezettség az érzékeny fájllal a gyorsítótárban marad. A hozzáféréshez ismernie kell az azonosítóját, de a gyorsítótár törléséig továbbra is elérhető.

Regenerálnom kell-e a kulcsokat, ha nyilvános adattárba tolom?

Röviden, igen. Ha az adattár nyilvános, vagy más okból nem gondolja, hogy biztonságos hely, akkor a bizalmas információkat veszélyeztetettnek kell tekintenie.

Még akkor sem, ha eltávolítja az adatokat a tárából, semmit sem tehet a repó botjaival és más villáival kapcsolatban. Tehát mik a következő lépések?

  • Deaktiválja az összes kulcsot és / vagy jelszót

    Tegye ezt első lépésként. A deaktiválás után a bizalmas információk haszontalanná válnak.

  • Állítsa be a gitignore-t

    Adja hozzá az összes érzékeny fájlt a .gitignore fájlhoz, hogy megbizonyosodjon róla, hogy a git nem fogja nyomon követni őket.

  • Távolítsa el az érzékeny fájlt
  • Végezze el a javítást értelmes magyarázattal

    Ne próbálja elrejteni a hibát. Más munkatársak és Ön egy hónap múlva értékelni fogják annak magyarázatát, hogy mi történt és mit javít ez az elkötelezettség.

Bevált módszerek a bizalmas adatok Gitben történő tárolásakor

Az ilyen helyzetek jövőbeni elkerülése érdekében íme néhány tipp a bizalmas adatok tárolásához:

A bizalmas adatokat az .env fájlban (vagy hasonló platformon tárolja).

Az API kulcsokat és egyéb érzékeny adatokat egyetlen .env fájlban tárolhatja. Így véletlenül nem fog új kulcsot végrehajtani, ha az .env fájl már ki van zárva a gitből.

További nagy előny, hogy hozzáférést kap minden kulcshoz egy globális folyamatváltozó segítségével .

Ha lehetséges, használja az API kulcsokat

Az API kulcsokat könnyű létrehozni és inaktiválni, ha veszélybe kerülnek. Ha lehetséges, használja őket, és kerülje a hitelesítő adatok / jelszavak használatát.

Adjon hozzá API kulcsokat a build eszközéhez

Az API kulcsokra általában az alkalmazás összeállításakor van szükség. Az olyan összeállítási eszközök, mint a Netlify, lehetővé teszik ezeknek a kulcsoknak az adminisztráció biztonságos területein történő hozzáadását. Ezeket a kulcsokat a globális folyamatváltozón keresztül automatikusan beadják az alkalmazásába .

.Env fájl hozzáadása a gitignore fájlhoz

Győződjön meg arról, hogy a Git nem követi a bizalmas információkat tartalmazó fájlokat.

Adja meg az .env.template fájlt

A sablonfájl utasítja a többi közreműködőt, hogy adják hozzá a szükséges API kulcsokat anélkül, hogy hosszú dokumentumok olvasására lenne szükségük.

Ne változtassa meg a távvezérlő előzményeit

Használja ezt ökölszabályként. Ha betartotta a fenti szabályokat, akkor nem kell módosítania az előzményeket.

Remélem, hogy ez az információ segített abban, hogy biztonságban maradhasson. Van személyes tapasztalata a vállalhatatlanságról, vagy esetleg egy jó tanulság ? Beszélj velem a Twitteren :-)