Ponad 9300 wyciekłych kluczy AWS nadal działało po latach

Samo pojawienie się danych w publicznym repozytorium nie przesądza jeszcze, że konto jest nadal zagrożone. Ryzyko staje się realne, gdy klucz nie został unieważniony, wciąż działa i zachował istotne uprawnienia. W analizowanej próbie te trzy warunki często występowały jednocześnie.

768 kluczy dawało pełną kontrolę nad firmowymi kontami

Wśród aktywnych kluczy przypisanych do kont firmowych 817 należało do przedsiębiorstw. W tej grupie znalazły się:

• 526 kluczy konta głównego AWS (root account),
• 242 klucze użytkowników IAM powiązane z polityką AdministratorAccess,
• 768 kluczy łącznie, które zapewniały pełną administracyjną kontrolę nad firmowym kontem AWS.

Dane dostępowe konta głównego zapewniają najwyższy poziom kontroli dostępny klientowi AWS. Z kolei tożsamość IAM z polityką AdministratorAccess może wykonywać operacje w wielu usługach AWS, korzystając z bardzo szerokiego zakresu uprawnień. Aktywny klucz na którymkolwiek z tych poziomów może otworzyć drogę do przejęcia konta, nieuprawnionego tworzenia zasobów, dostępu do danych lub nadużyć rozliczeniowych w chmurze.

Wyniki wskazują więc nie tylko na problem higieny kodu źródłowego, lecz także na niedociągnięcia w zarządzaniu uprawnieniami i cyklem życia poświadczeń. Usunięcie klucza z widocznego pliku nie chroni konta, jeśli ktoś wcześniej skopiował dane. Klucz trzeba unieważnić albo wymienić.

Hugging Face było największym pojedynczym źródłem

Serwis Hugging Face odpowiadał za 8482 ujawnienia poświadczeń AWS, co czyniło go największym pojedynczym źródłem wskazanym w analizie. Truffle Security podało, że 17,9 proc. tych poświadczeń stanowiły dane dostępowe kont głównych.

Wynik ten wpisuje się w szersze skanowanie publicznych danych Hugging Face. Truffle Security poinformowało, że przeanalizowało 7,6 petabajta publicznych zbiorów danych i znalazło aktywne poświadczenia w tysiącach z nich. Pokazuje to, że sekrety mogą przetrwać nie tylko w tradycyjnych repozytoriach oprogramowania, lecz także w publicznie rozpowszechnianych danych.

Dla zespołów bezpieczeństwa wniosek jest prosty: skanowanie wyłącznie bieżących repozytoriów nie wystarczy. Klucze mogą pozostać w historii Git, artefaktach kompilacji, obrazach kontenerów, rejestrach, opublikowanych zbiorach danych i logach CI — nawet gdy programiści są przekonani, że już je usunęli.

Wiele kluczy miało kilka lat i prawie nie było rotowanych

Mediana wieku analizowanych poświadczeń wynosiła około 1831 dni, czyli mniej więcej pięć lat. Najstarszy klucz miał 17,4 roku. Tylko 13,7 proc. wpisów miało nowszy klucz powiązany z tym samym użytkownikiem, co sugeruje, że większość nie była wymieniana w ramach regularnej rotacji.

Długowieczne klucze zwiększają czas, w którym mogą zostać wykorzystane bez zgody właściciela, i utrudniają ustalenie, kto powinien się nimi zajmować. Mogą przetrwać zmiany kadrowe, migrację aplikacji, porządki w repozytorium i przekazanie odpowiedzialności między zespołami.

Wiek poświadczenia powinien być traktowany jako sygnał ryzyka. Kilkuletniego klucza znalezionego publicznie nie należy uznawać za nieaktualny bez weryfikacji. Powinien zostać sprawdzony, unieważniony i objęty analizą, chyba że jego właściciel potrafi potwierdzić, że nie jest już ważny.

Alerty budżetowe były rzadkością

Truffle Security mogło odczytać informacje o 2754 kontach, ale alerty budżetowe AWS były włączone tylko na 262 z nich.

Alerty budżetowe nie zastępują unieważniania kluczy ani wykrywania zagrożeń. Mogą jednak ostrzec o wykorzystaniu ujawnionych danych do uruchamiania kosztownych zasobów, na przykład w celu kopania kryptowalut lub innego nadużycia chmury. Bez powiadomienia, które trafia do osoby mogącej szybko zareagować, nietypowe wydatki mogą narastać także po przejęciu konta.

Co rozwiązują powiadomienia AWS, a czego nie

Opisane zabezpieczenia AWS mogą wykrywać ujawnione klucze dostępu, powiadamiać klientów i nakładać ograniczenia lub uruchamiać środki kwarantanny. Utrzymywanie się ważności tak wielu przetestowanych kluczy wskazuje jednak, że samo wykrycie lub powiadomienie nie zawsze prowadziło do szybkiego unieważnienia i wymiany poświadczeń po stronie klienta.

Wykrycie to dopiero pierwszy etap reakcji na wyciek. Pełna procedura powinna obejmować ustalenie właściciela, sprawdzenie zakresu dostępu, analizę ewentualnego nadużycia oraz unieważnienie klucza.

Truffle Security określa własną walidację jako odczytową: badacze sprawdzali uwierzytelnianie oraz metadane konta i uprawnień, nie modyfikując zasobów klientów. Ten opis metodologii pochodzi od Truffle Security i nie każdy szczegół został niezależnie potwierdzony przez wszystkie dostępne źródła.

Co zrobić po wycieku klucza AWS

1. Natychmiast unieważnić lub wymienić klucz

Należy usunąć albo wyłączyć każde publicznie ujawnione poświadczenie, a następnie wydać nowe tylko wtedy, gdy dostęp jest nadal potrzebny. Usunięcie sekretu z repozytorium, skasowanie pliku czy przepisanie historii Git nie unieważnia kopii, które mogły już zostać pobrane.

2. Usunąć klucze konta głównego

Klucze użytkownika root AWS nie powinny służyć do codziennego dostępu programistycznego. Należy je usunąć, a obciążenia przenieść na kontrolowane tożsamości z możliwie wąskim zakresem uprawnień.

3. Sprawdzić uprawnienia i właściciela

Trzeba ustalić, do jakiego konta, użytkownika, usługi i zasobów należał klucz. Najwyższy priorytet powinny mieć klucze root, klucze z AdministratorAccess, szerokim dostępem do danych lub możliwością tworzenia infrastruktury.

4. Przeprowadzić analizę przed i po unieważnieniu

Warto przejrzeć aktywność uwierzytelniania, logi CloudTrail, zmiany w IAM, nowo utworzone zasoby i rozliczenia pod kątem podejrzanych działań. Unieważnienie zatrzymuje dalsze użycie ujawnionego klucza, ale nie odpowiada na pytanie, czy ktoś wykorzystał go wcześniej.

5. Zastąpić stałe klucze krótkotrwałymi tożsamościami

Tam, gdzie to możliwe, należy używać krótkotrwałych ról IAM i tożsamości obciążeń zamiast stałych kluczy dostępu. Zasada najmniejszych uprawnień ogranicza szkody, jakie może spowodować wyciek.

6. Włączyć alerty budżetowe i ustalić ścieżkę reakcji

Należy skonfigurować alerty AWS Budgets oraz monitorowanie anomalii kosztowych, a następnie kierować powiadomienia do osób, które mogą szybko podjąć działania. Monitoring finansowy jest dodatkowym zabezpieczeniem — nie zastępuje skanowania sekretów, rotacji poświadczeń ani przeglądu dostępu.

Najważniejsza lekcja

Najbardziej niepokojąca nie była sama liczba znalezionych sekretów, lecz ich połączenie: publiczne ujawnienie, dalsza ważność, wysokie uprawnienia, bardzo długi czas życia i słaby monitoring. Publiczne repozytoria oraz zbiory danych mogą przechowywać poświadczenia długo po tym, jak organizacja zapomni, gdzie ich używała. Skopiowany klucz może pozostać użyteczny aż do chwili, gdy zostanie wyraźnie unieważniony.

Bezpiecznym założeniem dla zespołów korzystających z chmury jest traktowanie każdego ujawnionego klucza AWS jako przejętego: trzeba natychmiast sprawdzić jego zasięg, unieważnić lub wymienić poświadczenie, a następnie zastąpić długowieczne klucze krótkotrwałymi tożsamościami o minimalnych uprawnieniach.