SoD wyrasta z klasycznego SAP. Oto co zbudowaliśmy z myślą o tym.

Jak faktycznie działa dostęp w SAP BTP

W klasycznym SAP prawa osoby wynikają z ról, które grupują transakcje i obiekty autoryzacji. W SAP BTP klocki budulcowe są inne - i zrozumienie ich to cała gra. Autoryzacje w subaccount BTP zarządzane są przez XSUAA i tworzą łańcuch:

Użytkownik ma przypisaną jedną lub więcej kolekcji ról - jednostkę, którą faktycznie rozdaje administrator, luźno porównywalną do roli złożonej. Kolekcja ról zawiera role (instancje szablonów ról, które żyją wewnątrz aplikacji). Każda rola przyznaje zestaw zakresów - a zakres to miejsce, w którym naprawdę siedzi uprawnienie.

Zakres to ciąg w formacie xsappname.object.path.verb. To nie jest transakcja - to czasownik na ścieżce zasobu, publikowany przez API aplikacji. Na przykład aicore!b164.scenarios.batches.write rozkłada się na:

Zatem jednostką dostępu w BTP jest uprawnienie na poziomie API - „może zapisywać batche w tej aplikacji" - a nie „może uruchomić transakcję X". Ta jedna różnica jest powodem, dla którego tradycyjna optyka nie daje sobie rady.

Dlaczego model transakcji / obiektów Fiori nie pasuje

Przez dwadzieścia lat Segregacja obowiązków w SAP oznaczała transakcje i obiekty autoryzacji: konflikt to para transakcji, których jedna osoba nigdy nie powinna mieć razem, a silniki reguł były zbudowane wyłącznie wokół tego kształtu. Aplikacja Fiori też nie zmienia leżącego u podstaw modelu - i tak ostatecznie sprowadza się do katalogów, kodów transakcji i tych samych obiektów autoryzacji.

BTP nie ma żadnej z tych kotwic. Nie ma kodu transakcji, nie ma S_TCODE, nie ma obiektu autoryzacji dynpro, na którym można by się dopasować. Jednostką jest zakres - natywny dla aplikacji ciąg opisujący czasownik na zasobie. Silnik związany z transakcjami dosłownie nie ma się czego chwycić: całe jego słownictwo (transakcja, obiekt autoryzacji, aktywność) nie istnieje na tej powierzchni.

Klasyczne podejście ma więc dwie opcje - zignorować BTP całkowicie albo wcisnąć każdy zakres w kształt transakcji, którym nigdy nie był. Co prowadzi nas do obejścia.

Gdy trzeba przebrać zakres za transakcję

Powszechny sposób wprowadzenia BTP do silnika opartego na transakcjach polega na sprawieniu, by zakres wyglądał jak transakcja. Opublikowano znakomite prace inżynierskie, które robią dokładnie to: niestandardowy adapter mapuje użytkowników XSUAA, kolekcje ról, role i zakresy do struktur silnika, a - ponieważ analiza silnika na poziomie akcji rozpoznaje tylko zakodowaną białą listę typów zasobów (transakcje SAP, usługi) - emituje drugi, wiersz-cień, który przebiera każdy zakres za transakcję, aby analiza mogła go w ogóle zobaczyć.

To działa i to jest sprytne. Ale wiersz-cień to sygnał: silnik nigdy nie był zaprojektowany do rozumowania o czymkolwiek, co nie jest transakcją SAP, więc każdy nowy model dostępu musi być tłumaczony z powrotem na transakcję.

Silnik SoD niezależny od modelu uprawnień

smartGRC startuje z innego założenia. Jego silnik ryzyka nie jest podpięty do kodów transakcji SAP - operuje na uprawnieniach ogólnie: obiekt i aktywność, niezależnie od systemu, z którego pochodzą. Ten jeden wybór projektowy sprawia, że reszta jest czysta:

Zakres BTP mapuje się do natywnego uprawnienia, a nie do przebranej transakcji. Transakcja SAP to jeden rodzaj uprawnienia; zakres XSUAA to inny; uprawnienie non-SAP to trzeci. Siedzą obok siebie w tej samej analizie - więc konflikt Segregacji obowiązków może rozciągać się na BTP × SAP × non-SAP w jednej regule. Ten konflikt hybrydowy - na przykład ktoś, kto może administrować aplikacją BTP zasilającą proces i zatwierdzać wynik w S/4HANA - jest dokładnie tym, czego potrzebuje obraz SoD obejmujący całe środowisko, i dokładnie tym, co silnik oparty tylko na transakcjach ma problem wyrazić.

Bez wierszy-cieni. Bez białej listy do spełnienia. Zakres jest first-class, ponieważ silnik został tak zbudowany.

Dwa narzędzia, dwa kształty problemu

Żeby być sprawiedliwym wobec Access Control: to nie jest AC zrobione źle, to AC poproszone o coś poza jego kształtem. SAP GRC AC to pełny pakiet governance - request, approve, provision, analyse i audit - głęboko wpięty w klasyczny SAP. Dla klasycznego cyklu request-to-audit w SAP jest dojrzały i trudny do pobicia, i ta szerokość jest realna.

smartGRC jest celowo węższy i zbudowany inaczej: skoncentrowany, niezależny od modelu silnik SoD. Tam, gdzie oba się nakładają - analiza dostępu pod kątem Segregacji obowiązków w nowoczesnym, hybrydowym, coraz bardziej non-SAP środowisku - wybory projektowe się rozjeżdżają:

Uczciwa linia: jeśli zadaniem jest pełny cykl request-to-audit na klasycznym SAP, AC to nieprzypadkowa waga ciężka. Jeśli zadaniem jest Segregacja obowiązków w hybrydowym środowisku - zrobiona lekko, bez przebierania każdej nowej powierzchni za transakcję - smartGRC jest zbudowany do tego kształtu.

GET /Users?filter=userName eq "..." and origin eq "..."   (SCIM)   -> user + groups[]
GET /Groups?attributes=id,displayName                     (SCIM)   -> kolekcje ról
GET /sap/rest/authorization/v2/rolecollections/<name>               -> role_references[]
GET /sap/rest/authorization/v2/apps/<app>/roletemplates/<t>/roles/<r> -> scopes[].name

aicore!b164.scenarios.batches.write
   object   = aicore!b164.scenarios.batches
   activity = write

Trzy problemy - i tylko środkowy jest moat-em

Wszystko powyższe sprawia, że brzmi to jak opowieść o konektorze. Nie jest. Wprowadzenie BTP do Segregacji obowiązków dzieli się na trzy problemy i nie są one równe: dwa to inżynieria, jeden to ocena. Środkowy jest tam, gdzie faktycznie żyje przewaga.

Konektor to standard, a raportowanie już jest nasze. Rzadkim zasobem jest wiedza, które kombinacje uprawnień BTP w ogóle warto flagować - zestaw reguł odzwierciedlający sposób, w jaki BTP faktycznie przyznaje władzę, a nie tłumaczenie zestawu SAP. To treść, nie kod, i to jest część, którą trzeba zapracować, a nie dostarczyć.

Jak więc wygląda „toksyczne na BTP" w praktyce? Trzy ilustracyjne konflikty, które nosiłby świadomy BTP zestaw reguł - typy warte zdefiniowania, a nie gotowy pakiet reguł. Żadnego z nich nie ma w zestawie reguł opartym na transakcjach, ponieważ żaden z nich nie jest transakcją.

To są konflikty, które decydują o tym, czy SoD dla BTP jest realne czy tylko teatrem. Napisanie ich dobrze wymaga kogoś, kto wie, jak BTP przyznaje władzę - i dlatego właśnie zestaw reguł, a nie konektor, jest miejscem, w którym koncentruje się wartość.

Ten sam model obejmuje tożsamości usług i AI

XSUAA nie wydaje tokenów tylko ludziom. Powiązania client-credentials uwierzytelniają aplikacja-do-aplikacji - konta serwisowe i agentów AI, którzy wywołują API BTP. Ponieważ smartGRC traktuje tożsamości nieludzkie tak samo jak użytkowników - analiza SoD, flagowanie dostępu wrażliwego i ciągły monitoring na kontach, a nie tylko na ludziach - zakresy BTP i tożsamości AI/usług są tą samą granicą, obsługiwaną przez ten sam model. SAP Audit Log dostarcza śladu aktywności, aby zamknąć pętlę.

To silnik, który traktuje transakcję SAP, zakres BTP i uprawnienie non-SAP jako to, czym są - first-class, obok siebie, w jednej analizie hybrydowej. To jest zakład, na którym zbudowany jest smartGRC.

Warto przeczytać