klucz API widoczny w repozytorium

Klucz API widoczny w repozytorium to wyciek poświadczeń wynikający z zapisania go w kodzie źródłowym projektu.

Jak klucz API trafia do repozytorium

Klucz API widoczny w repozytorium jest poświadczeniem zapisanym w miejscu, które może zostać odczytane przez osoby lub systemy mające dostęp do kodu projektu. Najczęściej pojawia się w pliku konfiguracyjnym, skrypcie, przykładzie integracji, notatniku programistycznym albo w zmiennej wpisanej bezpośrednio do kodu źródłowego. Sam fakt, że plik znajduje się w prywatnym repozytorium, nie oznacza jeszcze, że klucz jest bezpieczny. Dostęp mogą mieć członkowie zespołu, konta automatyzacji, kopie zapasowe, systemy ciągłej integracji oraz narzędzia synchronizujące zawartość projektu.

Problem dotyczy nie tylko aktywnego pliku. System kontroli wersji, taki jak Git, przechowuje historię zmian, dlatego usunięcie klucza z bieżącej wersji nie usuwa go automatycznie z wcześniejszych commitów. Klucz może pozostać także w tagach, gałęziach, pull requestach, artefaktach kompilacji lub lokalnych kopiach repozytorium. Z tego powodu publiczne ujawnienie poświadczenia należy traktować jako możliwy wyciek, nawet jeśli wpis został szybko skasowany z aktualnego kodu.

Dlaczego ujawnione poświadczenie stwarza ryzyko

Klucz API służy do identyfikowania aplikacji lub klienta podczas wywoływania określonej usługi. Zakres skutków zależy od dostawcy API oraz uprawnień przypisanych do konkretnego klucza. Ujawnione poświadczenie może pozwolić na wykonywanie żądań w imieniu projektu, wykorzystanie przydzielonego limitu, generowanie kosztów, odczyt danych dostępnych dla danego konta albo modyfikowanie zasobów, jeśli klucz otrzymał uprawnienia zapisu. Nie każdy klucz daje taki sam dostęp, dlatego ocena wymaga sprawdzenia jego zakresu, ograniczeń i historii użycia po stronie dostawcy.

Ryzyko zwiększa się, gdy klucz nie ma ograniczenia pochodzenia żądań, listy dozwolonych adresów, limitu wykorzystania lub zawężonych uprawnień. Znaczenie ma również czas ekspozycji i zasięg repozytorium. W publicznym projekcie wartość może zostać skopiowana przez automatyczne skanery niemal natychmiast po opublikowaniu commitu. W projekcie prywatnym zagrożenie może wynikać z przejęcia konta, błędnej konfiguracji dostępu albo niekontrolowanego udostępnienia kopii kodu.

Postępowanie po wykryciu klucza w kodzie

Pierwszą czynnością powinno być unieważnienie albo rotacja klucza u dostawcy usługi. Samo usunięcie wpisu z pliku nie odbiera uprawnień poświadczeniu, które mogło już zostać skopiowane. Jeżeli dostawca obsługuje osobne operacje revoke i rotate, należy zastosować procedurę odpowiednią dla danego typu klucza. Następnie trzeba sprawdzić logi użycia, limity, naliczenia oraz operacje wykonane w okresie, w którym poświadczenie mogło być dostępne.

Po unieważnieniu klucza należy wyszukać jego wystąpienia w całej historii Git, wszystkich gałęziach, tagach, plikach konfiguracyjnych i artefaktach generowanych przez proces budowania. Przydatne jest skanowanie sekretów rozpoznające wzorce charakterystyczne dla danego dostawcy, ale wynik narzędzia trzeba zweryfikować ręcznie, ponieważ ciągi znaków podobne do kluczy mogą być fałszywymi alarmami. Jeżeli repozytorium było publiczne, trzeba uwzględnić możliwość istnienia forków, klonów i zapisanych kopii, których nie da się unieważnić samą zmianą w głównym projekcie.

Bezpieczne przechowywanie konfiguracji projektu

Aktywne klucze API powinny być dostarczane aplikacji poza kodem źródłowym, na przykład przez zmienne środowiskowe, bezpieczny magazyn sekretów albo mechanizm poświadczeń dostępny w środowisku uruchomieniowym. Pliki zawierające lokalną konfigurację trzeba wyłączyć z repozytorium za pomocą odpowiednich reguł ignorowania, lecz nie należy traktować pliku ignorowanego jako zamiennika rotacji już ujawnionego klucza. Do repozytorium można dołączyć plik przykładowy zawierający nazwy wymaganych zmiennych bez ich rzeczywistych wartości.

Warto ograniczać uprawnienia każdego klucza do funkcji, które są rzeczywiście potrzebne, ustawiać limity i ograniczenia po stronie dostawcy oraz utrzymywać automatyczne skanowanie commitów i zmian przed ich publikacją. Diagnostyka problemów z konfiguracją może obejmować sprawdzenie, czy program odczytuje właściwą zmienną, czy nie korzysta z zakodowanego fallbacku oraz czy po rotacji wszystkie uruchomione komponenty otrzymały nową wartość. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów, a w przypadku komputera używanego do pracy z kodem może pomóc zdiagnozować lokalne źródło błędu konfiguracji oraz nieprawidłowe przechowywanie plików projektu.