NHI w chmurze – dlaczego same CSPM i PAM to za mało?

W dobie rosnącej cyfryzacji i migracji danych do chmury, zarządzanie tożsamością staje się kluczowym elementem skutecznego cyberbezpieczeństwa. Nowoczesne środowiska oparte na koncepcji Non-Human Identities (NHI) – czyli tożsamościach maszynowych, aplikacyjnych i usługowych – wprowadzają jednak zupełnie nowe wyzwania. Tradycyjne narzędzia IAM przestają wystarczać, gdy liczba automatycznych połączeń i procesów rośnie wykładniczo. Jakie więc są filary bezpieczeństwa tożsamości w chmurze i dlaczego organizacje muszą sięgnąć po nowe rozwiązania, by skutecznie chronić NHI przed nadużyciami i cyberatakami?

Wprowadzenie. Pięć filarów bezpieczeństwa tożsamości

Współczesne podejście do bezpieczeństwa koncentruje się na tożsamości jako nowym perymetrze ochrony cyfrowej. Aby skutecznie chronić zasoby i dane, organizacje opierają się na pięciu filarach bezpieczeństwa tożsamości:

• IAM (Identity and Access Management – zarządzanie tożsamością i dostępem),
• IGA (Identity Governance and Administration – nadzór i administracja tożsamościami),
• PAM (Privileged Access Management – zarządzanie uprzywilejowanymi dostępami),
• ISPM (Identity Security Posture Management – zarządzanie postawą bezpieczeństwa tożsamości),
• ITDR (Identity Threat Detection and Response – wykrywanie i reagowanie na zagrożenia tożsamości).

Każdy z tych obszarów odgrywa kluczową rolę – od nadawania dostępu i kontrolowania go, przez egzekwowanie zasad i przeglądy uprawnień, po monitorowanie konfiguracji i reagowanie na nadużycia. W przypadku tożsamości ludzkich stosowanie tych praktyk jest już standardem w wielu firmach – istnieją procedury i narzędzia do zarządzania kontami użytkowników, recertyfikacji dostępu czy monitorowania aktywności administratorów.

Coraz większym wyzwaniem staje się jednak objęcie podobną kontrolą tożsamości nieludzkich (Non-Human Identities, NHI), czyli kont i poświadczeń używanych przez aplikacje, usługi, procesy automatyczne czy urządzenia. W środowiskach chmurowych liczba takich tożsamości rośnie wykładniczo wraz z automatyzacją i architekturą mikroserwisów – szacuje się, iż kont maszynowych jest średnio ponad 90 na jedno konto użytkownika (czyli ok. 95% wszystkich tożsamości).

W dalszej części artykułu przyjrzymy się, dlaczego typowe narzędzia chmurowe w rodzaju CSPM (Cloud Security Posture Management) oraz klasyczne rozwiązania PAM nie wystarczają do zabezpieczenia NHI.

Dlaczego dotychczasowe narzędzia nie wystarczają dla NHI?

Wiele organizacji zakłada, iż posiadanie standardowych rozwiązań IAM/PAM oraz skanera konfiguracji chmury (CSPM) zapewni im pełne bezpieczeństwo tożsamości. Tymczasem skalowalność i charakterystyka NHI wykraczają poza możliwości tych klasycznych narzędzi. Główne problemy to brak widoczności, brak kontekstu oraz brak automatyzacji odpowiedniej dla dynamiki środowisk chmurowych:

• Ograniczenia IAM/IGA i PAM Systemy IAM (w tym IGA) oraz tradycyjne narzędzia PAM były projektowane z myślą o kontach ludzkich i kilku stałych kontach uprzywilejowanych. Działają one w modelu centralnego zarządzania – zakładają, iż każde konto jest przypisane do konkretnej osoby i obsługiwane cyklem życia przez zespół IT (np. tworzenie w HR, nadanie dostępu, wyłączenie przy odejściu pracownika). W przypadku tożsamości maszynowych ten model się załamuje. Programiści i zespoły DevOps często tworzą konta usług, role IAM czy klucze API ad-hoc w chmurze, poza tradycyjnym nadzorem działu IT. Takie NHI bywają ulotne, mnożą się w dziesiątkach środowisk i rzadko są powiązane z pojedynczym właścicielem. Rozwiązania IAM/PAM nie były projektowane, by objąć swym zasięgiem taką skalę i rozproszenie. Przykładowo narzędzia PAM nastawione na kontrolę dostępu uprzywilejowanego użytkowników (np. administratorów domeny) nie mają wglądu w kontekst setek tokenów i kont serwisowych tworzonych w CI/CD. Ponadto maszyn nie można uwierzytelnić dzięki MFA czy biometryki – brak tego dodatkowego zabezpieczenia oznacza, iż przejęcie klucza/hasła maszynowego daje atakującemu pełny dostęp bez możliwości dodatkowej weryfikacji.
• Braki menedżerów sekretów Wiele firm inwestuje w menedżery haseł i sekretów (np. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), zakładając iż wszystkie poświadczenia maszynowe trafią do takiego „sejfu”. Owszem, centralne vaulty są niezbędne do bezpiecznego przechowywania sekretów, ale same nie rozwiązują pełnego problemu. Menedżer sekretów nie wykryje nam hasła zaszytego w kodzie czy tokenu pozostawionego w logach – nie ma świadomości istnienia takich poświadczeń poza swoim magazynem. Co więcej, vault „nie rozumie” kontekstu tożsamości – nie wie, kto używa danego klucza, jakie ma on uprawnienia ani do jakich zasobów daje dostęp. Dlatego samo posiadanie sejfu na hasła bez odpowiedniej polityki i integracji nie zapobiegnie wyciekom ani nadużyciom. Badania pokazują wręcz, iż organizacje polegające wyłącznie na menedżerach sekretów często doświadczają większej liczby incydentów wycieku sekretów, prawdopodobnie z powodu fałszywego poczucia bezpieczeństwa. Innymi słowy, sam vault nie zapewni nam governance – nie zastąpi procesu inwentaryzacji NHI, kontroli uprawnień czy rotacji kluczy, jeżeli te procesy nie są wdrożone.
• CSPM – podejście „infrastruktura first” zamiast „identity first” Platformy CSPM świetnie sprawdzają się w wykrywaniu błędnych konfiguracji infrastruktury chmurowej (np. otwarte buckety S3, publiczne IP maszyn, brak szyfrowania dysków) i niewątpliwie są ważnym elementem bezpieczeństwa w chmurze. Ich wada polega jednak na tym, iż widzą chmurę głównie od strony zasobów, a nie tożsamości. Nie wszystkie problemy z tożsamościami są widoczne jako misconfiguration infrastruktury – np. CSPM może ostrzec o niezastosowaniu jakiejś polityki IAM, ale nie zauważy, iż dany klucz API jest od roku nieużywany albo iż konto serwisowe ma nadane zbyt szerokie uprawnienia w porównaniu do swojej funkcji. Co więcej, CSPM z reguły tylko alarmuje o zagrożeniu, ale nie daje rozwiązania. W praktyce zespoły bezpieczeństwa otrzymują listę potencjalnych problemów, z których wiele dotyczy właśnie tożsamości (np. nadmierne uprawnienia, brak rotacji poświadczeń), ale bez dedykowanych narzędzi trudno te zalecenia wdrożyć. W efekcie alerty się kumulują, a rzeczywiste ryzyko pozostaje niezmienne.

Podsumowując, obecny stack zabezpieczeń ma poważne luki w obszarze NHI – brakuje jednolitej inwentaryzacji i zarządzania życiem kont maszynowych, brakuje kontekstu (powiązania sekretu z konkretną aplikacją, właścicielem, prawami dostępu), a także mechanizmów automatycznej reakcji na incydenty z udziałem tych tożsamości. Działając z narzędziami przeznaczonymi głównie dla kont ludzkich, bezpieczeństwo łatwo traci z oczu setki czy tysiące „ukrytych” kont maszyn, które stanowią dla atakujących łatwy cel.

Podsumowanie

Dynamiczny rozwój usług chmurowych i automatyzacji sprawił, iż tożsamości nieludzkie stały się jednym z najsłabszych ogniw bezpieczeństwa. Poleganie wyłącznie na tradycyjnych narzędziach CSPM i PAM daje złudne poczucie ochrony – o ile skutecznie zabezpieczają one infrastrukturę i uprzywilejowane konta administratorów, o tyle nie dostrzegają setek tokenów, kluczy i kont usług krążących w środowisku. Zaniedbanie tego obszaru skutkuje powstaniem „szarej strefy” w bezpieczeństwie, którą agresorzy chętnie wykorzystują.

Rozwiązaniem jest przyjęcie podejścia zorientowanego na tożsamość (identity first), w którym wszystkie filary bezpieczeństwa tożsamości – IAM/IGA, PAM, ISPM, ITDR – obejmują również NHI. Organizacje muszą zyskać pełną widoczność swoich kont maszynowych, aktywnie zarządzać ich cyklem życia oraz monitorować ich użycie. Tylko wtedy ograniczą nadmiarowe uprawnienia, wycieki sekretów i nadużycia, które dziś pozostają poza radarem. W dobie gdy ponad 80% naruszeń wynika z wykorzystania skradzionych lub nadużytych tożsamości, inwestycja w kompleksowe zarządzanie tożsamościami – zarówno ludzkimi, jak i nieludzkimi – staje się nieodzownym elementem strategii bezpieczeństwa. Efektywna kontrola NHI zamyka istotną lukę w ochronie chmury, dając pewność, iż żaden „nierozpoznany” użytkownik czy proces nie stanie się furtką dla ataku.

Jak zwykle zachęcamy do kontaktu ze specjalistami ProLimes.