Ghost accounts: jak znaleźć dostęp, jaki wciąż mają byli pracownicy

czym naprawdę jest ghost account

Ghost account to dostęp, który przetrwał relację z firmą. Osoby już nie ma. Konta wciąż jest.

Ta kategoria jest szersza, niż zakłada większość checklist offboardingowych. Kiedy ktoś dołącza do firmy, gromadzi dostęp w systemach, z których korzysta. Konto katalogowe. Konta aplikacji wewnątrz i poza single sign-on. Granty OAuth wydane, żeby połączyć jedno narzędzie z drugim. Konta serwisowe utworzone do uruchamiania skryptu albo integracji. Współdzielone loginy, które dostał. Tokeny i klucze API, które wygenerował. Zanim odejdzie, jego dostęp jest rozproszony po większej liczbie miejsc, niż pamięta jedna osoba.

Kiedy odchodzi, IT zamyka konto katalogowe. Ten krok działa niezawodnie, bo IT nim zarządza i jest oczywisty. Wszystko inne zależy od tego, czy dany system był połączony z katalogiem, czy ktoś zbudował krok, który go zamyka, i czy ten krok faktycznie zadziałał.

Ghost account to to, co zostaje, kiedy jeden z tych warunków nie został spełniony. Należy do:

• Byłego pracownika, którego konto katalogowe zostało wyłączone, ale jego login do Notion, założony na prywatny mail, wciąż działa.
• Kontraktora, którego zlecenie skończyło się pół roku temu, a jego grant OAuth łączący narzędzie raportujące z Twoim CRM wciąż jest aktywny.
• Byłego admina, który utworzył konto serwisowe do nocnego eksportu danych, odszedł, a konto serwisowe wciąż działa z jego uprawnieniami i hasłem, które znał tylko on.
• Kogoś, kto znał współdzielone hasło do portalu rozliczeniowego, odszedł, a hasło nigdy nie zostało zmienione.

Żaden z tych przypadków nie jest egzotyczny. To zwyczajna pozostałość po ludziach wykonujących swoją pracę w rosnącym stosie narzędzi. Ręczny offboarding nie skaluje się, bo liczba systemów, z których korzysta pracownik, rośnie szybciej, niż nadąży za nią jakakolwiek ręczna checklista. Checklista zamyka drzwi, które ktoś pamiętał wypisać. Ghost accounts siedzą za drzwiami, których nikt nie wypisał.

dlaczego konto katalogowe to tylko pierwsze drzwi

Konto katalogowe, czyli to w Active Directory, Entra ID, Okta albo Google Workspace, to drzwi frontowe. Wyłączenie go jest konieczne i realnie coś daje. Blokuje osobie zalogowanie się do samego katalogu i blokuje każdą aplikację, która uwierzytelnia przez ten katalog za pomocą single sign-on.

W tym ostatnim zdaniu jest haczyk. Single sign-on obejmuje tylko te aplikacje, które podłączyłeś do single sign-on. Dla wszystkiego innego konto katalogowe to tylko jedne dane logowania spośród kilku, a jego wyłączenie nic nie daje.

Oto czego wyłączenie konta katalogowego nie dotyka.

Aplikacja uwierzytelniająca własnym hasłem. Narzędzie SaaS, które zespół wdrożył samodzielnie, założone na mail i hasło i nigdy niepodłączone do single sign-on, nie ma pojęcia, że konto katalogowe zostało wyłączone. Logowanie wciąż działa. Jeśli osoba założyła je na firmowego maila, możesz to później znaleźć. Jeśli użyła prywatnego maila, katalog nie ma żadnego śladu, że to konto w ogóle istnieje.

Token wciąż żyjący w skrypcie. Klucz API albo token dostępu wygenerowany przez tę osobę, wklejony do zaplanowanego zadania albo automatyzacji, dalej działa. Tokeny nie sprawdzają, czy człowiek, który je stworzył, wciąż pracuje w firmie. Uwierzytelniają żądanie i wygasają według własnego harmonogramu, który często oznacza „nigdy”.

Konto na prywatny mail używane do narzędzia firmowego. To ten przypadek, który nie zostawia żadnego śladu. Ktoś zarejestrował się w narzędziu na prywatnego Gmaila, bo było to szybsze niż zgłoszenie ticketu. Firmowe dane trafiły do środka. Katalog nigdy o tym nie wiedział. Kiedy osoba odchodzi, konto zostaje, przypisane do adresu maila, nad którym nie masz żadnej kontroli.

Grant OAuth wydany przez tę osobę. Kiedy ktoś klika „Zezwól”, żeby połączyć jedną aplikację z drugą, ten grant utrzymuje się dzięki tokenowi odświeżającemu. Wyłączenie konta katalogowego w wielu przypadkach nie cofa tego grantu. Połączenie dalej pobiera dane w harmonogramie, w jakim zostało skonfigurowane.

Współdzielony login, który ta osoba znała. Współdzielone dane logowania nie należą do jednego konta. Wyłączenie konta katalogowego nic nie robi z hasłem, które ta osoba zapamiętała. Pozostaje ważne, dopóki ktoś go nie zmieni.

Konto katalogowe to więc pierwsze drzwi i to ważne. Ale to nie cały budynek.

jak znaleźć ghost accounts

Znajdowanie ghost accounts to seria zestawień. Każde z nich porównuje listę kont z listą osób, które powinny mieć do nich dostęp. Tam, gdzie konto nie ma odpowiadającej mu aktualnej osoby, masz kandydata. Przechodź przez nie po kolei. Pierwsze jest najbardziej efektywne i najprostsze. Kolejne znajdują to, czego pierwsze nie widzi.

zestaw katalog z HR

Pobierz pełną listę kont z dostawcy tożsamości. Pobierz listę aktualnych pracowników i aktywnych kontraktorów z systemu HR. Porównaj je. Każde konto w katalogu, które nie odpowiada aktualnej osobie w HR, jest ghost accountem albo jest blisko tego. Ta metoda znajduje konta katalogowe, które nigdy nie zostały wyłączone, konta osób, których odejście nigdy nie zostało zgłoszone do IT, oraz konta kontraktorów, których data zakończenia zlecenia minęła, a nikt nic z tym nie zrobił.

To najbardziej produktywna kontrola ze wszystkich, bo katalog to jedyne miejsce z względnie kompletną listą kont, a HR to jedyne miejsce z względnie kompletną listą tego, kto wciąż tu pracuje. Różnica między nimi to Twój punkt wyjścia. Nie będzie idealny. HR rejestruje kontraktorów niekonsekwentnie, a konta serwisowe i współdzielone pojawiają się bez odpowiadającego im człowieka, co jest oczekiwane i obsługiwane osobno. Ale zestawienie daje Ci uporządkowaną listę kont ludzkich do zamknięcia.

przejrzyj konta w aplikacjach i daty ostatniego logowania

Przejdź aplikacja po aplikacji. Dla każdej aplikacji, w której trzymasz coś ważnego, pobierz jej własną listę użytkowników, która nie jest tym samym co lista osób sięgających do niej przez single sign-on. Dla każdego użytkownika sprawdź dwie rzeczy: czy ta osoba wciąż tu pracuje i kiedy ostatnio się logowała.

Użytkownik, który odszedł z firmy, to ghost account w danej aplikacji. Użytkownik, który nie logował się od dziewięćdziesięciu dni, to kandydat wart sprawdzenia, bo brak aktywności często oznacza, że osoba odeszła albo nie potrzebuje już dostępu. To wolniejsze niż zestawienie z katalogiem, bo dzieje się aplikacja po aplikacji, ale właśnie tu znajdziesz konta, których zestawienie nie widzi: te uwierzytelniające się własnym hasłem, poza single sign-on.

przejrzyj granty OAuth i tokeny powiązane z osobami, które odeszły

Dla głównych platform w Twoim stacku pobierz listę grantów OAuth i wydanych tokenów. Większość dostawców tożsamości i głównych platform SaaS pokazuje to w widoku administracyjnym: które aplikacje zewnętrzne są podłączone i który użytkownik autoryzował każdą z nich. Dla każdego grantu znajdź użytkownika, który go wydał. Jeśli ta osoba odeszła, grant jest połączeniem-widmem, wciąż przenoszącym dane między dwoma systemami na podstawie autoryzacji osoby, której już nie ma.

Zrób to samo dla tokenów API i tokenów dostępu osobistego tam, gdzie platforma zapisuje, kto je utworzył. Token utworzony przez byłego pracownika to dostęp, który przetrwał tę osobę, często bez terminu ważności. Ta kontrola ma znaczenie, bo granty OAuth i tokeny to typ dostępu najczęściej pomijany całkowicie. Nie są kontami w zwyczajnym sensie, więc przeglądy skupione na kontach je pomijają.

sprawdź konta serwisowe i współdzielone pod kątem byłych właścicieli

Konta serwisowe i współdzielone z założenia nie mają przypisanej osoby, dlatego właśnie stają się ghost accounts, kiedy ich właściciel odchodzi. Dla każdego konta serwisowego ustal, kto je utworzył i kto jest za nie odpowiedzialny teraz. Konto serwisowe, którego jedyny świadomy właściciel odszedł, jest osierocone: wciąż działa, wciąż ma nadane uprawnienia, a nikt aktualnie zatrudniony nie wie, co by się zepsuło, gdyby je wyłączyć.

Dla każdego konta współdzielonego wypisz, kto znał hasło. Jeśli ktokolwiek z tej listy odszedł, dane logowania są skompromitowane w dosłownym sensie: osoba spoza firmy ma działający login. Te konta nie pojawiają się w zestawieniu z HR, bo nigdy nie były przypisane do jednej osoby. Znajdujesz je, przechodząc bezpośrednio przez katalog i platformy i pytając, dla każdego konta niebędącego kontem człowieka, kto za nim stoi.

sprawdź podłączone aplikacje uwierzytelniające poza single sign-on

Na koniec poszukaj aplikacji, których poprzednie kontrole nie widziały, bo leżą całkowicie poza Twoim zarządzanym środowiskiem. To narzędzia wdrożone bez udziału IT, założone na prywatne maile albo samodzielne hasła, nigdy niepodłączone do single sign-on. Nie ma konta katalogowego do zestawienia ani widoku administracyjnego, który kontrolujesz.

Znajdujesz je przez discovery, nie zestawienie. Raporty wydatków pokazują cykliczne opłaty za narzędzia, których nikt nie skatalogował. Sygnały z przeglądarki i sieci pokazują ruch do domen SaaS. A najbardziej niezawodną metodą na przypadek prywatnego maila jest krótka ankieta wśród zespołu: zapytaj każdego menedżera i każdego pozostałego członka zespołu, jakich narzędzi używała osoba, która odeszła, na co się rejestrowała i do czego miała dostęp, którego reszta zespołu nie miała.

jak prawidłowo zamknąć ghost accounts

Znalezienie konta to połowa roboty. Prawidłowe zamknięcie oznacza, że dostęp faktycznie zniknął i możesz to udowodnić. Każdy typ zamyka się nieco inaczej.

Najpierw wyłącz, potem usuń. Dla konta człowieka w aplikacji albo katalogu wyłącz je najpierw. Wyłączenie jest odwracalne i natychmiastowe. Blokuje dostęp, podczas gdy potwierdzasz, że nic się nie psuje i nic ważnego nie jest przypisane do tego konta. Po okresie karencji usuń je, żeby nie pojawiło się ponownie w przeglądzie za kwartał jako coś do zbadania od nowa.

Odwołaj tokeny i granty OAuth. Wyłączenie konta nie zawsze cofa wydane przez nie granty i tokeny. Odwołaj je jawnie, na poziomie aplikacji, w widoku administracyjnym, gdzie są wylistowane. Odwołany token zatrzymuje skrypt, który go używał, więc sprawdź, co od niego zależy, zanim go wyłączysz, a potem go odwołaj.

Przypisz nowego właściciela albo wygaś konta serwisowe. Konto serwisowe, które wciąż jest potrzebne, dostaje nowego, aktualnego właściciela, który wie, co ono robi, i może za nie odpowiadać. Zresetuj jego dane logowania, żeby były twórca nie miał już działającego loginu. Konto serwisowe, które nie jest już potrzebne, zostaje wyłączone, a potem wygaszone, z okresem karencji na potwierdzenie, że nic się nie psuje.

Zmień każde współdzielone hasło, które ta osoba znała. Jeśli była osoba znała współdzielone hasło, zmień je. Nie ma tu wersji częściowej. Dane logowania są znów zabezpieczone dopiero wtedy, gdy hasło różni się od tego, które ta osoba pamięta. Zaktualizuj osoby, które wciąż go potrzebują, przez menedżera haseł, nie wysyłając nowego hasła mailem.

Zapisz, co zrobiłeś. Dla każdego zamkniętego ghost accountu zapisz, czym było, kiedy je zamknąłeś i jak. To zamienia sprzątanie w dowód. Kiedy audytor zapyta, jak obsługujesz dostęp osób odchodzących, albo te same pytania wrócą za kwartał, ten zapis jest odpowiedzią. Mówi też, co już sprawdziłeś, więc kolejne podejście zaczyna się tam, gdzie skończyło się to.

uczciwy zakres zestawienia

Zestawienie katalogu z HR znajduje dużo. To najbardziej efektywna dostępna kontrola. Ale ma twardą granicę, a jasność co do niej ma większe znaczenie niż przecenianie możliwości tej metody. Zestawienie działa przez dopasowanie kont do ludzi. Może znaleźć tylko konta, które pojawiają się na liście, jaką da się pobrać. Konto katalogowe, konto aplikacji na firmowego maila, grant OAuth zapisany przy użytkowniku: to zostawia ślad, który da się porównać z HR.

Aplikacja, z której były pracownik korzystał na prywatny mail bez połączenia z single sign-on, nie zostawia takiego śladu. Leży poza Twoim katalogiem, nieprzypisana do żadnej tożsamości służbowej. Żadne zestawienie jej nie wykryje, bo po Twojej stronie porównania nie ma nic do dopasowania. Dlatego przegląd aplikacja po aplikacji i ankieta to nie opcjonalne dodatki. To jedyny sposób, żeby dotrzeć do dostępu, którego automatyczne kontrole strukturalnie nie widzą. Sprzątanie oparte wyłącznie na zestawieniu jest dobrym sprzątaniem ze znaną luką. Sprzątanie, które dodaje przegląd aplikacji i ankietę, tę lukę zamyka.

jak zapobiec kolejnej fali

Znajdowanie ghost accounts to sprzątanie. Zajmuje się dostępem, który już istnieje. Nie robi nic, żeby powstrzymać kolejną osobę odchodzącą przed zostawieniem własnych pozostałości. Trwałym rozwiązaniem jest proces offboardingu, który dociera do każdego systemu, nie tylko katalogu: taki, który rutynowo, w dniu odejścia osoby, zamyka konta aplikacji poza single sign-on, odwołuje granty i tokeny, przypisuje nowych właścicieli kontom serwisowym i zmienia współdzielone dane logowania, zamiast robić to jako sprzątanie odkryte miesiące później. Uruchom sprzątanie, żeby wyczyścić to, co już jest. Zbuduj proces offboardingu, żeby nie musieć sprzątać ponownie.