Cykl joiner-mover-leaver: jak zapewnić właściwy dostęp na każdym etapie
Joiner-mover-leaver, czyli JML, to droga, jaką przechodzi dostęp przez czas, jaki dana osoba spędza w firmie. Dołącza i dostaje dostęp. Zmienia rolę i jej dostęp powinien się zmienić razem z nią. Odchodzi i cały dostęp powinien zniknąć.
Większość zespołów radzi sobie nieźle z etapem joiner, bo onboarding jest widoczny i ktoś go pilnuje: nowa osoba nie może pracować bez dostępu, więc to się dzieje. Etapy mover i leaver to miejsca, gdzie proces się psuje, bo nic nie przestaje działać, kiedy się je pominie. Zmiana roli, która dodaje nowy dostęp bez usunięcia starego, wciąż pozwala danej osobie wykonywać swoją pracę. Osoba odchodząca, której aplikacje zostają otwarte, wciąż wygląda dobrze od wewnątrz. Te awarie są niewidoczne, dopóki nie wydobędzie ich audyt, incydent albo przegląd.
Traktowanie JML jako jednego cyklu życia, a nie trzech osobnych zadań pilnowanych przez różne osoby, to właśnie to, co utrzymuje zgodność dostępu z rzeczywistością w czasie. To kręgosłup least privilege i kontrola, na której opiera się każdy framework.
- Dostęp ma cykl życia: nadawany na etapie joiner, zmieniany na etapie mover, usuwany na etapie leaver. Te trzy etapy działają tylko jako jeden system.
- Większość zespołów radzi sobie nieźle z etapem joiner, bo onboarding jest widoczny i ma właściciela. Etapy mover i leaver psują się, bo nic nie przestaje działać, kiedy się je pominie.
- Etap mover to silnik privilege creep: prawie każdy dodaje dostęp nowej roli, prawie nikt nie usuwa dostępu starej roli. Napraw mover jako pierwszy.
- Około 40% odchodzących pracowników zachowuje dostęp do przynajmniej jednej aplikacji biznesowej przy ręcznym offboardingu, a 65% procesów ręcznego offboardingu całkowicie pomija shadow SaaS (Reco, 2025-2026).
- Konta serwisowe, klucze API i integracje w ogóle nie mają procesu joiner-mover-leaver, a często mają najszerszy dostęp w środowisku. Nadaj każdemu z nich właściciela i przeglądaj je regularnie.
- JML działa, kiedy jest systemem: HR jest wyzwalaczem, provisioning jest zautomatyzowany tam, gdzie to możliwe przez SSO i SCIM, luki mają ręcznych właścicieli, a cykliczne przeglądy dostępów wyłapują to, co umyka procesowi.
joiner: nadawaj dostęp według roli, nie „wszystko, co dostał ostatni nowy pracownik”
Dobry onboarding daje ludziom to, czego potrzebują od pierwszego dnia, bez nadawania im więcej, niż wymaga ich rola. Częstym antywzorcem jest klonowanie: nowy pracownik dostaje dostęp przez skopiowanie dostępu podobnego kolegi. To szybkie i właśnie w ten sposób privilege creep zostaje zasiane od pierwszego dnia, bo dostęp kolegi już zawiera lata nagromadzonych dodatków.
Jak wygląda to zrobione dobrze:
- Dostęp oparty na roli. Zdefiniuj, czego potrzebuje każda rola, i nadawaj dostęp według roli, a nie według czyjejś pamięci ostatniej konfiguracji. Nie potrzebujesz idealnego modelu ról, żeby zacząć; nawet zgrubne szablony ról biją klonowanie.
- Ścieżka wniosku i zatwierdzenia z zapisem. Dostęp jest nadawany przez coś, co zostawia ślad, żebyś mógł później udowodnić, kto co zatwierdził. To dowód, który sprawdzają audytorzy.
- Birthright kontra na wniosek. Oddziel dostęp, który każdy w danej roli dostaje automatycznie, od dostępu wymagającego konkretnego wniosku i uzasadnienia. Trzymaj automatyczny zestaw minimalnym.
mover: etap, który tworzy większość bałaganu
Kiedy ktoś zmienia rolę, powinny zajść dwie rzeczy: dostaje dostęp potrzebny nowej roli i traci dostęp potrzebny starej roli. Prawie każdy robi to pierwsze. Prawie nikt nie robi tego drugiego.
Ta jedna luka to silnik privilege creep. Po kilku zmianach osoba gromadzi sumę dostępu ze wszystkich ról, jakie kiedykolwiek pełniła. Analityk finansowy, który kiedyś zajmował się zakupami, wciąż ma dostęp do zakupów. Inżynier, który miał epizod na dyżurach, wciąż ma uprawnienia produkcyjne. Nic z tego nie jest złośliwe i wszystko z tego jest ryzykiem.
Jak wygląda to zrobione dobrze:
- Zmiana roli wyzwala przegląd dostępów, nie tylko dodanie dostępu. Pytanie brzmi zawsze „czego już nie powinien mieć”, nie tylko „czego teraz potrzebuje”.
- Zdarzenie mover ma właściciela. Ktoś, zwykle z HR jako wyzwalaczem, odpowiada za stronę usuwania, tak samo jak ktoś odpowiada za joiner.
- Wrażliwe przejścia dostają dodatkową kontrolę. Przejścia do albo z ról uprzywilejowanych, albo między zespołami z różnym dostępem do danych, zasługują na bliższe przyjrzenie się.
Jeśli masz naprawić jedną rzecz w całym procesie JML, napraw mover. To najtańsze miejsce, żeby zatrzymać creep, zanim się zacznie.
leaver: zamknij każde drzwi, nie tylko katalog
Kiedy ktoś odchodzi, konto katalogowe zostaje niezawodnie wyłączone, bo IT je pilnuje. Awaria dotyczy wszystkiego poniżej: aplikacji SaaS z bezpośrednim logowaniem, grantów OAuth, tokenów API, haseł do kont współdzielonych, które ta osoba znała, kont serwisowych, które posiadała.
Kluczowe liczby są wymowne: większość byłych pracowników zachowuje dostęp do przynajmniej jednej firmowej aplikacji po odejściu, około 40% odchodzących pracowników zachowuje dostęp do przynajmniej jednej aplikacji biznesowej przy ręcznym offboardingu, a 65% procesów ręcznego offboardingu całkowicie pomija shadow SaaS (Reco, 2025-2026). Katalog się zamyka, aplikacje poza nim zostają otwarte. Zasada: offboarding musi obejmować każdy system, do którego dana osoba mogła sięgnąć, nie tylko ten, który IT kontroluje bezpośrednio. Pełny zakres i kolejność deprovisioningu to osobne zadanie samo w sobie, a etap leaver jest tu celowo skrócony, bo to największy z trzech etapów.
cykl życia tożsamości maszynowych, którego nikt nie prowadzi
Ludzki JML ma przynajmniej HR jako wyzwalacz. Konta serwisowe, klucze API i integracje w ogóle nie mają procesu joiner-mover-leaver. Powstają, kiedy potrzebuje ich projekt, i trwają, dopóki ktoś nie zauważy. Nie ma zdarzenia leaver, kiedy usługa, której służyły, zostaje wycofana, i nie ma przeglądu, kiedy klucz nie był używany od miesięcy.
Świadomie włącz tożsamości maszynowe (NHI) do cyklu życia: nadaj każdej z nich właściciela, zapisz, dlaczego istnieje, i przeglądaj je regularnie, bo często mają najszerszy dostęp w środowisku i nie odpowiadają przed żadnym systemem HR.
jak uczynić to powtarzalnym
JML działa, kiedy jest systemem, nie zestawem dobrych intencji:
- HR jest wyzwalaczem. Zdarzenia joiner, mover i leaver powinny startować z systemu ewidencji ludzi, żeby dostęp zmieniał się razem ze statusem zatrudnienia.
- Provisioning jest zautomatyzowany tam, gdzie to możliwe. Podłączenie aplikacji do dostawcy tożsamości przez single sign-on i SCIM oznacza, że dostęp automatycznie podąża za katalogiem, co zmniejsza ręczny zakres dla wszystkich trzech etapów.
- Luki mają ręcznych właścicieli. Aplikacje poza single sign-on i tożsamości maszynowe potrzebują imiennego właściciela i checklisty, bo automatyzacja do nich nie dotrze.
- Przeglądy wyłapują to, co umyka procesowi. Cykliczne przeglądy dostępów to siatka bezpieczeństwa dla wszystkiego, co przecieka przez JML.
let's start with a conversation
Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.
Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.
We'll take it from there
+48 783 762 997
julian@unshadowit.com
