Jeszcze kilka lat temu granica bezpieczeństwa przedsiębiorstwa przebiegała wzdłuż zapór sieciowych i serwerów proxy. Kto znajdował się „wewnątrz”, był traktowany jako godny zaufania. Kto „na zewnątrz” – jako potencjalne zagrożenie. Ten model zniknął bezpowrotnie.
W 2026 roku granicą stała się tożsamość. Każdy użytkownik, każde konto techniczne, każda integracja z systemem zewnętrznym to potencjalny wektor ataku. W ekosystemie SAP, gdzie przepływają najbardziej wrażliwe dane finansowe, kadrowe i operacyjne, ta zmiana ma fundamentalne znaczenie. Czy jesteśmy na nią gotowi?
Dlaczego tożsamość stała się główną powierzchnią ataku?
Odpowiedź jest prostsza, niż mogłoby się wydawać. Współczesne środowiska SAP to już nie izolowane systemy ukryte w firmowej serwerowni. To rozproszone ekosystemy łączące chmurę publiczną, rozwiązania hybrydowe, interfejsy API i dziesiątki aplikacji współpracujących poprzez SAP BTP. W takim świecie tradycyjna zapora sieciowa chroni niewiele.
Atakujący nie muszą już przełamywać zabezpieczeń technicznych. Wystarczy, że zdobędą dane uwierzytelniające jednego użytkownika z nadmiarowymi uprawnieniami. Wystarczy, że wykorzystają zapomniane konto techniczne, które powstało lata temu „na chwilę” i zostało na zawsze. Wystarczy, że przejmą sesję partnera biznesowego, który ma dostęp do produkcyjnego systemu SAP poprzez VPN.
Statystyki są nieubłagane. Według raportów branżowych ponad 80% incydentów bezpieczeństwa w środowiskach ERP wiąże się z niewłaściwym zarządzaniem dostępem lub kradzieżą poświadczeń. W świecie SAP, gdzie jedna transakcja może oznaczać przelew milionów złotych lub zmianę danych w centralnym rejestrze, konsekwencje są proporcjonalne do stawki.
Zero Trust – nie slogan, lecz zmiana myślenia
Koncepcja Zero Trust zakłada radykalną zmianę podejścia: nie ufamy nikomu i niczemu bez ciągłej weryfikacji. Nie wystarczy, że użytkownik zalogował się rano prawidłowym hasłem. Każde działanie, każde żądanie dostępu, każda transakcja wymaga ponownej oceny ryzyka.
W praktyce SAP oznacza to przejście od pytania „czy ten użytkownik ma przypisaną rolę?” do pytania „czy ten użytkownik, w tym momencie, z tego urządzenia, w tym kontekście biznesowym, powinien móc wykonać tę konkretną operację?”. To fundamentalna różnica.
„Zero Trust w środowisku SAP to nie projekt technologiczny z określonym końcem. To ciągły proces budowania kultury bezpieczeństwa, gdzie każdy dostęp jest uzasadniony, każde uprawnienie ma właściciela biznesowego, a każda anomalia wymaga wyjaśnienia” – podkreśla Jacek Bugajski ze SNOK .
Klasyczne role SAP a nowoczesne zarządzanie tożsamością
Wiele organizacji wciąż funkcjonuje w modelu, gdzie role SAP są definiowane raz, przypisywane użytkownikom i praktycznie nigdy nie weryfikowane. Procesy GRC istnieją na papierze, audyty odbywają się raz w roku i kończą się listą zaleceń, które trafiają do szuflady.
Tymczasem nowoczesne podejście do zarządzania tożsamością wymaga integracji kilku warstw. Po pierwsze – centralnego systemu IAM, który stanowi jedno źródło prawdy o wszystkich kontach w organizacji. Po drugie – mechanizmów automatycznej certyfikacji dostępu, gdzie właściciele biznesowi regularnie potwierdzają zasadność uprawnień swoich pracowników. Po trzecie – ciągłego monitorowania zachowań użytkowników i wykrywania anomalii.
Łączenie tych warstw z klasycznym modelem ról SAP nie jest trywialne. Wymaga przemyślenia architektury uprawnień od podstaw. Zamiast setek ról budowanych latami metodą prób i błędów, potrzebna jest przejrzysta struktura oparta na funkcjach biznesowych. Zamiast ręcznego przypisywania uprawnień – automatyzacja oparta na atrybutach użytkownika. Zamiast corocznego audytu – ciągła recertyfikacja.
Konkretne ryzyka, które widzimy u klientów
Doświadczenie pracy z polskimi przedsiębiorstwami pozwala nam wskazać kilka powtarzających się wzorców ryzyka.
Nadmiarowe uprawnienia to najpowszechniejszy problem. Użytkownicy zbierają role latami – przy zmianie stanowiska dostają nowe, ale stare pozostają. Po dekadzie pracy w organizacji niektórzy mają dostęp praktycznie do wszystkiego. Zasada najmniejszych uprawnień istnieje tylko teoretycznie.
Konta techniczne stanowią szczególne zagrożenie. Tworzone na potrzeby integracji, skryptów wsadowych czy interfejsów RFC, często mają uprawnienia znacznie przekraczające rzeczywiste potrzeby. Co gorsza – rzadko są objęte polityką rotacji haseł, a ich aktywność nie jest monitorowana.
Dostęp partnerów i konsultantów zewnętrznych to kolejny wektor ataku. Firmy regularnie udzielają dostępu do środowisk produkcyjnych podmiotom zewnętrznym, które realizują projekty wdrożeniowe lub świadczą wsparcie. Czy wiemy, kto konkretnie z firmy partnerskiej korzysta z tych kont? Czy dostęp jest odbierany natychmiast po zakończeniu współpracy?
Integracje systemów zewnętrznych mnożą się w tempie wykładniczym. Każde połączenie API, każdy interfejs z chmurą publiczną, każda wymiana danych z platformą e-commerce to potencjalna furtka. Czy mapujemy wszystkie te połączenia? Czy wiemy, jakie dane przepływają i w jakim kierunku?
Model uprawnień, który naprawdę działa
Budowanie skutecznego modelu zarządzania tożsamością w SAP wymaga podejścia etapowego. Nie da się zmienić wszystkiego od razu – ale można zacząć od fundamentów.
Pierwszym krokiem jest inwentaryzacja. Brzmi banalnie, ale zaskakująco wiele organizacji nie wie dokładnie, ile ma aktywnych kont w systemach SAP, ile z nich to konta techniczne, a ile należy do osób, które dawno opuściły firmę. Bez tej wiedzy dalsze działania są strzelaniem w ciemno.
Drugim krokiem jest analiza konfliktów uprawnień – w języku SAP nazywana segregacją obowiązków. Czy księgowy może jednocześnie tworzyć i zatwierdzać przelewy? Czy administrator IT ma dostęp do danych kadrowych? Identyfikacja krytycznych kombinacji uprawnień pozwala ustalić priorytety działań naprawczych.
Trzecim krokiem jest wdrożenie procesu recertyfikacji. Nie chodzi o formalne klikanie w okienka raz na kwartał. Chodzi o rzeczywiste zaangażowanie właścicieli biznesowych, którzy rozumieją, dlaczego ich pracownicy potrzebują określonych dostępów i potrafią uzasadnić tę potrzebę.
„Najskuteczniejsze wdrożenia Zero Trust w środowisku SAP łączą technologię z procesem. Można mieć najlepsze narzędzia do zarządzania tożsamością, ale bez jasno zdefiniowanych odpowiedzialności i regularnej weryfikacji dostępu pozostaną one niewykorzystane” – zauważa Jaroslaw Kamil Zdanowski ze SNOK.
Jak SNOK wspiera klientów w tej transformacji?
Nasz zespół specjalizuje się w projektowaniu i wdrażaniu modeli uprawnień dostosowanych do specyfiki każdej organizacji. Zaczynamy od warsztatu diagnostycznego, podczas którego mapujemy istniejący stan zarządzania dostępem, identyfikujemy krytyczne luki i ustalamy priorytety biznesowe.
Następnie projektujemy docelową architekturę uprawnień – nie na podstawie abstrakcyjnych najlepszych praktyk, lecz w oparciu o rzeczywiste procesy biznesowe klienta. Tworzymy matrycę ról, która jest zrozumiała dla właścicieli procesów i jednocześnie bezpieczna z perspektywy audytu.
Wspieramy wdrożenie procesów recertyfikacji, które nie są martwym dokumentem, lecz żywym mechanizmem zapewniającym ciągłą higienę dostępu. Integrujemy rozwiązania GRC z centralnymi systemami zarządzania tożsamością. Szkolimy zespoły klienta, aby były w stanie samodzielnie utrzymywać wypracowany model.
Co powinieneś zrobić od jutra?
Jeśli bezpieczeństwo SAP traktujesz poważnie, oto trzy działania, które możesz podjąć natychmiast.
Po pierwsze – zamów raport ze swojego systemu SAP pokazujący wszystkie konta, które nie logowały się od ponad 90 dni. Każde takie konto to potencjalne ryzyko, które można wyeliminować jednym kliknięciem.
Po drugie – zidentyfikuj wszystkie konta techniczne i sprawdź, kto jest ich właścicielem biznesowym. Jeśli nie możesz wskazać konkretnej osoby odpowiedzialnej za dane konto – masz problem, który wymaga pilnego rozwiązania.
Po trzecie – przeprowadź prosty test: wybierz losowo pięciu użytkowników i sprawdź, czy potrafisz uzasadnić każde z ich uprawnień aktualnym zakresem obowiązków. Jeśli nie potrafisz – masz materiał na pierwszy projekt optymalizacji.
Tożsamość jest nowym perimetrem. W świecie, gdzie granice sieci przestały istnieć, jedyną skuteczną linią obrony jest precyzyjne zarządzanie tym, kto, do czego i dlaczego ma dostęp. W ekosystemie SAP ta zasada ma znaczenie podwójne.
Masz pytania dotyczące zarządzania tożsamością i uprawnień w środowisku SAP? Chcesz przeprowadzić audyt bezpieczeństwa swojego systemu? Skontaktuj się z zespołem SNOK – pomożemy Ci zbudować model Zero Trust, który naprawdę działa.