Kto naprawdę ma dostęp — i czy potrafisz to udowodnić?
Kto naprawdę ma dostęp — i czy potrafisz to udowodnić?
Mariusz Przybyła | 08.09.2026
Firma może mieć w miarę sprawny proces zakładania kont, może mieć wdrożone uwierzytelnianie wieloskładnikowe i dobrze skonfigurowany firewall, a mimo to nie potrafić odpowiedzieć na podstawowe pytanie: kto ma dostęp do jej kluczowych systemów, dlaczego go ma i czy nadal powinien go mieć? Podobny brak szybkiej i poprawnej odpowiedzi na tak zadane pytanie można będzie spotkać również w tych organizacjach, które mają uruchomione systemy klasy IDM, których wdrożenie skupiło się tylko na zarządzaniu podstawowymi dostępami. Problem zaczyna się tam, gdzie informacje o uprawnieniach nie nadążają za zmianami w organizacji.
Wyobraźmy sobie pracownika, który przeszedł z finansów do sprzedaży. Otrzymał dostęp do CRM i raportów handlowych, ale zachował rolę w systemie finansowym. Każde z uprawnień zostało kiedyś nadane zgodnie z procedurą. Nikt jednak nie sprawdził, czy po zmianie stanowiska nadal jest potrzebne.
Podobny mechanizm dotyczy administratora z dostępem rozszerzonym na czas zakończonego projektu, dostawcy po wygaśnięciu umowy czy konta serwisowego, którego właściciela trudno dziś wskazać. To hipotetyczne sytuacje, ale dobrze pokazują, jak ryzyko może narastać w codziennej pracy — nawet wtedy gdy nie mówimy o sytuacjach związanych z incydentami bezpieczeństwa.
Poprawne logowanie nie wyjaśnia zasadności dostępu
Uwierzytelnianie pomaga potwierdzić tożsamość użytkownika. Kontrola uprawnień określa, jakie operacje może on wykonać. Ocena, czy ten zakres nadal odpowiada jego obowiązkom, wymaga dodatkowo informacji o stanowisku, procesie biznesowym i znaczeniu zasobu.
Firewall może ograniczać ruch, a MFA utrudniać przejęcie konta. Same nie rozstrzygną jednak, czy pracownik powinien nadal zatwierdzać płatności albo przeglądać dokumenty działu, z którego odszedł. Nadmiarowy dostęp zwiększa zarówno możliwości nieuprawnionego działania, jak i potencjalne skutki przejęcia konta.
Dlatego kontrolę warto oprzeć na zasadzie najmniejszych uprawnień: przyznawać użytkownikom i procesom tylko taki dostęp, jakiego potrzebują do wykonywania zadań. Tak definiuje tę zasadę NIST. Jej stosowanie wymaga ponownej oceny uprawnień, gdy zadania się zmieniają.
Lista kont pokazuje tylko część obrazu
Informacje o dostępie mogą być rozproszone między Active Directory, Entra ID, ERP, aplikacjami SaaS i systemami rozwijanymi wewnętrznie. Konto domenowe nie musi ujawniać wszystkich ról w aplikacjach zintegrowanych z Active Direcotry, a członkostwo w grupie nie zawsze pokazuje pełny zakres wynikających z niego możliwości.
Potrzebne jest powiązanie osoby z jej kontami, kont z rolami i grupami, a tych z konkretnymi zasobami oraz procesami. Trzeba uwzględnić także nadania bezpośrednie, dziedziczenie i reguły właściwe dla aplikacji. W przypadku kont technicznych odpowiednikiem powiązania z pracownikiem jest wskazanie właściciela oraz obsługiwanego procesu lub systemu.
Ryzyko może pojawić się również na styku aplikacji. Możliwość zmiany danych rachunku kontrahenta w jednym systemie i samodzielnego zatwierdzenia jego płatności w drugim może naruszać przyjęty rozdział obowiązków, czyli SoD. Ocena zależy od procesu, zakresu transakcji i działających zabezpieczeń. Sama zbieżność nazw ról nie wystarcza do stwierdzenia konfliktu.
Wiarygodny obraz dostępu musi mieć określony zakres i datę aktualności. Raport z trzech aplikacji może być użyteczny, ale nie opisuje automatycznie całej organizacji. Brak danych z systemu trzeba pokazać jako lukę w widoczności. Podobnie brak informacji o użyciu uprawnienia nie jest dowodem, że nikt z niego nie korzystał.
NIS2 i KSC wzmacniają odpowiedzialność za kontrolę dostępu
Dyrektywa NIS2 wymienia politykę kontroli dostępu i zarządzanie aktywami wśród środków zarządzania ryzykiem w cyberbezpieczeństwie. Wskazuje również ocenę skuteczności tych środków, a organom zarządzającym przypisuje ich zatwierdzanie i nadzór nad wdrażaniem. Podstawą są art. 20 oraz art. 21 ust. 1 i ust. 2 lit. f oraz i NIS2.
W Polsce nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa weszła w życie 3 kwietnia 2026 r. Zmieniony art. 8 KSC przewiduje wdrożenie systemu zarządzania bezpieczeństwem informacji, obejmującego m.in. polityki kontroli dostępu, zarządzanie aktywami oraz ocenę skuteczności środków technicznych i organizacyjnych. Wynika to z ustawy z 23 stycznia 2026 r., Dz.U. 2026 poz. 252.
To istotny kontekst dla CISO, CIO i właścicieli procesów. Kontrola dostępu wymaga współpracy pomiędzy IT, które odtwarza stan techniczny i wykonuje zmiany, biznesem, który ocenia potrzebę dostępu, oraz osobami odpowiedzialnymi za bezpieczeństwo i ryzyko, które ustalają zasady oraz priorytety kontroli.
Zakres obowiązków trzeba ustalić dla konkretnego podmiotu. Przykładowo dla bankowości i infrastruktury rynków finansowych istotne są odrębności związane z DORA oraz art. 8i KSC. Sam przykład dotyczący procesu płatności nie oznacza jednak, że organizacja należy do sektora finansowego.
Przepisy nie wskazują jednego obowiązkowego produktu IAM ani konkretnego formatu raportu z przeglądu. Zakres środków powinien odpowiadać ryzyku i właściwym wymaganiom. Posiadanie narzędzia lub polityki jest więc dopiero częścią odpowiedzi — organizacja potrzebuje także informacji, czy przyjęte zasady działają w praktyce.
Wpis do wykazu nie potwierdza skuteczności zabezpieczeń
Dla podmiotów spełniających kryteria podmiotów kluczowych i ważnych data 3 października 2026 r. jest terminem złożenia wniosku o wpis do Wykazu KSC (jeżeli podlegają samo rejestracji). Część podmiotów wpisywana jest z urzędu. Zasadniczy okres dostosowawczy dla tej grupy kończy się 3 kwietnia 2027 r.; szczegóły zależą od statusu podmiotu i przepisów przejściowych. Ministerstwo Cyfryzacji opisuje te terminy i odrębności.
Rejestracja jest obowiązkiem formalnym. Nie potwierdza, że uprawnienia są uzasadnione, przeglądy skuteczne, a niepotrzebne dostępy rzeczywiście odebrane. Prace nad tymi mechanizmami warto prowadzić równolegle z przygotowaniami formalnymi. Po zakończeniu okresu dostosowawczego trzeba je nadal utrzymywać i doskonalić.
Zacznij od sprawdzenia tego, co już masz
Samo posiadanie IAM nie rozstrzyga o kompletności kontroli. System może dobrze obsługiwać nowe nadania uprawnień, a jednocześnie nie obejmować części starszych aplikacji, kont lokalnych lub zmian wykonywanych bezpośrednio przez administratorów. Warto sprawdzić, czy informacje w procesie centralnym odpowiadają stanowi w systemach źródłowych.
Dobrym początkiem jest wybór jednego krytycznego procesu i prześledzenie dostępu kilku reprezentatywnych tożsamości: pracownika po zmianie stanowiska, administratora oraz konta technicznego lub dostawcy. Dla każdej z nich ustalmy zakres uprawnień, aktualne uzasadnienie, osobę odpowiedzialną za decyzję i wynik ostatniej weryfikacji.
Takie ćwiczenie pomaga odróżnić brak danych od braku odpowiedzialności lub nieskutecznego odbierania dostępów. Każdy z tych problemów wymaga innego działania. Wspólna pozostaje potrzeba odpowiedzi, którą można sprawdzić: kto ma dostęp, do czego i na jakiej podstawie?
Sprawdź swoją organizację w siedmiu pytaniach
W kolejnym artykule z serii „KTO MA DOSTĘP?” zamieniamy ten problem w praktyczny test. Każdemu pytaniu towarzyszy przykład informacji lub dowodu, który pozwala ocenić stan kontroli.
Przeczytaj: „7 pytań o uprawnienia, na które warto umieć odpowiedzieć przed audytem”.
Zapraszamy również do rejestracji na webinar poświęcony omawianej tematyce:
Czy naprawdę wiesz, kto ma dostęp do czego?
Tekst autora, napisany przy wsparciu AI, następnie przez niego zweryfikowany i zredagowany. Grafika wygenerowana przez AI.