FAKTURY I FINANSE
OBIEG DOKUMENTÓW I ARCHIWIZACJA
E-COMMERCE
BEZPIECZEŃSTWO
ANALITYKA
MARKETING
DIGITALIZACJA TREŚCI
ROBOTYZACJA PROCESÓWBezpieczeństwo SAP – od czego zacząć?
- Bezpieczeństwo
Od wielu lat spotykając się z C-Level, dyskutując o bezpieczeństwie SAP dostaję zwrotnie taki komunikat:
“wydaliśmy kilka milionów złotych na wdrożenie SAP i Pan chce powiedzieć, że to nie jest bezpieczny system?”
Jakby na to nie patrzeć – pytanie w punkt. W końcu potężny vendor, mnóstwo partnerów wdrożeniowych, ogromne kompetencje, rozwój narzędzia oraz permanentne wsparcie producenta.
Odpowiedź na pytanie jest prosta – SAP jest bezpieczny, ale…
“Ale” nr 1 – konfiguracja
To Klient odpowiada za odpowiednie sparametryzowanie systemu. Jest masa ustawień konfiguracyjnych, których niepoprawna definicja może doprowadzić do szeregu niebezpiecznych sytuacji.
Przykład:
hasła kont domyślnych powinny zostać zmienione, a profile wysoko uprzywilejowane (np. SAP_ALL) powinny zostać usunięte.
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*).
To Klient odpowiada zatem za to, by te parametry dostosować do swoich potrzeb.
W kwestii technicznej dodatkowo SAP regularnie reaguje na znalezione podatności (vulnerabilities), publikując noty bezpieczeństwa, które skutecznie ładają dziury oraz ryzyka. Jednak to od Klienta zależy odpowiednie wgranie noty, a to nie zawsze jest proste i szybkie.
Przykład:
Komunikacja bez enkrypcji – często wręcz wymuszona przez skomplikowane środowiska łączące się do systemu. Wystarczy nasłuchiwać w sieci wewnętrznej by dostać treść komunikacji.
Zwróć uwagę, na powyższą architekturę. Nie można zapominać o wszystkich warstwach, również tych „pod” warstwą aplikacji. Zatem odpowiednie sparametryzowanie DB czy OS jest kluczowe, aby sprytny użytkownik nie miał możliwości obejścia swoich autoryzacji.
„Ale” nr 2 – autoryzacje
Obserwując projekty wdrożeniowe SAP można odnieść wrażenie, że kwestie bezpieczeństwa jeśli w ogóle zostały zaadresowane – to traktowane są po macoszemu. Nie widziałem wdrożenia SAP, w którym kompleksowo zajętoby się stworzeniem takiej koncepcji uprawnień, w których temat krytycznych autoryzacji i konfliktów uprawnień byłby wiodącym elementem.
W sumie można się nie dziwić, jeśli wdrożenie musi skończyć się w odpowiednim czasie i budżecie – najważniejszymi elementami takiego wdrożenia jest szybkie uruchomienie funkcjonalności biznesowych (i z tym w żaden sposób nie polemizuję).
W końcu SAP dostarcza predefiniowane role i profile, i bardzo łatwo można rozpocząć prace z nimi. Jest to droga na skróty, która może odbić się czkawką przy audytach, lub (co gorsze) w skutecznych nadużyciach ze strony użytkowników.
Jeśli mowa o nich – użytkownicy w dojrzałych systemach, gdzie historycznie „podróżowali” po organizacji, mają zbyt dużo uprawnień. Jest to konsekwencja tejże „podróży”, oraz konkretnej cechy SAP – uprawnień dodatnich. W SAP nie można po prostu odjąć uprawnień, wektor jest tylko dodatni. Dodatkowo odjęcie autoryzacji w roli rozpropaguje się na innych użytkowników momentalnie.
To wszystko powoduje, że gdy przysłowiowy Kowalski pracuje w organizacji wiele lat – role są częściej dopisywane niż zabierane. A tu dochodzimy do jakże nie miłej dla oka wartości:
10%
To jest średnia wartość wykorzystanych autoryzacji w systemach, które mieliśmy okazję badać pod kątem bezpieczeństwa. Oznacza to ni mniej ni więcej, że 90% autoryzacji jest po prostu niepotrzebnych. A to prosta droga do krytycznych dostępów i konfliktów uprawnień, a więc pierwszego przylądka czerwonych lampek przy audytach.
Konflikty uprawnień – tu sprawa jest z definicji prosta.
„Utrzymuj zasadę 2 par oczu przy realizacji krytycznych procesów”.
Niemniej standardowo w SAP jest sto kilkadziesiąt tysięcy transakcji. Nie jesteśmy w stanie bez odpowiednich automatyzmów zweryfikować co oznaczają wszystkich transakcje. Mało tego osoba posiadająca wiedzę ze swojego zakresu modułów nie będzie wiedziała o innych, a kross-modułowe konflikty to zmora.
W powyższym przykładzie zwróć uwagę na kolumnę „Transakcje”.
Czy za pomocą tej nomenklatury jesteś w stanie odpowiedzieć na pytanie z jakim ryzykiem się wiąże taki zestaw transakcji?
A co jeśli powiem Ci, że tych zestawów konfliktów mogą być setki?
Wtedy zagadnienie się komplikuje.
„Ale” nr 3 – monitoring
Mniej niż ćwierć systemów klasy SIEM monitoruje aplikacje biznesowe w organizacjach globalnie (badanie HPE/2016). Nie sposób bez mozolnego definiowania ryzyk w prosty sposób stworzyć definicji ryzyk, by SOC mógł intepretować zdarzenia krytyczne.
Mnogość źródeł logów SAP jest również elementem wspierającym brak przejrzystości tego, co dzieje się w systemie.
Powyżej przykład tego, jakie grupy logów chodzą „dookoła” SAP.
Każdy z tych logów to swoiste wyzwania związane na przykład z niepoprawną klasyfikacją zdarzeń, nadpisywaniem, bądź brakiem czytelności. A to powoduje, że wyzwania z monitoringiem SAP nie są takie łatwe.
Przykład ataku
Spotkaliśmy się ze sprytnymi nadużyciami, dokonywanymi przez administratora, który realizował zamówienia towaru i ich rozliczenia (na fałszywe konta) używając wcześniej przygotowanego użytkownika. Proceder trwał około roku, i byłby niezauważony, gdyby nie zachłanność (ale o tym nie dziś).
Administrator wyszedł z założenia, że wystarczy utworzyć backdoor usera w taki sposób, by możliwie zatrzeć ślady. Proces jest prosty:
Zmieniam typ użytkownika technicznego na „service”. (Tu trzeba dodać, że użytkownik techniczny to taki, który często ma spore uprawnienia i nikt nie powinien mieć możliwości zalogowania się do niego w trybie dialogowym przez SAP GUI).
Po tej zmianie przez SU01 zakładamy użytkownika backdoor.
Tu jeszcze tylko dopiszemy sobie SAP_ALL, i nie ma granic dla naszych działań.
Na koniec sprzątanie i powrót usera technicznego do trybu System. Całość trwa nie więcej niż 5 minut. Spójrzmy na ślady w systemie. Zajrzyjmy do SAL:
A tam:
- brak info o profilu SAP_ALL
- brak info o zmianie usera techniczne w tryb serwisowy
- na czerwono utworzenie użytkownika (tak, SAL na czerwono pokazuje utworzenie każdego użytkownika, więc w gąszczy codziennych zajęć łatwo przeoczyć).
Można oczywiście wspomóc się gotowymi narzędziami jak SAST Security Radar, który tego typu scenariusze ma zaszyte w bibliotekach, w teraz takie działanie nie przejdzie bez echa.
I tu cały zestaw alertów, np.:
- zmiana trybu na service i logowanie dialogowe usera technicznego,
- dopisanie SAP_ALL.
PODSUMOWANIE
SAP jest bezpieczny sam w sobie. Jednak to od działań Klienta zależy w jaki sposób zadbamy o kwestie bezpieczeństwa danych. W tym konkretnie kontekście nie sposób zignorować dobrodziejstw inwentarzy, jakimi są dedykowane narzędzia do SAP Security.
Im bardziej kompleksowo zaadresowane są tematy bezpieczeństwa (czyli zarówno kwestie monitoringu, autoryzacji i techniczne są dostarczane) – tym mniejsze ryzyka dla Twoich danych.
Więcej z kategorii
- Bezpieczeństwo
Tomasz Jurgielewicz
Head of Security Department w Lukardi. Od 10 lat prowadzi zespół specjalistów SAP Security, dostarczając kompleksowe usługi i narzędzia do zabezpieczenia systemów SAP oraz optymalizacji licencji. Doświadczenie w obszarze: - identyfikacji konfliktów uprawnień i reorganizacji autoryzacji, - identyfikacja podatności SAP, - integracja rozwiązań SIEM z SAP, - optymalizacja licencji SAP.
