Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Klucze API od lat pozostają jednym z najczęściej wykorzystywanych mechanizmów dostępu do usług chmurowych i interfejsów programistycznych. W praktyce bezpieczeństwa zakłada się, że ich usunięcie lub unieważnienie powinno natychmiast odciąć możliwość dalszego wykonywania żądań. Najnowsze ustalenia dotyczące Google Cloud pokazują jednak, że rzeczywistość może być bardziej złożona.
Opisany problem dotyczy opóźnienia propagacji unieważnienia klucza API. Oznacza to, że po formalnym usunięciu sekretu z panelu administracyjnego część infrastruktury może przez pewien czas nadal akceptować żądania podpisane tym samym kluczem. Z punktu widzenia bezpieczeństwa to istotna rozbieżność między oczekiwanym a rzeczywistym zachowaniem systemu.
W skrócie
Badacz bezpieczeństwa wykazał, że wybrane klucze API Google mogły pozostawać skuteczne nawet do około 23 minut po usunięciu. Mediana zaobserwowanego czasu wygaszania wyniosła około 16 minut, a najkrótsze przypadki mieściły się w granicach około 8 minut.
To oznacza, że przejęty lub wyciekły klucz może być nadal nadużywany mimo jego skasowania w konsoli. Dla zespołów SOC, administratorów i specjalistów IR to ważny sygnał, że operacja usunięcia sekretu nie zawsze oznacza natychmiastowe zamknięcie ryzyka.
Kontekst / historia
Opóźnienia w unieważnianiu poświadczeń nie są zjawiskiem nowym i wcześniej pojawiały się także w kontekście innych dostawców usług chmurowych. W środowiskach rozproszonych część operacji działa w modelu spójności ostatecznej, przez co zmiany nie zawsze są natychmiast widoczne we wszystkich komponentach systemu.
W przypadku Google Cloud dodatkowego znaczenia nabiera sposób zarządzania kluczami API. Dokumentacja opisuje usunięcie jako operację oznaczającą klucz stanem DELETED, przy czym sam obiekt może jeszcze pozostawać w systemie w okresie retencji i potencjalnie zostać przywrócony. Jednocześnie użytkownicy mają uzasadnione oczekiwanie, że klucz oznaczony jako usunięty nie będzie już używalny operacyjnie.
To właśnie napięcie między dokumentowanym stanem administracyjnym a faktycznym zachowaniem infrastruktury sprawia, że sprawa ma znaczenie nie tylko techniczne, ale również proceduralne i audytowe.
Analiza techniczna
Według opisanych testów badawczych proces polegał na utworzeniu klucza API, jego usunięciu, a następnie wielokrotnym wysyłaniu uwierzytelnionych żądań w celu sprawdzenia, jak długo system nadal akceptuje ten sam sekret. Wyniki okazały się nieregularne, co sugeruje brak pełnej spójności w czasie wygaszania dostępu.
Najbardziej prawdopodobnym wyjaśnieniem jest rozproszona propagacja informacji o unieważnieniu. W praktyce różne węzły, warstwy routingu, mechanizmy cache lub komponenty odpowiedzialne za weryfikację poświadczeń mogą przez pewien czas operować na niespójnym stanie. W efekcie to samo żądanie może zostać odrzucone przez jeden element infrastruktury, a zaakceptowane przez inny.
W badaniu zwrócono również uwagę na różnice zależne od regionu inicjowania ruchu. To sugeruje, że lokalizacja geograficzna, ścieżka obsługi żądania lub architektura pośrednicząca mogą mieć wpływ na to, jak długo usunięty klucz pozostaje skuteczny. Dla obrońców oznacza to większą trudność w oszacowaniu rzeczywistego momentu pełnej neutralizacji zagrożenia.
Istotnym problemem pozostaje także widoczność takich zdarzeń w monitoringu. Jeżeli organizacja opiera się wyłącznie na statusie klucza widocznym w konsoli administracyjnej, może uznać incydent za zamknięty zbyt wcześnie, mimo że część żądań nadal przechodzi poprawnie.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem jest fałszywe poczucie bezpieczeństwa po wykryciu wycieku klucza API. W standardowym scenariuszu administrator usuwa sekret i zakłada, że nadużycia zostały zatrzymane. Jeśli jednak klucz pozostaje aktywny jeszcze przez kilka lub kilkanaście minut, atakujący zyskuje dodatkowe okno działania.
W tym czasie możliwe są dalsze zapytania do usług, eksfiltracja danych, generowanie kosztów, testowanie uprawnień oraz rozszerzanie wiedzy o środowisku ofiary. Nawet relatywnie krótki okres dalszej aktywności może być wystarczający, by pobrać cenne informacje albo zainicjować kosztowne operacje w usługach chmurowych.
Ryzyko rośnie szczególnie wtedy, gdy klucz API zapewnia dostęp do systemów o wysokiej wartości biznesowej, usług analitycznych, interfejsów AI, usług mapowych, backendów aplikacyjnych lub innych zasobów produkcyjnych. Problem uderza też w procesy reagowania na incydenty, ponieważ klasyczne założenie „usuń sekret i zamknij sprawę” przestaje być w pełni wiarygodne.
- dodatkowe okno operacyjne dla atakującego po usunięciu klucza,
- możliwość dalszej eksfiltracji danych lub wykonywania kosztownych żądań,
- utrudniona analiza incydentu i ustalenie momentu pełnej neutralizacji,
- ryzyko błędnego zamknięcia incydentu przez zespół bezpieczeństwa,
- większa ekspozycja organizacji korzystających z szeroko uprzywilejowanych kluczy API.
Rekomendacje
Organizacje korzystające z Google Cloud powinny traktować usunięcie klucza API nie jako natychmiastowe odcięcie dostępu, lecz jako początek procesu wygaszania. W praktyce oznacza to konieczność utrzymania wzmożonego monitoringu jeszcze przez co najmniej kilkanaście lub kilkadziesiąt minut po usunięciu poświadczenia.
Kluczowe znaczenie ma ograniczanie uprawnień oraz zawężanie zakresu użycia kluczy API. Im mniejszy zestaw usług, aplikacji i źródeł ruchu dopuszcza dany klucz, tym mniejszy będzie wpływ jego ewentualnego dalszego działania po skasowaniu. Równolegle warto ograniczać stosowanie samych kluczy API wszędzie tam, gdzie możliwe jest użycie silniejszych mechanizmów uwierzytelniania.
Z perspektywy operacyjnej warto wdrożyć następujące działania:
- monitorowanie użycia kluczy i anomalii również po ich usunięciu,
- uwzględnienie bufora czasowego w procedurach reagowania na incydenty,
- dokumentowanie rzeczywistego czasu wygaszania dostępu w środowisku organizacji,
- segmentowanie projektów i usług, aby pojedynczy klucz nie dawał zbyt szerokiego dostępu,
- regularną rotację sekretów oraz ograniczanie ich obecności w kodzie, logach i pipeline’ach CI/CD,
- preferowanie krótkotrwałych tokenów, kont usługowych i innych bezpieczniejszych metod uwierzytelniania tam, gdzie to możliwe.
Podsumowanie
Przypadek Google API keys pokazuje, że w systemach rozproszonych samo usunięcie poświadczenia nie zawsze oznacza natychmiastowe odcięcie możliwości jego użycia. W badaniu odnotowano sytuacje, w których usunięty klucz pozostawał skuteczny nawet do około 23 minut, a zachowanie środowiska było nieregularne i zależne od infrastruktury.
Dla zespołów bezpieczeństwa najważniejszy wniosek jest praktyczny: klucze API należy traktować jako poświadczenia wysokiego ryzyka, a proces ich wycofywania musi być wsparty monitoringiem, ograniczaniem uprawnień oraz dodatkowymi kontrolami obronnymi. W przeciwnym razie luka między stanem widocznym w konsoli a rzeczywistym egzekwowaniem polityki może zostać wykorzystana przez atakującego.