# SUSE i SNOK w Villi Foksal: od której warstwy zacząć obronę SAP
> Relacja z warsztatów SUSE i SNOK: SLES for SAP 16, SAP HANA na KVM zamiast VMware, SecurityBridge w stosie ABAP i SSO do SAP GUI bez Active Directory.
- Source: https://snok.ai/pl/aktualnosci/blog/suse-snok-warsztaty-bezpieczenstwo-sap/
- Author: Jacek Bugajski
- Published: 2026-11-04
---
*Piszą Jacek Bugajski, prezes SNOK, i Jarosław Zdanowski, partner SNOK, który prowadził naszą sesję na warsztatach. Obaj byliśmy na sali.*
Wtorek, 3 listopada, ulica Foksal w Warszawie. Sala Villi Foksal podświetlona na zielono, na stolikach pluszowe kameleony SUSE, na ekranie przewijają się kroki roli Ansible `sap_install`, która przygotowuje serwer pod **SAP HANA**. Spotkanie „Od ryzyka do odporności” przygotowaliśmy razem z **SUSE** dla zespołów odpowiedzialnych za bezpieczeństwo i ciągłość działania systemów **SAP**. Formuła Lunch & Learn i pełna sala: przyszli wszyscy zarejestrowani uczestnicy.
Program był przekrojem przez środowisko SAP, od jądra systemu operacyjnego, przez wirtualizację i wnętrze aplikacji, po logowanie użytkownika do SAP GUI. Patrzyliśmy na niego z dwóch stron - od infrastruktury i od bezpieczeństwa aplikacji - dlatego tę relację piszemy we dwóch, każdy swoim głosem.
**W skrócie:**
**1/** zespół SUSE pokazał SUSE Linux Enterprise Server for SAP Applications 16 z SELinux, automatyczną instalacją przez Agamę i Ansible oraz cztery pokazy w konsoli, w tym awarię SAP HANA diagnozowaną w Trento z asystentem AI,
**2/** wirtualizacja SAP HANA na KVM ma walidację SAP dla konkretnych scenariuszy i procesorów, dziś do 8 TB pamięci na maszynę wirtualną na Intel Xeon 6,
**3/** w sesji SNOK Jarosław Zdanowski omówił, czego utwardzony system operacyjny nie widzi: ataku prowadzonego wewnątrz SAP, który wykrywa SecurityBridge działający w stosie ABAP,
**4/** logowanie do SAP GUI przez OpenID Connect w TrustBrokerze 5.1.1 działa bez Active Directory, a pakiet serwerowy jest dostępny także dla SUSE Linux Enterprise Server 16.
Utwardzanie platformy systemowej SAP - wystąpienie Adama Jeża, SUSE
## SUSE Linux Enterprise Server for SAP Applications 16 - utwardzenie od pierwszej instalacji
Pierwsze półtorej godziny należało do SUSE. W wystąpieniu Adama Jeża, Solutions Architect, pierwsze miejsce zajęły zmiany w **SUSE Linux Enterprise Server for SAP Applications 16**. SELinux staje się mechanizmem ochrony systemu operacyjnego; aplikacje SAP działają w domenie unconfined, a sam SELinux startuje w trybie permissive, więc wdrożenie nie wywraca istniejących instalacji. Narzędzie sapconf ustępuje miejsca saptune, które dostraja parametry jądra do wymagań obciążeń SAP zgodnie z notami SAP. Instalację prowadzi Agama, a jej konfigurację można wyeksportować do profilu JSON i odtworzyć na kolejnym serwerze bez ręcznej konfiguracji. SUSE dostarcza role i playbooki Ansible rozwijane w otwartej inicjatywie SAP Linux Lab, a każde wydanie minor ma pięć lat wsparcia.
Potem slajdy ustąpiły miejsca konsoli. Cztery pokazy: automatyczna instalacja SLES for SAP 16, automatyczna instalacja klastra wysokiej dostępności z SAP HANA, aktualizacja jądra i biblioteki glibc metodą live patching bez restartu oraz awaria SAP HANA diagnozowana w Trento z modelem językowym podłączonym przez serwer MCP.
**Jacek:** Dla mnie to była najważniejsza część dnia. Odłożona poprawka jądra, bo restart wymaga okna serwisowego, i serwer zbudowany ręcznie inaczej niż jego bliźniak to dwie wymówki dobrze znane każdemu, kto utrzymuje SAP. Live patching i instalacja z profilu usuwają obie. O utwardzaniu SAP HANA na SLES pisałem już przy okazji [konfiguracji zapory sieciowej dla SAP HANA](https://snok.ai/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-hardening-sap-hana-na-sles-skuteczna-konfiguracja-fire/) - wersja 16 przenosi wiele z tych zaleceń do konfiguracji domyślnej.
**Jarek:** Zgoda co do platformy, z jednym zastrzeżeniem. SELinux w trybie permissive i aplikacja SAP w domenie unconfined to uczciwy kompromis, tyle że oznacza wprost: system operacyjny nie pilnuje tego, co robi SAP. Utwardzony Linux jest warunkiem koniecznym, ale niewystarczającym, i nie chcę, żeby ktoś wyszedł z sali z przekonaniem, że po instalacji SLES 16 temat bezpieczeństwa SAP jest zamknięty.
## Trento z serwerem MCP - asystent AI przy awarii SAP HANA z ograniczonymi uprawnieniami
Konsola Trento - widok hostów SAP z wynikami kontroli zgodności
Trento to konsola SUSE do monitorowania środowisk SAP. Sprawdza zgodność konfiguracji z dobrymi praktykami i notami SAP, a przy każdym niespełnionym warunku pokazuje, jakie fakty zebrała, jakiej wartości oczekiwała i dlaczego test nie przeszedł. Wersja 3.0 dodaje integrację z modelem językowym przez MCP, z ograniczeniami: operacje chronione uprawnieniami, wewnętrzne zabezpieczenia i jedna operacja naraz na jednym celu.
**Jacek:** Na ten kierunek czekałem. Administrator przy nocnej awarii HANA potrzebuje kogoś, kto przeczyta fakty zebrane z klastra i zaproponuje kolejny krok - kolejny pulpit niewiele mu da.
**Jarek:** Pod warunkiem, że ten ktoś nie zrobi kroku sam. Każdy serwer MCP podłączony do produkcyjnego SAP to nowa ścieżka wykonania poleceń, więc nowa powierzchnia ataku. Zasada jednej operacji naraz i uprawnienia na każdą operację to dobry początek, ale w projekcie zaczynałbym od trybu tylko do odczytu. Szerzej opisywaliśmy to w tekście o [trzech aktach SAP AI i bezpieczeństwie agentów](https://snok.ai/pl/aktualnosci/blog/trzy-akty-sap-ai-bezpieczenstwo-agentow/).
## SAP HANA na KVM - alternatywa dla VMware z walidacją SAP
Następnie Jarosław Biniek z SUSE zajął się wirtualizacją. Wirtualizator dla SAP HANA nie może być dowolny: SAP wymaga jego walidacji, bo od niej zależą spójność danych, wspólna linia wsparcia i wydajność bliska serwerowi fizycznemu. Według zestawienia SUSE z prezentacji VMware vSphere pozostaje liderem z szerokim wsparciem, Nutanix AHV ogranicza maszynę wirtualną do 4,5 TB pamięci, Red Hat OpenShift Virtualization nie jest obsługiwany przez SAP (SUSE powołuje się na notę SAP 1122387, brak wsparcia potwierdza też sam Red Hat), a KVM w SUSE Linux Enterprise Server for SAP Applications ma walidację zarówno dla SAP HANA, jak i dla pozostałych aplikacji SAP.
Walidacja dotyczy konkretnych permutacji: wersji SLES, architektury procesora, liczby gniazd, ilości pamięci, typu pamięci masowej i scenariusza wdrożenia. Dla SLES for SAP 15 SP7 obejmuje dziś procesory Intel Xeon od Cascade Lake po Granite Rapids, maszyny wirtualne do 8 TB pamięci, dyski NFS, Fibre Channel i podłączone bezpośrednio oraz scenariusze Single-VM i Multi-VM. Najnowsza nota SAP 3741904 dotyczy SAP HANA na SUSE KVM z SLES 15 SP7. Plany SUSE, z zastrzeżeniem możliwych zmian, zapowiadają 16 TB na dwóch gniazdach Diamond Rapids z wersją 16.1.
**Jacek:** Tu nie mam wątpliwości. KVM wchodzi w skład SLES for SAP, więc kto ma tę subskrypcję, ten już za niego zapłacił - często w tym samym roku, w którym negocjuje z Broadcomem nowe warunki dla vSphere. Pisałem o tym w analizie [VMware czy KVM dla SAP](https://snok.ai/pl/aktualnosci/blog/vmware-kvm-sap-suse-broadcom-2026/) i w tekście o [vendor lock-in w 2026 roku](https://snok.ai/pl/aktualnosci/blog/vendor-lock-in-zlota-klodka-czy-pek-kluczy/). Warsztaty dały to, czego w rachunku kosztów brakowało: listę not SAP, z którą zespół Basis może iść do zarządu.
**Jarek:** I właśnie ta lista studzi mój entuzjazm. Walidacja obejmuje konkretną kombinację wersji systemu, procesora, liczby gniazd i pamięci masowej. Kto ma serwery spoza tabeli albo bazę większą niż zwalidowany rozmiar maszyny wirtualnej, ten w tym roku nie migruje, tylko planuje wymianę sprzętu. Zanim ktokolwiek policzy oszczędności na licencjach, zespół Basis powinien przyłożyć własne środowisko do noty SAP 3741904.
**Jacek:** Dla mnie to argument za inwentaryzacją przed odnowieniem umowy z VMware, a nie po nim.
**Jarek:** Na to się zgadzam.
Wykrywanie ataków wewnątrz SAP - sesja SNOK, prowadzi Jarosław Zdanowski
## SecurityBridge - wykrywanie ataków, których system operacyjny nie widzi
Po przerwie przyszła sesja SNOK. Jarosław Zdanowski zaczął od tezy, która spinała cały dzień: utwardzony system operacyjny nie widzi aplikacji SAP. Nadużycie uprawnień, nietypowe wywołanie RFC albo zmiana w tabeli krytycznej to dla systemu operacyjnego i dla EDR prawidłowa praca procesu SAP.
**SecurityBridge** działa jako dodatek w stosie ABAP, bez osobnego kolektora. Według bazy wiedzy producenta moduł Threat Detection ma 131 sensorów zdarzeń i setki wzorców ataków specyficznych dla SAP. Zdarzenie krytyczne zamienia się w incydent, incydent trafia do posiadanego SIEM (Splunk, IBM QRadar, Microsoft Sentinel, ArcSight, LogRhythm i inne), a platforma może zareagować sama, na przykład blokując konto albo kończąc sesję. W subskrypcji jest osiem modułów, od oceny konfiguracji i stanu not bezpieczeństwa SAP, przez mapę ruchu RFC i HTTP, po analizę podatności w kodzie ABAP i kontrolę zleceń transportowych. Platforma ma wbudowane ramy ISO/IEC 27001, ISO/IEC 27002 i dyrektywy NIS2.
**Jarek:** To jest warstwa, którą zespoły SOC obserwują najsłabiej. Zdarzenia z SAP nie trafiają do ich narzędzi, a specyfika SAP nie jest ich codziennością. Dlatego zaczynałbym od wykrywania wewnątrz aplikacji, bo tam leżą dane i procesy, o które chodzi atakującemu. Niezgodność widać w dniu zmiany, co przy obowiązkach z [nowelizacji KSC i NIS2](https://snok.ai/pl/aktualnosci/blog/ksc-nis2-sap-securitybridge/) ma znaczenie. Zastrzeżenie, które powtórzyłem na sali: platforma wspiera proces zapewnienia zgodności, ale nie zastępuje oceny prawnej obowiązków organizacji.
**Jacek:** Kusi prosta kolejność: najpierw platforma i poprawki, które kosztują głównie dyscyplinę, potem warstwa aplikacji. Tu jednak przyznaję Jarkowi rację.
**Jarek:** Atakujący nie czeka, aż skończymy pierwszy etap. Obie warstwy trzeba prowadzić równolegle, inaczej przez rok porządkowania platformy nikt nie widzi, co się dzieje w SAP.
**Jacek:** I to jest wniosek, który zabieram z tego dnia. Utwardzona platforma bez wglądu w SAP daje poczucie bezpieczeństwa, którego nie ma. Detekcję wewnątrz aplikacji uruchamiamy od razu, równolegle z porządkami w systemie operacyjnym. Jak wdrażamy SecurityBridge, opisujemy na stronie [SecurityBridge w SNOK](https://snok.ai/pl/oferta/bezpieczenstwo-sap/securitybridge/).
## TrustBroker 5.1.1 - logowanie do SAP GUI bez Active Directory
Druga część sesji SNOK dotyczyła logowania. TrustBroker od wersji 5.1 obsługuje w bibliotece SNC protokół OpenID Connect obok Kerberosa, więc pojedyncze logowanie do SAP GUI działa bez Active Directory pośrodku, bezpośrednio z Entra ID, Oktą, Ping albo Keycloakiem. Uwierzytelnienie odbywa się kluczem passkey, przez Windows Hello for Business albo tokenem FIDO2, czyli metodami odpornymi na phishing. Ponowne uwierzytelnienie można wymusić przy uruchomieniu wrażliwej transakcji, na wskazanym ekranie albo przy podpisie elektronicznym. Kerberos i OIDC działają równolegle. Pakiet serwerowy TrustBrokera jest dostępny między innymi dla SUSE Linux Enterprise Server 16, więc platforma, którą rano utwardzał zespół SUSE, po przerwie dostała logowanie odporne na phishing.
**Jarek:** Przejęcie konta w domenie wciąż jest najkrótszą drogą do SAP. Dopóki logowanie do SAP GUI wisi na Kerberosie, kontrole tożsamości zbudowane w chmurze w tej ścieżce po prostu nie występują. Szczegóły techniczne opisałem we wpisie [TrustBroker 5.1 - SSO i MFA do SAP bez Active Directory](https://snok.ai/pl/aktualnosci/blog/trustbroker-5-1-sso-mfa-sap-bez-active-directory/).
**Jacek:** Tu sporu nie ma. Dorzucę perspektywę zarządu: to jedna z niewielu zmian w bezpieczeństwie SAP, którą użytkownik odczuwa jako ułatwienie, bo znika hasło do SAP. O budżet na projekt, który nie budzi oporu użytkowników, jest łatwiej.
## SUSE i SNOK: cały stos SAP w jednej sali
**Jacek:** Spotkania o bezpieczeństwie SAP zwykle rozdzielają warstwy. Konferencje infrastrukturalne kończą się na hiperwizorze, konferencje bezpieczeństwa zaczynają od uprawnień i SIEM. Trzeciego listopada te dwa światy siedziały w jednej sali i rozmawiały o tym samym systemie. Tak pracujemy na co dzień - w ramach [utrzymania SAP Basis 24/7](https://snok.ai/pl/oferta/bezpieczenstwo-sap/sap-basis-24-7/) odpowiadamy za system operacyjny, bazę i aplikację jednocześnie.
**Jarek:** Wniosek mamy wspólny: atak i awaria nie respektują granic między zespołem Linuksa, zespołem Basis i SOC. Kto pilnuje jednej warstwy, widzi tylko fragment obrazu.
Po części merytorycznej została godzina na lunch i rozmowy w kuluarach. Dziękujemy zespołowi SUSE - Tomaszowi Surmaczowi, Adamowi Jeżowi i Jarosławowi Bińkowi - za wspólne przygotowanie spotkania, a uczestnikom za komplet na sali. Więcej o naszym partnerstwie piszemy na stronie [SUSE i SNOK](https://snok.ai/pl/suse-snok/).
## Książka „Cyberbezpieczeństwo SAP od A do Z” nadal do pobrania
Wątki z warsztatów rozwijamy w książce [„Cyberbezpieczeństwo SAP od A do Z”](https://snok.ai/pl/materialy/cyberbezpieczenstwo-sap-od-a-do-z/), którą napisaliśmy razem na podstawie projektu wzmocnienia bezpieczeństwa SAP w dużej instytucji publicznej. To 304 strony w 24 rozdziałach i pięciu częściach: od tożsamości i dostępu, przez model zagrożeń z agentami AI, po detekcję i reakcję z SOC i SIEM oraz program zgodności z KSC, NIS2, DORA i ISO 27001, z kwartalną listą kontrolną dla CIO i CISO w aneksie. Książka cały czas czeka do pobrania, w wydaniu polskim i angielskim - po wypełnieniu formularza wyślemy ją na Wasz służbowy adres e-mail. O tym, jak powstała, opowiadamy we wpisie [Cyberbezpieczeństwo SAP od A do Z - książka gotowa do pobrania](https://snok.ai/pl/aktualnosci/blog/ksiazka-cyberbezpieczenstwo-sap-od-a-do-z/).
Jeżeli chcecie zobaczyć SecurityBridge albo TrustBroker na własnym środowisku, albo porozmawiać o przeniesieniu SAP HANA na KVM, napiszcie do nas przez stronę [bezpieczeństwa SAP](https://snok.ai/pl/oferta/bezpieczenstwo-sap/securitybridge/).
