publiczny dostęp do repozytorium z kluczami

Publiczny dostęp do repozytorium z kluczami to jedno z najczęstszych źródeł wycieku danych uwierzytelniających.

Jak powstaje wyciek kluczy w publicznym repozytorium

Publiczny dostęp do repozytorium z kluczami oznacza, że pliki zawierające dane uwierzytelniające mogą zostać pobrane przez każdą osobę mającą dostęp do tego repozytorium. Dotyczy to między innymi kluczy API, tokenów dostępowych, haseł do usług, kluczy prywatnych SSH, certyfikatów z kluczem prywatnym oraz ciągów używanych przez aplikacje do łączenia się z bazami danych. Sam fakt, że plik ma nazwę .env, config.json albo secrets.yml, nie decyduje o jego bezpieczeństwie. Znaczenie ma to, czy zawartość pliku obejmuje informacje pozwalające uwierzytelnić się w konkretnej usłudze.

Do ujawnienia może dojść przez przypadkowe dodanie pliku do systemu kontroli wersji, błędne ustawienie uprawnień repozytorium albo umieszczenie sekretu w przykładzie konfiguracji. Częstym błędem jest również zapisanie klucza w komentarzu, skrypcie wdrożeniowym lub komunikacie zatwierdzenia. W systemie Git usunięcie pliku z bieżącej wersji nie oznacza automatycznego usunięcia jego wcześniejszych wersji. Sekret może nadal znajdować się w historii commitów, lokalnych kopiach, klonach, forkach albo archiwach utworzonych przez inne osoby.

Dlaczego usunięcie pliku nie wystarcza

Historia repozytorium przechowuje kolejne zmiany, dlatego klucz zapisany w dawnym commicie może być dostępny nawet po wykonaniu zwykłego usunięcia pliku i utworzeniu następnego commita. Polecenie git log --all -p pozwala przejrzeć zmiany w historii, a git grep może pomóc znaleźć podejrzane wzorce w aktualnie dostępnych plikach. Nie są to jednak kompletne mechanizmy wykrywania wszystkich sekretów, ponieważ klucz może mieć nietypowy format, być zapisany w pliku binarnym albo występować pod zmienioną nazwą.

Po ujawnieniu klucza podstawowym działaniem jest jego unieważnienie lub rotacja po stronie usługi, która go wystawiła. Nowy klucz powinien zostać przekazany aplikacji przez bezpieczny mechanizm konfiguracji, a nie zapisany w kodzie źródłowym. Dopiero po rotacji można usuwać sekret z historii, na przykład za pomocą narzędzia git filter-repo albo odpowiednio przygotowanego przepisywania historii. Taka operacja zmienia identyfikatory commitów i wymaga ponownego zsynchronizowania wszystkich kopii repozytorium. Nie daje też pewności usunięcia kopii, które wcześniej pobrali inni użytkownicy.

Kontrola historii, uprawnień i konfiguracji

Ocena ryzyka powinna obejmować zarówno zawartość bieżącej gałęzi, jak i pełną historię wszystkich istotnych referencji. Warto sprawdzić, czy repozytorium jest publiczne, kto może tworzyć branche i tagi, czy istnieją automatyczne kopie oraz czy proces budowania nie zapisuje sekretów w logach. Należy także przeanalizować pliki ignorowane przez Git. Wpisanie .env do .gitignore ogranicza ryzyko przypadkowego dodania nowych plików, ale nie usuwa pliku, który został już zatwierdzony w historii.

Przed publikacją kodu można stosować skanery sekretów analizujące commity, nazwy zmiennych i charakterystyczne wzorce tokenów. Wynik skanowania wymaga ręcznej weryfikacji, ponieważ losowy ciąg znaków może być zwykłą wartością testową, a prawdziwy sekret może nie pasować do znanego wzorca. Bezpieczniejszy model zakłada przechowywanie kluczy poza repozytorium, ograniczanie ich zakresu uprawnień, ustawianie terminów wygaśnięcia tam, gdzie usługa to obsługuje, oraz oddzielanie danych dla środowiska testowego i produkcyjnego.

Skutki dla komputera i dalsze postępowanie

Na laptopie lub komputerze PC problem może ujawnić się podczas pracy z narzędziem Git, klientem chmurowym, edytorem kodu albo skryptem automatyzującym wdrożenie. Należy ustalić, gdzie zapisano repozytorium, jakie pliki zostały pobrane lokalnie i czy klucz nie został skopiowany do dodatkowych katalogów, schowka lub plików tymczasowych. Jeżeli sekret był używany na komputerze, trzeba sprawdzić również historię poleceń i logi aplikacji, ponieważ niektóre programy zapisują parametry uruchomieniowe lub komunikaty diagnostyczne.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i podzespołów, w tym diagnostykę problemów związanych z konfiguracją systemu, oprogramowaniem oraz działaniem narzędzi używanych na komputerze. W przypadku publicznego repozytorium z kluczami konieczne jest jednak równoległe unieważnienie ujawnionych danych po stronie właściwej usługi. Sama naprawa komputera, usunięcie pliku lokalnego lub ponowne zainstalowanie programu nie unieważnia klucza, który został opublikowany w repozytorium.