Najczęściej zadawane pytania o zarządzanie „tożsamościami nieludzkimi” (NHI):
- Dlaczego adekwatne zarządzanie kontami maszynowymi (Non-Human Identities) jest najważniejsze dla bezpieczeństwa firmy?
- Jak unikać najczęstszych błędów w zarządzaniu tożsamościami maszyn?
- Co robić, gdy odkryjemy, iż hasło lub klucz API konta maszynowego zostały umieszczone w kodzie źródłowym?
- Jak są zalecenia i dobre praktyki w pracy z NHI?
To drugi tekst, (właściwie jego połowa, bo druga ukaże się w poniedziałek) w naszym cyklu poświęconym Non-Human Identities (NHI). Po wprowadzeniu, w którym pokazaliśmy, czym są konta maszynowe i dlaczego identity-first to dziś konieczność, przechodzimy do praktyki: dzisiaj 5 z 10 najczęstszych błędów związanych z NHI wraz z informacją, jak ich uniknąć. Warto przypomnieć skalę zjawiska: w typowej organizacji kont maszynowych (NHI) możemy znaleźć od 10 do 50 razy więcej niż kont ludzkich. Tworzą je zespoły dev/ops, narzędzia CI/CD, integracje SaaS, chmura i infrastruktura on-prem – często poza centralnym nadzorem.
Ta masowa, rozproszona i dynamiczna populacja NHI to dziś jeden z głównych wektorów ataku: długowieczne sekrety (klucze API, tokeny), hard-coded credentials (jawnie zapisane loginy i hasła) w repozytoriach, brak rotacji i excessive privileges (nadmierne uprawnienia) ułatwiają lateral movement (niezauważone poruszanie się po sieci ofiary) i eskalację uprawnień. jeżeli dołożyć brak właściciela konta NHI, współdzielenie poświadczeń (skąd my to znamy?) i brak segregacji środowisk (Dev/Test/Prod), mamy gotowy przepis na incydent. W tym artykule syntetyzujemy najczęstsze pułapki i podajemy konkretne, krótkie remedia – tak, by od razu zacząć redukować ryzyko: inventory → ownership → hygiene → least privilege → rotation → monitoring (z secrets vault i automatyzacją w DevSecOps).
1. Hasła w kodzie (hard-coded credentials)
Błąd: Umieszczanie haseł, kluczy API lub tokenów dostępowych bezpośrednio w kodzie źródłowym lub plikach konfiguracyjnych. Takie poświadczenia (credentials) w postaci jawnego tekstu (plaintext) są łatwym łupem – jeżeli kod wycieknie lub zostanie zindeksowany, tajne dane stają się publiczne. Przykładowo w 2023 roku użytkownicy GitHub niechcący ujawnili aż 12,8 miliona haseł i kluczy w publicznych repozytoriach.
Jak unikać: Zawsze oddzielaj sekrety od kodu – korzystaj z menedżerów sekretów (secrets vault) lub usług chmurowych do przechowywania poświadczeń. Implementuj automatyczne skanowanie kodu pod kątem wrażliwych danych (np. w ramach CI/CD pipeline – podejście zgodne z DevSecOps). Gdy już dojdzie do wycieku hasła w kodzie, natychmiast je unieważnij i zmień oraz przeanalizuj historię repozytorium. Najlepszą praktyką jest, by aplikacje pobierały klucze i hasła z bezpiecznych magazynów w czasie działania, a nie miały je na stałe wpisane w kod.
2. Brak pełnej inwentaryzacji kont
Błąd: Nieposiadanie pełnego spisu wszystkich kont NHI w firmie. Konta te często istnieją w wielu miejscach naraz – w usługach chmurowych, usługach on-premise, katalogach (AD/LDAP), narzędziach CI/CD, bazach danych, skryptach automatyzacji – przez co trudno je wszystkie wykryć i policzyć. Uzyskanie kompletnej listy NHI jest dużym wyzwaniem, dlatego wiele organizacji nigdy nie wie, ile dokładnie takich identyfikatorów posiada. Brak inwentaryzacji oznacza, iż niektóre konta mogą pozostać niezauważone, niezarządzane i podatne na atak.
Jak unikać: Należy przeprowadzić dokładny spis i audyt kont maszynowych we wszystkich środowiskach. Wykorzystuj narzędzia automatyczne do odkrywania kont (np. skanery katalogów, skrypty wykorzystujące API chmurowe). najważniejsze jest też posiadanie centralnej bazy wszystkich NHI wraz z informacją o ich przeznaczeniu. Jeśli nie wiesz, gdzie są Twoje konta, nie możesz ich chronić – dlatego budowa bazy kont NHI to pierwszy krok do poprawy bezpieczeństwa. Regularnie aktualizuj tę listę, zwłaszcza gdy zespoły wdrażają nowe aplikacje lub usługi. Wiele organizacji wskazuje, iż odkrywanie i śledzenie kont maszynowych to jedno z największych wyzwań (24% badanych), zatem warto zainwestować czas i środki w odpowiednie narzędzia i procesy inwentaryzacyjne.
3. Nieaktywne lub przestarzałe konta (stale/inactive accounts)
Błąd: Pozostawianie nieużywanych kont maszynowych (NHI) aktywnych w systemach. Wiele NHI nie ma ustawionego cyklu życia – raz utworzone konto może nigdy nie zostać usunięte, choćby gdy przestaje być potrzebne. Z czasem środowisko IT się zmienia (projekty są zamykane, aplikacje zastępowane nowymi, integracje wygasają), ale powiązane z nimi konta często dalej istnieją – z nadanymi uprawnieniami. Takie porzucone, „osierocone” konta stanowią poważne ryzyko, bo atakujący mogą je wykorzystać jako ukryte wejście do naszej sieci. Bywa, iż firmy odkrywają konta serwisowe nieużywane od kilkunastu lat. Co gorsza, badania pokazują, iż tylko 20% organizacji ma formalny proces wyłączania i usuwania niepotrzebnych kluczy i kont API – reszta zostawia je aktywne na czas nieokreślony.
Jak unikać: Zaprojektuj i wprowadź proces zarządzania cyklem życia kont NHI. Każde konto maszynowe powinno mieć przypisany status (aktywne/używane vs. planowane do wycofania) oraz być regularnie przeglądane pod kątem użycia. Monitoruj logi – jeżeli dane konto nie odnotowało aktywności od dłuższego czasu (np. 90 dni lub przez inny ustalony okres), oznacz je jako konto do weryfikacji. Być może można je dezaktywować lub usunąć, po upewnieniu się, iż nie jest już potrzebne. Automatyzuj wykrywanie stale accounts (przestarzałych kont) – skany konfiguracji, audyty uprawnień w chmurze i narzędzia klasy IGA mogą pomóc w wyłapaniu kont-widm. Pamiętaj, iż każde nieaktywne konto to niepotrzebne powiększenie powierzchni ataku. Lepiej zawczasu sprzątać takie „martwe dusze”, niż pozwolić im stać się tykającymi bombami.
4. Brak przypisanego właściciela konta
Błąd: Nieprzypisanie konkretnej osoby odpowiedzialnej za dane konto maszynowe. Często w firmach konta NHI tworzone są ad-hoc przez różne zespoły (DevOps, administratorów, deweloperów), a potem nikt nie czuje się ich opiekunem. W efekcie, gdy pojawia się problem – np. dane konto ma słabe hasło, generuje błędy lub zostaje zidentyfikowane jako zagrożenie – nie wiadomo, kto powinien podjąć działanie naprawcze. Brak właściciela oznacza brak nadzoru: kontem nikt się nie zajmuje, nikt nie aktualizuje jego uprawnień ani nie rotuje hasła. Jest to szczególnie ryzykowne przy kontach wysoko uprzywilejowanych – brak odpowiedzialności prowadzi do zaniedbań.
Jak unikać: Przypisz właściciela (owner) do każdego konta NHI. Najlepiej, aby właścicielem był menedżer lub członek zespołu odpowiedzialnego za aplikację/usługę korzystającą z danego konta. Takie podejście jest rekomendowane przez ekspertów – każde konto serwisowe powinno być skojarzone z konkretną tożsamością osoby odpowiedzialnej. W praktyce oznacza to utrzymywanie atrybutu owner przy wpisie konta w katalogu lub innym repozytorium. Gdy konto zostaje utworzone, od razu określ, kto będzie dbał o jego zgodność z politykami (np. regularną zmianę hasła, recertyfikację dostępu). jeżeli dana osoba opuszcza firmę lub zmienia rolę, wyznacz nowego opiekuna. Formalna odpowiedzialność motywuje do lepszej opieki nad kontem – nikt nie chce być właścicielem, pod którego kuratelą doszło do incydentu.
5. Wykorzystywanie kont maszynowych przez ludzi
Błąd: Użytkownicy z krwi i kości (np. administratorzy, deweloperzy) logują się na konta przeznaczone dla maszyn i używają ich do codziennych czynności. Dzieje się tak, ponieważ konta maszynowe często dysponują stałymi poświadczeniami (hasłami, kluczami) i działają bez wymogu MFA, co kusi do obchodzenia formalnych procedur dostępu. Jest to nagminne zwłaszcza tam, gdzie wprowadzono silne zarządzanie uprzywilejowanym dostępem dla ludzi (PAM) – administrator traci stały dostęp do produkcji, więc zamiast wnioskować za każdym razem o uprawnienia, używa współdzielonego konta serwisowego jako furtki. To bardzo niebezpieczna praktyka, bo podważa wszelkie mechanizmy kontroli dostępu i audytu. Przykładem są tzw. hybrid accounts – konta M2M, z których czasem korzystają ludzie (np. admin uruchamiający skrypty z własnego konta, które przejmują tożsamość usługi). W razie nadużycia lub ataku trudno ustalić, czy winna była maszyna czy człowiek.
Jak unikać: Zabroń używania kont maszynowych do interaktywnej pracy ludzkiej. Polityki bezpieczeństwa powinny jasno definiować, iż logowanie się na konta serwisowe (szczególnie te z uprawnieniami administratorskimi) przez personel jest niedozwolone, poza ściśle określonymi sytuacjami awaryjnymi. Zamiast tego wdrażaj mechanizmy PAM dla dostępu uprzywilejowanego – jeżeli administrator potrzebuje tymczasowego dostępu, niech uzyska go poprzez dedykowane narzędzie z pełnym audytem, a nie przez „pożyczanie” konta maszyny. Monitoruj nietypowe użycie – systemy UEBA mogą wykryć, iż dany identyfikator maszynowy nagle wykonuje działania typowe dla człowieka (np. interaktywna sesja SSH). Edukacja jest tu kluczowa: uświadamiaj zespoły, iż korzystanie z NHI jako skrótu jest poważnym wykroczeniem, które naraża firmę. W razie potrzeby technicznie wymuś to rozdzielenie – np. blokując możliwość logowania interaktywnego na kontach serwisowych (ustawienie „nologin” na kontach Unix, „deny logon” lokalnie w Windows itp.).
Drugą cześć artykułu opublikujemy w poniedziałek.
