Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Tożsamości nie-ludzkie, takie jak konta usługowe, tokeny API, agenci automatyzacji, integracje CI/CD czy komponenty oparte na AI, stały się podstawowym elementem nowoczesnych środowisk chmurowych. Problem pojawia się wtedy, gdy ich liczba rośnie szybciej niż zdolność organizacji do zarządzania uprawnieniami, relacjami zaufania i cyklem życia poświadczeń. W efekcie powstają „martwe” lub uśpione tożsamości, które formalnie nie są używane na co dzień, ale nadal zachowują dostęp do wrażliwych zasobów.
W skrócie
Badacz bezpieczeństwa Aleksandr Krasnov opisał zjawisko „ghost credentials”, czyli ukrytych i często zapomnianych poświadczeń oraz tożsamości nie-ludzkich funkcjonujących poza tradycyjnym modelem zaufania w chmurze. Impulsem do analizy był incydent, w którym nieaktywny przez 30 dni agent workflow oparty na AI nagle wznowił wykonywanie nietypowych wywołań API. Dochodzenie wykazało istnienie łańcuchów zaufania umożliwiających ruch boczny i eskalację uprawnień, w tym potencjalny dostęp do systemów produkcyjnych oraz ról administracyjnych. W odpowiedzi powstało narzędzie open source NHI Hound, zaprojektowane do identyfikacji ukrytych relacji między tożsamościami ludzkimi i nie-ludzkimi oraz do oceny ryzyka wynikającego z nadmiernego zaufania.
Kontekst / historia
Środowiska chmurowe od lat rozwijają się w kierunku wysokiej automatyzacji. Rozbudowane pipeline’y DevOps, integracje SaaS, systemy zarządzania sekretami, kontenery, funkcje serverless i agenci AI tworzą gęstą sieć zależności operacyjnych. Każdy z tych elementów wymaga jakiejś formy uwierzytelnienia i autoryzacji, co prowadzi do gwałtownego wzrostu liczby tożsamości nie-ludzkich.
Tradycyjne modele IAM były projektowane głównie z myślą o użytkownikach końcowych i administratorach. W praktyce oznacza to, że wiele organizacji ma stosunkowo dojrzałe procesy dla kont pracowników, ale znacznie słabszą widoczność w obszarze kont usługowych, tokenów aplikacyjnych, kluczy dostępowych i relacji trust między systemami. To właśnie ta luka operacyjna staje się dziś atrakcyjnym wektorem ataku.
Według obserwacji Krasnova skala problemu rośnie szczególnie szybko w organizacjach intensywnie korzystających z automatyzacji i rozwiązań AI. Im większa liczba integracji, tym trudniej ustalić jedno źródło prawdy dla wszystkich tożsamości oraz ich faktycznych uprawnień.
Analiza techniczna
Sednem problemu nie jest samo istnienie tożsamości nie-ludzkich, lecz ich niejawna i skumulowana zdolność do budowania ścieżek eskalacji. Pojedynczy token o pozornie ograniczonym zakresie może w praktyce otwierać drogę do kolejnych zasobów poprzez dziedziczone role, delegowane uprawnienia, powiązania z pipeline’ami, federację z dostawcą tożsamości lub możliwość uruchamiania zadań z wyższym poziomem uprzywilejowania.
W opisanym przypadku analiza rozpoczęła się od anomalii związanej z aktywacją uśpionego agenta workflow. Kluczowym odkryciem było to, że nieaktywna tożsamość nadal posiadała ważne uprawnienia i mogła wykonywać działania wykraczające poza swój pierwotny kontekst biznesowy. Tego typu konto może być szczególnie niebezpieczne, ponieważ:
- rzadko pojawia się w codziennym monitoringu,
- często nie ma jednoznacznego właściciela biznesowego,
- bywa pomijane podczas przeglądów uprawnień,
- może pozostawać aktywne długo po zakończeniu projektu lub zmianie architektury.
Technicznie rzecz biorąc, atakujący może rozpocząć od przejęcia wycieku pojedynczego sekretu, tokena lub klucza API, a następnie mapować środowisko pod kątem możliwych relacji zaufania. Jeżeli dana tożsamość ma prawo do odczytu sekretów, uruchamiania zadań, modyfikacji konfiguracji IAM albo uzyskania dostępu do systemu pośredniczącego, możliwe staje się zbudowanie łańcucha prowadzącego do wyższych uprawnień. W skrajnym scenariuszu taki łańcuch może zakończyć się dostępem do systemu zarządzania tożsamością lub do kont administracyjnych w środowisku produkcyjnym.
Narzędzie NHI Hound ma odpowiadać właśnie na ten problem. Agreguje dane o tożsamościach z różnych źródeł, takich jak platformy IAM, repozytoria kodu czy dostawcy tożsamości, a następnie rekonstruuje graf zależności i poziomów zaufania. Na tej podstawie wskazuje, które relacje są krytyczne, gdzie występują ukryte ścieżki nadużyć oraz które poświadczenia mogą umożliwić nieproporcjonalnie szeroki dostęp.
Konsekwencje / ryzyko
Ryzyko związane z niekontrolowanym rozrostem tożsamości nie-ludzkich jest wielowymiarowe. Po pierwsze, zwiększa się powierzchnia ataku. Każdy dodatkowy token, sekret i konto usługowe to potencjalny punkt wejścia. Po drugie, maleje przejrzystość środowiska, co utrudnia zarówno prewencję, jak i reagowanie na incydenty.
Najpoważniejsze konsekwencje obejmują:
- ruch boczny między usługami i kontami chmurowymi,
- eskalację uprawnień do ról administracyjnych,
- nieautoryzowany dostęp do systemów produkcyjnych,
- kompromitację dostawcy tożsamości i przejęcie kontroli nad federacją,
- utratę integralności pipeline’ów CI/CD,
- długotrwałą obecność napastnika dzięki poświadczeniom, które nie są regularnie rotowane.
Istotnym problemem jest również skala. W większych organizacjach liczba relacji zaufania może być tak duża, że klasyczne audyty ręczne przestają być skuteczne. Wtedy nawet wykrycie anomalii nie oznacza szybkiego zrozumienia pełnego łańcucha zależności. Dodatkowo środowiska oparte na AI i automatyzacji często generują nowe byty tożsamości dynamicznie, co utrudnia utrzymanie aktualnej inwentaryzacji.
Rekomendacje
Organizacje powinny traktować tożsamości nie-ludzkie jako pełnoprawny obszar zarządzania ryzykiem, a nie jako techniczny detal infrastruktury. W praktyce oznacza to potrzebę wdrożenia kilku równoległych działań.
Po pierwsze, konieczna jest pełna inwentaryzacja wszystkich tożsamości nie-ludzkich wraz z przypisaniem właściciela, celu biznesowego, zakresu uprawnień i daty ważności. Każde konto usługowe, token i sekret powinny mieć jasny cykl życia.
Po drugie, należy regularnie analizować graf zależności i zaufania, a nie tylko listę uprawnień przypisanych bezpośrednio. Wiele krytycznych ścieżek ataku wynika z kombinacji kilku pozornie niskiego ryzyka relacji.
Po trzecie, warto wdrożyć zasadę najmniejszych uprawnień oraz krótkotrwałe poświadczenia wszędzie tam, gdzie to możliwe. Ograniczenie trwałych sekretów i przejście na mechanizmy federacyjne lub tokeny o krótkim czasie życia znacząco redukuje okno nadużycia.
Po czwarte, zespoły SOC i Cloud Security powinny monitorować:
- reaktywację długo nieużywanych tożsamości,
- nietypowe wywołania API poza normalnym harmonogramem,
- nagłe rozszerzenie zakresu uprawnień,
- dostęp do sekretów przez tożsamości, które wcześniej tego nie robiły,
- relacje między kontami usługowymi a systemami IAM/IdP.
Po piąte, przeglądy bezpieczeństwa powinny obejmować także konta „osierocone” po zamkniętych projektach, testach, migracjach i wdrożeniach proof-of-concept. To właśnie one najczęściej stają się źródłem ukrytego ryzyka.
Podsumowanie
Rosnąca liczba tożsamości nie-ludzkich w chmurze tworzy nową klasę zagrożeń, która łączy problemy zarządzania IAM, bezpieczeństwa sekretów, automatyzacji i architektury zaufania. Opisane „ghost credentials” pokazują, że nawet uśpione konta i zapomniane tokeny mogą stać się skutecznym punktem startowym do przejęcia rozległych fragmentów środowiska. Dla zespołów bezpieczeństwa oznacza to konieczność przejścia od statycznego przeglądu uprawnień do ciągłej analizy relacji zaufania i realnych ścieżek nadużyć. W środowiskach cloud-native i AI-first to właśnie widoczność nad tożsamościami nie-ludzkimi staje się jednym z kluczowych warunków utrzymania odporności operacyjnej.
Źródła
- Ghost Credentials Expose Cloud Systems to Hidden Identity Risks — https://www.darkreading.com/cloud-security/non-human-identity-sprawl-creates-a-new-cloud-attack-path
- Black Hat USA 2026 Session Listing — https://www.blackhat.com