Jak skutecznie przeprowadzić audyt podziału obowiązków w systemie SAP?

Po co przeprowadzać audyt uprawnień? To jedno kluczowe pytanie nigdy nie traci na aktualności: kto ma dostęp do jakich danych w systemie SAP?

Przeglądy uprawnień SAP pomagają odpowiedzieć na kluczowe pytanie: w jakim stopniu role i transakcje przypisane użytkownikowi w systemie odzwierciedlają jego rzeczywiste obowiązki? Nie jest to łatwe zadanie, ponieważ w praktyce często trudno jest precyzyjnie określić, za co naprawdę odpowiada pracownik, zwłaszcza że jego rola i obowiązki z czasem ulegają zmianom.

Aby uprościć proces wdrażania nowych pracowników, organizacje często kopiują uprawnienia od innego użytkownika. Chociaż praktyka ta przyspiesza przyznawanie dostępu, powoduje również utratę kontroli nad tym, kto ma dostęp do czego, szczególnie gdy struktura uprawnień w systemie jest złożona, a użytkownicy otrzymują dziesiątki, a nawet setki ról jednocześnie. Z czasem struktura dostępu staje się nieczytelna i trudna do zarządzania. W tym momencie pojawia się potrzeba przeprowadzenia przeglądu uprawnień, którego celem jest weryfikacja często nieprawidłowo przypisanych uprawnień.

W tym momencie do akcji wkraczają audytorzy.

Brak kontroli dostępu najczęściej wychodzi na jaw podczas codziennych operacji — na przykład, gdy okazuje się, że pracownik opublikował dokument w firmie, do której nie jest formalnie przypisany, lub przeniósł towary między zakładami bez odpowiedniego upoważnienia. Chociaż takie incydenty są zazwyczaj szybko korygowane, rzadko stają się one impulsem do głębszych zmian. Panuje powszechne przekonanie, że lepiej jest mieć „za dużo niż za mało” uprawnień, a potrzeba zapewnienia wsparcia często przeważa nad zasadą minimalizacji dostępu.

Audytorzy finansowi postrzegają jednak tę kwestię inaczej — przez pryzmat zasady minimalnych uprawnień, zgodnie z którą użytkownicy powinni mieć dostęp tylko do funkcji niezbędnych do wykonywania swojej pracy.

Z punktu widzenia audytu finansowego celem jest potwierdzenie, że dane generowane w systemie ERP (np. SAP) są wiarygodne i że dostęp do funkcji mających wpływ na wyniki finansowe nie został przyznany osobom nieuprawnionym. Audytorzy oceniają zgodność z zasadą podziału obowiązków (SoD) i sprawdzają dostęp do wrażliwych funkcji, takich jak realizacja płatności, edycja danych bankowych dostawców lub modyfikacja danych podstawowych klientów i dostawców. Dobrze przygotowana matryca SoD i lista krytycznych dostępów stanowią dla organizacji praktyczny punkt wyjścia do przeglądu oraz ramy do oceny aktualnych ról i uprawnień.

Dobrze przygotowana matryca SoD i lista krytycznych dostępów stanowią dla organizacji praktyczny punkt wyjścia do przeglądu oraz ramy do oceny aktualnych ról i uprawnień. Zamiast zadawać pytanie, jaki dostęp powinien mieć użytkownik (co wymaga analizy obowiązków, zadań i doświadczenia), znacznie łatwiej i szybciej jest określić, jakiego dostępu nie powinien mieć — zwłaszcza gdy audytor dostarcza gotową listę ryzyk i wrażliwych działań lub gdy taka lista najlepszych praktyk jest już dostępna w narzędziu do zarządzania ryzykiem dostępu (klasa GRC).

1. Audyt uprawnień przynosi również wymierne korzyści biznesowe:

• Lepsze zrozumienie procesów i obowiązków – pomaga wyjaśnić, kto jest za co odpowiedzialny i gdzie mogą występować „szare strefy” w procesie podejmowania decyzji.
• Zwiększone bezpieczeństwo operacyjne – ograniczenie nadmiernego dostępu jest jedną z najprostszych i najskuteczniejszych form zapobiegania.
• Przygotowanie do zmian – dobrze zorganizowane uprawnienia znacznie ułatwiają migracje, aktualizacje i przejście do środowisk chmurowych.
• Zmniejszone ryzyko błędów i nadużyć dzięki wyeliminowaniu konfliktów ról i krytycznych kombinacji dostępu.
• Wsparcie dla audytów wewnętrznych i zewnętrznych – przejrzyste raporty i czytelna matryca ryzyka znacznie przyspieszają procesy kontrolne.

Ważne jest to, że większość organizacji nie ma czasu na przemyślenie modelu autoryzacji podczas wdrażania systemu ERP. Najważniejsze są zazwyczaj testy, dane podstawowe, harmonogram i samo uruchomienie systemu. Prawa dostępu są często ustalane w ostatniej chwili – zazwyczaj poprzez kopiowanie użytkowników lub ról – bez analizy rzeczywistych potrzeb i ryzyka. W rezultacie system może działać poprawnie z punktu widzenia procesów, ale pozostawia zbyt wiele luk w zakresie bezpieczeństwa i kontroli.

Dlatego warto przeprowadzić audyt uprawnień po stabilizacji, jako świadomy krok w kierunku uporządkowania dostępu i poprawy dojrzałości organizacji w zakresie bezpieczeństwa i zgodności z przepisami.

Jak przeprowadzić audyt dostępu do systemu SAP w praktyce.

Teraz, gdy rozumiemy, dlaczego audyt dostępu jest ważny i jakie korzyści przynosi, logiczne jest pytanie: jak przeprowadzić go w praktyce? Organizacje mają kilka możliwości – od ręcznej analizy tabel systemu SAP po wykorzystanie różnych narzędzi wspierających ocenę ryzyka SoD. Wybór zależy od kilku czynników, takich jak:

• liczba użytkowników i złożoność środowiska IT (np. czy jest ono oparte głównie na SAP, czy obejmuje systemy specyficzne dla danej dziedziny), ręczne przeprowadzenie audytu ponad 100 użytkowników jest prawie niemożliwe do wykonania w sposób kompletny i dokładny
• zasoby i kompetencje zespołu wewnętrznego, specjaliści techniczni zaczną od SUIM w SAP i podzielą się wynikami, które są trudne do zrozumienia dla zespołów biznesowych
• presja i oczekiwania audytorów wewnętrznych lub zewnętrznych dotyczące SoD i kontroli dostępu do danych wrażliwych,
• oraz to, czy audyt jest jednorazowym przeglądem, czy działaniem cyklicznym.

Wiele organizacji zaczyna od pobrania raportów SUIM, eksportowania danych z tabel i ręcznej analizy w Excelu. Po tygodniach spędzonych na uzgadnianiu surowych danych systemowych często zwracają się do audytorów zewnętrznych o wskazówki – tylko po to, aby zdać sobie sprawę, że ich podejście było błędne od samego początku. Firmy audytorskie, zwłaszcza z Wielkiej Czwórki, oferują nie tylko zaawansowane narzędzia (takie jak ACE firmy PwC), ale także ustrukturyzowane metodologie skoncentrowane na ryzyku, kontekście biznesowym i powtarzalności. Nie poprzestają one jednak na identyfikacji ryzyka. Po wykryciu konfliktu podziału obowiązków audytorzy drążą temat, pytając, czy dostęp został wykorzystany, czy ryzyko się zmaterializowało oraz jakie dane zostały zmienione lub dotknięte zmianami. Udowodnienie, że szeroki dostęp do krytycznych zasobów nie został nadużyty, może być czasochłonnym i wymagającym dużych nakładów zadaniem, zwłaszcza jeśli nie ma systemu śledzenia użytkowania lub kontekstowej ścieżki audytu. Dlatego prawdziwa siła nie leży tylko w narzędziu, ale w połączeniu odpowiedniej technologii z odpowiednią metodologią, zaczynając od ryzyka i potrzeb biznesowych, a nie od surowych transakcji lub list transakcji z dostępem krytycznym.

Wielu informatyków uważa, że wdrożenie narzędzia GRC automatycznie rozwiąże ich problemy związane z zarządzaniem dostępem. Jest to jednak klasyczna pułapka: jeśli problem nie został jasno zdefiniowany, narzędzie nie rozwiąże go. Prawdziwe pytanie często nie brzmi: „Czy brakuje nam narzędzia GRC?”, ale raczej: „Czy naprawdę rozumiemy, kto ma dostęp do czego i dlaczego?”. Bez tej jasności nawet najlepsze rozwiązanie nie przyniesie znaczących rezultatów. Dobrze znanym rozwiązaniem w tej dziedzinie jest SAP GRC Access Control 12.0 (dla środowisk lokalnych). SAP oferuje również wersję opartą na chmurze – SAP IAG – która obsługuje zarówno systemy lokalne (za pośrednictwem SAP Connector), jak i natywne dla chmury (np. SuccessFactors).

GRC Hack #2

Wdrożenie SAP GRC Access Control na miejscu zajmuje zazwyczaj od 3 do 6 miesięcy. Jeśli czas ma kluczowe znaczenie, wersja IAG oparta na chmurze może zapewnić szybsze wdrożenie — można też rozważyć alternatywne rozwiązania SaaS.

W rzeczywistości alternatywne rozwiązania kontroli dostępu stają się coraz bardziej popularne — zwłaszcza te, które koncentrują się na elastyczności, integracji z systemami innymi niż SAP, szybszym wdrożeniu i uproszczonej konserwacji. Jednym z przykładów jest smartGRC , dostępny zarówno w modelu lokalnym, jak i w chmurze, który może zapewnić pierwsze wyniki już w ciągu 1 miesiąca.

Czy jednorazowa usługa audytu jest alternatywą dla systemu GRC?

Kierownictwo często zadaje pytanie:„Czy naprawdę potrzebuję pełnego systemu GRC, aby zrozumieć, kto ma dostęp do czego?”

Istnieją dwa główne podejścia:

• Jednorazowy audyt przeprowadzony przez firmę zewnętrzną – szybki, ekonomiczny i przydatny do uzyskania aktualnego obrazu sytuacji (np. przed przeglądem finansowym).
• Wdrożenie systemu GRC – idealne rozwiązanie dla organizacji wymagających ciągłej kontroli, niezależności i skalowalności.

GRC Hack #3

Jednorazowy audyt to tylko migawka. W dynamicznych środowiskach SAP ryzyko związane z dostępem zmienia się nieustannie. Bez ciągłego nadzoru konieczne staje się powtarzanie audytów.

Jeśli częste audyty nie są konieczne, outsourcing może nadal być najlepszym rozwiązaniem. Jednak dla organizacji poszukujących elastyczności lean GRC solutions oferują opłacalny kompromis — zwłaszcza gdy w zakresie audytu znajdują się również systemy inne niż SAP, które zazwyczaj wymagają więcej czasu na przygotowanie i przeprowadzenie przeglądu podziału obowiązków.

Plan działania — przeprowadzenie audytu uprawnień SAP — od czego zacząć?

Rozpoczęcie audytu uprawnień SAP od identyfikacji kodów transakcji (t-kodów) jest częstym błędem, zwłaszcza wśród zespołów technicznych. Podejście to pomija kluczowy pierwszy krok: zrozumienie procesów biznesowych, ról i ryzyk, które determinują wymagania dotyczące dostępu. Bez tego kontekstu analiza t-kodów przypomina mapowanie miasta na podstawie samych latarni – jest technicznie precyzyjna, ale strategicznie ślepa.

GRC Hack #4

Nie zaczynaj od kodów t! Zacznij od procesów biznesowych i obszarów ryzyka – dopiero potem przypisz je do transakcji. Przejście od razu do kwestii technicznych powoduje utratę szerszej perspektywy.

2. Opracowanie macierzy podziału obowiązków (SoD) i listy wrażliwych dostępów

To podstawa każdego przeglądu kontroli dostępu. Na tym etapie organizacja identyfikuje procesy biznesowe narażone na potencjalne naruszenia i określa konflikty podziału obowiązków (SoD) — np. księgowanie wpisu do dziennika i zatwierdzanie płatności. Zespół projektowy wraz z właścicielami obszarów biznesowych określa listę tzw. działań biznesowych, które mogą wystąpić w ramach tego samego procesu. Każdemu ryzyku przypisuje się poziom ważności — np. niski, średni, wysoki. Każde narzędzie klasy GRC zapewnia taką funkcjonalność, ale warto zwrócić uwagę na kilka niuansów.

GRC Hack #5

Największym wyzwaniem przy tworzeniu macierzy SoD jest zapewnienie wspólnego zrozumienia definicji ryzyka w całej firmie. Bez tego dyskusja nie ma rzeczywistej wartości. Na rynku dostępne są już rozwiązania, takie jak smartGRC, które umożliwiają integrację sztucznej inteligencji, wspierają użytkowników, sugerując ryzykowne kombinacje działań, pokazując przykłady materializacji ryzyka i wskazując konkretne transakcje SAP lub aplikacje Fiori. Skraca to czas warsztatów i poprawia jakość macierzy.

2. Techniczne zmapowanie matrycy SoD

Po sfinalizowaniu i uzgodnieniu z biznesem macierzy ryzyka SoD oraz listy wrażliwych dostępów, kolejnym krokiem jest techniczne odwzorowanie ich w systemie GRC. Jest to moment, w którym ryzyka na poziomie procesów przekładają się na rzeczywiste uprawnienia w systemach IT — najczęściej w SAP.

Na tym etapie każda działalność biznesowa jest przypisana do określonego zestawu transakcji SAP, aplikacji Fiori lub innych elementów technicznych (np. programów, raportów, funkcji). Następnie tworzone są relacje między transakcjami a obiektami autoryzacji – elementami systemu SAP, które kontrolują zakres dostępu użytkownika.

Dla każdej pary działań biznesowych definiowane są warunki konfliktu – na przykład, czy użytkownik ma dostęp zarówno do tworzenia, jak i zatwierdzania dokumentu. Wynikiem jest kompletny zbiór zasad zawierający odwzorowane definicje techniczne działań i reguły konfliktu.

GRC Hack #6

Na tym etapie warto skorzystać z narzędzia, które pozwala łatwo mapować systemy wykraczające poza SAP S/4HANA. Na przykład SmartGRC (smartgrc.eu) umożliwia tworzenie definicji technicznych w formacie XML przy użyciu struktury złożonej i atomowej, co pozwala na modelowanie dowolnej koncepcji autoryzacji. System automatycznie sprawdza poprawność importu i zaznacza problemy, takie jak brakujące atomy w rolach złożonych lub atomy przypisane do nieistniejących użytkowników. Przyspiesza to nie tylko wdrożenie, ale także pomaga poprawić jakość koncepcji autoryzacji w systemie źródłowym.

3. Sporządź raporty dotyczące salda otwarcia.

Jest to etap, na którym system analizuje rzeczywiste uprawnienia użytkowników i identyfikuje miejsca występowania ryzyka SoD i wrażliwych dostępów. Raporty uwzględniają poziomy organizacyjne — na przykład, czy konflikt występuje w ramach tego samego kodu firmy.

W zależności od narzędzia raport może zawierać tysiące wpisów, dlatego kluczowe znaczenie mają przejrzystość, filtrowanie i agregacja wyników. Bardziej zaawansowane rozwiązania oferują również analizę trendów w czasie, umożliwiając organizacjom ocenę, czy sytuacja ulega poprawie, czy pogorszeniu. Dane są zazwyczaj prezentowane w intuicyjnych pulpitach nawigacyjnych.

GRC Hack #7

Cenne jest, gdy raport pokazuje rzeczywiste wykorzystanie transakcji i aplikacji Fiori powiązanych z ryzykiem — pomaga to określić, czy ryzyko jest tylko teoretyczne, czy aktywne, co oznacza, że jest wykorzystywane przez użytkownika w codziennych operacjach.

GRC Hack #8

Jeszcze lepiej, jeśli raport nie jest tylko „statyczną listą”, ale interaktywną listą zadań — umożliwiającą takie działania, jak przypisywanie elementów właścicielom biznesowym, dodawanie środków ograniczających ryzyko lub przekazywanie ich do zatwierdzenia lub usunięcia dostępu.

4. Opracuj plan naprawczy.

Jest to etap, na którym na podstawie raportu podejmowane są konkretne decyzje. Zespół ds. bezpieczeństwa lub właściciele procesów określają:

• które uprawnienia należy cofnąć,
• które działania należy zablokować lub zreorganizować
• oraz jakie zmiany należy wprowadzić w rolach użytkowników.

Na tej podstawie tworzona jest specyfikacja techniczna dla administratorów systemu — zawierająca listę transakcji, ról i użytkowników, którzy wymagają aktualizacji. W zależności od narzędzia, zalecenia mogą być przygotowane hurtowo lub wymagać analizy indywidualnej.

GRC Hack #9

Jest to krytyczny etap całego projektu — warto z wyprzedzeniem przeznaczyć na niego odpowiednią ilość czasu i zasoby. Przed cofnięciem dostępu poszczególnym użytkownikom lepiej najpierw udoskonalić role i ogólny model autoryzacji — dzięki temu zmiany będą bardziej trwałe, logiczne i łatwiejsze do utrzymania w przyszłości.

5. Monitoruj bieżące ryzyko.

Audyt dostępu nie kończy się na jednorazowej analizie — ryzyko należy monitorować w sposób ciągły. Po wdrożeniu zmian ważne jest, aby:

• regularnie przeglądać nowe uprawnienia i zmiany ról,
• wykrywać nowe konflikty i aktywność użytkowników w newralgicznych obszarach,
• oraz analizować trendy — czy liczba zagrożeń rośnie, maleje czy pozostaje na stałym poziomie?

Bardziej zaawansowane narzędzia umożliwiają planowanie powtarzających się analiz, automatyzację raportowania i automatyczne powiadomienia dla właścicieli procesów.
Jest to również etap, na którym wdrożenie narzędzia GRC zapewnia największy zwrot z inwestycji — umożliwiając ciągłą kontrolę bez konieczności powtarzania ręcznych audytów, co pozwala zaoszczędzić czas i zasoby.

GRC Hack #10

Największą wartość zapewnia ciągła kontrola — zamiast przeprowadzać audyty raz w roku, znacznie skuteczniejsze jest monitorowanie ryzyka co kwartał lub co miesiąc. System GRC umożliwia planowanie powtarzających się analiz i wizualizację ryzyka w czasie, pomagając ocenić, czy działania naprawcze faktycznie przynoszą rezultaty.

Audyt uprawnień SAP jest kluczowym etapem zapewnienia zgodności, bezpieczeństwa i integralności danych finansowych. Niezależnie od tego, czy jesteś audytorem, właścicielem procesu, czy specjalistą IT, przejście przez pięć kluczowych etapów audytu zapewnia jasny obraz struktury dostępu w organizacji:

1. Zdefiniowanie macierzy SoD i listy wrażliwych dostępów
2. Mapowanie do systemu (mapowanie techniczne)
3. Wykonanie raportu salda otwarcia
4. Sformułowanie konkretnych zaleceń
5. Monitorowanie ryzyka w czasie

Narzędzia GRC umożliwiają organizacjom szybsze, tańsze i bardziej efektywne wdrażanie audytów przy zachowaniu wysokich standardów kontroli i zgodności. Nie musisz być „uwięziony” w jednym narzędziu. Istnieją alternatywne rozwiązania, które warto rozważyć — zwłaszcza gdy liczy się czas, elastyczność i budżet.

Wybór podejścia i narzędzia GRC ma znaczący wpływ na skuteczność każdego etapu. Kompleksowe, ale często skomplikowane w utrzymaniu rozwiązania (takie jak SAP GRC Access Control) mogą przytłoczyć projekt technicznymi zawiłościami. Tymczasem alternatywne rozwiązania, takie jak SmartGRC, koncentrują się na prostocie, przejrzystości i współpracy z użytkownikami biznesowymi. Dzięki takim funkcjom, jak:

• Szybkie wdrożenie i przyjazny dla użytkownika interfejs
• Integracja z OpenAI
• Obsługa systemów innych niż SAP poprzez XML
• Aktywne raporty i analiza trendów

Podsumowanie.

Narzędzia GRC mogą pomóc nie tylko w monitorowaniu ryzyka, ale także w przepływie pracy związanym z przyznawaniem dostępu i projektowaniem ról — jednak ich skuteczność zależy od zawartości, na której się opierają. Dlatego tak ważne jest, aby w pierwszej kolejności stworzyć jasną i dobrze zorganizowaną matrycę SoD oraz definicje ryzyka. Bez solidnej treści nawet najlepsze narzędzie nie przyniesie oczekiwanych korzyści.