Rola biznesowa zamiast PFCG, katalogi zamiast ról technicznych, a do tego dwa duże release’y rocznie, które potrafią przemeblować cały model uprawnień. Tak wygląda autoryzacja w SAP Public Cloud — i o niej rozmawiamy w nowym odcinku GRC Ninja.

W poprzednim odcinku pytaliśmy, czym jest SAP Public Cloud, dla kogo ma sens i jakie ma ograniczenia. Teraz schodzimy poziom niżej. Rafał, konsultant wspierający takie wdrożenia, pokazuje na żywym systemie, z czego składa się rola biznesowa, co widzi użytkownik w Launchpadzie i dlaczego model uprawnień trzeba przeglądać co pół roku. Poniżej najważniejsze wnioski z tej rozmowy.

Koniec z PFCG. W centrum stoi rola biznesowa

Public Cloud podchodzi do autoryzacji zupełnie inaczej niż systemy on-premise i private cloud. Klasyczne role techniczne budowane w PFCG zastąpiły role biznesowe. Każda z nich składa się z katalogów biznesowych, a te z aplikacji Fiori. Sposób ich prezentacji definiują Spaces and Pages, czyli przestrzenie i strony nawigacyjne w Launchpadzie. Na końcu dochodzą restrykcje, które ograniczają dostęp do danych wewnątrz samych aplikacji.

Brzmi logicznie? Na papierze tak. W praktyce ten model zaskakuje nawet doświadczonych konsultantów, bo rola to nie tylko dostęp, ale cały układ aplikacji w interfejsie. Masz nadane uprawnienia, ale bez przypisanych Spaces and Pages użytkownik loguje się i widzi pusty ekran. W on-premise coś takiego by nie przeszło. Tutaj to norma.

Z czego składa się rola w Maintain Business Roles?

Rolami zarządza się w aplikacji Maintain Business Roles — repozytorium, w którym role się tworzy i modyfikuje. Każda rola ma kilka elementów:

• Dane podstawowe — opis roli i kategorie dostępu, czyli informacja, czy rola pozwala edytować dane, czy tylko je wyświetlać. Tu widać też kategorię cenową roli.
• Business Catalogs — katalogi biznesowe, które dają użytkownikom dostęp do poszczególnych aplikacji. Każdy katalog można otworzyć i sprawdzić w szczegółach.
• IAM Apps — wszystkie aplikacje przypisane przez katalogi. Stąd da się też przyciąć dostęp do wybranych z nich.
• Launchpad Spaces — przestrzenie nawigacyjne, dzięki którym pracownik trafia do potrzebnych aplikacji.
• Restrykcje — filtry danych w samych aplikacjach, na przykład na poziomie jednostki gospodarczej, zakładu albo grupy autoryzacji.

Całość jest bardzo wizualna. I właśnie dlatego wymaga dyscypliny przy projektowaniu: każdy element tej układanki musi znaleźć się na swoim miejscu, inaczej komuś zniknie kawałek ekranu.

Dwa release’y rocznie. Kto decyduje o zmianach?

Środowisko on-premise działało latami, dopóki sami nie zdecydowaliście się na upgrade. W Public Cloud tę decyzję podejmuje SAP: centralnie, dwa razy w roku. Major release wprowadza zmiany funkcjonalne, nowe aplikacje Fiori, czasem także korekty w katalogach czy restrykcjach. A to bezpośrednio uderza w uprawnienia.

Weźmy rolę księgowego. Po nowym release’ie SAP może dodać aplikacje do katalogu Accounts Payable, zmienić nazwę lub kategorię istniejącej aplikacji, usunąć część wcześniej dostępnych funkcji albo wprowadzić nowe pole w restrykcjach. Księgowy nagle widzi nowy kafelek i może wykonać operację, do której wcześniej nie miał prawa. Albo odwrotnie: traci dostęp do raportu, na którym pracował od miesięcy.

To nie są teoretyczne scenariusze. W jednym z projektów SAP zmienił podejście do wymaganych wartości w restrykcjach, a nikt tego na czas nie skorygował. Raporty finansowe wyglądały na sprawne, tylko pokazywały część danych. W innym release usunął katalog biznesowy, a administrator nie przypiął jego następcy.

Da się to kontrolować? Tak — narzędzia są. Funkcja Manage Changes After Upgrade w Maintain Business Roles listuje zmiany, które wpływają na daną rolę, choćby katalogi wycofane i zastąpione nowymi. What’s New Viewer opisuje zmiany językiem biznesowym, często z informacją o wpływie na uprawnienia i wytycznymi korekty ról. Każdy release ma również notę, która zbiera wszystkie modyfikacje autoryzacyjne: w rolach, katalogach, restrykcjach i powiązanych obiektach. Problem? Mało kto to analizuje.

Cztery błędy, które wracają w projektach

1. Za szerokie role

Klasyka. Na etapie testów użytkownicy dostają szeroki dostęp, „żeby działało”, a potem tak już zostaje. Efekt: dostęp do funkcji, których nikt nie potrzebuje, więcej okazji do pomyłek i wyższe koszty licencji, bo niektóre aplikacje podbijają kategorię cenową użytkownika. W skrajnym przypadku audyt wykrywa konflikty segregation of duties, których nikt wcześniej nie zauważył — i nagle na stole ląduje temat nadużyć.

2. Brak Spaces and Pages

Użytkownicy logują się, widzą pusty ekran i zgłaszają, że system nie działa. Role formalnie są przypisane, więc zespół IT analizuje logi i szuka błędu technicznego. A to po prostu brak przypisanego menu. Rafał widział projekty, w których testy startowały przez to z tygodniowym opóźnieniem.

3. Brak przeglądu restrykcji po release’ach

Cicha bomba z opóźnionym zapłonem. Po aktualizacji SAP potrafi zmienić restrykcje albo dodać nowe pola i część danych znika z raportów. Użytkownik nie widzi dokumentów z innej jednostki gospodarczej, bo pole company code dostało nową wartość. Czasem wychodzi to dopiero po tygodniu, gdy ktoś zauważa, że w zestawieniach brakuje faktur. Release’ów w chmurze nie można pominąć, więc przegląd ról po każdej aktualizacji musi być stałym procesem, a nie akcją ratunkową.

4. Brak kontroli SoD

Konflikty uprawnień w on-premise monitorowały systemy klasy GRC. W Public Cloud często się o tym zapomina: skoro system jest standardowy, ryzyka wydają się mniejsze. Nieprawda. Nadal możesz mieć użytkownika, który tworzy dostawców i zatwierdza płatności — tyle że bez zaktualizowanej bazy reguł dla aplikacji Fiori żadne narzędzie tego nie pokaże. Audytorzy mają wtedy używanie: wszystko działa, tylko nikt nie ma dowodu, że działa zgodnie z zasadami.

Utrzymanie uprawnień to proces, nie projekt

Każdy z tych błędów niesie realne konsekwencje: od frustracji użytkowników, przez błędy w danych, aż po ryzyka audytowe i finansowe. W chmurze nie działa już zasada „raz zbuduj i zapomnij”. Dział autoryzacji pracuje trochę jak zespół bezpieczeństwa — śledzi release’y i reaguje na to, co się w nich pojawia. Co pół roku SAP rozdaje karty na nowo. Wygrywają organizacje, które ustaliły standard na początku projektu i konsekwentnie go pilnują.

Zobacz, jak to wygląda w systemie

Ten materiał powstał na podstawie odcinka kanału GRC Ninja o modelu uprawnień w SAP Public Cloud. W wideo zobaczysz pełne demo: jak wygląda rola biznesowa w aplikacji Maintain Business Roles, jak działa Manage Changes After Upgrade i co sprawdzić przed każdym release’em, zanim zrobi to za Ciebie audytor. Całość trwa niecałe 11 minut — w sam raz na jedną kawę. Obejrzyj odcinek na kanale GRC Ninja i podziel się w komentarzu własną listą błędów. Może masz na niej coś, czego my nie wymieniliśmy?