Czy można wydać znaczący budżet na budowę modelu ról SAP w ramach wdrożenia S/4HANA, a mimo to po kilku miesiącach dowiedzieć się w audycie, że system uprawnień generuje tysiące konfliktów rozdziału obowiązków? Okazuje się, że tak – i nie jest to zjawisko odosobnione.
Opisywany przypadek dotyczy dużej organizacji działającej w sektorze usług logistycznych, w której system SAP stanowi istotne narzędzie obsługujące kluczowe procesy operacyjne i finansowe. W środowisku tej skali model ról i autoryzacji ma bezpośredni wpływ nie tylko na bezpieczeństwo danych, ale również na zgodność z zasadami kontroli wewnętrznej i wymaganiami audytowymi.
W pewnym momencie organizacja podjęła decyzję o wdrożeniu nowego systemu SAP S/4HANA i zbudowaniu modelu ról w systemie, w taki sposób, aby zapewnić bezpieczeństwo procesów biznesowych. Realizację projektu powierzono dostawcy wdrożenia S/4HANA w firmie z doświadczeniem we wdrożeniach SAP, jednak skupionej przede wszystkim na dostarczeniu funkcjonalności systemu.
Problem zaczął się już na etapie planowania projektu. Zakres projektu wdrożeniowego nie obejmował dedykowanych wymagań dotyczących modelu uprawnień ani zasad rozdziału obowiązków. Nie zdefiniowano oczekiwanego poziomu bezpieczeństwa, nie określono reguł SoD, które powinny być respektowane, ani nie ustalono, kto po stronie organizacji jest odpowiedzialny za zatwierdzenie modelu ról pod kątem kontroli wewnętrznej. Zabrakło również zaplanowanego podejścia do tematu uprawnień, zarówno po stronie klienta, jak i dostawcy. Dostawca wdrożenia skupił się na terminowej realizacji projektu i uruchomieniu systemu, natomiast kwestie modelu autoryzacji były traktowane jako element towarzyszący, a nie samodzielny obszar wymagający odrębnej metodologii. Po zakończeniu prac organizacja otrzymała nową strukturę ról biznesowych i technicznych, która zgodnie z założeniami projektu – miała stanowić stabilną podstawę zarządzania dostępami w systemie.
Przez pewien czas nic nie wskazywało na to, że rzeczywisty obraz sytuacji może wyglądać inaczej…
Weryfikacja – audyt uprawnień
Rzeczywista weryfikacja modelu ról nastąpiła dopiero w trakcie standardowego cyklu audytowego obejmującego kontrolę procesów finansowych i systemów IT. Podczas przeglądu uprawnień w systemie SAP audytorzy przeanalizowali zarówno strukturę ról, jak i przypisania uprawnień do użytkowników. Wyniki audytu okazały się dla organizacji dużym zaskoczeniem. Mimo niedawno zakończonego projektu budowy ról w systemie zidentyfikowano znaczną liczbę konfliktów rozdziału obowiązków (SoD) oraz nadmiarowych dostępów. W praktyce oznaczało to sytuacje, w których pojedynczy użytkownik mógł wykonywać w systemie czynności należące do różnych etapów tego samego procesu biznesowego jak na przykład wprowadzanie dokumentów finansowych, ich księgowanie oraz realizację płatności.
Wnioski audytu wskazywały, że problem nie dotyczy pojedynczych wyjątków czy kilku nieprawidłowych przypisań ról. Skala zidentyfikowanych niezgodności sugerowała, że źródło problemu może leżeć głębiej, czyli w samej konstrukcji modelu ról. W tej sytuacji organizacja zdecydowała się przeprowadzić pogłębioną analizę uprawnień, której celem było dokładne określenie skali problemu oraz identyfikacja jego przyczyn.
Analiza z wykorzystaniem dedykowanego narzędzia – smartGRC
Szczegółowa analiza została przeprowadzona z wykorzystaniem narzędzia smartGRC. W przeciwieństwie do standardowego przeglądu audytowego jej celem było nie tylko wskazanie konfliktów, lecz także dokładne zrozumienie, w jaki sposób powstały. Podstawą analizy była matryca SoD przygotowana i dostosowana do specyfiki procesów biznesowych organizacji. Dzięki temu możliwe było dokładniejsze odwzorowanie rzeczywistych czynności wykonywanych w systemie oraz powiązanie ich z konkretnymi ryzykami. Zakres analizy obejmował konflikty SoD w uprawnieniach użytkowników i rolach, dostępy krytyczne oraz faktyczne wykorzystanie nadanych funkcji w systemie.
Uzyskane wyniki pokazały skalę problemu.
W systemie zidentyfikowano ponad 10 000 konfliktów SoD w uprawnieniach użytkowników, z czego ok. 1/3 została określona jako konflikty o poziomie wysokim. Co więcej, niemal wszyscy użytkownicy objęci analizą posiadali przynajmniej jedno ryzyko SoD. Źródłem tak dużej liczby konfliktów SoD okazało się kilkadziesiąt ról, które już same w sobie zawierały ryzyka SoD, co zgodnie z dobrymi praktykami zupełnie nie powinno mieć miejsca. Analiza wykazała również wyraźną koncentrację ryzyk w określonych obszarach procesowych. Ponad 60% konfliktów dotyczyło procesów finansowych, takich jak księgowanie dokumentów, obsługa zobowiązań czy zarządzanie danymi podstawowymi. Jednocześnie okazało się, że znaczną część wszystkich konfliktów generowała stosunkowo niewielka liczba typowych scenariuszy biznesowych. Dziesięć najczęściej występujących ryzyk odpowiadało za blisko 60% wszystkich konfliktów SoD w systemie.
Analiza wykorzystania uprawnień pokazała dodatkowy problem – znaczna część nadanych dostępów nie była faktycznie wykorzystywana przez użytkowników. Około 80% dostępnych funkcji pozostawało nieużywanych w codziennej pracy.
Dodatkowym efektem ubocznym tak zaprojektowanego modelu ról były wyższe koszty licencyjne systemu SAP. Szeroki zakres uprawnień powodował, że wielu użytkowników posiadało dostęp do funkcji kwalifikujących się do wyższych kategorii licencyjnych, co przekładało się na zwiększone zużycie jednostek FUE i wyższe koszty utrzymania środowiska.
Zebrane dane prowadziły do jednoznacznego wniosku: problemy zidentyfikowane w audycie nie wynikały z pojedynczych błędów czy wyjątkowych przypisań ról do użytkowników. Ich źródłem była sama konstrukcja modelu ról.
Diagnoza i wnioski – gdzie leżał problem i jak go unikać?
Pogłębiona analiza modelu ról pokazała, że źródło problemu nie znajdowało się w pojedynczych przypisaniach ról do użytkowników ani w incydentalnych błędach administracyjnych. Konflikty SoD wynikały przede wszystkim z samej konstrukcji ról, a ta z kolei była skutkiem braku właściwej metodologii na etapie projektowania.
W wielu przypadkach role zostały zaprojektowane szeroko, tak aby obejmowały pełen zakres czynności wykonywanych w danym procesie biznesowym. W efekcie w jednej roli pojawiały się funkcje, które z punktu widzenia kontroli wewnętrznej powinny być rozdzielone pomiędzy różne osoby. Każdy użytkownik przypisany do takiej roli automatycznie dziedziczył wynikające z niej ryzyka SoD. Jednocześnie analiza wykorzystania uprawnień pokazała, że użytkownicy często otrzymywali dostęp do znacznie większego zestawu operacji, niż faktycznie wykorzystywali w codziennej pracy. Oznaczało to, że część ról została zaprojektowana szerzej niż wymagał tego rzeczywisty zakres obowiązków.
W zaistniałej sytuacji rozwiązanie może być jedno – ponowna przebudowa modelu uprawnień. Choć na pierwszy rzut oka może to wydawać się radykalne, przy skali zidentyfikowanych problemów jest w praktyce jedyną racjonalną drogą. Próby naprawiania istniejących ról byłyby nie tylko mało skuteczne, ale również czasochłonne i kosztowne. Doświadczenia z opisanego przypadku pokazują, że skuteczne projektowanie ról w systemie SAP wymaga innego podejścia niż to, które często stosowane jest w praktyce projektów wdrożeniowych. Kluczowe znaczenie ma uwzględnienie zasad rozdziału obowiązków już na etapie projektowania modelu ról, a nie dopiero podczas jego późniejszej kontroli. W praktyce oznacza to kilka podstawowych zasad:
- Wykorzystanie matrycy SoD jako narzędzia projektowego – matryca SoD nie powinna służyć wyłącznie do raportowania konfliktów po zakończeniu projektu. Powinna być używana już na etapie definiowania ról, tak aby struktura uprawnień była od początku projektowana z uwzględnieniem rozdziału obowiązków.
- Projektowanie ról w oparciu o rzeczywiste obowiązki użytkowników – role powinny odzwierciedlać faktyczny zakres czynności wykonywanych przez użytkowników w organizacji. W praktyce oznacza to unikanie sytuacji, w których jedna rola obejmuje wszystkie funkcje dostępne w danym procesie biznesowym.
- Stosowanie zasady minimalnych uprawnień – użytkownik powinien posiadać dostęp wyłącznie do tych funkcji, które są niezbędne do wykonywania jego obowiązków. Analiza wykorzystania uprawnień w wielu organizacjach pokazuje, że znaczna część nadanych dostępów pozostaje nieużywana, co jednocześnie zwiększa poziom ryzyka.
- Spójna architektura i konwencja budowy ról – model ról powinien być oparty na jasno określonych zasadach konstrukcji i nazewnictwa. Spójna architektura ról ułatwia zarówno zarządzanie dostępami w systemie, jak i późniejsze analizy audytowe.
Takie podejście pozwala przejść od modelu reaktywnego, w którym konflikty są identyfikowane dopiero po wdrożeniu ról, do modelu projektowego, w którym zasady bezpieczeństwa stanowią integralną część budowy systemu uprawnień.
Podsumowanie
Opisany przypadek pokazuje, że nawet projekt wdrożenia S/4HANA zrealizowany przez doświadczonego dostawcę nie gwarantuje powstania właściwego modelu autoryzacji – jeżeli uprawnienia nie były traktowane jako odrębny, wymagający metodologii obszar projektu. W analizowanej organizacji nowy model ról powstał w ramach wdrożenia, jednak dopiero standardowy cykl audytowy ujawnił skalę konfliktów rozdziału obowiązków oraz nadmiarowych dostępów w systemie.
Dopiero pogłębiona analiza przeprowadzona z wykorzystaniem narzędzia smartGRC pozwoliła określić rzeczywistą skalę problemu oraz zrozumieć jego przyczyny. Okazało się, że konflikty SoD nie wynikały z pojedynczych błędów czy incydentalnych przypisań ról do użytkowników, lecz z samego sposobu zaprojektowania modelu ról.
Najważniejszą lekcją płynącą z tego przypadku jest to, że jakość modelu ról nie zależy wyłącznie od doświadczenia dostawcy wdrożenia. Kluczowe znaczenie ma zdefiniowanie wymagań w zakresie uprawnień już na etapie planowania projektu, przypisanie odpowiedzialności po obu stronach oraz przyjęta metodologia projektowania ról z uwzględnieniem zasad SoD.
Jeżeli zasady rozdziału obowiązków są traktowane wyłącznie jako element późniejszej kontroli, konflikty pojawią się prędzej czy później – niezależnie od tego, kto realizuje projekt.
Dlatego w wielu organizacjach coraz częściej odchodzi się od podejścia polegającego na późniejszym korygowaniu ról na rzecz projektowania modelu autoryzacji „by design”, w którym zasady bezpieczeństwa stanowią jeden z fundamentów całej architektury ról.
O autorach:
Artykuł opracowany na podstawie doświadczeń zespołu GRC Advisory z realizacji przeglądów uprawnień w systemach SAP oraz wiedzy zdobytej podczas rozwoju narzędzi wspierających analizę uprawnień w ramach aplikacji smartGRC.
