Systemy SAP obsługują 77% globalnych transakcji biznesowych i przechowują najbardziej wrażliwe dane finansowe, kadrowe oraz operacyjne organizacji. W 2024 i 2025 roku nastąpił wzrost o 210% aktywnej eksploatacji podatności SAP, a ceny exploitów na czarnym rynku sięgają 250 000 dolarów. Raporty branżowe dokumentują 400-procentowy wzrost incydentów ransomware dotykających systemy SAP od 2021 roku. Te liczby jednoznacznie wskazują, że regularne testy penetracyjne systemów ERP przestały być opcją — stały się fundamentalnym wymogiem bezpieczeństwa.
W Polsce temat nabiera szczególnego znaczenia w kontekście nadchodzących regulacji NIS2, obowiązującej od stycznia 2025 roku dyrektywy DORA oraz nowelizacji ustawy o Krajowym Systemie Cyberbezpieczeństwa. Dla instytucji publicznych, które z różnych względów muszą utrzymywać środowiska on-premise, wyzwania są jeszcze bardziej złożone.
Czym właściwie są pentesty SAP i dlaczego różnią się od standardowych testów bezpieczeństwa?
Testy penetracyjne systemów SAP to kontrolowane, autoryzowane próby włamania do środowiska ERP, przeprowadzane przez wykwalifikowanych specjalistów. Ich celem jest identyfikacja podatności zanim zrobią to prawdziwi atakujący. Brzmi prosto, ale diabeł tkwi w szczegółach.
Standardowe testy penetracyjne infrastruktury IT koncentrują się na systemach operacyjnych, bazach danych czy aplikacjach webowych. Pentesty SAP wymagają zupełnie innego zestawu kompetencji. Pentester musi rozumieć architekturę ABAP, mechanizmy autoryzacyjne SAP, protokoły komunikacyjne RFC, specyfikę interfejsu Fiori oraz dziesiątki innych elementów charakterystycznych wyłącznie dla ekosystemu SAP.
Systemy SAP różnią się fundamentalnie od typowych aplikacji biznesowych. Mają własne protokoły komunikacyjne, własne mechanizmy uwierzytelniania, własną logikę autoryzacyjną opartą na obiektach autoryzacyjnych i profilach. Standardowy skaner podatności webowych nie wie, czym jest transakcja SE16, nie rozumie znaczenia obiektu S_DEVELOP, nie potrafi ocenić ryzyka związanego z destynacją RFC typu H. To jak próba diagnozowania samochodu narzędziami do naprawy roweru — teoretycznie jedno i drugie to pojazdy, ale podobieństwa kończą się na tym poziomie ogólności.
„Wielu klientów przychodzi do nas po standardowym audycie bezpieczeństwa przeprowadzonym przez firmę specjalizującą się w infrastrukturze sieciowej” — mówi Jaroslaw Kamil Zdanowski, Partner SNOK w obszarze Cybersecurity i SAP BASIS. „Audytorzy sprawdzili firewalle, przeskanowali porty, przetestowali aplikacje webowe. Wszystko wyglądało dobrze. Tymczasem system SAP pozostawał praktycznie nietkniętym — nikt nie sprawdził konfiguracji RFC, uprawnień krytycznych transakcji czy bezpieczeństwa kodu własnego. To jak zabezpieczyć wszystkie okna w domu, zostawiając otwarte drzwi frontowe.”
RFC hopping — klasyczny, ale wciąż zabójczo skuteczny wektor ataku
Interfejs RFC (Remote Function Call) to standardowy mechanizm komunikacji między systemami SAP oraz między SAP a aplikacjami zewnętrznymi. Każda organizacja korzystająca z SAP ma dziesiątki, setki, czasem tysiące połączeń RFC. Łączą systemy produkcyjne z testowymi, SAP z hurtowniami danych, moduły HR z systemami zewnętrznymi. Jednocześnie RFC stanowi jeden z najczęściej eksploatowanych wektorów ataku. Technika RFC hopping polega na wykorzystaniu słabo skonfigurowanych połączeń RFC do przemieszczania się między systemami.
Jak to działa w praktyce? Atakujący najpierw kompromituje system o niższym poziomie bezpieczeństwa — typowo środowisko deweloperskie lub testowe, gdzie kontrole są luźniejsze. Następnie identyfikuje destynacje RFC z zapisanymi poświadczeniami. Wykorzystuje te poświadczenia do połączenia z kolejnymi systemami. Krok po kroku eskaluje uprawnienia, aż dociera do systemu produkcyjnego.
Problem polega na tym, że wiele organizacji traktuje środowiska nieprodukcyjne jako mniej istotne z punktu widzenia bezpieczeństwa. Hasła są prostsze, aktualizacje rzadsze, monitoring symboliczny. Tymczasem te systemy często mają skonfigurowane połączenia RFC do produkcji — na potrzeby testów integracyjnych, migracji danych czy raportowania. Deweloper potrzebował kiedyś skopiować dane z produkcji na potrzeby testu. Administrator skonfigurował połączenie RFC z zapisanym hasłem, żeby uprościć proces. Minęły lata, nikt o tym nie pamięta, a połączenie wciąż istnieje.
Podczas profesjonalnego pentestu SAP specjaliści skanują wszystkie aktywne systemy, identyfikują destynacje RFC pomijające ręczne logowanie, sprawdzają czy odziedziczone uprawnienia na systemach docelowych nie są zbyt szerokie oraz wykrywają połączenia z przestarzałymi lub nieważnymi poświadczeniami. Istotne jest również sprawdzenie destynacji typu Trusted RFC, które umożliwiają logowanie bez hasła na podstawie zaufania między systemami.
Kluczowe obiekty autoryzacyjne wymagające weryfikacji to S_RFC kontrolujący dostęp do grup funkcji RFC, S_RFCACL odpowiadający za autoryzacje zaufanych połączeń RFC oraz S_ICF ograniczający dostęp do destynacji RFC według grup autoryzacyjnych. Typowym błędem konfiguracyjnym jest stosowanie autoryzacji z gwiazdką — wildcard umożliwiający dostęp do wszystkich modułów funkcyjnych zamiast tylko wymaganych. Pentester sprawdza również, czy użytkownicy komunikacyjni mają minimalny niezbędny zestaw uprawnień oraz czy hasła są odpowiednio złożone i regularnie zmieniane.
10KBlaze, ICMAD i najnowsze zero-daye — zagrożenia, które nie śpią
Historia bezpieczeństwa SAP zna kilka przełomowych momentów, które zmieniły postrzeganie ryzyka związanego z systemami ERP. Podatność 10KBlaze, zaprezentowana na konferencji OPCDE w 2019 roku, pozostaje aktualnym zagrożeniem dla organizacji, które nie wdrożyły odpowiednich zabezpieczeń. Wykorzystuje błędną konfigurację SAP Gateway i Message Server — domyślne ustawienie pliku ACL pozwalające na połączenia z dowolnego hosta umożliwia nieautoryzowane zdalne wykonanie kodu. Atakujący może zarejestrować się jako serwer aplikacyjny SAP i wykonywać polecenia systemu operacyjnego z uprawnieniami administratora.
Co sprawia, że 10KBlaze jest tak niebezpieczne? Domyślna konfiguracja wielu instalacji SAP jest podatna. Wiele organizacji nigdy nie zmieniło ustawień plików ACL, bo nie wiedziało o ryzyku. Atak nie wymaga uwierzytelnienia — wystarczy dostęp sieciowy do odpowiednich portów. W środowiskach, gdzie SAP jest dostępny z internetu lub z sieci wewnętrznej o szerokim dostępie, ryzyko jest znaczące.
W lutym 2022 roku amerykańska agencja CISA wydała alert dotyczący ICMAD (Internet Communication Manager Advanced Desync) — zestawu krytycznych podatności w SAP NetWeaver. Najpoważniejsza z nich otrzymała maksymalną ocenę CVSS 10.0 i umożliwia pełne przejęcie systemu bez uwierzytelnienia poprzez pojedyncze żądanie HTTP. Podatność ta jako pierwsza dotycząca SAP trafiła na listę najczęściej eksploatowanych podatności CISA. Problem dotyczy komponentu ICM odpowiedzialnego za obsługę komunikacji HTTP — czyli każdego systemu SAP z interfejsem webowym, w tym Fiori, Web GUI czy portali.
Najnowsze zagrożenie to podatność zero-day w SAP NetWeaver Visual Composer wykryta w marcu 2025 roku, również z oceną CVSS 10.0. Grupy ransomware aktywnie wykorzystują tę lukę. Atakujący potrzebowali zaledwie 24 godzin od ujawnienia podatności do rozpoczęcia skanowania podatnych systemów, a funkcjonalne exploity pojawiły się w ciągu 72 godzin. To pokazuje, jak szybko przestępcy reagują na nowe możliwości ataku.
We wrześniu 2025 roku odkryto kolejną krytyczną podatność w S/4HANA z oceną CVSS 9.9, dotykającą zarówno instalacje Private Cloud, jak i on-premise. Umożliwia użytkownikowi z niskimi uprawnieniami wstrzyknięcie dowolnego kodu ABAP, omijając kontrole autoryzacyjne — prowadzi to do pełnej kompromitacji systemu. Szczególnie niepokojące jest to, że atak może przeprowadzić każdy użytkownik z podstawowym dostępem do systemu.
„Te podatności pokazują fundamentalną prawdę o bezpieczeństwie SAP” — komentuje Michal Korzen, CTO SNOK i Enterprise & AI Architect. „Systemy ERP ewoluują, wprowadzane są nowe komponenty, interfejsy, integracje. Każda zmiana to potencjalnie nowa powierzchnia ataku. Dlatego testy penetracyjne nie mogą być jednorazowym wydarzeniem — muszą stanowić element ciągłego procesu zarządzania bezpieczeństwem. Organizacja, która przeprowadziła pentesty dwa lata temu i od tamtej pory nic nie robiła, ma fałszywe poczucie bezpieczeństwa.”
Narzędzia do pentestów SAP — arsenał etycznego hakera
Profesjonalne testy penetracyjne systemów SAP wymagają specjalistycznych narzędzi wykraczających poza standardowy arsenał pentestera. Na rynku dostępne są zarówno rozwiązania komercyjne, jak i narzędzia open source. Wybór zależy od celów testów, budżetu i dostępnych kompetencji.
Wśród platform komercyjnych SecurityBridge oferuje natywną platformę SAP z wykrywaniem zagrożeń w czasie rzeczywistym, zarządzaniem podatnościami, skanowaniem kodu ABAP i integracją z systemami SIEM. Rozwiązanie działa bezpośrednio w środowisku SAP, co zapewnia głęboką widoczność i minimalne opóźnienia w wykrywaniu zagrożeń. Onapsis Platform koncentruje się na ocenie podatności i monitorowaniu zgodności, oferując również funkcje threat intelligence specyficzne dla ekosystemu SAP. RedRays specjalizuje się w usługach pentestów SAP i skanerze bezpieczeństwa kodu ABAP, pomagając wykrywać podatności w programach własnych organizacji.
Dla organizacji poszukujących alternatyw open source, pysap stanowi bibliotekę Python obsługującą protokoły SAP — NI, Diag, Enqueue, Router, MS, RFC i HDB. Pozwala na tworzenie własnych skryptów i narzędzi do testowania. Metasploit zawiera moduły SAP umożliwiające między innymi odkrywanie usług, bruteforce logowania czy wykonanie poleceń systemu operacyjnego. Warto śledzić repozytorium auxiliary/scanner/sap w Metasploit, które jest regularnie aktualizowane o nowe techniki ataku. Nmap z dostosowanym plikiem services pozwala na wykrywanie usług specyficznych dla SAP i identyfikację wersji — wersja systemu często determinuje, które podatności są aktualne. Framework Sapyto oferuje pluginy do fazy discovery i audytu, choć wymaga nieco więcej konfiguracji niż inne narzędzia.
Kluczowe porty SAP wymagające uwagi podczas testów to: 32XX dla SAP GUI i Dispatchera, 33XX dla SAP Gateway, 36XX dla zewnętrznego Message Server, 39XX dla wewnętrznego Message Server wymagającego ścisłej kontroli, 3299 dla SAP Router, 50XX dla ICM HTTP, 81XX dla Web Dispatcher oraz 1128 dla SAP Host Agent. Każdy z tych portów może stanowić wektor ataku, jeśli jest nieprawidłowo skonfigurowany lub wystawiony na sieć.
„Narzędzia to tylko połowa sukcesu” — podkreśla Jarosław Zdanowski. „Kluczowa jest wiedza ekspercka pozwalająca interpretować wyniki i planować ścieżki ataku. Automatyczny skaner może wykryć otwarte porty i domyślne hasła. Doświadczony pentester SAP potrafi połączyć pozornie niegroźne podatności w łańcuch prowadzący do pełnej kompromitacji systemu. Widzi kontekst, rozumie procesy biznesowe, wie gdzie szukać najcenniejszych danych.”
S/4HANA, BTP i RISE — nowe architektury, nowe wyzwania
Migracja z SAP ECC do S/4HANA wprowadza istotne zmiany architekturalne wpływające na bezpieczeństwo. Konsolidacja tabel — na przykład Universal Journal zastępujący oddzielne tabele finansowe i kontrolingowe — wymaga przeprojektowania koncepcji autoryzacyjnej. Dane, które wcześniej były rozproszone w wielu tabelach z różnymi poziomami dostępu, teraz znajdują się w jednym miejscu. To upraszcza architekturę, ale wymaga przemyślenia na nowo, kto powinien mieć dostęp do czego.
Unifikacja danych master Business Partner oraz wprowadzenie interfejsu Fiori tworzą nowe wektory ataku aplikacji webowych. Fiori to nowoczesny interfejs oparty na HTML5 i OData, ale też nowa powierzchnia ataku dla tradycyjnych ataków webowych — XSS, CSRF, injection. Organizacje migrujące do S/4HANA muszą uwzględnić te zmiany w strategii bezpieczeństwa.
SAP Business Technology Platform (BTP) wprowadza model cloud security z czterema filarami — zarządzaniem bazą danych, rozwojem aplikacji i integracją, analityką oraz technologiami inteligentnymi. Kluczowe zagrożenia obejmują nieautoryzowany dostęp przez błędnie skonfigurowane konta BTP, podatności w aplikacjach własnych tworzonych w CAP lub Fiori Elements oraz słabości w rozszerzeniach firm trzecich działających jako potencjalne backdoory. BTP łączy się z systemami on-premise poprzez Cloud Connector, co tworzy dodatkowe punkty, które należy zabezpieczyć i testować.
W modelu RISE with SAP odpowiedzialność za bezpieczeństwo jest dzielona, ale często nieprawidłowo rozumiana. SAP zarządza infrastrukturą, systemem operacyjnym, bazą danych oraz podstawowym hardeningiem. Klient natomiast odpowiada za bezpieczeństwo warstwy aplikacyjnej, zarządzanie tożsamością i dostępem, decyzje o wdrażaniu patchy (nawet jeśli SAP je dostarcza, klient decyduje o terminie wdrożenia), bezpieczeństwo kodu własnego, ochronę danych oraz zgodność regulacyjną.
„Model współdzielonej odpowiedzialności bywa źródłem nieporozumień” — wyjaśnia Michał Korzeń. „Słyszę czasem: przecież SAP zarządza naszą infrastrukturą, więc bezpieczeństwo to ich problem. Nic bardziej mylnego. W RISE tracisz widoczność na poziomie systemu operacyjnego i bazy danych, chyba że zakupisz dodatkową subskrypcję. Ale odpowiedzialność za to, kto ma dostęp do jakich transakcji, jakie uprawnienia mają użytkownicy i czy Twój kod własny nie zawiera podatności — to zawsze pozostaje po Twojej stronie. SAP nie będzie zarządzał Twoimi rolami autoryzacyjnymi.”
Polski kontekst — NIS2, DORA, KSC i specyfika instytucji publicznych
Dyrektywa DORA (Digital Operational Resilience Act) obowiązuje od 17 stycznia 2025 roku i dotyczy praktycznie wszystkich podmiotów finansowych w Unii Europejskiej — banków, ubezpieczycieli, firm inwestycyjnych, instytucji płatniczych, a nawet dostawców usług IT dla sektora finansowego. Wymaga ona corocznych testów penetracyjnych dla wszystkich podmiotów objętych regulacją oraz zaawansowanych testów TLPT (Threat-Led Penetration Testing) co najmniej co 3 lata dla systemowo ważnych instytucji finansowych.
TLPT to nie są zwykłe pentesty. Muszą obejmować systemy produkcyjne, w tym SAP, jeśli jest wykorzystywany do krytycznych procesów biznesowych. Obowiązkowo zawierają purple teaming — współpracę zespołów atakujących i obrońców, gdzie obie strony uczą się od siebie. Threat intelligence musi być dostarczany przez zewnętrznego dostawcę specjalizującego się w analizie zagrożeń. Testy muszą symulować rzeczywiste scenariusze ataków stosowane przez grupy przestępcze i aktorów państwowych. Kary za nieprzestrzeganie sięgają 1% średniego dziennego globalnego obrotu — dziennie, nie jednorazowo.
NIS2 wyraźnie klasyfikuje systemy SAP ERP jako krytyczne systemy sieciowe i informacyjne dla organizacji w sektorach istotnych i ważnych. Wytyczne implementacyjne rekomendują testy penetracyjne co najmniej raz w roku lub po istotnych zmianach systemowych. Środowiska wysokiego ryzyka mogą wymagać częstszego testowania. Dyrektywa kładzie nacisk na zarządzanie ryzykiem w łańcuchu dostaw, co oznacza konieczność oceny bezpieczeństwa również u dostawców i partnerów.
Polska ustawa o Krajowym Systemie Cyberbezpieczeństwa jest obecnie nowelizowana w celu implementacji NIS2. Projekt trafił do Sejmu w listopadzie 2025 roku i wprowadza istotne zmiany. Nowa klasyfikacja dzieli podmioty na kluczowe i ważne, z różnymi poziomami wymagań i sankcji. Mechanizm samoidentyfikacji w systemie S46 wymaga od organizacji samodzielnej oceny, czy podlegają regulacji — nie można czekać, aż ktoś nas powiadomi. Osobista odpowiedzialność kierownictwa oznacza kary do 600% wynagrodzenia za niedopełnienie obowiązków związanych z cyberbezpieczeństwem. Kary finansowe dla podmiotów kluczowych sięgają 10 milionów euro lub 2% rocznych przychodów, dla podmiotów ważnych 7 milionów euro lub 1,4% przychodów.
Warto zauważyć, że regulacje wymagają nie tylko przeprowadzania testów, ale także dokumentowania ich wyników i podejmowanych działań naprawczych. W przypadku kontroli lub incydentu organizacja musi być w stanie wykazać, że proaktywnie zarządzała ryzykiem. Pentesty SAP przeprowadzone przez zewnętrzny, kompetentny podmiot stanowią silny dowód należytej staranności.
„Dla wielu polskich organizacji to będzie szok” — przyznaje Jacek Bugajski , CEO SNOK. „Dotychczas bezpieczeństwo systemów SAP traktowano jako temat wewnętrzny, do rozwiązania własnymi siłami albo do zignorowania w nadziei, że nic się nie stanie. Nowe regulacje wymuszają dokumentowanie wszystkich działań, regularne testy przez zewnętrzne podmioty, raportowanie incydentów w ściśle określonych terminach. Kierownictwo będzie osobiście odpowiadać za zaniedbania. To fundamentalna zmiana paradygmatu — z opcjonalnego do obowiązkowego, z wewnętrznego do zewnętrznie weryfikowalnego.”
Polskie instytucje publiczne stoją przed dodatkowymi wyzwaniami. Wiele z nich nie może lub nie chce korzystać z rozwiązań chmurowych, utrzymując środowiska on-premise ze względu na wymogi suwerenności danych, procedury bezpieczeństwa lub po prostu brak budżetu na migrację. Z jednej strony daje to pełną kontrolę nad infrastrukturą. Z drugiej — wymaga utrzymywania kompetencji bezpieczeństwa wewnętrznie lub poprzez zaufanych partnerów, co przy ograniczonych budżetach i trudnościach z pozyskaniem specjalistów stanowi poważne wyzwanie.
„Instytucje publiczne w Polsce operują w specyficznym środowisku” — dodaje Jarosław Zdanowski. „Mają ograniczone budżety, procedury zamówień publicznych wydłużające każdą decyzję o miesiące, często starsze wersje systemów SAP ze względu na koszty aktualizacji. Jednocześnie przetwarzają dane szczególnie wrażliwe — obywateli, świadczeniobiorców, podatników. Pentesty SAP dla sektora publicznego wymagają zrozumienia tej specyfiki i elastycznego podejścia do zakresu i harmonogramu prac.”
Automatyczne skanowanie kontra pentesty manualne — co wybrać?
Pytanie nie brzmi czy, ale jak połączyć oba podejścia. Skanowanie automatyczne zapewnia szybkie pokrycie rozległych krajobrazów SAP, konsekwentne i powtarzalne kontrole, możliwość ciągłego monitorowania oraz integrację z workflow centrum operacji bezpieczeństwa. Platformy bezpieczeństwa SAP oferują ponad 200 reguł bezpieczeństwa i mogą być wdrożone w ciągu 48 godzin. Automatyzacja jest niezbędna przy dużej liczbie systemów — organizacja z dziesiątkami instancji SAP nie jest w stanie przeprowadzać manualnych testów wszystkiego wystarczająco często.
Typowe kontrole automatyczne obejmują walidację konfiguracji względem ustalonych standardów i najlepszych praktyk SAP, weryfikację poziomu patchy i brakujących poprawek bezpieczeństwa, ocenę bezpieczeństwa destynacji RFC oraz monitoring krytycznych transakcji i autoryzacji. To fundament, bez którego trudno mówić o dojrzałym programie bezpieczeństwa SAP. Automatyczne skanery wykryją domyślne hasła, znane podatności, oczywiste błędy konfiguracyjne.
Testy manualne pozostają niezbędne przy początkowej ocenie bezpieczeństwa gdy nie znamy stanu środowiska, istotnych zmianach infrastrukturalnych takich jak migracja do S/4HANA czy wdrożenie BTP, audytach zgodności z PCI-DSS, SOX, NIST czy DORA gdzie wymagana jest niezależna weryfikacja, analizie po incydencie gdy chcemy zrozumieć jak doszło do kompromitacji, oraz badaniu podatności zero-day gdy pojawiają się nowe zagrożenia. Doświadczony pentester potrafi rozwinąć własne exploity, eksploatować relacje zaufania RFC, testować ścieżki eskalacji uprawnień, deszyfrować hasła SAP i klucze SecStore oraz przeprowadzić eskalację z bazy danych do systemu operacyjnego.
Rekomendowana częstotliwość testów to co 6-9 miesięcy jako kompromis między tradycyjnym podejściem rocznym a wymogami środowisk wysokiego ryzyka. Systemy produkcyjne powinny być oceniane kwartalnie za pomocą skanów automatycznych. Podczas migracji lub znaczących zmian zalecane są dodatkowe testy manualne. Po wykryciu krytycznej podatności testowanie powinno być natychmiastowe.
„Automatyzacja i ekspertyza ludzka nie konkurują ze sobą — uzupełniają się” — podkreśla Michał Korzeń. „Skaner wykryje znane podatności i błędy konfiguracyjne. Człowiek znajdzie logiczne błędy w procesach biznesowych, nieoczywiste ścieżki eskalacji, podatności w kodzie własnym. Skaner powie Ci, że masz użytkownika z uprawnieniami SAP_ALL. Człowiek powie Ci, że ten użytkownik to konto serwisowe używane przez system HR do synchronizacji danych i że kompromitacja tego konta oznacza wyciek danych wszystkich pracowników. Organizacje potrzebują obu perspektyw.”
Rzeczywiste incydenty — przestrogi z bankructw i wycieków danych
W sierpniu 2024 roku atak ransomware na dużą międzynarodową grupę spożywczą spowodował wyłączenie systemów SAP ERP, szyfrując systemy księgowe i finansowe. Firma była zmuszona do ręcznego prowadzenia wszystkich procesów — wystawiania faktur, zarządzania zapasami, rozliczeń z dostawcami. Szacowany czas odzyskania wynosił 5-7 miesięcy. W listopadzie 2024 roku firma złożyła wniosek o upadłość, wprost cytując naruszenie bezpieczeństwa SAP jako główny czynnik prowadzący do niewypłacalności.
Przypadek amerykańskiej firmy prowadzącej sprawdzanie przeszłości dla rządu federalnego pokazuje długoterminowe konsekwencje nieodpowiedniego zabezpieczenia SAP. Hakerzy sponsorowani przez obce państwo wykorzystali podatność w aplikacji SAP zarządzanej przez podmiot trzeci — dostawcę usług IT. Wyciekło 27 000 akt personalnych, w tym dane z poświadczeń bezpieczeństwa pracowników rządowych. Skutki były katastrofalne — firma straciła kontrakty warte 3 miliardy dolarów, zwolniła połowę pracowników, a spółka matka ogłosiła upadłość. Incydent pokazał też, jak ważne jest bezpieczeństwo łańcucha dostaw.
We wrześniu 2025 roku atak na globalnego producenta wykorzystujący najnowszą podatność zero-day spowodował 2,1 miliarda dolarów kwartalnych strat i około 260 milionów dolarów bezpośrednich kosztów związanych z incydentem — odzyskiwanie danych, prace forensic, kary regulacyjne, odszkodowania dla klientów. Co istotne, podatność była znana i patch dostępny — organizacja po prostu nie zdążyła go wdrożyć.
Warto też wspomnieć o mniej spektakularnych, ale równie bolesnych przypadkach. Wiele organizacji doświadcza naruszenia bezpieczeństwa SAP i nigdy publicznie o tym nie informuje — płacą okup, naprawiają systemy, mają nadzieję, że nikt się nie dowie. Ale wewnętrzne koszty — utracona produktywność, odbudowa zaufania pracowników, nadgodziny zespołu IT — są realne i znaczące.
„Te przypadki nie są abstrakcyjnymi historiami z zagranicy” — mówi Jacek Bugajski. „Pracujemy z klientami, którzy doświadczyli incydentów bezpieczeństwa SAP. Widzieliśmy paraliż operacyjny, gdy system przestaje działać i nikt nie wie, ile mamy na magazynie, komu jesteśmy winni pieniądze, którzy pracownicy powinni dostać wypłatę. Widzieliśmy zarządy tłumaczące się przed radą nadzorczą i regulatorami, wyjaśniające dlaczego nie było regularnych testów bezpieczeństwa. Koszt regularnych pentestów to ułamek potencjalnych strat. A jednak wiele organizacji nadal traktuje bezpieczeństwo SAP jako opcjonalny wydatek, który można odłożyć na później.”
Jak przygotować organizację do testów penetracyjnych SAP?
Przed rozpoczęciem pentestów organizacja powinna przeprowadzić inwentaryzację wszystkich systemów SAP, hostów i instancji oraz zidentyfikować misyjnie krytyczne aktywa i powiązane ryzyka biznesowe. Wiele organizacji nie ma pełnego obrazu swojego krajobrazu SAP — systemy powstawały przez lata, niektóre są zapomniane, inne zarządzane przez różne działy. Dobry pentest zaczyna się od zrozumienia, co właściwie testujemy.
Kluczowe jest określenie zakresu testów — czy obejmują systemy produkcyjne (co jest bardziej realistyczne, ale wymaga ostrożności), jakie komponenty są w zakresie (ABAP, Java, HANA, Fiori, integracje z systemami zewnętrznymi), oraz czy testy mają charakter black-box, gray-box czy white-box.
Black-box symuluje zewnętrznego atakującego bez wiedzy o systemie — pentester dostaje tylko adres IP i musi sam odkryć wszystko inne. Gray-box zapewnia częściową wiedzę — na przykład konto użytkownika z podstawowymi uprawnieniami, co symuluje atak od wewnątrz lub po kradzieży poświadczeń. White-box daje pełen dostęp do dokumentacji, kodu źródłowego i konfiguracji, co pozwala na najgłębszą analizę, ale jest mniej realistyczne. Każde podejście ma swoje zastosowania — często łączy się je w jednym projekcie.
Dla środowisk RISE with SAP i BTP pentesty wymagają przestrzegania zasad określonych przez SAP. Testowanie ogranicza się do warstwy aplikacyjnej — dla warstw zarządzanych przez SAP należy polegać na raportach SOC i certyfikatach dostępnych przez SAP Trust Center. Nie można testować infrastruktury, bo nie jest Twoja.
Metodologia pentestów SAP obejmuje pięć faz. Discovery to wykrywanie sieci, skanowanie portów SAP, rekonesans — ustalenie co działa, na jakich serwerach, jakie wersje. Enumeration obejmuje identyfikację typu bazy danych, wersji SAP, System ID i numerów instancji — zbieranie informacji potrzebnych do dalszych ataków. Vulnerability assessment koncentruje się na brakujących kontrolach autoryzacyjnych, domyślnych poświadczeniach, błędach konfiguracyjnych i podatnościach kodu własnego. Exploitation to faktyczne wykorzystanie znalezionych podatności — eksploatacja relacji zaufania RFC, wstrzyknięcie poleceń systemu operacyjnego, eskalacja uprawnień. Post-exploitation obejmuje pivoting między połączonymi systemami i dostęp do krytycznych danych biznesowych — pokazanie, co naprawdę może zrobić atakujący po przejęciu pierwszego systemu.
„Kluczowe jest zaangażowanie właściwych interesariuszy od początku” — radzi Jarosław Zdanowski. „Pentesty SAP to nie tylko sprawa działu IT. Potrzebujemy właścicieli biznesowych systemów, którzy powiedzą co jest krytyczne. Administratorów BASIS, którzy udostępnią potrzebne dostępy. Zespołu bezpieczeństwa, który będzie monitorował testy. Często też prawników ze względu na kwestie zgodności i odpowiedzialności. Im lepiej przygotujemy grunt, tym wartościowsze będą wyniki.”
Co powinien zawierać raport z pentestów SAP?
Profesjonalny raport z testów penetracyjnych SAP musi być użyteczny dla różnych odbiorców. Zarząd potrzebuje podsumowania wykonawczego z oceną ryzyka biznesowego i priorytetyzacją działań naprawczych — bez technicznego żargonu, z jasnym przełożeniem na język biznesu. Zespół techniczny wymaga szczegółowych opisów znalezionych podatności, kroków reprodukcji umożliwiających weryfikację i rekomendacji remediacji. Audytorzy oczekują dokumentacji metodologii, zakresu testów i ich ograniczeń.
Raport powinien jasno klasyfikować znalezione podatności według krytyczności. Podatności krytyczne to te umożliwiające przejęcie systemu bez uwierzytelnienia, dostęp do danych wrażliwych lub znaczący wpływ biznesowy — wymagają natychmiastowej reakcji. Podatności wysokie stanowią poważne ryzyko, ale wymagają dodatkowych warunków do eksploatacji — powinny być naprawione w ciągu tygodni. Podatności średnie i niskie to problemy wymagające uwagi w ramach normalnego cyklu utrzymaniowego.
Dla każdej znalezionej podatności raport powinien zawierać opis techniczny wyjaśniający na czym polega problem, dowód koncepcji lub zrzuty ekranu dokumentujące możliwość eksploatacji, ocenę wpływu biznesowego wykraczającą poza techniczny scoring CVSS, rekomendowane działania naprawcze z priorytetami i szacowaną pracochłonnością oraz odniesienia do odpowiednich SAP Security Notes jeśli producent wydał już poprawkę.
Dobry raport nie kończy się na liście problemów. Powinien zawierać również pozytywne obserwacje — co organizacja robi dobrze, jakie kontrole działają skutecznie. Powinien też wskazywać obszary wymagające dalszej analizy oraz rekomendacje dotyczące poprawy ogólnej postawy bezpieczeństwa, wykraczające poza konkretne podatności.
„Raport z pentestów to nie koniec, ale początek procesu” — podkreśla Michał Korzeń. „Dokument trafiający do szuflady nie poprawia bezpieczeństwa. Liczy się plan remediacji z przypisanymi właścicielami i terminami, weryfikacja wdrożonych poprawek poprzez retesty, aktualizacja procedur i polityk. Dlatego w SNOK oferujemy wsparcie nie tylko w przeprowadzeniu testów, ale także w interpretacji wyników i planowaniu działań naprawczych. Towarzyszymy klientom na całej drodze — od identyfikacji problemu do jego rozwiązania.”
Podsumowanie — działaj zanim będzie za późno
Statystyki są jednoznaczne. 92% organizacji uważa dane w systemach SAP za misyjnie krytyczne. Jednocześnie 23% doświadczyło cyberataku wpływającego na ich środowisko SAP w ciągu ostatniego roku. Średni koszt naruszenia bezpieczeństwa SAP wynosi 5 milionów dolarów. Przestój spowodowany incydentem bezpieczeństwa kosztuje średnio ponad 50 000 dolarów za godzinę. Te liczby dotyczą globalnego rynku, ale polskie organizacje nie są odporne na te same zagrożenia.
Organizacje działające w sektorze finansowym muszą natychmiast zapewnić zgodność z DORA obowiązującą od stycznia 2025 roku. Wszystkie podmioty powinny przygotować się do implementacji znowelizowanej ustawy o KSC. Ustanowienie regularnego programu testów penetracyjnych z minimalną częstotliwością roczną jest niezbędne — środowiska wysokiego ryzyka wymagają testów kwartalnych.
Kluczowe jest udokumentowanie wszystkich działań bezpieczeństwa jako dowodów audytowych. Ocena ryzyka związanego z dostawcami zewnętrznymi SAP, szczególnie w kontekście RISE, powinna stanowić element strategii. Organizacje korzystające z SAP ECC powinny uwzględnić kończące się w 2027 roku wsparcie maintenance jako dodatkowy czynnik ryzyka — systemy bez wsparcia producenta są szczególnie narażone na nowe podatności.
Regularne, profesjonalne testy penetracyjne stanowią najbardziej efektywną formę proaktywnej ochrony przed zagrożeniami. Pozwalają wykryć podatności zanim zrobią to przestępcy. Dostarczają dowodów należytej staranności dla regulatorów i audytorów. Budują świadomość bezpieczeństwa w organizacji. Identyfikują luki nie tylko techniczne, ale również procesowe i organizacyjne.
Nie czekaj na incydent, który zmusi Cię do działania. Nie czekaj na kary od regulatora. Nie czekaj na nagłówek w prasie o wycieku danych z Twojej organizacji. Koszt profesjonalnego pentestu SAP to ułamek potencjalnych strat finansowych i reputacyjnych. Działaj teraz — Twój system SAP tego potrzebuje.
Potrzebujesz wsparcia w zakresie bezpieczeństwa SAP?
SNOK oferuje kompleksowe usługi testów penetracyjnych systemów SAP — od wstępnej oceny bezpieczeństwa, przez regularne testy zgodne z wymogami DORA i NIS2, po wsparcie w remediacji znalezionych podatności. Współpracujemy z wiodącymi dostawcami rozwiązań bezpieczeństwa SAP — SecurityBridge i bowbridge — łącząc ich technologie z naszą wiedzą ekspercką. Skontaktuj się z nami, aby omówić potrzeby Twojej organizacji.