Szacuje się, że do 2020 roku około 30% firm globalnie zacznie używać produkcyjnie S4/HANA (w 2018 zaledwie 2% wszystkich firm używało S4). Omówię dwa obszary, które powinny zostać zaadresowane, jeśli mamy na uwadze podniesienie (bądź utrzymanie wysokiego) poziomu bezpieczeństwa docelowego systemu – autoryzacje oraz poziom techniczny.
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).
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.
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.
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.
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.
autor: /Tomasz Jurgielewicz/
