Offboarding w firmie na SaaS-ach: odbieranie dostępów, zanim będzie za późno

W audytach procesów mamy stałe pytanie kontrolne: kto odszedł z firmy w ostatnim półroczu i czy na pewno nie ma już dostępu do żadnego systemu. Odpowiedź brzmi zwykle „no, mail na pewno zablokowaliśmy". Potem otwieramy panel administracyjny CRM-u i widzimy tam trzy aktywne konta osób, które w tej firmie nie pracują.

Trudno to nazwać niedbalstwem. Tak wygląda każda firma, która przez pięć lat rozrastała się na SaaS-ach: ktoś kupował kolejne narzędzia, każde ma własną listę użytkowników, część podpięto pod czyjś prywatny login, a nigdzie nie ma jednego miejsca z odpowiedzią na pytanie, kto ma dostęp do czego. Offboarding sprowadza się wtedy do wysiłku pamięciowego jednej osoby w piątkowe popołudnie. Poniżej opisuję, jak układamy to u klientów, bez kupowania systemu klasy IAM, bo w firmie na czterdzieści osób to armata na wróbla.

TL;DR: Offboarding zaczyna się od rejestru „osoba × narzędzie × poziom", uzupełnianego przy onboardingu. Dzień zero: blokada konta w Google Workspace lub Microsoft 365 razem z unieważnieniem aktywnych sesji, potem narzędzia bez SSO według rejestru, rotacja haseł współdzielonych, klucze SSH i VPN, karty i subskrypcje. Konta serwisowe zakładasz wcześniej, zanim odejdzie osoba, na której koncie stoją integracje.

Dlaczego to boli bardziej, niż wygląda

Cztery sytuacje z praktyki. W żadnej nie było złej woli po drugiej stronie.

Handlowiec odchodzi do konkurencji. IT blokuje mu maila w poniedziałek, ale konto w CRM zostaje, bo CRM-em zarządza dyrektor sprzedaży i nikt go o to nie poprosił. Przez miesiąc były pracownik loguje się do bazy z historią kontaktów i cenami. Nie musi nic wykradać, wystarczy, że ma to na ekranie.

Druga jest subtelniejsza: sesja przeżywa blokadę konta. Wyłączenie konta zatrzymuje kolejne logowanie, ale nie zamyka sesji, które już trwają. Zalogowana przeglądarka i aplikacja mobilna z ważnym tokenem odświeżania potrafią działać dalej.

Trzecia to hasło „zespołowe": jedno konto do panelu firmy kurierskiej, jedno do Allegro, jedno do hostingu. Zna je pół firmy, w tym cztery osoby, które już odeszły. Nikt go nie zmienił, bo zmiana oznacza obdzwonienie wszystkich, którzy z niego korzystają. Gorsza od ryzyka dostępu jest inna konsekwencja: przy wspólnym loginie nie da się ustalić, kto wykonał daną operację.

Czwarta wychodzi przypadkiem, przy przeglądzie kosztów licencji.

„Dostęp byłego pracownika odkrywamy zwykle nie przy audycie bezpieczeństwa, tylko przy sprzątaniu faktur. Ktoś zauważa, że firma od pół roku płaci za licencję osoby, która odeszła w marcu, i dopiero wtedy wychodzi, że to konto przez cały ten czas działało. Konto, za które płacisz, to konto, które ktoś może otworzyć." — Mikołaj Brunka, założyciel NoCodeWork

Rejestr dostępów: fundament całej reszty

Bez rejestru offboarding jest zgadywanką i tak też wygląda. Ktoś siada, wypisuje z głowy siedem narzędzi, blokuje konta i uznaje temat za zamknięty. Narzędzi jest dwadzieścia dwa.

Kolumna „sposób logowania" wygląda na techniczny drobiazg, a rozdziela wpisy na trzy zupełnie różne ścieżki. Dostępy przez SSO gasną razem z kontem głównym. Dostępy z osobnym loginem trzeba wyłączyć w każdym narzędziu z osobna. Hasła współdzielone wymagają rotacji i poinformowania wszystkich, którzy ich używają.

W małej firmie wystarczy arkusz, byle jeden i byle wersjonowany. Powyżej trzydziestu osób lepiej sprawdza się prosta baza: Airtable, NocoDB na własnym serwerze albo tabela w narzędziu, którego firma już używa. Wtedy rejestr da się odpytać przez API i staje się źródłem danych dla automatyzacji zamiast dokumentem do czytania. Kiedy arkusz przestaje wystarczać, opisaliśmy w tekście o aplikacji wewnętrznej zamiast Excela.

Trudne jest nie założenie rejestru, tylko utrzymanie go w aktualności. Działa jedna zasada: rejestr uzupełnia się przy onboardingu, a nadanie dostępu bez wpisu traktujemy jak dostęp nienadany. Jak poukładać to od strony kadrowej, opisaliśmy w artykule o automatyzacji procesów HR. Pierwsze wypełnienie zajmuje zwykle jeden dzień i jest nieprzyjemne, bo wychodzą wtedy wszystkie narzędzia kupione poza wiedzą zarządu. To druga funkcja rejestru: pokazuje, za co firma naprawdę płaci.

Dzień zero: checklista odbierania dostępów

Dzień zero to dzień zakończenia współpracy, a nie dzień, w którym ktoś znajdzie czas. Kolejność ma znaczenie: najpierw miejsca, przez które można wejść wszędzie indziej.

Konto główne. W Google Workspace zawieszenie konta to ustawienie pola suspended na true przez Admin SDK Directory API (PUT albo PATCH na /admin/directory/v1/users/{userKey}, zakres admin.directory.user). Osobno wywołujesz users.signOut (POST na /admin/directory/v1/users/{userKey}/signOut, zakres admin.directory.user.security), co wylogowuje użytkownika ze wszystkich sesji przeglądarkowych i urządzeń oraz resetuje ciasteczka logowania.

W Microsoft 365 odpowiednikiem jest PATCH /users/{id | userPrincipalName} z accountEnabled: false w Microsoft Graph; najmniej uprzywilejowana kombinacja uprawnień do zmiany tego pola to User.EnableDisableAccount.All razem z User.Read.All. Sesje zamykasz przez POST /users/{id}/revokeSignInSessions (uprawnienie User.RevokeSessions.All), które unieważnia tokeny odświeżania wydane aplikacjom oraz ciasteczka sesji w przeglądarce, przestawiając właściwość signInSessionsValidFromDateTime na bieżącą datę. Microsoft zastrzega przy tym dwie rzeczy istotne przy odejściach konfliktowych: unieważnienie może zająć kilka minut, a operacja nie obejmuje użytkowników zewnętrznych logujących się przez własnego dostawcę tożsamości.

W obu ekosystemach to są dwie osobne czynności i na tym polega cały krok. Blokada bez unieważnienia sesji zostawia otwarte okno.

Dostępy zdalne. Klucz publiczny SSH usunięty z authorized_keys na wszystkich serwerach, konto VPN wyłączone, urządzenie wyrejestrowane z sieci firmowej. Jeden wspólny klucz do serwerów to ten sam problem co hasło zespołowe, tylko trzeba go wymienić wszędzie.

Poczta. Konta nie usuwamy. Zawieszone zostaje z całą historią, a przełożony dostaje do niego dostęp albo przekierowanie przychodzącej korespondencji. Uwaga na licencje: zawieszone konto w Google Workspace nadal ją zajmuje, dopóki go nie usuniesz, więc sprawdź w swoim planie tańszy wariant archiwalny. W Microsoft 365 typową ścieżką jest konwersja skrzynki na współdzieloną, co przy niedużych skrzynkach pozwala zwolnić licencję.

Narzędzia. Przy logowaniu przez konto Google albo Microsoft blokada konta głównego załatwia sprawę, choć w dwóch najważniejszych systemach i tak warto to sprawdzić, bo część narzędzi trzyma własną sesję jeszcze przez jakiś czas. Reszta to ręczna robota według rejestru: dezaktywacja użytkownika w panelu każdego narzędzia z osobna, nie usunięcie. Usunięcie potrafi zabrać ze sobą historię działań tej osoby, a ta bywa potrzebna.

Hasła współdzielone. Każdy wpis oznaczony w rejestrze jako współdzielony wymaga zmiany hasła i przekazania nowego pozostałym. To najbardziej upierdliwy krok i dlatego najczęściej pomijany. Jeśli rotacja oznacza u Was obdzwonienie ośmiu osób, problemem nie jest procedura, tylko brak menedżera haseł dla zespołu: hasło leży w sejfie, zmiana jest jednym ruchem, a dostęp do sejfu odbiera się razem z kontem.

Karty, subskrypcje, dane. Karta służbowa zablokowana, subskrypcje opłacane z prywatnej karty pracownika przepięte na firmową. Ten drugi punkt zaskakuje najczęściej: usługa opłacana prywatnie i refakturowana przestaje działać w chwili, gdy pracownik anuluje płatność, a w firmie nikt nie wie nawet, że tam była. Na koniec pliki: te utworzone na Dysku Google należą do jego konta i znikają razem z jego usunięciem, więc własność przenosisz przez Data Transfer API (POST na /admin/datatransfer/v1/transfers, zakres admin.datatransfer) albo ręcznie z panelu. Przed usunięciem konta, nie po.

Workflow „odchodzi pracownik"

Automatyzacja offboardingu nie polega na tym, że robot zamyka wszystkie drzwi. Robot zamyka te, które umie, a o pozostałych nie pozwala zapomnieć. Podział przebiega po granicy dostępności API; jak sprawdzić, po której stronie leży dane narzędzie, opisaliśmy w tekście o tym, jak rozpoznać, czy narzędzie ma API.

Tak wygląda ten proces w n8n u naszych klientów:

1. Trigger: formularz wypełniany przez kadry albo zmiana statusu w bazie kadrowej. Dane wejściowe to osoba, data ostatniego dnia, tryb odejścia (standardowy albo natychmiastowy) i przełożony przejmujący obowiązki.
2. Workflow odpytuje rejestr, wyciąga wiersze tej osoby i dzieli je na dwa koszyki: narzędzia z API i cała reszta.
3. Ścieżka automatyczna. Google Workspace: zawieszenie plus wylogowanie ze wszystkich sesji. Microsoft 365: accountEnabled: false plus unieważnienie sesji. Do tego dezaktywacja użytkownika wszędzie, gdzie API na to pozwala, czyli zwykle w komunikatorze, w narzędziu do projektów, w CRM i w repozytorium kodu.
4. Ścieżka ręczna. Każdy pozostały wpis staje się osobnym zadaniem z właścicielem i terminem. Zadanie brzmi konkretnie: „wyłącz konto Anny K. w panelu firmy kurierskiej", a nie „sprawdź dostępy".
5. Rotacja haseł: osobne zadanie na każde hasło oznaczone w rejestrze jako współdzielone, z listą osób do poinformowania.
6. Workflow wpisuje datę odebrania do rejestru i wysyła na czat jedną wiadomość: co zablokował sam, co czeka na ludzi, co się nie udało.

Ostatni punkt bywa lekceważony, a decyduje o wszystkim. Automatyzacja, która próbuje zablokować konto i dostaje błąd autoryzacji, nie może zawieść po cichu, bo wtedy firma ma poczucie bezpieczeństwa bez bezpieczeństwa. Jak ustawić takie alerty, żeby ktoś je faktycznie czytał, opisaliśmy w tekście o monitoringu automatyzacji. Przed samym uruchomieniem zostawiamy krok potwierdzenia, bo pomyłkowe zablokowanie kont pracującej osoby kosztuje pół dnia pracy zespołu: człowiek akceptuje, automat wykonuje.

Z naszej praktyki zbudowanie takiego procesu razem z rejestrem mieści się w widełkach 3–10 tys. zł, zależnie od liczby systemów z API. Szerzej o automatyzacjach po stronie IT piszemy w artykule o automatyzacji działu IT w MŚP.

Konta serwisowe: dlaczego po odejściu jednej osoby padają integracje

Na tym przewraca się co druga firma i to jest najdroższa konsekwencja offboardingu zrobionego poprawnie.

Kiedy podpinasz Gmaila, Dysk, CRM albo arkusz do n8n czy Make, autoryzujesz połączenie przez OAuth. Token, który powstaje, jest wystawiony na konkretne konto: tej osoby, która akurat siedziała przy klawiaturze podczas konfiguracji. Zawieszasz to konto w ramach offboardingu i wszystkie integracje wiszące na tym tokenie przestają działać. Zwykle bez żadnego komunikatu, więc firma dowiaduje się po tygodniu, kiedy okazuje się, że leady z formularza od wtorku nigdzie nie trafiają. To samo dotyczy reguł automatyzacji przypisanych do konta autora, zaplanowanych raportów i integracji bankowych.

Wzorzec, który wdrażamy zawsze:

• Osobne konto serwisowe typu [email protected], którego właścicielem jest firma, a nie człowiek. Wszystkie integracje autoryzujesz z tego konta.
• Hasło i drugi składnik w sejfie zespołowym, z dostępem dla co najmniej dwóch osób. Konto serwisowe, do którego klucz ma jedna osoba, to ten sam problem w nowym opakowaniu.
• Uprawnienia aplikacyjne zamiast delegowanych tam, gdzie ekosystem to umożliwia. W Google Workspace to konto usługi z delegacją w domenie, w Microsoft 365 rejestracja aplikacji z uprawnieniami app-only. Wtedy integracja nie wisi na żadnym użytkowniku.
• Kolumna „na czyim koncie stoi" w rejestrze integracji, sprawdzana przed każdym offboardingiem.

Przy automatyzacjach zbudowanych przez kogoś z zewnątrz ten problem występuje w ostrzejszej wersji, bo konta bywają prywatne i poza kontrolą firmy. Rozpisaliśmy to w instrukcji przejęcia automatyzacji po freelancerze.

RODO: dostęp byłego pracownika to incydent, nie drobiazg

Ta część przekonuje zarząd szybciej niż argument o bezpieczeństwie. Pracownik przetwarza dane osobowe klientów i współpracowników na polecenie administratora, czyli firmy, i na podstawie upoważnienia. Z dniem zakończenia współpracy upoważnienie wygasa. Jeśli tego samego dnia nadal ma techniczną możliwość zalogowania się do CRM-u z bazą klientów, dane osobowe są dostępne dla osoby nieupoważnionej. To wypełnia definicję naruszenia ochrony danych osobowych, a nie zaległości administracyjnej.

RODO wymaga od administratora wdrożenia odpowiednich środków technicznych i organizacyjnych zapewniających bezpieczeństwo przetwarzania, a procedura odbierania uprawnień należy do podstawowych. Naruszenie trzeba też ocenić pod kątem ryzyka dla praw i wolności osób, których dane dotyczą, i przy wystąpieniu takiego ryzyka zgłosić je organowi nadzorczemu bez zbędnej zwłoki, najpóźniej w ciągu 72 godzin od stwierdzenia. Ten termin biegnie od momentu, w którym ktoś w firmie się zorientował, a nie od zakończenia ustaleń wewnętrznych. Stąd kolumna „data odebrania" i logi z workflow przestają być porządkowym drobiazgiem: w razie kontroli albo sporu z byłym pracownikiem to jedyny dowód, że procedura zadziałała.

Osobny temat to dostęp przełożonego do skrzynki byłego pracownika: technicznie prosty, prawnie już nie, bo w firmowej skrzynce zwykle znajdzie się też korespondencja prywatna. Standardowo przekierowuje się przychodzącą pocztę i zapisuje to w regulaminie, zamiast swobodnie przeglądać archiwum. Gdzie w automatyzacjach lądują dane osobowe, opisaliśmy w tekście n8n a RODO, a nową warstwę przepisów w artykule o AI Act i RODO.

Audyt kwartalny: kto ma co i po co

Rejestr i procedura rozjeżdżają się z rzeczywistością mniej więcej po kwartale. Ktoś nadał komuś dostęp w pośpiechu, ktoś dołożył narzędzie, ktoś zapomniał odhaczyć zadanie. Raz na kwartał eksportujesz więc listę użytkowników z każdego kluczowego narzędzia i porównujesz ją z rejestrem oraz z listą osób zatrudnionych. Szukasz pięciu rzeczy:

• Kont osób, których nie ma już w firmie.
• Kont bez przypisanego właściciela, zwykle o nazwach w rodzaju „biuro" albo „test".
• Uprawnień administratora u osób, które ich do pracy nie potrzebują. To najczęstsze odchylenie, bo administratora nadaje się „na chwilę" przy jakimś problemie.
• Dostępów gości i firm zewnętrznych, którym projekt skończył się dawno temu: agencji, księgowej, poprzedniego wykonawcy.
• Integracji OAuth podpiętych do kont osobowych zamiast serwisowego.

Ten przegląd też da się zautomatyzować: workflow pobiera listy użytkowników przez API i wystawia raport z samymi różnicami wobec rejestru, a człowiekowi zostaje decyzja, co z każdą różnicą zrobić. Przy dwudziestu narzędziach to różnica między dniem klikania a piętnastoma minutami czytania. Przy okazji sprawdź, czy nikt nie wgrał firmowych danych do losowego narzędzia AI; ten wątek rozpisaliśmy w poradniku jak bezpiecznie korzystać z AI w organizacji.

Na co uważać

• Nie automatyzuj usuwania kont, tylko blokowanie. Usunięcie zabiera dane, historię działań i dowody. Odwrócenie pomyłkowej blokady zajmuje minutę, odtworzenie usuniętego konta bywa niemożliwe.
• Nie buduj automatu przed rejestrem. Workflow zablokuje dokładnie te systemy, o których mu powiedziałeś. Bez aktualnej listy dostajesz szybszą wersję tego samego niepełnego offboardingu, tylko z raportem, który wygląda wiarygodnie.
• Data w systemie kadrowym to nie zawsze dzień zero. Koniec umowy, ostatni dzień w pracy i moment odcięcia dostępów potrafią być trzema różnymi datami. Trigger musi obsługiwać tryb natychmiastowy.
• Nie odcinaj dostępów przed rozmową. Człowiek, który dowiaduje się o zwolnieniu przez zablokowanego maila, opowie o tym całej branży. Kolejność jest zawsze taka sama: rozmowa, potem blokada, najlepiej tego samego dnia.
• Offboarding dotyczy też osób, których nie zatrudniasz. Podwykonawcy, agencja marketingowa, księgowa, poprzedni wykonawca automatyzacji. Wchodzą do rejestru na tych samych zasadach, a wypadają z niego rzadziej, bo nikt nie dostaje o tym informacji z kadr.
• Przy odejściach konfliktowych liczą się minuty, nie elegancja procesu. Miej wariant „odetnij wszystko teraz", uruchamiany ręcznie przez jedną osobę, bez zatwierdzania w trzech miejscach.

FAQ

Jak szybko trzeba odebrać dostępy odchodzącemu pracownikowi?

Najpóźniej w dniu zakończenia współpracy, a przy odejściach konfliktowych w ciągu godziny od rozmowy. Konta głównego (Google Workspace albo Microsoft 365) i dostępów zdalnych nie odkłada się na następny dzień, bo to przez nie wchodzi się do reszty systemów. Pozostałe narzędzia domykasz w ciągu tej samej doby, a hasła współdzielone rotujesz w ciągu 24 godzin.

Czy zablokowanie konta wystarczy, żeby odciąć byłego pracownika?

Nie w pełni. Wyłączenie konta blokuje kolejne logowania, ale sesje już otwarte oraz tokeny odświeżania wydane aplikacjom mogą działać dalej. Trzeba wykonać drugą operację: w Google Workspace users.signOut z Admin SDK, w Microsoft 365 revokeSignInSessions w Microsoft Graph. Dopiero blokada razem z unieważnieniem sesji zamyka temat.

Co zrobić z hasłami współdzielonymi po odejściu pracownika?

Zmienić je w ciągu doby i poinformować pozostałe osoby korzystające z danego konta. Docelowo warto ograniczyć liczbę kont współdzielonych do minimum, a resztę przenieść do menedżera haseł dla zespołu, gdzie rotacja jest jedną operacją, a dostęp do sejfu odbiera się razem z kontem pracownika. Konta współdzielone mają też drugą wadę: uniemożliwiają ustalenie, kto wykonał daną operację.

Czy dostęp byłego pracownika do systemów firmowych to naruszenie RODO?

Jeśli w tych systemach są dane osobowe, a upoważnienie do ich przetwarzania wygasło razem z zakończeniem współpracy, to tak: dane są dostępne dla osoby nieupoważnionej, czyli doszło do naruszenia ochrony danych osobowych. Trzeba je ocenić pod kątem ryzyka dla praw i wolności osób, których dane dotyczą, i przy wystąpieniu takiego ryzyka zgłosić organowi nadzorczemu bez zbędnej zwłoki, najpóźniej w ciągu 72 godzin od stwierdzenia.

Czy mała firma potrzebuje systemu klasy IAM do zarządzania dostępami?

Zwykle nie. W firmie do stu osób wystarczy rejestr dostępów, spisana procedura offboardingu i dwie albo trzy automatyzacje: blokada konta głównego, checklista dla narzędzi bez API i kwartalny raport różnic. Dedykowany system tożsamości ma sens dopiero przy dużej liczbie narzędzi z SSO i rotacji pracowników na tyle wysokiej, że ręczna obsługa przestaje nadążać.

Podsumowanie

Offboarding w firmie zbudowanej na SaaS-ach przegrywa się na braku listy, nie na braku narzędzi. Dopóki nie wiadomo, kto ma dostęp do czego, każde odejście pracownika jest ćwiczeniem z pamięci. Rejestr „osoba × narzędzie × poziom", uzupełniany przy nadawaniu dostępu, zdejmuje większość problemu i nie wymaga kupowania niczego.

Reszta to procedura i kilka automatyzacji: konto główne blokowane razem z unieważnieniem sesji, poczta przekierowana, narzędzia bez SSO domknięte według rejestru, hasła zrotowane, klucze i karty odebrane, dane przeniesione. Część kroków wykonasz przez API, część zostanie zadaniami dla ludzi i to jest w porządku, o ile mają właściciela, termin i widoczny status. Osobno, zanim ktokolwiek odejdzie, przenieś integracje z kont osobowych na serwisowe. To ten koszt, który uderza najmocniej i zawsze w najgorszym momencie.

Chcecie sprawdzić, jak Wasz offboarding wygląda dziś naprawdę? Umów bezpłatną konsultację — przejdziemy przez listę narzędzi i powiemy wprost, jeśli wystarczy Wam porządny arkusz i godzina ustaleń, bez żadnego wdrożenia.

Przeczytaj również

• Kto pilnuje twoich automatyzacji? Monitoring, alerty i utrzymanie bez niespodzianek
• n8n a RODO: gdzie trzymać dane firmowych automatyzacji
• Przejęcie automatyzacji po freelancerze albo innej firmie: instrukcja
• Jak bezpiecznie korzystać z AI w organizacji