Hur gör man för att inte överdriva behörigheter? - Principen om minsta möjliga privilegium i SAP

I affärssystem som SAP är användarbehörigheter en kritisk faktor för både säkerhet och smidig affärsverksamhet. Ändå händer det förvånansvärt ofta att användare får mycket mer åtkomst än de egentligen behöver. Ibland "bara för säkerhets skull", ibland "för att det gick snabbare". Och ibland helt enkelt för att ingen brydde sig om att verifiera det. Det finns dock en princip som bör ligga till grund för alla policyer för hantering av behörigheter: principen om lägsta privilegium (LPP). Kort sagt - användarna ska bara beviljas den åtkomst som är absolut nödvändig för att de ska kunna utföra sina arbetsuppgifter. Inget mindre, men inte heller något mer. Problemets omfattning illustreras av en studie som genomfördes i 225 organisationer: så mycket som 85% av tilldelade behörigheter användes inte under de senaste 90 dagarna, och 1 av 3 användare hade tillgång till system som de inte alls hade loggat in på. Dessa siffror visar hur ofta överdriven åtkomst beviljas som standard eller glöms bort vid rollförändringar. Och varje sådan åtkomst innebär en potentiell risk: för dataläckage, bedrägeri, fel eller överträdelser av efterlevnaden.  

Varför är det så viktigt?

LPP är inte bara en bästa praxis. Det är en av grundpelarna för informationssäkerhet och regelefterlevnad. Att bevilja alltför breda behörigheter kan leda till:

• finansiellt bedrägeri och manipulering av data,
• oavsiktliga fel som leder till dataförlust eller processavbrott,
• brott mot åtskillnad av arbetsuppgifter (SoD),
• bristande efterlevnad av bestämmelser (t.ex. GDPR, SOX),
• svårare revisioner och en större attackyta för cyberbrottslingar.

 

Historier från verkliga livet: hur det ser ut i praktiken

Låt oss ta en titt på några exempel där principen om minsta möjliga privilegium inte tillämpades: Exempel 1: Redovisningsanställd med full tillgång till faktureringscykeln En anställd på ekonomiavdelningen hade tillgång till alla transaktioner inom faktureringscykeln: från registrering av inkommande fakturor (MIRO), via kontering av dokument (FB60), till betalningsgodkännanden (F110). Risk: Den anställde kan självständigt slutföra hela processen - från att skapa dokument till att verkställa betalningen. Denna åtkomstnivå bryter mot principen om åtskillnad av arbetsuppgifter och gör det betydligt svårare att avgöra vem som ansvarade för vilken del av processen. Lösning: Begränsa åtkomsten till endast en roll - t.ex. antingen MIRO eller FB60 - och tilldela betalningsgodkännande till en annan användare. Det är också värt att implementera ett arbetsflöde och tydligt definiera ägandet av varje steg i processen. Exempel 2: Inköpande medarbetare med tillgång till försäljningsvillkor En anställd på inköpsavdelningen hade inte bara tillgång till inköpsorder (ME21N, ME22N), utan även till villkor för försäljningspriser (VK11). Vad var problemet? De här uppgifterna behövdes inte för deras roll, och om de redigerades kunde det få strategiska konsekvenser. Risk: Obehörig ändring av prissättningspolicyn - antingen oavsiktligt eller avsiktligt. Lösning: Gör en tydlig åtskillnad mellan inköps- och säljroller och begränsa tillgången till data till relevanta organisationsenheter. Exempel 3: Medarbetare efter rollbyte Efter att ha flyttats från lagret till kontrollavdelningen behöll medarbetaren sina gamla behörigheter och fick nya. Resultatet? Samtidig åtkomst till lagerdokument och kostnadsrelaterade data. Risk: Överdriven tillgång till processer utanför nuvarande ansvarsområden; potentiella SoD-konflikter (Segregation of Duties). Lösning: Varje rollförändring bör leda till en fullständig granskning av åtkomsten - inte bara genom att lägga till nya roller utan också genom att ta bort roller som inte längre behövs. Dessa exempel visar hur lätt det är att bevilja överdriven åtkomst - ofta på grund av brådska, avsaknad av regelbundna granskningar eller slarviga rollkombinationer. Vart och ett av dessa fall belyser hur även till synes mindre förbiseenden kan leda till allvarliga risker som är lätta att eliminera genom att tillämpa LPP.  

Hur tillämpar man LPP i praktiken?

För att tillämpa principen om minsta möjliga privilegium krävs inte bara medvetenhet om potentiella risker utan också konkreta organisatoriska och tekniska åtgärder - som helst ska genomföras systematiskt och med långsiktig säkerhet i åtanke. Här är några förslag:

• Utforma affärsroller baserat på den faktiska omfattningen av ansvarsområden - utan onödiga transaktioner.
• Definiera organisatoriska fält och begränsa dataåtkomst (t.ex. till en viss företagskod eller ett visst lager).
• Använd strukturerade processer för godkännande och granskning - särskilt vid förändringar av roller eller befattningar.
• Verifiera SoD-konflikter (Segregation of Duties) innan du beviljar åtkomst.
• Omcertifiera användaråtkomst regelbundet, t.ex. var 6:e eller 12:e månad.
• Utnyttja SAP-verktyg som GRC Access Control, SUIM, ST03N eller transaktionsloggar.

Om du verkligen vill effektivisera åtkomsthanteringen är det värt att investera i dedikerade lösningar som smartGRC (https://smartgrc.eu/). Dessa verktyg gör att du kan:

• genomföra periodiska granskningar av åtkomst,
• implementera arbetsflöden för processer för begäran om åtkomst och godkännande,
• hantera en SoD-riskdatabas, vilket avsevärt förbättrar kontrollen och höjer säkerheten i din SAP-miljö.

 

LPP och användarvänlighet

En vanlig myt är att begränsning av användaråtkomst gör arbetet mindre bekvämt. I själva verket är det precis tvärtom. Väl utformade roller - i linje med faktiska ansvarsområden och befriade från onödiga transaktioner - hjälper användarna:

• hitta de funktioner de behöver snabbare,
• undvika att bli överväldigad av onödiga gränssnittsalternativ,
• göra färre misstag som beror på att man klickar på "fel sak".

Least Privilege-principen förbättrar inte bara SAP-systemets säkerhet utan även dess användbarhet. Det skapar ett renare och mer intuitivt gränssnitt - vilket resulterar i en bättre upplevelse för slutanvändaren.  

LPP och säkerhetsstandarder och -bestämmelser

Det är också viktigt att komma ihåg att Least Privilege-principen inte bara är en god praxis - den är ett formellt krav i många internationella standarder och dataskyddsbestämmelser. Här är några exempel:

• ISO/IEC 27001 - kräver att åtkomst beviljas baserat på affärsbehov.
• NIST SP 800-53 - identifierar principen om minsta möjliga privilegium som en grundläggande kontroll för att skydda IT-system.
• RODO/GDPR - genomdrivs dataminimering, vilket innebär att tillgången till personuppgifter måste begränsas till dem som verkligen behöver dem.
• SOX (Sarbanes-Oxley Act) - föreskriver åtkomstkontroll för att säkerställa integriteten i den finansiella rapporteringen.

Att följa LPP minimerar inte bara operativa risker utan bidrar också till att upprätthålla efterlevnaden av tillämpliga lagar och standarder - vilket ofta är kritiskt vid revisioner och externa inspektioner.  

Vad vinner du på att tillämpa LPP?

Att implementera principen om minsta möjliga privilegier handlar inte bara om efterlevnad och säkerhet. Det ger också ett antal praktiska fördelar:

• Färre revisionsfrågor - tack vare bättre kontroll över åtkomsträttigheter.
• Snabbare och mer transparenta granskningar - välstrukturerade roller innebär färre undantag att förklara.
• Lägre kostnader för åtkomsthantering - färre roller att underhålla, färre förfrågningar om IT-support.
• Ökad transparens i ansvarsfördelningen - det är tydligt vem som ansvarar för vad.
• Färre användarfel - eftersom användarna bara har tillgång till det de verkligen behöver.
• Ett "renare" SAP-system - inga överdimensionerade roller eller föråldrade behörigheter som dröjer sig kvar i bakgrunden.

 

Sammanfattningsvis - sunt förnuft som standard

Least Privilege-principen handlar inte om överdriven försiktighet - det är ett professionellt förhållningssätt till SAP-säkerhet. Den skyddar inte bara data och processer utan även organisationens rykte. Det är därför det är värt att ta en stund och fråga sig: Är den här åtkomsten verkligen nödvändig? Om svaret är nej - då är det ett perfekt tillfälle att minska den. Referenser

1. Cloud Security Alliance. (2024). Mastering least privilege: Begränsa oanvänd åtkomst utan att ta genvägar. Hämtad från https://cloudsecurityalliance.org/blog/2024/05/30/mastering-least-privilege-cutting-unused-access
2. (n.d.). Vad är minsta privilegium? Hämtat från https://www.cyberark.com/what-is/least-privilege/
3. Edwards, M. (2025). Bilaga A.5.3: Åtskillnad av arbetsuppgifter. ISMS.online. Hämtad från https://www.isms.online/iso-27001/annex-a/5-3-segregation-of-duties-2022/
4. Nationella institutet för standarder och teknik (NIST). (u.å.). Lägsta privilegium. Hämtad från https://csrc.nist.gov/glossary/term/least_privilege
5. (2024). Säkra SAP med effektiv styrning av åtkomst. Hämtad från https://www.safepaas.com/articles/secure-sap-with-effective-access-governance/
6. (2025). Accesscertifiering: En ultimat guide. Zluri. Hämtad från https://www.zluri.com/blog/access-certification
7. (2024). Officiell webbplats för smartGRC-produkten. Hämtad från https://smartgrc.eu/