Nie ma takiego protokołu z komitetu sterującego, w którym ktoś zapisuje: „zatwierdzamy rozszerzenie powierzchni ataku na najbliższe dwa lata”. A dokładnie to zapada na tych spotkaniach. Zamrożenie zmian w SAP ECC na czas programu. Zgoda na kopie produkcji w systemach projektowych, bo bez danych nie przejdziecie testów akceptacyjnych. Uprawnienia awaryjne dla integratora „do końca cutoveru”. Kryteria przejścia do go-live, w których nie ma ani jednego warunku bezpieczeństwa. Każda z tych decyzji jest osobno rozsądna. Razem tworzą okno, które stoi otwarte od roku do trzech lat, czyli tyle, ile realnie trwa program konwersji do SAP S/4HANA.
Termin też nie pomaga. SAP utrzymuje mainstream maintenance dla SAP Business Suite 7 do 31 grudnia 2027, a utrzymanie rozszerzone od początku 2028 do końca 2030 kosztuje dodatkowe dwa punkty procentowe do podstawy utrzymania. Kto startuje teraz, ma kilkanaście miesięcy. Kto ma kilkanaście miesięcy, ten tnie zakres. A bezpieczeństwo tnie się najłatwiej, bo nikogo nie blokuje.
W skrócie:
1/ zamrożenie zmian funkcjonalnych w SAP ECC nie zamraża ryzyka - SAP Security Patch Day wychodzi co miesiąc niezależnie od waszego harmonogramu,
2/ w modelu RISE with SAP to klient składa wniosek o łatkę bezpieczeństwa warstwy Basis i zgadza się na przestój, a testu penetracyjnego nie uruchomi bez zgody SAP - oba fakty pochodzą z materiału SAP, nie od dostawcy zabezpieczeń,
3/ przebieg ABAP Test Cockpit pod konwersję nie sprawdza bezpieczeństwa kodu, bo kontrole bezpieczeństwa dostarcza osobno licencjonowany SAP Code Vulnerability Analyzer, a licencja z SAP ERP nie przechodzi na SAP S/4HANA,
4/ systemy nieprodukcyjne i produkcyjne stoją w RISE w tej samej sieci wirtualnej - z powodów, które SAP opisuje wprost, i o których wasz sandboks konwersyjny powinien wiedzieć.
Trzy zdania, które brzmią rozsądnie i nie są prawdziwe
„System jest zamrożony, więc jest stabilny”
To najczęstsze założenie w programach konwersji i najbardziej kosztowne. SecurityBridge opisał je w styczniu 2026 jednym zdaniem, które warto powiesić w pokoju projektowym: freezing functional changes does not equal freezing security risks. Zamrażacie zmiany biznesowe. Nie zamrażacie kalendarza publikacji podatności.
Przez ten czas w starym krajobrazie zwykle nie działa ciągła ocena podatności, nikt nie patrzy na kod własny, interfejsy i połączenia RFC, a kontrole zostają ręczne. Polityka „żadnych zmian” daje przy tym poczucie bezpieczeństwa, które nie ma pokrycia: atakującego nie obowiązuje wasz change freeze, a wasze systemy w tym okresie są przewidywalne jak nigdy. Jeżeli chcecie zobaczyć, co miesięcznie trafia na tę listę, zajrzyjcie do naszego zestawienia z wrześniowego SAP Security Patch Day - cztery noty krytyczne w czterech różnych warstwach, w miesiącu uznanym za spokojny.
„Przechodzimy na RISE, więc bezpieczeństwo bierze SAP”
W modelu RISE with SAP przesuwa się granica odpowiedzialności. Sama odpowiedzialność zostaje tam, gdzie była. SAP prowadzi centra danych, sieć, maszyny wirtualne, system operacyjny, bazę HANA, kopie zapasowe, monitorowanie całodobowe i zarządzanie incydentami warstwy technicznej. Po waszej stronie zostaje konfiguracja aplikacji, tożsamość użytkowników, role i kontrola dostępu, dziennik audytu, integracje, rozwój własny i zgodność z regulacjami.
To jeszcze nie jest zaskoczenie, bo model współdzielonej odpowiedzialności zna każdy, kto pracował z chmurą publiczną. Zaskoczeniem bywają trzy szczegóły z opublikowanego przez SAP zestawu odpowiedzi na pytania o cyberbezpieczeństwo SAP S/4HANA Cloud Private Edition.
Pierwszy. System operacyjny i bazę SAP łata regularnie samo. Ale przy łatkach bezpieczeństwa warstwy technicznej Basis rola się zmienia: SAP przegląda dostępne poprawki i przygotowuje przetestowane paczki wdrożeniowe, natomiast - jak stoi w tym materiale - to klient zgodnie z umową składa wniosek o ich wdrożenie i godzi się na przestój w oknie utrzymaniowym. Wniosek trafia do SAP przez kokpit klienta. Nikt nie wgra wam łatki Basis dlatego, że wyszła.
Drugi. Test penetracyjny i skan podatności możecie przeprowadzić wyłącznie na warstwie aplikacji i wyłącznie po zatwierdzeniu przez SAP. Jeżeli chcecie niezależny test przed uruchomieniem produkcyjnym, to jest pozycja w harmonogramie z wyprzedzeniem liczonym w tygodniach, a nie zadanie, które ktoś dorzuci w tygodniu cutoveru.
Trzeci, najciekawszy dla architektów. Systemy deweloperskie, testowe i produkcyjne stoją w tej samej sieci wirtualnej. SAP podaje powód wprost: bez tego nie działa logistyka oprogramowania, czyli transporty i kopie klienta. To nie jest luka, to projekt. Oznacza jednak, że system projektowy waszej konwersji nie jest osobną wyspą, tylko sąsiadem produkcji.
„Konwersja techniczna wyszła, więc system jest bezpieczny”
Testy konwersyjne sprawdzają, czy proces się zamyka, czy dokument się księguje, czy raport zwraca to samo. Nie sprawdzają, czy program, który to robi, ma kontrolę uprawnień. O tym, jak rozdzielamy te dwa pytania w testach, pisaliśmy przy okazji testów SAP S/4HANA przy konwersji i przed go-live. Tutaj wystarczy jedno zdanie: zielony wynik testu funkcjonalnego nie jest dowodem w sprawie bezpieczeństwa i nikt nigdy nie twierdził, że jest.
Cztery rzeczy, które konwersja mnoży
Program konwersji nie wymyśla nowych klas podatności. On mnoży i uprawomocnia te, które w normalnym utrzymaniu byłyby wyjątkiem wymagającym zgody.
Kopie produkcji. Testy akceptacyjne bez danych produkcyjnych nie mają wartości, więc kopie powstają - zwykle kilka, w kilku środowiskach, przez kilkanaście miesięcy. Kopia niesie nie tylko dane osobowe, które widzi inspektor ochrony danych. Niesie także definicje połączeń RFC, konta techniczne i relacje zaufania. System projektowy ma luźniejsze role, słabszy nadzór i rzadko trafia do monitorowania.
Warto nazwać wnioski z tego wprost, bo w rozmowach o konwersji zwykle padają osobno. Kopia produkcji to nie jest wyłącznie temat ochrony danych osobowych. To jest system, który potrafi zalogować się tam, gdzie potrafił logować się oryginał - z tymi samymi definicjami połączeń i tymi samymi kontami technicznymi, tylko z gorszymi rolami, bez monitorowania i z listą osób mających dostęp, której nie zatwierdzał nikt poza kierownikiem projektu. Ryzyko nie polega na tym, że ktoś wykradnie dane z sandboksu. Polega na tym, że wejdzie do sandboksu, a wyjdzie w systemie, który księguje.
Dostęp uprzywilejowany z datą ważności, której nikt nie wpisał. Integrator, jego podwykonawcy, konta serwisowe, uprawnienia awaryjne „na czas projektu”. Te kategorie rzadko mają właściciela po stronie klienta, a jeszcze rzadziej termin wygaśnięcia zapisany w systemie, a nie w umowie. SecurityBridge wskazuje nadmiarowe uprawnienia jako jedną z rzeczy, które organizacje przenoszą do nowego środowiska razem z danymi - i ma rację, bo czyszczenie ról w trakcie programu nie ma w harmonogramie ani jednego kamienia milowego.
Kod własny. O tym za chwilę osobno, bo to najgorzej rozumiany punkt całej listy.
Ścieżki, których nikt nie monitoruje. Joris van de Vis z SecurityBridge opisał to w sierpniu 2026 celnie: w SAP do jednego efektu biznesowego prowadzi wiele dróg technicznych, a monitorowana jest zwykle jedna, standardowa transakcja. Drogi poboczne to mniej znane transakcje, mechanizmy transportowe, rozwój własny, interfejsy i procesy w tle. W cutoverze każda z nich pracuje na najwyższych obrotach, a kontrola zmiany działa w trybie awaryjnym. Jego wniosek jest prosty i niewygodny: kontrolujcie skutek, nie tylko proces.
Te cztery mechanizmy nie działają równomiernie. Najdłuższe okno to zamrożony krajobraz wyjściowy i najczęściej nikt nie jest jego właścicielem, bo zespół utrzymania czeka na nowy system, a zespół projektowy patrzy na docelowy. Najintensywniejsze okno to cutover, w którym kontrola zmiany pracuje w trybie awaryjnym z definicji. Najbardziej niedoceniane są pierwsze dwa tygodnie po uruchomieniu - wrócimy do nich osobno, bo to jedyny moment w całym programie, w którym nowy system jest jednocześnie produkcyjny i nieobserwowany.
„Odpaliliśmy ATC” - co ten skan naprawdę pokrył
To zdanie pada na każdym przeglądzie programu konwersji i prawie zawsze znaczy coś innego, niż myśli osoba, która je słyszy.
ABAP Test Cockpit dostarcza infrastrukturę kontroli oraz kontrole poprawności funkcjonalnej i wydajności. Kontrole bezpieczeństwa dostarcza SAP Code Vulnerability Analyzer, zbudowany na tej samej infrastrukturze, ale będący osobnym, osobno licencjonowanym produktem. Wariant kontroli, który uruchamia wyłącznie analizator podatności, nazywa się SLIN_SEC. Wariant, który uruchamia wasz zespół konwersyjny, sprawdza gotowość na SAP S/4HANA i elementy uproszczeń, bo to one blokują go-live. Bezpieczeństwo kodu nie blokuje niczego, więc nie wchodzi do przebiegu „przy okazji”.
Trzy fakty z materiału SAP, które w programie konwersji zmieniają rozmowę:
- licencja jest liczona per użytkownik, z pułapem stu użytkowników, a użytkownikiem jest także osoba, która tylko czyta wyniki skanu,
- analizator można aktywować bez licencji - system pokaże wtedy ostrzeżenie, i tyle,
- licencja z SAP ERP nie przechodzi na SAP S/4HANA, potrzebna jest nowa.
Ten ostatni punkt jest dla programu konwersji krytyczny, bo dotyka firm, które akurat robiły wszystko dobrze. Skanowaliście kod na SAP ECC przez lata, macie proces, macie wyjątki, macie historię. Po konwersji stoicie z tym samym procesem i bez licencji, dokładnie w momencie, w którym baza kodu zmieniła się najbardziej.
Do tego dochodzą trzy ograniczenia, o których warto wiedzieć, zanim ktoś pokaże zarządowi zielony wykres:
Pierwszy przebieg daje tysiące znalezisk. Tak opisuje to sam SAP. To nie jest powód, żeby nie skanować - to powód, żeby ustalić segregację znalezisk, właściciela i kryteria zamknięcia, zanim uruchomicie skan, a nie po.
Analiza przepływu danych nie przekracza jednostki kompilacji. Jeżeli skanujecie raport, który woła moduł funkcyjny, podatność w tym module nie zostanie znaleziona. Musicie przeskanować moduł. Zielony wynik mówi wtedy o zakresie skanu, a nie o stanie systemu.
Znalezisko nie blokuje wydania. W standardzie znaleziska priorytetu trzeciego nie zatrzymują transportu, a produkt można wydać z otwartymi znaleziskami. Narzędzie nie podejmie za was decyzji o ryzyku. Ono tylko sprawia, że decyzja jest świadoma.
Jeżeli kod własny jest u was dużym tematem, mamy o nim osobny wpis o nieoczywistych zagrożeniach w kodzie ABAP, a o tym, co do tego równania dokłada kod pisany przez asystentów, pisaliśmy tutaj.
Cutover i dwa tygodnie, których nikt nie pilnuje
Cutover to jedyny moment w programie, w którym wszystkie cztery mechanizmy pracują naraz. W ciągu jednej doby albo dwóch jedzie komplet transportów, przełączane są integracje, konta techniczne dostają nowe hasła albo zachowują stare, a kontrola zmiany działa w trybie, który zespół sam nazywa awaryjnym. To nie jest zaniedbanie - tak wygląda każde przełączenie systemu, który obsługuje firmę. Problem zaczyna się przy zdaniu, które pada wtedy w każdej organizacji: „nie cofamy, bo wycofanie kosztuje tydzień przestoju”.
W zwykłym utrzymaniu transport z brakiem kontroli uprawnień utyka na bramce. W cutoverze przechodzi, bo kryterium brzmi „czy się aktywuje”, a nie „czy jest bezpieczny”. Różnica nie leży w narzędziach. Leży w tym, że przez dwie doby koszt zatrzymania czegokolwiek jest wyższy niż koszt przepuszczenia.
Potem przychodzi część jeszcze gorzej opisana. Przez pierwsze dwa tygodnie po uruchomieniu cały zespół pilnuje wydajności, zamknięcia okresu i tego, czy dokumenty się księgują. Monitorowanie bezpieczeństwa nowego systemu zwykle jeszcze nie działa w pełnym zakresie, bo reguły alertowania dostraja się „jak już się uspokoi”. To znaczy, że najgorętszy okres w całym programie jest jednocześnie jedynym, z którego nie macie danych. Jeżeli coś wydarzyło się w cutoverze, dowiecie się o tym z innego źródła niż własny dziennik zdarzeń.
Obowiązki regulacyjne nie robią w tym czasie przerwy - o tym za moment osobno. Tu wystarczy jedna obserwacja: zegar na zgłoszenie incydentu rusza od wykrycia, a nie od momentu, w którym zespół projektowy uzna, że ma czas.
Co wpisać w kryteria przejścia
Najtańsza zmiana w całym programie kosztuje jedno zdanie w dokumencie, który już istnieje. Kryteria przejścia między fazami i kryteria dopuszczenia do uruchomienia produkcyjnego są spisane, uzgodnione i podpisywane. Wystarczy, że znajdą się w nich cztery pozycje, które dzisiaj zwykle są tylko czyimś zmartwieniem.
Stan wyjściowy zmierzony przed zamrożeniem. Konfiguracja, uprawnienia i kod w SAP ECC opisane liczbami w dniu, w którym wchodzi change freeze. Bez tego zdjęcia nie udowodnicie po roku, co przenieśliście, a czego nie, a audytor zapyta.
Próg blokujący dla znalezisk w kodzie. Nie „przeskanujemy kod”, tylko: który priorytet zatrzymuje transport, kto może udzielić odstępstwa i na jaki czas. Narzędzie w standardzie nie zatrzyma transportu za was.
Wygaszenie dostępu projektowego jako kamień milowy. Uprawnienia awaryjne, konta integratora i konta serwisowe z datą w systemie, nie w umowie, i z zadaniem odbioru po cutoverze.
Monitorowanie działające przed uruchomieniem, nie po. Dziennik audytu bezpieczeństwa, zbieranie zdarzeń i reguły alertowania włączone i przetestowane w systemie docelowym przed go-live. Jeżeli pierwszy tydzień produkcji jest też pierwszym tygodniem monitorowania, nie macie danych z najgorętszego okresu w całym programie.
Nad tymi czterema pozycjami stoi pytanie o właściciela. Program konwersji ma kierownika, architekta, właścicieli procesów i partnera wdrożeniowego. Rzadko ma kogoś, kto ma wypisane prawo zatrzymania uruchomienia z powodu bezpieczeństwa. Jeżeli takiej osoby nie ma, to znaczy, że decyzję o ryzyku podejmuje harmonogram.
Sześć pytań, które warto zadać na komitecie sterującym
To nie jest lista narzędzi do kupienia. To sześć pytań, na które program konwersji albo ma odpowiedź, albo właśnie znaleźliście temat na najbliższy przegląd.
1. Kto ma prawo zatrzymać go-live z powodu bezpieczeństwa i czy to prawo jest zapisane w kryteriach przejścia, czy tylko w czyjejś intencji?
2. Ile kopii produkcji istnieje dzisiaj, kto jest właścicielem każdej z nich i które z nich mają aktywne połączenia RFC do systemów, które nadal księgują?
3. Jaka jest data wygaśnięcia uprawnień awaryjnych integratora i gdzie ta data jest wpisana w systemie, a nie w umowie?
4. Czy w przebiegach ABAP Test Cockpit działa wariant bezpieczeństwa, kto jest właścicielem znalezisk i jaki próg blokuje transport?
5. Kto po przejściu do RISE with SAP składa wniosek o łatkę bezpieczeństwa, w jakim czasie i kto akceptuje przestój?
6. Kiedy złożyliście wniosek o zgodę na test penetracyjny przed uruchomieniem produkcyjnym, skoro wymaga on zatwierdzenia przez SAP i dotyczy wyłącznie warstwy aplikacji?
Pytanie szóste w większości programów nie ma odpowiedzi, bo nikt go nie zadał na czas. To jest dobry moment, żeby je zadać.
Regulator nie czeka na wasz cutover
Ta część dotyczy wyłącznie polskiego rynku i w materiałach producentów nie występuje, bo tam jej nie ma.
Program konwersji, który zaczyna się dzisiaj, kończy się w oknie, w którym obowiązki z ustawy o krajowym systemie cyberbezpieczeństwa są już w pełni egzekwowane. Liczy się w nich czas od wykrycia incydentu, a nie od momentu, w którym zespół projektowy skończył cutover: dwadzieścia cztery godziny na wczesne ostrzeżenie i siedemdziesiąt dwie godziny na zgłoszenie incydentu poważnego. Zestawcie to z realiami programu konwersji. Incydent w systemie projektowym z kopią produkcji, wykryty w weekend przełączeniowy, przez zespół, który w tym momencie ma inne zadanie, i przy monitorowaniu uruchamianym dopiero po go-live. Zegar rusza mimo to.
Drugi wniosek jest przyjemniejszy. Ten sam program jest najlepszą okazją w dekadzie, żeby wejść w te obowiązki z porządną dokumentacją, bo i tak opisujecie systemy, przepływy danych, role i dostawców. Rozpisaliśmy to osobno we wpisie o ustawie o KSC i NIS2 w kontekście systemów SAP.
Gdzie w tym stoi SecurityBridge
Deklaracja wprost: SNOK jest partnerem SecurityBridge i wdrażamy tę platformę u klientów. Dlatego napiszemy to precyzyjnie, a nie hasłowo.
SecurityBridge nie zastępuje SAP Code Vulnerability Analyzer i nie rozwiązuje kwestii licencji po stronie SAP. Pokrywa natomiast dokładnie tę warstwę, która w modelu RISE with SAP zostaje po waszej stronie: ciągłą ocenę podatności i konfiguracji, monitorowanie aktywności użytkowników i ruchu na interfejsach, analizę kodu własnego oraz dopasowanie do ram zgodności. W programie konwersji sensowne miejsca są cztery: zdjęcie stanu wyjściowego SAP ECC przed zamrożeniem, nadzór nad zamrożonym krajobrazem w trakcie, kontrola kodu i transportów w toku projektu oraz porównanie stanu docelowego ze stanem wyjściowym przed go-live. Piąte miejsce zaczyna się dzień po uruchomieniu i trwa tak długo, jak system.
Jeżeli chcecie zobaczyć, jak to wygląda w naszej praktyce, opisaliśmy platformę na osobnej stronie.
Jedna rzecz od nas
Zakończyliśmy właśnie wdrożenie w jednej z największych instytucji publicznych w Polsce korzystających z SAP. Szczegóły wkrótce, w zakresie, na jaki pozwoli nam umowa. Wspominamy o tym w tym miejscu nie przypadkiem: to, co opisaliśmy wyżej, nie jest teorią z prezentacji dostawcy, tylko listą rzeczy, które trzeba rozstrzygnąć w prawdziwym programie, z prawdziwym terminem i prawdziwym audytem na końcu.
Na koniec, najkrócej jak się da
Konwersja do SAP S/4HANA nie jest ryzykowna dlatego, że ktoś zaniedbał bezpieczeństwo. Jest ryzykowna dlatego, że wszystkie decyzje, które ją otwierają, są osobno rozsądne. Zamrożenie zmian chroni stabilność. Kopie produkcji są warunkiem sensownych testów. Uprawnienia awaryjne pozwalają integratorowi pracować. Wariant ATC pod konwersję odblokowuje uruchomienie. RISE with SAP zdejmuje z was infrastrukturę. Każda z tych rzeczy ma dobre uzasadnienie i żadna z nich nie ma w harmonogramie miejsca, w którym ktoś pyta, co z nich razem wynika.
Dlatego całą tę listę da się sprowadzić do jednego pytania, które warto zadać na najbliższym komitecie sterującym: kto w tej firmie ma prawo zatrzymać uruchomienie produkcyjne z powodu bezpieczeństwa i gdzie to prawo jest zapisane. Jeżeli odpowiedź brzmi „nikt” albo „nie wiem”, to decyzję o ryzyku podejmuje harmonogram, a harmonogram nie odpowie potem przed audytorem.
Jeżeli prowadzicie dzisiaj taki program i któreś z sześciu pytań zostało bez odpowiedzi, napiszcie do nas. Przejdziemy je z waszym zespołem.
Źródła
- SecurityBridge, Jephy Pothen, Security by Design in the Age of S/4HANA and SAP RISE Migrations, 13 stycznia 2026 - securitybridge.com
- SecurityBridge, Joris van de Vis, Breaking the Rules: Why Standard SAP Controls Are Not Enough, 20 sierpnia 2026 - securitybridge.com
- SAP Community, Jana Subramanian, RISE with SAP S/4HANA Cloud, Private Edition: Cybersecurity FAQ Explained - community.sap.com
- SAP Community, SAP Code Vulnerability Analyzer (CVA) - FAQs - community.sap.com
- SAP, Maintenance strategy - SAP S/4HANA and SAP Business Suite 7 - support.sap.com
Zakres odpowiedzialności w RISE with SAP opisujemy za materiałem opublikowanym przez SAP. W konkretnej umowie rozstrzyga dokument Roles and Responsibilities oraz warunki kontraktu - sprawdźcie własne, zanim oprzecie na tym decyzję.