zantiga

Pracownik odszedł z organizacji. Kiedy traci dostęp do systemów?

W teorii – natychmiast.

W praktyce – bywa różnie.

Odejście pracownika z organizacji to jeden z tych momentów, w których bezpieczeństwo IT zależy nie tylko od technologii, ale przede wszystkim od sprawności procesu. Ktoś z działu IT musi dostać informację od HR. Następnie powinien sprawdzić, do jakich systemów dana osoba miała dostęp, jakie role były jej przypisane, które konta trzeba zablokować, a które uprawnienia odebrać.

Jeśli systemów jest kilka, może się to wydawać proste. Jeśli jest ich kilkanaście lub kilkadziesiąt, a pracownik korzystał z wielu aplikacji, repozytoriów, zasobów, folderów, systemów branżowych i narzędzi administracyjnych – proces zaczyna być dużo bardziej złożony.

W tym czasie były pracownik może nadal mieć dostęp do danych, do których nie powinien mieć dostępu. Nie zawsze wynika to z zaniedbania. Bardzo często wynika z tego, że proces jest ręczny, rozproszony i zależny od wielu osób.

To jedno z najczęstszych ryzyk, jakie widzimy w organizacjach, z którymi pracujemy. I jedno z pierwszych, które warto uporządkować.

Temat offboardingu i odbierania dostępów był również jednym z elementów naszej prezentacji podczas IN.SE.CON.

Dlaczego offboarding jest krytycznym momentem dla bezpieczeństwa IT?

Offboarding, czyli proces zakończenia współpracy z pracownikiem, kontraktorem lub współpracownikiem, jest jednym z najważniejszych elementów zarządzania dostępami IT.

W momencie odejścia z organizacji zmienia się status użytkownika. Osoba, która jeszcze wczoraj potrzebowała dostępu do systemów, danych i aplikacji, dziś nie powinna już z nich korzystać. To oznacza, że organizacja musi szybko i skutecznie odebrać jej uprawnienia.

Problem polega na tym, że dostęp rzadko dotyczy tylko jednego systemu.

Pracownik może mieć konto w poczcie firmowej, systemie kadrowym, systemie finansowym, CRM, ERP, systemie medycznym, repozytorium dokumentów, narzędziu do obsługi zgłoszeń, katalogu Active Directory, aplikacji lokalnej, systemie raportowym albo narzędziu chmurowym.

Część dostępów mogła zostać nadana automatycznie. Część ręcznie. Część mogła wynikać z roli, stanowiska lub działu. Część mogła być dostępem wyjątkowym, czasowym albo odziedziczonym po wcześniejszym projekcie.

Dlatego pytanie nie brzmi tylko:

Czy konto pracownika zostało wyłączone?

Właściwe pytanie brzmi:

Czy wszystkie jego dostępy zostały odebrane, potwierdzone i zapisane w sposób możliwy do wykazania podczas audytu?

To ogromna różnica.

Gdzie najczęściej powstaje ryzyko?

Ryzyko pojawia się zwykle nie w jednym miejscu, ale na styku procesów HR, IT i właścicieli systemów.

Najczęstsze problemy to:

  • opóźniona informacja z HR do IT,
  • brak centralnej listy systemów, do których użytkownik miał dostęp,
  • ręczne odbieranie uprawnień w wielu aplikacjach,
  • brak potwierdzenia, że dostęp faktycznie został odebrany,
  • brak historii działań,
  • konta aktywne mimo zakończenia współpracy,
  • dostępy nadane poza głównym katalogiem użytkowników,
  • konta kontraktorów bez daty końcowej,
  • dostępy czasowe, które nigdy nie wygasły,
  • brak właściciela odpowiedzialnego za potwierdzenie odebrania dostępu.

W praktyce organizacja może sądzić, że pracownik utracił dostęp, ponieważ jego konto zostało zablokowane w jednym głównym systemie. Tymczasem nadal może istnieć dostęp do innych aplikacji, folderów, systemów lokalnych lub usług zewnętrznych.

To właśnie dlatego offboarding powinien być traktowany jako proces zarządzania ryzykiem, a nie wyłącznie jako techniczne zamknięcie konta.

Dlaczego ręczne odbieranie dostępów nie skaluje się w organizacji?

Ręczne odbieranie dostępów może działać w małej organizacji. Wystarczy kilka systemów, niewielka liczba użytkowników i dobra komunikacja między HR a IT. Problem zaczyna się wtedy, gdy organizacja rośnie.

Przy kilkuset użytkownikach i wielu systemach ręczny proces staje się trudny do utrzymania. Dział IT musi każdorazowo sprawdzić, gdzie dana osoba miała dostęp, zalogować się do odpowiednich systemów, odebrać uprawnienia, potwierdzić wykonanie zadania i najlepiej jeszcze zapisać dowód działania.

Jeśli takich zmian jest kilka miesięcznie, proces może być obciążający. Jeśli jest ich kilkanaście lub kilkadziesiąt – staje się źródłem błędów, opóźnień i ryzyka.

Jeśli organizacja nadal prowadzi rejestr dostępów w arkuszu kalkulacyjnym, problem skali i aktualności danych staje się jeszcze większy. Szerzej opisujemy to w artykule: Arkusz Excel dla uprawnień – pytanie o ryzyko, odpowiedzialność i skalę.

Największy problem polega na tym, że ręczny proces wymaga pamięci, dyscypliny i dostępności wielu osób. A bezpieczeństwo nie powinno zależeć od tego, czy ktoś zdążył wysłać maila, odczytać zgłoszenie albo ręcznie zaktualizować arkusz.

W procesie offboardingu liczy się czas, kompletność i dowód wykonania.

Jeśli organizacja nie ma centralnego procesu, trudno jednoznacznie odpowiedzieć na pytania:

  • kiedy dokładnie pracownik utracił dostęp,
  • do jakich systemów miał dostęp w momencie odejścia,
  • które uprawnienia zostały odebrane automatycznie,
  • które wymagały ręcznego działania,
  • kto potwierdził odebranie dostępu,
  • czy wszystkie działania zostały zakończone,
  • czy istnieje raport audytowy.

To są pytania, które mogą pojawić się podczas audytu, kontroli lub analizy incydentu.

Offboarding a NIS2, audyt i odpowiedzialność

Wraz z rosnącym znaczeniem regulacji takich jak NIS2, organizacje muszą coraz poważniej podchodzić do kontroli dostępu, zarządzania ryzykiem i rozliczalności działań.

Odebranie dostępów po zakończeniu współpracy jest jednym z podstawowych elementów bezpieczeństwa. Jeżeli były pracownik, kontraktor lub dostawca nadal ma dostęp do systemów, organizacja może mieć problem nie tylko techniczny, ale również formalny i audytowy.

Audytor może zapytać:

  • czy istnieje formalny proces offboardingu,
  • kto inicjuje odebranie dostępów,
  • jak szybko dostęp jest odbierany,
  • czy proces obejmuje wszystkie systemy,
  • czy działania są rejestrowane,
  • kto potwierdza wykonanie zadań,
  • czy organizacja ma raport pokazujący, kiedy użytkownik utracił dostęp,
  • czy dostęp czasowy wygasa automatycznie,
  • czy konta kontraktorów mają daty końcowe.

Bez systemowego podejścia odpowiedzi na te pytania często wymagają ręcznego sprawdzania maili, zgłoszeń, arkuszy i logów z różnych systemów. To wydłuża audyt i zwiększa ryzyko, że organizacja nie będzie w stanie szybko przedstawić wiarygodnych dowodów.

Dlatego bezpieczny offboarding powinien być nie tylko wykonany, ale też udokumentowany.

Jak powinien wyglądać bezpieczny proces odebrania dostępów?

Bezpieczny proces offboardingu powinien być szybki, kompletny, powtarzalny i możliwy do zweryfikowania.

W praktyce oznacza to, że organizacja powinna wiedzieć:

  • kto kończy współpracę,
  • kiedy kończy współpracę,
  • do jakich systemów ma dostęp,
  • które uprawnienia wynikają z roli,
  • które dostępy są wyjątkowe lub czasowe,
  • kto zatwierdza odebranie dostępu,
  • które działania wykonują się automatycznie,
  • które wymagają ręcznej weryfikacji,
  • czy wszystkie zadania zostały zakończone,
  • gdzie znajduje się historia procesu.

Najlepiej, jeśli proces nie zaczyna się dopiero wtedy, gdy ktoś wyśle wiadomość do IT. Powinien być powiązany z cyklem życia pracownika w organizacji – od zatrudnienia, przez zmianę stanowiska, aż po zakończenie współpracy.

Dzięki temu data zakończenia umowy, decyzja o rozstaniu lub zmiana statusu użytkownika może automatycznie uruchomić proces odebrania dostępów.

To szczególnie ważne w organizacjach, które mają wiele systemów, rotację personelu, kontraktorów, użytkowników tymczasowych lub dostęp do danych wrażliwych.

Jak Zantiga automatyzuje offboarding pracownika?

Z systemem Zantiga proces offboardingu wygląda inaczej niż w tradycyjnym modelu opartym na mailach, zgłoszeniach i ręcznych działaniach.

Zantiga odwzorowuje cykl życia pracownika w organizacji – od momentu zatrudnienia, przez zmiany stanowiska lub zakresu obowiązków, aż po zakończenie współpracy. Dzięki temu odebranie dostępów nie jest pojedynczym zadaniem technicznym, ale częścią kontrolowanego procesu zarządzania tożsamością i uprawnieniami.

Kiedy zapada decyzja o zakończeniu współpracy lub wynika ona z wprowadzonych dat granicznych dla umowy, system automatycznie generuje wnioski o odebranie uprawnień do wszystkich systemów powiązanych z danym pracownikiem.

Dzięki temu organizacja nie musi każdorazowo zaczynać od pytania: „gdzie ta osoba miała dostęp?”. System wie, jakie uprawnienia były przypisane do użytkownika i jakie działania powinny zostać wykonane.

Zantiga wspiera m.in.:

  • automatyczne uruchomienie procesu offboardingu,
  • identyfikację systemów powiązanych z użytkownikiem,
  • generowanie wniosków o odebranie dostępów,
  • automatyczne lub półautomatyczne wykonanie działań,
  • raportowanie wyników,
  • zapis historii w rejestrze,
  • ścieżkę audytową dla HR, IT i compliance.

Więcej o roli automatyzacji w zarządzaniu uprawnieniami piszemy w artykule: Automatyzacja w zarządzaniu uprawnieniami.

To pozwala ograniczyć ryzyko, że jakiś dostęp zostanie pominięty, wykonany z opóźnieniem albo nieudokumentowany.

Technik AI, tryb hybrydowy i tryb nadzorowany

Dalej pracę może przejąć Technik AI – mechanizm automatyzacji wbudowany w Zantigę.

Technik AI łączy się z systemami docelowymi, odbiera uprawnienia, raportuje wyniki i zapisuje je w rejestrze. Dzięki temu działania, które wcześniej wymagały ręcznego logowania się do wielu systemów, mogą zostać wykonane szybciej i w sposób powtarzalny.

Co ważne, organizacja sama decyduje, które systemy obsługuje automatyzacja, a które wymagają nadzoru człowieka. Nie każdy proces musi od razu działać w pełni automatycznie.

Zantiga umożliwia elastyczne podejście:

  • tryb automatyczny – Technik AI wykonuje działania samodzielnie zgodnie z ustalonym procesem,
  • tryb hybrydowy – automatyczne przetwarzanie jest połączone z obowiązkową ręczną weryfikacją wyników,
  • tryb nadzorowany – zespół może obserwować działanie Technika AI w czasie rzeczywistym i ręcznie potwierdzać rezultat.

To szczególnie ważne w organizacjach, które chcą wdrażać automatyzację stopniowo. Nie trzeba od razu przekazywać całego procesu systemowi. Można zacząć od wybranych aplikacji, wybranych grup użytkowników albo wybranych etapów offboardingu.

Dzięki temu automatyzacja jest dopasowana do gotowości organizacji, poziomu zaufania, krytyczności systemów i wymagań bezpieczeństwa.

Minuty zamiast godzin lub dni

W tradycyjnym modelu odebranie dostępów może trwać godziny, a czasem dni. Wszystko zależy od tego, jak szybko HR przekaże informację, jak szybko IT sprawdzi listę systemów, czy właściciele aplikacji potwierdzą działania i czy nie pojawią się wyjątki.

W modelu opartym na Zantiga proces może zostać uruchomiony automatycznie, a wiele działań może wykonać się w ciągu minut.

Najważniejsze korzyści to:

  • szybsze odebranie dostępów,
  • mniejsze ryzyko błędów ręcznych,
  • pełniejsza kontrola nad procesem,
  • mniejsze obciążenie działu IT,
  • lepsza współpraca HR i IT,
  • jasna historia działań,
  • gotowość audytowa,
  • możliwość stopniowego wdrażania automatyzacji.

Czas realizacji ma znaczenie, ale równie ważna jest kompletność. Nie chodzi tylko o to, żeby zablokować jedno konto. Chodzi o to, żeby organizacja miała pewność, że wszystkie powiązane dostępy zostały obsłużone zgodnie z procesem.

Podsumowanie: offboarding nie musi być źródłem ryzyka

Pracownik powinien tracić dostęp do systemów natychmiast po zakończeniu współpracy – albo zgodnie z wcześniej określoną datą i procesem. W praktyce jednak wiele organizacji nadal opiera się na ręcznej komunikacji, mailach, zgłoszeniach i działaniach wykonywanych osobno w każdym systemie.

Takie podejście może działać przy małej skali. Przy większej liczbie użytkowników, systemów i zmian staje się źródłem ryzyka.

Offboarding nie musi jednak oznaczać chaosu. Może być procesem kontrolowanym, powtarzalnym i bezpiecznym.

Zantiga pomaga organizacjom uporządkować odebranie dostępów po zakończeniu współpracy, skrócić czas realizacji, ograniczyć błędy i zachować pełną ścieżkę audytową.

Jeśli chcesz sprawdzić, jak wygląda automatyczny offboarding w praktyce, umów prezentację Zantiga.

FAQ

Kiedy pracownik powinien stracić dostęp do systemów?

Pracownik powinien stracić dostęp do systemów natychmiast po zakończeniu współpracy albo zgodnie z wcześniej określoną datą końcową. Ważne jest, aby proces obejmował wszystkie systemy i był udokumentowany.

Dlaczego ręczny offboarding jest ryzykowny?

Ręczny offboarding jest ryzykowny, ponieważ zależy od komunikacji między HR, IT i właścicielami systemów. Łatwo pominąć aplikację, konto, dostęp czasowy lub uprawnienie nadane poza głównym katalogiem użytkowników.

Czym jest offboarding IT?

Offboarding IT to proces odebrania użytkownikowi dostępów do systemów, aplikacji, danych i zasobów po zakończeniu współpracy lub zmianie statusu w organizacji.

Jak automatyzacja pomaga w odbieraniu dostępów?

Automatyzacja pozwala uruchamiać proces odebrania dostępów na podstawie statusu pracownika lub daty zakończenia umowy. System może generować wnioski, wykonywać działania w systemach docelowych, raportować wyniki i zapisywać historię procesu.

Czy offboarding jest ważny dla audytu?

Tak. Podczas audytu organizacja może zostać poproszona o wykazanie, kiedy użytkownik utracił dostęp, kto zatwierdził działania i czy proces objął wszystkie systemy. Dlatego ważna jest pełna ścieżka audytowa.

Chcesz mieć pewność, że były pracownik nie ma już dostępu do systemów?

Umów prezentację Zantiga i zobacz, jak automatyzować offboarding oraz odbieranie uprawnień.

Przewijanie do góry