# Security Score w RISE with SAP - co mierzy zielony wskaźnik, a czego nie widzi

> Security Score w RISE with SAP: 28 metryk i trzy KPI według dokumentacji SAP. Czego punktacja nie obejmuje i jak domknąć lukę w rolach, kodzie i detekcji.

- Source: https://snok.ai/pl/aktualnosci/blog/security-score-rise-with-sap/
- Author: Jarosław Zdanowski
- Published: 2026-11-03

---
SAP ogłosił w sierpniu 2026 roku nowy obszar oceny w pulpicie RISE with SAP Methodology Dashboard: Security Score. Bezpieczeństwo waży w nim 40% oceny operacyjnej systemu, więcej niż kondycja systemu i konfiguracja narzędzi operacyjnych. Na liście 28 metryk, z których SAP liczy ten wynik, tożsamość i dostęp to siedem kontroli kont standardowych. Kontroli ról i uprawnień użytkowników na tej liście nie ma.

To dobry krok SAP. Punktacja wymusza uruchomienie analizy konfiguracji, karze brak pomiaru i daje zarządowi czytelny wskaźnik dla produkcyjnych systemów SAP S/4HANA podłączonych do SAP Cloud ALM. Ryzyko pojawia się dopiero przy wniosku „wynik jest zielony, więc system jest bezpieczny”. Żeby ocenić, na ile ten wniosek jest uprawniony, przeszliśmy przez pełną listę metryk w dokumentacji SAP.

**W skrócie:**

**1/** Security Score to 28 kontroli konfiguracji produkcyjnego systemu SAP S/4HANA, sprawdzanych raz na dobę w SAP Cloud ALM,

**2/** punktacja ocenia utwardzanie systemu, aktualność komponentów i konta standardowe; nie ocenia ról, uprawnień, kodu własnego ani systemów nieprodukcyjnych,

**3/** widzi brakującą aktualizację, ale nie widzi, że ktoś z luki właśnie korzysta,

**4/** ścieżka ataku z pięciu kroków może prowadzić z systemu testowego do danych w produkcji, a wynik pozostaje zielony,

**5/** domknięcie luki wymaga przeglądu ścieżek ataku, kontroli kodu i stałej detekcji w systemie.

## Czym jest Security Score w RISE with SAP

Security Score jest jednym z trzech obszarów oceny w widoku Operations View pulpitu RISE with SAP, obok kondycji systemu (System Health) i konfiguracji narzędzi operacyjnych (Operations Setup). SAP ogłosił go we wpisie w SAP Community 11 sierpnia 2026 roku. Wynik dotyczy produkcyjnych systemów SAP S/4HANA podłączonych do SAP Cloud ALM, w których działa aplikacja Configuration and Security Analysis (CSA). Kontrole SAP wybrał z SAP Security Baseline Template, opisanego w nocie SAP 2253549.

Wagi w ocenie operacyjnej są stałe:

| Obszar oceny | Waga |
|---|---|
| Security | 40% |
| System Health | 30% |
| Operations Setup | 30% |

Sam Security Score składa się z trzech wskaźników:

- System Hardening - 40%, 17 metryk,
- Vulnerability & Lifecycle - 40%, 4 metryki,
- Identity & Access Control - 20%, 7 metryk.

W ocenie operacyjnej całego systemu daje to 16% dla utwardzania, 16% dla aktualności komponentów i 8% dla tożsamości i dostępu. Wynik powyżej 85% jest zielony, między 70 a 85% pomarańczowy, poniżej 70% czerwony. Pulpit pokazuje wartość z poprzedniego dnia i trend z 30 dni.

Dwie zasady działają na korzyść klienta. Kontrola, której nie włączono w CSA, liczy się jako niezgodna, więc brak pomiaru obniża wynik. Kontrole należące w RISE do SAP też są widoczne, więc klient widzi pełny obraz, łącznie z częścią zarządzaną przez SAP.

## Co sprawdzają metryki Security Score w RISE with SAP

System Hardening (17 metryk) obejmuje opcje zmian w systemie i ustawienia klienta wraz z ich zmianami, długość i ważność haseł, hasła zgodne wstecz, szyfrowanie komunikacji wewnętrznej, listy kontroli dostępu bramy RFC i serwera komunikatów, ścieżkę pliku ACL serwera komunikatów, ustawienia bezpieczeństwa i monitorowania bramy, tryb symulacji bramy, ochronę monitorowania serwera komunikatów oraz metodę zabezpieczenia relacji zaufania między systemami.

Vulnerability & Lifecycle (4 metryki) sprawdza aktualizacje pakietów wsparcia, wiek pakietów, wiek jądra SAP i wiek biblioteki SAP Cryptolib. Wskaźnik ma tylko cztery metryki i 40% wagi, więc jedna nieaktualna pozycja wyraźnie obniża cały wynik. SAP opisuje to jako zamierzone.

Identity & Access Control (7 metryk) dotyczy wyłącznie kont standardowych: SAP* (hasło domyślne, istnienie, blokada), SAPCPIC, TMSADM (hasło domyślne i obecność w kliencie produkcyjnym) oraz EARLYWATCH.

SAP zastrzega to wprost: „The Security Score is not intended to replace Configuration and Security Analysis” (punktacja nie ma zastępować Configuration and Security Analysis). Ma być punktem wejścia, od którego zespół przechodzi do szczegółowej analizy w CSA.

## Czego Security Score nie obejmuje

Poniższe obszary wynikają wprost z zakresu opisanego przez SAP.

- **Role i uprawnienia.** Na liście 28 metryk (stan dokumentacji SAP na 2 listopada 2026 roku) nie ma kontroli ról, uprawnień krytycznych, SAP_ALL ani rozdziału obowiązków. Użytkownik techniczny z szeroką rolą nie zmienia wyniku.
- **Wykorzystanie podatności.** Punktacja widzi brakującą aktualizację, ale nie widzi wywołania podatnej usługi. To ocena ustawień raz na dobę, nie detekcja zdarzeń.
- **Kod własny ABAP.** Żadna metryka nie dotyczy kodu Z. Do jego analizy SAP oferuje osobne narzędzie: SAP Code Vulnerability Analyzer w ABAP Test Cockpit.
- **Systemy poza produkcyjnym SAP S/4HANA.** Systemy deweloperskie i testowe, SAP BW, SAP GRC i SAP BTP nie wchodzą do wyniku.
- **Sens relacji między systemami.** Punktacja sprawdza, jak zabezpieczono relację zaufania i bramę RFC w jednym systemie. Nie ocenia, czy dana relacja w ogóle powinna istnieć.

## Ścieżka ataku przy zielonym wyniku

Ryzyko w SAP rzadko wynika z jednego ustawienia. Napastnik buduje ścieżkę z kilku kroków, z których żaden osobno nie wygląda groźnie. Przykład, w którym żaden krok nie obniża wyniku. Część kroków leży poza zakresem 28 metryk, a tam, gdzie metryka działa, pokazuje zgodność:

1. Wejście przez system testowy. Systemy nieprodukcyjne są poza zakresem punktacji, a często mają słabsze zabezpieczenia niż produkcja.
2. Zaufane połączenie RFC z systemu testowego do produkcji. Relacja jest zabezpieczona właściwą metodą, więc metryka pokazuje zgodność. Punktacja nie pyta, po co ta relacja istnieje.
3. Użytkownik techniczny z szeroką rolą, bez SAP_ALL i bez hasła domyślnego. Role są poza zakresem.
4. Wywołanie własnego modułu Z bez kontroli uprawnień. Kod własny jest poza zakresem.
5. Dane opuszczają system. Następnego dnia Security Score pozostaje zielony, bo żadne z 28 ustawień się nie zmieniło.

<figure class="blog-video">
  <video autoplay muted loop playsinline controls preload="metadata" poster="/images/blog/security-score-rise-with-sap-sciezka.webp" width="1600" height="900" aria-label="Diagram: ścieżka ataku w pięciu krokach od systemu testowego przez zaufane RFC i użytkownika technicznego do kodu Z i danych w produkcyjnym SAP S/4HANA, przy każdym kroku Security Score pozostaje zielony" style="width:100%;height:auto;border-radius:0.75rem;border:1px solid rgba(255,255,255,0.1);">
    <source src="https://snok.ai/images/blog/security-score-rise-with-sap-sciezka-pl.mp4" type="video/mp4" />
    Wasza przeglądarka nie obsługuje odtwarzania wideo. <a href="/images/blog/security-score-rise-with-sap-sciezka-pl.mp4">Pobierzcie animację (MP4)</a>.
  </video>
  <figcaption>Pięć kroków ścieżki ataku i stan Security Score przy każdym z nich</figcaption>
</figure>

Tę samą logikę opisywaliśmy przy [SAPMAP, narzędziu do mapowania ścieżek ataku w SAP](https://snok.ai/pl/aktualnosci/blog/sapmap-bloodhound-dla-sap/). Pytanie kontroli brzmi „które ustawienia są niezgodne?”. Napastnik pyta, jaka jest najkrótsza droga do danych. Te dwa pytania rzadko mają tę samą odpowiedź.

## Jak domknąć lukę po stronie klienta

Macierz odpowiedzialności SAP dla RISE with SAP S/4HANA Cloud Private Edition w wariancie tailored option (wersja z lipca 2026 roku) dzieli te obszary wyraźnie. Techniczne połączenia RFC do systemów centralnych, którymi zarządza SAP, konfiguruje SAP. Administrację użytkownikami i rolami klient prowadzi sam albo kupuje jako usługę dodatkową. Przegląd kodu klienta jest poza zakresem usług SAP. Pisaliśmy o tym podziale przy okazji [bezpiecznej konwersji do SAP S/4HANA w RISE](https://snok.ai/pl/aktualnosci/blog/bezpieczna-konwersja-sap-s4hana-rise/). Do pokrycia obszarów spoza punktacji potrzebne są trzy warstwy kontroli.

**Przegląd ścieżek ataku.** Analiza relacji zaufania, połączeń RFC, użytkowników technicznych i ról w całym krajobrazie, łącznie z systemami nieprodukcyjnymi. Wynikiem są ścieżki uszeregowane według odległości od danych krytycznych.

**Kontrola kodu własnego.** Analiza bezpieczeństwa kodu Z w tym samym przebiegu ATC, który sprawdza gotowość do clean core. Opisywaliśmy to we wpisie o [centralnym ATC na SAP BTP](https://snok.ai/pl/aktualnosci/blog/central-atc-sap-btp-bezpieczenstwo-kodu-abap/).

**Stała detekcja w systemie.** Monitorowanie zdarzeń w systemie SAP z przekazaniem alertów do SIEM, żeby wykorzystanie luki było widać w chwili, gdy następuje. SAP oferuje tu SAP Enterprise Threat Detection. Platforma SecurityBridge ma certyfikat SAP dla wdrożenia jako dodatek w RISE with SAP (certyfikat nr 24982, SAP S/4HANA Cloud Private Edition 2023, ważny do 5 maja 2028 roku). Certyfikat potwierdza zgodność techniczną integracji. Według producenta platforma obejmuje w RISE detekcję zagrożeń, zarządzanie podatnościami i poprawkami z wirtualnym łataniem, analizę kodu ABAP, zarządzanie dostępem uprzywilejowanym, ochronę tożsamości oraz integrację z SIEM. SNOK jest partnerem SecurityBridge i wdraża tę platformę u klientów.

## Jak prowadzimy przegląd warstwy aplikacyjnej w RISE

Przegląd zaczynamy od wyniku Security Score i raportu CSA, bo pokazują stan, który SAP już ocenił. Potem przechodzimy przez obszary spoza punktacji w czterech krokach:

1. Inwentaryzacja połączeń - relacje zaufania, destynacje RFC i użytkownicy techniczni we wszystkich systemach krajobrazu, także testowych.
2. Role i uprawnienia krytyczne - kto ma dostęp do transakcji i obiektów uprawnień, które otwierają drogę do danych finansowych i osobowych.
3. Kod własny - przebieg kontroli bezpieczeństwa kodu Z wraz z oceną krytyczności znalezisk.
4. Ścieżki ataku - złożenie wyników z trzech kroków w ścieżki prowadzące do danych.

Taki zakres wynika z testów penetracyjnych i audytów SAP, które prowadzimy w środowiskach rozwojowych, testowych i produkcyjnych. Wśród najczęściej wykrywanych słabości [w Bezpiecznym Wtorku o testach penetracyjnych SAP](https://snok.ai/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-testy-penetracyjne-systemow-sap-klucz-do-bezpieczenstw/) wymieniliśmy błędną konfigurację ról i uprawnień, słabo zabezpieczone interfejsy RFC, luki w kodzie ABAP klienta oraz brak monitorowania zdarzeń bezpieczeństwa. Role, kod i monitorowanie leżą poza 28 metrykami Security Score, a interfejsy RFC wskaźnik obejmuje tylko w części: przez ustawienia bramy RFC i metodę zabezpieczenia relacji zaufania.

Zarząd dostaje listę ścieżek ataku z oceną krytyczności i planem działań, a zespół SAP listę poprawek do wdrożenia. Szczegóły zakresu opisujemy na stronach [wdrożenia platformy SecurityBridge](https://snok.ai/pl/oferta/bezpieczenstwo-sap/securitybridge/) i [testów penetracyjnych SAP](https://snok.ai/pl/oferta/bezpieczenstwo-sap/pentesty-sap/).

Zielony wynik jest dobrą wiadomością o 28 ustawieniach. Zanim trafi do raportu dla zarządu jako ocena bezpieczeństwa, warto sprawdzić, co mogłoby naruszyć bezpieczeństwo Waszych systemów, gdy ten wynik pozostaje zielony.

## Najczęstsze pytania

### Czy Security Score w RISE with SAP obejmuje role i uprawnienia?

Nie. Wskaźnik Identity & Access Control składa się z siedmiu kontroli kont standardowych: SAP*, SAPCPIC, TMSADM i EARLYWATCH. Według listy metryk w dokumentacji SAP (stan na 2 listopada 2026 roku) punktacja nie ocenia ról, uprawnień krytycznych ani rozdziału obowiązków.

### Skąd Security Score bierze dane?

Z aplikacji Configuration and Security Analysis w SAP Cloud ALM. System musi być produkcyjnym SAP S/4HANA podłączonym do SAP Cloud ALM, z włączonymi kontrolami CSA. Kontrola niewłączona liczy się jako niezgodna.

### Czy Security Score zastępuje Configuration and Security Analysis?

Nie. SAP opisuje punktację jako punkt wejścia do analizy. Szczegółowe wyniki kontroli, także tych spoza zakresu Security Score, zostają w Configuration and Security Analysis.

### Jak często Security Score się aktualizuje?

Raz na dobę. Pulpit pokazuje wartość z poprzedniego dnia (według czasu UTC) i trend z 30 dni.

### Czy zielony Security Score oznacza, że system SAP jest bezpieczny?

Oznacza, że wybrane ustawienia konfiguracji spełniają wymagania SAP Security Baseline Template. Nie obejmuje ról, kodu własnego, systemów nieprodukcyjnych ani zdarzeń w działającym systemie, więc sam nie wystarcza jako ocena bezpieczeństwa.

## Źródła

- SAP Community, „Introducing Security in Operations View: A New Score for RISE with SAP”, 11.08.2026 - [wpis SAP](https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/introducing-security-in-operations-view-a-new-score-for-rise-with-sap/ba-p/14460341) (dostęp 02.11.2026)
- SAP Help Portal, „At a Glance: Available Scores, KPIs, and Metrics” - [dokumentacja SAP Cloud ALM](https://help.sap.com/docs/cloud-alm/applicationhelp/scores-kpis-metrics) (dostęp 02.11.2026)
- SAP Help Portal, Operation Details - Security - [dokumentacja SAP Cloud ALM](https://help.sap.com/docs/cloud-alm/applicationhelp/security-b142fe2fffd34167b2e8384363a11c5c) (dostęp 02.11.2026)
- SAP, certyfikat integracji nr 24982, SecurityBridge Platform 7, 05.05.2025 - [certyfikat w katalogu SAP](https://sapblobs.blob.core.windows.net/csd-live/securitybridge-platform-7-certificate-4ab0e030-2b27-11f0-a62c-6d8a53f9b906) (dostęp 02.11.2026)
- SAP, „Roles and Responsibilities - SAP S/4HANA Cloud, private edition and SAP ERP, tailored option”, lipiec 2026 - [macierz odpowiedzialności SAP](https://www.sap.com/belgique/docs/download/agreements/product-policy/hec/roles-responsibilities/sap-s4hana-cloud-private-edition-and-sap-erp-tailored-option-roles-and-responsibilities-english-v7-2026.pdf) (dostęp 02.11.2026)
- SecurityBridge, „Securing RISE with SAP” - [strona producenta](https://securitybridge.com/solutions/securing-rise-with-sap/) (dostęp 02.11.2026)
