Måste det vara smärtsamt att omorganisera SoD-konflikter och SAP-rättigheter?

På konferensen SAP Security - tips för säkerhet delade jag med mig av de kunskaper jag fått från både SoD- och entitlement-omstruktureringsprojekt och det dagliga arbetet inom Managed Services. För er som inte hade möjlighet att närvara på konferensen har jag gjort en kort sammanfattning.

I början frågade vi oss själva vad som skulle kunna vara anledningen till att vi bestämde oss för att ge oss in i ett sådant projekt som omorganisering av rättigheter. Exempel på scenarier inkluderar:

 

1. 1. Bolaget har upplevt dataläckage eller bedrägeri till följd av alltför omfattande användarrättigheter.
      Vi fick reda på händelsen av en slump. Hur många incidenter fick vi inte reda på
   2. Det har uppstått ett fel i produktionssystemet - oavsiktligt mänskligt fel. Var behörigheterna för breda? Vet vi hur vi kan återskapa felet? Lagrar systemet loggar och vet vi hur vi ska läsa dem?
   3. SAP-roller som rör till det, förlorad känsla av kontroll över roller. Lägg till nya behörigheter till roller, ta inte bort behörigheter. Resultat: alla har tillgång till (nästan) allt.

1.  

1.  

SoD-koncept

Vi blev också påminda om grundläggande SoD-koncept - från det allmänna till det specifika:

Deadline	Definition
SoD-matris	en uppsättning definierade och beskrivna auktoritetskonflikter inom ett visst område (t.ex. FI, TR, SD, HR, Basis)
SoD-konflikt	kritisk kombination av minst två affärsprocesser (t.ex. löneutbetalning + byte av bankkonto, öppnande av redovisningsperioder + frisläppande av dokument för betalning, systemkonfiguration + transportimport)
Risker	beskrivning av SoD-konflikten ur affärssynpunkt och de möjliga konsekvenserna av de befogenheter som tilldelats
Process	affärsverksamhet (t.ex. öppnande av en redovisningsperiod, frisläppande av dokument för betalning)
Behörighets-ID	definierade transaktioner, rapporter, tabeller, dvs. värdena för SAP-fält som kontrolleras av motorn i den matris som definierats och konfigurerats i SAP-systemet. Allt som vi vill fånga upp som „kritiskt” i behörigheterna för kontrollerade användare
Begränsningar	kontroll av risker för vilka tillträdet bör dras in/upprätthållas för specifika användare; kontrollerna kan vara manuella, kompensatoriska, automatiska, enligt „fyra ögon-principen”
SOD Åtskillnad av arbetsuppgifter	dvs. varje anställd utför bara sin del av processen och ingen har rätt att agera utöver sina arbetsuppgifter!

PRU-planering

Vid planering av en PRU bör åtminstone följande fem faser planeras:

 

1. 1. Analys aktuella SoD-konflikter, behörighetsproblem, status för roller, status för förfaranden
   2. Planering arbetsuppgifter och ansvarsområden i PRU, det nya konceptet för rättigheter
   3. Konfiguration nya roller, Brandman
   4. Tester/Pilot
   5. Produktionsstart - Hyper care, dokumentationen har sina ägare, begränsningsåtgärder

1.  

1.  

1.  

1.  

En mängd utmaningar och fallgropar väntar under projektets gång, till exempel när vi analyserar kritiska åtkomster i SAP-systemet och upptäcker vem som har en tilldelad SAP_ALL-profil....

Det kanske inte är så lätt för enskilda personer att vilja avstå från en så bred och bekväm tillgång. Argumentet: „Jag är en nyckelanvändare och behöver bred åtkomst i nödfall i händelse av en nödsituation i systemet”.
En annan överraskning gäller en annan viktig aspekt i projektet. Projektet för omorganisering av auktorisering och SoD är i allra högsta grad ett tvärvetenskapligt projekt. För att skapa ett perfekt projektteam måste vi involvera och fördela uppgifter mellan både affärsanvändare och tekniska användare (auktoriseringsteam, modulkonsulter, utvecklare, Basis). Tyvärr är det ofta så att när ett projekt har „auktorisation” i sitt namn är projektägaren ofta placerad i IT-teamen:

Exempel på kombination av SAP-standardverktyg med SAST Suite-verktyg

När ämnesägare och uppgifter har definierats för varje fas i projektet är det viktigt att överväga lämpliga verktyg som kan vara användbara i ett projekt för bemyndigande och omorganisation av SoD. Det är värt att titta på de verktyg som finns tillgängliga i SAP och på marknaden som minska tidskrävande och automatisera arbetet projektgrupp. Nedan ger jag exempel på hur SAP:s standardverktyg kan kombineras med SAST Suite-verktyg.

1. SoD:s konfliktmatris - eller vår behörighetsmotor. Låt oss börja med att samla in och dokumentera de kritiska processerna i organisationen.
   SAP-standardKonfiguration av „kritiska kombinationer” och „kritiska behörigheter” i SUIM. Verifiering endast på åtkomstnivå för T-kod (transaktion).
   SAST-sviten: Färdigt SOD-konfliktbibliotek (mer än 300 definierade konflikter) per SAP-modul. Verifiering på nivån för Tcode-åtkomst + rättighetsobjekt + värde på rättighetsobjektets fält
2. SAP-rollhantering - under ett projekt för omorganisation av rättigheter skapar vi ofta nya roller eller ändrar befintliga roller.
   SAP-standard: skapa och ändra roller efter behov och definierade (om några) positioner - PFCG
   SAST-sviten: färdiga rollmallar (laddas upp till systemet via standard SAP-transport) - uppdelade i affärsroller, tekniska roller, SAP-moduler och arbetsroller
   Resultat: Standardiserad konvention för rollnamn + Omfattande rollbeskrivning.
3. SAP rollhantering - miniprojekt för utrullning förekommer i snabbt växande företag. Nya behörigheter för nya organisationsnivåer måste då organiseras.
   SAP-standard: Referensroller måste skapas, på grundval av vilka härledda roller med nya organisationsnivåer skapas - kopiera roller + manuell ändring i PFCG.
   SAST Suite: Definition av referensroller + skapande av orgset med värden för nya organisationsnivåer + automatiskt skapande av härledda roller.
   Automatiskt skapande av roller med nya organisationsnivåer:
   Resultat: efter att ha definierat värdena i orgset, automatiskt skapande av en roll med namnet: YFI_C_AC00:AA-DAILY med de organisatoriska nivåerna slutförda.
4. Spåra - vi använder den här funktionen för att spåra en användares åtgärder i systemet mot de behörigheter som används.
   SAP-standard: ST01 eller SM20 (säkerhetsgranskningslogg), SU53, STUSOBTRACE
   SAST Suite: Möjlighet att börja spåra alla användare från en enda instrumentpanel + fullständiga uppgifter om utförda aktiviteter + skapande av en roll från ett spår.
   Användarspårning + skapande av en roll med använda behörigheter + visning av saknade behörigheter
   Resultat: skapande av en roll från ett spår på en vald användare.

Sammanfattning

Låt oss inte glömma de återstående utmaningarna i projektet för omorganisation av rätten till förmåner:

• Rättighetsbegreppet - underhåll - detta dokument är en „levande organism”
• Processer för behörighets- och användarhantering
• Identifiering av områdesägare och roller
• Cykliska kontroller av SoD och rättigheter - minst en gång om året
• Upprätthålla kontinuiteten i det nya behörighetssystemet och SoD

Välkommen att kontakta oss

Om du är särskilt intresserad av någon av de frågor som diskuteras är du välkommen att kontakta mig.