Kto ma dostęp do Twoich danych i systemów?
Zarządzanie tożsamością i dostępem (IAM) to jeden z fundamentów bezpieczeństwa operacyjnego.
Bez kontroli nad tym, kto ma dostęp do czego, każda inna inicjatywa bezpieczeństwa budowana jest na niepewnym gruncie.
Średni czas wykrycia nieautoryzowanego dostępu to 197 dni. (IBM)
byłych pracowników zachowuje dostęp do co najmniej jednej aplikacji firmowej po odejściu
Beyond Identity
średni czas w dniach do wykrycia nieautoryzowanego dostępu
IBM Cost of a Data Breach
naruszeń bezpieczeństwa wiąże się z przejętymi poświadczeniami
Verizon DBIR
Identity & Access Management - co się pod tym kryje?
Zarządzanie tożsamością i dostępem to zestaw procesów i narzędzi, które odpowiadają na jedno fundamentalne pytanie:
→ kto ma dostęp, do czego, dlaczego i czy wciąż powinien.
W praktyce IAM obejmuje cały cykl życia konta w organizacji: od momentu, gdy nowa osoba dołącza do firmy i dostaje dostęp do systemów, przez każdą zmianę roli w trakcie zatrudnienia, aż do dnia odejścia, kiedy te dostępy powinny zostać cofnięte.
Obejmuje też dostępy, które nie należą do konkretnych osób: konta serwisowe, tokeny API, uprawnienia aplikacji.
IAM nie jest jednym narzędziem. To domena złożona z procesów, polityk i technologii, które razem tworzą kontrolę nad tym, kto może co zrobić w środowisku IT organizacji.
Dlaczego tożsamość staje się problemem dopiero przy pewnej skali?
Mniejsze firmy zwykle radzą sobie z dostępami intuicyjnie. IT zna każdego i wie, kto czego używa, offboarding robi jedna osoba w ciągu godziny, a lista aplikacji mieści się w głowie.
W firmach 100+ to przestaje działać, gdyż skala zmienia mechanikę problemu. Zespoły pracują między sobą, rotacja jest większa, przestajesz kojarzyć nowych pracowników, a część z nich pracuje tylko zdalnie.
To jest moment, w którym firmy zaczynają rozmawiać o IAM nie jako o projekcie bezpieczeństwa, ale jako o podstawowej higienie operacyjnej.
Liczba systemów rośnie nieliniowo
Firma 50-osobowa używa szacunkowo kilkudziesięciu aplikacji. Firma 200-osobowa, szczególnie jeśli ma kilka działów z różnymi potrzebami, używa wielokrotnie więcej. Każda aplikacja to osobny model dostępu, osobna lista użytkowników, osobne uprawnienia do zarządzania
Rotacja rośnie
Im więcej ludzi, tym więcej zmian: awanse, zmiany działów, odejścia, kontrahenci na czas określony. Każda zmiana powinna pociągać za sobą aktualizację uprawnień. W praktyce to często nie następuje, bo nikt nie ma czasu, bo procedura nie jest jednoznaczna, albo system, w którym trzeba coś zmienić, nie jest podłączony do centralnego katalogu.
Odpowiedzialność jest rozmyta
W małej firmie offboarding robi konkretna osoba. W firmie 100+ HR zamyka konto w systemie kadrowym, IT zamyka konto w Active Directory, a za aplikacje SaaS, repozytoria na GitHubie i konto w narzędziu do analityki odpowiada każdy i nikt.
Historyczne decyzje kumulują się
Każde konto, które nie zostało zamknięte w odpowiednim momencie, każde uprawnienie nadane "tymczasowo" i każdy token wygenerowany do projektu, który się skończył, zostaje w systemie. Po trzech latach takich decyzji masz środowisko, którego nie da się zrozumieć bez narzędzia, które je zmapuje.
Ryzyka w obszarze zarządzania tożsamością i dostępem
Każde z poniższych to kategoria ryzyka, która pojawia się systematycznie w środowiskach firm zatrudniających powyżej 100 pracowników. Nie wszystkie dotyczą każdej organizacji w tym samym stopniu, ale wszystkie z nich warto rozumieć
Współdzielone konta administratora
Współdzielone hasła administratora to sytuacja, w której kilka osób używa tego samego konta z szerokimi uprawnieniami. Powody są praktyczne: szybszy dostęp, brak narzędzia do zarządzania uprzywilejowanym dostępem, tradycja z czasów gdy firma była mniejsza.
Konsekwencja jest prosta: jeśli coś się dzieje, nie wiesz kto to zrobił. Jeśli jedna z osób z dostępem do tego konta odchodzi, jedynym sposobem na zabezpieczenie jest zmiana hasła. I nadzieja, że nikt go sobie nie zanotował.
Niewdrożone uwierzytelnianie
Multi-factor authentication (MFA) to jedna z najbardziej efektywnych kontroli w obszarze IAM. Badania Microsoft wskazują, że MFA blokuje ponad 99,9% zautomatyzowanych ataków na konta.
Mimo to w wielu środowiskach mid-market MFA wdrożone jest niekonsekwentnie: obowiązuje dla poczty, ale nie dla VPN; jest włączone dla pracowników, ale nie dla kont serwisowych; wymaga się go od nowych pracowników, ale starsi konfigurację mają z przed lat i nikt jej nie weryfikuje.
Konta administratorów bez MFA to najwyższe uprawnienia w środowisku chronione jedynie hasłem.
Brak weryfikacji uprawnień
Access review to cykliczny przegląd uprawnień, w którym właściciel zasobu potwierdza, że każda osoba z dostępem wciąż powinna go mieć. To podstawowy mechanizm, który pozwala wykrywać i eliminować uprawnienia, które narosły przez dłuższy czas.
W firmach bez formalnych access reviews uprawnienia są dodawane, gdy są potrzebne, i rzadko są cofane, gdy potrzeba mija. Po roku środowisko zawiera setki decyzji dostępowych, których nikt nie weryfikował.
Regularne weryfikacje są też wymagane przez większość standardów bezpieczeństwa: SOC 2, ISO 27001, NIS2 i DORA. Każdy z tych standardów wymaga, by organizacja potrafiła wykazać, że dostępy są weryfikowane.
Dostępy zewnętrznych kontraktorów
Kontrahenci, freelancerzy, firmy zewnętrzne i agencje regularnie dostają dostęp do systemów wewnętrznych na czas projektu. Problem polega na tym, że "czas projektu" jest rozumiany różnie: przez IT, przez menedżera projektu i przez samego kontrahenta.
Gdy projekt się kończy, dostępy kontrahenta często zostają. Bez formalnego procesu, który wiązałby dostęp z datą końca kontraktu, żaden system nie wie, że ten dostęp powinien wygasnąć.
Zmiany ról bez zmiany uprawnień
Zmiana roli to jeden z bardziej pomijanych momentów w cyklu życia pracownika w systemach. Ktoś awansuje z analityka na menedżera, dostaje nowe uprawnienia do nowych systemów, ale stare zostają.
Ktoś przechodzi z działu sprzedaży do marketingu, dostaje dostęp do nowych narzędzi, ale CRM, do którego miał dostęp wcześniej, wciąż widzi jego konto i daje dostęp do pełnej bazy klientów.
Kumulacja uprawnień przy zmianach ról to jeden z głównych mechanizmów, przez które konta z czasem mają znacznie więcej dostępów niż powinny.
Broken Joiner-Mover-Leaver
Joiner-Mover-Leaver (JML) to trzy kluczowe momenty w cyklu życia pracownika w systemach IT: dołączenie, zmiana roli i odejście. Jeśli którykolwiek z tych momentów nie jest obsługiwany automatycznie lub przynajmniej procesowo, środowisko zaczyna akumulować błędy.
Nowy pracownik dostaje dostępy na podstawie tego, co miał poprzednik na tym stanowisku, bez weryfikacji czy tamte dostępy były adekwatne. Ktoś zmienia dział i dostaje nowe uprawnienia, ale stare zostają. Ktoś odchodzi i konto w głównym katalogu jest zamknięte, ale aplikacje SaaS, repo, narzędzia projektowe i tokeny API nie wiedzą, że ta osoba już nie pracuje.
W środowiskach bez automatyzacji JML każdy z tych momentów opiera się na ręcznych checkllistach. Checkllisty pomijają appki, które ktoś dodał do projektu dwa miesiące temu. I nikt o tym nie wie, dopóki ktoś nie sprawdzi.
Nadmiarowe uprawnienia
Nadmiarowe uprawnienia narastają powoli i niepostrzeżenie. Ktoś dostaje dostęp administratora "żeby szybciej rozwiązać problem". Projekt się kończy, ale dostęp zostaje. Ktoś prosi o podniesienie uprawnień do folderu, bo był pilny termin, i nikt nie cofa tej zmiany, gdy termin mija.
Zasada least privilege, czyli nadawanie tylko tych uprawnień, które są niezbędne do wykonania konkretnej pracy, jest powszechnie znana. Trudność w jej stosowaniu w większych firmach polega na tym, że bez narzędzia do zarządzania widocznością nie mamy informacji, kto faktycznie ma jakie uprawnienia w każdej z dziesiątek aplikacji.
Konta serwisowe bez przeglądu
Konta serwisowe to konta techniczne, które nie należą do konkretnego człowieka: konta używane przez aplikacje do komunikacji między systemami, przez procesy automatyczne, przez integracje. W każdym środowisku jest ich więcej niż ktokolwiek szacuje.
Problem polega na tym, że konta serwisowe rzadko mają przypisanego właściciela, rzadko są uwzględnione w access reviews, a ich uprawnienia rzadko są weryfikowane. Często mają szerokie dostępy, które były potrzebne przy wdrożeniu, i które nikt nie zawęził, bo "działa, nie ruszać".
Identity Sprawl / Rozproszenie tożsamości
Identity sprawl to sytuacja, w której ta sama osoba ma wiele kont w różnych systemach, bez centralnej koordynacji. Jedno konto w Google Workspace, jedno w Azure AD, jedno w narzędziu do projektów, jedno w każdym SaaS, do którego nie ma SSO.
Rozproszenie sprawia, że nie ma jednego miejsca, w którym możesz zobaczyć pełny obraz: co ta osoba ma, w jakich systemach, z jakimi uprawnieniami. Offboarding staje się bardzo trudny, bo nie ma kompletnej listy, a access review staje się niemożliwy, bo nie wiesz, gdzie szukać.
Klucze API bez rotacji
Klucze API i tokeny serwisowe to długożyjące poświadczenia, które dają dostęp do systemów bez logowania i bez MFA. W środowiskach, gdzie nie ma formalnego procesu rotacji, klucze generowane są raz i działają latami.
Jeśli taki klucz wycieknie, na przykład przez przypadkowy commit do publicznego repozytorium, dostęp, który daje, pozostaje aktywny do momentu, gdy ktoś go ręcznie wycofa. W środowisku bez inwentaryzacji kluczy nikt nie wie, że trzeba coś wycofać.
Jak w praktyce wygląda kontrola nad tożsamościami?
Dobry IAM nie musi być skomplikowany, ale musi być konsekwentny w egzekwowaniu polityk dostępów oraz monitorowaniu całości środowiska
JML działa automatycznie lub jest sprocesowany
Nowy pracownik dostaje dostępy na podstawie swojej roli, nie historii poprzednika. Zmiana roli pociąga za sobą aktualizację uprawnień, nie tylko dodanie nowych. Offboarding wyłącza konto we wszystkich systemach, nie tylko w katalogu głównym.
Jest jeden centralny katalog tożsamości
Wszyscy pracownicy są uwierzytelniani przez jeden system (przykładowo Google Workspace lub M365), a dostęp do pozostałych aplikacji jest przyznawany przez SSO. Dzięki temu wyłączenie jednego konta oznacza wyłączenie dostępu wszędzie.
MFA jest obowiązkowe i konsekwentne
Uwierzytelnianie wieloskładnikowe dotyczy wszystkich kont, szczególnie tych z uprawnieniami administracyjnymi, a jego skonfigurowanie jest wymuszone do korzystania z konta.
Przegląd nadanych uprawnień odbywa się cyklicznie
Raz na kwartał lub raz na pół roku właściciele zasobów weryfikują, kto ma dostęp. Wyniki są udokumentowane, a cofanie dostępów po review jest procesem, nie jednorazowym projektem.
Konta serwisowe mają właściciela i są inwentaryzowane
Każdy token API, każde konto techniczne, każda integracja jest przypisana do właściciela, który odpowiada za jej przegląd,
Uprawnienia administracyjne są wydzielone i chronione
Nikt nie pracuje codziennie na koncie z uprawnieniami administratora. PAM i dedykowane konta administracyjne są standardem.
Żadne z powyższych nie wymaga drogiego narzędzia jako pierwszego kroku, ale wymaga posiadania pełnego obrazu tożsamości w organizacji.
Nie można zarządzać tym, czego się nie widzi.
Kiedy IAM trafia na agendę?
Firmy rzadko podejmują temat zarządzania tożsamością bez powodu. Zazwyczaj jest coś, co sprawia, że pytanie "kto ma dostęp do czego" staje się pilne.
Pewne sytuacje powtarzają się jednak regularnie
Odejście kluczowej osoby z IT
Gdy osoba, która "wiedziała wszystko o systemach", odchodzi, organizacja nagle zdaje sobie sprawę, że ta wiedza nie była nigdzie zapisana. Offboarding tej osoby staje się pierwszym testem tego, jak dobrze działa zarządzanie dostępami.
Audyt bezpieczeństwa lub due diligence
SOC 2, ISO 27001, audyt zewnętrzny, due diligence przed inwestycją lub przejęciem. Każdy z tych procesów wymaga wykazania, że dostępy są pod kontrolą i weryfikowane. To jeden z najczęstszych punktów niezgodności w audytach, stąd staje się to priorytetem.
Incydent lub niemal-incydent
Odkrycie, że konto byłego pracownika wciąż jest aktywne. Wyciek hasła i niemożność szybkiej oceny zakresu dostępu. Ktoś z zewnątrz prosi o hasło "bo musi coś sprawdzić".
Wzrost firmy pokazuje nieporadność ręcznego zarządzania
Przekroczenie pewnego progu liczby pracowników, wdrożenie nowego systemu ERP, przejście na pracę zdalną. Każda z tych zmian ujawnia, że ręczne zarządzanie dostępami nie skaluje się.
Wymagania klientów lub kontrahentów
Klienci, szczególnie korporacje i firmy podlegające regulacjom, coraz częściej wymagają wykazania kontroli nad dostępami jako warunku współpracy. Pytania o polityki bezpieczeństwa i access management stają się częścią procesu vendor assessment.
Wdrożenie regulacji
NIS2, DORA i wymagania sektorowe dla firm finansowych lub ochrony zdrowia. Każde z nich wymaga możliwości wykazania pełnej kontroli nad dostępami do systemów krytycznych i przetwarzanych danych.
Narzędzia, z którymi pracujemy w tym obszarze
Wybór narzędzia do zarządzania tożsamością zależy od skali, architektury i dojrzałości procesów w organizacji. Nie ma jednego właściwego. Są narzędzia adekwatne do konkretnego etapu.
Dlaczego tożsamość staje się problemem dopiero przy pewnej skali?
Mniejsze firmy zwykle radzą sobie z dostępami intuicyjnie. IT zna każdego i wie, kto czego używa, offboarding robi jedna osoba w ciągu godziny, a lista aplikacji mieści się w głowie.
W firmach 100+ to przestaje działać, gdyż skala zmienia mechanikę problemu. Zespoły pracują między sobą, rotacja jest większa, przestajesz kojarzyć nowych pracowników, a część z nich pracuje tylko zdalnie.
To jest moment, w którym firmy zaczynają rozmawiać o IAM nie jako o projekcie bezpieczeństwa, ale jako o podstawowej higienie operacyjnej.
Liczba systemów rośnie nieliniowo
Firma 50-osobowa używa szacunkowo kilkudziesięciu aplikacji. Firma 200-osobowa, szczególnie jeśli ma kilka działów z różnymi potrzebami, używa wielokrotnie więcej. Każda aplikacja to osobny model dostępu, osobna lista użytkowników, osobne uprawnienia do zarządzania
Rotacja rośnie
Im więcej ludzi, tym więcej zmian: awanse, zmiany działów, odejścia, kontrahenci na czas określony. Każda zmiana powinna pociągać za sobą aktualizację uprawnień. W praktyce to często nie następuje, bo nikt nie ma czasu, bo procedura nie jest jednoznaczna, albo system, w którym trzeba coś zmienić, nie jest podłączony do centralnego katalogu.
Odpowiedzialność jest rozmyta
W małej firmie offboarding robi konkretna osoba. W firmie 100+ HR zamyka konto w systemie kadrowym, IT zamyka konto w Active Directory, a za aplikacje SaaS, repozytoria na GitHubie i konto w narzędziu do analityki odpowiada każdy i nikt.
Historyczne decyzje kumulują się
Każde konto, które nie zostało zamknięte w odpowiednim momencie, każde uprawnienie nadane "tymczasowo" i każdy token wygenerowany do projektu, który się skończył, zostaje w systemie. Po trzech latach takich decyzji masz środowisko, którego nie da się zrozumieć bez narzędzia, które je zmapuje.
Jak możemy pomóc
Jeśli tematyka tej strony jest bliska temu, co widzisz w swoim środowisku, to są dwa miejsca, od których warto zacząć.
Audyt tożsamości i dostępów →
14-dniowy audyt kończący się pełnym raportem. Mapujemy każde konto, każdy OAuth grant i każde uprawnienie w trybie read-only. Bez zmian w środowisku. Po audycie wiesz dokładnie, co masz i co wymaga uwagi.
Dobór i wdrożenie IAM →
Doradztwo w doborze narzędzia, projekt architektury i pełne wdrożenie. Od JML przez SSO i MFA po access reviews i IGA dla firm z bardziej zaawansowanymi wymaganiami governance oraz compliance.
Jeśli chcesz lepiej poznać ten obszar
You don't need to overhaul everything. Start with what you can see. Build from there
Zero Trust: A Modern Framework for Digital-First Companies
