Jak zarządzać konfliktem uprawnień od momentu wniosku użytkownika?

Czy nie byłoby wspaniale myśleć o uprawnieniach w sposób prewencyjny i przeciwdziałać konfliktom SoD, zanim stanie się coś niepokojącego jak użycie krytycznej transakcji przez użytkownika działającego na szkodę organizacji? Jak nie dopuścić do konfliktu na samym początku „łańcucha” uprawnień?


SAST User Access Management pozwala na implementację takiego modelu workflow, który umożliwia już na etapie wnioskowania weryfikację konfliktu SoD. W ten sposób zaoszczędza się pracy administratorom uprawnień czy zespołom autoryzacyjnym przy wykonywaniu ręcznych symulacyjnych kontroli SoD.

  1. Przyjrzyjmy się zatem jak działa SAST UAM w praktyce: W poniższym dwuminutowym video zobaczą Państwo proces wnioskowania przez użytkownika o przypisanie nowej roli z transakcją FEBAN (Wyświetlanie pozycji wyciągu z konta):
Filmik 1 Wniosek

Po wypełnieniu pola z treścią wniosku i nazwy użytkownika, który wnioskuje o dostęp, na tym samym ekranie należy wejść w wyszukiwarkę ról, gdyż wnioskujemy automatycznie o rolę (zawierającą pożądaną transakcję), a nie transakcję celem skrócenia obiegu. Użytkownik wnioskujący ma następujące opcje wyboru roli:

• Może wnioskować o konkretną rolę jeśli zna jej nazwę (Role Name)
• Może wnioskować o rolę po nazwie transakcji (Tcode in Role)
• Może wnioskować o rolę przypisaną do innego konkretnego pracownika - może być przydatne w momencie gdy np. użytkowniczka chce zawnioskować o rolę, którą ma jej kolega, bo będzie go zastępować podczas urlopu? (Roles from user)
• Może wnioskować o rolę z wcześniej zdefiniowanego stanowiska (Workplaces)

Po wybraniu odpowiedniej roli użytkownik może przesłać wniosek do akceptacji przełożonego lub właściciela roli (istnieje również możliwość dodania odbiorcy dodatkowego w postaci Zespołu IT, który filtruje wnioski przed dostarczeniem ich do Akceptantów). Przed wysłaniem nastąpi jednak sprawdzenie konfliktów SoD w relacji do aktualnie przypisanych uprawnień oraz nowo wybranej roli przez wnioskodawcę. W przypadku wystąpienia konfliktu pojawi się komunikat ostrzegający o wykryciu konfliktu. W takim momencie wnioskodawca ma możliwość rezygnacji z dalszego wnioskowania, czyli przesyłania do akceptacji, jednak może również wysłać wniosek mimo konfliktu SoD, pozostawiając decyzję przełożonemu, właścicielowi roli lub oficerowi SoD.

2. Teraz proszę przyjrzeć się, w jakiej formie wniosek wyświetla się u Akceptantów oraz jak zmienia się status wniosku:

Filmik 2 Akceptacja

3. Po otrzymaniu akceptacji wniosek trafia do tzw. Implementatora (czyli Administratora Uprawnień), który może za pomocą jednego kliknięcia z konsoli SAST dodać wnioskowaną rolę do konta użytkownika:

Filmik 3 Implementacja

Jesteście ciekawi jak wyglądają w narzędziu SAST User Access Management inne procesy takie jak stworzenie, usunięcie czy blokowanie użytkownika lub procesy związane z zarządzaniem rolami?

Zapraszamy do kontaktu, z chęcią zaprezentujemy pełne możliwości narzędzia.

Bernadeta Szwarc: bernadeta.szwarc@lukardi.com
Tomasz Jurgielewicz: tomasz.jurgielewicz@lukardi.com

WARTO PRZECZYTAĆ RÓWNIEŻ:

Autoryzacje SAP - Zbiór podstawowych pojęć część 2

Czy podobało się Tobie nasze ostatnie zestawienie pojęć SAP? Jeśli tak, zapraszam na drugą część, w której kontynuujemy budowanie słownika podstawowych elementów świata autoryzacji SAP.

Słownik podstawowych elementów świata autoryzacji SAP

Obiekt autoryzacji (ang. Authorization object) – istotny z perspektywy uprawnień element SAP, dzięki któremu dostęp użytkownika (a dokładnie jego uprawnienia) jest kontrolowany za pomocą kontrol zaprogramowanych w danym obiekcie. Obiekt zazwyczaj składa się z różnych pól np. ACTVT (czynności) i BUKRS (jednostka gospodarcza). Obiekt uprawnień tworzy się w transakcji SU21.


Pole i wartości pól obiektu (ang. Field and field value) – Obiekt autoryzacji składa się z pól, a pola muszą być wypełnione wartościami aby uprawnienia działały. Na przykład, żeby można było wyświetlać dokumenty księgowe pole ACTVT musi być wypełnione wartością 03 (display), a pole BRGRU (authorization group) odpowiednią grupę, do której są przypisane dane dokumenty.


GRC (ang. Governance, Risk and Compliance) – Obszar technologiczno-biznesowy w przedsiębiorstwach, którego głównymi wyzwaniami są definiowanie oraz kontrola ryzyk i przestrzeganie zasad zgodności. W dużym skrócie. SAST jest jednym z dostępnych na rynku globalnym narzędzi do zarządzania GRC w małych i dużych organizacjach.


Konflikt Uprawnień (ang. Authorization conflict) – W świecie ludzi, aby powstał konflikt wystarczą dwie osoby, które wchodzą ze sobą w interakcję. W ekosystemie konfliktów uprawnień SAP to przynajmniej dwie transakcje czy podprocesy, które w zestawieniu ze sobą generują konflikt czyli ryzyko biznesowe czy techniczne.


SoD (ang. Segregation of Duties) – czyli podział obowiązków. Według standardów SAP, dostęp do transakcji powinien być odpowiednio zorganizowany tak, aby przedsiębiorstwo nie narażało się na ryzyko. O Jaki podział obowiązków chodzi? Na przykład taki żeby Ania uzupełniała dane pracowników o konta bankowe a Janek zwalniał przelewy pracownikom w dniu wypłat, jedna osoba nie powinna mieć uprawnień do obu czynności gdyż taka sytuacja umożliwiałaby potencjalne nadużycie uprawnień. Taki rozdział i model stanowisk musi być zaprojektowany przed utworzeniem docelowych ról.


Macierz/matryca konfliktów uprawnień (ang. Authorization conflicts matrix)
– zbiór pogrupowanych konfliktów, czyli „co z czym się gryzie”. Dobrą praktyką jest pogrupować konflikty według modułów SAP oraz należy pamiętać, aby zaimplementować w matrycy własne rozwiązania zetowe. SAST Authorization Management dostarcza bibliotekę konfliktów z ponad 100 zdefiniowanymi konfliktami z podziałem na moduły oraz procesy.


Trace/śledzenie – za pomocą transakcji ST01 (lub SAST SGM) można śledzić wykonywane przez użytkownika działania na zasadzie zbierania przez system logu z informacjami o wywoływanych transakcjach i czynnościach (z podziałem na obiekty i wartości). Trace’a często używa się przy tworzeniu nowych ról gdy wypełnienie pól w roli nie jest oczywiste lub w przypadku pojawiających się powtarzających komunikatów o braku uprawnień.


Firefighter – użytkownik specjalny, dedykowany do sytuacji awaryjnych. Często ma przypisane role z rozszerzonymi uprawnieniami do działań przy „pożarach” na systemie. Na przykład gdy trzeba szybko coś naprawić, aby nie zakłócać procesów biznesowych. Tacy użytkownicy są często przypisywani użytkownikom zewnętrznym jak konsultanci modułowi czy developerzy. SAST Super User Management pozwala na zarządzanie użytkownikami awaryjnymi za pomocą wnioskowania i akceptacji admina systemu lub na stały dostęp. Każde działania takiego firefightera od momentu zalogowania jest monitorowane i zapisywane w logach systemu.


SAP_ALL – profil o pełnych wartościach dla każdego aktywnego obiektu autoryzacji na systemie. Użytkownik z takim profilem ma pełne uprawnienia w modułach biznesowych (FI, HR, MM, etc) oraz developerskie i administracyjne systemu. Nie zaleca się nadawać takich profili użytkownikom, zwłaszcza na systemie produkcyjnym. Dlaczego jest zatem tak popularną wpadką administratorów? Przypisanie SAP_ALL do użytkownika trwa 3 sekundy, zaś analiza i przygotowanie dedykowanych ról, testy oraz ewentualne poprawki (okraszone zniecierpliwionymi komentarzami docelowych odbiorców ról) odrobinę dłużej…


Gwiazdki – magiczne gwiazdki („*”) mogą pojawić się w komentarzach audytorów przeglądających nasze role SAP „o, a tutaj są same gwiazdki, ktoś poszedł na łatwiznę, czy ktoś w ogóle weryfikował te role”? „Dlaczego młodszy księgowy ma gwiazdki na dokumentach, kontach i w działaniach”? O jakie gwiazdki chodzi? Gwiazdki w SAP = wszystko, czyli pełne uprawnienie w zakresie danego obiektu uprawnień, np. każdy rodzaj działań, każdy dokument, każda tabela, etc.


SU53 – „podeślij mi screena z SU53”, możesz to usłyszeć od swojego admina uprawnień. To transakcja, która pozwoli na szybką weryfikację brakujących uprawnień (dla twojego użytkownika) w postaci obiektu autoryzacji oraz wartości.

Potrzebujesz więcej informacji? Skontaktuj sę z nami!

Jeśli podoba się Tobie nasz słowniczek i chciałbyś/chcialabyś wziąć udział w dedykowanym warsztacie uprawnień i konfliktów SAP – napisz do nas.

Zaproponujemy interesującą i dopasowaną do Twoich potrzeb formułę.

Autor: Bernadeta Szwarc

Powiązane artykuły:

W świecie uprawnień SAP - zbiór pojęć
Co powinna zawierać koncepcja uprawnień SAP?
Jak zdefiniować koncepcje autoryzacji?
Projekt reorganizacji uprawnień

Czy zbyt duże uprawnienia dla użytkownika SAP stanowią zagrożenie?

Czy zbyt duże uprawnienia dla użytkownika SAP

 stanowią zagrożenie?

Wydawać by się mogło, że – na pewno - każdy administrator systemu, jak również – co najmniej - użytkownicy reprezentujący top management doskonale zdają sobie sprawę, jakie uprawnienia dostępowe do systemu posiada każdy z nich.

NIC BARDZIEJ MYLNEGO!

Większość uprawnień nadanych użytkownikom jest zbyt obszerna

Praktyka w zakresie wykonywania audytów systemu SAP pokazała, że tak nie jest.

Na co zwrócić uwagę przy nadawaniu uprawnień?

Często zdarza się, że nadawane uprawnienia dla użytkownika SAP są zbyt obszerne. Nawet jeśli mają świadomość zakresu swoich uprawnień, to już w przypadku zagrożenia jakie może się wiązać z ich posiadaniem – tej świadomości brakuje.

Administratorzy z kolei nie mając możliwości monitorowania zagrożeń, nie posiadając dokumentacji działań krytycznych, nie mają też szansy na przedsięwzięcie środków zaradczych.

Jakie zagrożenie wynika ze zbyt dużych uprawnień?

Myślę, że najbardziej jaskrawym przykładem (szczególnie dla osób pełniących funkcje zarządcze w obszarze finansów, np. dla dyrektorów finansowych) będzie sytuacja kiedy użytkownik (niech to będzie konsultant) posiada konto pozwalające mu na tworzenie i modyfikację dokumentów finansowych.

Czy takie uprawnienia są temu użytkownikowi potrzebne?

Dyrektor Finansowy powie – Niemożliwe! A jednak! Takie sytuacje mają miejsce bardzo często, i tak naprawdę są pułapką dla osoby je posiadającej, ponieważ zwiększają ryzyko omyłkowej ingerencji (nie zakładam celowego działania) w dokumenty, do których posiadają dostęp, a użytkownikom z działu finansowego przysparzają dodatkowej – niepotrzebnej – pracy związanej z korygowaniem tych działań.

Najczęściej pojawiające się przykłady zagrożeń

Tym razem niech to będzie administrator modułu SAP BASIS. Bardzo częstym zjawiskiem jest posiadanie przez użytkowników tego typu następujących uprawnień:

Łatwo się domyślić, że użytkownik z takimi uprawnieniami posiada również dostęp i możliwość modyfikacji danych w Księdze Głównej.

Co to oznacza?

Może dokonać zmian w planie kont, a dalej - wszystkich zdarzeniach biznesowych istotnych dla firmy/organizacji.

Czy administrator potrzebuje takich uprawnień? Odpowiedź brzmi – NIE.

Dlaczego?

Ponieważ taki wachlarz uprawnień u danej osoby (użytkownika) stwarza realne zagrożenie dla bezpieczeństwa systemu.

PODSUMOWANIE

Reasumując: mój kolega, który jest absolutnie najlepszym administratorem systemu SAP, jakiego znam, mawia:

„Użytkownik produkcji posiadający klucz developerski jest Bogiem”.

I zdecydowanie wie, co mówi. Osoba posiadająca taki klucz/uprawnienie może dokonać wszelkich zmian na systemie produkcyjnym.

Przykład: może napisać program kasujący, modyfikujący, itd.

Pomyśl – niemożliwe, żeby takie sytuacje się zdarzały!

Uwierz na słowo – sytuacje z niewłaściwie przypisanymi uprawnieniami zdarzają się bardzo często!

Jeśli zarządzanie i kontrola uprawnień stanowią dla Ciebie wyzwanie napisz do nas!

WARTO PRZECZYTAĆ RÓWNIEŻ INNE ARTYKUŁY DOTYCZĄCE UPRAWNIEŃ SAP: