Czy reorganizacja konfliktów SoD i uprawnień SAP musi być bolesna?

Na konferencji poświęconej SAP Security – wskazówki dla bezpieczeństwa dzieliłam się z Państwem wiedzą zdobytą podczas zarówno projektów reorganizacji SoD i uprawnień jak i codziennych zadań w ramach Managed Services. Dla tych z Państwa, którzy nie mogli uczestniczyć w konferencji przygotowałam krótkie podsumowanie.

Na samym początku zadaliśmy sobie pytanie co może być przyczyną decyzji o rozpoczęciu takiego przedsięwzięcia jakim jest Projekt Reorganizacji Uprawnień. Przykładowe scenariusze to:

 

1. 1. W firmie doszło do wycieku danych lub oszustwa finansowego wynikającego ze zbyt szerokich uprawnień użytkownika.
      O zdarzeniu dowiedzieliśmy się przypadkiem. O ilu zdarzeniach się nie dowiedzieliśmy
   2. Doszło do awarii na systemie produkcyjnym – niezamierzony błąd ludzki. Czy uprawnienia były zbyt szerokie? Czy wiemy jak odtworzyć błąd? Czy system przechowuje logi i wiemy jak je czytać?
   3. Bałagan w rolach SAP, utrata poczucia kontroli nad rolami. Dodajemy nowe uprawnienia do ról, nie odbieramy uprawnień. Rezultat: wszyscy mają dostęp do (prawie) wszystkiego.

1.  

1.  

Pojęcia z zakresu SoD

Przypomnieliśmy sobie również podstawowe pojęcia z zakresu SoD – od ogółu do szczegółu:

Termin	Definicja
Matryca SoD	zbiór zdefiniowanych oraz opisanych konfliktów uprawnień w danym obszarze (np. FI, TR, SD, HR, Basis)
Konflikt SoD	krytyczne zestawienie przynajmniej dwóch procesów biznesowych (np. wystawianie płac + zmiana konta bankowego, otwieranie okresów księgowych + zwalnianie dokumentów do płatności, konfiguracja systemu + import transportu)
Ryzyko	opis konfliktu SoD z punktu widzenia biznesowego oraz możliwych konsekwencji wynikających z przypisanych uprawnień
Proces	działanie biznesowe (np. otwieranie okresu księgowego, zwalnianie dokumentów do płatności)
Authorization ID	zdefiniowane transakcje, raporty, tabele czyli wartości pól SAP sprawdzanych przez silnik zdefiniowanej i skonfigurowanej na systemie SAP matrycy. Wszystko to co chcemy wyłapać jako „krytyczne” w uprawnieniach kontrolowanych użytkowników
Mitygacje	kontrola ryzyk, do których powinien zostać odebrany/zachowany dostęp dla określonych użytkowników; kontrole mogą być manualne, kompensacyjne, automatyczne, zgodne z zasadą „four eyes principle”
SOD Segregation of duties	czyli każdy pracownik wykonuje wyłącznie swoją część procesu i nikt nie jest uprawniony do działań wykraczających poza stanowiskowe obowiązki!

Planowanie PRU

Planując PRU należy zaplanować przynajmniej poniższe 5 faz:

 

1. 1. Analiza aktualnych konfliktów SoD, problemów autoryzacyjnych, stanu ról, stanu procedur
   2. Planowanie zadań i odpowiedzialności w PRU, nowa Koncepcja Uprawnień
   3. Konfiguracja nowych ról, Firefighter
   4. Testy/Pilot
   5. Start Produkcyjny – Hyper care, dokumentacja ma swoich właścicieli, mitygacje

1.  

1.  

1.  

1.  

W trakcie projektu czeka na nas cała masa wyzwań oraz pułapek, na przykład gdy przeanalizujemy krytyczne dostępy na systemie SAP i wykryjemy kto ma przypisany profil SAP_ALL…

Może się okazać, że nie tak łatwo poszczególne osoby będą chciały oddać taki szeroki, wygodny dostęp. Argument: „jestem kluczowym użytkownikiem i potrzebuję szerokiego dostępu na cito w razie awarii na systemie”.
Kolejna niespodzianka dotyczy innego ważnego aspektu w projekcie. Otóż projekt reorganizacji uprawnień i SoD to projekt wybitnie interdyscyplinarny. Aby stworzyć perfekcyjny zespół projektowy musimy zaangażować i podzielić zadania zarówno wśród użytkowników biznesowych jak i technicznych (Zespół Autoryzacji, konsultanci modułowi, developerzy, Basis). Niestety, bardzo często gdy projekt ma w nazwie „autoryzacje” właściciela projektu często przypisuje się w zespołach IT:

Przykłady zestawienia narzędzi standardowych SAP z narzędziami SAST Suite

Po zdefiniowaniu właścicieli tematów i zadań w każdej fazie projektu należy zastanowić się nad odpowiednimi narzędziami, które mogą być przydatne w projekcie reorganizacji uprawnień i SoD. Warto przyjrzeć się dostępnym w SAP oraz na rynku narzędziom, które redukują czasochłonność i automatyzują pracę zespołu projektowego. Poniżej podaję przykłady zestawienia narzędzi standardowych SAP z narzędziami SAST Suite.

1. Matryca konfliktów SoD – czyli nasz silnik autoryzacyjny. Działania rozpocznijmy od zebrania i udokumentowania procesów krytycznych w organizacji.

   Standard SAP: konfiguracja „Critical combinations” i „Critical authorizations” w SUIM. Weryfikacja wyłącznie na poziomie dostępu do Tcode’a (transakcji).

   SAST Suite: gotowa biblioteka konfliktów SOD (ponad 300 zdefiniowanych konfliktów) z podziałem na moduły SAP. Weryfikacja na poziomie dostępu do Tcode’a + obiekt uprawnień + wartość pól obiektu uprawnień
2. Zarządzanie rolami SAP – podczas projektu reorganizacji uprawnień często będziemy tworzyli nowe role lub modyfikowali istniejące.
   Standard SAP: tworzenie i modyfikacja ról według potrzeb i zdefiniowanych (jeśli są) stanowiskach – PFCG
   
SAST Suite: gotowe do użycia role szablony (wgrywane na system standardowym transportem SAP) – z podziałem na role biznesowe, techniczne, moduły SAP oraz stanowiska

   Rezultat: Ujednolicona konwencja nazewnictwa ról + Obszerny opis roli.
3. Zarządzanie rolami SAP – w przypadku prężnie rozwijających się spółek pojawiają się mini projekty związane z rolloutami. Należy wówczas zorganizować nowe uprawnienia dla nowych poziomów organizacyjnych.
   Standard SAP: Należy utworzyć role referencyjne, na których bazie tworzy się role pochodne z nowymi poziomami organizacyjnymi – kopiowanie ról + manualna modyfikacja w PFCG.
   SAST Suite: Zdefiniowanie ról referencyjnych + utworzenie orgsetów z wartościami nowych poziomów organizacyjnych + automatyczne utworzenie ról pochodnych.
   Automatyczne tworzenie ról z nowymi poziomami organizacyjnymi:
   Rezultat: po zdefiniowaniu wartości w orgsecie automatyczne utworzenie roli o nazwie: YFI_C_AC00:AA-DAILY wraz z uzupełnionymi poziomami organizacyjnymi.
4. Trace – używamy tej funkcjonalności celem prześledzenia działań użytkownika na systemie względem wykorzystywanych autoryzacji.
   Standard SAP: ST01 lub SM20 (Security Audit Log), SU53, STUSOBTRACE
   SAST Suite: możliwość rozpoczęcia śledzenia dowolnych użytkowników z jednego dashboardu + pełne dane dotyczące wykonywanych czynności + utworzenie roli z trace’a.
   Śledzenie użytkownika + tworzenie roli z wykorzystywanych uprawnień + wyświetlenie brakujących uprawnień
   Rezultat: utworzenie roli z prześledzonego na wybranym użytkowniku trace’a.

Podsumowanie

Nie zapominajmy o pozostałych wyzwaniach Projektu Reorganizacji Uprawnień:

• Koncepcja Uprawnień – utrzymanie – ten dokument to „żywy organizm”
• Procesy zarządzania uprawnieniami i użytkownikami
• Wyłonienie właścicieli obszarów oraz ról
• Cykliczne kontrole SoD i uprawnień – przynajmniej raz w roku
• Utrzymanie ciągłości nowego systemu uprawnień i SoD

Zapraszamy do kontaktu

Gdyby zainteresowało Państwa szczególnie któreś z omówionych zagadnień, serdecznie zapraszam do kontaktu.