Dojrzałość bezpieczeństwa tożsamości: samoocena

co oznacza dojrzałość bezpieczeństwa tożsamości

Dojrzałość bezpieczeństwa tożsamości opisuje, jak konsekwentnie i systematycznie organizacja zarządza pełnym cyklem życia dostępu cyfrowego. Przy niskiej dojrzałości dostęp jest nadawany na żądanie, odbierany niekonsekwentnie i nigdy w pełni nie inwentaryzowany. Przy wysokiej dojrzałości każde konto ma znanego właściciela, decyzje o dostępie podlegają udokumentowanemu procesowi, a okresowe przeglądy potwierdzają, że stan środowiska odpowiada zamierzeniu.

W praktyce różnica sprowadza się do widoczności i kontroli. Dojrzałe środowisko tożsamości potrafi wiarygodnie odpowiedzieć na cztery pytania: kto ma dostęp, do czego, dlaczego i czy to nadal ma sens. Niewiele organizacji potrafi odpowiedzieć na wszystkie cztery bez przeprowadzenia dedykowanej oceny.

Dojrzałość na żadnym poziomie nie wymaga konkretnych narzędzi. Wymaga konsekwentnego procesu i dowodów, że ten proces faktycznie działa. Dobrze przeprowadzony przegląd dostępów w arkuszu kalkulacyjnym świadczy o większej dojrzałości niż droga platforma IGA, z której nikt nie korzysta poprawnie. Ten przewodnik skupia się na sześciu wymiarach, które obejmują powierzchnię ryzyka dostępu najbardziej istotną dla firm z segmentu mid-market. Każdy jest oceniany niezależnie. To zwykle najsłabiej oceniony wymiar kryje w sobie realne ryzyko.

model dojrzałości: cztery poziomy

Te poziomy stosuje się do każdego wymiaru osobno. Organizacja może być jednocześnie na poziomie 3 w pokryciu MFA i na poziomie 1 w nadzorze nad OAuth.

Poziom 1: doraźny (ad hoc). Brak formalnego procesu dla tego wymiaru. Działania podejmowane są reaktywnie, gdy coś pójdzie nie tak albo ktoś o to poprosi. Nie ma inwentarza, dokumentacji ani cyklu przeglądów.

Poziom 2: zarządzany. Istnieją podstawowe procesy dla najbardziej widocznych scenariuszy. Główne systemy są objęte, ale pokrycie jest niepełne. Dokumentacja częściowo istnieje, ale nie jest regularnie aktualizowana. Działania zależą od tego, czy właściwa osoba jest dostępna i pamięta, żeby zareagować.

Poziom 3: zdefiniowany. Udokumentowany, powtarzalny proces obejmuje pełen zakres tego wymiaru. Przypisana jest odpowiedzialność. Istnieje rytm przeglądów i ślad dowodowy. Luki wciąż mogą istnieć, ale są widoczne i śledzone, a nie nieznane.

Poziom 4: mierzony. Proces działa konsekwentnie, generuje dowody i jest sprawdzany pod kątem skuteczności. Istnieją metryki, na podstawie których się działa. Stan środowiska w tym wymiarze można dokładnie opisać w dowolnym momencie, nie tylko po ręcznym audycie.

Większość firm z segmentu mid-market plasuje się między poziomem 2 a 3 w tych wymiarach. Celem tej oceny jest zidentyfikowanie wymiarów, w których jesteś na poziomie 1, i potraktowanie ich jako ustaleń P0, zanim zajmiesz się dalszym rozwijaniem wymiarów ocenionych już wyżej.

wymiar 1: pokrycie MFA

MFA blokuje ponad 99,2% ataków na przejęcie konta (Microsoft). Częściowe wdrożenie oznacza częściową ochronę.

Jak wygląda dobry stan. MFA jest wymuszone na każdym koncie w katalogu, łącznie z kontami administracyjnymi, kontami serwisowymi tam, gdzie jest to technicznie wykonalne, i wszystkimi zewnętrznymi ścieżkami dostępu. Wymuszenie jest obowiązkowe, nie opcjonalne. Konta nie mogą ominąć MFA, korzystając z przestarzałego protokołu uwierzytelniania. Nowe konta są objęte MFA od pierwszego dnia.

Jak wygląda słaby stan. MFA jest wdrożone na poczcie i kilku narzędziach SaaS, ale nie na VPN ani systemach wewnętrznych. Konta administracyjne są objęte niekonsekwentnie. Część użytkowników skonfigurowała MFA, ale nie musi go używać przy każdym logowaniu. Konta założone przed wprowadzeniem polityki MFA nigdy nie zostały zaktualizowane.

Pytania do samooceny. Czy potrafisz dziś wyciągnąć listę wszystkich kont i sprawdzić status MFA? Czy są konta administracyjne bez skonfigurowanego albo wymaganego MFA? Czy VPN wymaga MFA niezależnie od logowania przez IdP? Czy istnieją aplikacje akceptujące bezpośrednie logowanie, całkowicie omijające IdP? Kiedy ostatni raz sprawdzono status MFA na kontach administracyjnych?

Choćby jedno konto administracyjne bez wymuszonego MFA to ustalenie P0, niezależnie od tego, jak dobrze wypada reszta oceny. Te dane logowania kontrolują wszystko, do czego dany administrator ma dostęp, a jedyną barierą jest samo hasło.

wymiar 2: higiena dostępu uprzywilejowanego

Dostęp uprzywilejowany to każde konto, które może zmieniać konfigurację, tworzyć inne konta, sięgać po dane wykraczające poza zakres standardowego użytkownika albo wpływać na stan bezpieczeństwa systemu.

Jak wygląda dobry stan. Konta administracyjne są oddzielone od kont do codziennej pracy. Każde konto uprzywilejowane ma wymuszone MFA. Pełna lista kont uprzywilejowanych w całym środowisku jest znana i przeglądana w ustalonym rytmie. Działania administracyjne są logowane. Tymczasowe podwyższone uprawnienia mają ograniczenie czasowe i są przeglądane.

Jak wygląda słaby stan. Administratorzy używają kont o wysokich uprawnieniach do codziennej pracy. Część osób ma dostęp administracyjny z projektu sprzed miesięcy albo lat, który nigdy nie został odebrany. Pełna lista kont administracyjnych we wszystkich systemach nigdy nie została zestawiona. Logowanie audytowe istnieje w części systemów, a w innych nie.

Pytania do samooceny. Czy masz pełną listę wszystkich kont z uprawnieniami administracyjnymi albo podwyższonymi w katalogu, platformach chmurowych i głównych narzędziach SaaS? Czy jakiekolwiek konta administracyjne są używane jako konta do codziennej pracy? Ile osób ma dostęp administracyjny w IdP i ile z nich pełni obecnie rolę, która tego wymaga? Kiedy ostatnio sprawdzono, czy konkretna osoba nadal potrzebuje swojego uprawnienia administracyjnego? Czy działania administracyjne w krytycznych systemach są logowane i przechowywane?

Ryzyko niekontrolowanego dostępu uprzywilejowanego wykracza poza same konta i sięga luki audytowej. Gdy coś pójdzie nie tak w systemie ze współdzielonym albo nieudokumentowanym dostępem administracyjnym, dochodzenie nie ma śladu, którym mogłoby podążyć.

wymiar 3: kompletność offboardingu

83% pracowników przyznaje, że nadal ma dostęp do co najmniej jednego konta z poprzedniego pracodawcy (Beyond Identity, 2022, dane deklaratywne). Średni czas identyfikacji i opanowania naruszenia to 241 dni (IBM). Te dwie liczby razem opisują, jak w praktyce wygląda niekompletny offboarding.

Jak wygląda dobry stan. Offboarding uruchamia udokumentowany proces obejmujący każdy system, nie tylko główny katalog. Aplikacje SaaS z bezpośrednim logowaniem są jawnie sprawdzane. Granty OAuth autoryzowane przez odchodzącą osobę są odbierane. Tokeny API i konta serwisowe utworzone przez tę osobę są identyfikowane i przekazywane dalej albo rotowane. Kontrola uzupełniająca po 30 dniach potwierdza, że nic nie zostało pominięte.

Jak wygląda słaby stan. Offboarding oznacza zamknięcie głównego konta w katalogu. Zakłada się, że narzędzia SaaS uwierzytelniane przez SSO są przez to objęte. Bezpośrednie logowania do narzędzi niepodłączonych do SSO nie są sprawdzane. Granty OAuth nie są celowo odbierane. Tokeny i konta serwisowe powiązane z odchodzącą osobą nie są identyfikowane.

Pytania do samooceny. Czy twoja lista kontrolna offboardingu jawnie obejmuje narzędzia SaaS niepodłączone do SSO? Czy odbierasz granty OAuth, gdy ktoś odchodzi, czy zakładasz, że zamknięcie konta w katalogu wystarczy? Czy identyfikujesz i przekazujesz dalej tokeny API albo konta serwisowe należące do odchodzących osób? Czy masz kontrolę po offboardingu po 30 dniach? Czy potrafisz teraz odpowiedzieć, czy konkretna osoba, która odeszła sześć miesięcy temu, wciąż ma dostęp do jakiegoś systemu?

wymiar 4: nadzór nad OAuth

Granty OAuth to uprawnienia, jakie użytkownicy nadają aplikacjom firm trzecich do dostępu do danych w twoim środowisku pracy. Kumulują się bez przerwy i rzadko są odbierane.

Jak wygląda dobry stan. Masz aktualną listę wszystkich aktywnych grantów OAuth, z nazwą aplikacji, zakresem dostępu i użytkownikiem, który go autoryzował. Granty z nieaktywnych albo odebranych kont zostały odwołane. Granty o szerokim zakresie (pełny odczyt skrzynki, pełny dostęp do plików, zapis kalendarza) są przeglądane co kwartał. Nowe granty OAuth powyżej ustalonego progu zakresu przechodzą proces zatwierdzenia przed autoryzacją.

Jak wygląda słaby stan. Granty OAuth nigdy nie były audytowane jako osobna kategoria. Nie masz pełnej listy aplikacji firm trzecich, które obecnie mają dostęp do twojego środowiska Google Workspace, Microsoft 365 albo Okta. Część osób, które odeszły, miała granty OAuth, które nie zostały celowo odebrane. Kilka grantów powstało podczas okresów próbnych produktów i nigdy nie zostało przejrzanych.

Pytania do samooceny. Czy kiedykolwiek wyciągnąłeś pełną listę aktywnych grantów OAuth z konsoli administracyjnej IdP? Czy jakieś granty należą do kont, które już nie są aktywne? Czy są granty z zakresem odczytu skrzynki albo pełnego dostępu do plików od aplikacji, z których już aktywnie nie korzystasz? Czy twoja organizacja ma proces przeglądu albo zatwierdzania grantów OAuth, zanim użytkownicy je autoryzują? Kiedy ostatni raz jakikolwiek grant OAuth został jawnie odebrany w wyniku świadomej decyzji zgodnej z przyjętą polityką?

Nadzór nad OAuth leży na styku bezpieczeństwa SaaS i tożsamości. To często wymiar z największymi zaległościami w środowiskach, które nigdy go osobno nie oceniły.

wymiar 5: widoczność shadow SaaS

Shadow SaaS to każda używana aplikacja, której IT nie wdrożyło i nie przejrzało. Ryzyko polega na tym, że te narzędzia przechowują dane firmowe i mają ścieżki dostępu, których nie obejmują twoje procesy offboardingu i przeglądów dostępów. Pracownicy je wdrażają, bo są produktywne. Luka polega na tym, że nikt nie zmapował, do czego mają dostęp.

Jak wygląda dobry stan. Masz aktualny inwentarz wszystkich używanych aplikacji SaaS, łącznie z tymi wdrożonymi przez zespoły spoza IT. Nowe aplikacje przechodzą lekki przegląd, zanim użytkownicy podłączą je do kont firmowych albo wgrają do nich wrażliwe dane. Inwentarz jest aktualizowany przy każdym dodaniu aplikacji. Konta odchodzących pracowników w aplikacjach niepodłączonych do SSO są sprawdzane podczas offboardingu.

Jak wygląda słaby stan. Oficjalna lista oprogramowania obejmuje narzędzia wdrożone przez IT. Narzędzia działowe wdrożone przez sprzedaż, marketing czy inżynierię w ciągu ostatnich dwóch lat nie są śledzone. Użytkownicy regularnie zakładają konta w nowych narzędziach SaaS, używając firmowego maila. Nikt nie ma pełnego obrazu tego, co jest w użyciu.

Pytania do samooceny. Czy twój zespół IT widzi aplikacje SaaS wdrożone bez etapu zakupowego przez IT? Czy są w użyciu aplikacje przechowujące dane klientów albo dokumenty wewnętrzne, których IT nie wdrożyło? Czy uwzględniasz narzędzia SaaS niepodłączone do SSO w procesie offboardingu? Czy sprawdziłeś, które aplikacje SaaS są widoczne na liście podłączonych aplikacji w IdP w porównaniu z tym, co faktycznie jest w użyciu? Kiedy ostatnio zaktualizowano oficjalny inwentarz aplikacji?

Shadow SaaS to problem widoczności, nie problem dyscypliny. Rozwiązaniem jest proces wykrywania i lekki nadzór, a nie całkowity zakaz.

wymiar 6: ekspozycja na narzędzia AI

W większości organizacji wdrażanie narzędzi AI wyprzedza nadzór nad nimi. Ten wymiar mierzy, czy wiesz, jakie narzędzia AI są w użyciu, jakie dane do nich płyną i czy istnieje polityka albo proces, który to reguluje.

Jak wygląda dobry stan. Masz aktualny obraz tego, jakich narzędzi AI używają pracownicy, łącznie z rozszerzeniami przeglądarki, samodzielnymi narzędziami webowymi i integracjami z istniejącymi platformami. Istnieje udokumentowana polityka określająca, które narzędzia są zatwierdzone, jakich danych można z nimi używać i co jest poza zakresem. Narzędzia AI łączące się z systemami firmowymi przez OAuth albo API zostały przejrzane. Wiesz, czy jakiekolwiek narzędzia trenują się na danych firmowych i czy obowiązują odpowiednie umowy.

Jak wygląda słaby stan. Poszczególni pracownicy korzystają z ChatGPT, Claude, Copilota, Gemini i różnych rozszerzeń AI do przeglądarki. Część zakłada konta na firmowe adresy mailowe. Nie ma aktualnego inwentarza narzędzi aktywnie w użyciu. Nie ma polityki określającej, jakie dane można wprowadzać do narzędzi AI. Nikt nie sprawdził, czy jakiekolwiek narzędzie AI ma połączenie OAuth z kontami firmowymi.

Pytania do samooceny. Czy masz listę narzędzi AI aktualnie w użyciu? Czy istnieje polityka określająca, jakie dane firmowe można, a jakich nie można używać z zewnętrznymi narzędziami AI? Czy sprawdziłeś listę podłączonych aplikacji w IdP pod kątem grantów OAuth narzędzi AI? Czy są zainstalowane rozszerzenia AI w przeglądarkach, które mają też dostęp do firmowej poczty albo dokumentów? Czy wiesz, które narzędzia AI mają domyślne ustawienia obejmujące trenowanie na danych wejściowych użytkownika?

Ekspozycja na narzędzia AI to wymiar, którego większość organizacji formalnie nie oceniła. Brak oceny odzwierciedla lukę w widoczności, a nie brak ryzyka.

jak ocenić się samodzielnie

Dla każdego wymiaru przypisz poziom z modelu dojrzałości. Użyj pytań do samooceny, żeby zakotwiczyć swoją ocenę. Jeśli nie potrafisz odpowiedzieć na większość pytań dla danego wymiaru, ten wymiar jest na poziomie 1. Tam, gdzie odpowiedź brzmi „mamy proces, ale nie obejmuje wszystkiego", to poziom 2. Tam, gdzie proces obejmuje pełen zakres i generuje dowody, to poziom 3 albo 4, w zależności od tego, czy dodatkowo mierzysz i przeglądasz jego skuteczność.

Po ocenieniu wszystkich sześciu wymiarów spójrz na rozkład. Choćby jeden wymiar na poziomie 1 w środowisku ogólnie ocenionym na poziomie 3 stanowi istotną koncentrację ryzyka. Ogólna średnia liczy się mniej niż najsłabsze ogniwo.

co naprawić najpierw: myślenie w kategoriach P0, P1, P2

Ocena dojrzałości daje ustalenia. Wartość leży w priorytetyzacji, nie na samej liście.

P0: napraw natychmiast. Każde konto administracyjne bez wymuszonego MFA. Każde aktywne konto należące do osoby, która odeszła z organizacji. Każdy grant OAuth przypisany do konta odchodzącego użytkownika, który nie został jawnie odebrany. Ustalenia P0 to żywe ryzyka, na które można zareagować w tym samym tygodniu. Działanie jest konkretne (odbierz ten grant, wymuś MFA na tym koncie, wyłącz to konto), a potrzebne narzędzia to te, które już masz.

P1: napraw w tym kwartale. Luki w MFA na kontach użytkowników niebędących administratorami. Aplikacje shadow SaaS przechowujące wrażliwe dane bez nadzoru. Granty OAuth o szerokim zakresie z aplikacji, które nie są już używane. Konta uprzywilejowane, które nigdy nie zostały skonfrontowane z aktualnymi wymogami roli. Luki w offboardingu, gdzie proces jest udokumentowany, ale nie obejmuje SaaS poza SSO. To wymaga zaprojektowania procesu albo koordynacji, nie tylko jednorazowego działania.

P2: zaplanuj na kolejny cykl przeglądu. Wymiary, w których proces jest częściowo zdefiniowany i wymaga sformalizowania. Nadzór nad narzędziami AI, gdzie użycie istnieje, ale polityki nie ma. Rytm przeglądów grantów OAuth, który trzeba dopiero ustalić. Wykrywanie shadow SaaS, które trzeba przeprowadzać co roku. Ustalenia P2 niosą realne ryzyko i są niżej niż P0 i P1 tylko dlatego, że wymagają strukturalnej pracy nad procesem, a nie pojedynczego, jednorazowego działania.

Użyteczna zasada: jeśli nie potrafisz jasno wskazać, kto odpowiada za dane ustalenie i jakie konkretne działanie je zamyka, to ustalenie nie jest jeszcze dobrze zdefiniowane. Dobra priorytetyzacja daje zadania do wykonania, nie kategorie niepokoju.

jak to się przekłada na przeglądy dostępów i standardy

Dojrzałość bezpieczeństwa tożsamości i przeglądy dostępów są ze sobą powiązane, ale to nie to samo. Przeglądy dostępów to okresowy proces potwierdzania, kto nadal powinien mieć dostęp do jakich systemów. Dojrzałość opisuje system kontroli, którego przeglądy dostępów są jednym elementem. Organizacja może prowadzić przeglądy dostępów bez wysokiej dojrzałości w pozostałych wymiarach: jeśli pokrycie MFA jest słabe, a granty OAuth nie są inwentaryzowane, przeglądy dostępów potwierdzą dostęp w katalogu, podczas gdy realne ryzyko siedzi w wymiarach, których przegląd nie objął.

SOC 2 adresuje dostęp uprzywilejowany, MFA i przegląd dostępów użytkowników w ramach kryteriów kontroli dostępu logicznego (CC6.1 do CC6.3). ISO 27001:2022 zawiera kontrole dotyczące zarządzania dostępem (Annex A, 5.15-5.18), informacji uwierzytelniających (5.17) i przeglądu praw dostępu (5.18). NIS2 wymaga od podmiotów objętych regulacją wdrożenia polityk kontroli dostępu i wykazania, że dostęp do systemów krytycznych jest odpowiednio zarządzany (Artykuł 21). DORA wymaga od podmiotów finansowych utrzymania kontroli dostępu ICT obejmujących zarządzanie dostępem uprzywilejowanym i okresowy przegląd (Artykuł 9). Dojrzałość w tych wymiarach nie daje certyfikatu. Daje dowody i faktyczny stan, których szukają certyfikacje i audyty.

częste wzorce

Te wzorce pojawiają się często w ocenach i warto sprawdzić je osobno.

MFA na poziomie 3 dla użytkowników, na poziomie 1 dla administratorów. Wdrożenie MFA często obejmuje standardowych użytkowników, a konta administracyjne są odkładane z powodu postrzeganej złożoności operacyjnej. W efekcie konta o najwyższych uprawnieniach są też najsłabiej chronione.

Offboarding na poziomie 3 dla katalogu, na poziomie 1 dla wszystkiego innego. Formalna lista kontrolna zamyka konto w IdP i odbiera laptop. Aplikacje SaaS z bezpośrednim logowaniem, granty OAuth i konta serwisowe utworzone przez odchodzącą osobę nie są objęte procesem. Luka jest niewidoczna, bo offboarding wygląda na zakończony prawidłowo.

Zaległości w grantach OAuth, których nigdy nie rozliczono. Organizacje korzystające z Google Workspace albo Microsoft 365 od kilku lat mają zwykle setki aktywnych grantów OAuth, wiele z aplikacji, które nie są już używane. Gdy wyciągnie się je i przejrzy po raz pierwszy, spora część należy do nieaktywnych kont albo ma szerszy zakres, niż wymaga tego funkcja aplikacji.

Shadow SaaS i AI w tej samej luce nadzoru. W wielu organizacjach żadne z nich nie zostało formalnie ocenione. Oba traktowane są jak decyzje na poziomie zespołu, których IT nie musi nadzorować. Przepływy danych z obu obszarów zwykle nie są ani klasyfikowane, ani śledzone.

Niezamierzone rozproszenie dostępu uprzywilejowanego. Uprawnienia administracyjne w narzędziach SaaS często powstają podczas migracji, integracji albo okresów wdrożeniowych i nigdy potem nie są przeglądane. Łączna liczba kont z jakąś formą podwyższonego dostępu jest zwykle większa, niż szacuje zespół bezpieczeństwa albo IT.