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 reorganizacja konfliktów SoD i uprawnień SAP musi być bolesna?

Projekt Reorganizacji Uprawnień - przykładowe scenariusze

Na ostatniej 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. 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.

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. 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

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ń.

Przykład wycinka matrycy HR w SAST Suite:

Fragment biblioteki krytycznej autoryzacji – transakcja PA30 + obiekt autoryzacyjny wraz z krytycznymi transakcjami:

  1. 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:


  1. 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

  1. 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ń:

Zapraszamy do kontaktu

Gdyby zainteresowało Państwa szczególnie któreś z omówionych zagadnień, serdecznie zapraszam do kontaktu. Do usłyszenia na kolejnej konferencji SAP Securitywskazówki dla bezpieczeństwa!

Luka bezpieczeństwa powodem cyber ataku

Luka bezpieczeństwa powodem cyber ataku

Po raz pierwszy w historii Departament Bezpieczeństwa Krajowego USA (Departament of Homeland Security) opublikował raport o zagrożeniach bezpieczeństwa systemów SAP (US-CERT Alert for cybersecurity of SAP business applications). Raport opisuje to jaka luka bezpieczeństwa miała wpływ na przejęcie kontroli nad systemami SAP.

36 organizacji ofiarą ataku przy użyciu luki bezpieczeństwa

Co najmniej 36 organizacji (posiadających w swojej infrastrukturze system SAP) zostało zaatakowanych z użyciem luki bezpieczeństwa znanej od około 6 lat. Atak był wycelowany przede wszystkim w systemy, które nie były aktualizowane zgodnie z dostarczanymi patchami w ramach SAP Security Notes. Opisane luki dotyczyły z pewnością adonów SAP NetWeaver Server Java - Invoker Servlet.

Jakie systemy są najbardziej zagrożone?

W związku z tym raport DHS wskazuje na to, że systemy SAP posiadające nieaktualizowane oprogramowanie są podatne na zagrożenia. Dotyczy to systemów działających na platformie SAP Java. Ze względu na fakt, że omawiana platforma SAP Java jest podstawową technologią dla wielu systemów włączając w to SAP:
luka bezpieczeństwa jest umiejscowiona na warstwie aplikacyjnej systemu SAP, zatem jej wystąpienie jest niezależne od systemu operacyjnego oraz bazy danych wspierającej system SAP.

Jakie są efekty wykorzystania luki?

Wykorzystanie omawianej luki Invoker Servlet pozwala z pewnością na zdalną, nieuwierzytelnioną, pełną kontrolę nad zaatakowanymi systemami. Pozwala w związku z tym na pełny dostęp do danych i procesów biznesowych na systemach (lub wręcz dostęp do połączonych z SAPem innych systemów).

Jak się zabezpieczyć?

Najpewniejszym rozwiązaniem jest skorzystanie i użycie SAP Security Note 1445998 oraz wyłączenie Invoker Servlet.

Komentarz naszego eksperta

Ze względu na to, że omawiana podatność jest znana od co najmniej 6 lat wydaje się rzeczą nieprawdopodobną, że ta luka została wykorzystana przez włamywaczy. Niepokojące jest również to, że sytuacja dotyczy aż takiej ilości globalnych systemów. Co to oznacza? Ze względu na fakt, że do tematu bezpieczeństwa danych nie podchodzi się w sposób usystematyzowany powoduje takie zaniechania na poziomie bezpieczeństwa. Trudność polega przede wszystkim na przekonaniu decydentów o konieczności inwestycji w rozwiązania automatyzujące procesy bezpieczeństwa SAP.
Daniel Sikorski / SAP Security / BASIS
kontakt z ekspertem


WARTO PRZECZYTAĆ NA TEMAT BEZPIECZEŃSTWA SAP: