Wprowadzenie do problemu
Publicznie ujawnione klucze dostępowe AWS należą do najpoważniejszych zagrożeń w bezpieczeństwie chmury. Takie poświadczenia umożliwiają programistyczny dostęp do zasobów, a jeśli są nadal aktywne i mają szerokie uprawnienia, mogą prowadzić do przejęcia infrastruktury, eksfiltracji danych, sabotażu usług oraz generowania bardzo wysokich kosztów operacyjnych.
Problem nie dotyczy wyłącznie pojedynczych błędów deweloperskich. Najnowsze ustalenia pokazują, że aktywne klucze AWS pozostają publicznie dostępne przez długi czas, co wskazuje na systemowy problem z rotacją sekretów, nadawaniem uprawnień i monitoringiem środowisk chmurowych.
W skrócie
Badacze ustalili, że ponad 9,3 tys. publicznie ujawnionych kluczy AWS pozostawało aktywnych w okresie od sierpnia 2022 do sierpnia 2026 roku. Wśród nich znalazły się setki kluczy powiązanych z kontami firmowymi, w tym poświadczenia root oraz klucze użytkowników IAM z bardzo szerokimi uprawnieniami administracyjnymi.
Oznacza to, że w części przypadków pojedynczy wyciek mógł umożliwić napastnikowi pełne przejęcie konta chmurowego organizacji. Sytuację pogarsza fakt, że wiele kluczy nie było wymienianych przez lata, a część firm nie wdrożyła nawet podstawowych alertów budżetowych i kosztowych.
Kontekst i historia
AWS od lat działa w modelu współdzielonej odpowiedzialności. Dostawca odpowiada za bezpieczeństwo infrastruktury bazowej, natomiast klient musi samodzielnie zabezpieczać tożsamości, konfigurację oraz dostęp do własnych zasobów. W praktyce jednym z najczęstszych błędów pozostaje publikowanie sekretów w publicznych repozytoriach, logach CI/CD, obrazach kontenerów, plikach konfiguracyjnych i innych artefaktach.
W analizowanym przypadku szczególnie niepokojące okazało się występowanie kluczy root. Są to poświadczenia powiązane z najwyżej uprzywilejowaną tożsamością w koncie AWS, dlatego ich ujawnienie należy traktować jako incydent krytyczny. Klucze tego typu mogą omijać wiele ograniczeń operacyjnych stosowanych wobec standardowych użytkowników i ról IAM.
Analiza techniczna
Klucze dostępowe AWS składają się z identyfikatora oraz sekretu i służą do podpisywania żądań do API. Jeśli taki zestaw trafi do źródła publicznego i nadal pozostaje aktywny, osoba nieuprawniona może wykonywać autoryzowane operacje w środowisku ofiary bez konieczności łamania haseł czy omijania klasycznych mechanizmów logowania.
Skala zagrożenia zależy od rzeczywistych uprawnień przypisanych do danej tożsamości. Najgroźniejsze są trzy scenariusze: użycie kluczy root, użycie kluczy użytkowników IAM z polityką administracyjną oraz przejęcie technicznych kont serwisowych, które pozornie mają ograniczone możliwości, ale pozwalają na eskalację uprawnień.
- odczyt i eksport danych z usług magazynowania i baz danych,
- uruchamianie lub modyfikację instancji obliczeniowych,
- tworzenie nowych kont administracyjnych i utrwalanie dostępu,
- usuwanie logów, snapshotów i kopii zapasowych,
- wdrażanie koparek kryptowalut lub innych nieautoryzowanych obciążeń,
- modyfikację polityk bezpieczeństwa, sieci i konfiguracji IAM.
Istotnym elementem analizy jest również wiek części ujawnionych kluczy. Wieloletni brak rotacji pokazuje, że wiele organizacji nadal opiera integracje i automatyzację na długoterminowych sekretach. To podejście znacząco zwiększa skutki pojedynczego wycieku, ponieważ kompromitacja może pozostać użyteczna przez bardzo długi czas.
Konsekwencje i ryzyko
Aktywny wyciek klucza AWS może oznaczać pełne naruszenie poufności, integralności i dostępności danych oraz usług. Atakujący może uzyskać dostęp do danych klientów, środowisk produkcyjnych, kodu źródłowego, backupów oraz innych sekretów przechowywanych w ekosystemie organizacji.
Drugim ważnym obszarem są straty finansowe. Przejęte konto może zostać użyte do uruchomienia kosztownych zasobów, farm obliczeniowych lub infrastruktury do kryptominingu. Jeśli organizacja nie ma aktywnych alertów budżetowych, wykrycie incydentu może nastąpić dopiero po zauważalnym wzroście rachunku lub po pogorszeniu jakości usług.
Trzecie ryzyko dotyczy trwałości ataku. Napastnik z szerokimi uprawnieniami może utworzyć nowe tożsamości, dodać własne klucze, zmienić polityki zaufania albo osłabić mechanizmy monitoringu. W takiej sytuacji samo unieważnienie jednego ujawnionego klucza może nie wystarczyć bez pełnego przeglądu całego konta i śladów nadużycia.
Rekomendacje
Każda organizacja korzystająca z AWS powinna traktować sekret opublikowany w źródle publicznym jako natychmiast skompromitowany. Reakcja musi obejmować zarówno działania doraźne, jak i zmianę modelu zarządzania tożsamością maszynową.
- przeprowadzenie pełnej inwentaryzacji kluczy dostępowych, ich właścicieli i wieku,
- natychmiastowe usunięcie kluczy root z użycia operacyjnego,
- rotację lub unieważnienie wszystkich ujawnionych poświadczeń,
- analizę logów pod kątem wcześniejszego nadużycia,
- migrację z długoterminowych kluczy do ról IAM i poświadczeń tymczasowych,
- ograniczanie uprawnień zgodnie z zasadą najmniejszych uprawnień,
- wdrożenie automatycznego skanowania repozytoriów, pipeline’ów CI/CD i artefaktów buildów,
- konfigurację alertów kosztowych i budżetowych,
- włączenie monitoringu aktywności API oraz alarmów o zmianach w IAM,
- regularne ćwiczenia reagowania na incydenty związane z przejęciem konta chmurowego.
Z perspektywy architektury bezpieczeństwa kluczowe jest odejście od statycznych sekretów wszędzie tam, gdzie to możliwe. Role IAM, federacja tożsamości i krótkotrwałe tokeny znacząco ograniczają skutki pojedynczego wycieku i poprawiają kontrolę nad dostępem.
Podsumowanie
Wyciek kluczy AWS to nie tylko problem higieny deweloperskiej, ale realny wektor pełnego przejęcia środowiska chmurowego. Najgroźniejsze pozostają aktywne klucze root i poświadczenia z uprawnieniami administracyjnymi, które mogą zapewnić napastnikowi praktycznie nieograniczoną kontrolę nad kontem organizacji.
Najskuteczniejszą linią obrony pozostają eliminacja kluczy root, redukcja długoterminowych sekretów, ciągłe skanowanie wycieków, ścisłe zarządzanie uprawnieniami oraz monitoring kosztów i aktywności API. Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona tożsamości maszynowej musi być traktowana tak samo poważnie jak zabezpieczanie kont uprzywilejowanych.
Źródła
- Hundreds of leaked AWS keys give full control over corporate accounts — https://www.bleepingcomputer.com/news/security/hundreds-of-leaked-aws-keys-give-full-control-over-corporate-accounts/
- Secure access keys – AWS Identity and Access Management — https://docs.aws.amazon.com/IAM/latest/UserGuide/securing_access-keys.html
- Root user best practices for your AWS account — https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html
- Best practices for AWS Budgets — https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html
- AWS Identity and Access Management Best Practices — https://aws.amazon.com/iam/resources/best-practices/