Pse git log ekspozon sekretet edhe pasi ato janë "fshirë"
Fshirja e një rreshti nga një skedar dhe commitNdryshimi nuk i heq në fakt të dhënat e ndjeshme nga depoja juaj. Nëse ai sekret, një çelës API, kredencial ose token, ka qenë ndonjëherë committed, ai ndodhet në historikun tuaj të Git. Kushdo që e ekzekuton git log -p, shfaqje git, ose duke inspektuar ndryshimet nga e kaluara commits ende mund ta rikuperojë atë.
Edhe nëse mbishkruani një skedar ose zëvendësoni vlerën, log git ruan të gjithë prejardhjen e çdo ndryshimi. Kjo është bërë me dashje. I gjithë modeli i Git bazohet në të pandryshueshmen commit historia dhe kopjet e shpërndara. Pra, nëse nuk e rishkruani në mënyrë të qartë historinë, sekretet tuaja janë ende aty. Ja një rast praktik:
git commit -m "Added config with AWS_SECRET_KEY" # Realize mistake git rm config.json git commit -m "Removed secret file" ⚠️ Shembull edukativ, mos e ekzekutoni në prodhim
Shumë vonë. log git ende e tregon atë çelës në fillim commit.
Keqkuptime rreth git stash dhe git rebase
Shumë zhvillues supozojnë gatishmëri Ndihmon në fshehjen ose pastrimin e sekreteve. Nuk është e vërtetë. gatishmëri vetëm rafte drejtoria e punës ndryshon përkohësisht; nuk prek kurrë commit histori. Nëse ndonjëherë do të kishte një sekret committed, ruajtja e ndryshimeve më pas nuk bën asgjë për ta pastruar atë.
Po për bazoj gitNdërsa mund të rishkruajë historinë, duhet të bëhet paraprakishtcisely. Vetëm duke vrapuar git ribazo -i dhe riorganizimi ose shtrydhja commits nuk i heq sekretet përveç nëse i modifikoni ose i hiqni ato në mënyrë të qartë. Dhe nëse ekziston edhe një klon ose degëzim me origjinalin commits, sekreti yt vazhdon të jetojë.
Edhe më keq, ndryshimi i bazës pa u detyruar të ushtrohet siç duhet ose pa u rikoordinuar me bashkëpunëtorët mund të riprezantojë kredencialet e ekspozuara nëpërmjet bashkimeve.
git commit -m "Added config with AWS_SECRET_KEY"⚠️ Shembull edukativ, mos e përdorni në mjedise reale
git rebase -i HEAD~3⚠️ Shembull edukativ, mos ekzekutoni në depo prodhimi
Edit commit që përmban sekretin, por harron ta heqësh atë. Juaj log git fuqi shikoj më i pastër, por përmbajtja e ndjeshme është ende e rikuperueshme.
Rreziqet e botës reale nga kredencialet e harruara në historinë e Git
Kjo nuk është teorike. Sulmuesit skanojnë në mënyrë aktive depot publike dhe private për sekrete të fshehura në commit historitë. Degëzimet e GitHub, depot e pasqyruara dhe të ruajtura në memorje CI/CD pipelinetë gjitha mund të strehojnë ato tokena të harruara.
- Një çelës API i rrjedhur nga një i vjetër log git çoi në mijëra faturime në cloud për një startup.
- Shenjat OAuth committed, pastaj “fshirë”, u përdorën për të rrëmbyer llogaritë e përdoruesve.
- Sekretet e fshehura thellë në degët e projekteve me burim të hapur shkaktuan incidente të mëdha sigurie.
Këto probleme shkallëzohen CI/CDÇdo punë që klonon një depo ekzekutohet. log git nën kapuç, dhe çdo objekt ndërtimi mund të përfshijë potencialisht gjurmë të sekreteve të zbuluara.
Pastrimi i të dhënave të ndjeshme me git filter-repo
Nëse dëmi është bërë, mjeti më i besueshëm për ta pastruar atë është git filter-repo. ndryshe nga bazoj git, e cila rishkruan individual commits, git filter-repo mund ta rishkruajë të gjithën commit historia bazuar në shtigjet e skedarëve, modelet ose përmbajtjen.
Shembull: të fshihen të gjitha paraqitjet e config.json që mund të përmbajnë sekrete:
pip install git-filter-repo # Backup your repo first cp -r my-repo my-repo-backup cd my-repo git filter-repo --path config.json --invert-paths ⚠️ Shembull edukativ, verifikojeni në një depo testimi përpara se ta përdorni në prodhim
Ose për të hequr të gjitha commitqë përfshijnë një varg specifik (p.sh., AWS_SECRET_ACCESS_KEY):
git filter-repo --replace-text <(echo 'AWS_SECRET_ACCESS_KEY==REDACTED')⚠️ Shembull edukativ, verifikojeni në një depo testimi përpara se ta përdorni në prodhim
Kini kujdes: Kjo do të rishkruhet commit hash-e. Do të duhet të detyrosh dhe të informosh të gjithë bashkëpunëtorët. Çdo çelës automatizimi ose vendosjeje i lidhur me commit hash-et do të prishen.
Gjithashtu, mjete si BFG Repo-Cleaner ofrojnë aftësi të ngjashme, por janë më pak fleksibile dhe tani konsiderohen të vjetruara për raste komplekse.
Parandalimi i rrjedhjeve të sekreteve përpara se ato të arrijnë në Git
Parandalimi është më i mirë se pastrimi. Ja si t’i ndaloni sekretet të shfaqen ndonjëherë log git:
1. Pre-commit Hooks
Përdorni mjete si pre-commit, gitleaksose hajmali për të kërkuar sekrete më parë commits:
# .pre-commit-config.yaml - repo: https://github.com/zricethezav/gitleaks rev: v8.15.0 hooks: - id: gitleaks 2. CI/CD Pipeline zbatim
të integruar zbulim sekret në punët tuaja të CI-së. Dështimet rriten kur zbulohen sekrete. Bëjeni këtë një politikë.
3. Menaxhimi i Sekreteve
Mos përdorni kurrë kode të forta për kredencialet. Përdorni variabla mjedisi, kasaforta ose menaxherë sekretë që nga dita e parë.
4. Varësitë e Auditimit
Mos u besoni verbërisht paketave të palëve të treta. Sekretet mund të zbulohen përmes shtresave npm, PyPI ose Docker.
Rregullimi përfundimtar: Sekretet e pastrimit me git filter-repo
Fshirja e sekreteve nga kodi nuk mjafton. log git mban një regjistër të plotë përveç nëse ndërmerrni veprime të qëllimshme për të rishkruar historinë. Mos u mbështetni te gatishmëri ose gjysmë i pjekur bazoj git përpjekje. Përdor git filter-repo kur keni nevojë për një pastrim të thellë dhe zbatoni politikat dhe skanimin përpara se sekretet të arrijnë në depon tuaj.
Për zbulimin proaktiv të sekreteve, merrni në konsideratë përdorimin e mjeteve si Xygeni për të siguruar tuajën pipelines, zbato commit higjienën dhe parandaloni rrjedhjet e kushtueshme përpara se ato të dalin në pah. Git nuk harron kurrë, por mund të siguroheni që ai të mos i kujtojë kurrë sekretet tuaja që në fillim.
