SAP S/4HANA 2025 wnosi cztery przełomowe mechanizmy bezpieczeństwa, które automatycznie aktywują się podczas instalacji. To efekt kilkuletniej ewolucji koncepcji bezpieczeństwa wbudowanego od podstaw (secure by default) – z aspiracji do rzeczywistości. Problem w tym, że tylko 32% organizacji zakończyło migrację, a termin 2027 zbliża się nieubłaganie. Gdy 23% firm doświadczyło cyberataków na środowiska SAP w minionym roku, pytanie brzmi: czy jesteś gotowy na transformację, w której bezpieczeństwo nie jest dodatkiem, ale fundamentem?
Z aspiracji do rzeczywistości – ewolucja bezpieczeństwa od podstaw
W 2018 roku, gdy SAP wprowadził pierwszą odsłonę S/4HANA 1909, koncepcja bezpieczeństwa wbudowanego w system brzmiała jak śmiała obietnica. Siedem lat później, w wydaniu S/4HANA 2025, to już nie aspiracja – to podstawa architektury. SAP sam opisuje tę przemianę słowami: „Co zaczynało się jako śmiała inicjatywa wzmocnienia domyślnej postawy bezpieczeństwa, z biegiem lat stało się fundamentalną zasadą produktu”.
Każda kolejna wersja S/4HANA – od 1909 przez 2020, 2021, 2022, 2023 aż do dzisiejszej 2025 – przynosi kolejne warstwy zabezpieczeń. To progresywne wzmacnianie, które automatycznie stosuje się podczas nowych instalacji, konwersji z ECC oraz kopiowania systemów. Kluczowe słowo: automatycznie. Nie musisz niczego włączać. Nie musisz pamiętać o kolejnych parametrach. System robi to za Ciebie.
„To właśnie różni współczesne podejście SAP od tego, co widzieliśmy dekadę temu” – mówi Jaroslaw Kamil Zdanowski, Partner SNOK i ekspert SAP Basis oraz cyberbezpieczeństwa. „Kiedyś bezpieczeństwo było listą kontrolną do realizacji po wdrożeniu. Dziś jest wbudowane w strukturę systemu. Ale uwaga – to dopiero punkt startowy, nie meta”.
Cztery filary bezpieczeństwa w wydaniu 2025
Najnowsza odsłona S/4HANA przynosi cztery konkretne nowości, które zasługują na szczególną uwagę.
TLS 1.3 – szyfrowanie nowej generacji
Pierwsza nowość to wsparcie dla TLS 1.3 – najnowszego standardu szyfrowania transportowego. Obejmuje wszystkie interfejsy webowe: SAP Internet Communication Manager (ICM), SAP Start Service i SAP Host Agent. Implementacja wymaga Kernel Version 793 PL84 lub wyższego oraz CommonCryptoLib w wersji 8.5.55 i nowszych.
Co to oznacza w praktyce? TLS 1.3 upraszcza zestawy szyfrów, zawsze wymusza doskonałą tajemnicę przekazywania (Perfect Forward Secrecy) i przyspiesza nawiązywanie połączeń. To nie kosmetyczna zmiana – to fundamentalna różnica w architekturze bezpieczeństwa. Podczas gdy TLS 1.2 wymaga dwóch pełnych obrotów komunikacji do nawiązania bezpiecznego kanału, TLS 1.3 redukuje to do jednego.
Koniec ery starych tokenów logowania
Druga nowość brzmi jak pogrzeb technologii: SAP wyłącza wsparcie dla starych tokenów logowania SAP, zachowując jedynie nowoczesne tokeny potwierdzenia SAP Assertion. Stare tokeny, uznane za niebezpieczne, znikają z krajobrazu. To też część większego trendu – od wersji 2023 SAP systematycznie eliminuje przestarzałe mechanizmy komunikacji opartej na zaufaniu.
„Widzimy to u klientów co miesiąc” – komentuje Michal Korzen, CTO SNOK i architekt rozwiązań Enterprise oraz AI. „Rozwiązania starsze są wygodne. Ale wygoda kosztuje. Organizacje, które odwlekają modernizację mechanizmów uwierzytelniania, budują dług technologiczny, który w kontekście NIS2 i nadchodzących audytów może być bardzo bolesny”.
Logi dla systemów SIEM – koniec z ręcznym przetwarzaniem
Trzecia nowość to logi bezpieczeństwa w formacie czytelnym dla systemów z ICM. Brzmi technicznie, ale ma fundamentalne znaczenie praktyczne. Do tej pory integracja logów SAP z korporacyjnymi systemami zarządzania informacjami i zdarzeniami bezpieczeństwa była koszmarem administratorów. Zamknięte formaty, niestandardowe struktury, potrzeba dedykowanych analizatorów składniowych.
S/4HANA 2025 kończy ten problem. Logi bezpieczeństwa z ICM są teraz strukturyzowane w sposób umożliwiający bezpośrednią integrację z Splunk, Microsoft Sentinel, IBM QRadar i innymi platformami zarządzania bezpieczeństwem. To oznacza monitoring w czasie rzeczywistym, automatyczne alerty i włączenie SAP w jednolity obraz bezpieczeństwa organizacji.
„To przełamuje podstawowy problem, z którym borykają się zespoły centrów operacji bezpieczeństwa” – dodaje Jarosław Zdanowski. „SAP zazwyczaj operuje w silosie. Zespół SAP Basis ma swoje narzędzia, zespół bezpieczeństwa informacji ma swoje, a między nimi przepaść. Logi w czytelnym formacie to most, który w końcu pozwala je połączyć”.
Content Security Policy – druga linia obrony
Czwarta nowość to Content Security Policy w trybie raportowania. CSP działa jako druga warstwa obrony przed atakami Cross-Site Scripting w aplikacjach webowych. Tryb raportowania pozwala organizacjom testować polityki bez ryzyka zablokowania prawdziwych funkcji.
Równolegle SAP wyłącza przestarzały interfejs skanowania zawartości ICM, zastępując go dedykowanymi mechanizmami sprawdzania bezpieczeństwa wbudowanymi bezpośrednio w aplikacje przeglądarkowe. To przesunięcie bezpieczeństwa w praktyce – zabezpieczenia przesuwają się bliżej użytkownika i stają się naturalną częścią aplikacji, nie zewnętrznym dodatkiem.
Co dziedziczymy z poprzednich wersji
Bezpieczeństwo wbudowane w S/4HANA 2025 to nie tylko cztery nowe funkcje. To kumulacja zabezpieczeń z siedmiu lat rozwoju. Każdy system, który dzisiaj instalujesz lub na który migrujesz, automatycznie otrzymuje pełen stos mechanizmów obronnych.
Od wersji 1909: wzmocniony system autoryzacji, ulepszona ochrona interfejsów RFC, aktywacja dziennika audytu bezpieczeństwa.
Od wersji 2020: silne polityki haseł, ochrona komunikacji wewnątrzsystemowej, aktywacja wszystkich scenariuszy mechanizmu przełączalnych kontroli autoryzacji.
Od wersji 2021: aktywacja dziennika audytu HANA, rejestrowanie zmian w krytycznych tabelach biznesowych, ochrona WebDynpro, lista dozwolonych adresów HTTP, ochrona przed przechwytywaniem kliknięć.
Od wersji 2022: obowiązkowa ochrona SSL dla tokenów logowania sesji, ochrona bramki RFC, wymuszenie TLS 1.2 jako minimum dla wszystkich interfejsów webowych.
Od wersji 2023: automatyczna aktywacja szyfrowania danych w spoczynku HANA (w HANA2 SP07 i nowszych), blokowanie przypisywania użytkowników do ról w ramach transportów (eliminacja ryzyka nieautoryzowanych uprawnień w środowiskach produkcyjnych).
„To jest właśnie siła progresywnego modelu” – wyjaśnia Jacek Bugajski, CEO SNOK. „Klienci czasem pytają: po co kolejna aktualizacja, skoro obecna wersja działa? Odpowiedź jest prosta – każda nowa wersja S/4HANA przynosi zabezpieczenia, które w starszych systemach wymagałyby miesięcy ręcznej konfiguracji. To nie koszt, to inwestycja w spokój”.
Luka między domyślnym a wystarczającym
Przyjrzyjmy się jednak twardej prawdzie: bezpieczeństwo domyślne to punkt startowy, nie linia mety. Sam SAP pisze wprost: „Ustawienia bezpieczeństwa domyślnego nie mogą i nie będą obejmować wszystkich aspektów konfiguracji bezpieczeństwa w systemach S/4HANA”.
Co to oznacza praktycznie? Trzy obszary wymagają Twojej uwagi:
Po pierwsze: ustawienia specyficzne dla Twojej organizacji. Profile parametrów bezpieczeństwa domyślnego są uniwersalne – dostosowane do przeciętnych potrzeb. Twoja firma może potrzebować bardziej rygorystycznych zasad haseł, specyficznych ograniczeń sieciowych czy dedykowanych polityk audytu.
Po drugie: regularne aktualizacje bezpieczeństwa. SAP publikuje informacje o zabezpieczeniach drugiego wtorku każdego miesiąca. Bezpieczeństwo domyślne nie zastępuje tego procesu. Według badania SAPinsider 2025, 35% organizacji wskazuje zarządzanie poprawkami jako największe wyzwanie bezpieczeństwa – trzeci rok z rzędu. Powód? Trudności z zaplanowaniem przestoju (64% respondentów) i sprawdzaniem zgodności aplikacji z aktualizacjami (57%).
Po trzecie: bezpieczeństwo kodu własnego. Twoje modyfikacje ABAP, rozszerzenia, interfejsy własne – wszystko to wymaga dedykowanego zabezpieczenia. Mechanizmy przełączalnych kontroli i inne narzędzia szkieletowe pomagają, ale nie zastąpią przeglądu bezpieczeństwa Twojego kodu.
Polskie realia – stos wymagań zgodności, który nie wybacza
Jeśli prowadzisz organizację w Polsce, masz dodatkową warstwę złożoności. I nie chodzi tylko o język interfejsu.
NIS2 – odpowiedzialność zarządu, która boli
Dyrektywa NIS2, implementowana w Polsce przez rok 2024/2025, to zmiana paradygmatu. Dotyczy organizacji średnich i dużych w sektorach krytycznych – energia, transport, bankowość, opieka zdrowotna, administracja publiczna, infrastruktura cyfrowa.
Co konkretnie oznacza dla SAP? System ERP to krytyczna aplikacja biznesowa. NIS2 wymaga zarządzania ryzykiem cybernetycznym z perspektywy wpływu społecznego i ekonomicznego. Aktualizacje bezpieczeństwa (paragraf 6.6 dyrektywy), reagowanie na incydenty, bezpieczeństwo łańcucha dostaw, dokumentacja – wszystko to staje się obowiązkowe i podlega audytom.
Ale najważniejsze: odpowiedzialność zarządu. Zarząd jest osobiście odpowiedzialny za zgodność. Sankcje finansowe, zawieszenie działalności, potencjalny zakaz pełnienia funkcji kierowniczych – to już nie abstrakcja, to rzeczywistość od października 2024.
„Rozmawialiśmy niedawno z dyrektorem informatycznym dużej firmy produkcyjnej” – opowiada Jacek Bugajski. „Pierwsze pytanie, które padło: kto idzie do więzienia jak będzie włamanie? To pokazuje zmianę świadomości. NIS2 to nie kolejna regulacja informatyczna – to ryzyko biznesowe na poziomie najwyższego kierownictwa”.
DORA – gdy jesteś w finansach
Jeśli działasz w sektorze finansowym, od 17 stycznia 2025 masz dodatkową warstwę wymagań zgodności – DORA (rozporządzenie o cyfrowej odporności operacyjnej). Wymaga zarządzania ryzykiem informatycznym i telekomunikacyjnym, testów odporności cyfrowej, raportowania incydentów, zarządzania ryzykiem dostawców.
Co to oznacza dla SAP? Ochrona eksportów danych (Excel, PDF z SAP), zarządzanie łańcuchem dostaw, dokumentacja reagowania na incydenty. DORA jest bardziej restrykcyjna niż NIS2 dla instytucji finansowych.
JPK_CIT – bo polska zgodność podatkowa też się liczy
Od stycznia 2025 obowiązuje JPK_CIT (Jednolity Plik Kontrolny dla podatku dochodowego od osób prawnych). To nie bezpieczeństwo SAP w ścisłym znaczeniu, ale ma bezpośredni wpływ na architekturę systemu.
Polska specyfika: automatyczna ekstrakcja danych z ERP, generowanie XML według polskiego schematu XSD, walidacja, transmisja do systemu e-Urząd Skarbowy. Wymaga dedykowanych rozszerzeń (np. certyfikowanych przez SAP rozwiązań Melasoft) i integracji z SAP FI/CO.
„To jest właśnie przykład tego, o czym mówiliśmy – bezpieczeństwo domyślne nie obejmuje lokalnych wymogów zgodności” – komentuje Jarosław Zdanowski. „JPK, polski plik audytowy, to są wyzwania, które wymagają lokalnej ekspertyzy. Dlatego partnerstwo z polskimi firmami, które rozumieją krajobraz regulacyjny i mają gotowe rozwiązania, jest tak istotne”.
Krajobraz zagrożeń 2025 – co naprawdę atakuje SAP
Dane z badania SAPinsider/Onapsis 2025 są jednoznaczne: 23% organizacji doświadczyło cyberataków wpływających na środowiska SAP w minionym roku. Przy czym 92% uważa dane w systemach SAP za kluczowe dla misji.
Ranking zagrożeń zmienił się dramatycznie:
Numer jeden: kradzież danych. Wyskoczyła z czwartego miejsca w 2024 na pierwsze w 2025. Powód? Centralizacja danych dla inicjatyw sztucznej inteligencji, wdrożenia chmury danych biznesowych SAP, koncentracja krytycznych informacji biznesowych. Atakujący już nie chcą blokować systemów (oprogramowanie okupowe) – chcą wykraść dane.
Numer dwa: systemy bez aktualizacji. Konsekwentnie w pierwszej trójce od lat. Luka zerowego dnia w S/4HANA odkryta i wykorzystywana w 2025 – pokazała, że atakujący mają głęboką wiedzę techniczną o SAP i aktywnie szukają słabości.
Numer trzy: połączenia z innymi systemami. Skok z dziesiątego miejsca na trzecie. Chmura, chmura hybrydowa, rozszerzanie krajobrazów aplikacyjnych – każdy punkt integracji to potencjalny wektor ataku.
„To odpowiada na pytanie, dlaczego logi w czytelnym formacie w S/4HANA 2025 są tak ważne” – podkreśla Michał Korzeń. „Nie chodzi o elegancję architektury. Chodzi o to, że bez widoczności w czasie rzeczywistym w połączonych systemach jesteś ślepy. A ślepota w cyberbezpieczeństwie to gwarancja problemów”.
SecurityBridge i bowbridge – polski kontekst globalnych narzędzi
SNOK jako partner zarówno SAP , jak i SecurityBridge i bowbridge Software GmbH, ma unikalną perspektywę na to, jak te narzędzia współpracują z bezpieczeństwem domyślnym.
SecurityBridge – platforma, która widzi wszystko
SecurityBridge to pierwsza i jedyna w pełni zintegrowana platforma cyberbezpieczeństwa działająca całkowicie osadzona w środowisku SAP. 200+ klientów na świecie, 5000+ systemów produkcyjnych zabezpieczonych. W Polsce realizujemy wdrożenia, które pokazują konkretną wartość biznesową.
Studium przypadku: Stock Spirits Group – producent alkoholi działający w Polsce, Czechach, Włoszech. Podczas transformacji S/4HANA SNOK wdrożył SecurityBridge. Wyzwanie? Przejście z podmiotów regionalnych do podmiotu paneuropejskiego, zwiększone ryzyko cyberataków, szczupły zespół SAP wymagający efektywnego zarządzania alertami.
Rezultat? Zamknięcie krytycznych tylnych furtek bezpieczeństwa, wzmocnienie postawy ochronnej, usprawniony monitoring bez przytłaczania małego zespołu, poprawna bazowa konfiguracja eliminująca fałszywe alarmy.
Cytat z Stock Spirits: „Z moim wieloletnim doświadczeniem w SAP jest jasne, że SecurityBridge wypełnia krytyczne luki bezpieczeństwa, których sam SAP nie jest w stanie zaadresować” – Jaromir Wróblewski, kierownik infrastruktury informatycznej grupy.
SecurityBridge integruje się z Splunk, Microsoft Sentinel, IBM QRadar. Automatyczne skanowanie podatności, zarządzanie aktualizacjami, analiza bezpieczeństwa kodu, wykrywanie anomalii behawioralnych oparte na uczeniu maszynowym, ciągły monitoring przez całą dobę. I co najważniejsze – wdrożenie w 48 godzin bez dodatkowej infrastruktury.
„Klienci często pytają: czy SecurityBridge to konkurencja dla bezpieczeństwa domyślnego?” – mówi Jarosław Zdanowski. „Odpowiedź brzmi: nie, to uzupełniające się warstwy. Bezpieczeństwo domyślne daje ci zdrową podstawę. SecurityBridge daje ci oczy, uszy i refleks. Widzisz, co się dzieje, reagujesz na zagrożenia, zarządzasz lukami, automatyzujesz zgodność. To różnica między posiadaniem zamka w drzwiach a posiadaniem systemu alarmowego, kamer i ochrony”.
bowbridge – gdy złośliwe oprogramowanie celuje w przesyłanie plików
bowbridge to specjalizacja, której brakuje w standardowym zestawie: ochrona antywirusowa dla aplikacji SAP. Dlaczego standardowy program antywirusowy nie działa? Bo pliki przesyłane do SAP są szyfrowane w tranzycie, przechowywane w zamkniętych repozytoriach (nie na systemie plików), a systemowy program antywirusowy nie ma dostępu do zaszyfrowanych plików w bazie SAP czy serwerze treści.
bowbridge integruje się z interfejsem skanowania wirusów SAP NetWeaver – jedyne rozwiązanie zaprojektowane specjalnie do tego interfejsu. Całkowite skanowanie w pamięci, wsparcie dwóch silników (Trellix i SOPHOS), pełne skanowanie archiwów SAPCAR, wykrywanie ataków Cross-Site Scripting nawet w ukrytych plikach.
Dla RISE with SAP – gdzie SAP zabezpiecza warstwę systemu operacyjnego (ochrona antywirusowa na poziomie systemu plików), ale nie może zabezpieczyć warstwy aplikacji (pliki w pamięci procesu roboczego SAP, baza danych, serwer treści) – bowbridge wypełnia dokładnie tę lukę.
„Widzieliśmy przypadki, gdzie organizacje miały najnowocześniejszą ochronę punktów końcowych, ale złośliwe oprogramowanie weszło przez formularz przesyłania plików SAP w aplikacji kadrowej” – opowiada Michał Korzeń. „Standardowy program antywirusowy tego nie złapał, bo plik nigdy nie dotknął systemu plików w sposób, który by go zobaczył. W bazie HANA był zaszyfrowany. bowbridge skanuje w pamięci, zanim plik w ogóle trafi do trwałego zapisu. To jest właśnie obrona wielowarstwowa”.
Rzeczywistość migracji – gdzie jesteśmy w 2025
Twarda prawda o adopcji S/4HANA: tylko 32% organizacji zakończyło migrację. 27% jest w aktywnej implementacji. 21% nadal w fazie oceny. A termin 2027 – koniec głównego wsparcia dla ECC – to już pojutrze.
Model Basis Technologies (recenzowany przez ekspertów SAP) przewiduje, że tylko 57% klientów ECC ukończy migrację do 2027. 80% do 2030. Pełna transformacja potrwa do połowy lat 30.
Co to oznacza praktycznie? Niedobór zasobów. Ceny doradztwa będą rosnąć. Dostępność ekspertów będzie maleć. Organizacje, które czekają do ostatniej chwili, zapłacą więcej. To nie jest straszenie – to matematyka podaży i popytu.
„Mamy klientów, którzy przyszli do nas w 2023 z prośbą o audyt przed migracją” – wspomina Jacek Bugajski. „Ci, którzy zaczęli wtedy, teraz kończą albo są w końcowych etapach. Mamy też klientów, którzy przyszli w 2024 i mówią: zrobimy to w rok. I tu trzeba powiedzieć prawdę – realistyczny harmonogram to 18-36 miesięcy, w zależności od złożoności. Im później zaczynasz, tym większa presja, tym więcej skrótów, tym większe ryzyko bezpieczeństwa”.
Co robić – plan działania
Jeśli planujesz migrację
Zrób ocenę bazową bezpieczeństwa przed rozpoczęciem. Nie możesz migrować długu bezpieczeństwa z ECC do S/4HANA – to jak budowanie nowego domu na wadliwych fundamentach.
Włącz bezpieczeństwo do harmonogramu projektu i budżetu od dnia zero. Nie jako późniejszy dodatek, ale jako główny element. Bezpieczeństwo zbudowane w projekcie kosztuje pięć razy mniej niż bezpieczeństwo dodane po fakcie.
Planuj zgodność od początku. NIS2, DORA (dla finansów), JPK_CIT, RODO – to nie są osobne projekty. To są wymogi, które muszą być wbudowane w architekturę systemu.
Rozważ RISE with SAP, jeśli masz ograniczone zasoby infrastrukturalne. Model współodpowiedzialności – SAP zabezpiecza platformę, Ty zabezpieczasz aplikację – może być efektywny, pod warunkiem że rozumiesz, gdzie leży granica odpowiedzialności.
Jeśli już masz S/4HANA
Zweryfikuj, czy ustawienia bezpieczeństwa domyślnego są aktywne. Nota SAP 2926224 zawiera pełną listę kontrolną. Rezygnacja z nich jest możliwa dla parametrów profilu, ale SAP wyraźnie tego nie zaleca. Jeśli ktoś w Twojej organizacji wyłączył część ustawień podczas migracji „bo coś nie działało”, możesz mieć luki bezpieczeństwa.
Uzupełnij luki w widoczności. Bezpieczeństwo domyślne nie obejmuje integracji z systemami zarządzania bezpieczeństwem. Logi w czytelnym formacie z ICM w S/4HANA 2025 ułatwiają to znacząco, ale ktoś musi te logi podłączyć do Splunk/Sentinel/QRadar i skonfigurować istotne powiadomienia.
Rozważ platformy trzeciej generacji jak SecurityBridge dla ciągłego monitorowania i bowbridge dla ochrony opartej na plikach. Bezpieczeństwo domyślne plus natywne narzędzia SAP plus wyspecjalizowane platformy to kompletny zestaw.
Dla wszystkich
Zarządzanie aktualizacjami nie może być przypadkowe. Drugi wtorek każdego miesiąca – dzień aktualizacji SAP. Potrzebujesz procesu: monitorowanie informacji o bezpieczeństwie, ocena wpływu, testowanie w środowisku testowym, wdrożenie do produkcji. Narzędzia do automatycznego skanowania podatności (SecurityBridge, Onapsis, Pathlock) redukują wysiłek ręczny.
Szkoł ludzi. Świadomość bezpieczeństwa to nie jednorazowe szkolenie przy zatrudnieniu. To ciągły program. Wyłudzanie danych, inżynieria społeczna, kompromitacja poświadczeń – 57% ataków wykorzystuje błąd ludzki.
Audytuj regularnie. Kwartalne przeglądy dostępu, roczne kompleksowe oceny bezpieczeństwa, testy penetracyjne. Nie czekaj na audyt od regulatora czy włamanie od atakującego.
SNOK i PWCyber – gdy ekspertyza spotyka się z misją edukacyjną
Bezpieczeństwo systemów SAP w Polsce to nie tylko kwestia wdrożeń komercyjnych. To też wyzwanie edukacyjne i świadomościowe. SNOK jest aktywnym uczestnikiem inicjatywy PWCyber – Program Współpracy w Cyberbezpieczeństwie prowadzonej przez Ministerstwo Cyfryzacji.
PWCyber to platforma łącząca sektor publiczny wokół wspólnego celu: podnoszenia poziomu cyberbezpieczeństwa w Polsce. W ramach tej inicjatywy SNOK prowadzi działania edukacyjne skupione na specyfice zabezpieczania środowisk SAP – obszarze, który mimo krytycznego znaczenia dla polskiej gospodarki, wciąż pozostaje niszą w dyskusji o cyberbezpieczeństwie.
„Systemy SAP to kręgosłup polskiej gospodarki – od energetyki przez produkcję po sektor publiczny” – mówi Jacek Bugajski. „Ale gdy mówimy o cyberbezpieczeństwie w Polsce, dyskusja koncentruje się na klasycznych tematach: firewalle, punkty końcowe, phishing. Tymczasem SAP wymaga specjalistycznej wiedzy – od mechanizów autoryzacji przez protokoły RFC po luki w kodzie ABAP. To nie jest wiedza, którą zespoły bezpieczeństwa mają naturalnie. Dlatego angażujemy się w PWCyber – żeby tę lukę kompetencyjną zmniejszać”.
W praktyce oznacza to udział w konferencjach, webinarach, publikacjach eksperckich i współpracę z uczelniami technicznymi. Tematyka obejmuje zarówno podstawy bezpieczeństwa SAP dla zespołów bezpieczeństwa informacji, jak i zaawansowane zagadnienia dla administratorów SAP Basis – od implementacji NIS2 w środowiskach SAP, przez testy penetracyjne specyficzne dla SAP, po budowanie programów zarządzania podatnościami.
„Widzimy efekty tej pracy w terenie” – dodaje Jarosław Zdanowski. „Pięć lat temu rozmowa z zespołem bezpieczeństwa klienta o SAP kończyła się na 'macie firewall przed SAP?’. Dziś pytają o SACF, o segregację obowiązków w GRC, o monitoring anomalii w SecurityBridge. To jest właśnie ta zmiana świadomości, o którą nam chodzi. Bo technologia się rozwija – widzieliśmy to w S/4HANA 2025 – ale ludzie muszą wiedzieć, jak z niej korzystać”.
Szczególnie istotne jest to w kontekście NIS2 i rosnących wymagań regulacyjnych. Organizacje potrzebują nie tylko narzędzi, ale też wiedzy: jak przeprowadzić audyt bezpieczeństwa SAP zgodnie z wymogami dyrektywy? Jak zbudować plan reagowania na incydenty uwzględniający specyfikę środowiska SAP? Jak dokumentować kontrole bezpieczeństwa w sposób zrozumiały dla audytorów, którzy sami mogą nie być ekspertami SAP?
„PWCyber daje nam platformę, żeby tę wiedzę szerzyć szerzej niż tylko wśród naszych bezpośrednich klientów” – podsumowuje Michał Korzeń. „To inwestycja w długoterminową odporność polskiego biznesu. Bo gdy organizacje rozumieją zagrożenia i mają kompetencje, żeby im przeciwdziałać, cały ekosystem jest bezpieczniejszy. A to leży w interesie nas wszystkich”.
Przyszłość to bezpieczeństwo od projektu, nie dodane później
S/4HANA 2025 i jego bezpieczeństwo domyślne to symptom szerszego trendu w oprogramowaniu dla przedsiębiorstw: bezpieczeństwo staje się domyślne, nie opcjonalne. Architektura zerowego zaufania, wykrywanie zagrożeń oparte na sztucznej inteligencji, automatyczny monitoring zgodności – to już nie modne hasła, to rzeczywistość.
Dla polskich organizacji, które stają przed wyborem: migrować teraz czy czekać – dane są jednoznaczne. Czekanie to rosnące koszty operacyjne (25-30% rocznie), niedobór zasobów, akumulacja długu technicznego, mnożenie się luk bezpieczeństwa.
„Każdy dzień zwłoki to dzień, kiedy Twój system ECC jest o jedną poprawkę starszy, o jedną lukę bardziej wrażliwy, o jednego doświadczonego konsultanta mniej dostępny na rynku” – podsumowuje Jacek Bugajski. „Ale jeśli robisz to dobrze – z bezpieczeństwem od dnia zero, z lokalnymi partnerami, którzy rozumieją polski kontekst zgodności, z narzędziami trzeciej generacji uzupełniającymi bezpieczeństwo domyślne – to nie jest projekt informatyczny. To jest transformacja biznesowa, która daje przewagę konkurencyjną”.
S/4HANA 2025 daje Ci zdrowe fundamenty. Co zbudujesz na nich – to już zależy od Ciebie.
Podsumowanie
Bezpieczeństwo domyślne w SAP S/4HANA 2025 automatycznie aktywuje TLS 1.3, wyłącza przestarzałe tokeny logowania, udostępnia logi w formacie czytelnym dla systemów zarządzania bezpieczeństwem i wprowadza Content Security Policy. To punkt startowy, który wymaga uzupełnienia o konfigurację specyficzną dla bezpieczeństwa, regularne aktualizacje, zabezpieczenie kodu własnego, integrację z systemami zarządzania bezpieczeństwem i kontrole zgodności. Polski kontekst (NIS2, DORA, JPK_CIT) oraz termin 2027 tworzą presję działania. Organizacje, które traktują bezpieczeństwo jako dodatek, zapłacą cenę w postaci kar za niezgodność, naruszeń bezpieczeństwa i utraconych możliwości. Te, które budują bezpieczeństwo od podstaw projektu, zyskują przewagę konkurencyjną.