Przeglądy uprawnień użytkowników, które akceptują audytorzy (z szablonem)
Przegląd uprawnień użytkowników to okresowe sprawdzenie, czy każde konto w systemie nadal należy do kogoś, kto go potrzebuje — na poziomie uprawnień, którego potrzebuje. Audytorzy testujący SOC 2 CC6 albo ISO 27001 A.5.18 i A.8.2 odrzucają ten dowód z przewidywalnych powodów: nie da się wykazać, że populacja kont jest kompletna, przeglądu dokonała ta sama osoba, która ma dany dostęp, eksport pokazuje kto ma dostęp, ale nie co zdecydowano, albo odebranie uprawnień zatwierdzono i nigdy nie wykonano. Użyteczny dowód nazywa populację i jej źródło, zapisuje decyzję dla każdego konta wraz z osobą przeglądającą i datą oraz domyka pętlę dowodem, że usunięcia faktycznie nastąpiły.
Przegląd uprawnień użytkowników to okresowe sprawdzenie, czy każde konto w systemie nadal należy do kogoś, kto go potrzebuje — na poziomie uprawnień, którego potrzebuje. To jeden z najczęściej żądanych dowodów audytowych — i jeden z najczęściej odrzucanych, bo zespoły przesyłają eksport listy użytkowników, podczas gdy audytor prosił o zapis decyzji.
To rozróżnienie jest ważniejsze niż jakikolwiek inny szczegół w tym artykule: eksport pokazuje stan; przegląd pokazuje osąd. Arkusz ze wszystkimi, którzy mieli dostęp w marcu, dowodzi tylko tego, że potrafisz odpytać własne systemy. Audytor sprawdza natomiast, czy konkretna, wskazana z imienia i nazwiska osoba spojrzała na każde z tych kont i coś o nim zdecydowała.
Czego naprawdę wymagają standardy
Przeglądy uprawnień leżą na przecięciu dwóch wymagań z różnych standardów — dlatego pojawiają się w niemal każdym audycie:
- SOC 2 Common Criteria CC6 obejmuje dostęp logiczny: jak dostęp jest rejestrowany, autoryzowany, modyfikowany i odbierany. Przeglądy to sposób, żeby pokazać, że autoryzacja pozostaje poprawna w czasie, a nie tylko w momencie nadania. Zobacz wyjaśnienie Common Criteria.
- ISO 27001 Załącznik A.5.18 (prawa dostępu) obejmuje nadawanie, przeglądanie i odbieranie praw dostępu. A.8.2 (uprzywilejowane prawa dostępu) podnosi poprzeczkę konkretnie dla kont administracyjnych, a A.5.15–A.5.17 obejmują otaczające je praktyki kontroli dostępu, tożsamości i uwierzytelniania. Kompletny przewodnik po Załączniku A pokazuje, jak to się ze sobą łączy.
Żaden ze standardów nie narzuca częstotliwości. Oba oczekują, że ją zdefiniujesz, uzasadnisz ryzykiem, a potem faktycznie jej dotrzymasz.
Krok 1: Zdefiniuj populację — to jest testowane jako pierwsze
Zanim audytor spojrzy na jakąkolwiek pojedynczą decyzję, sprawdzi, czy Twoja lista była kompletna. To krok, który zespoły pomijają, i to krok, który unieważnia wszystko, co jest dalej: jeśli populacja jest błędna, żadnej decyzji podjętej na jej podstawie nie da się zweryfikować.
Kompletność oznacza dwie rzeczy. Po pierwsze: przeglądem objęte zostało każde konto w systemie, nie tylko te, o których akurat pamiętałeś — łącznie z kontami serwisowymi, kontami kontraktorów, kontami współdzielonymi i kontami osób, które już odeszły. Po drugie: potrafisz pokazać, skąd wzięła się lista — eksport wygenerowany przez system, z widocznym źródłem i znacznikiem czasu, a nie arkusz prowadzony ręcznie.
Praktyczny sposób, żeby to spełnić: wyeksportuj listę użytkowników bezpośrednio z każdego systemu objętego zakresem, zanotuj datę eksportu i osobę, która go wykonała, a potem uzgodnij sumę z listą kadrową HR oraz z inwentarzem aktywów i systemów. Każde konto, które jest w systemie, a nie ma go w HR, to albo konto serwisowe, które musisz udokumentować, albo ustalenie, które musisz naprawić.
Krok 2: Dobierz częstotliwość według ryzyka, nie według przyzwyczajenia
Częstotliwość powinna iść za promieniem rażenia danego dostępu. Broniący się wzorzec dla małego zespołu:
- Dostęp uprzywilejowany i administracyjny — kwartalnie. Infrastruktura produkcyjna, chmurowe role root i admin, administracja bazami danych, wszystko, co może nadawać kolejne uprawnienia.
- Standardowy dostęp do systemów z danymi klientów — co pół roku albo raz w roku, zależnie od wrażliwości danych i od tego, jak bardzo rotuje Twój zespół.
- Wyzwalany zdarzeniem, obok kalendarza — przegląd uruchamiany zmianą roli, reorganizacją zespołu albo odejściem, zamiast czekania na kolejny zaplanowany cykl.
Wpisz częstotliwość do swojej polityki kontroli dostępu, a potem jej dotrzymuj. Audytor, który zestawi politykę obiecującą przeglądy kwartalne z dowodami na dwa przeglądy w roku, zgłosi ustalenie — a to ustalenie dotyczy niedotrzymanego zobowiązania, nie samej częstotliwości. Polityka, której naprawdę przestrzegasz, bije ambitną, której nie przestrzegasz.
Krok 3: Upewnij się, że przeglądający nie przegląda sam siebie
Niezależność to drugi najczęstszy powód odrzucenia. Osoba, która przegląda konto, nie powinna być tą, która to konto ma — i najlepiej też nie tą, która nadaje dostępy.
W większości małych firm działa model, w którym właściciel systemu albo przełożony posiadacza konta wykonuje przegląd, a ktoś inny — założyciel, osoba odpowiedzialna za bezpieczeństwo, ktokolwiek prowadzi SZBI — zatwierdza przegląd jako całość. Dzięki temu na zapisie są dwa nazwiska, a właśnie tego szuka audytor.
Niewygodny przypadek to dwuosobowy startup, w którym CTO jest właścicielem każdego systemu i trzyma wszystkie poświadczenia administracyjne. Uczciwa odpowiedź to nie udawać, że jest inaczej: niech drugi założyciel przejrzy dostępy CTO, udokumentuj, że rozdział obowiązków jest ograniczony wielkością zespołu, i odnotuj kontrole kompensujące (logowanie, alerty przy zmianach uprawnień). Audytorzy dużo chętniej przyjmują udokumentowane, uzasadnione ograniczenia niż fikcyjny podział.
Ready to Streamline Your Compliance?
Discover how AuditBadger can simplify your compliance management process.
Krok 4: Zapisz decyzję dla każdego konta
To ta część, która zamienia eksport w przegląd. Każdy wiersz populacji potrzebuje jawnego wyniku — a „brak działania” to też wynik, o ile wybrał go człowiek.
| Kolumna | Co w niej wpisujesz |
|---|---|
| System | Objęty zakresem system, który podlega przeglądowi |
| Konto / nazwa użytkownika | Identyfikator w takiej postaci, w jakiej występuje w systemie |
| Typ konta | Osobowe, serwisowe, współdzielone, kontraktora |
| Właściciel | Imiennie wskazana osoba odpowiedzialna za konto |
| Poziom dostępu | Posiadana rola lub uprawnienie, nie tylko „ma dostęp” |
| Uzasadnienie biznesowe | Dlaczego ta osoba potrzebuje tego poziomu |
| Decyzja | Zachowaj / Ogranicz / Odbierz |
| Osoba przeglądająca | Imiennie wskazana osoba, która podjęła decyzję |
| Data przeglądu | Kiedy podjęto decyzję |
| Podjęte działanie | Numer zgłoszenia lub rekord zmiany dla Ogranicz/Odbierz |
| Działanie zakończone | Data faktycznego wprowadzenia zmiany i przez kogo |
Dwie ostatnie kolumny to te, które zespoły zostawiają puste, i te, które audytorzy sprawdzają najostrzej.
Krok 5: Domknij pętlę — zatwierdzone to nie usunięte
Przegląd, który wskazuje dwanaście kont do odebrania uprawnień i nie odbiera ich w żadnym z nich, jest gorszy niż brak przeglądu: dokumentuje, że wiedziałeś o problemie i go nie naprawiłeś. Audytorzy rutynowo losują próbkę odebranych dostępów z Twojego przeglądu i sprawdzają w działającym systemie, czy konto faktycznie zniknęło.
Dlatego pakiet dowodowy dla każdego cyklu potrzebuje trzech artefaktów, nie jednego:
- Eksportu populacji, ze źródłem i datą.
- Wypełnionego zapisu przeglądu, z decyzjami dla poszczególnych kont, nazwiskami osób przeglądających i datami.
- Dowodu wykonania — zgłoszeń, rekordów zmian albo późniejszego eksportu pokazującego, że konta z odebranym dostępem faktycznie zniknęły.
Ten trzeci artefakt zamienia przegląd z deklaracji w dowód. Jak to wpisuje się w szerszy obraz dowodów, zobacz czego audytorzy naprawdę chcą jako dowodu.
Przeglądy wyłapują to, co przegapił offboarding
Warto jasno powiedzieć, jaką pracę wykonuje przegląd. Offboarding to Twoja kontrola prewencyjna: kiedy ktoś odchodzi, dostęp odchodzi razem z nim, tego samego dnia. Przegląd uprawnień to kontrola detekcyjna, która łapie przypadki, w których offboarding nie zadziałał — kontraktor, którego współpraca po cichu się skończyła, narzędzie SaaS, którego nie było na liście offboardingowej, konto serwisowe założone do migracji zakończonej rok temu.
Jeśli Twoje przeglądy uprawnień regularnie wyciągają na wierzch osoby, które już odeszły, ustalenie tak naprawdę nie dotyczy przeglądu. Dotyczy procesu offboardingu i to tam należy je naprawić.
Antywzorce
- Wysłanie eksportu zamiast przeglądu. Stan, nie osąd. Najczęstszy powód odrzucenia, jaki istnieje.
- Przeglądanie tylko tych systemów, które łatwo wyeksportować. Audytorzy pytają o systemy objęte zakresem — także o te niewygodne.
- Hurtowe zatwierdzanie wszystkich wierszy jednym kliknięciem. Przegląd, w którym w rosnącej firmie zachowano 100% kont, zachęca do wnikliwszego sprawdzenia — a jeśli nigdy nic się nie zmienia, przeglądający nie przegląda.
- Zapominanie o kontach serwisowych i współdzielonych. Niosą najwięcej uprawnień i najmniej odpowiedzialności.
- Brak jakiegokolwiek śladu po wykonaniu. Decyzja bez doprowadzenia sprawy do końca to niezamknięte ustalenie.
Wnioski
Przeglądy uprawnień nie są trudne, ale są wymagające: kompletna populacja z eksportu systemowego, przeglądający, który sam nie ma tego dostępu, jawna decyzja przy każdym koncie i dowód, że odebranie uprawnień naprawdę nastąpiło. Rób to cztery razy w roku dla kont uprzywilejowanych, a prośba o dowody przestanie być gorączkową zbiórką.
Dalej: całoroczna checklista monitorowania, żeby zobaczyć, gdzie przeglądy siedzą w szerszym kalendarzu, zbieranie dowodów do SOC 2 po resztę listy żądań, albo zobacz, jak automatyczne zbieranie dowodów trzyma populację i dowód razem.
