token uwierzytelniający zapisany w repozytorium

Token uwierzytelniający zapisany w repozytorium to poważny wyciek, wymagający natychmiastowej rotacji klucza.

Czym jest token uwierzytelniający zapisany w repozytorium

Token uwierzytelniający to ciąg znaków używany przez aplikację, skrypt albo narzędzie automatyzujące do potwierdzenia tożsamości wobec usługi. Może pełnić funkcję poświadczenia dostępu do interfejsu API, repozytorium kodu, systemu wdrożeniowego, usługi chmurowej albo panelu administracyjnego. Sam token nie musi zawierać nazwy użytkownika ani hasła w formie czytelnej dla człowieka, ale dla serwera może mieć taką samą wartość praktyczną jak hasło: jego posiadacz może zostać uznany za uprawnionego do wykonania określonych operacji.

Umieszczenie aktywnego tokenu w repozytorium oznacza, że poświadczenie może trafić do historii zmian, kopii roboczych, klonów, forków, pamięci podręcznych systemu kontroli wersji oraz automatycznych kopii zapasowych. Usunięcie linii z najnowszej wersji pliku nie usuwa jej automatycznie z wcześniejszych commitów. W przypadku publicznego repozytorium token może zostać pobrany przez dowolną osobę. W repozytorium prywatnym ryzyko nadal istnieje, ponieważ dostęp mogą mieć inni członkowie zespołu, integracje CI/CD lub konta techniczne.

Dlaczego sam token wymaga traktowania jak ujawnione poświadczenie

Ujawniony token należy uznać za skompromitowany nawet wtedy, gdy nie ma dowodu jego wykorzystania. Osoba analizująca historię Git może znaleźć ciąg znaków w dawnym commicie, a wyspecjalizowane skanery sekretów potrafią wykrywać charakterystyczne prefiksy, długości i formaty kluczy. Ryzyko zależy od zakresu uprawnień tokenu, czasu jego ważności, wymogu dodatkowej weryfikacji oraz usługi, do której token należy. Odczyt danych, modyfikowanie kodu, tworzenie wydań, zmiana ustawień automatyzacji i dostęp do zasobów produkcyjnych mają różne skutki, ale każdy niepotrzebnie ujawniony zakres zwiększa możliwe konsekwencje.

Nie wolno zakładać, że token jest bezpieczny tylko dlatego, że został zapisany w pliku ignorowanym przez Git, zakodowany w Base64 albo ukryty w komentarzu. Kodowanie Base64 nie jest szyfrowaniem. Plik ignorowany przez Git może nadal zostać przypadkowo dodany, skopiowany lub udostępniony poza repozytorium. Token może być również widoczny w logach procesu budowania, komunikatach błędów, artefaktach CI albo historii poleceń powłoki. Weryfikacja powinna obejmować wszystkie miejsca, do których poświadczenie mogło trafić, bez publikowania jego pełnej wartości w zgłoszeniu, raporcie lub komunikacie zespołowym.

Rotacja, unieważnienie i oczyszczenie historii zmian

Pierwszym działaniem jest unieważnienie albo rotacja tokenu po stronie usługi, która go wystawiła. Nowe poświadczenie należy wygenerować z minimalnym zakresem uprawnień, krótkim okresem ważności, jeżeli usługa to umożliwia, oraz ograniczeniem do wymaganych repozytoriów, środowisk lub adresów sieciowych. Samo utworzenie nowego tokenu bez odebrania starego nie rozwiązuje problemu, ponieważ ujawniona wartość nadal może działać. Po rotacji trzeba sprawdzić, czy aplikacja korzysta już z nowego sekretu i czy zaplanowane zadania nie kończą się błędami uwierzytelniania.

Następnie należy usunąć token z plików roboczych i konfiguracji śledzonej przez Git, ale trzeba zachować świadomość, że zwykły nowy commit nie czyści historii. Jeżeli sekret występował w commitach, historii trzeba użyć narzędzia przeznaczonego do przepisywania zawartości repozytorium, na przykład git-filter-repo, zgodnie z procedurą dla danego repozytorium. Po przepisaniu historii konieczne może być wymuszone uzgodnienie zmienionych gałęzi i klonów, dlatego operację należy koordynować z osobami korzystającymi z projektu. Oczyszczenie historii nie zastępuje rotacji: kopia tokenu mogła zostać pobrana przed usunięciem.

Po usunięciu sekretu warto przeszukać historię, tagi, gałęzie, artefakty oraz logi automatyzacji pod kątem pozostałych kopii. Mechanizmy wykrywania sekretów powinny działać przed zatwierdzeniem zmian i po stronie zdalnego repozytorium. Poświadczenia używane przez procesy budowania powinny być przekazywane jako sekrety środowiska CI, menedżera sekretów albo chronionych zmiennych, a nie jako literały w kodzie. Warto także przejrzeć logi dostępu usługi i unieważnić sesje lub dodatkowe klucze, jeżeli istnieją przesłanki, że token został wykorzystany.

Bezpieczny przepływ pracy przy konfiguracji aplikacji

Konfiguracja lokalna powinna rozdzielać kod od sekretów. W repozytorium może znajdować się plik przykładowy z nazwami zmiennych i wartościami zastępczymi, natomiast właściwe tokeny powinny być dostarczane przez bezpieczny mechanizm konfiguracji używany w danym środowisku. Nie należy wpisywać poświadczeń bezpośrednio do skryptów, plików JSON, YAML, dokumentacji, testów ani poleceń uruchamianych w systemie budowania. Jeżeli aplikacja zapisuje token w pamięci podręcznej lub pliku konfiguracyjnym, dostęp do tego miejsca powinien być ograniczony do konta i procesu, które rzeczywiście go potrzebują.

W diagnostyce problemu trzeba odróżnić błąd wygasłego tokenu od błędu zakresu uprawnień, nieprawidłowego adresu usługi, złej zmiennej środowiskowej i zegara systemowego ustawionego poza właściwym czasem. Komunikaty logów nie powinny zawierać pełnego tokenu; bezpieczniejsze jest zapisanie nazwy zmiennej, identyfikatora poświadczenia lub krótkiego, nieodwracalnego odcisku używanego wyłącznie do korelacji. Jeśli ujawnienie nastąpiło na laptopie albo komputerze PC, Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, natomiast sama rotacja tokenu musi zostać wykonana w usłudze, która ten token wydała.