Wprowadzenie: Zbrodnia doskonała

To był zupełnie zwyczajny poniedziałek w systemie SAP GRC 12.0 (SP 23).
Użytkownik utworzył wniosek o dostęp, kliknął Wyślij i otrzymał standardowe potwierdzenie:

„Wniosek wysłany pomyślnie. Numer wniosku: 12345.”

Nic nie wyglądało podejrzanie. Użytkownik wrócił do swoich obowiązków.
Tymczasem skrzynka Akceptującego pozostała pusta. Wyszukiwanie wniosków zwracało komunikat „Nie znaleziono rekordów”.

Po sprawdzeniu tabel GRACREQ ostatni zapisany wniosek miał numer 12344.
Nowy numer, 12345, został pobrany z zakresu numeracji — ale nigdy nie został zapisany w bazie danych.

Wniosek nie zakończył się błędem.
On po prostu… wyparował.

To jeden z tych błędów, które potrafią zjeść pół dnia pracy zespołu GRC. Najgorsze było to, że system kłamał — spokojnie i z pełnym przekonaniem.

Analiza: Pewność interfejsu kontra rzeczywistość backendu

Na pierwszy rzut oka wyglądało to na błąd użytkownika.
Zrzuty ekranu szybko jednak pokazały, że interfejs za każdym razem potwierdzał sukces.

Dopiero analiza logów backendowych zaczęła odsłaniać prawdę.
W ST22 i SM21 pojawił się kluczowy komunikat:

„Brak autoryzacji RFC dla modułu funkcyjnego GRAC_AR_UPDATE_REQUEST.”

Brak popupu. Brak ostrzeżenia. Tylko cicha odmowa po stronie backendu.

Co tak naprawdę się działo

System niedawno przeszedł aktualizację kernela.
Ta zmiana wprowadziła bardziej restrykcyjne kontrole autoryzacji RFC wewnątrz procesu aplikacyjnego GRC.

Proces wyglądał następująco:

• Interfejs UI inicjował utworzenie wniosku.
• System generował nowy numer wniosku z zakresu numeracji.
• Podczas próby zapisu danych poprzez GRAC_AR_UPDATE_REQUEST kernel wykonywał kontrolę uprawnień RFC.
• Rola użytkownika nie posiadała wymaganego obiektu S_RFC.
• Zapis nie powiódł się, ale interfejs nie obsłużył wyjątku i nadal wyświetlił komunikat sukcesu, opierając się jedynie na samym wywołaniu procesu.

W efekcie numer został „zużyty”, dane nie zostały zapisane, a użytkownik nie dostał żadnej informacji.

Dlaczego nie wykryliśmy tego w testach (pułapka Firefightera)

Dlaczego problem nie wyszedł podczas UAT?

Administrator próbował go odtworzyć — i nie widział żadnego błędu. Wszystko działało poprawnie.
Powód okazał się banalny, choć bolesny.

Testował na ID Firefightera.

Role Firefighter zazwyczaj mają bardzo szerokie uprawnienia, często obejmujące obiekty RFC, których zwykli użytkownicy nie posiadają.
Te dodatkowe uprawnienia całkowicie zamaskowały brak autoryzacji.

Wniosek na przyszłość:
Nigdy nie testuj błędów użytkowników końcowych kontem z uprawnieniami administratora.
Jeśli chcesz realnych wyników, użyj użytkownika testowego z identyczną kopią roli biznesowej. SU53 zrobi resztę.

Rozwiązanie

To zachowanie jest opisane w SAP Note 3694152.

Rozwiązanie było proste, gdy już znaliśmy przyczynę:
role użytkowników końcowych musiały zostać rozszerzone o jawne uprawnienie do modułu funkcyjnego GRAC_AR_UPDATE_REQUEST w obiekcie S_RFC.

Po przetransportowaniu zmian ról z DEV do QAS i PRD wnioski przestały znikać.
Interfejs i baza danych znów zaczęły mówić to samo.

Podsumowanie

Jeśli korzystasz z SAP GRC 12.0 i niedawno aktualizowałeś kernel, warto to sprawdzić.

Zajrzyj do ST22 zaraz po zgłoszeniach użytkowników o znikających wnioskach.
Testuj na użytkownikach z ograniczonymi uprawnieniami, a nie na Firefighterach.
I koniecznie przejrzyj SAP Note 3694152 — zwłaszcza jeśli system po aktualizacji stał się podejrzanie „cichy”.

Szczegóły zostały zanonimizowane. Case oparty na rzeczywistym problemie klienta.

Jeśli pracujesz z systemami GRC po aktualizacjach, takie sytuacje zdarzają się częściej, niż mogłoby się wydawać 🙂