Tożsamości maszynowe: zabezpieczanie kont serwisowych, tożsamości workloadów i agentów AI

czym są tożsamości maszynowe

Tożsamości maszynowe to dane uwierzytelniające, których oprogramowanie używa, żeby uwierzytelnić się i uzyskać dostęp do systemów, API albo danych.

Konta serwisowe. Konto powiązane z systemem operacyjnym, katalogiem albo aplikacją, a nie z osobą. Uwierzytelniają procesy działające w tle: zaplanowany skrypt eksportu, agenta monitorującego, aplikację łączącą się z bazą danych. Występują w Active Directory, Google Workspace, Entra ID i większości platform SaaS pod nazwami takimi jak „service principals" albo „technical users".

Klucze API i tokeny. Dane uwierzytelniające, które autoryzują programowy dostęp do API albo usługi. Często statyczne, rzadko rotowane, i przechowywane w miejscach trudnych do zinwentaryzowania: zmiennych środowiskowych, plikach konfiguracyjnych, secrets managerach, a czasem wprost w repozytoriach kodu źródłowego.

Tożsamości workloadów. Dane uwierzytelniające przypisane konkretnym workloadom obliczeniowym: kontenerom, maszynom wirtualnym, funkcjom serverless, pipeline'om CI/CD. W środowiskach chmurowych są nadawane przez warstwę IAM dostawcy (role AWS IAM, tożsamości zarządzane Azure, konta serwisowe Google) i mogą istnieć na dużą skalę oraz ze znacznym dostępem.

Granty OAuth i połączenia serwisowe. Kiedy aplikacja SaaS zostaje autoryzowana do dostępu do drugiej, powstały grant OAuth to forma tożsamości maszynowej. Integracja ma uprawnienia, które trwają niezależnie od osoby, która je nadała. Jeśli ta osoba odejdzie, grant zostaje.

Boty i konta automatyzacji. Konta używane przez narzędzia RPA, frameworki testowe i platformy automatyzacji workflow. Często trzymają ten sam poziom dostępu, co osoba, która je skonfigurowała, łącznie z dostępem do odczytu i zapisu w systemach produkcyjnych.

Agenci AI. Oprogramowanie, które działa autonomicznie, żeby dokończyć zadania, zwykle wywołując narzędzia i API w imieniu użytkownika albo systemu. Pytanie o tożsamość to nie tylko to, jakie dane uwierzytelniające trzyma agent, ale z jakimi uprawnieniami działa, wykonując zadanie. Ten temat ma swoją osobną sekcję poniżej.

dlaczego przewyższają liczebnie tożsamości ludzkie i wciąż rosną

Proporcja tożsamości maszynowych do ludzkich znacząco się przesunęła, w miarę jak organizacje wdrażały coraz więcej narzędzi SaaS, budowały więcej automatyzacji i przenosiły więcej workloadów do infrastruktury chmurowej. Każda nowa integracja aplikacji tworzy przynajmniej jedną NHI. Każdy workload chmurowy, który wywołuje API, wymaga danych uwierzytelniających.

Verizon 2024 Data Breach Investigations Report ustalił, że dane uwierzytelniające biorą udział w większości naruszeń, a zakres nadużywanych ważnych danych uwierzytelniających rozszerzył się o dane maszynowe. Tam, gdzie dekadę temu głównym ryzykiem związanym z danymi uwierzytelniającymi były przejęte hasła użytkowników, dziś obejmuje ono klucze API wrzucone do publicznych repozytoriów, wyciekłe tokeny OAuth i konta serwisowe z nadmiernymi uprawnieniami bez historii rotacji.

Ten wzrost jest strukturalny. API to wzorzec integracji dla współczesnego oprogramowania. Architektury agentów AI mnożą liczbę autonomicznych procesów, które potrzebują dostępu. Liczba NHI zwykle rośnie szybciej niż zdolność zespołu do zarządzania nimi, bo utworzenie konta serwisowego albo klucza API to rutynowa czynność deweloperska, a zarządzanie nie ma równoważnego, rutynowego procesu usuwania.

dlaczego trudno nimi zarządzać

Brak wyzwalacza joiner-mover-leaver. NHI to nie ludzie. Nie ma dla nich rekordu HR, zdarzenia zatrudnienia ani workflow offboardingu. Kiedy aplikacja, którą obsługiwała NHI, zostaje wycofana, nie ma automatycznego wyzwalacza, który by ją usunął. Konto trwa, dopóki ktoś jawnie go nie usunie, a ta osoba musi najpierw wiedzieć, że ono istnieje.

Brak przypisanego właściciela domyślnie. Konta serwisowe i klucze API zwykle tworzy ten, kto akurat ich potrzebuje. Twórca niekoniecznie jest długoterminowym właścicielem, a własność rzadko jest dokumentowana. Kiedy twórca odchodzi, konto staje się dosłownie niczyje.

Szerokie, stałe uprawnienia. Uprawnienia niemal zawsze są ustawiane przy tworzeniu, tak jak było potrzeba, żeby integracja zadziałała. Ich zawężenie wymaga przetestowania, czy integracja nadal działa przy zredukowanym dostępie, co zajmuje czas, którego twórca nie miał. Efektem jest stałe uprawnienie: szeroki dostęp, który istnieje nieprzerwanie, niezależnie od tego, czy workload akurat działa.

Długo żyjące albo nigdy nie rotowane dane uwierzytelniające. Rotacja danych uwierzytelniających dla NHI to ręczny proces wymagający znajomości aplikacji: rotacja klucza API wymaga aktualizacji w każdym miejscu, gdzie jest używany. Bez harmonogramu rotacji i automatyzacji dane uwierzytelniające trwają w nieskończoność.

Nieobecność w przeglądach dostępów. Standardowe przeglądy pobierają listy użytkowników z katalogów i proszą właścicieli zasobów o potwierdzenie dostępu. NHI zwykle nie pojawiają się na tych listach. Efektem są programy przeglądów, które spełniają wymogi compliance dla kont ludzkich, a tożsamości maszynowe zostawiają całkowicie bez przeglądu.

Niewidoczne w środowiskach SaaS. Każda aplikacja SaaS zarządza własnymi kluczami API, połączeniami serwisowymi i grantami OAuth niezależnie. Organizacja może mieć setki grantów OAuth w swoim stosie SaaS i żadnego jednego miejsca, żeby je wszystkie wypisać.

konkretne ryzyka

Osierocone konta serwisowe. Konto serwisowe, którego przeznaczenie się skończyło, ale dane uwierzytelniające pozostają aktywne. Jeśli te dane wyciekną, dostęp, jaki niosą, jest żywy. Atakujący, który je zdobędzie, nie musi wiedzieć, do czego konto służyło. Musi tylko wiedzieć, do czego może sięgnąć.

Workloady z nadmiernymi uprawnieniami. Kontener, funkcja albo pipeline trzymające więcej dostępu, niż wymaga tego ich obecna funkcja: dostęp administracyjny nadany podczas developmentu, nigdy nie zawężony na produkcji, pipeline danych z dostępem do zapisu do bazy, którą tylko odczytuje. Szerokie uprawnienia przy tworzeniu bez przeglądu to domyślny wzorzec w większości środowisk.

Wyciekłe sekrety. Klucze API i dane uwierzytelniające wrzucone do repozytoriów, ujawnione w plikach konfiguracyjnych albo logowane jawnym tekstem. Baza doradcza GitHub konsekwentnie wskazuje ujawnione dane uwierzytelniające jako jedną z najczęstszych kategorii wycieku sekretów. Wyciekłego sekretu nie można uznać za cofnięty, dopóki nie zostanie rotowany, a rotacja wymaga wiedzy, że wyciek w ogóle nastąpił.

Agenci AI działający z delegowanymi uprawnieniami. Kiedy użytkownik autoryzuje agenta AI do działania w swoim imieniu, agent może otrzymać uprawnienia użytkownika w poczcie, kalendarzu, magazynie plików i innych obszarach. Jeśli agent zostanie przejęty, źle skonfigurowany albo zmanipulowany przez prompt injection, może wykonywać działania z pełnym poziomem dostępu użytkownika.

Lateral movement przez dane uwierzytelniające kont serwisowych. Przejęte dane uwierzytelniające konta serwisowego nie wywołują tego samego alertowania, co przejęte konto użytkownika, bo od kont serwisowych oczekuje się uwierzytelniania z procesów. Lateral movement z użyciem danych uwierzytelniających kont serwisowych może pozostać niewykryty dłużej. Framework MITRE ATT&CK dokumentuje ważne dane uwierzytelniające kont, łącznie z kontami serwisowymi, jako główną technikę trwałości i lateral movement.

agenci AI jako nowa klasa NHI

Agenci AI to autonomiczne procesy programowe, które używają narzędzi i API, żeby dokończyć zadania. Użytkownik może autoryzować agenta do czytania poczty, tworzenia wydarzeń w kalendarzu, odpytywania bazy danych i wywoływania zewnętrznego API w ramach jednego workflow. Agent wykonuje to, używając danych uwierzytelniających, które trzyma bezpośrednio albo które zostały mu delegowane.

Łańcuchy delegacji. Uprawnienia agenta mogą pochodzić od uprawnień użytkownika w momencie autoryzacji, zawężone albo nie, i mogą trwać dłużej niż pierwotna sesja. Zrozumienie, do czego agent ma dostęp, wymaga zrozumienia zakresu autoryzacji, jaki odziedziczył.

Łańcuchowanie działań. Pojedyncza instrukcja może wywołać sekwencję wywołań API w wielu systemach naraz. Łączny zakres tego, co agent może zrobić w ramach workflow, jest często szerszy niż każde pojedyncze uprawnienie w tym łańcuchu.

Wywołania zewnętrznych usług. Agenci często wywołują zewnętrzne API, w tym usługi AI firm trzecich. Każde wywołanie angażuje dane uwierzytelniające i może wiązać się z wysyłaniem danych poza organizację, co przecina się z wymogami zarządzania danymi.

Prompt injection jako atak na dane uwierzytelniające. Jeśli agent czyta zewnętrzną treść w ramach zadania, ta treść może zawierać instrukcje zaprojektowane, żeby manipulować jego zachowaniem. To prompt injection, sklasyfikowany w projekcie OWASP LLM Application Security jako główny wektor ataku. Istotne dla zarządzania NHI ryzyko polega na tym, że przejęty agent może działać ze swoją delegowaną tożsamością w sposób, którego użytkownik nie zamierzył.

Praktyczny wymóg zarządzania jest taki sam jak dla każdej innej NHI: zinwentaryzuj je, przypisz właściciela, zawęź uprawnienia do minimum wymaganego, zdefiniuj, jak dane uwierzytelniające i granty autoryzacji są przeglądane i rotowane, i monitoruj aktywność.

jak wziąć je pod kontrolę: krok po kroku

Proces przebiega według tej samej sekwencji, niezależnie od tego, czy środowisko ma kilkadziesiąt kont serwisowych, czy setki tożsamości workloadów w wielu chmurach naraz.

Krok 1: zbuduj inwentaryzację. Pobierz tożsamości maszynowe z każdego źródła: dostawców tożsamości (konta serwisowe, technical users, service principals), platform chmurowych (role, tożsamości zarządzane), aplikacji SaaS (klucze API, granty OAuth, połączenia serwisowe), secrets managerów, repozytoriów kodu źródłowego i platform CI/CD. Zapisz co najmniej: nazwę tożsamości, typ, platformę, do czego ma dostęp, obecny poziom uprawnień, typ danych uwierzytelniających i czy jest zapisany właściciel. To najtrudniejszy krok. Inwentaryzacja, która pokrywa większość, ale nie wszystkie NHI, jest znacznie bardziej użyteczna niż brak jakiejkolwiek, bo sprawia, że luki stają się widoczne i mierzalne.

Krok 2: przypisz właściciela do każdej NHI. Dla każdej wskaż obecnego pracownika, który wie, co ona robi, z czym się łączy i kto się nią zajmie, jeśli będzie wymagała aktualizacji, przeglądu albo wyłączenia. Konta bez możliwego do przypisania właściciela to pozycje najwyższego priorytetu: konto serwisowe bez właściciela z dostępem do produkcji to niemonitorowane dane uwierzytelniające bez osoby odpowiedzialnej.

Krok 3: zawęź uprawnienia do least privilege. Sprawdź, czego każda NHI faktycznie potrzebuje, na tle tego, co ma. Częste ustalenia: dostęp administracyjny, który wymaga tylko odczytu, szeroki dostęp do zapisu na workloadzie tylko do odczytu, dostęp do wielu systemów, kiedy integracja używa jednego, uprawnienia odziedziczone z szablonu. Zawężenie wymaga przetestowania, że zredukowany zakres nie łamie integracji. Rób to po jednym koncie wysokiego priorytetu naraz, zaczynając od najszerszego dostępu.

Krok 4: ustal harmonogram rotacji danych uwierzytelniających. Każde dane uwierzytelniające powinny mieć zdefiniowany interwał rotacji. Jako punkt wyjścia: dane uwierzytelniające o wysokich uprawnieniach przynajmniej co 90 dni, standardowe dane uwierzytelniające integracji przynajmniej co 180 dni, a dane uwierzytelniające, których datę ekspozycji nie znasz, traktuj jako potencjalnie ujawnione i rotuj natychmiast. Automatyzuj tam, gdzie się da. Narzędzia do zarządzania sekretami (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) potrafią zautomatyzować rotację dla obsługiwanych typów danych uwierzytelniających.

Krok 5: włącz NHI do przeglądów dostępów. NHI powinny pojawiać się w cyklach przeglądów jako osobna kategoria, a nie coś dorzuconego na końcu przeglądu skupionego na ludziach.

Krok 6: monitoruj aktywność. NHI z czystą inwentaryzacją i wydzielonymi uprawnieniami wciąż jest ryzykiem, jeśli jej aktywność nigdy nie jest monitorowana. Loguj zdarzenia uwierzytelniania i dostępu obok kont ludzkich. Ustaw alerty na uwierzytelnianie poza normalnym wzorcem, dostęp poza udokumentowanym zakresem, użycie z nieoczekiwanych adresów IP i nieudane uwierzytelnienia, które mogą wskazywać na credential stuffing.

włączanie NHI do przeglądów dostępów

Rytm. NHI o wysokich uprawnieniach (konta serwisowe na poziomie admina, tożsamości workloadów z dostępem do zapisu na produkcji, szerokie granty autoryzacji agentów AI) powinny być przeglądane kwartalnie, tak jak konta admina dla ludzi. Standardowe dane uwierzytelniające integracji i konta serwisowe tylko do odczytu mogą iść w cyklu półrocznym.

Decyzja przeglądu. Dla każdej NHI objętej zakresem osoba przeglądająca potwierdza, modyfikuje albo cofa dostęp.

Przypisanie osoby przeglądającej. Właściwą osobą przeglądającą jest właściciel przypisany w kroku 2. Tam, gdzie nikogo nie przypisano, przegląd domyślnie trafia do właściciela systemu albo aplikacji.

Co sprawdzić. Czy tożsamość jest wciąż aktywnie używana (dane o ostatnim użyciu, gdzie dostępne), czy funkcja, której służy, wciąż istnieje, czy uprawnienia pasują do obecnej funkcji, czy dane uwierzytelniające były rotowane zgodnie z harmonogramem i czy przypisanie właściciela jest aktualne.

Wykrywanie osieroconych kont. Każda NHI bez aktywności w ciągu ostatnich 90 dni powinna być automatycznie oznaczona jako kandydat do cofnięcia dostępu. Uśpione konta trzymają dostęp, który nie jest już aktywnie używany, bez żadnego naturalnego sygnału monitorującego.

jak to się mapuje na SOC 2, ISO 27001, NIS2 i DORA

Zarządzanie tożsamościami maszynowymi mieści się w wymogach kontroli dostępu i zarządzania tożsamością, jakie zawierają wszystkie cztery główne frameworki. Zarządzanie NHI to sposób, w jaki spełniasz te wymogi, a nie osobny tor.

SOC 2. Kryteria dotyczące dostępu logicznego (CC6.1, CC6.2, CC6.3) obejmują wszystkie konta, nie tylko ludzkie. Audytorzy szukają dowodu, że konta maszynowe są objęte zakresem przeglądu dostępów. Konta serwisowe z szerokimi uprawnieniami i bez historii przeglądu to częste odstępstwo.

ISO 27001. Kontrola 5.18 obejmuje zarządzanie prawami dostępu, w tym przegląd, dostosowanie i cofnięcie, kiedy dostęp nie jest już potrzebny. Standard nie ogranicza tego do użytkowników ludzkich. Audyt ISMS, który ujawnia nieudokumentowane, niczyje konta serwisowe z szerokimi uprawnieniami, zwykle podnosi tu ustalenia.

NIS2. Artykuł 21 wymaga polityk kontroli dostępu, w tym zarządzania dostępem uprzywilejowanym (PAM). Tożsamości maszynowe z dostępem administracyjnym albo produkcyjnym wprost mieszczą się w tym zakresie.

DORA. Artykuł 9 obejmuje kontrolę dostępu jako obowiązkowy obszar, ze szczególną uwagą na konta uprzywilejowane. Konta serwisowe z dostępem do krytycznych systemów finansowych są objęte zakresem, a DORA oczekuje udokumentowanych kontroli, zdefiniowanej własności i wykazywalnych procesów przeglądu.

RODO. NHI z dostępem do systemów zawierających dane osobowe podlegają środkom technicznym i organizacyjnym wymaganym na mocy artykułu 32. Niczyje konto serwisowe z dostępem do odczytu albo zapisu do magazynu danych osobowych to luka w kontroli dostępu o bezpośrednim znaczeniu dla ochrony danych.

typowe scenariusze porażki

Inwentaryzacja nigdy nie powstała. Bez inwentaryzacji każdy kolejny krok jest niemożliwy. Organizacje, które od lat prowadzą przeglądy dostępów, ale nigdy nie objęły nimi NHI, zwykle nie wiedzą, co w ogóle istnieje.

Inwentaryzacja powstała, ale nigdy nie jest utrzymywana. Jednorazowe ćwiczenie discovery szybko się dezaktualizuje, w miarę jak kumulują się nowe konta i granty. Traktuj inwentaryzację NHI jako żywy rekord, aktualizowany jako część provisioningu, a nie okresowy projekt.

Rotacja pomijana, bo jest operacyjnie skomplikowana. Rotacja danych uwierzytelniających używanych przez działające aplikacje wymaga koordynacji i może spowodować przestój, jeśli zostanie źle przeprowadzona. Narzędzia do zarządzania sekretami istnieją właśnie po to, żeby to ograniczyć. Zacznij od danych uwierzytelniających o najwyższych uprawnieniach i najdłużej istniejących.

NHI wykluczone z przeglądów, bo nie pasują do szablonu. Najczęstszą reakcją jest ich pominięcie, co daje program przeglądu, który satysfakcjonuje audytorów w zakresie dostępu ludzkiego, zostawiając bez przeglądu najszybciej rosnącą kategorię danych uwierzytelniających.

Brak monitoringu aktywności NHI. Bez monitoringu przejęte dane uwierzytelniające konta serwisowego mogą działać niewykryte. Konta serwisowe mają przewidywalne wzorce użycia, więc odchylenia łatwiej wykryć niż w ruchu ludzkim.

Agenci AI autoryzowani bez wydzielonych uprawnień. Autoryzacje agentów są czasem nadawane z takim samym zakresem, jak pełne uprawnienia autoryzującego użytkownika. Zawężenie do minimum wymaganego to least privilege zastosowane do nowej klasy tożsamości.

narzędzia: na co zwracać uwagę

Zarządzanie NHI może zacząć się ręcznie, z arkuszami dla inwentaryzacji, przypomnieniami w kalendarzu dla rotacji i dostosowanymi szablonami przeglądu. Przy małej skali to wystarcza. W miarę wzrostu liczby NHI ręczne procesy zawodzą z tych samych powodów, co przy kontach ludzkich.

Podstawowe wymogi funkcjonalne w kategorii zarządzania NHI są spójne: discovery (zautomatyzowane wykrywanie w katalogach, chmurze, SaaS i magazynach sekretów), przypisywanie i śledzenie właścicieli, analiza uprawnień (obecne kontra wymagane), zarządzanie sekretami i rotacja, monitoring aktywności oraz integracja z workflow przeglądów dostępów.

Dostawcy chmury oferują natywne narzędzia dla tożsamości workloadów wewnątrz swoich platform (AWS IAM Access Analyzer, Azure Entra Workload Identities, Google Cloud IAM Recommender), ale nie obejmują one NHI między chmurami albo hostowanych w SaaS. Dla stosów SaaS zarządzanie grantami OAuth to osobna luka. Dedykowane narzędzia SSPM ujawniają granty z szerszym pokryciem. Dla zarządzania sekretami HashiCorp Vault, AWS Secrets Manager, Azure Key Vault i porównywalne oferty dostarczają automatyzację, która czyni rotację wykonalną na dużą skalę. Właściwym punktem startowym w większości środowisk jest ręczne zbudowanie inwentaryzacji, a potem ocena narzędzi względem konkretnych luk, jakie ona ujawnia.