Wprowadzenie do problemu / definicja
Tożsamości nieosobowe, określane jako NHI, obejmują konta usługowe, tokeny API, klucze dostępowe, workflow automatyzacji oraz agentów działających bez bezpośredniego udziału użytkownika. W nowoczesnych środowiskach chmurowych są one niezbędne do działania integracji, procesów CI/CD, orkiestracji usług oraz narzędzi opartych na AI. Problem zaczyna się wtedy, gdy organizacja traci pełną widoczność nad tym, które z tych tożsamości są aktywne, jakie mają uprawnienia i jakie relacje zaufania tworzą między systemami.
W praktyce oznacza to, że poza klasycznym zarządzaniem kontami pracowników firmy muszą dziś kontrolować również rozległy ekosystem tożsamości technicznych. To właśnie one coraz częściej stają się ukrytą powierzchnią ataku.
W skrócie
Badacz bezpieczeństwa Aleksandr Krasnov zwrócił uwagę na ryzyko związane z tzw. „ghost credentials”, czyli zapomnianymi, uśpionymi lub słabo nadzorowanymi poświadczeniami oraz tożsamościami nieosobowymi. Z jego ustaleń wynika, że pojedynczy wyciek klucza, tokena lub kompromitacja agenta workflow może otworzyć drogę do ruchu lateralnego w chmurze, eskalacji uprawnień, a nawet przejęcia ról administracyjnych.
- Problem dotyczy szczególnie środowisk silnie zautomatyzowanych.
- NHI często rosną szybciej niż możliwości ich monitorowania.
- Ukryte zależności między systemami utrudniają wykrywanie ryzyka.
Kontekst / historia
Punktem wyjścia dla opisywanej analizy był pozornie ograniczony incydent dotyczący odizolowanego konta chmurowego. Po około 30 dniach bezczynności agent workflow wspierany przez mechanizmy AI wznowił aktywność i zaczął wykonywać wywołania API o nietypowych porach. To uruchomiło analizę anomalii, która doprowadziła do odkrycia znacznie większego problemu.
W trakcie badania zidentyfikowano rozbudowaną sieć uśpionych poświadczeń, tokenów i kont usługowych funkcjonujących poza oczekiwanymi granicami zaufania. Sam problem nie jest całkowicie nowy, ale jego skala rośnie wraz z popularyzacją chmury, integracji SaaS, pipeline’ów developerskich oraz agentów AI. Organizacje zarządzają dziś nie tylko użytkownikami, lecz także setkami lub tysiącami technicznych tożsamości tworzonych automatycznie i dziedziczących uprawnienia między wieloma platformami.
Analiza techniczna
Techniczny rdzeń zagrożenia polega na tym, że tożsamości nieosobowe rzadko są modelowane i monitorowane równie dokładnie jak konta ludzkie. W efekcie tworzą się ukryte ścieżki zaufania. Przykładowo token wykorzystywany przez pipeline CI/CD może uruchomić workflow, workflow może uzyskać dostęp do menedżera sekretów, a ten z kolei może umożliwić pobranie kolejnych poświadczeń prowadzących do bardziej uprzywilejowanej roli w środowisku produkcyjnym.
„Ghost credentials” to nie tylko nieużywane sekrety. To także pozostałości po migracjach, tymczasowych integracjach, testach, wdrożeniach automatyzacji i projektach AI. Nawet jeśli dana tożsamość nie wykonuje codziennie operacji, może nadal zachowywać ważne relacje zaufania umożliwiające dalszą eskalację.
- dostęp do interfejsów API,
- pobranie lub odświeżenie tokenów,
- uruchamianie zadań w uprzywilejowanym kontekście,
- przejęcie roli przez federację lub impersonację,
- ruch lateralny między kontami, subskrypcjami lub tenantami.
Szczególnie niebezpieczne jest zaufanie pośrednie. Niskopoziomowa tożsamość może nie mieć bezpośrednio uprawnień administratora, ale dzięki łańcuchowi zależności doprowadzić do wykonania operacji równoważnych z uprawnieniami superadministratora. Takie scenariusze są trudne do wykrycia podczas klasycznych audytów opartych wyłącznie na statycznych listach ról.
Znaczenie ma również skala. Według przywołanych ustaleń pojedynczy programista może być powiązany nawet z 244 tożsamościami nieosobowymi. W dużych organizacjach graf zależności staje się więc bardzo złożony, a liczba ukrytych relacji zaufania rośnie szybciej niż możliwości ręcznej kontroli.
Konsekwencje / ryzyko
Najważniejszą konsekwencją jest gwałtowny wzrost powierzchni ataku w chmurze. Dla przeciwnika przejęcie porzuconego tokena lub słabo monitorowanego konta usługowego może być prostsze niż atak phishingowy skierowany przeciw pracownikowi. Tożsamości nieosobowe często nie korzystają z MFA, mają długi cykl życia i są mocno zintegrowane z systemami krytycznymi.
- Brak regularnej rotacji sekretów zwiększa ryzyko przejęcia dostępu.
- Nadmierne uprawnienia pozwalają na szybką eskalację.
- Słabsza analiza behawioralna utrudnia wykrycie nadużyć.
- Brak skutecznego offboardingu sprzyja pozostawianiu aktywnych poświadczeń.
Ryzyko obejmuje poufność, integralność i dostępność. Atakujący może wykorzystać taką tożsamość do kradzieży danych, manipulacji pipeline’ami wdrożeniowymi, utrwalenia dostępu, wyłączenia mechanizmów ochronnych albo przejęcia centralnego systemu tożsamości. Dla dużych przedsiębiorstw dodatkowym problemem pozostaje szum operacyjny, ponieważ nawet po wykryciu dziesiątek krytycznych zależności ustalenie priorytetów i szybka remediacja bywają bardzo trudne.
Rekomendacje
Organizacje powinny traktować tożsamości nieosobowe jako pełnoprawny obszar zarządzania tożsamością i bezpieczeństwem chmury. Konieczna jest nie tylko inwentaryzacja, lecz także ciągłe modelowanie zależności i aktywne ograniczanie ryzyka.
- Zbudować aktualny, ciągły rejestr wszystkich NHI, w tym kont usługowych, tokenów, sekretów, workflow i integracji SaaS.
- Mapować graf zaufania, aby rozumieć, które tożsamości mogą pośrednio przejmować role uprzywilejowane.
- Wdrożyć lifecycle management dla NHI, obejmujący właściciela biznesowego i technicznego, datę utworzenia, plan wycofania oraz recertyfikację uprawnień.
- Wymuszać rotację sekretów i automatyczne wygaszanie nieużywanych poświadczeń.
- Ograniczać uprawnienia zgodnie z zasadą least privilege i separacją obowiązków.
- Monitorować nietypowe zachowania, takie jak aktywacja po długiej bezczynności, wywołania API poza harmonogramem czy podejrzane sekwencje assume-role.
- Testować scenariusze abuse paths poprzez red teaming i ćwiczenia DevSecOps.
Podsumowanie
Rozrost tożsamości nieosobowych staje się jednym z kluczowych wyzwań bezpieczeństwa chmury. Problem nie sprowadza się wyłącznie do liczby tokenów i kont usługowych, lecz do ukrytych relacji zaufania łączących pozornie niskoprzywilejowane komponenty z systemami krytycznymi. W środowiskach silnie zautomatyzowanych pojedyncze, zapomniane poświadczenie może stać się punktem wejścia do pełnej kompromitacji.
Skuteczna obrona wymaga więc stałej widoczności nad NHI, modelowania grafu zaufania, ograniczania uprawnień i monitorowania ścieżek eskalacji. Bez tego organizacje będą coraz częściej narażone na ataki wykorzystujące niewidoczne zależności w chmurze.