Niegdyś nieszkodliwe klucze API, używane do wyświetlania map czy filmów z YouTube, stały się nagle przepustką do prywatnych danych i systemów AI. Błąd w architekturze uprawnień Google sprawił, że tysiące organizacji nieświadomie udostępniło postronnym osobom dostęp do swoich modeli językowych oraz poufnych dokumentów.
Najważniejsze w skrócie:
- Ponad 2800 aktywnych kluczy API należących do dużych firm finansowych i technologicznych zostało znalezionych w publicznym kodzie stron WWW.
- Cicha zmiana statusu: Klucze, które wcześniej służyły jedynie do identyfikacji projektu (np. w Google Maps), po włączeniu usług AI zyskały uprawnienia do autoryzacji w modelach Gemini.
- Ryzyko finansowe i prywatności: Atakujący mogą nie tylko generować ogromne koszty na koncie ofiary, ale też wyciągać dane z plików i historii czatów połączonych z projektem.
- Reakcja Google: Firma wprowadziła poprawki blokujące wyciekłe klucze, jednak eksperci ostrzegają, że problem „nadmiarowych uprawnień” jest systemowy.
Od mapy do poufnych czatów: Mechanizm „cichej” eskalacji
W świecie programowania Google API keys o prefiksie „AIza” przez lata uchodziły za stosunkowo bezpieczne do umieszczania bezpośrednio w kodzie JavaScript po stronie klienta. Deweloperzy używali ich do osadzania map, widżetów YouTube czy usług Firebase. Google w swojej dokumentacji wręcz sugerowało taką praktykę, traktując te klucze bardziej jako identyfikatory projektu niż tajne hasła.
Wszystko zmieniło się wraz z premierą Gemini. Gdy organizacje zaczęły aktywować w swoich istniejących projektach Google Cloud usługę Generative Language API, stare klucze „mapowe” automatycznie dziedziczyły uprawnienia do modeli AI. Problem polega na tym, że te same klucze, które wciąż widnieją w kodzie źródłowym stron internetowych, pozwalają teraz każdemu na wykonywanie zapytań do modeli LLM na koszt właściciela.
Skala problemu: Tysiące otwartych furtek
Badacze z TruffleSecurity, wykorzystując dane z Common Crawl, zidentyfikowali blisko 3000 takich kluczy należących do kluczowych instytucji. Co gorsza, firma Quokka po przeanalizowaniu 250 tysięcy aplikacji mobilnych na Androida, znalazła aż 35 tysięcy wyeksponowanych kluczy.
Nie jest to jedynie problem teoretyczny. Jeden z użytkowników serwisu [podejrzany link usunięto] zgłosił, że przejęty klucz Google Cloud API wygenerował na jego koncie rachunek w wysokości 82 314 USD w ciągu zaledwie dwóch dni. To drastyczny przeskok w porównaniu do standardowego miesięcznego kosztu na poziomie 180 USD.
Ewolucja zagrożenia: Jak "bezpieczny" klucz stał się wytrychem
Jak sprawdzić, czy Twój projekt jest zagrożony?
Większość administratorów nie zdaje sobie sprawy, że ich klucze „nagle” stały się wrażliwe. Eksperci zalecają natychmiastowy audyt w konsoli Google Cloud:
- Weryfikacja usług: Sprawdź, czy w projekcie włączone jest „Generative Language API”.
- Ograniczenia kluczy: Nowe klucze tworzone przez AI Studio domyślnie mają ograniczony zakres, ale te starsze często są oznaczone jako „Unrestricted” (Nieograniczone).
- Rotacja: Każdy klucz widoczny w publicznym kodzie JavaScript powinien zostać uznany za skompromitowany, zrotowany i zastąpiony mechanizmem backendowym.
W przeciwieństwie do konkurencyjnych rozwiązań, takich jak Anthropic czy OpenAI, gdzie klucze API od początku traktowane są jako ściśle tajne „secrets”, Google oparło swój system na architekturze, która zatarła granicę między publicznym identyfikatorem a prywatnym poświadczeniem.
Dlaczego to ważne? (Analiza)
Ten incydent to podręcznikowy przykład zjawiska znanego jako „privilege escalation after the fact” (wsteczna eskalacja uprawnień). Pokazuje on fundamentalne ryzyko związane z ewolucją ekosystemów chmurowych. W 2019 roku wystawienie klucza do map było co najwyżej niechlujstwem, które mogło skutkować kradzieżą limitów na wyświetlanie lokalizacji. W 2026 roku ten sam klucz staje się kluczem do „mózgu” firmy.
Problem jest głębszy niż zwykły błąd w kodzie. Wynika on z próby nałożenia nowoczesnych, niezwykle potężnych narzędzi Agentic AI na stare struktury zarządzania uprawnieniami. W dobie, gdy modele AI mają dostęp do firmowych plików na Google Drive, e-maili czy baz danych, każdy wyciekły klucz to potencjalna całkowita kompromitacja danych.
Dla branży cyberbezpieczeństwa jest to sygnał ostrzegawczy: nie istnieją już „niegroźne” dane uwierzytelniające. W miarę jak dostawcy usług integrują AI z każdym aspektem swoich platform, granice między tym, co publiczne, a tym, co poufne, ulegają niebezpiecznemu rozmyciu. Firmy muszą przestać polegać na „bezpieczeństwie przez ukrycie” i przejść na model zero-trust, gdzie żaden klucz po stronie klienta nie ma prawa dostępu do zasobów o wysokim stopniu krytyczności.
Co dalej?
- Automatyczne blokady: Google ogłosiło wdrożenie mechanizmów proaktywnie wykrywających i blokujących klucze Gemini, które pojawią się w publicznych repozytoriach.
- Zmiana domyślnych ustawień: Nowe projekty w Google Cloud mają mieć domyślnie włączone restrykcje zakresu (scoping), co uniemożliwi jednemu kluczowi obsługę zbyt wielu usług jednocześnie.
- Audyt deweloperski: Firmy powinny spodziewać się fali audytów i aktualizacji bibliotek klienckich, które wymuszą przeniesienie logiki AI całkowicie na stronę serwera (backend).
Źródło: The Hacker News, TruffleSecurity, BleepingComputer.
