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ń

Bezpieczeństwo SAP

Bezpieczeństwo SAP

Wymogi dotyczące bezpieczeństwa nieprzerwanie wzrastają, a zabezpieczenie krytycznych danych w organizacji jest jedną z podstawowych kwestii, gwarantujących ciągłość podstawowych procesów biznesowych.
Środowiska systemowe stają się coraz bardziej złożone (komunikacja z systemami zewnętrznymi, wymiana danych oraz ciągły rozwój istniejących systemów).

Podczas ewentualnego ataku na system SAP (bez względu na to, czy atak pochodzi z wewnątrz czy z zewnątrz organizacji) osoba atakująca może uzyskać dostęp do cennych informacji systemowych.
W związku z tym może wykorzystać te informacje do dalszych ataków na inne systemy SAP a także uzyskać ważne dane firmowe (dane klientów, informacje o produkcie, np. receptury i rysunki techniczne, dane o wynagrodzeniu itp.) w sposób niezauważony.

Zarządzanie bezpieczeństwem sprowadza się do zarządzania ryzykiem

Przede wszystkim, aby zrobić to odpowiednio należy zewidencjonować wszystkie ryzyka i pogrupować je wg priorytetów po to, by organizacja posiadająca system SAP mogła poznać i skorygować ewentualne zagrożenia dla systemu SAP (na przykład z pomocą zewnętrznego wsparcia).
Badanie bezpieczeństwa i zgodności SAP obejmuje sprawdzenie sieci, systemu operacyjnego, bazy danych, parametrów, konfliktów SoD w systemie SAP w oparciu o dostarczane matryce ryzyk i konfliktów.

6 podstawowych obszarów ryzyk

Wyszczególniliśmy 6 podstawowych obszarów ryzyk, które należy wziąć pod lupę w pierwszej kolejności.
Obszary podzieliliśmy na dwie części: techniczną oraz użytkowników.

Warstwa techniczna

1. Ustawienie konfiguracji SAP

Warstwa parametrów konfiguracyjnych, które powinny odpowiadać polityce bezpieczeństwa organizacji. Parametry te należy kontrolować regularnie.

Przykład:

login/password_expiration_time (wartość domyślna 0, nasza rekomendacja 30)
Użytkownik musi zmienić hasło po określonej ilości dni (dla parametru 0 wymuszenie nie jest włączone).


login/min_password_lng
(wartość domyślna 3, nasza rekomendacja 8+)
Ustawienie minimalnej długości hasła.

login/fails_to_user_lock (wartość domyślna 12, nasza rekomendacja 5)
Ilość źle wpisanego hasła do blokady konta użytkownika.

2. Weryfikacja zdarzeń i ustawień "na" i "poza" warstwą SAP

Poziom SAP

SAP Security Audit Log:

  • główny log bezpieczeństwa,
  • część informacji jest mało czytelna z perspektywy bezpieczeństwa,
  • zalogowanie usera SAP* nie stanowi wg logu ryzyka, podczas gdy ryzykiem jest źle wpisane hasło logowania.

SAP Change Documents and Table Loggin:

  • logowanie zmian dokumentów oraz zmian w tabelach,
  • niska jakość w przypadku braku archiwizacji dokumentów w czasie.

SAP System Log:

  • główny log systemu SAP,
  • logi nadpisywane po 14 dniach.

Poziomy poza SAP

Log systemu operacyjnego Windows/UNIX - problemem jest np. fakt, że administrator musi posiadać uprawnienia root do samego odczytu logów

Log bazy danych – brak możliwości analizy ustawień bazy danych z poziomu SAP (np. Informacja o kontach i ich autoryzacjach)

Logi sieciowe SAP Router/HTTP - problemem jest brak standardowych rozwiązań do przekierowania logów do syslogu

3. Aktualizowanie Patchy systemowych

Każdy system jest podatny na działania hackerskie, SAP nie jest wyjątkiem, dlatego istotne jest, aby regularnie instalować łatki systemowe.
Dzięki nim pojawiają się informacje o włamaniach z wykorzystaniem znanych podatności.

Przykład 1 - raport Departamentu Bezpieczeństwa USA wskazującego na włamania do co najmniej 36 globalnych systemów SAP z wykorzystaniem luki znanej (i naprawionej) od 2010 roku. Więcej na https://bit.ly/28Kpk5r

Przykład 2 - coroczne spotkanie społeczności zajmującej się tematyką bezpieczeństwo the PWNIE Awards w 2015 roku przyznało pierwszą nagrodę w kategorii Best Server-Side Bug za wykrycie podatności w SAP, pozwalającej na nieautoryzowany dostęp do systemu https://bit.ly/29Se5hB

Warstwa użytkowników

4. Domyślne konta

Podczas wdrożenia systemu SAP tworzone są domyślne konta użytkowników. Służą one do wstępnej instalacji systemu, powszechnie znane są zarówno z nazwy jak i hasła.
Niezwykle ważna jest odpowiednia ochrona tych kont.
Najbardziej krytyczne konto to SAP* (pozwala na praktycznie nieograniczoną możliwość dostępu i zmian w systemie).

Hasła kont domyślnych należy zmienić, a profile wysoko uprzywilejowane (np. SAP_ALL) należy usunąć.
Istotne jest to, że w przypadku usunięcia konta domyślnego - odtworzy się ono automatycznie (z domyślnym hasłem).
Konto SAP* powinno zatem mieć zmienione hasło, a parametr login/no_automatic_user_sapstar ustawione na wartość 1 (brak możliwości odtworzenia automatycznego konta SAP*).

5. Domyślne profile

Tak jak w przypadku kont domyślnych, SAP posiada (dostarczane wraz z instalacją) zestawy profili autoryzacyjnych, pozwalających na szeroki dostęp do systemu. Wykorzystanie tych profili powinno być bardzo restrykcyjnie zarządzane, a ich użycie ograniczone tylko do sytuacji awaryjnych.

Najważniejszym profilem szerokiego dostępu jest SAP_ALL - pozwala on na wykonanie dowolnej transakcji, dostępu do dowolnego obiektu, funkcji czy akcji (nie bez powodu w żargonie administratorów SAP o tym profilu zwykło się mówić "Bóg na systemie"). Istotne jest by ten profil nie został nigdzie przypisany. Podobnie sprawa ma się z profilem SAP_NEW

6. Konflikty uprawnień

Nieodpowiednie dostarczenie użytkownikom praw dostępu do różnych części systemu to zwiększone ryzyko defraudacji.

Przykład: jeśli jedna osoba posiada zarówno możliwość zmiany numeru konta bankowego oraz możliwość wykonania przelewu - istnieje możliwość obejścia polityk organizacji w celu wyprowadzenia pieniędzy na zewnątrz.

Reasumując: istotne jest aby odpowiednio zarządzać matrycą konfliktów uprawnień. Matryca taka pozwala przede wszystkim na identyfikację istniejących konfliktów, a weryfikacja dostępów poszczególnych użytkowników pozwoli na ocenę ryzyk. Realizacja skutecznej polityki dostępów do danych w SAP stanowi jeden z najważniejszych elementów uszczelnienia środowiska SAP pod kątem ryzyk, których głównym czynnikiem jest działanie użytkownika.

WARTO PRZECZYTAĆ NA TEMAT BEZPIECZEŃSTWA SAP:

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: