Niższe koszty w SAP: jak usunąć nieaktywnych użytkowników - optymalizacja licencji SAP

Poniższy wpis zawiera konspekt prac zrealizowanych dla jednego z Klientów SAST, którego głównym trzonem była optymalizacja autoryzacji i dostępu użytkowników realizowany był również remodeling koncepcji autoryzacji. Jednym z elementów wdrożenia była ocena zasadności czy wszystkie dostępy są rzeczywiście potrzebne, projekt zakładał również optymalizację licencji SAP. Takie przedsiewzięcia jak projekt reorganizacji autoryzacji i wdrożenia nowej koncepcji opłacają się gdyż skutkują klasyfikacją użytkowników i redukcją dostępów, co pociąga za sobą zredukowanie kosztów licencji SAP.

Co roku SAP przeprowadza audyt systemów Klientów i na tej podstawie często wymaga dodatkowej opłaty licencyjnej za nadmiarowych użytkowników. Wiadomo, że wszyscy aktywni użytkownicy dialogowi SAP mają wpływ na wysokość opłat licencyjnych. W tym kontekście “aktywni” oznacza ograniczenie czasowe ważności konta użytkownika, a nie blokadę administratora.

Zatem zmniejszenie liczby aktywnych master rekordów użytkowników ma bezpośredni i zauważalny wpływ na oszczędność kosztów. Wiele firm w ramach wątpliwości postanawia zostawić część aktywnych użytkowników z obawy przed tym, że codzienna praca może zostać zakłócona. Obawa jest rownież taka, że konkretny użytkownik może być nadal wykorzystywany jako user techniczny do obsługi np. jobów w tle. Pojawia się zatem oczywiste pytanie:

W jaki sposób można uzyskać wgląd w aktywność użytkowników w systemach SAP i w jaki sposób można efektywnie analizować różne rodzaje dostępy użytkowników?

Czy użytkownik jest aktywny? Brak konkretów

Obserwujemy widoczną tendencję pozostawiania aktywnych użytkowników w obawie przed tym, że ich usunięcie może mieć wpływ na przerwanie procesu biznesowego. Wynika to przede wszystkim z braku konkretnej wiedzy na temat korzystania (zarówno pośredniego jak i bezpośredniego) z master rekordów użytkowników.

Jeśli spojrzymy na znacznik czasu logowania użytkownika - nie będzie to precyzyjna informacja, biorąc dodatkowo pod uwagę skomplikowane środowiska (wielosystemowe), czy np. narzędzia webowe. Poziom skomplikowania takiej analizy wzrasta jeśli bierzemy pod uwagę połączenia RFC lub SOAP i ODATA - tu często brakuje i wiedzy i rozwiązań potrzebnych do tego, by skutecznie ocenić dostępy.

Analiza - możliwości i trudności

Jedną z opcji analizy wykorzystania transakcji jest ST03N (STAD - analiza transakcji biznesowych). Transakcja ta pozwala na analizę wykorzystania różnych typów komunikacji:

Rysunek 1 - Elementy menu system load monitor - click w Business Transaction Analysis
Rysunek 2 - Analiza transakcji biznesowych (STAD) - konfiguracja raportu
Rysunek 3 - Wybór opcji typów komunikacji
Rysunek 4 - rezultat listy analizy transakcji biznesowych

Analiza wskazuje którzy użytkownicy generują obciążenie systemu za pomocą konkretnego typu komunikacji. Z tych danych wynika oczywiście którzy użytkownicy są aktywni, ale jest pewne ograniczenie - dane dotyczą tylko określonego dnia. Do głębszej analizy potrzebujemy większego zakresu czasu, zwłaszcza, gdy potrzebujemy wyciągać daleko idące wnioski. ST03N pozwala na analizę transakcji i wywołania programów. Wystarczy tylko dwuklik, aby wyświetlić użytkowników, którzy korzystali z określonej transakcji lub programu ABAP.

Rysunek 5 - profil transakcji z widokiem użytkownika

Niewątpliwym wyzwaniem jest połączenie obu źródeł danych. Bez tego nie uzyskamy pełnego obrazu sytuacji. Standardowe narzędzia SAP dostarczą nam tylko źródła danych. Niestety nie mamy możliwości elastycznej analizy (na przykład dla indywidualnych użytkowników). Zatem dla uzyskania odpowiedniej informacji wymagana jest ręczna analiza i agregowanie danych.

Best Pratice - analiza wykorzystania transakcji za pomocą SAST

Przykład jednego z Klientów - mieszanka dostępów, przy braku konkretnej wiedzy odnośnie tego w jaki sposób użytkownicy wykorzystują transakcje. Podczas analizy przyglądaliśmy się ogólnym informacjom o dostępach - dotyczyło to wszystkich poziomów użytkowania (dialog, batch, RFC, http, itd…).

Dla optymalizacji czasu analizy wykorzystaliśmy funkcję SAST Suite pozwalającą na szczegółową analizę wykorzystania transakcji. Analiza ta została przeprowadzona dla wszystkich aktywnych użytkowników w oparciu o CCMS. Kompleksowo zostały przeanalizowane wszystkie poziomy komunikacji z systemem w dłuższym okresie niż jeden dzień. Dostarczamy tym sposobem również informacje o częstotliwości dostępów (klasyfikacja od A do D na rysunku 7 oznacza częstotliwość, których wartość jest opisana na rysunku 6).

Rysunek 6 - Wykorzystanie transakcji za pomocą SAST
Rysunek 7 - Rezultat analizy wykorzystania transakcji i ich częstotliwość (SAST)

25% nieaktywnych użytkowników - wymiernie niższe koszty

W tym przypadku analiza zawierała takie elementy jak:

W efekcie powyższego otrzymaliśmy informację o tym jacy użytkownicy nie pozostawili żadnego śladu aktywności w tym okresie - ci użytkownicy stali się zatem kandydatami do usunięcia. Jest to zatem bezpośredni przykład jak można zająć się optymalizacją licencji SAP.

Rezultat:

Procedura optymalizacji:

Faza 1 - Przygotowanie

- Przygotowanie projektu
- Instalacja SAST

Faza 2 - Analiza

- Ocena aktywności user master rekordów
- Połączenie danych
- Dokumentacja aktywności
- Koordynacja z administratorem

Faza 3 - Wykonanie

- Poinformowanie biznesu (odpowiednich departamentów)
- Usunięcie nieaktywnych UMR

Sporo informacji o naszym podejściu do zarządzania autoryzacjami SAP znajdziesz tutaj.

Oryginalny wpis pierwotnie ukazał się tutaj.

CZYTAJ POWIĄZANE ARTYKUŁY:


Co powinna zawierać koncepcja uprawnień SAP?

Co powinna zawierać koncepcja uprawnień SAP?

Z mojej obserwacji wynika iż Koncepcja Uprawnień, obok projektu reorganizacji uprawnień jawi się niczym zgroza audytowanych kierowników oraz administratorów uprawnień.
Jednak tylko w przypadku, gdy takiej dokumentacji nie prowadzono w organizacji lub nie była ona aktualizowana wiele lat, a często od czasów wdrożenia SAP w danym przedsiębiorstwie.
Można by się zapytać, gdzie podziała się nasza kultura piśmiennicza? 😉

Warsztaty z Koncepcji Uprawnień często zaczynam (niczym na wykładzie akademickim) rozgrzewką w postaci pytań skierowanych do klientów:

Co to jest Koncepcja Uprawnień waszym zdaniem?

Jakie treści i elementy może, a które powinna zawierać?

Zdecydowanie najtrudniej jest organizacjom, które odkładają wszelkie działania dokumentacyjne na ostatni moment (lub nigdy).

„Skupiamy się na ciągłości biznesu, nie na pisaniu procedur.”

„Mamy zbyt mało zasobów żeby zajmować się tworzeniem, przeglądem i aktualizacją dokumentacji, musimy dostarczać wyniki.”

„Jako administrator uprawnień codziennie przerabiam kilkadziesiąt ticketów, czy naprawdę myślisz, że mam czas na dokumentację?”

To wszystko brzmi znajomo, prawda?
Co więcej, trudno się nie zgodzić z zasadnością przytoczonych pytań.

A teraz wyobraźcie sobie następujące sytuacje i odpowiedzi:

SYTUACJA 1

"Przyszło kilka nowych osób do obsługi procesów do departamentu Kasi i nie za bardzo wiedzą jak złożyć wniosek o nowe uprawnienia, najgorsze, że codziennie dostaję te same pytania od pojedynczych osób. Ja nie mam czasu im tłumaczyć tego jak to u nas wygląda…

ROZWIĄZANIE

- Nadam im dostęp do części Koncepcji Uprawnień przeznaczonej dla Biznesu, niech przeczytają ze zrozumieniem, jest tam informacja o składaniu wniosków, formułce i niezbędnych informacjach potrzebnych do poprawnego przetworzenia zgłoszenia.

- Super, dzięki, zaoszczędziłaś mi czasu na codziennie mini szkolenia.

SYTUACJA 2

- Marek, szybko! Wpadli do mnie znienacka audytorzy i pytają się o Koncepcję Uprawnień SAP, co to jest? Mamy to? Kurczę, co roku pytają i Marta zawsze coś miała pod ręką, ale teraz jest na swoim sabbatical year, najpewniej w buszu w Nowej Zelandii, nie odpisuje na WA i nikt nie wie co się stało z tymi plikami.

ROZWIĄZANIE

- Jest na zasobie, zaraz podeślę link i nadam Ci stałe uprawnienia do wglądu.

-Uffff, co za ulga. Dzięki za ratunek!”

SYTUACJA 3

- Hey, nasz nowy kierownik developerów na dzisiejszym spotkaniu zespołu wyraził niezadowolenie z powodu częstych sytuacji z brakiem uprawnień u jego pracowników. Od jutra nakazał żeby wszyscy mieli SAP_ALL, żeby uniknąć czekania na analizę i rozwiązanie ticketów.

ROZWIĄZANIE

- Nie nadajemy developerom ani konsultantom modułowym SAP_ALL, jest o tym osobny rozdział w przyjętej przez naszą firmę Koncepcji Uprawnień. Mamy procedurę na rozszerzone uprawnienia Firefightera, zaproponuj proszę twojemu kierownikowi 15 minutowy slot na spotkanie, przedstawię mu możliwości. Jestem pewna, że będzie zadowolony z takiego rozwiązania.

- Pewnie, brzmi dobrze. Robi się!

Czy i te przytoczone scenki brzmią dla Was znajomo?
Jeśli tak, to znaczy, że jesteście na dobrej drodze ku stworzeniu czy ulepszeniu Waszej Koncepcji Uprawnień, bo zidentyfikowaliście potrzeby biznesowe takiej dokumentacji.

Co powinna zawierać Koncepcja Uprawnień?

Każdy klient i każde przedsiębiorstwo jest inne, ale wyróżniamy cztery główne rdzenie Koncepcji Uprawnień:

  1. Podstawowy podział ról w organizacji (pojedyncze, zbiorcze, pochodne, referencyjne, szablonowe)
  2. Proces zarządzania użytkownikami (wnioski, akceptacja, wykonanie, dokumentacja z działań)
  3. Proces zarządzania rolami (wnioski, akceptacja, wykonanie, dokumentacja z działań)
  4. Polityka SoD (obowiązująca matryca uprawnień, konflikty krytyczne, odpowiedzialni za cykliczną kontrolę)

Powyższe przykłady to tylko część istotnych informacji, które powinny znaleźć się w Koncepcji Uprawnień.

Zespół konsultantów SAST Polska posiada doświadczenie zarówno w pracach supportowych jak i projektowych. Pomagamy naszym klientom projektować i tworzyć Koncepcje Uprawnień.
Oferujemy szablony dopasowane do potrzeb klienta, które omawiamy na dedykowanych warsztatach.
Jeśli zależy Ci na stworzeniu kompletnej dokumentacji Koncepcji Uprawnień SAP, chętnie Was w tym wesprzemy. Nie jest to takie straszne jak by się mogło wydawać. Zapraszamy do kontaktu.

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

autor: Bernadeta Szwarc /Sast Polska Team/

-------------------------------------------------------------------------------------------------

WARTO PRZECZYTAĆ:

Czy wiesz jakie uprawnienia mają Twoi pracownicy?

Biznes nie lubi chaosu i nie znosi niepewności

Role, uprawnienia i autoryzacje w SAP to temat rzeka, który poruszaliśmy już kilkukrotnie.
Pisaliśmy o zagrożeniach, które wynikają z braku koncepcji uprawnień, źle prowadzonych procach ich nadawania oraz ryzykach z tym związanych dla organizacji. Dzisiaj, w tej nowej dla wielu przedsiębiorstw rzeczywistości temat jest tym bardziej "gorący".

Raport PWC "Global Economic Crime Survey 2020" jednoznacznie wskazuje, że wśród Polskich firm spory wzrost odnotowują nadużycia księgowe. Okazuje się, że około 63% nadużyć było dokonywanych przez pracowników (insider).

Skala nadużyć jest także coraz większa - ponad 61% firm, w których wykryto nadużycie poniosło z tego tytułu straty większe niż 400k PLN (ponad połowa z nich osiągnęła straty powyżej 4 mln PLN).
Warto jeszcze zaznaczyć, że w większości wykrycia nadużyć zostały dokonane przez działania rutynowe (takie jak audyty czy przeglądy dokumentów). Zaledwie 23% wykryć pochodziło przez automatyzację działań podejrzanych i systemy ochrony IT.

Skoro większość z dokonanych nadużyć było realizowane przez pracowników - warto przyjrzeć się możliwym przyczynom. Podczas realizacji projektów - w kontekście autoryzacji SAP obserwujemy trzy znaczące trendy w tym zakresie: zaniedbanie autoryzacji na początkowym etapie wdrożenia systemu, proces akceptowania oraz konflikty uprawnień.

Zaniedbanie autoryzacji na początkowym etapie wdrożenia systemu

Projekty wdrożeniowe mają to do siebie, że istnieje dość duży nacisk na budżet i prędkość realizacji projektu. Ma to oczywiście swoje uzasadnienie, gdyż biznes musi generować przychód, a czas ma kolosalne znaczenie. Niemniej w późniejszym etapie życia systemu i użytkowników w nim - istotne jest zabezpieczenie zarządzania autoryzacjami konkretnymi wytycznymi.

Stąd też pojęcie koncepcji uprawnień, czyli zestawu szczegółowych informacji o podstawowych zasadach tego wyzwania. Począwszy od nazewnictwa i zawartości ról, przez zmapowanie ról ze stanowiskami, na określeniu ram i ryzyk związanych z dostępami kończąc. I wydaje się, że taka spójność dostępów powinna być w każdej organizacji priorytetem - powyższe opracowanie PWC pokazuje, że sporo jest jeszcze do zrobienia.

Skoro system działa parę (często paręnaście) lat - jest spore prawdopodobieństwo, że nieuprawnione
(z definicji) osoby mają potencjalną możliwość realizacji nadużyć przez zbyt duże dostępy.

Użytkownikowi łatwiej jest dodać rolę niż jakąś zabrać - a to wychodzi z naszych obserwacji, gdzie około 10-15% autoryzacji nadanych użytkownikom jest używana w codziennym życiu (reszta jest po prostu zbędna).

Proces akceptowania - brak wiedzy

Znasz taki scenariusz?

- "Poproszę o rolę taką jak ma Pan Staszek"

- "Ok, akceptuję"

Co w tej sytuacji robi BASIS (lub dział autoryzacji)?
Jeśli proces akceptacji się w tym momencie kończy - realizowana jest prośba.

Czy osoba akceptująca posiada wiedzę odnośnie wszystkich transakcji i ról, związanych z nimi ryzyk i potencjalnych zagrożeń?
Śmiem twierdzić, że jest to mało prawdopodobne.

Wnioski na mailu, w formie papierowej lub w systemie ticketowym, których weryfikacja jest oderwana od kontekstu systemu (brak możliwości sprzężenia zwrotnego z ryzykami w SAP) powodują, że organizacja
w tym zakresie nie działa proaktywnie. Dzięki temu do systemu regularnie przedostają się niebezpieczne zestawy autoryzacji.

Konflikty Uprawnień - czyli wypływ pieniędzy z organizacji

Pracownik w ciągu wielu lat pracy w organizacji przechodzi przez różne jej szczeble. Dostaje nowe dostępy, zmienia funkcje, dostaje następne role. Jest to również pochodna dwóch pierwszych punktów (typowych zaniedbań).

Konsekwencje są tu bardzo widoczne, bo jego dostępy pozwalają na wykonanie całych procesów biznesowych. Często wielu...

Dobrze, gdy organizacja zna ryzyka i potrafi sobie z nimi poradzić wdrażając odpowiednie procesy GRC
w SAP. Jednak są to wyjątkowe sytuacje, a w większości przypadków aktywności sprowadzają się do wykonania ogólnych raportów z pojedynczych konfliktów.

Nadużyć związanych z Konfliktami Uprawnień (SOD) można mnożyć. Dotyczą one praktycznie każdego obszaru biznesu realizowanego przez SAP.

Prosty scenariusz dla FI:

Autoryzacja nr 1 - FK01 / XK01 - Zarządzanie danymi podstawowymi dostawców

Autoryzacja nr 2 - FB60 / FB65 / FB01 / F-53 - Fakturowanie towarów przychodzących

Konflikt uprawnień - Ryzyko wysłania faktury dla fikcyjnego dostawcy. Wypłynięcie pieniędzy z tytułu rozliczenia faktury.

Obszar SD

VA01/VA02/WCS0

+

Np.: V32/V32/V33/V35

Możliwość wprowadzenia dokumentów sprzedaży i obniżenia cen celem osiągnięcia korzyści finansowych dla użytkownika, który może edytować fikcyjnych dostawców i inicjować zakupy na danego dostawcę.

Obszar HR/PY

Np.:F-18/F-46/F-58_K

+

Np.: FEBA/FF.5/FF/4/FF/5

Wprowadzenie nieautoryzowanych płatności i realizacja salda rachunku bankowego. Ryzyko wprowadzenia nieautoryzowanej płatności i potwierdzenia salda bankowego przez tą samą osobę.

Podsumowanie

W tak potężnym narzędziu, przetwarzającym najważniejsze dane w organizacjach - kwestie optymalnego zarządzania dostępem to nic innego jak wymóg, by organizacja mogła panować nad ryzykiem i potencjalnymi nadużyciami.

I to nie jest tylko potrzeba, na którą zwracamy uwagę, jako producent narzędzi do zarządzania procesami GRC w SAP. To również opracowania Wielkiej Czwórki, oraz ich Klienci, którzy spotykają się z wymiernymi problemami właśnie ze względu na nadużycia użytkowników, którzy nie powinni mieć dostępu, lub dostęp ten powinien być ściśle monitorowany.

Co można zatem zrobić?

Przede wszystkim przyjrzeć się obecnej infrastrukturze SAP:

1 - jaka jest aktualna Twoja koncepcja uprawnień? Czy jest brana pod uwagę w codziennych czynnościach?

2 - jak wygląda Twój proces nadawania uprawnień oraz ich akceptacja? Czy osoby akceptujące posiadają wystarczającą wiedzę o ryzykach?

3 - czy znasz poziom ryzyk związanych z dostępami i konfliktami uprawnień?

Jeśli masz wątpliwości co do któregokolwiek z punktów - jesteśmy do dyspozycji.

autor: Tomasz Jurgielewicz /Sast Polska Team/
tomasz.jurgielewicz@lukardi.com

------------------------------------------------------------------------------------------------
Bibliografia
https://www.slideshare.net/slideshow/embed_code/key/36w8AjPl4t9TcE
https://www.pwc.com/gx/en/forensics/gecs-2020/pdf/global-economic-crime-and-fraud-survey-2020.pdf

-------------------------------------------------------------------------------------------------

WARTO PRZECZYTAĆ:

Projekt reorganizacji uprawnień

W poprzednim artykule pisałam o audycie uprawnień za pomocą narzędzi SAST.
Audyt taki, jeśli przynosi zatrważające rezultaty w obszarze bezpieczeństwa SAP (czytaj: z raportu audytowego jasno wynika, iż jako organizacja potrzebujemy zmian w zakresie lepszego zarządzania użytkownikami i uprawnieniami w organizacji) często prowadzi do dyskusji dotyczącej aktualnych procesów zarządzania uprawnieniami.

Takie dyskusje często są świetnym początkiem drogi do rozpoczęcia projektu.
Warto zauważyć, iż w przypadku reorganizacji uprawnień można też zastosować tzw. „projekt pełzający” czyli naprawiamy i uszczelniamy system krok po kroku.  Jest to dobra opcja, gdy mamy mało zasobów ludzkich, czasu i pieniędzy na wielki projekt reorganizacyjny.

Projekt reorganizacji uprawnień- od czego zacząć?

Klienci zazwyczaj obawiają się wielkiego przedsięwzięcia i wywrócenia do góry nogami świata autoryzacyjnego, a co za tym idzie, świata codziennego biznesu. Często taki świat rządzi się swoimi prawami, role są przepełnione, zawierają setki nieużywanych transakcji lub S_TCODE są wypełnione,
o zgrozo, * (słownie: gwiazdką)!
Jednak coraz częściej atrakcyjniejszy staje się model reorganizacyjny  gdzie porządki robi się stopniowo, dział po dziale, czas na spotkania znajduje się poza gorącymi okresami w przedsiębiorstwie. Kroki milowe nie są wielkie i gwałtowne, ale są wdrażane stopniowo przyczyniając się do wzrostu świadomości autoryzacyjnej we wszystkich działach.

Dobrze, zatem jak robimy projekt?

Audyt
Weryfikuje obecną sytuację i jest argumentem przemawiającym za rozpoczęciem reorganizacji uprawnień. SAST analizuje m.in. wykorzystywane transakcje i generuje raporty, które muszą być przeanalizowane przez sponsora projektu, jego doradców oraz zespół projektowy.
W skład zespołu projektowego muszą wchodzić osoby pełniące rolę administratora uprawnień.

Zdefiniowanie ryzyk projektowych w przedsiębiorstwie
Standard przy każdym projekcie, nie tylko autoryzacyjnym.
W każdej organizacji będą to inne ryzyka. Może brak Key-userów? Może brak zespołu autoryzacyjnego?
Może niezrozumienie istotności obszaru uprawnień SAP przez Zarząd?

Plan projektu
Dzielimy projekt na najważniejsze fazy, podczas których muszą wydarzyć się odpowiednie działania
w nieprzypadkowej kolejności.

Koncepcja Uprawnień
Dokument, który opisuje kompletny model zarządzania uprawnieniami i użytkownikami w SAP
w organizacji. Najważniejsze: nie tworzy się go raz przy wdrożeniu SAP i się o nim zapomina.
Jest to „żyjący” dokument, aktualizuje go na bieżąco zespół autoryzacyjny przy każdorazowej modyfikacji uprawnień. Na wniosek klienta dostarczamy nasz szablon Koncepcji Uprawnień podczas projektu.

 Dobre praktyki

Gotowi na projekt?  Zapraszamy, pomożemy Wam zrobić wiosenne porządki w autoryzacji!

autor: Bernadeta Szwarc /Sast Polska Team/

-------------------------------------------------------------------------------------------------

WARTO PRZECZYTAĆ:

Czym jest SoD ? - Konflikt uprawnień #1

SAST w swoim pakiecie posiada zdefiniowane mechanizmy dotyczące kontroli SoD. Zasady te oparte są na standardach weryfikacji stosowanych przez wiodące firmy audytorskie. Tym samym obejmują wszystkie niezbędne wymogi monitorowania. Jednak każdy z klientów korzystający z SAST może również dostosować swoje wewnętrzne wymogi i zaimplementować do swojej matrycy.

W dzisiejszym artykule omówimy czym jest SoD i jak wzmocnić jego kontrolę w organizacji na przykładzie konfliktu uprawnień na poziomie BASIS

Czym jest SoD?

Segregation of Duties – rozdział obowiązków oznaczający, że niektóre zadania w ramach danego procesu biznesowego nie powinny być wykonywane przez tę samą osobę lub jednostkę organizacyjną zgodnie z:

SAST Authorization Management oraz SAST Risk and Compliace Management pozwala nam na przygotowanie matrycy konfliktów uprawnień nie tylko na poziomie transakcji ale również mamy możliwość dodania zależnych obiektów autoryzacyjnych.

Posłużmy się przykładowym konfliktem uprawnień na poziomie BASIS, gdzie użytkownicy mogą zarządzać użytkownikami i jednocześnie modyfikować role w systemie SAP.

PRZYKŁAD KONFLIKTU NA POZIOMIE BASIS

1. Definiujemy krytyczne autoryzacje dla procesu BC_AUTH_ADMIN

Każda z krytycznych autoryzacji posiada unikalny identyfikator (Authorization ID).

Listę Authorization ID przedstawia tabela.

Każda krytyczna autoryzacja definiuje zależne transakcje oraz autoryzacje.

2. Definiujemy krytyczne autoryzacje dla procesu BC_USER_ADMIN

Każda z krytycznych autoryzacji posiada unikalny identyfikator (Authorization ID).

Listę Authorization ID przedstawia tabela.

konflikt uprawnień_blog_sast_polska

Każda krytyczna autoryzacja definiuje zależne transakcje oraz autoryzacje.

3. Opisujemy powstały konflikt, który będziemy mogli dodać do matrycy uprawnień SoD

konflikty uprawnień_3_blog_sast polska

4. Przygotowujemy opis ryzyka, gdzie zawarty jest m.in. identyfikator, poziom krytyczności, tytuł, przyczyna powstania ryzyka

konflikty uprawnień_4 blog sast polska

PODSUMOWANIE

W celu usunięcia konfliktu SoD w roli należy wyeliminować jeden proces.
Rola musi być zmodyfikowana na tyle aby z jednego procesu pozbyć się transakcji oraz zależnych obiektów autoryzacji.

Narzędzie dostarczane przez Akquinet jakim jest SAST pomaga klientom wzmocnić kontrolę SoD w swojej organizacji. Produkt ten pozwala wykrywać, analizować, monitorować oraz budować ryzyka.
Automatyzuje kontrolę dostępu do krytycznych transakcji zawartych w rolach systemu SAP.

Autor: Marek /Sast Team Polska/

WARTO PRZECZYTAĆ RÓWNIEŻ: