Offboarding SaaS

czym jest

Offboarding SaaS to proces zamykania albo dezaktywowania dostępu odchodzącego pracownika we wszystkich aplikacjach, których używał, nie tylko w centralnym katalogu tożsamości.

Standardowy offboarding zamyka konto Microsoft 365 albo Google Workspace. Aplikacje połączone z tym kontem przez SSO stają się wtedy niedostępne. Ale aplikacje działające na niezależnych danych logowania, dodane do zestawu narzędzi pracownika bez udziału IT albo niewspierające SSO, nie są w żaden sposób dotknięte zamknięciem konta w katalogu.

Dane logowania pracownika w tych narzędziach pozostają ważne. Jego sesje mogą pozostać aktywne. Jeśli zapisał hasło lokalnie, może zalogować się z dowolnego urządzenia.

Badanie Beyond Identity wykazało, że 83% pracowników przyznaje, że nadal ma dostęp do przynajmniej jednego konta u poprzedniego pracodawcy (Beyond Identity, 2022, dane self-reported). Konto w katalogu to widoczna część offboardingu. Luki powstają na poziomie aplikacji.

dlaczego narasta

Luki w offboardingu SaaS narastają z tego samego powodu co shadow SaaS: warstwa aplikacji rośnie szybciej, niż jakikolwiek ręczny proces jest w stanie za nią nadążyć.

Pracownik, który jest w firmie dwa albo trzy lata, zwykle połączył się z całym szeregiem narzędzi, niektóre zatwierdzone przez IT, inne wdrożone samodzielnie do własnej pracy. Lista kontrolna offboardingu IT obejmuje narzędzia, o których IT wie. Reszty nie ma na żadnej liście.

Nawet w przypadku znanych narzędzi ręczny offboarding wymaga, żeby ktoś zalogował się do panelu administracyjnego każdej aplikacji, znalazł konto i je dezaktywował. Wraz ze wzrostem liczby aplikacji staje się to czasochłonnym zadaniem, które często dzieje się równolegle z pilną pracą. Kroki są odkładane albo pomijane.

Problem narasta przy każdym kolejnym offboardingu. Każde odejście zostawia potencjalny osad otwartych kont. Z czasem środowisko trzyma konta byłych pracowników, kontraktorów i konsultantów w narzędziach, którymi nikt aktywnie nie zarządza.

co to kosztuje

Bezpośrednie ryzyko dostępu. Były pracownik z dostępem do CRM, narzędzia do zarządzania projektami, platformy dokumentów czy systemu komunikacji może dalej czytać, eksportować albo modyfikować dane. Ryzyko jest wyższe, gdy odejście było konfliktowe albo gdy dana osoba przechodzi do konkurencji.

Zachowany dostęp. Badanie Beyond Identity wykazało, że 83% pracowników przyznaje, że nadal ma dostęp do przynajmniej jednego konta u poprzedniego pracodawcy (Beyond Identity, 2022, dane self-reported). W każdym środowisku ze znaczącym wykorzystaniem SaaS oznacza to, że większość odejść zostawia po sobie przynajmniej jedno otwarte konto.

241 dni luki w wykrywaniu. Badania IBM wskazują średni czas identyfikacji i opanowania naruszenia na 241 dni. Otwarte konta byłych pracowników są rzadko monitorowane. Jeśli dostęp zostanie użyty, najprawdopodobniej pozostanie niewykryty przez miesiące.

Niezaliczony audyt. Zarówno SOC 2 Trust Services Criteria, kontrola A.9.2.6 normy ISO 27001 (usuwanie dostępu użytkownika), jak i wymagania DORA dotyczące zarządzania dostępem, oczekują terminowego odbierania uprawnień. Audytorzy to sprawdzają. Znalezienie wielu aktywnych kont byłych pracowników to bezpośrednia niezgodność.

Konsekwencje dla rezydencji danych i RODO. Jeśli były pracownik zachowuje dostęp do narzędzia, które przetwarza dane osobowe klientów, odpowiedzialność organizacji za te dane nie kończy się wraz z jego odejściem. Niezarządzany dostęp byłego pracownika do procesorów danych tworzy ekspozycję na ryzyko związane z RODO.

co działa

Solidne sprzątanie zaczyna się od listy odejść: wszyscy, którzy odeszli w ostatnie 12 do 18 miesięcy, z datami i, jeśli to możliwe, rolami i działami. Role przekładają się na aplikacje, aplikacje na listy użytkowników, a porównanie, kto odszedł i kto nadal ma konto w każdym narzędziu, to cała metoda. Jest żmudna dokładnie w tych miejscach, które mają największe znaczenie, i właśnie dlatego luki w ogóle powstały.

Dwie warstwy trzeba obsłużyć osobno, bo zawodzą osobno. W IdP dezaktywacja konta w katalogu nie odbiera uprawnień OAuth tego konta; uprawnienia przetrwają dezaktywację i wymagają jawnego usunięcia, co sprawia, że szukanie aktywnych uprawnień na dezaktywowanych kontach jest jedną z najbardziej opłacalnych kontroli. Poza SSO nie ma nic centralnego do sprawdzenia, więc każde niezależnie uwierzytelniające się narzędzie wymaga własnej weryfikacji w konsoli administracyjnej względem listy odejść. To właśnie ta druga warstwa najczęściej zawodzi w ręcznym offboardingu, bo zależy od tego, czy IT wie o istnieniu narzędzia i pamięta o nim przy każdym odejściu. Sprzątanie naturalnie zaczyna się od aplikacji, które trzymają wrażliwe dane albo mają wysoki zakres OAuth, bo tam otwarte konto robi najwięcej szkody.

Proces, który zapobiega powtórce, ma dwie cechy. Pierwsza to nazwana odpowiedzialność: jedna osoba odpowiedzialna za potwierdzenie przy każdym odejściu, że zamknięty jest dostęp do aplikacji, a nie tylko konto w katalogu, bo lista kontrolna bez właściciela z czasem znów zamienia się w offboarding ograniczony do katalogu, który miała zastąpić. Druga to automatyzacja tam, gdzie istnieje: provisioning SCIM dezaktywuje konta aplikacji bezpośrednio ze zdarzenia w katalogu, całkowicie eliminując ręczną zależność dla aplikacji, które to wspierają, i zostawiając ludzką uwagę dla kurczącej się listy tych, które tego nie robią.