Varför genomföra en behörighetsrevision? Den här nyckelfrågan förlorar aldrig sin relevans: vem har tillgång till vilka data i SAP?
SAP entitlement reviews hjälper till att besvara en viktig fråga: i vilken utsträckning återspeglar de roller och transaktioner som tilldelats en användare i systemet dennes faktiska ansvarsområden? Det är ingen lätt uppgift, eftersom det i praktiken ofta är svårt att avgöra exakt vad en anställd verkligen ansvarar för, särskilt som deras roller och ansvarsområden förändras över tid.
För att förenkla processen med att distribuera nya medarbetare kopierar organisationer ofta behörigheter från en annan användare. Även om detta förfarande påskyndar beviljandet av åtkomst leder det också till att man förlorar kontrollen över vem som har åtkomst till vad, särskilt när behörighetsstrukturen i systemet är komplex och användarna får dussintals eller till och med hundratals roller samtidigt. Med tiden blir åtkomststrukturen oläslig och svår att hantera. Vid denna tidpunkt uppstår behovet av en behörighetsgranskning, vars syfte är att verifiera ofta felaktigt tilldelade behörigheter.
Det är då revisorerna kommer in i bilden.
Bristande åtkomstkontroll uppdagas oftast i den dagliga verksamheten – till exempel när en anställd upptäcks ha skickat ett dokument till ett företag som han eller hon inte formellt är knuten till, eller flyttat varor mellan olika platser utan korrekt tillstånd. Även om sådana incidenter vanligtvis snabbt korrigeras blir de sällan drivkraften för en djupare förändring. Det finns en utbredd uppfattning om att det är bättre att ha ”för mycket än för lite” befogenheter, och behovet av att ge stöd väger ofta tyngre än principen om att minimera åtkomsten.
Finansiella revisorer ser dock frågan på ett annat sätt – genom principen om minimiprivilegier, enligt vilken användare endast ska ha tillgång till funktioner som är nödvändiga för att utföra sitt arbete.
Ur ett finansiellt revisionsperspektiv är målet att bekräfta att de uppgifter som genereras i affärssystemet (t.ex. SAP) är tillförlitliga och att obehöriga personer inte har fått tillgång till funktioner som påverkar det finansiella resultatet. Revisorerna bedömer efterlevnaden av principen om åtskillnad av arbetsuppgifter (SoD) och kontrollerar tillgången till känsliga funktioner som betalningshantering, redigering av leverantörers bankuppgifter eller ändring av kund- och leverantörsmasterdata. En väl förberedd SoD-matris och en lista över kritisk åtkomst ger organisationen en praktisk utgångspunkt för granskning och ett ramverk för att bedöma aktuella roller och behörigheter.
En väl förberedd SoD-matris och lista över kritisk åtkomst ger en organisation en praktisk utgångspunkt för granskning och ett ramverk för att bedöma aktuella roller och behörigheter. I stället för att ställa frågan om vilken åtkomst en användare bör ha (vilket kräver en analys av ansvar, uppgifter och erfarenhet) är det mycket enklare och snabbare att fastställa vilken åtkomst de inte bör ha – särskilt när en revisor tillhandahåller en färdig lista över risker och känsliga aktiviteter, eller när en sådan lista med bästa praxis redan finns tillgänglig i ett verktyg för hantering av åtkomstrisker (GRC-klass).
1. Granskning av rättigheter ger också konkreta affärsmässiga fördelar:
- Bättre förståelse för processer och ansvarsområden – bidrar till att klargöra vem som ansvarar för vad och var det kan finnas ”gråzoner” i beslutsfattandet.
- Förbättrad driftsäkerhet – att begränsa obehörig åtkomst är en av de enklaste och mest effektiva formerna av förebyggande åtgärder.
- Förbereda för förändring – välorganiserade behörigheter gör migreringar, uppgraderingar och övergången till molnmiljöer mycket enklare.
- Minskad risk för fel och missbruk genom att rollkonflikter och kombinationer av kritisk tillgång elimineras.
- Stöd för interna och externa revisioner – transparenta rapporter och en tydlig riskmatris påskyndar revisionsprocesserna avsevärt.
Det är viktigt att notera att de flesta organisationer inte har tid att fundera över behörighetsmodellen när de implementerar ett affärssystem. Testning, masterdata, schemaläggning och att få systemet att fungera är oftast det som är viktigast. Åtkomsträttigheterna fastställs ofta i sista minuten – vanligtvis genom att kopiera användare eller roller – utan att de verkliga behoven och riskerna analyseras. Resultatet kan bli att systemet fungerar bra ur processynpunkt, men lämnar alltför många luckor i säkerhet och kontroll.
Det är därför värt att genomföra en granskning av behörigheter efter stabiliseringen som ett medvetet steg mot att strukturera åtkomsten och förbättra organisationens säkerhet och efterlevnad.
Hur man genomför en SAP Access Audit i praktiken.
Nu när vi förstår, varför accessrevision är viktig och vilka fördelar den ger, är den logiska frågan: hur genomför vi den i praktiken? Organisationer har flera alternativ – från att manuellt analysera SAP-tabeller till att använda olika verktyg för att stödja SoD-riskbedömning. Valet beror på flera faktorer, t.ex:
- antalet användare och IT-miljöns komplexitet (t.ex. om den huvudsakligen är SAP-baserad eller innehåller domänspecifika system), manuell revision av mer än 100 användare är nästan omöjlig att göra fullständigt och korrekt
- resurser och kompetens hos det interna teamet, tekniska specialister börjar med SUIM i SAP och delar resultat som är svåra för affärsteamen att förstå
- interna eller externa revisorers krav och förväntningar på SoD och åtkomstkontroll till känslig data,
- och om revisionen är en engångsgranskning eller en återkommande aktivitet.
Många organisationer börjar med att ladda ner SUIM-rapporter, exportera data från tabeller och analysera dem manuellt i Excel. Efter att ha tillbringat veckor med att stämma av rådata från systemet vänder de sig ofta till externa revisorer för att få vägledning – bara för att inse att deras tillvägagångssätt var fel från början. Revisionsfirmor, särskilt de fyra stora, erbjuder inte bara sofistikerade verktyg (som PwC:s ACE) utan även strukturerade metoder som fokuserar på risk, affärssammanhang och repeterbarhet. De stannar dock inte vid att identifiera risker. När en konflikt med åtskillnad av arbetsuppgifter har upptäckts gräver revisorerna djupare och frågar sig om åtkomst har använts, om risker har materialiserats och vilka data som har ändrats eller påverkats. Att bevisa att den breda tillgången till kritiska resurser inte har missbrukats kan vara en tids- och resurskrävande uppgift, särskilt om det inte finns något system för att spåra användningen eller någon kontextuell verifieringskedja. Därför ligger den verkliga styrkan inte bara i verktyget, utan i att kombinera rätt teknik med rätt metodik och utgå från riskerna och affärsbehoven snarare än råa transaktioner eller listor över transaktioner med kritisk åtkomst.
Många IT-proffs tror att implementeringen av ett GRC-verktyg automatiskt kommer att lösa deras problem med åtkomsthantering. Detta är dock en klassisk fälla: om problemet inte är tydligt definierat kommer verktyget inte att lösa det. Den verkliga frågan är ofta inte ”Saknar vi ett GRC-verktyg?”, utan snarare: ”Förstår vi verkligen vem som har tillgång till vad och varför?”. Utan denna tydlighet kommer inte ens den bästa lösningen att ge några meningsfulla resultat. En välkänd lösning inom detta område är SAP GRC Access Control 12.0 (för lokala miljöer). SAP erbjuder också en molnbaserad version – SAP IAG – som stöder både lokala (via SAP Connector) och molnbaserade system (t.ex. SuccessFactors).
GRC Hack #2
En lokal implementering av SAP GRC Access Control tar vanligtvis mellan tre och sex månader. Om tiden är avgörande kan en molnbaserad version av IAG ge en snabbare implementering – eller så kan alternativa SaaS-lösningar övervägas.
Faktum är att alternativa lösningar för passerkontroll blir alltmer populära – särskilt de som fokuserar på flexibilitet, integration med icke-SAP-system, snabbare driftsättning och förenklat underhåll. Ett exempel på detta är smartGRC som finns i både lokala modeller och molnmodeller, och som kan leverera de första resultaten på så lite som 1 månad.
Är en revisionstjänst av engångskaraktär ett alternativ till GRC-systemet?
Ledningen ställer ofta frågan:”Behöver jag verkligen ett komplett GRC-system för att förstå vem som har tillgång till vad?”
Det finns två huvudsakliga tillvägagångssätt:
- Engångsrevision av ett externt företag – snabbt, kostnadseffektivt och användbart för att få en aktuell bild (t.ex. inför en finansiell översyn).
- Implementering av ett GRC-system – den perfekta lösningen för organisationer som kräver kontinuerlig kontroll, oberoende och skalbarhet.
GRC Hack #3
En engångsrevision är bara en ögonblicksbild. I dynamiska SAP-miljöer förändras åtkomstriskerna ständigt. Utan kontinuerlig övervakning blir det nödvändigt med upprepade revisioner.
Om det inte är nödvändigt med frekventa revisioner kan outsourcing fortfarande vara det bästa alternativet. Men för organisationer som vill ha flexibiliteten hos lean GRC-lösningar är de en kostnadseffektiv kompromiss – särskilt när revisionen även omfattar icke-SAP-system, som vanligtvis kräver mer tid för att förbereda och granska åtskillnaden av arbetsuppgifter.
Handlingsplan – genomföra en revision av SAP-rättigheter – var ska man börja?
Att börja en SAP-rättighetsrevision med att identifiera transaktionskoder (t-koder) är ett vanligt misstag, särskilt bland tekniska team. Med detta tillvägagångssätt missar man ett viktigt första steg: att förstå de affärsprocesser, roller och risker som avgör åtkomstkraven. Utan detta sammanhang är en analys av t-koder ungefär som att kartlägga en stad enbart utifrån lyktstolpar – det är tekniskt korrekt men strategiskt blint.
GRC Hack #4
Börja inte med t-koder! Börja med affärsprocesser och riskområden – först därefter kan du koppla dem till transaktioner. Om man går direkt till tekniska frågor förlorar man den större bilden.
2. utveckling av en matris för arbetsfördelning (SoD) och en lista över känsliga åtkomster
Detta är grunden för all granskning av åtkomstkontroll. I det här skedet identifierar organisationen de affärsprocesser som är utsatta för potentiella överträdelser och identifierar konflikter i fråga om ansvarsfördelning (SoD) – t.ex. att bokföra en journalpost och godkänna en betalning. Projektgruppen identifierar tillsammans med affärsområdesägarna en lista över så kallade affärsaktiviteter som kan förekomma inom samma process. Varje risk tilldelas en viktighetsnivå – t.ex. låg, medel, hög. Alla GRC-verktyg erbjuder denna funktionalitet, men det är värt att notera några nyanser.
GRC Hack #5
Den största utmaningen med att skapa en SoD-matris är att säkerställa en gemensam förståelse för riskdefinitionen inom hela företaget. Utan detta har diskussionen inget verkligt värde. Det finns redan lösningar på marknaden, t.ex. smartGRC, som möjliggör integration av artificiell intelligens och stödjer användarna genom att föreslå riskfyllda kombinationer av åtgärder, visa exempel på hur risker materialiseras och peka på specifika SAP-transaktioner eller Fiori-applikationer. Detta minskar workshoptiden och förbättrar matrisens kvalitet.
2. Teknisk kartläggning av SoD-matrisen
När SoD-riskmatrisen och listan över känsliga behörigheter har färdigställts och godkänts av verksamheten är nästa steg att tekniskt mappa dem i GRC-systemet. Detta är den punkt där risker på processnivå översätts till faktiska rättigheter i IT-system – oftast i SAP.
I detta skede tilldelas varje affärsaktivitet en specifik uppsättning SAP-transaktioner, Fiori-applikationer eller andra tekniska element (t.ex. program, rapporter, funktioner). Relationer upprättas sedan mellan transaktioner och auktoriseringsobjekt – element i SAP-systemet som styr omfattningen av användaråtkomst.
För varje par av affärsaktiviteter definieras konfliktvillkor – t.ex. om en användare har tillgång till att både skapa och godkänna ett dokument. Resultatet är en komplett uppsättning regler som innehåller mappade tekniska definitioner av aktiviteter och konfliktregler.
GRC Hack #6
I det här skedet är det bra att använda ett verktyg som gör att du enkelt kan kartlägga system utöver SAP S/4HANA. SmartGRC (smartgrc.eu) gör det till exempel möjligt att skapa tekniska definitioner i XML-format med hjälp av en sammansatt och atomär struktur, vilket gör att alla auktoriseringskoncept kan modelleras. Systemet kontrollerar automatiskt att importen är korrekt och flaggar för problem som att det saknas atomer i sammansatta roller eller att atomer tilldelas användare som inte finns. Detta påskyndar inte bara implementeringen, utan bidrar också till att förbättra kvaliteten på behörighetskonceptet i källsystemet.
3. Rapportera om den ingående balansen.
Det är i detta skede som systemet analyserar de faktiska användarrättigheterna och identifierar var SoD-risker och känsliga åtkomster förekommer. I rapporterna tas hänsyn till organisatoriska nivåer, t.ex. om konflikten uppstår inom samma företagskod.
Beroende på vilket verktyg som används kan en rapport innehålla tusentals poster, så transparens, filtrering och aggregering av resultat är avgörande. Mer avancerade lösningar erbjuder också trendanalys över tid, vilket gör det möjligt för organisationer att bedöma om situationen förbättras eller försämras. Data presenteras vanligtvis i intuitiva instrumentpaneler.
GRC Hack #7
Det är värdefullt när rapporten visar den faktiska användningen av riskrelaterade Fiori-transaktioner och applikationer – detta hjälper till att avgöra om risken bara är teoretisk eller aktiv, vilket innebär att den används av användaren i den dagliga verksamheten.
GRC Hack #8
Det är ännu bättre om rapporten inte bara är en ”statisk lista”, utan en interaktiv uppgiftslista som gör det möjligt att till exempel tilldela objekt till affärsinnehavare, lägga till begränsande åtgärder eller vidarebefordra dem för godkännande eller borttagning av åtkomst.
4. Ta fram en återhämtningsplan.
Det här är det skede då konkreta beslut fattas baserat på rapporten. Säkerhetsteamet eller processägarna bestämmer:
- vilka rättigheter som bör dras in,
- vilka aktiviteter som bör blockeras eller omorganiseras
- och vilka ändringar som behöver göras i användarrollerna.
På grundval av detta skapas en teknisk specifikation för systemadministratörer – inklusive en lista över transaktioner, roller och användare som behöver uppdateras. Beroende på verktyget kan rekommendationer utarbetas i bulk eller kräva individuell analys.
GRC Hack #9
Det här är ett kritiskt skede i hela projektet – det är värt att avsätta tillräckligt med tid och resurser i förväg. Innan du återkallar åtkomsten för enskilda användare är det bättre att först förfina rollerna och den övergripande behörighetsmodellen – detta kommer att göra ändringarna mer permanenta, logiska och lättare att underhålla i framtiden.
5. Övervaka aktuella risker.
En tillträdesrevision slutar inte med en engångsanalys – riskerna bör övervakas kontinuerligt. När förändringar har genomförts är det viktigt att:
- regelbundet gå igenom nya rättigheter och rollförändringar,
- upptäcka nya konflikter och användaraktivitet i känsliga områden,
- och analysera trender – ökar, minskar eller förblir antalet risker konstant?
Mer avancerade verktyg möjliggör schemaläggning av återkommande analyser, automatisering av rapportering och automatiska meddelanden till processägare.
Detta är också det skede där implementeringen av ett GRC-verktyg ger störst avkastning på investeringen – det möjliggör kontinuerlig övervakning utan behov av upprepade manuella revisioner, vilket sparar tid och resurser.
GRC Hack #10
Det största värdet skapas genom kontinuerlig övervakning – i stället för att genomföra revisioner en gång om året är det mycket mer effektivt att övervaka riskerna kvartalsvis eller månadsvis. GRC-systemet gör det möjligt att schemalägga återkommande analyser och visualisera risker över tid, vilket hjälper till att bedöma om korrigerande åtgärder faktiskt fungerar.
SAP-rättighetsrevisionen är ett viktigt steg för att säkerställa efterlevnad, säkerhet och integritet för finansiella data. Oavsett om du är revisor, processägare eller IT-specialist får du en tydlig bild av organisationens behörighetsstruktur när du går igenom de fem viktigaste stegen i granskningen:
- Definition av SoD-matris och lista över känslig åtkomst
- Kartläggning av systemet (teknisk kartläggning)
- Upprättande av rapport över ingående balans
- Formulering av konkreta rekommendationer
- Övervakning av risker över tid
GRC-verktyg gör det möjligt för organisationer att genomföra revisioner snabbare, billigare och mer effektivt samtidigt som de upprätthåller höga standarder för kontroll och efterlevnad. Du behöver inte vara ”fast” med ett verktyg. Det finns alternativ att överväga – särskilt när tid, flexibilitet och budget är av avgörande betydelse.
Valet av GRC-metod och GRC-verktyg har en betydande inverkan på effektiviteten i varje steg. Komplexa lösningar (som SAP GRC Access Control), som ofta är svåra att underhålla, kan göra ett projekt överväldigande tekniskt komplicerat. Samtidigt fokuserar alternativa lösningar som SmartGRC på enkelhet, transparens och samarbete med affärsanvändare. Med funktioner som t.ex:
- Snabb implementering och användarvänligt gränssnitt
- Integration med OpenAI
- Hantering av icke-SAP-system via XML
- Aktiv rapportering och trendanalys
Sammanfattning.
GRC-verktyg kan inte bara hjälpa till med riskövervakning, utan även med arbetsflödet för att bevilja åtkomst och utforma roller – men deras effektivitet beror på det innehåll som de baseras på. Det är därför det är så viktigt att skapa en tydlig och välstrukturerad SoD-matris och riskdefinitioner från första början. Utan ett gediget innehåll kommer inte ens det bästa verktyget att ge de förväntade fördelarna.
