Jak przeprowadzić przegląd dostępów użytkowników: proces, rytm i dowody

czym jest przegląd dostępów użytkowników

Przegląd dostępów użytkowników to proces ograniczony w czasie, w którym osoby odpowiedzialne za system albo zbiór danych potwierdzają, że każde konto z dostępem do niego wciąż powinno go mieć. Dla każdego konta objętego zakresem recenzent podejmuje jedną z trzech decyzji: potwierdź, zmodyfikuj albo odbierz.

Przegląd nie jest jednorazowym ćwiczeniem. Działa w zdefiniowanym cyklu. Produkuje pisemny zapis. I obejmuje krok dociągnięcia do końca, w którym decyzje o odebraniu dostępu są faktycznie wykonywane w zdefiniowanym oknie czasowym.

To coś innego niż proces joiner-mover-leaver (JML), który obsługuje zmiany dostępu wywołane konkretnymi zdarzeniami, takimi jak zatrudnienie, zmiana roli albo odejście. Przegląd obejmuje dostęp, który proces JML mógł pominąć, oraz dostęp, który dryfował w czasie bez żadnego wywołującego zdarzenia. Te dwa procesy się uzupełniają. Żaden nie zastępuje drugiego.

dlaczego bez przeglądów uprawnienia tylko przyrastają

Dostęp jest niemal zawsze nadawany w odpowiedzi na prośbę. Ktoś potrzebuje dostępu do systemu. Prosi o niego. IT go nadaje. To zdarzenie jest zwykle logowane, a prośba zostaje zamknięta.

Usuwanie nie działa tak samo. Nie powstaje żadna równoważna prośba, kiedy powód dostępu przestaje istnieć. Analityk, który przeszedł do innego zespołu, wciąż ma dostęp do bazy danych, o który poprosił osiem miesięcy temu. Kontraktor, którego projekt skończył się w pierwszym kwartale, wciąż pojawia się w narzędziu do zarządzania projektami. Developer z tymczasowymi uprawnieniami admina do migracji wciąż je ma.

83% pracowników przyznaje, że wciąż ma dostęp do przynajmniej jednego konta u poprzedniego pracodawcy (Beyond Identity, 2022, self-reported). Ta liczba obejmuje najbardziej oczywisty przypadek. Dryf wewnątrz zestawów uprawnień aktywnych pracowników jest trudniejszy do zmierzenia i w większości środowisk nigdy nie jest mierzony.

Strukturalny problem polega na tym, że usunięcie dostępu wymaga, żeby ktoś wiedział, że powinien zostać usunięty. Zmiana roli to jedno z głównych źródeł. Ktoś przechodzi między zespołami, dostaje dostęp wymagany przez nową rolę i zatrzymuje wszystko z poprzedniej. Po dwóch albo trzech zmianach roli luka między tym, co ktoś ma, a tym, czego potrzebuje, jest znacząca. Przeglądy dostępów to mechanizm, który zamyka tę pętlę. Tworzą ustrukturyzowany moment dla osób, które faktycznie wiedzą, kto powinien mieć dostęp, żeby zastosowały tę wiedzę.

co przeglądać

Nie każdy system potrzebuje tej samej częstotliwości przeglądu, ale każdy system, który przechowuje wrażliwe dane, daje uprawnienia admina albo dotyka regulowanych procesów, musi być objęty zakresem.

Standardowe konta użytkowników. Pełna lista pracowników i kontraktorów z dostępem do każdego systemu. Przegląd skupia się na tym, czy poziom dostępu jest odpowiedni dla obecnej roli danej osoby, i czy ta osoba wciąż pełni rolę, która w ogóle uzasadnia dostęp.

Konta uprzywilejowane i admina. Uprawnienia admina do infrastruktury, konsol chmurowych, dostawców tożsamości i aplikacji SaaS. Niosą najwyższe ryzyko w razie kompromitacji. Powinny być przeglądane częściej niż konta standardowe, a grono recenzentów powinno obejmować starszych przedstawicieli IT albo bezpieczeństwa.

Konta serwisowe i tożsamości maszynowe (NHI). Konta techniczne używane przez aplikacje, skrypty i integracje. Są konsekwentnie niedoreprezentowane w przeglądach dostępów. Często mają szeroki dostęp nadany przy konfiguracji, rzadko mają wskazanego właściciela i nie pojawiają się w standardowych przeglądach prowadzonych przez HR, bo nie są powiązane z konkretną osobą. Bez osobnej inwentaryzacji i procesu przeglądu dla kont serwisowych, gromadzą się bez końca.

Użytkownicy zewnętrzni i kontraktorzy. Konta dostawców, loginy konsultantów, portale partnerskie. Są szczególnie podatne na to, żeby przeżyć swój zamierzony okres. Przegląd powinien potwierdzić, że współpraca jest wciąż aktywna i że poziom dostępu pasuje do obecnego zakresu prac.

Dostęp do aplikacji SaaS. Każda aplikacja SaaS ma własną listę użytkowników, własny model ról i własny panel admina. Centralny katalog obsługuje deprovisioning tylko dla aplikacji połączonych przez SCIM albo zarządzany offboarding. Aplikacje spoza tego zakresu trwają niezależnie. Kompletny przegląd dostępów obejmuje SaaS, nie tylko katalog.

Konta współdzielone i generyczne. Dane logowania współdzielone między wieloma osobami. Powinny być oznaczone do likwidacji, nie tylko przeglądane, bo uniemożliwiają zarówno przypisanie odpowiedzialności, jak i odebranie dostępu.

kto jest właścicielem przeglądu

IT nie prowadzi przeglądów dostępów w izolacji. IT koordynuje proces, utrzymuje harmonogram przeglądów i wykonuje odebrania dostępu. Osobami, które podejmują decyzje o dostępie, są właściciele zasobów.

Właściciel zasobu to osoba odpowiedzialna za system, zbiór danych albo aplikację. Wie, kto faktycznie z niej korzysta i w jakim celu. To właściwa osoba, żeby potwierdzić, czy dane konto powinno istnieć. IT zna katalog. Właściciele zasobów znają zespoły.

W praktyce właściciele zasobów to zwykle liderzy zespołów, szefowie działów albo właściciele aplikacji. Dla CRM to szef sprzedaży albo wyznaczony właściciel sales ops. Dla hurtowni danych to szef działu danych albo lider analityki. Dla systemu finansowego to CFO albo kontroler.

Przypisanie własności zasobów przed rozpoczęciem cyklu przeglądu to jeden z najważniejszych kroków w budowaniu działającego programu przeglądów. Przeglądy, które kierują wszystkie decyzje do IT, omijają osoby z wiedzą potrzebną, żeby podjąć te decyzje trafnie. Efektem jest albo automatyczne zatwierdzanie, albo opóźnienia.

rytm: jak często przeglądać

Nie ma jednej poprawnej odpowiedzi, ale są obronne punkty wyjścia.

Kwartalnie dla kont wysokiego uprzywilejowania, dostępu admina, dostępu do wrażliwych albo regulowanych danych i każdego systemu, w którym naruszenie miałoby istotne konsekwencje operacyjne albo regulacyjne.

Co pół roku dla standardowego dostępu użytkowników do aplikacji biznesowych. To najczęstszy rytm w środowiskach mid-market, ogólnie akceptowany przez audytorów SOC 2 i jednostki certyfikujące ISO 27001.

Rocznie dla systemów niskiego ryzyka ze stabilną, małą populacją użytkowników. To minimum dla systemów, które w ogóle są objęte zakresem.

Przeglądy wyzwalane zdarzeniem uzupełniają cykl kalendarzowy. Taki przegląd powinien się odbyć, kiedy zajdzie istotna zmiana roli, kiedy dział jest restrukturyzowany, kiedy kończy się zaangażowanie kluczowego kontraktora, albo kiedy incydent rodzi pytania o dostęp.

Właściwy rytm zależy od tego, jak szybko zmienia się wasze środowisko. Firma z wysoką rotacją, częstym korzystaniem z kontraktorów albo szybkim przyjmowaniem SaaS zobaczy szybsze gromadzenie się dostępu i powinna przeglądać go częściej.

jak przeprowadzić przegląd dostępów: krok po kroku

To jest proces. Każdy krok ma zdefiniowanego właściciela i wynik.

Krok 1: Zdefiniuj zakres. Przygotuj listę każdego systemu, aplikacji i zbioru danych, który wymaga przeglądu w tym cyklu. Dla każdego zapisz właściciela zasobu, częstotliwość przeglądu i datę ostatniego ukończonego przeglądu. To wasz harmonogram przeglądów. Bez niego przeglądy dostępów dzieją się doraźnie, kiedy ktoś sobie o nich przypomni, a nie w cyklu. Wynik: harmonogram przeglądów z inwentaryzacją systemów, przypisaniami właścicieli i rytmem.

Krok 2: Pobierz aktualny stan dostępu. Dla każdego systemu w zakresie wyeksportuj aktualną listę użytkowników z rolami i poziomami uprawnień. Eksport powinien zawierać nazwę konta, typ konta (człowiek, serwisowe, współdzielone), aktualny poziom dostępu albo rolę, datę ostatniej aktywności, o ile dostępna, i wszelkie znane odejścia albo zmiany ról od ostatniego przeglądu. Jeśli nie potrafisz wyeksportować listy użytkowników z danego systemu, to luka widoczności do osobnego zaadresowania. Wynik: eksport dostępu dla każdego systemu.

Krok 3: Przypisz recenzentów i skomunikuj. Wyślij każdemu właścicielowi zasobu listę dostępu do jego systemu z jasnymi instrukcjami. Określ, jaka decyzja jest wymagana dla każdego konta, termin odpowiedzi i co się stanie, jeśli odpowiedź nie nadejdzie. Traktuj brak odpowiedzi jako punkt eskalacji, nie jako domyślną zgodę. Wynik: wysłane przypisania przeglądu, udokumentowany termin.

Krok 4: Zbierz decyzje. Recenzenci przechodzą przez swoje listy i zwracają decyzję dla każdego konta: potwierdź (dostęp jest odpowiedni i powinien zostać), zmodyfikuj (poziom dostępu powinien się zmienić, ze wskazaniem nowego poziomu), albo odbierz (dostęp powinien zostać całkowicie usunięty). Cykl przeglądu, który we wszystkich systemach daje zero odebrań dostępu, to sygnał. Może oznaczać, że środowisko jest naprawdę czyste. Częściej oznacza, że recenzenci potwierdzili wszystko bez zastosowania realnej uważności. Wynik: ukończone arkusze decyzji od wszystkich recenzentów.

Krok 5: Wykonaj zmiany. Wszystkie odebrania i modyfikacje dostępu muszą zostać wykonane w zdefiniowanym oknie czasowym. Trzydzieści dni to powszechne i obronne maksimum, a niektóre frameworki oczekują szybszego działania w przypadku findingów wysokiego ryzyka. Wykonanie oznacza, że dostęp jest faktycznie usunięty, nie dodany do backlogu. Finding z przeglądu dostępów, na który nikt nie zareagował, jest traktowany przez audytorów tak samo jak brak findingu. Wynik: log zmian dokumentujący każde odebranie i modyfikację, z sygnaturami czasowymi ukończenia.

Krok 6: Udokumentuj i zamknij. Zbierz pełny zapis przeglądu: datę, objęte systemy, recenzenta dla każdego systemu, podjęte decyzje i dowód, że odebrania dostępu zostały wykonane. Przechowuj to w trwałej, możliwej do audytu lokalizacji. Pytanie, które zadaje audytor, brzmi nie „czy przeprowadzacie przeglądy dostępów?", ale „pokażcie mi ostatni przegląd". Zapis odpowiada na to pytanie. Wynik: ukończony zapis przeglądu, przechowywany i opatrzony datą.

dowody i audit trail

Dowód to coś, co zamienia proces przeglądu w coś, co można wykazać. Bez niego przeprowadziliście przegląd, ale nie potraficie tego udowodnić. Kompletny audit trail obejmuje datę rozpoczęcia przeglądu, objęte systemy i recenzenta przypisanego do każdego z nich, opatrzony sygnaturą czasową eksport dostępu użyty jako podstawa przeglądu, decyzje zwrócone przez każdego recenzenta dla każdego konta, dowód, że odebrania i modyfikacje zostały wykonane (zgłoszenia zmian, zrzuty ekranu z systemu, porównanie eksportów albo logi systemu zarządzania dostępem), i datę zamknięcia przeglądu.

Poziom oczekiwanej dokumentacji skaluje się razem z frameworkiem, z którym się dopasowujecie. Audytorzy SOC 2 Type II zwykle chcą zobaczyć zapisy przeglądów obejmujące cały okres audytu, w tym dowód wykonania. Certyfikacja ISO 27001 wymaga udokumentowanych procedur i zapisów przeglądów. DORA i NIS2 oczekują możliwych do wykazania kontroli zarządzania dostępem, a zapisy przeglądów dostępów służą jako bezpośredni dowód. Jeśli wasz proces przeglądu produkuje decyzje, ale nie zapisy wykonania, macie połowę dowodu. Audytorzy regularnie stwierdzają, że organizacje potrafią pokazać, że przegląd się odbył, ale nie potrafią pokazać, że odebrania dostępu zostały wykonane.

jak przeglądy dostępów mapują się na SOC 2, ISO 27001, NIS2 i DORA

Przeglądy dostępów pojawiają się we wszystkich czterech głównych frameworkach, choć każdy adresuje je inaczej. Wspólny wątek jest taki, że wszystkie oczekują dowodu cyklicznego przeglądu, nie deklaracji, że przeglądy się odbywają.

SOC 2. Trust Services Criteria obejmują kontrole dostępu logicznego jako podstawowy wymóg. Odpowiednie kryteria (CC6.1, CC6.2, CC6.3) adresują nadawanie, modyfikację i usuwanie dostępu. Audytorzy sprawdzający certyfikację Type II będą szukać dowodu, że dostęp jest przeglądany w zdefiniowanym rytmie i że wyniki są egzekwowane. Przeglądy, które się odbyły, ale nie zostały udokumentowane, albo w których odebrania dostępu nie zostały dokończone, tworzą wyjątki.

ISO 27001. Załącznik A, kontrola 5.18 normy ISO 27001:2022 obejmuje zarządzanie uprawnieniami dostępu, w tym wymóg przeglądania uprawnień dostępu w regularnych odstępach. Kontrola oczekuje, że uprawnienia są przeglądane, korygowane i odbierane, kiedy nie są już potrzebne. Audyt certyfikacyjny ISMS sprawdza udokumentowane procedury i zapisy ukończonych przeglądów.

NIS2. NIS2 wymaga od podmiotów objętych zakresem wdrożenia polityk kontroli dostępu jako części środków zarządzania ryzykiem cyberbezpieczeństwa (Artykuł 21). Obejmuje to zapewnienie, że dostęp do wrażliwych systemów jest oparty na zasadzie need-to-know i podlega przeglądowi. Zapisy przeglądów dostępów służą jako bezpośredni dowód.

DORA. Wymogi bezpieczeństwa ICT DORA dla podmiotów finansowych (Artykuł 9) obejmują kontrolę dostępu jako obowiązkowy obszar. Rozciąga się to na cykliczny przegląd uprawnień dostępu użytkowników, ze szczególną uwagą na dostęp uprzywilejowany. Zapisy przeglądów dostępów dopasowane do zdefiniowanego rytmu i szczegółowo obejmujące konta uprzywilejowane to oczekiwany rezultat.

Wszystkie cztery frameworki oczekują cyklicznych, udokumentowanych, egzekwowanych przeglądów. Żadnego z nich nie zaspokoi ustne potwierdzenie, że przeglądy się odbywają.

najczęstsze tryby awarii

Większość programów przeglądu dostępów zawodzi na jeden z czterech sposobów.

Automatyczne zatwierdzanie. Recenzenci zatwierdzają wszystko bez uważnego sprawdzenia. Dzieje się tak, kiedy recenzenci dostają długą listę, nie mają wskazówek, mają krótki termin i nie ponoszą odpowiedzialności za nietrafne zatwierdzenia. Naprawa to mniejsze obciążenie recenzentów, lepszy kontekst dla każdego konta (ostatnia aktywność, historia ról) i odpowiedzialność za wynik.

Brak dociągnięcia odebrań do końca. Przegląd identyfikuje konta do usunięcia, ale usunięcia nie są dokończone, albo są dokończone miesiące później. Częściowe wykonanie to częsty wyjątek audytowy. Naprawa to zdefiniowane okno wykonania ze wskazanym właścicielem i zapis zamknięcia, który potwierdza ukończenie, zanim przegląd zostanie zamknięty.

Brakujące systemy. Przegląd obejmuje katalog i główne aplikacje biznesowe, ale pomija aplikacje SaaS, portale kontraktorów, dyski współdzielone i konsole chmurowe. Zwykle dzieje się tak, kiedy inwentaryzacja systemów jest niekompletna. Przegląd jest tak dobry, jak jego zakres.

Brak dowodów. Przegląd się odbył, ale zapisy nie istnieją, były przechowywane nieformalnie, albo nie da się ich znaleźć, kiedy są potrzebne. Decyzje podjęte ustnie na spotkaniu albo zatwierdzenia wysłane wiadomością błyskawiczną bez archiwum nie stanowią dowodu audytowego. Naprawa to zdefiniowany format zapisu przeglądu i trwała lokalizacja przechowywania, ustalone przed rozpoczęciem cyklu przeglądu.

Wyłącznie roczny rytm dla dostępu uprzywilejowanego. Prowadzenie rocznego przeglądu dla kont admina i uprzywilejowanych jest poniżej progu oczekiwanego przez większość frameworków. Dostęp uprzywilejowany zmienia się szybciej i niesie więcej ryzyka. Kwartalne albo wyzwalane ryzykiem przeglądy to obronne minimum dla tej populacji.

narzędzia: na co zwracać uwagę

Przeglądy dostępów można prowadzić ręcznie, za pomocą arkuszy kalkulacyjnych i zatwierdzeń mailowych. W małej skali to działa. Kiedy liczba systemów, recenzentów i kont rośnie, ręczne procesy produkują tryby awarii opisane powyżej.

Wymagania funkcjonalne dla wsparcia przeglądów dostępów są spójne w większości narzędzi: automatyczny eksport dostępu z połączonych systemów, przypisywanie i powiadamianie recenzentów, ustrukturyzowany interfejs decyzyjny zamiast arkusza przesyłanego mailem, automatyczne wykonanie odebrań przez integracje systemowe i eksport dowodów spełniający standardy audytowe.

Wiele platform IdP (Okta, Microsoft Entra, Google Workspace) zawiera podstawowe funkcje certyfikacji dostępu. Działają dla systemów, którymi zarządzają bezpośrednio, ale nie obejmują niezarządzanego SaaS, shadow apps ani systemów spoza zakresu SCIM. Dedykowane narzędzia IGA (SailPoint, Saviynt, Omada i inne) oferują szersze pokrycie i bardziej ustrukturyzowany workflow. Wymagają pracy integracyjnej i zwykle są wdrażane, kiedy organizacje dojrzewają poza to, co pokrywają natywne funkcje IdP. Dla organizacji, które nie przeprowadziły jeszcze formalnego cyklu przeglądu, właściwym punktem startowym jest zwykle ręczny proces z zdefiniowanym szablonem, skupiony na systemach najwyższego ryzyka. Zbuduj nawyk i zapis dowodowy, zanim dodasz złożoność narzędziową.

przykładowy rytm w praktyce

To przykładowy rytm dla firmy ze średniej wielkości środowiskiem tożsamości. Dostosuj do swoich systemów i profilu ryzyka.

Kwartalnie (styczeń, kwiecień, lipiec, październik): wszystkie role admina IdP, root i admin konsol chmurowych, dostęp uprzywilejowany do systemów finansowych i danych; wszystkie konta serwisowe z dostępem do systemów produkcyjnych; wszystkie konta zewnętrznych kontraktorów aktywne w danym kwartale.

Co pół roku (styczeń, lipiec): standardowy dostęp użytkowników do wszystkich aplikacji biznesowych (CRM, ERP, system HR, zarządzanie projektami, narzędzia do współpracy); sprawdzenie inwentaryzacji SaaS pod kątem aplikacji dodanych poza listą zarządzaną przez SCIM od ostatniego przeglądu.

Rocznie (styczeń): narzędzia niskiego ryzyka, takie jak analityka marketingowa, wewnętrzne wiki i narzędzia raportujące tylko do odczytu z minimalną ilością wrażliwych danych; inwentaryzacja kluczy API obejmująca wszystkie aktywne klucze z dostępem do systemów produkcyjnych, z oznaczeniem długo żyjących kluczy do rotacji.

Przeglądy wyzwalane zdarzeniem (w miarę występowania): każda istotna zmiana roli, koniec zaangażowania kontraktora, incydent albo podejrzenie nieautoryzowanego dostępu, albo każdy dodany system, który nie jest objęty cyklem kwartalnym albo półrocznym.