Wyciekły klucz cloud nie jest zdarzeniem z przeszłości. To aktywne logowanie, dopóki ktoś go nie zrotuje, nie usunie i nie sprawdzi, do czego mógł prowadzić. Badanie Truffle Security z sierpnia 2026 roku pokazuje właśnie ten problem: nie tylko sekrety trafiły publicznie, ale wiele z nich żyło później bardzo długo.

Abstrakcyjna konsola chmurowa z ujawnionym kluczem, taśmą kwarantanny i listą rotacji

Truffle Security zebrało 431 875 zweryfikowanych znalezisk sekretów AWS, zredukowało je do 64 024 unikalnych access keys w 50 654 kontach i ponownie sprawdziło 10 616 pełnych par kluczy ujawnionych publicznie między sierpniem 2022 a sierpniem 2026. 88% nadal się uwierzytelniało. Z 9 308 aktywnych kluczy 817 powiązano z firmami, a 768 dawało pełną kontrolę nad kontem AWS: 526 root keys i 242 użytkowników IAM z AdministratorAccess.

BleepingComputer, The Register i TNW szybko opisały sprawę. Corey Quinn w The Register przeniósł dyskusję na AWSCompromisedKeyQuarantineV3. AWS opisuje tę politykę jako ograniczenie części szkód fraud-related bez wpływu na istniejące zasoby. Krytyka jest prosta: kwarantanna nie jest naprawą. Może ograniczyć część nadużyć, ale zostawić ryzyko resztkowe.

To dobry temat bez paniki, bo wnioski są praktyczne. Root access keys prawie nigdy nie powinny istnieć. Długowieczne IAM access keys muszą mieć właściciela, termin życia i rotację. Sekret w Git history, obrazie Docker, logu CI, notebooku lub datasecie należy traktować jak opublikowany. Quarantine policy zaczyna incident response, a nie go kończy.

Co znaleziono

Duża liczba 431 875 obejmuje powtórzenia w forkach, mirrorach, logach, obrazach i datasetach. Ważniejsze są 64 024 unikalne klucze i 10 616 pełnych par sprawdzonych 10 sierpnia 2026 roku. 9 308 działało.

Część biznesowa była mniejsza, ale groźniejsza. 817 aktywnych kluczy wiązało się z firmami, a 768 miało pełną kontrolę administracyjną. Szczególnie niebezpieczne było 130 żywych root keys na organization management accounts. To nie jest tylko zapomniany sekret developera; czasem to klucz główny całej organizacji.

Wiek pogarsza obraz. Mediana wieku żywego wyciekłego klucza wyniosła 1 831 dni. Wiele credentials było publicznych przez lata. Truffle Security podało też, że tylko 13,7% przypadków miało nowszy klucz obok wyciekłego. To wygląda bardziej jak brak rotacji niż kontrolowany proces.

Hugging Face pojawił się jako duże źródło kluczy w publicznych datasetach. Nie należy tego czytać jako nowego włamania do Hugging Face. Chodzi o to, że datasety ML, notebooki i repozytoria modeli dziedziczą stary problem repozytoriów kodu: artefakty czasem zawierają credentials.

Dlaczego root jest inny

IAM key może być groźny. Root access key jest gorszy. Root user reprezentuje samo konto AWS. AWS zaleca chronić root credentials, nie używać root na co dzień i korzystać z IAM Identity Center, ról oraz tymczasowych credentials.

Różnica to zakres. IAM identity można ograniczać uprawnieniami, warunkami i politykami organizacji. Root stoi ponad dużą częścią tej struktury. Wyciek root key dotyczy billing, ustawień konta, odzyskiwania i czasem management account organizacji.

Root keys przeżywają właścicieli. Inżynierowie odchodzą, kontraktorzy znikają, stara automatyzacja dalej używa jednego klucza, który kiedyś działał. Nikt nie chce go ruszać z obawy przed awarią. Właśnie dlatego jest groźny.

Dojrzały program cloud powinien zawsze wiedzieć: czy istnieją root access keys, kto je zatwierdził i kiedy znikną. Brak odpowiedzi oznacza brak kontroli.

Usunięcie linii nie wystarczy

Gdy credential trafi do publicznego artefaktu, trzeba zakładać kopie. Usunięcie z ostatniego commita nie czyści historii Git. Zamknięcie repozytorium nie usuwa forków, mirrorów, cache, warstw Docker, logów CI, notebooków, indeksów i datasetów.

Wyciekły AWS key należy traktować jak opublikowane hasło. Trzeba go zrotować lub usunąć, sprawdzić użycie, zależności i aktywność. Przy root albo AdministratorAccess dochodzi CloudTrail, billing, inventory sekretów i szukanie persistence.

Częsty błąd brzmi: “usunąłem linię”. Poprawna lekcja: “linia ujawniła credential, który trzeba zastąpić”. To różnica między czyszczeniem pliku a zamknięciem dostępu.

Docker i ML utrudniają sprawę. Klucz może zostać w starej warstwie obrazu, output cell notebooka, debug logu, corpusie benchmarku albo ZIP. Secret management musi skanować więcej niż główne repo.

Co oznacza kwarantanna AWS

AWSCompromisedKeyQuarantineV3 to AWS managed policy. Dokumentacja mówi, że używa się jej przy compromised or publicly exposed IAM credentials, aby odmówić części akcji i ograniczyć szkody fraud-related bez wpływu na istniejące zasoby.

To ostatnie jest kluczowe. To harm reduction, nie remediacja. Quarantined key jest sygnałem incydentu. Nie dowodzi bezpieczeństwa konta. Jeśli polityka ma nie łamać istniejących zasobów, część ścieżek może nadal działać.

Corey Quinn krytykuje właśnie residual risk: operacje bazodanowe, sesje administracyjne, AssumeRole, logi audytowe, messaging, odczyt sekretów, backupy i zmiany infrastruktury. Nie trzeba robić z tego instrukcji ataku, aby wyciągnąć wniosek obronny: quarantine is a temporary guardrail, not incident closure.

Dylemat jest realny. Automatyczne wyłączenie każdego publicznego klucza może złamać produkcję klienta. Pozostawienie go aktywnym ogranicza outage, ale utrzymuje exposure. Dlatego organizacje potrzebują własnego playbooka rotacji.

Co sprawdzić dzisiaj

Zacznij od root. W każdym koncie AWS sprawdź root access keys. Jeśli istnieją, ustal powód, właściciela, ostatnie użycie i datę usunięcia. Dla większości firm stan docelowy to zero root keys, root z MFA i tylko do wyjątkowych zadań.

Zrób inventory IAM access keys. Sortuj według wieku, last-used, właściciela, workload i permission level. AdministratorAccess, wildcard permissions, brak właściciela, brak rotacji albo brak użycia to priorytet.

Szukaj AWSCompromisedKeyQuarantine attachments. Jeśli AWS ustawił kwarantannę, traktuj to jako incident signal. Znajdź credential, zrotuj, usuń stary, sprawdź CloudTrail, billing, anomalies i AssumeRole paths.

Skanuj więcej niż kod: Git history, forks, registries, container images, build logs, CI variables, notebooks, support bundles, public datasets i model repositories. Sekrety żyją dziś w data artifacts.

Zastępuj static credentials. CI/CD powinno używać OIDC federation i krótkich ról. Ludzie powinni używać IAM Identity Center lub federation. Workloads powinny używać scoped roles. Legacy keys muszą mieć owner, expiry i monitoring.

Rotacja bez awarii

Strach przed outage wyjaśnia, czemu klucze żyją latami. Nagłe usunięcie może zepsuć build, backup, pipeline albo stary serwis. Rozwiązaniem jest evidence-based rotation.

Najpierw ustal principal i używane usługi. CloudTrail, IAM last accessed, logi aplikacji i anomalie kosztów pomagają. Potem znajdź właściciela, zbuduj replacement path z mniejszymi permissions, wdroż z monitoringiem i usuń stary key. Jeśli trzeba czekać, wyjątek musi mieć datę końca i właściciela.

Dla root i AdministratorAccess zakładaj możliwe użycie przez obcych. Sprawdź API activity, dostęp do sekretów, AssumeRole, IAM changes, bucket policies, backups i nietypowe koszty. Budget alerts i anomaly detection są podstawą.

Cel to rutynowa rotacja przed awarią. Zespół, który zna właścicieli, reaguje w godzinach. Zespół bez ownerów tygodniami negocjuje z compromised key.

Wniosek

Badanie nie znaczy, że każde konto AWS jest przejęte. Nie znaczy też, że kwarantanna AWS jest bezużyteczna albo że trzeba usuwać losowe klucze. Panika psuje produkcję; zaprzeczanie tworzy incydenty.

Proporcjonalna reakcja: każdy publiczny credential traktować jako compromised, usuwać root keys, zastępować long-lived IAM keys rolami i federation, skanować prawdziwe artefakty, reagować na quarantine, ćwiczyć rotację i trzymać billing alerts.

Najbardziej niewygodne jest to, że cloud access często psuje się po cichu. Klucz wycieka, skaner ostrzega, provider ogranicza część akcji, ktoś usuwa linię i wszyscy idą dalej. Credential nadal działa. To naprawia ownership, inventory, short-lived credentials i dyscyplina.