Przejdź do treści

Hardening SAP - dlaczego to proces, nie projekt

Wasza firma stoi na dokumentach, a te na fundamencie SAP. Pokazujemy w 90 sekund, jak wygląda pięć warstw hardeningu i dlaczego jedna łatka nie wystarczy.

Film „Firma z dokumentów" - hardening SAP w 90 sekund, w technice wycinanki.

Wyobraźcie sobie, że cała Wasza firma to jedna wysoka wieża. Zbudowana z kartek: faktury, listy płac, zamówienia, potwierdzenia dostaw. Wszystko, co się w firmie dzieje, wcześniej czy później staje się dokumentem. A ten dokument leży w SAP-ie.

Teraz wyobraźcie sobie rękę, która wysuwa z fundamentu tej wieży jedną kartkę. Nie kradnie danych po cichu. Po prostu pociąga za jeden słaby punkt i patrzy, jak cała konstrukcja się chwieje.

Ten film pokazuje dokładnie ten moment. I to, co można zrobić, zanim się wydarzy.

Fundament, o którym nie myślimy, dopóki nie zadrży

SAP rzadko trafia na pierwszą stronę planu bezpieczeństwa. Chronimy styk z internetem, pocztę, stacje robocze. Tymczasem system obsługujący finanse, kadry i cały obieg dokumentów często pracuje na ustawieniach sprzed lat.

Cztery miejsca, które administrator SAP zna aż za dobrze:

  • Klucz pod wycieraczką. Konto SAP* z domyślnym hasłem, którego nikt nie zmienił po instalacji. Wpisane w każdym podręczniku dla atakującego.
  • Pożółkłe kartki. Kernel i łatki z datą, przy której trudno nie westchnąć. Każdy niezałatany miesiąc to znana, opisana luka.
  • Luźne zakładki. Interfejsy RFC otwarte i nieszyfrowane. Pociągniecie jedną i wysuwacie całe segregatory z sąsiedniego systemu.
  • Jeden pęk kluczy. Użytkownik z uprawnieniami do wszystkiego, bo „tak było szybciej”. Jeden przejęty login i atakujący ma tyle samo dostępu, co on.

Żaden z tych punktów nie jest egzotyczny. To codzienność audytów SAP.

Pięć warstw, nie jedna łatka

Hardening SAP to nie jedna decyzja ani jednorazowy projekt z datą końca. To warstwy, które razem sprawiają, że wysunięcie jednej kartki przestaje ruszać całą wieżą.

  1. Kernel i patche. Wymieniacie pożółkłe kartki, zanim ktoś je rozerwie. Aktualny kernel to najniższy próg wejścia, a i tak często pomijany.
  2. Konfiguracja. Parametry systemu ustawione świadomie, nie fabrycznie. Domyślne wartości pisano pod wygodę instalacji, nie pod Wasze ryzyko.
  3. Uprawnienia. Każdy nosi jeden klucz do swoich drzwi. Zasada minimalnego dostępu brzmi banalnie, dopóki nie policzycie, ile kont w Waszym systemie ma za dużo.
  4. Interfejsy. Każda zakładka wpięta, opisana i szyfrowana. RFC, o którym wiecie, dokąd prowadzi i kto z niego korzysta.
  5. Monitoring. Wartownik, który widzi każdą rękę wyciągniętą po Wasze dokumenty. Bo najlepszy hardening i tak zakłada, że ktoś spróbuje - tu z pomocą przychodzą platformy klasy SecurityBridge, które wychwytują podejrzane zdarzenia w czasie rzeczywistym.

Żadna z tych warstw nie jest darmowa. Aktualizacja kernela wymaga okna serwisowego. Porządek w uprawnieniach potrafi odsłonić, że połowa ról powstała ad hoc przez ostatnie lata. Monitoring bez kogoś, kto reaguje na alerty, to tylko droższy dziennik zdarzeń. Dlatego mówimy o procesie, nie o jednym wdrożeniu.

Od czego zaczynamy

W SNOK zaczynamy od audytu fundamentu: sprawdzamy, gdzie leży klucz pod wycieraczką i które zakładki sterczą luzem. Dopiero potem wzmacniamy system warstwa po warstwie, w tempie, które Wasza produkcja wytrzyma.

Jeśli działacie w sektorze objętym NIS2 albo DORA, hardening SAP przestaje być kwestią dobrej praktyki i staje się elementem zgodności. Sprawdźcie stan fundamentu, zanim zrobi to za Was audytor. Albo ktoś, kto nie przyszedł z audytem.

Tematy: hardening SAP bezpieczeństwo SAP SAP Basis SAP security SAP* RFC kernel SAP NIS2 audyt SAP
Spodobał się artykuł? Proszę podać go dalej:

Skontaktuj się z nami