Publiczne klucze API / tokeny w kodzie lub repozytorium

Publiczne klucze API i tokeny w kodzie lub repozytorium to poważne ryzyko — ich ujawnienie równa się przekazaniu dostępu.

Dlaczego klucz lub token zapisany w repozytorium staje się zagrożeniem

Publiczne klucze API i tokeny w kodzie lub repozytorium to dane uwierzytelniające używane przez program do komunikacji z zewnętrzną usługą. Token może reprezentować konto użytkownika, aplikację, projekt albo określony zakres uprawnień. Jeżeli taki ciąg znaków zostanie zapisany w pliku źródłowym, historii systemu Git, obrazie kontenera, archiwum lub logu, może zostać skopiowany przez każdą osobę mającą dostęp do tego miejsca. Sam fakt, że token znajduje się w prywatnym repozytorium, nie oznacza pełnego bezpieczeństwa, ponieważ dostęp może uzyskać nieuprawniona osoba, konto może zostać przejęte, a kopia repozytorium może trafić poza organizację.

Określenie „publiczny klucz API” bywa mylące. Niektóre klucze są przeznaczone do użycia po stronie klienta i pozwalają jedynie rozpoznać aplikację, ale inne umożliwiają wykonywanie operacji rozliczanych finansowo albo dostęp do danych. Token dostępu, token odświeżający, klucz prywatny certyfikatu, hasło do usługi oraz ciąg używany do podpisywania żądań powinny być traktowane jako sekrety, chyba że dokumentacja konkretnego dostawcy wyraźnie określa odmienny model. Przypadkowe ujawnienie może skutkować nieautoryzowanymi żądaniami, zmianą konfiguracji, wykorzystaniem limitu zapytań lub naliczeniem opłat.

Gdzie sekrety pozostają po usunięciu z pliku

Usunięcie tokenu z bieżącej wersji kodu nie usuwa go automatycznie z historii Git. Wartość może nadal znajdować się w wcześniejszym commicie, tagu, gałęzi, lokalnym reflogu, kopii roboczej albo w zewnętrznym mirrorze. Dodatkowe kopie mogą występować w systemie ciągłej integracji, pamięci podręcznej procesu budowania, artefaktach testowych, raportach błędów oraz logach aplikacji. Szczególnie ryzykowne jest umieszczanie sekretu w parametrze adresu URL, ponieważ adres może zostać zapisany w historii przeglądarki, nagłówku referer, proxy lub narzędziu monitorującym.

Podobny problem dotyczy plików konfiguracyjnych kopiowanych do paczek instalacyjnych i obrazów uruchomieniowych. Sekret może zostać włączony do pliku JavaScript dostarczanego do przeglądarki, do aplikacji mobilnej, do dokumentacji przykładowej albo do zrzutu diagnostycznego. Zmienna środowiskowa ogranicza ryzyko przypadkowego zapisania wartości w kodzie, ale nie chroni przed wyciekiem podczas nieprawidłowego logowania, ujawnieniem konfiguracji procesu lub udostępnieniem środowiska uruchomieniowego. Dlatego trzeba sprawdzać nie tylko plik, w którym znaleziono ciąg, lecz także miejsca, do których trafiają kopie aplikacji i jej danych konfiguracyjnych.

Rozpoznanie wycieku i właściwa reakcja

Podejrzany klucz lub token należy najpierw uznać za ujawniony, bez czekania na potwierdzenie jego wykorzystania. Najważniejszą czynnością jest unieważnienie albo rotacja poświadczenia w panelu dostawcy usługi. Nowa wartość powinna otrzymać możliwie wąski zakres uprawnień, ograniczenie do konkretnych operacji oraz, jeżeli dostawca to obsługuje, ograniczenia dotyczące domen, adresów IP, aplikacji lub środowiska. Samo przepisanie sekretu do innego pliku nie rozwiązuje problemu, jeśli stary token nadal pozostaje aktywny.

Po rotacji należy ustalić zakres zdarzenia: sprawdzić historię zmian, uprawnienia repozytorium, logowania, wykorzystanie API, utworzone zasoby, zmienione ustawienia i nietypowe koszty. Analiza logów powinna uwzględniać czas, adresy źródłowe, typy żądań i identyfikator użytego poświadczenia, o ile usługa je rejestruje. Warto także przejrzeć inne gałęzie, artefakty budowania oraz kopie repozytorium. Jeżeli sekret został zapisany w historii, można przepisać historię za pomocą odpowiednich narzędzi do oczyszczania repozytorium, lecz jest to działanie porządkowe, a nie zastępstwo unieważnienia tokenu. Wszystkie osoby i systemy korzystające ze starej wartości muszą otrzymać nową konfigurację.

Bezpieczne przechowywanie poświadczeń w codziennym kodzie

W kodzie źródłowym powinny znajdować się nazwy zmiennych konfiguracyjnych, a nie ich rzeczywiste wartości. Sekrety należy dostarczać aplikacji przez mechanizm konfiguracji przeznaczony dla danego środowiska, z kontrolą dostępu i możliwością rotacji. Pliki lokalne zawierające wartości poufne powinny być wyłączone z repozytorium za pomocą reguł ignorowania, ale sam wpis w pliku ignorowania nie usuwa pliku już wcześniej dodanego do historii. Przydatne są skanery sekretów uruchamiane przed commitem i w potoku ciągłej integracji; ich wynik trzeba jednak weryfikować, ponieważ mogą wykrywać także przykładowe, nieaktywne ciągi.

Podczas diagnostyki laptopa lub komputera PC warto sprawdzić, czy podejrzane dane nie zostały zapisane w historii poleceń, plikach konfiguracyjnych, kopiach zapasowych, logach i narzędziach deweloperskich. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów stacjonarnych PC i ich podzespołów, w tym analizą problemów z oprogramowaniem na urządzeniu użytkownika. Przy podejrzeniu ujawnienia tokenu decyzje o jego unieważnieniu i zmianie uprawnień należy wykonać w konkretnej usłudze, która ten token wydała, ponieważ lokalne usunięcie pliku nie cofa dostępu nadanego aktywnemu poświadczeniu.