Myśląc o cyberbezpieczeństwie w naszych firmach głównie myślimy o ochronie infrastruktury fizycznej, tożsamości użytkowników czy urządzeń końcowych. Gdzieniegdzie organizowane są szkolenia dla pracowników unaoczniające potencjalne zagrożenia i namawiające do stosowania dobrych praktyk oraz sumiennego przestrzegania wewnętrznych polityk firmowych. Tymczasem coraz więcej incydentów zaczyna się gdzie indziej – od kont, które nigdy nie należały do żadnego człowieka.
Ciche konta z ogromnymi uprawnieniami
Konta serwisowe, konta aplikacji, skrypty w Active Directory, integracje API, to tzw. non-human identities (NHI). W typowej organizacji jest ich kilkukrotnie więcej niż kont ludzkich, a mimo to prawie nikt nie traktuje ich priorytetowo. Powód jest prosty: te konta „po prostu działają” od lat, nikt nie pamięta, kto je zakładał, zmiana hasła grozi wysypaniem krytycznej usługi, a zdarza się nawet, że administratorzy nie kontrolują jakie zadania wykonują rzeczone service accounts. W efekcie latami zachowują niezmienione hasła, nadmiarowe uprawnienia i zerową widoczność dla zespołów bezpieczeństwa. W tym obszarze znane porzekadło „działa, więc po co zmieniać” nabiera jeszcze więcej mocy oraz… obrazuje nieświadomość być może już czyhających za rogiem zagrożeń.
Problem pogłębia fakt, że praktycznie nie da się ich objąć standardowym MFA – nie działa tu uruchomione w organizacji chmurowe rozwiązanie, nie ma tu człowieka, który potwierdzi powiadomienie na telefonie, a rotacja haseł przez PAM bywa odkładana w nieskończoność z obawy przed przestojem. Powstaje luka: uprzywilejowane konta działają bez żadnej warstwy ochrony stosowanej wobec ludzi.
Realne przykłady, nie teoria
W ataku na SolarWinds (2020) przejęte konto serwisowe Orion, obrosłe latami w nagromadzone uprawnienia, pozwoliło poruszać się lateralnie po infrastrukturze niemal 18 tysięcznej organizacji, co wyglądało jak legalna aktywność administracyjna. W przypadku Ubera (2022) atakujący znalazł na współdzielonym zasobie skrypt PowerShell z zaszytymi danymi uprzywilejowanego konta i zyskał dostęp do kluczowych systemów. Inny przykład – zapomniane konto usługowe w infrastrukturze Starwood wykorzystano w jednym z największych wycieków danych hotelowych. Wspólny mianownik: konto, o którym nikt nie pamiętał, z uprawnieniami, których nikt nie weryfikował.
Jak realnie zabezpieczyć konta serwisowe
Pierwszy krok to pełna inwentaryzacja – bez wiedzy, ile kont NHI istnieje i z czym się łączą, nie da się nimi zarządzać. Nowoczesne platformy do ochrony tożsamości wykrywają takie konta automatycznie, na podstawie ich powtarzalnego zachowania, bez ręcznego tagowania każdego z nich.
Kluczowa zmiana to przejście od ochrony statycznej (hasła, rotacja) do behawioralnej w czasie rzeczywistym. Silverfort, bo o tym rozwiązaniu mowa, uczy się codziennej aktywności konta – jakich zasobów dotyka, skąd się loguje i tworzy na tej podstawie automatyczną politykę dostępu. Jest to więc realna odpowiedź na wymienione na początku tego tekstu obawy – uruchomienie dodatkowej ochrony starych i zaniedbanych kont serwisowych nie wygeneruje dodatkowych problemów, a pozwoli zaopiekować istotną część infrastruktury. W praktyce wystarczy kilka godzin a rozwiązanie Silverfort samodzielnie „nauczy się” behawiorystyki działania kont serwisowych i na podstawie utworzonych polityk będzie przyznawał dostęp lub go blokował. W ten sposób system wykryje każde odchylenie, np. logowanie z nietypowego hosta będzie blokowane lub zgłaszane alertem.
Takie podejście, integrujące się natywnie z Active Directory i chmurą, obejmuje ochronę kont dotąd niedostępne dla klasycznych MFA i PAM bez rotacji haseł i ryzyka przestoju. Skala problemu jest na tyle duża, że warto potraktować go priorytetowo, zanim stanie się punktem wejścia kolejnego incydentu.
Umów się na demo Silverfort:
https://outlook.office.com/book/KonsultacjaSilverfort@ISCG.onmicrosoft.com/?ismsaljsauthenabled
