Dlaczego git log ujawnia sekrety nawet po ich „usunięciu”
Usuwanie wiersza z pliku i commitWprowadzenie zmiany nie powoduje usunięcia poufnych danych z repozytorium. Jeśli ten sekret, klucz API, dane uwierzytelniające lub token zostały kiedykolwiek commitTed, to jest zapisane w historii Git. Każdy, kto uruchamia git log -p, git pokażlub sprawdzanie różnic z przeszłości commitNadal można je odzyskać.
Nawet jeśli nadpiszesz plik lub zamienisz wartość, dziennik git zachowuje pełną historię każdej zmiany. Jest to celowe. Cały model Gita opiera się na niezmiennych commit Historia i rozpowszechniane kopie. Więc dopóki nie przepiszesz historii w sposób jawny, twoje sekrety nadal tam pozostaną. Oto praktyczny przypadek:
git commit -m "Added config with AWS_SECRET_KEY"
# Realize mistake
git rm config.json
git commit -m "Removed secret file"
⚠️ Przykład edukacyjny, nie uruchamiać w środowisku produkcyjnym
Za późno. dziennik git nadal pokazuje ten klucz na początku commit.
Nieporozumienia dotyczące poleceń git stash i git rebase
Wielu deweloperów zakłada git schowek Pomaga ukryć lub oczyścić sekrety. Nieprawda. git schowek tylko półki katalog roboczy zmienia się tymczasowo; nigdy nie dotyka commit historia. Jeśli kiedykolwiek istniała tajemnica committed, późniejsze odkładanie zmian nie ma żadnego wpływu na ich czyszczenie.
A co z git rebase? Choć może zmienić historię, musi to zostać zrobione wcześniejcisely. Po prostu biegam git rebase -i i ponowne uporządkowanie lub spłaszczenie commits nie usuwa sekretów, chyba że je jawnie edytujesz lub usuniesz. Nawet jeśli istnieje choć jeden klon lub fork z oryginałem, commitS, twój sekret żyje dalej.
Co gorsza, zmiana bazy bez prawidłowego wymuszenia lub ponownej koordynacji ze współpracownikami może spowodować ponowne wprowadzenie ujawnionych danych uwierzytelniających poprzez scalenia.
git commit -m "Added config with AWS_SECRET_KEY"
⚠️ Przykład edukacyjny, nie należy używać w rzeczywistych środowiskach
git rebase -i HEAD~3
⚠️ Przykład edukacyjny, nie uruchamiaj w repozytoriach produkcyjnych
Edytuj commit zawierającego sekret, ale zapominającego go usunąć. Twoje dziennik git może na temat czystsze, ale nadal możliwe jest odzyskanie wrażliwej zawartości.
Rzeczywiste zagrożenia wynikające z zapomnianych danych uwierzytelniających w historii Git
To nie jest teoria. Atakujący aktywnie skanują publiczne i prywatne repozytoria w poszukiwaniu ukrytych sekretów. commit historie. Forki GitHub, repozytoria lustrzane i buforowane CI/CD pipelineWszystkie mogą zawierać zapomniane symbole.
- Wyciekły klucz API ze starego dziennik git doprowadziło do powstania tysięcy rozliczeń w chmurze w jednym startupie.
- Tokeny OAuth committed, a następnie „usunięte”, służyły do przejmowania kont użytkowników.
- Tajemnice głęboko zakopane w rozwidleniach projektów open source wywołały poważne incydenty bezpieczeństwa.
Te problemy narastają CI/CD. Każde zadanie klonujące repozytorium jest uruchamiane dziennik git pod maską, a każdy artefakt kompilacji może potencjalnie zawierać ślady ujawnionych sekretów.
Czyszczenie poufnych danych za pomocą git filter-repo
Jeśli uszkodzenie już wystąpiło, najpewniejszym narzędziem do jego oczyszczenia jest repozytorium filtrów git. w odróżnieniu git rebase, który przepisuje indywidualny commits, repozytorium filtrów git może przepisać całość commit historia oparta na ścieżkach plików, wzorcach lub zawartości.
Przykład: aby wyczyścić wszystkie wystąpienia konfiguracja.json które mogą zawierać sekrety:
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
⚠️ Przykład edukacyjny, zweryfikuj w repozytorium testowym przed użyciem w środowisku produkcyjnym
Lub usunąć wszystkie commits, które zawierają określony ciąg (np. AWS_SECRET_ACCESS_KEY):
git filter-repo --replace-text <(echo 'AWS_SECRET_ACCESS_KEY==REDACTED')
⚠️ Przykład edukacyjny, zweryfikuj w repozytorium testowym przed użyciem w środowisku produkcyjnym
Bądź ostrożny: to przepisze commit haszy. Będziesz musiał wymusić wypchnięcie i poinformować wszystkich współpracowników. Wszelkie klucze automatyzacji lub wdrażania powiązane z commit hasze ulegną uszkodzeniu.
Ponadto narzędzia takie jak Środek czyszczący BFG Repo oferują podobne możliwości, ale są mniej elastyczne i obecnie uważa się je za przestarzałe w przypadku skomplikowanych przypadków.
Zapobieganie wyciekom poufnych informacji zanim dotrą do Git
Zapobieganie jest ważniejsze niż sprzątanie. Oto jak zapobiec ujawnieniu sekretów dziennik git:
1. Pre-commit Hooks
Użyj narzędzi takich jak pre-commit, gitleakslub talizman skanować w poszukiwaniu sekretów przed commits:
# .pre-commit-config.yaml
- repo: https://github.com/zricethezav/gitleaks
rev: v8.15.0
hooks:
- id: gitleaks
2. CI/CD Pipeline Egzekwowanie
Zintegrować wykrywanie tajemnic do zadań CI. Kompilacje kończą się niepowodzeniem, gdy zostaną znalezione sekrety. Ustanów tę zasadę.
3. Zarządzanie tajemnicami
Nigdy nie koduj danych uwierzytelniających na stałe. Korzystaj ze zmiennych środowiskowych, sejfów lub menedżerów sekretów od pierwszego dnia.
4. Zależności audytu
Nie ufaj bezgranicznie pakietom oferowanym przez inne firmy. Sekrety mogą wyciekać poprzez warstwy npm, PyPI lub Docker.
Ostateczna poprawka: czyszczenie sekretów za pomocą git filter-repo
Samo usunięcie sekretów z kodu nie wystarczy. dziennik git przechowuje pełną dokumentację, chyba że celowo podejmiesz działania mające na celu zmianę historii. Nie polegaj na git schowek lub półupieczone git rebase Próby. Użyj repozytorium filtrów git gdy potrzebujesz gruntownego czyszczenia i wyegzekwujesz zasady oraz skanowanie zanim poufne informacje dotrą do Twojego repozytorium.
Aby proaktywnie wykrywać tajne informacje, rozważ użycie takich narzędzi jak Xygeni aby zabezpieczyć pipelines, wyegzekwować commit higienę i zapobiegaj kosztownym wyciekom, zanim się pojawią. Git nigdy nie zapomina, ale możesz upewnić się, że nigdy nie zapomni Twoich sekretów.
