Najgroźniejsze konto w firmowej sieci często nie wygląda podejrzanie. Ma zwyczajne imię i nazwisko, firmowy adres e-mail, dostęp do Teamsa, dysku, CRM-u i VPN-u. Problem w tym, że jego właściciel od czterech miesięcy pracuje już u konkurencji.
To właśnie takie przypadki powinien wykrywać audyt uprawnień użytkowników. Nie chodzi przy tym o wygenerowanie z Active Directory czy Microsoft Entra ID listy kilkuset kont i podpisanie jej przez administratora. Dobry audyt odpowiada na znacznie trudniejsze pytania: kto rzeczywiście korzysta z konta, czy nadal powinien je mieć, do jakich danych może dotrzeć, kto zatwierdził ten dostęp i czy zakres uprawnień odpowiada aktualnym obowiązkom tej osoby.
Najwyższy priorytet mają trzy problemy: aktywne konta byłych pracowników, konta bez jednoznacznego właściciela oraz użytkownicy posiadający większe uprawnienia, niż wymaga ich obecna praca. Dopiero po ich uporządkowaniu ma sens zajmowanie się mniej istotnymi odstępstwami.
Najpierw porównaj ludzi z kontami, zamiast ręcznie przeglądać setki użytkowników
Punktem wyjścia nie powinien być system IT, lecz aktualna lista zatrudnionych i współpracowników. Dopiero ją porównuje się z kontami istniejącymi w Microsoft Entra ID, lokalnym Active Directory, Google Workspace oraz aplikacjach działających poza centralnym katalogiem.
W praktyce potrzebne są przynajmniej cztery zestawy danych:
- lista aktywnych pracowników i współpracowników wraz z datami rozpoczęcia i zakończenia współpracy,
- lista wszystkich aktywnych i zablokowanych kont użytkowników,
- lista kont z dostępem administracyjnym lub uprzywilejowanym,
- lista kont zewnętrznych, technicznych, serwisowych i współdzielonych.
Najlepiej łączyć dane za pomocą identyfikatora pracownika, a dopiero w drugiej kolejności adresu e-mail lub nazwy użytkownika. Samo imię i nazwisko jest kiepskim kluczem: zmieniają się nazwiska, występują duplikaty, a stare konta bywają pozostawiane pod innymi aliasami.
Pierwszy filtr powinien być brutalnie prosty: osoba nie jest już zatrudniona, a konto pozostaje aktywne. Taki przypadek nie trafia do kolejki „do sprawdzenia kiedyś”. Powinien zostać potraktowany jako incydent wymagający natychmiastowej weryfikacji.
Samo wyłączenie konta to przy tym tylko część pracy. Przy zakończeniu współpracy zwykle trzeba również:
- unieważnić aktywne sesje i tokeny,
- odebrać dostęp przez VPN,
- usunąć członkostwo w grupach dających dostęp do aplikacji i danych,
- sprawdzić klucze API, tokeny osobiste i certyfikaty przypisane użytkownikowi,
- odebrać dostęp do repozytoriów GitHub, GitLab lub Bitbucket,
- sprawdzić zewnętrzne platformy, które nie korzystają z firmowego SSO,
- zabezpieczyć skrzynkę pocztową i dokumenty zgodnie z polityką retencji,
- odebrać dostęp do systemów administracji publicznej, bankowości, księgowości czy platform kadrowo-płacowych, jeżeli pracownik taki dostęp posiadał.
Ten ostatni punkt bywa pomijany. Konto zablokowane w Microsoft 365 nie oznacza automatycznie odebrania dostępu do każdego serwisu używanego przez firmę.
Dlatego offboarding nie może kończyć się na Active Directory.
W polskich firmach szczególnej kontroli wymagają między innymi dostępy do systemów kadrowo-płacowych, bankowości elektronicznej, PUE/eZUS, systemów księgowych, CRM, paneli hostingowych, domen, chmur publicznych oraz kont reklamowych Google i Meta. Część z tych usług może funkcjonować niezależnie od centralnego katalogu tożsamości.
Nie należy natomiast automatycznie usuwać konta wraz z odejściem pracownika. Najpierw powinno zostać zablokowane, a następnie trzeba ustalić, które dane należy zachować z powodów prawnych, księgowych, dowodowych lub operacyjnych.
Ma to znaczenie szczególnie przy dokumentacji pracowniczej. Dla stosunku pracy nawiązanego od 1 stycznia 2019 r. okres przechowywania dokumentacji pracowniczej wynosi co do zasady 10 lat od końca roku kalendarzowego, w którym stosunek pracy ustał. W przypadku wcześniejszych okresów zatrudnienia mogą obowiązywać reguły 10- lub 50-letnie.
Nie oznacza to jednak, że przez dziesięć lat należy utrzymywać aktywną skrzynkę i konto użytkownika. Przechowywanie dokumentów i utrzymywanie dostępu to dwie różne rzeczy. Dane można zachować w kontrolowanym archiwum, jednocześnie całkowicie odbierając byłemu pracownikowi możliwość logowania.
Druga grupa to konta osierocone. Typowy przypadek wygląda tak: w katalogu istnieje konto „marketing2”, „biuro”, „recepcja”, „crm-admin” albo użytkownik założony kilka lat temu dla zewnętrznego konsultanta. Nikt nie potrafi już wskazać jego właściciela.
Takie konto powinno mieć przypisaną osobę odpowiedzialną i uzasadniony cel. Jeżeli w ciągu krótkiego terminu operacyjnego — na przykład jednego dnia roboczego — nie da się ustalić właściciela aktywnego konta, rozsądniej jest je czasowo zablokować i obserwować skutki, niż pozostawić bez kontroli tylko dlatego, że „ktoś może go potrzebować”.
Inaczej traktuje się konta techniczne i serwisowe. Brak interaktywnego logowania przez 90 dni nie oznacza, że są zbędne. Mogą obsługiwać integrację ERP, kopie zapasowe, automatyczne raporty albo synchronizację danych. Dla nich trzeba sprawdzić nie aktywność człowieka, lecz właściciela biznesowego, uruchamiane procesy, wykorzystywane poświadczenia oraz to, czy konto rzeczywiście potrzebuje wszystkich przyznanych praw.
W przypadku zwykłych użytkowników 90 dni bez aktywności jest dobrym progiem uruchamiającym kontrolę. Nie jest jednak automatycznym terminem usunięcia. Microsoft wskazuje przedział około 90–180 dni jako rozsądny punkt odniesienia przy poszukiwaniu kont nieaktywnych. Pracownik może przecież przebywać na długim urlopie, urlopie rodzicielskim albo korzystać z systemu jedynie kilka razy w roku.
Zasada powinna więc brzmieć: 90 dni bez logowania oznacza „sprawdź”, a nie „usuń”.
Zbyt szerokiego dostępu nie zobaczysz, patrząc wyłącznie na rolę użytkownika
Drugi etap jest trudniejszy, bo konto może być całkowicie legalne, aktywne i należeć do właściwej osoby, a mimo to tworzyć poważne ryzyko.
Najczęstszy powód to narastanie uprawnień wraz ze zmianami stanowiska.
Pracownik zaczyna w sprzedaży i otrzymuje CRM. Po dwóch latach przechodzi do controllingu, więc dostaje dostęp do systemu finansowego. Później zostaje kierownikiem i dochodzą raporty zarządcze oraz foldery menedżerskie. Starych uprawnień nikt nie usuwa. Po pięciu latach użytkownik ma dostęp do danych z trzech różnych funkcji organizacji, choć do codziennej pracy potrzebuje tylko części z nich.
Dlatego audyt powinien analizować uprawnienia efektywne, a nie wyłącznie role widoczne bezpośrednio przy koncie.
Trzeba sprawdzić:
użytkownik → grupy → grupy zagnieżdżone → aplikacje → role → zasoby → dane.
To różnica fundamentalna. Użytkownik może nie mieć bezpośrednio przypisanej roli administratora aplikacji, ale uzyskać ją przez członkostwo w grupie. Podobnie pracownik może nie mieć formalnego dostępu do folderu, lecz otrzymywać go przez zespół Microsoft Teams, grupę SharePoint, dysk współdzielony albo link udostępniony wcześniej przez innego użytkownika.
Audyt powinien wychwycić przede wszystkim:
- Global Administrator, Super Admin i równoważne role administracyjne nadane osobom, które ich nie potrzebują,
- lokalnych administratorów pozostawionych na stacjach roboczych,
- dostęp administracyjny nadany na stałe zamiast czasowo,
- użytkowników posiadających jednocześnie uprawnienia operacyjne i kontrolne,
- stare członkostwa w grupach wynikające z poprzedniego stanowiska,
- bezterminowy dostęp zewnętrznych konsultantów,
- konta gości bez aktywnego sponsora po stronie firmy,
- publiczne i anonimowe udostępnienia plików,
- dostęp do całych baz lub katalogów danych tam, gdzie wystarczyłby pojedynczy zakres,
- współdzielone hasła i konta, dla których nie można ustalić konkretnego użytkownika.
Szczególnie ostrożnie trzeba traktować systemy finansowe i kadrowe.
Osoba tworząca kontrahenta nie powinna automatycznie móc samodzielnie zatwierdzić jego rachunku bankowego, wprowadzić faktury i autoryzować płatności. Podobnie pracownik HR obsługujący część procesów kadrowych nie zawsze potrzebuje dostępu do pełnych danych płacowych całej organizacji.
To separacja obowiązków, a nie kosmetyka w tabeli uprawnień.
Dobrym testem dla każdego dostępu jest jedno pytanie: *co konkretnie użytkownik nie będzie mógł zrobić w swojej obecnej pracy, jeśli odbierzemy mu to uprawnienie?*
Jeśli właściciel biznesowy odpowiada „nie wiem, ale zawsze je miał”, uprawnienie nie ma wystarczającego uzasadnienia.
Dostęp uprzywilejowany powinien mieć dodatkowo właściciela, uzasadnienie i termin ponownej weryfikacji. Jeżeli infrastruktura na to pozwala, lepiej przydzielać wysokie uprawnienia czasowo, na przykład poprzez mechanizmy typu Privileged Identity Management, niż utrzymywać je stale.
Nie ma jednego ustawowego interwału audytu odpowiedniego dla każdej firmy. Sensownie jest ustalić częstotliwość według ryzyka:
- zakończenia współpracy — obsługa natychmiastowa, a nie podczas kwartalnego audytu,
- role administracyjne i dostęp do danych wysokiego ryzyka — kontrola co miesiąc lub co kwartał,
- konta gościnne i zewnętrzne — zwykle co kwartał,
- pełna recertyfikacja zwykłych dostępów — najczęściej co 3–6 miesięcy,
- konta nieaktywne — automatyczny raport przynajmniej raz w miesiącu.
W firmie zatrudniającej kilkanaście osób ręczna kontrola może jeszcze działać. Przy kilkuset kontach arkusz Excel zaczyna być problemem samym w sobie: szybko się dezaktualizuje, trudno odtworzyć historię decyzji, a menedżerowie często zatwierdzają całe kolumny bez sprawdzania poszczególnych uprawnień.
Audyt musi kończyć się odebraniem dostępu, a nie podpisaniem arkusza
RODO nie narzuca jednej konkretnej aplikacji do zarządzania uprawnieniami ani uniwersalnego terminu recertyfikacji. Wymaga natomiast m.in. minimalizacji danych, ograniczenia ich dostępności do zakresu niezbędnego oraz stosowania zabezpieczeń odpowiadających ryzyku. Art. 32 RODO wskazuje również na potrzebę regularnego testowania i oceniania skuteczności środków technicznych i organizacyjnych.
W praktyce oznacza to, że firma powinna potrafić pokazać nie tylko listę kont, ale również proces podejmowania decyzji.
Minimalny zapis z audytu powinien zawierać:
- identyfikator użytkownika,
- jego status zatrudnienia lub współpracy,
- właściciela biznesowego,
- system i konkretny zakres dostępu,
- sposób nadania uprawnienia,
- datę ostatniego użycia, jeżeli można ją wiarygodnie ustalić,
- decyzję: pozostawić, ograniczyć, zablokować albo usunąć,
- osobę zatwierdzającą decyzję,
- uzasadnienie,
- termin wykonania zmiany,
- potwierdzenie jej wykonania.
Samo pole „zaakceptowane przez kierownika” jest za słabe, jeżeli nie wiadomo, co dokładnie kierownik zaakceptował.
Ważna jest też jakość danych o aktywności. Administratorzy często przyjmują, że skoro w panelu nie widać logowania użytkownika od kilku miesięcy, konto nie było używane. To nie zawsze prawda.
W Microsoft Entra ID standardowa retencja części logów jest stosunkowo krótka. Dla logów logowania i audytu wynosi obecnie 7 dni w Microsoft Entra ID Free oraz 30 dni dla licencji P1 i P2. Jeśli organizacja chce analizować dłuższą historię, powinna odpowiednio wcześniej eksportować dane do przeznaczonego do tego magazynu lub systemu analitycznego. Brak starszego wpisu w panelu nie jest dowodem, że użytkownik się nie logował.
Najwięcej problemów sprawiają jednak aplikacje poza centralnym systemem zarządzania tożsamością. Firma może mieć świetnie uporządkowany Microsoft 365, a jednocześnie byłego pracownika nadal aktywnego w HubSpot, GitHubie, panelu hostingu albo firmowym koncie reklamowym.
Dlatego przy większej organizacji opłaca się doprowadzić do sytuacji, w której HR jest źródłem informacji o cyklu życia człowieka, system tożsamości steruje kontem, a aplikacje korzystają z centralnego SSO i automatycznego provisioningu/deprovisioningu.
Najprostszy docelowy scenariusz wygląda tak:
- HR rejestruje zakończenie współpracy wraz z dokładną datą i godziną.
- System tożsamości otrzymuje tę informację automatycznie.
- Konto zostaje wyłączone w określonym momencie.
- Aktywne sesje zostają unieważnione.
- Dostępy do aplikacji są wycofywane.
- Zespół IT otrzymuje listę wyjątków wymagających ręcznego działania.
- Skrzynka i dokumenty trafiają do odpowiedniego procesu retencji.
- Właściciele systemów potwierdzają wykonanie operacji wymagających ręcznej kontroli.
Najbardziej irytującym elementem takiego projektu jest zwykle nie technologia, lecz jakość danych organizacyjnych. Jeżeli dział HR nie aktualizuje na czas dat rozwiązania umów, menedżerowie nie zgłaszają zmian stanowisk, a konta techniczne nie mają właścicieli, nawet drogie narzędzie klasy Identity Governance będzie automatyzowało bałagan.
Najpierw trzeba więc ustalić jedno źródło prawdy o zatrudnieniu, właściciela każdego systemu i właściciela każdego wyjątku. Automatyzację warto wdrażać dopiero na tej podstawie.
FAQ – najczęstsze pytania o audyt uprawnień
Czy konto byłego pracownika trzeba od razu usunąć?
Nie. W pierwszej kolejności należy je zablokować, unieważnić sesje i odebrać dostęp do systemów. Usunięcie powinno nastąpić dopiero po sprawdzeniu wymogów dotyczących retencji poczty, dokumentów, postępowań, księgowości i innych danych biznesowych. Zachowanie danych nie wymaga zachowania aktywnego dostępu.
Czy 90 dni bez logowania oznacza, że konto można skasować?
Nie. To dobry próg do rozpoczęcia weryfikacji, ale konto może należeć do osoby na długim urlopie albo być używane tylko okresowo. Konta techniczne trzeba oceniać według działania usług i integracji, a nie typowej aktywności człowieka.
Kto powinien zatwierdzać pozostawienie uprawnień – dział IT czy przełożony?
Właściciel biznesowy zasobu lub danych. IT powinno dostarczyć informacje o faktycznych uprawnieniach i wykonać zmianę, ale administrator nie zawsze wie, czy specjalista księgowości rzeczywiście potrzebuje dostępu do konkretnego modułu ERP. W przypadku uprawnień administracyjnych potrzebna jest dodatkowo kontrola bezpieczeństwa.
Jak często wykonywać audyt uprawnień?
Nie należy czekać na jeden coroczny przegląd. Offboarding powinien działać na bieżąco, konta administracyjne warto sprawdzać co miesiąc lub kwartał, a całościową recertyfikację dostępów przeprowadzać zwykle co 3–6 miesięcy. Im bardziej wrażliwe dane i większa rotacja pracowników, tym krótszy powinien być cykl.
Czy audyt powinien obejmować konta gości i firmy zewnętrzne?
Tak. W praktyce są one jedną z częściej zaniedbywanych grup. Każdy gość powinien mieć aktualnego sponsora wewnątrz organizacji, określony cel dostępu i moment ponownej weryfikacji. Zakończenie projektu powinno powodować odebranie dostępu, a nie pozostawienie konta „na wypadek kolejnej współpracy”.
Od czego zacząć, jeśli firma nigdy nie robiła takiego audytu?
Nie zaczynaj od przebudowy wszystkich ról ani zakupu systemu Identity Governance. Najpierw wyeksportuj listę aktywnych kont i zestaw ją z aktualną listą pracowników oraz współpracowników. Pierwszego dnia usuń najgroźniejszy błąd: aktywne konta osób, których współpraca już się zakończyła. Następnie sprawdź konta bez właściciela i użytkowników z uprawnieniami administracyjnymi. Dopiero kiedy te trzy grupy są pod kontrolą, przechodź do pełnej recertyfikacji pozostałych dostępów.
Więcej informacji na: https://hd-biznes.com/blog
