Jeśli jesteście zaskoczeni, widząc na początku tego tekstu punkt numer 6, spieszymy z wyjaśnieniem – publikujemy dziś drugą część artykułu o błędach w zarządzaniu tożsamościami maszynowymi. Z częścią pierwszą możecie zapoznać się tutaj.
6. Nadmierne uprawnienia kont (excessive privileges)
Błąd: Przyznawanie kontom maszynowym większych uprawnień, niż rzeczywiście potrzebują do działania. Często spotykamy się z sytuacją, gdy dla świętego spokoju konto integracyjne dostaje rolę Administratora lub pełne uprawnienia do bazy danych, mimo iż realnie powinno mieć tylko dostęp odczytu do konkretnej tabeli. Wynika to z pośpiechu („dajmy mu na wszelki wypadek wszystko, żeby nic się nie wykrzaczyło”) albo z niewiedzy co do minimalnego zakresu dostępu wymaganego przez aplikację. W konsekwencji kompromitacja takiego konta daje atakującemu dużo większe możliwości wyrządzenia szkód, niż gdyby miało ono ograniczony dostęp. Niestety badania potwierdzają ten problem: około 5% kont maszynowych w środowiskach chmurowych (np. AWS) ma uprawnienia administratora, a niemal 10% to konta z nadmiernymi uprawnieniami, do tego nieużywane na co dzień – prawdziwe bomby z opóźnionym zapłonem.
Jak unikać: Kieruj się zasadą least privilege (poruszaliśmy ten temat na stronach Kapitana „Jak Just in Time JIT zwiększa poziom bezpieczeństwa organizacji”) – każdemu kontu maszynowemu nadawaj minimalny wymagany zestaw uprawnień. W praktyce, o ile usługa potrzebuje dostępu tylko do jednego zasobu, przyznaj jej uprawnienia tylko do tego zasobu, a nie globalne. Unikaj dodawania kont serwisowych do ogólnych grup – na przykład „Administrators”. Regularnie przeglądaj uprawnienia NHI i usuwaj nadmiarowe – podobnie jak robi się recertyfikację dostępu pracowników. Wykorzystaj listy kontroli dostępu i separuj role: np. osobne konta do odczytu danych, osobne do zapisu, zamiast jednego superkonta do wszystkiego. Automatyzuj wykrywanie anomalii uprawnień – istnieją narzędzia, które potrafią wskazać, iż dane konto posiada szerszy zakres dostępu, niż potrzebuje (np. nigdy nie korzysta z uprawnień administracyjnych mimo ich posiadania). To sygnał, by odebrać zbędne przywileje. Pamiętaj, iż nadanie zbyt dużych uprawnień jest jak zostawienie kluczy do królestwa – jeżeli już musisz to zrobić, to tylko świadomie i tymczasowo (a potem odbierz klucze).
7. Brak rotacji haseł i kluczy (credential cycling)
Błąd: Statyczne, nigdy niezmieniane hasła lub klucze dostępu przypisane do kont maszynowych. Wiele firm konfiguruje konta aplikacyjne raz i pozostawia te same poświadczenia przez lata. Brak rotacji wynika często z obaw – zmiana hasła konta usługi może być kłopotliwa, bo trzeba je zaktualizować w wielu miejscach (skrypty, zmienne środowiskowe, konfiguracje). jeżeli organizacja nie korzysta z centralnego systemu PAM ani automatycznej propagacji haseł, to rzeczywiście rotacja bywa ryzykowna (grozi zatrzymaniem integracji lub aplikacji). Efekt? Hasła serwisowe „żyją” wiecznie, często zapisane w plikach lub kodzie. To skrajnie niebezpieczne – atakujący dysponując takim starym hasłem, może uzyskać dostęp choćby po długim czasie, bo hasło jest przez cały czas ważne.
Jak unikać: Wdróż politykę regularnej rotacji poświadczeń dla NHI. Hasła kont maszynowych powinny być zmieniane co określony czas (np. co 90 dni lub częściej w przypadku krytycznych systemów). Najlepiej skorzystać z narzędzi, które automatyzują ten proces – menedżer haseł (PAM) potrafi zmieniać hasła na kontach serwisowych i od razu dystrybuować je do wszystkich aplikacji, które z nich korzystają. o ile manualna zmiana jest trudna, to znak, iż czas usprawnić cykl życia tokenów (token lifecycle): aplikacje powinny pobierać aktualne sekrety dynamicznie, np. przez API vaulta albo poprzez mechanizmy CI/CD. W planach DR uwzględnij tzw. break-glass account, czyli konto awaryjne na wypadek odcięcia dostępu – ale nie używaj go na co dzień zamiast adekwatnego zarządzania hasłami. najważniejsze jest również, aby wszystkie klucze i hasła NHI były trzymane w kontrolowanym magazynie (vault\PAM), a nie w plikach konfiguracyjnych. Dzięki temu możesz je centralnie rotować, monitorować użycie oraz gwałtownie unieważnić w razie podejrzenia kompromitacji. Pamiętaj: sekret, który nie był zmieniany od lat, należy uznać za potencjalnie znany atakującym – działaj proaktywnie, nim będzie za późno.
8. Brak segregacji środowisk
Błąd: Używanie tych samych kont maszynowych lub tych samych poświadczeń w różnych środowiskach (np. to samo konto działa w środowisku deweloperskim, testowym i produkcyjnym). To poważne uchybienie, bo znosi izolację między środowiskami. Atakujący, który złamie zabezpieczenia słabszego środowiska (np. testowego), może zdobyć dane dostępowe ważne również w produkcji, co umożliwi mu niezauważone przejście (lateral movement) do najcenniejszych systemów. Niestety w wielu firmach dla wygody używa się tych samych kluczy i kont zarówno w środowiskach produkcyjnych. jak i deweloperskich – jest mniej pracy przy konfiguracji, ale rośnie ryzyko. Przykładowe incydenty (jak wycieki w środowiskach deweloperskich dużych firm) pokazują, iż dostęp do niezabezpieczonej instancji deweloperskiej może skutkować wykradzeniem kodu źródłowego, sekretów i danych uwierzytelniających. jeżeli te dane zadziałają w produkcji – mamy poważny problem.
Jak unikać: Rozdziel środowiska i konta. Zasada jest prosta: żadne konto ani hasło używane w produkcji nie powinno być wykorzystane w innym środowisku. Dla Dev, QA, UAT utwórz oddzielne konta maszynowe o ograniczonym dostępie. choćby jeżeli aplikacja wymaga podobnej integracji w Dev i Prod, wygeneruj dwa osobne klucze API – każdy ograniczony do odpowiedniego środowiska. Dzięki temu kompromitacja jednego nie wpływa na drugie. Zaimplementuj także segmentację sieciową – usługi deweloperskie nie powinny mieć swobodnej komunikacji z infrastrukturą produkcyjną. Pilnuj konfiguracji chmury: separuj konta/subskrypcje/projekty dla różnych środowisk, aby role i uprawnienia się nie przenikały. Testuj bezpieczeństwo środowisk niższych – często są one słabiej monitorowane, więc upewnij się, iż nie staną się tylnymi drzwiami. Traktuj środowiska Dev/QA z niemal taką samą troską, jak produkcję. To już nie są niewinne piaskownice, ale integralna część ekosystemu, którą atakujący chętnie wykorzystają, jeżeli będzie słabo chroniona.
9. Współdzielenie poświadczeń między aplikacjami
Błąd: Używanie tego samego hasła lub tokenu dostępowego w wielu niezależnych aplikacjach lub usługach. Często spotykamy się z sytuacją, iż kilka aplikacji korzysta z jednego, „technicznego” konta bądź wszędzie w kodzie wpisywany jest identyczny klucz API. Jest to wygodne przy konfiguracji, ale kłóci się z zasadą need-to-have i least privilege. Każda aplikacja czy integracja powinna mieć własną unikalną tożsamość i uprawnienia dostosowane tylko do swoich potrzeb. Gdy wiele systemów dzieli jedno konto/sekret, przede wszystkim łamie to izolację – kompromitacja jednej aplikacji oznacza automatycznie dostęp do pozostałych. Po drugie, uniemożliwia to skuteczne zarządzanie: jeżeli trzeba zmienić hasło, musimy zsynchronizować tę zmianę we wszystkich powiązanych systemach, co bywa na tyle trudne, iż zniechęca do jakiejkolwiek rotacji. Współdzielenie utrudnia też audyt – nie wiadomo, która aplikacja w danym momencie użyła poświadczenia. Jak ujął to jeden z poradników: „złośliwe działania są trudniejsze do wykrycia, gdy wiele podmiotów korzysta z tych samych danych logowania”.
Jak unikać: Izoluj tożsamości aplikacji. Każda usługa powinna posiadać własne konto lub unikalny klucz dostępu, choćby jeżeli pełni podobną rolę, co inna. Unikaj tworzenia „superkont” używanych przez wszystko – lepsze jest posiadanie 10 kont z ograniczonym zakresem niż jednego z nieograniczonym. Wprowadź procedury wydawania nowych sekretów dla nowych integracji, zamiast odruchowo podawać istniejący. Wykorzystuj mechanizmy OAuth tam, gdzie to możliwe – zamiast udostępniać aplikacjom raw credentials, pozwalaj im działać na podstawie tokenów dostępowych wydanych dla każdej z osobna (co ułatwia unieważnienie pojedynczej integracji bez ruszania reszty). Z perspektywy Zero Trust (dla przypomnienia: „Co dla IAM oznacza Zero-Trust?”) – każde połączenie między komponentami powinno być uwierzytelniane odrębnie. Dzięki temu zyskasz też lepszą kontrolę: np. możesz logować i monitorować aktywność na poziomie poszczególnych aplikacji. Unikalność poświadczeń per aplikacja znacząco zmniejsza zasięg potencjalnego włamania i upraszcza reagowanie na incydenty (wystarczy zmienić klucz jednej usługi, nie powodując przestoju innych).
10. Słabe, niezłożone hasła
Błąd: Stosowanie prostych i przewidywalnych haseł dla kont maszynowych. O ile większość organizacji wypracowała polityki złożoności haseł dla kont pracowników, o tyle konta techniczne często umykają tym rygorom. Zwłaszcza starsze systemy (legacy) czy urządzenia IoT/OT mogą posiadać domyślne loginy typu admin/admin lub hasła typu P@ssw0rd, ustawione lata temu. Niezłożone hasła NHI są podatne na ataki słownikowe i brute-force, co czyni je łatwym celem. Głośnym przykładem konsekwencji takiego zaniedbania był botnet Mirai, który zdołał przejąć kontrolę nad setkami tysięcy urządzeń właśnie dzięki fabrycznym, banalnym hasłom (admin, 1234, root bez hasła). Ogólna zasada bezpieczeństwa IT mówi jasno: domyślne i proste hasła to ogromny problem – w przypadku NHI to również obowiązuje.
Jak unikać: Wymuszaj silne hasła również na kontach maszynowych. Każde hasło czy klucz statyczny powinny spełniać wymagania złożoności (długość, użycie różnych klas znaków, brak wzorców słownikowych). Najlepiej generować hasła automatycznie (losowe, długie) i przechowywać je w PAM lub menedżerze haseł – człowiek nie musi ich pamiętać, więc mogą być naprawdę skomplikowane. jeżeli to możliwe, stosuj klucze asymetryczne lub certyfikaty zamiast haseł – klucze RSA/ECC o odpowiedniej długości są nieporównanie trudniejsze do odgadnięcia niż najwymyślniejsze hasło. Unikaj pozostawiania ustawień domyślnych – po instalacji nowej aplikacji czy urządzenia IoT natychmiast zmień domyślne hasła. Wprowadź skanowanie pod kątem słabych haseł w środowisku. Pamiętaj też o polityce blokady – jeżeli to możliwe, ogranicz próby logowania i stosuj mechanizmy anti-bruteforce. Silne hasło to wciąż pierwsza linia obrony – nie pozwól, by najsłabszym ogniwem w Twojej infrastrukturze było hasło „qwerty” do konta, które ma dostęp do krytycznych danych.
Podsumowanie: Zarządzanie tożsamościami nieludzkimi bywa trudne, ale jest absolutnie niezbędne w dobie automatyzacji i chmury. Błędy takie jak pozostawienie haseł w kodzie, brak przeglądu kont czy niereagowanie na „wygasłe” konta mogą kosztować firmę kompromitację systemów i danych. Dobra wiadomość jest taka, iż większości z opisanych błędów można skutecznie uniknąć poprzez wdrożenie podstawowych zasad bezpieczeństwa: pełna widoczność (wiedza o wszystkich NHI), mocne uwierzytelnienie i regularna rotacja sekretów, ściśle ograniczone uprawnienia, separacja środowisk, a także automatyzacja zarządzania kontami maszynowymi (np. narzędzia IGA i PAM dostosowane do NHI, integracja z procesami DevSecOps). Traktuj konta maszynowe z równą uwagą, jak konta użytkowników – bo dla hakera nie ma większej różnicy, czy przejmie konto Jana Kowalskiego czy kontener aplikacji – wykorzysta jedno i drugie, jeżeli będzie miał taką okazję. Dzięki proaktywnemu podejściu i wystrzeganiu się powyższych błędów, zamkniesz przed atakującymi tę furtkę, jaką jest niewłaściwie zarządzane tożsamością nieludzką.
Jeżeli chcesz dowiedzieć się więcej, skontaktuj się z Prolimes.
