Git log komutu, dosyalar silindikten sonra bile neden gizli bilgileri açığa çıkarıyor?
Bir dosyadan bir satırı silmek ve commitDeğişikliği yapmak, hassas verileri deponuzdan gerçekten kaldırmaz. Eğer bu gizli bilgi, bir API anahtarı, kimlik bilgisi veya belirteç, daha önce ele geçirilmişse... commitTed, bu Git geçmişinizde yer alıyor. Bunu çalıştıran herkes. git log -p, git gösterveya geçmişteki farklılıkları incelemek commits hâlâ onu geri alabilir.
Dosyayı üzerine yazsanız veya değeri değiştirseniz bile, git günlüğü Her değişikliğin tüm izini korur. Bu, tasarım gereğidir. Git'in tüm modeli değiştirilemezliğe dayanmaktadır. commit Tarih ve dağıtılmış kopyalar. Dolayısıyla, tarihi açıkça yeniden yazmadığınız sürece, sırlarınız hala orada duruyor. İşte pratik bir örnek:
git commit -m "Added config with AWS_SECRET_KEY" # Realize mistake git rm config.json git commit -m "Removed secret file" ⚠️ Eğitim amaçlı örnek, üretim ortamında çalıştırmayın.
Çok geç. git günlüğü Başlangıçtaki anahtarın hala göründüğünü gösteriyor. commit.
Git stash ve git rebase ile ilgili yanlış anlamalar
Birçok geliştirici varsayıyor ki... git zula Sırları saklamaya veya temizlemeye yardımcı olur. Bu doğru değil. git zula sadece raflar çalışma dizini Değişiklikler geçicidir; asla dokunmaz. commit tarih. Eğer bir sır hiç... commitTed, bozuk paraları sonradan saklamak temizlemeye hiçbir fayda sağlamaz.
Ne dersin git yeniden tabanıTarihi yeniden yazabilir, ancak bu önceden yapılmalıdır.cisely. Sadece koşuyorum. git rebase -i ve yeniden sıralama veya sıkıştırma commits komutu, siz açıkça düzenlemediğiniz veya silmediğiniz sürece gizli bilgileri kaldırmaz. Ve orijinal dosyanın tek bir kopyası veya çatalı bile mevcutsa, bu durum geçerlidir. commitYani, sırrınız yaşamaya devam ediyor.
Daha da kötüsü, doğru şekilde force push yapmadan veya işbirlikçilerle yeniden koordinasyon sağlamadan rebase işlemi yapmak, birleştirmeler yoluyla açığa çıkan kimlik bilgilerini yeniden ortaya çıkarabilir.
git commit -m "Added config with AWS_SECRET_KEY"⚠️ Eğitim amaçlı örnek, gerçek ortamlarda kullanmayın.
git rebase -i HEAD~3⚠️ Bu sadece bir eğitim örneğidir, üretim depolarında çalıştırmayın.
Düzenle commit Sırrı içinde saklıyor ama çıkarmayı unutuyor. Sizin git günlüğü olabilir bak Daha temiz, ancak hassas içerik hala kurtarılabilir.
Git Geçmişinde Unutulan Kimlik Bilgilerinden Kaynaklanan Gerçek Dünya Riskleri
Bu teorik bir durum değil. Saldırganlar, gizlenmiş sırları bulmak için kamuya açık ve özel depoları aktif olarak tarıyorlar. commit Geçmişler. GitHub çatalları, ayna depoları ve önbelleğe alınmış depolar. CI/CD pipelineHepsi de o unutulmuş hatıraları barındırabilir.
- Eski bir API anahtarının sızdırılması git günlüğü Bu durum, bir girişim şirketi için binlerce dolarlık bulut faturalandırmasına yol açtı.
- OAuth belirteçleri commit"Ted" olarak işaretlenip ardından "silindi" şeklinde kaydedilen mesajlar, kullanıcı hesaplarını ele geçirmek için kullanıldı.
- Açık kaynak kodlu projelerin farklı sürümlerine gizlenmiş sırlar, büyük güvenlik olaylarına yol açtı.
Bu sorunlar giderek büyüyor CI/CDBir depoyu kopyalayan her işlem çalışır. git günlüğü Arka planda, her derleme çıktısı potansiyel olarak açığa çıkmış sırların izlerini içerebilir.
git filter-repo kullanarak hassas verileri temizleme
Hasar meydana geldiyse, onu temizlemenin en güvenilir aracı şudur: git filtre-repo. aksine git yeniden tabanı, bu da yeniden yazıyor bireysel commits, git filtre-repo tümünü yeniden yazabilir commit Dosya yollarına, kalıplara veya içeriğe dayalı geçmiş kaydı.
Örnek: tüm tekrarlarını silmek için yapılandırma.json Sırlar içerebilecek şeyler:
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 ⚠️ Bu sadece bir eğitim örneğidir, üretimde kullanmadan önce test deposunda doğrulayın.
Veya tümünü kaldırmak için commitbelirli bir dize içeren s'ler (örneğin, AWS_SECRET_ACCESS_KEY):
git filter-repo --replace-text <(echo 'AWS_SECRET_ACCESS_KEY==REDACTED')⚠️ Bu sadece bir eğitim örneğidir, üretimde kullanmadan önce test deposunda doğrulayın.
Dikkatli olun: Bu, yeniden yazacaktır. commit Karma değerler. Tüm işbirlikçileri bilgilendirmeniz ve zorla göndermeniz gerekecek. Otomasyon veya dağıtım anahtarlarıyla bağlantılı her şey. commit Karma değerler bozulacak.
Ayrıca aşağıdaki gibi araçlar BFG Repo Temizleyici Benzer yetenekler sunuyorlar ancak daha az esnekler ve karmaşık durumlar için artık eski moda olarak kabul ediliyorlar.
Gizli Bilgilerin Git'e Ulaşmasını Önlemek
Önlem almak, sonradan düzeltmekten daha iyidir. İşte sırların asla ortaya çıkmasını engellemenin yolları. git günlüğü:
1. Pre-commit Hooks
Gibi araçları kullanın pre-commit, gitleaksya da tılsım önce gizli bilgileri taramak için commits:
# .pre-commit-config.yaml - repo: https://github.com/zricethezav/gitleaks rev: v8.15.0 hooks: - id: gitleaks 2. CI/CD Pipeline uygulama
Birleştirmek gizli tespit CI işlerinize entegre edin. Gizli bilgiler bulunduğunda derlemeleri başarısız kılın. Bunu bir politika haline getirin.
3. Sırların Yönetimi
Kimlik bilgilerini asla doğrudan kod içine yazmayın. İlk günden itibaren ortam değişkenleri, kasalar veya gizli veri yöneticileri kullanın.
4. Denetim Bağımlılıkları
Üçüncü taraf yazılım paketlerine körü körüne güvenmeyin. Sırlar sızabilir npm, PyPI veya Docker katmanları aracılığıyla.
Son Çözüm: Git filter-repo ile gizli bilgileri temizleyin.
Koddan gizli bilgileri silmek yeterli değil. git günlüğü Tarihi yeniden yazmak için kasıtlı bir girişimde bulunmadığınız sürece, her şey eksiksiz kayıt altında kalır. Buna güvenmeyin. git zula ya da yarı pişmiş git yeniden tabanı denemeler. Kullanın git filtre-repo Derinlemesine temizliğe ihtiyaç duyduğunuzda ve gizli bilgiler deponuza ulaşmadan önce politikaları ve taramayı uyguladığınızda.
Önleyici gizli bilgi tespiti için aşağıdaki gibi araçları kullanmayı düşünebilirsiniz. Xygeni güvenliğini sağlamak için pipelines, uygulamak commit Hijyeni sağlayın ve maliyetli sızıntıların ortaya çıkmasını önleyin. Git asla unutmaz, ancak siz de onun sırlarınızı en başından hatırlamamasını sağlayabilirsiniz.
