Przebudowa czy budowa? – podejście do zarządzania katalogiem ról dla systemów SAP
Wraz z systematycznym rozwojem systemów informatycznych pojawia się problem z powiązaniem uprawnień użytkowników na systemie z ich faktycznym obszarem obowiązków. W dużej mierze organizacje nie są świadome, że zbyt szerokie uprawnienia nadawane pracownikom mogą być przyczyną poważnych naruszeń, a nawet strat finansowych i pozafinansowych. Obecnie coraz więcej organizacji sięga po rozwiązania pozwalające na wykrycie i wyeliminowanie potencjalnych zagrożeń wynikających z tego faktu. Opracowanie odpowiednich standardów, które zostaną zaimplementowane w systemie pozwala na ich monitorowanie i kontrolowanie. Jednym z takich rozwiązań jest stworzenie i wdrożenie matrycy konfliktów SoD (Rozdział obowiązków (SoD) – teoria i praktyka).
Przez konflikt rozdziału obowiązków (SoD) rozumiemy możliwość wykonania przez jednego użytkownika w systemie (np. SAP), lub pomiędzy systemami czynności, które z punktu widzenia: kontroli wewnętrznej firmy, bezpieczeństwa procesów w firmie, dobrych praktyk biznesowych lub regulacji prawnych powinny być rozdzielone i wykonywane przez co najmniej dwóch pracowników. Analizy konfliktów SoD przeprowadzane są najczęściej tylko dla użytkowników. Warto wziąć również pod uwagę, że konflikty pojawiają się także na poziomie ról i przyznanych uprawnień, które pozwalają użytkownikowi na wykonywanie działań w systemie. Korzystając z odpowiednich narzędzi (SAP ARA, smartGRC: smartSoD, smartReport) możliwe jest wygenerowanie raportów naruszeń dotyczących ról dostępnych w systemie.
Konflikty wynikające z połączenia uprawnień przypisanych do użytkownika biznesowego są bardziej zrozumiałe niż te, które znajdują się wewnątrz samych ról. Często zespoły IT bądź dedykowani specjaliści ds. autoryzacji modyfikują uprawnienia na prośbę użytkowników biznesowych, np. ze względu na nowe funkcjonalności. Wykonywanie takich modyfikacji niesie ze sobą realne zagrożenie powstania konfliktów SoD wewnątrz ról. Nie zawsze takie aktualizacje uprawnień są monitorowane i analizowane tak dokładnie jak proces ich nadawania. Nieefektywnie zaprojektowane role mogą posiadać za dużo autoryzacji, zbyt szeroki zakres organizacyjny, mogą być zbyt ogólne (dające pełne uprawnienia). Oznacza to, że rola dająca dostęp do jednej czynności w systemie w wyniku dodania transakcji lub obiektów autoryzacyjnych uzyskuje możliwość wykonania kolejnej czynności w systemie. Z punktu widzenia użytkownika biznesowego oznacza to, że pracownik, który nie posiada w swoich uprawnieniach roli dedykowanej dla danej czynności ma do niej dostęp poprzez inną rolę. Brak przejrzystości w uprawnieniach użytkownika, stwarza zagrożenie dla organizacji oraz przyczynia się do potencjalnego popełniania nadużyć. Dopiero implementacja matrycy SoD i wykonanie początkowych analiz na poziomie uprawnień pozwoli określić jak duża jest skala naruszeń wewnątrz ról przypisanych do użytkowników.
Krok 1: Ustalenie podejścia
Po przeprowadzonej początkowej analizie i ocenie sytuacji możliwe jest wybranie jednej z dróg, która pozwoli uporządkować role w systemie. Można wziąć pod uwagę jedno z dwóch podejść:
I. budowę ról od podstaw
- Stworzenie ról od podstaw pozwoli na dopasowanie katalogu ról do aktualnych potrzeb użytkowników biznesowych i najlepszych praktyk, jednakże jest to duża zmiana począwszy od architektury/katalogu ról, aż do szczegółowego ustalenia, co w danych rolach powinno się znaleźć.
- Przebudowa uprawnień w mniejszym stopniu ingeruje w istniejący zbiór ról, przez co część zbyt szerokich definicji musi pozostać, np. ze względu na transakcje customowe lub zbyt dużą ingerencję w istniejące procesy. Ograniczenia w zakresie zmian mogą być także wyzwaniem w dopasowaniu nowych uprawnień do stawianych oczekiwań.
Ważną rolę w takim projekcie odgrywają użytkownicy biznesowi. Niezależnie od wybranej koncepcji zmiany uprawnień powinni być oni zaangażowani na każdym etapie projektu, począwszy od opracowania katalogu ról, aż do implementacji uprawnień w systemie produkcyjnym. W rozwiązywaniu konfliktów związanym w przebudową uprawnień, to właśnie kluczowi użytkownicy (przełożeni, dyrektorzy, menadżerowie itd.) decydują, czy dostęp do poszczególnych czynności jest uzasadniony na danym stanowisku. Dzięki dostarczonym raportom możliwe jest rozdzielenie poszczególnych obowiązków pomiędzy swoich pracowników tak, aby rozwiązać konflikty SoD. Jeśli jednak nie ma możliwości rozdzielenia zadań miedzy różnych pracowników możliwe jest opracowanie i wdrożenie w organizacji kontroli mitygujących.
Krok 2: Katalog ról i prace w systemie
Przed rozpoczęciem zmian w uprawnieniach należy ustalić ogólne podejście (budowa lub przebudowa ról), opracować katalog ról oraz wyznaczyć zakres i cel projektu. W katalogu ról zawarte są między innymi informacje o:
- Architekturze ról
- Konwencji nazewniczej
- Podziale ról ze względu na przyjętą strukturę organizacyjną
- Transakcjach zawartych w poszczególnych rolach
- Właścicielstwie ról (opcjonalnie)
Podczas przygotowywania katalogu ról istotne są konsultacje z użytkownikami biznesowymi. Dzięki prowadzonej dyskusji możliwe jest jak najlepsze dopasowanie zakresu przebudowy uprawnień do zgłaszanych potrzeb. Ważne jest potwierdzenie ze strony użytkowników, że zaproponowane podejście w pełni pokryje zgłaszane wymagania oraz zapewni zachowanie ciągłości procesów biznesowych, tzn. użytkownicy po nadaniu nowych uprawnień nadal będą mogli bez przeszkód wykonywać swoje obowiązki. Po zaakceptowaniu przez kluczowych użytkowników (właścicieli modułów, właścicieli ról itp.) przedstawionego katalogu ról zespół specjalistów przystępuje do działań w systemie. W zależności od przyjętej koncepcji role mogą być budowane od podstaw lub też istniejące role zostają zmodyfikowane. Przebudowa ról zakłada, np. usunięcie konfliktujących się transakcji, a niekiedy ograniczenie lub usunięcie obiektów autoryzacyjnych, a następnie przydzielenie ich do odpowiednich ról. W procesie budowy lub przebudowy uprawnień powinna być cyklicznie wykonywana analiza konfliktów SoD (SAP GRC ARA, SAP GRC BRM, smartGRC), która już na każdym etapie zmian dostarczy wyników i pozwoli odpowiednio wcześnie wykryć ewentualne nieprawidłowości.
Krok 3: Testy
Według dobrych praktyk wszelkie prace projektowe powinny być wykonywane na środowisku deweloperskim, gdzie po pozytywnym zakończeniu działań zostaną wykonane testy jednostkowe oraz wprowadzone i ponownie sprawdzone ewentualne aktualizacje w uprawnieniach. Pozytywny wynik testów jednostkowych pozwoli na przeniesienie/wgranie uprawnień do środowiska testowego, gdzie zostaną wykonane testy akceptacyjne przez użytkowników biznesowych. Jest to niezwykle ważny etap, ponieważ pozwala on na sprawdzenie, czy nowe uprawnienia umożliwiają wykonywanie przydzielonych obowiązków. Użytkownicy zgłaszają swoje spostrzeżenia i ewentualne ograniczenia dostępu, które na bieżąco są weryfikowane przez zespół projektowy pod kątem ich zasadności. Po uzyskaniu odpowiednich zgód zmiany zostają wprowadzane i przekazane do retestów. Podczas testów akceptacyjnych następuje weryfikacja faktycznych obowiązków pracownika z decyzjami podjętymi przez przełożonych. Pozwala to także na optymalizację i zabezpieczenie przebiegu istniejących procesów w danej organizacji.
Krok 4: Start produkcyjny
Dodatkowym etapem w procesie rozwiązywania konfliktów SoD jest ich mitygacja. W zależności od przyjętej struktury organizacyjnej przedsiębiorstwa nie zawsze jest możliwe rozwiązanie konfliktu, tzn. użytkownik potrzebuje dostęp do ról pozwalających na wykonanie skonfliktowanych ze sobą czynności. Jeśli w danym przedsiębiorstwie zostały wdrożone kontrole mitygujące, mogą one być przypisane do użytkowników, dla których nie ma możliwości rozwiązania konfliktów SoD. Mitygacja konfliktu oznacza, że dostęp do danych czynności pozostanie w uprawnieniach użytkownika, ale będzie on monitorowany na zasadach określonych we wdrożonej kontroli mitygującej dla danego ryzyka. Kontrole mitygujące mogą być wykorzystane tylko na poziomie użytkownika, nie powinny obejmować ról. Według najlepszych praktyk uprawnienia w systemie nie powinny mieć wewnętrznych konfliktów SoD. Po pozytywnym zakończeniu testów akceptacyjnych nowe uprawnienia zostają przeniesione na środowisko produkcyjne i przypisane użytkownikom zgodnie z przyjętym harmonogramem i mapowaniem. Stopniowa migracja użytkowników na nowe uprawnienia zapewnia zachowanie ciągłości działań w systemie i pozwala na szybką reakcję w przypadku pojawienia się błędów lub braków autoryzacyjnych. Równocześnie minimalizowane jest ryzyko związane z brakiem dostępu do systemu przez wielu użytkowników biznesowych jednocześnie.
Podsumowanie
Opisany proces budowy bądź przebudowy uprawnień pozwala na wyeliminowanie konfliktów wewnątrz ról. Ponadto umożliwia optymalizację procesów biznesowych przez świadome rozdzielenie obowiązków pomiędzy pracowników, co sprzyja na zwiększenie efektywności. Przypisanie nowych uprawnień wpływa także na uporządkowanie danych w systemie (usuwane bądź ograniczane są uprawnienia, których użytkownik już nie potrzebuje, np. związane z poprzednim stanowiskiem). Dodatkowo użytkownicy biznesowi otrzymują wiedzę, która pozawala w sposób bardziej świadomy zarządzać procesem wnioskowania i akceptacji uprawnień, co z kolei ogranicza możliwość popełnienia naruszeń. Dodatkowo katalog ról w sposób przejrzysty i zrozumiały dostarcza wiedzy jak powinny być tworzone nowe role zgodnie z przyjętą konwencją nazewniczą oraz założeniami projektu. Tworzone role będą dopracowane pod kątem transakcji oraz obiektów autoryzacyjnych, co pozwoli uniknąć zbyt szerokich dostępów. Należy jednak pamiętać, że proces rozwiązywania konfliktów jest procesem ciągłym i wymaga cyklicznego sprawdzania i przeprowadzania analiz konfliktów SoD nie tylko na poziomie użytkowników, ale także na poziomie ról.
Konsultant w Dziale Usług Doradczych, GRC Advisory