SoD växer ur klassisk SAP. Så här byggde vi för det.

Hur åtkomst faktiskt fungerar i SAP BTP

I klassisk SAP kommer en persons rättigheter från roller som buntar ihop transaktioner och behörighetsobjekt. I SAP BTP är byggstenarna annorlunda - och att förstå dem är hela spelet. Behörigheter i ett BTP-subkonto hanteras av XSUAA, och de bildar en kedja:

En användare tilldelas en eller flera rollsamlingar - den enhet som en administratör faktiskt delar ut, löst jämförbar med en composite role. En rollsamling innehåller roller (instanser av rollmallar som lever inuti en applikation). Varje roll beviljar en uppsättning scopes - och det är i scope:et den verkliga rättigheten sitter.

Ett scope är en sträng av formen xsappname.object.path.verb. Det är inte en transaktion - det är ett verb på en resurssökväg, publicerat av en applikations API. Till exempel bryts aicore!b164.scenarios.batches.write ned som:

Åtkomstenheten i BTP är alltså en behörighet på API-nivå - "får skriva batches i den här appen" - inte "får köra transaktion X". Just den skillnaden är varför den traditionella linsen har svårt.

Varför tcode-/Fiori-objekt-modellen inte passar

I tjugo år har ansvarsuppdelning i SAP betytt transaktioner och behörighetsobjekt: en konflikt är ett par transaktioner som en person aldrig borde inneha samtidigt, och regelmotorerna byggdes helt kring den formen. En Fiori-app ändrar inte heller den underliggande modellen - den bryts fortfarande ned till kataloger, transaktionskoder och samma behörighetsobjekt.

BTP har inga av dessa fästpunkter. Det finns ingen transaktionskod, inget S_TCODE, inget dynpro-behörighetsobjekt att matcha mot. Enheten är ett scope - en app-nativ sträng som beskriver ett verb på en resurs. En transaktionsbunden motor har bokstavligen inget att gripa tag i: hela dess vokabulär (transaktion, behörighetsobjekt, aktivitet) existerar inte på den här ytan.

Så det klassiska angreppssättet har två alternativ - ignorera BTP helt, eller tvinga in varje scope i en transaktionsform det aldrig hade. Vilket leder oss till kringgåendet.

När man måste förkläda ett scope som en transaktion

Det vanliga sättet att få in BTP i en transaktionsbunden motor är att få scope:et att se ut som en transaktion. Utmärkt ingenjörskonst har publicerats som gör just detta: en anpassad adapter mappar XSUAA-användare, rollsamlingar, roller och scopes in i motorns strukturer, och - eftersom motorns aktivitetsnivåanalys bara känner igen en hårdkodad vitlista av resurstyper (SAP-transaktioner, tjänster) - släpper den ut en andra skuggrad som klär upp varje scope som en transaktion så att analysen överhuvudtaget kan se det.

Det fungerar, och det är smart. Men skuggraden är tecknet: motorn designades aldrig för att resonera om något som inte är en SAP-transaktion, så varje ny åtkomstmodell måste översättas tillbaka till en sådan.

En behörighetsmodell-agnostisk SoD-motor

smartGRC utgår från ett annat antagande. Dess riskmotor är inte kopplad till SAP-transaktionskoder - den resonerar om behörigheter generiskt: ett objekt och en aktivitet, oavsett från vilket system de kom. Det enda designvalet gör resten rent:

Ett BTP-scope mappas till en nativ behörighet, inte en utklädd transaktion. En SAP-transaktion är en typ av behörighet; ett XSUAA-scope är en annan; en icke-SAP-behörighet är en tredje. De sitter sida vid sida i samma analys - så en ansvarsuppdelningskonflikt kan spänna över BTP × SAP × icke-SAP i en enda regel. Den hybridkonflikten - till exempel någon som kan administrera BTP-applikationen som matar en process och godkänna resultatet i S/4HANA - är exakt den sort som en beståndstäckande SoD-bild behöver, och exakt den sort som en enbart transaktionsbaserad motor har svårt att uttrycka.

Inga shadow-rows. Ingen vitlista att uppfylla. Scope:et är förstaklassigt eftersom motorn är byggd för att vara det.

Två verktyg, två former av problemet

För att vara rättvis mot Access Control: detta är inte AC utfört fel, det är AC ombedd att göra något utanför sin form. SAP GRC AC är en fullständig styrningssvit - begäran, godkännande, provisionering, analys och revision - djupt kopplad till klassisk SAP. För den klassiska SAP-livscykeln från begäran till revision är den mogen och svår att slå, och den bredden är verklig.

smartGRC är avsiktligt smalare och byggt annorlunda: en fokuserad, modellagnostisk SoD-motor. Där de två överlappar - analys av åtkomst för ansvarsuppdelning över ett modernt, hybridt, allt mer icke-SAP-bestånd - drar designvalen isär:

Den ärliga slutsatsen: om jobbet är den heltäckande SAP-livscykeln från begäran till revision på klassisk SAP, är AC en tungviktare av en anledning. Om jobbet är ansvarsuppdelning över ett hybridt bestånd - utfört lätt, utan att förkläda varje ny yta som en transaktion - är smartGRC byggt för den formen.

GET /Users?filter=userName eq "..." and origin eq "..."   (SCIM)   -> user + groups[]
GET /Groups?attributes=id,displayName                     (SCIM)   -> rollsamlingar
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

Tre problem - och bara det mellersta är vallgraven

Allt ovan får det att låta som en kopplingshistoria. Det är det inte. Att få in BTP i ansvarsuppdelning delas upp i tre problem, och de är inte likvärdiga: två är ingenjörskonst, ett är omdöme. Det mellersta är där fördelen faktiskt bor.

Kopplingen är grundinsats och rapporteringen är redan vår. Det knappa är att veta vilka BTP-behörighetskombinationer som är värda att flagga i första hand - en regeluppsättning som återspeglar hur BTP faktiskt beviljar makt, inte en översättning av en SAP-motsvarighet. Det är innehåll, inte kod, och det är den del som måste förtjänas snarare än levereras.

Så vad ser "toxiskt på BTP" faktiskt ut som? Tre illustrativa konflikter som en BTP-medveten regeluppsättning skulle bära - typer värda att definiera, inte ett levererat regelpaket. Ingen av dem finns i en transaktionsbaserad regeluppsättning, eftersom ingen av dem är en transaktion.

Det är dessa konflikter som avgör om BTP SoD är verklig eller teater. Att skriva dem bra kräver någon som vet hur BTP beviljar makt - vilket är exakt varför regeluppsättningen, inte kopplingen, är där värdet koncentreras.

Samma modell täcker tjänste- och AI-identiteter

XSUAA utfärdar inte bara tokens till människor. Client-credentials-bindningar autentiserar applikation-till-applikation - tjänstekontona och AI-agenterna som anropar BTP-API:er. Eftersom smartGRC behandlar icke-mänskliga identiteter på samma sätt som den behandlar användare - SoD-analys, flaggning av känslig åtkomst och kontinuerlig övervakning på kontona, inte bara på människorna - är BTP-scopes och AI-/tjänsteidentiteter samma frontlinje, hanterade av samma modell. SAP Audit Log ger aktivitetsspåret för att sluta cirkeln.

Det är en motor som behandlar en SAP-transaktion, ett BTP-scope och en icke-SAP-behörighet som det de är - förstaklassiga, sida vid sida, i en hybrid analys. Det är vadslagningen smartGRC är byggt på.

Relaterad läsning