Od strony technicznej tworzenie uprawnień w systemach SAP jest względnie prostą operacją. Jeśli wiemy, do jakich transakcji/programów chcemy nadać uprawnienia, oraz jakie mają być ograniczenia, stworzenie odpowiedniej roli nie wydaje się skomplikowane. Obraz staje się jednak mniej czytelny, kiedy spojrzymy na uprawnienia z perspektywy całego systemu.

W złożonych funkcjonalnie systemach jak rozwiązania SAP kluczowe jest takie zaprojektowanie siatki uprawnień, aby możliwe było przejrzyste ich przypisywanie do odpowiednich stanowisk (użytkowników). Wyzwaniem jest pogrupowanie uprawnień w rolach w taki sposób, aby możliwe było ich wielokrotne wykorzystanie, przy jednoczesnym uwzględnieniu faktu, że uprawnienia pojedynczych użytkowników często nieznacznie się różnią (co komplikuje grupowanie).

Na przykład wszyscy pracownicy zatrudnieni na stanowisku specjalisty ds. administracji kadrami korzystają z tego samego zbioru ról, a dodatkowo dla wybranego pracownika uprawnienia mogą być rozszerzone do funkcjonalności zarządzania czasem pracy lub zakładowym funduszem świadczeń socjalnych.

W całym procesie bardzo istotne jest również podejście do późniejszych zmian uprawnień (tworzenie nowych bądź modyfikacja istniejących ról). Częste zmiany uprawnień, niejednokrotnie ad hoc, wykonywane w oderwaniu od początkowej koncepcji, powodują, że po kilku latach użytkowania stwierdzamy, że użytkownicy posiadają znacznie szersze uprawnienia niż powinni. Dodatkowo, ze względu na wprowadzane zmiany, zaciera się definicja konkretnych ról. Skutkuje to np. dużą ilością konfliktów, kiedy wprowadzamy zasady SoD (Segregation of Duties) i zwiększa się ryzyko nieautoryzowanego dostępu do danych.

Poniżej prezentujemy podstawowe zasady, które warto wziąć pod uwagę przy tworzeniu bądź reorganizacji uprawnień w systemach SAP.

Analiza aktywności

Pierwszym i najbardziej istotnym krokiem przy tworzeniu lub reorganizacji uprawnień jest zebranie pełnych informacji o aktywności użytkowników w systemie. Informacje, jakie transakcje, programy wykorzystywane są na danym stanowisku, jakie są ograniczenia (np. jednostka gospodarcza, kanał sprzedaży itp.) są kluczowe.

Takie informacje powinny się znajdować np. w dokumentacji procesów biznesowych. Jeśli obawiamy się, że nasza dokumentacja nie jest kompletna i aktualna, to możemy takie informacje zebrać od użytkowników kluczowych.

Pomocne mogą być również narzędzia zbierające informacje o aktywności użytkowników, takie jak:

  • ST01 – System Trace,
  • SM20 – Security Audit Log.

Fragment logu security dla użytkownika BCCBASIS

Finalnie powinniśmy dysponować arkuszem, który opisuje aktywności wszystkich użytkowników na poszczególnych stanowiskach. Ze względu na dużą liczbę informacji arkusze warto podzielić np. ze względu na moduły (jeden arkusz dla każdego modułu).

Przykładowy fragment arkusza aktywności/uprawnień

Grupowanie autoryzacji w rolach

Kiedy zgromadziliśmy już komplet informacji o aktywności użytkowników z danego modułu, możemy przystąpić do grupowania autoryzacji w role. Jeśli dysponujemy dobrze przygotowanym arkuszem, jest to relatywnie proste. Możemy wizualnie ocenić, które transakcje można zgromadzić w jednej roli, tak aby można ją było wykorzystać na kilku stanowiskach.

Grupowanie transakcji w role

Jak łatwo zauważyć, w przykładzie zamieszczonym w arkuszu powyżej wystarczy utworzyć trzy role. Oczywiście nie zawsze sytuacja będzie tak przejrzysta, może się zdarzyć, że na określonych stanowiskach wymagany będzie dostęp do pojedynczych transakcji i wtedy zmuszeni będziemy utworzyć większą liczbę „drobnych” ról.

Na tym etapie powinniśmy tworzyć role jako role pojedyncze. Ewentualnie możemy również wykorzystać role pochodne (derived roles), w sytuacji kiedy np. na kilku stanowiskach mamy takie same aktywności (transakcje/programy), a różnice polegają na ograniczeniach takich jak np. inne jednostki gospodarcze. Wykorzystanie ról pochodnych pozwoli nam łatwiej modyfikować role w przyszłości.

W kolejnym kroku opisujemy nasze role tak, aby możliwe było ich łatwe utworzenie w systemie. Ponieważ pojedyncza rola może zawierać dziesiątki obiektów autoryzacji, warto przyjąć założenie, że na arkuszu umieszczamy tylko te informacje, które są niezbędne do utworzenia roli. Pomijamy obiekty autoryzacji, których nie wypełniamy (mają standardowe wartości), jak również te, które mają pełne uprawnienia (*). Wszystkie obiekty, które nie mają wartości, oraz te, które modyfikujemy (zmieniamy standardową wartość), powinny się znaleźć na arkuszu.

Tak przygotowany arkusz pozwoli na utworzenie w systemie ról pojedynczych przez osobę, która niekoniecznie musi być zaangażowana w projekt tworzenia uprawnień.

Arkusz ról

Przypisanie uprawnień użytkownikom

Przygotowane role pojedyncze najlepiej zgrupować w role złożone. Takie podejście zdecydowanie ułatwia przypisywanie uprawnień użytkownikom.

Rekomendujemy, aby jedna rola złożona odpowiadała stanowisku. W ten sposób przypisanie uprawnień do użytkownika wymaga przypisania tylko jednej roli (role pojedyncze zostaną przypisane pośrednio przez rolę złożoną).

Fragment arkusza ról złożonych

Podział obowiązków

Tworząc uprawnienia, warto pamiętać o podziale obowiązków (Segregation of Duties). Mając przygotowane odpowiednie macierze konfliktów, możemy, już na etapie analizy aktywności, sprawdzać, czy przypisane do stanowiska aktywności nie kolidują ze sobą.

Po utworzeniu ról w systemie SAP proces sprawdzania konfliktów SoD możemy zautomatyzować, korzystając z dodatkowych narzędzi, takich jak SAP GRC lub narzędzia firm trzecich, albo posiłkować się rozwiązaniami, które są dostępne w systemie, takimi jak funkcjonalność analizy krytycznych kombinacji (raport RSUSR008_009_NEW).

Niestety, przygotowanie odpowiednich definicji krytycznych autoryzacji, a następnie pogrupowanie ich w odpowiednie kombinacje odpowiadające konfliktom, wymaga sporego nakładu pracy.

O czym warto pamiętać

Realizując projekt reorganizacji czy tworzenia uprawnień, warto pamiętać o kilku podstawowych zasadach.

  • Właściwe zaprojektowanie ról wymaga wiedzy z danego obszaru/modułu SAP, dlatego do projektu warto zaangażować osoby, które znają specyfikę danego obszaru (np. użytkowników kluczowych lub konsultantów modułowych).
  • Jeśli role nie zostały dobrze zaprojektowane, to suma uprawnień z kilku ról może pozwolić użytkownikowi na szerszy dostęp, niż pierwotnie zakładaliśmy.
  • Nowo utworzone role powinny zostać przetestowane. Jako scenariusz testów możemy wykorzystać arkusz aktywności.
  • W przypadku problemów do analizy warto wykorzystać zbiór raportów dostępnych z tr. SUIM. Za ich pomocą możemy wyszukać określone informacje (role, użytkowników, przypisania itp.), jak również prześledzić zmiany wprowadzane w uprawnieniach, korzystając z dokumentów zmian.
  • Tworzone role powinny mieć spójne, czytelne nazwy, tak aby łatwo można było je identyfikować i kojarzyć, czego dotyczą.

Jeśli mamy do czynienia z systemami, na których zdefiniowano wiele mandantów, to warto rozważyć konfigurację centralnego zarządzania użytkownikami (CUA), aby usprawnić przypisywanie uprawnień do użytkowników (zamiast wykonywać ją na każdym mandancie osobno, możemy realizować centralnie, z jednego miejsca).