Lukardi

Migration zu S/4HANA - Herausforderungen bei Sicherheit und Autorisierung

Udostępnij

Es wird geschätzt, dass bis 2020 etwa 30% Unternehmen weltweit S4/HANA in der Produktion einsetzen werden (2018 nutzten nur 2% aller Unternehmen S4). Ich werde zwei Bereiche erörtern, die angegangen werden sollten, wenn wir das Sicherheitsniveau des Zielsystems anheben (oder hoch halten) wollen - Berechtigungen und technische Ebene.

Warstwa autoryzacji

Ze względu na to, że S/4HANA to nowe rozwiązanie z rodziny SAP (a nie tylko ewolucja SAP ERP) – przeniesienie autoryzacji do nowego środowiska nie może zostać zrealizowane bez odpowiedniej adaptacji (np. część autoryzacji nie ma w S/4).

Jakie działania należy podjąć, by przekonwertować autoryzacje?

Na początku należy podjąć decyzję – czy dla docelowego środowiska wystarczy przenieść (z odpowiednią adaptacją) obecne role (podejście brown field) czy rozpocząć prace nad nowym zestawem ról (podejście green field). Oba podejścia mają swoje wady i zalety. Wszystko zależy przede wszystkim od stanu obecnego poziomu wykorzystania nadanych autoryzacji. Z doświadczenia wiemy, że średnia wartość wykorzystania nadanych uprawnień dla przeciętnej organizacji (która posiada SAP od co najmniej kilku lat) to wartości pomiędzy 10-15%. A to może oznaczać, że nadane uprawnienia w rolach nie są optymalne – należy zatem skalkulować wybór podejścia (często przy takich statystykach wykorzystania to właśnie greenfield jest najlepszym podejściem).

Dla podejścia brownfield wykorzystujemy narzędzia SAST, które wspierają konwersję autoryzacji do S/4HANA (wymagana jest część manualnej pracy). Dla testowania nowych ról – wdrażamy narzędzie ułatwiające wdrożenie produkcyjne ról (o czym za chwilę).

Przy podejściu greenfield pracujemy na metodyce utworzenia ryzyk oraz ról (bazując na szablonach ról wolnych od konfliktów dedykowanych dla S/4HANA). Tu również wspieramy testowanie produkcyjne ról.

Należy również zweryfikować dostępy krytyczne w rolach i konflikty uprawnień oraz zaktualizować SU24. Generalnie – bez reorganizacji koncepcji autoryzacji migracja jest niemożliwa.

Bezpieczne uruchomienie ról na systemie produkcyjnym – testowanie

Każda praca projektowa, w której zaangażowani są użytkownicy testowi, jest zagrożona niedopatrzeniami. Utworzenie nowych ról i przetestowanie ich przed wdrożeniem produkcyjnym jest kluczowe z punktu widzenia realizacji procesów biznesowych. Jeśli nowe role nie są wystarczająco przetestowane – istnieje ryzyko braku możliwości realizacji swoich zadań. Dlatego wprowadziliśmy wsparcie tego etapu, automatyzując proces testowy (nadawanie, tworzenie testuserów) oraz wdrażając możliwość awaryjnego powrotu do starych autoryzacji (fallback user).

W praktyce wygląda to tak:

1 – utworzone (i wstępnie przetestowane) role zostają przypięte do użytkowników (zastępując stare role),

2 – w przypadku, gdy użytkownik nie może wykonać jakiegoś działania (brak możliwości pracy) – powraca awaryjnie do starego zestawu ról (dzieje się to w sposób automatyczny, czynność trwa 1-2 minuty),

3 – administrator dostaje informacje o działaniach użytkownik, które różnią się od nowego zestawu ról – na tej podstawie podejmowana jest decyzja o ewentualnym uzupełnieniu nowych ról dla użytkownika.

Przy użyciu funkcji fallback – działania na systemie produkcyjnym nie mają przestoju, nawet w przypadku błędów w tworzeniu/testowaniu autoryzacji.

Warstwa techniczna

Nowe instalacje S4 posiadają szereg ryzyk już w samej domyślnej konfiguracji (out of the box Klient dostaje zatem zestaw parametrów, które powinien dostosować, by podnieść poziom bezpieczeństwa). Ryzyka w docelowej infrastrukturze S/4HANA generalnie zawierają się dwóch obszarach: niebezpieczna konfiguracja systemu oraz luki w klienckich rozwiązaniach ABAP.

Robimy sporą ilość audytów bezpieczeństwa, realizujemy również testy penetracyjne. Doświadczenie zdobyte podczas takich projektów potwierdza, że głównymi powodami generującymi problemy związane z bezpieczeństwem SAP są:

– brak wdrożonych wytycznych bezpieczeństwa (lub brak patchy),

– brak separacji w sieci,

– brak narzędzi monitorujących.

Model procesu dla bezpiecznej migracji to SAP HANA

Weryfikacja poziomu bezpieczeństwa

1 – zweryfikuj poziom bezpieczeństwa docelowego systemu (przydadzą się dobre praktyki rynku bezpieczeństwa SAP, identyfikujące najbardziej palące problemy),

2 – znalezione ryzyka ułóż w raport wraz z informacją o działaniach naprawczych,

3 – utwórz priorytety dla ryzyk by podnieść bezpieczeństwo.

Podniesienie poziomu bezpieczeństwa

Na podstawie raportu, ryzyk i priorytetów zacznij uszczelniać środowisko. Pamiętaj, że ważne są również warstwy poniżej warstwy aplikacji SAP (OS/net/DB) oraz klienckie rozszerzenia ABAP (które mogą zawierać krytyczne funkcje, wywołania, bądź są pozbawione obiektów autoryzacji).

Ważne by w prace były zaangażowane osoby odpowiedzialne za obszar, by potwierdzić, że zmiany nie wpłynęły na dotychczasowe procesy. Jednym z wyzwań to niewątpliwie klienckie programy ABAP. Organizacje rzadko posiadają szczegółowe opisy wszystkich programów oraz równie rzadko posiadają wiedzę odnośnie tych programów, które są szczególnie wykorzystywane. Objawia się to tym, że w gąszczu kilku tysięcy Zetek zaledwie kilkadziesiąt/kilkaset to te wykorzystywane w codziennej pracy. Należy zatem zebrać odpowiednie informacje odnośnie wykorzystywania programów. Identyfikujemy programy, które nie są używane oraz minimalizujemy ryzyko metodyką „Soft Cleaning”. Dzięki temu podejściu jesteśmy w stanie ograniczyć koszty migracji, a sam element czyszczenia kodu jest o 80% szybszy (i tańszy) niż standardowe podejście.

Monitoring bezpieczeństwa

Po uszczelnieniu środowiska – zacznij monitorować je. Każda krytyczna zmiana ustawień powinna zostać od razu wyłapana. I tutaj również dotyczy to tych warstw, które są ważne z punktu widzenia SAP.

Podsumowanie

Bez względu na rozmiar środowiska oraz jego zakres – w ramach migracji do S/4HANA sugerujemy przyjrzenie się poziomowi bezpieczeństwa docelowej platformy. Koniec końców im wcześniej zostaną wykryte problemy bezpieczeństwa, tym niższe koszty będą związane z ich rozwiązaniem. To do organizacji należy podjęcie decyzji o niezbędnych krokach oraz ograniczeniu ryzyka. My jesteśmy w stanie pomóc na każdym etapie zabezpieczenia systemu SAP.

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.