Lukardi > Case study > Branża retail > Reorganizacja uprawnień SAP i SoD
BRANŻA RETAIL
Reorganizacja uprawnień SAP i SoD
Bezpieczeństwo SAP


BRANŻA RETAIL
Profil Klienta
Firma z branży retail
Lider sieci sklepów convenience w Polsce, oferujący szybkie zakupy blisko domu. Dzięki szerokiemu asortymentowi, innowacyjnym rozwiązaniom i usługom, marka odpowiada na codzienne potrzeby klientów, łącząc wygodę z nowoczesnością.
Wyzwania
Klient mierzył się z kilkoma problemami w zakresie zarządzania uprawnieniami SAP w tym:
Brak kontroli nad zawartością ról (role „puchły”, czyli ciągle były przypisywane nowe transakcje, brak właściciela, brak cyklicznych weryfikacji ról)
Duża liczba konfliktów SoD, a co za tym idzie, wysoki poziom niebezpieczeństwa tj. możliwość dokonania szkód w firmie poprzez nadane uprawnienia znacznie wykraczające poza codzienne obowiązki pracy
Analiza
Podczas audytu SoD wykonanym narzędziem SAST Authorization Management, okazało się, iż na systemie produkcyjnym (S4) liczba konfliktów jest o wiele za duża niż próg tolerancji ryzyka w organizacji. Biorąc pod uwagę charakter zwinny projektu oraz ścisłą współpracę z użytkownikami biznesowymi, skupiliśmy się na jakości reorganizacji uprawnień SAP a nie szybkości przeskakiwania do kolejnych etapów projektu oraz startu produkcyjnego. Po ponad roku skończyliśmy projekt we wszystkich obszarach Finansowych lub okołofinansowych, m.in: Księgowości, Controllingu, Kontroli Biznesu, Skarbu.
Kluczowym etapem na pewno był moment tworzenia nowej Koncepcji Uprawnień oraz wdrożenie procesów i tzw „właścicielstwa” (eng. Ownership) nowych ról SAP. Był to etap przełomowy, gdyż należy wziąć pod uwagę, iż w wielu przedsiębiorstwach odpowiedzialność za zawartość ról SAP (transakcje, raporty, tabele, wartości aktywności) jest przenoszona z Biznesu do IT. Jesteśmy świadomi, że tak nie powinno być, prawda? Dlatego widząc entuzjazm klienta po stronie biznesowej, aby poznać najważniejsze zagadnienia i najlepsze praktyki w zakresie podziału i zarządzania uprawnieniami na pewno dodał całemu zespołowi projektowemu skrzydeł.
Projekt w Finansach został zakończony pomyślnie,
wdrożony model koncepcji funkcjonuje bez zakłóceń w działach, które brały dział w projekcie. Po Finansach przyszedł czas na podobny projekt w Departamencie HR. Aktualnie projekt reorganizacji uprawnień i SoD realizujemy w obszarze zakupów. Cieszy nas zaufanie klienta i wdrażanie najlepszych praktyk w kolejnych działach oraz systemach SAP".
Bernadeta Szwarc
Project Manager / Lukardi S.A.
Kluczowe informacje o projekcie
Etapy projektu
Analiza
Koncepcja i konfiguracja
Faza testów
Start produkcyjny
Implementering
Etap 1: Analiza
Projekt reorganizacji uprawnień i SoD to projekt koncepcyjny. Należy się odpowiednio zastanowić co chcemy osiągnąć w projekcie, które ryzyka są akceptowalne, a których musimy się pozbyć. Dlatego faza pierwsza – FAZA ANALIZY – jest najważniejszą fazą projektu. Należy skupić się na tym co widzimy w systemie SAP (czytaj: aktualny stan ról vs wykorzystywane transakcje, raporty, wyświetlane i edytowane tabele) i rozpocząć rozmowy, na których będą obecni reprezentanci strony biznesowej oraz administratorzy SAPa ze strony technicznej. Z takich warsztatów każdy uczestnik powinien wyjść z podstawową wiedzą z zakresu bezpieczeństwa SAP oraz konkretnymi zadaniami.
Aby zweryfikować „AS IS” (stan obecny) korzystaliśmy z narzędzia SAST Authorization Management, który pozwala m.in. na:
raport wykorzystywanych transakcji i raportów w interesującym nas okresie czasu
raportu zużycia transakcji w danej roli (odpowiada na pytania: czego na pewno nie potrzebujemy zawierać w roli)
raport aktualnie przypisanych ról do użytkowników (tak jak SUIM, ale jest więcej przydatnych projektowo danych)
raport SoD na konkretnych użytkownikach/grupach z opisami ryzyk
Powyższe raporty to nasz punkt startowy w każdym projekcie. Dowiedzmy się jak wygląda sytuacja, KTO ma dostęp do CZEGO i KIEDY wykorzystywał (krytyczne) uprawnienia.
Etap 2: Koncepcja i konfiguracja
W kolejnych fazach projektu gdy już „wiemy co mamy”, czego chcemy w projekcie i do czego nie powinniśmy mieć dostępu na systemie w SAP, możemy skupić się na pracy koncepcyjnej oraz konfiguracyjnej. Po okresie spotkań, analizy, wspólnych warsztatach, negocjacjach („nie używam tych transakcji, ale może się przydać”, „chyba nie zabierzecie mi potrzebnych do pracy uprawnień?”) jest to już często czysta przyjemność.
Etap 3: Testy
Dla fazy testów istotną kwestią jest odpowiednie środowisko testowe, czyli warto pomyśleć o świeżej kopii systemu produkcyjnego, tak aby testujący przedstawiciele strony biznesowej mogli w pełni (lub choćby w bardzo przybliżony) przetestować nowe role przed przeniesieniem ich na system produkcyjny.
Etap 4: Start produkcyjny
Końcowa faza to przekazanie i wspólne omówienie (bardzo ważne) stworzonej Koncepcji Uprawnień. Należy upewnić się, że konwencja i nomenklatura są jasne dla użytkowników biznesowych oraz technicznych oraz że odpowiedzialność za zarządzanie koncepcją została jasno rozdzielona i przypisana. Start produkcyjny organizujemy w dwóch etapach, najpierw pilot, czyli przypisanie nowych uprawnień części użytkowników. Hypercare trwa około dwóch tygodni. Po pomyślnym pilocie, reszta użytkowników może zacząć pracować na nowych uprawnieniach. Dzięki takiemu modelowi udało nam się uniknąć zastopowania czy zakłócenia krytycznego procesu biznesowego podczas ostatniej fazy projektu.
Efekty projektu
Warsztaty i wspólne testy z użytkownikami biznesowymi umożliwiły transfer wiedzy w obu kierunkach (Biznes – IT) oraz rozpoczęły wspólne działania na przyszłość w kwestii bezpieczeństwa SAP
Wdrożono nowe procedury uszczelniające procesy zarządzania uprawnieniami SAP
Wdrożono Koncepcję Uprawnień jako dokument „który żyje” czyli jest głównym odnośnikiem dla Biznesu i IT podczas zarządzania uprawnieniami SAP
Zminimalizowano dostęp do krytycznych autoryzacji w obszarze FI
Zminimalizowano liczbę konfliktów SoD


Produkt | Przed projektem | Po projekcie |
Departamentowe Koncepcje Uprawnień | 0 | 5 |
Właściciele działowych/obszarowych ról SAP | 0 | 21 |
Max. liczba transakcji w rolach | 750 | 50 |
Liczba konfliktów SoD % statystycznie w działach biorących udział w projekcie | 100% | 30%* |
*wyeliminowano 70% konfliktów SoD
Podsumowanie
Oprócz wyżej wymienionych rezultatów na pewno dużą zmianą na lepsze było „zapanowanie” nad rolami SAP i wyłonienie właścicieli odpowiedzialnych za nowe role. Czasami aby rozpocząć działania porządkujące odstrasza nas nawarstwienie bałaganu i zapominamy o najprostszych rozwiązaniach. Najprostsze rozwiązanie w kwestii reorganizacji ról SAP: nadać dostęp do minimalnego wymaganego minimum.
Z drugiej strony, zauważyliśmy pewnego rodzaju komfort psychiczny Keyuserów, którzy byli świadkami odebrania krytycznych uprawnień osobom spoza obszaru finansowego. Oprócz działania naprawczego czyli odebrania uprawnień, wdrożyliśmy kontrolę prewencyjną czyli zabezpieczono krytyczne transakcje oraz tabele w matrycy SoD, która z zasady w przyszłości nie pozwali administratorowi dodawać do ról spoza obszaru finansowe zdefiniowanych krytycznych uprawnień.
Dina behov,
vårt stöd.
Låt oss prata
Dina behov, vårt stöd.
Låt oss prata
Dina behov, vårt stöd. Låt oss prata om det