Muss es schmerzhaft sein, SoD-Konflikte und SAP-Ansprüche neu zu ordnen?
Lukardi > Blog > Sicherheit > Muss es schmerzhaft sein, SoD-Konflikte und SAP-Ansprüche neu zu ordnen?
- Sicherheit
Auf der Konferenz "SAP Security - Tipps für die Sicherheit" habe ich meine Erkenntnisse aus den Projekten zur Umstrukturierung von SoD und Berechtigungen sowie aus der täglichen Arbeit im Rahmen der Managed Services mit Ihnen geteilt. Für diejenigen unter Ihnen, die nicht an der Konferenz teilnehmen konnten, habe ich eine kurze Zusammenfassung vorbereitet.
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:
- 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? - 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ć?
- 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ń |
Prozess | 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:
- Analiza aktualnych konfliktów SoD, problemów autoryzacyjnych, stanu ról, stanu procedur
- Planowanie zadań i odpowiedzialności w PRU, nowa Koncepcja Uprawnień
- Konfiguration nowych ról, Firefighter
- Testy/Pilot
- 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.
- 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ń
- 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.
Bernadeta Szwarc
- 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
- 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.