Konta osierocone

czym to jest

Konta osierocone to konta użytkowników, które pozostają aktywne w Twoich systemach po tym, jak osoba, do której należą, przestała być zatrudniona lub zaangażowana. Termin obejmuje pracowników pełnoetatowych, którzy odeszli, kontraktorów, których projekty się skończyły, i freelancerów, których praca dobiegła końca.

Konto istnieje, może się uwierzytelniać i w wielu przypadkach zachowuje uprawnienia, jakie miało w momencie odejścia. Wpis w katalogu może pokazywać status wyłączony. Aplikacje SaaS, przechowywanie w chmurze, repozytoria kodu i integracje trzecie często o tym nie wiedzą.

Luka między „katalog mówi wyłączone" a „każdy system został zaktualizowany" to miejsce, gdzie żyją konta osierocone.

dlaczego się gromadzi

Offboarding zależy od kompletnej listy wszystkich miejsc, gdzie ktoś ma dostęp. Taka lista nie istnieje w większości środowisk bez dedykowanego narzędzia.

IT zna główny katalog. HR zna zapis zatrudnienia. Ale narzędzie do zarządzania projektami, do którego ktoś sam się dodał, platforma analityczna, którą podłączył bezpośrednio, wspólny login, który ktoś skonfigurował podczas pilnego projektu: to wszystko leży poza główną checklistą offboardingu.

Każdy pracownik dodaje z czasem nieformalny dostęp. Do dnia odejścia liczba systemów, których dotyka, jest zwykle większa niż liczba na jakiejkolwiek udokumentowanej liście. Ręczne checklisty mogą zamknąć tylko to, co widzą.

Jest też problem czasowy. Odbieranie dostępu często zależy od tego, że HR informuje IT, IT prowadzi proces, a każda aplikacja reaguje. Każde przekazanie to potencjalne opóźnienie albo krok, który po prostu się nie wydarzy.

co to kosztuje

Główne ryzyko jest proste: były pracownik lub kontraktor może zalogować się po odejściu. To, co zrobi z tym dostępem, zależy od intencji, ale możliwość istnieje niezależnie od tego, czy dzieje się coś złego.

Według raportu IBM Cost of a Data Breach (2025) identyfikacja i opanowanie naruszenia zajmuje średnio 241 dni. Konta osierocone mogą pozostawać otwarte przez cały ten okres, bez żadnego alertu, przeglądu ani mechanizmu, który by to zauważył.

Poza ekspozycją bezpieczeństwa jest też konsekwencja audytowa. SOC 2, ISO 27001, NIS2 i DORA wymagają dowodów, że dostęp jest kontrolowany. Audytor pytający „kto ma dostęp do tego systemu" i otrzymujący odpowiedź obejmującą byłych pracowników to niezgodność wymagająca naprawy i dokumentacji.

Jest też praktyczny koszt operacyjny. Licencje na aplikacje przypisane do kont, które nie służą już żadnemu celowi, wciąż się naliczają.

co działa

Najszybszym wykrywaczem jest porównanie dwóch list, które już istnieją: listy aktywnych użytkowników z katalogu lub IdP i zapisu HR o zwolnionych pracownikach. Konta aktywne w katalogu, ale zwolnione w HR, tworzą natychmiastową kolejkę przeglądu. To samo porównanie przeprowadza się potem na poziomie aplikacji, bo katalog obejmuje tylko to, co jest z nim połączone: lista aktywnych użytkowników każdej aplikacji SaaS zestawiona z katalogiem aktywnych pracowników, przy czym każdy obecny w aplikacji, a nieobecny w katalogu, jest albo osierocony, albo ma login omijający IdP.

Bezpośrednie loginy zasługują na osobne, celowe spojrzenie. Konta stworzone z prywatnymi adresami mailowymi albo samodzielnymi danymi uwierzytelniającymi nigdy nie pojawiają się w eksporcie IdP, więc sygnałem są użytkownicy wewnątrz aplikacji, których adresy nie pasują do żadnego oczekiwanego wzorca domeny. Konta serwisowe ukrywają cichszą wersję tego samego problemu: pole właściciela albo twórcy często wskazuje osobę, która odeszła lata temu, zostawiając działające dane uwierzytelniające bez obecnego właściciela i bez historii przeglądu.

To, co doświadczeni operatorzy robią ze znalezionym sierotą, to wyłączenie, nie usunięcie. Usunięcie trwale kasuje konfigurację, historię i zapisy własności w wielu systemach. Wyłączenie kończy dostęp równie skutecznie, zachowując zapis. Usunięcie może nastąpić później, gdy jest już jasne, że nic od konta nie zależało i nic z jego historii nie jest już potrzebne.