I en värld av affärssystem som SAP är frågan om användarrättigheter avgörande – inte bara för säkerheten, utan också för hela organisationens effektivitet. Ändå stöter man i praktiken ofta på situationer där användarna har tillgång till en mycket bredare uppsättning funktioner än de egentligen behöver. Ibland ”för säkerhets skull”, ibland ”för att det går snabbare”, och ibland har ingen helt enkelt brytt sig om att kontrollera.
Samtidigt finns det en princip som bör ligga till grund för alla policyer för åtkomsthantering:Principen omminsta möjligaprivilegium(LPP). I ett nötskal innebär det att en användare ska ha exakt så mycket privilegier som han eller hon behöver för att utföra sina arbetsuppgifter. Varken mindre eller mer.
En undersökning av 225 organisationer visade att 85% av behörigheterna inte hade använts under de senaste 90 dagarna, och en av tre användare hade tillgång till system som de inte hade använt alls. Dessa uppgifter lämnar inga illusioner – överflödig åtkomst är ett verkligt och utbrett problem. Majoriteten av användarna har alldeles för breda behörigheter, vilket inte bara ökar attackytan utan också utgör en revisionsrisk.
Varför spelar det egentligen någon roll?
LPP-principen är inte bara sunt förnuft – den är en av grundpelarna för informationssäkerhet och regelefterlevnad. Alltför omfattande befogenheter kan bli resultatet:
- bedrägeri eller manipulation av data,
- oavsiktliga fel som stör processer eller orsakar dataförlust,
- brott mot principen om åtskillnad av arbetsuppgifter (SoD),
- bristande efterlevnad av regelverk som RODO eller SOX,
- svårare revisioner och större utrymme för cyberattacker.
Berättelser från livet, eller hur det ser ut i praktiken.
Låt oss titta på några exempel på hur principen om minsta möjliga tillgång inte tillämpas:
Exempel 1: Redovisningsekonom med full tillgång till faktureringscykeln
Personen på ekonomiavdelningen hade tillgång till alla transaktioner i faktureringscykeln: från registrering av inkommande fakturor (MIRO), till kontering av dokument (FB60) och godkännande av betalningar (F110).
Risk: Den anställde kan utföra hela processen själv – från skapandet av dokumentet till genomförandet av överföringen. En sådan åtkomst bryter mot principen om åtskillnad av arbetsuppgifter och gör det betydligt svårare att senare fastställa vem som var ansvarig för vad.
Lösning: Begränsa åtkomsten till en roll – t.ex. endast MIRO eller endast FB60 – och tilldela betalningsgodkännande till en annan användare. Det är värt att implementera ett arbetsflöde och tydligt definiera ägarna till varje steg i processen.
Exempel 2: Anställd på inköpsavdelningen med tillgång till försäljningsvillkoren
Inköpschefen hade inte bara tillgång till order (ME21N, ME22N), utan även till villkor för försäljningspriser (VK11). Problemet var att han inte behövde dessa uppgifter och att redigering av dem kunde få strategiska konsekvenser.
Risker: Obehörig ändring av prispolicy – oavsiktlig eller avsiktlig.
Lösning: Gör en tydlig åtskillnad mellan inköps- och säljroller och begränsa åtkomsten till data endast inom de relevanta enheterna.
Exempel 3: Anställd efter byte av arbete
Efter att ha flyttat från lagret till ekonomiavdelningen behöll medarbetaren de gamla rättigheterna och fick nya. Resultatet? Samtidig åtkomst till lagerdokument och kostnadsdata.
Risker: Överflödig tillgång till processer utanför nuvarande ansvarsområden, potentiella SoD-konflikter.
Lösning: Varje förändring av befattning bör innebära en fullständig genomgång av behörigheter – inte bara att lägga till nya roller utan också att ta bort onödiga.
Dessa exempel visar hur lätt det i praktiken är att ge för stora befogenheter – ofta till följd av brådska, bristande granskning eller ogenomtänkta kombinationer av roller. Vart och ett av de beskrivna fallen visar tydligt att även till synes mindre försummelser kan leda till allvarliga risker som lätt kan elimineras genom att tillämpa LPP-principen.
Hur ska man agera enligt LPP-principen?
För att tillämpa principen om minsta möjliga åtkomst krävs inte bara medvetenhet om riskerna, utan också konkreta organisatoriska och tekniska åtgärder – helst systematiskt genomförda och med långsiktig säkerhet i åtanke. Här är några förslag:
- Skapa affärsroller som är anpassade till faktiska ansvarsområden – inga onödiga transaktioner.
- Upprätta organisatoriska fält och begränsa omfattningen av data (t.ex. till ett visst företag eller lager).
- Använd genomtänkta processer för godkännande och granskning av rättigheter – särskilt när du byter roll eller position.
- Verifiera SoD-konflikter innan du beviljar åtkomst.
- Kontrollera rättigheterna regelbundet, t.ex. var 6:e eller 12:e månad.
- Stöd dig själv med SAP-verktyg som GRC Access Control, SUIM, ST03N eller transaktionsloggar.
Och om du verkligen vill reda ut frågan om åtkomst är det värt att ta fram dedikerade lösningar som smartGRC (https://smartgrc.eu/). Med dessa kan du bland annat
- genomföra periodiska granskningar av rättigheter,
- implementera ett arbetsflöde för att bevilja och godkänna åtkomst,
- hantera SoD:s riskdatabas, vilket avsevärt underlättar kontrollen och förbättrar systemsäkerheten.
LPP och användarupplevelse
En vanlig myt är att begränsad auktoritet gör människor mindre bekväma. I själva verket är det precis tvärtom.
Väl utformade roller – i linje med ansvarsområden och rensade från överflödiga transaktioner – skapar användare:
- hitta de funktioner de behöver snabbare,
- inte överväldigas av onödiga alternativ i gränssnittet,
- är mindre benägna att göra misstag som beror på att de råkar klicka på ”fel sak”.
Principen om minsta möjliga åtkomst förbättrar därför inte bara säkerheten utan också SAP-systemets användbarhet. Det är ett renare och tydligare gränssnitt – och därmed en bättre upplevelse för slutanvändaren.
LPP och säkerhetsföreskrifter och -standarder
Det är också värt att komma ihåg att principen om minsta möjliga åtkomst inte bara är god praxis – den är ett av de formella kraven i många internationella standarder och bestämmelser för informationssäkerhet och dataskydd.
Här är några exempel:
- ISO/IEC 27001 – kräver att tillgång till resurser kontrolleras utifrån affärsmässiga behov.
- NIST SP 800-53 – identifierar principen om minsta möjliga privilegier som den primära mekanismen för att skydda informationssystem.
- RODO/GDPR – innebär en skyldighet att begränsa tillgången till personuppgifter till dem som faktiskt behöver dem (minimeringsprincipen).
- SOX (Sarbanes-Oxley Act) – kräver åtkomstkontroller i samband med integriteten i de finansiella rapporterna.
Att följa LPP-principen bidrar därför inte bara till att minimera operativa risker, utan också till att upprätthålla efterlevnaden av tillämpliga regler och standarder, vilket kan vara avgörande vid revisioner och externa inspektioner.
Vad vinner du på att använda LPP?
Att implementera principen om minsta möjliga åtkomst handlar inte bara om efterlevnad och säkerhet. Det innebär också en rad påtagliga fördelar:
- Färre problem med revisioner – tack vare bättre kontroll över åtkomst.
- Snabbare och tydligare kontroller – strukturerade roller innebär färre undantag som måste översättas.
- Lägre kostnader för åtkomsthantering – färre roller att underhålla, färre förfrågningar till IT.
- Ökad transparens i ansvarsutkrävandet – det är tydligt vem som ansvarar för vad.
- Färre användarfel – eftersom de bara har tillgång till det de verkligen behöver.
- ”Renare” SAP-system – utan förvuxna roller och historiska behörigheter.
Slutligen, sunt förnuft som standard
Principen om minsta möjliga åtkomst är inte en överdriven försiktighetsåtgärd, utan ett professionellt förhållningssätt till säkerhet inom SAP. Den skyddar inte bara data och processer, utan även organisationens rykte.
Det är därför värt att ta sig en funderare: Är denna åtkomst verkligen nödvändig? Om inte – så är det just nu den perfekta tidpunkten att begränsa den.
Källor:
- Cloud Security Alliance. (2024). Mastering Least Privilege: Minska oanvänd åtkomst utan att skära hörn. Hämtad från https://cloudsecurityalliance.org/blog/2024/05/30/mastering-least-privilege-cutting-unused-access
- (u.å.). Vad är Least Privilege? Hämtad från https://www.cyberark.com/what-is/least-privilege/
- Edwards, M. (2025). Bilaga A.5.3: Åtskillnad av arbetsuppgifter. Online. Hämtad från https://www.isms.online/iso-27001/annex-a/5-3-segregation-of-duties-2022/
- Nationella institutet för standarder och teknik (NIST). (u.å.). Lägsta privilegium. Hämtad från https://csrc.nist.gov/glossary/term/least_privilege
- (2024). Säkra SAP med effektiv styrning av åtkomst. Hämtad från https://www.safepaas.com/articles/secure-sap-with-effective-access-governance/
- (2025). Accesscertifiering: En ultimat guide. Zluri. Hämtad från https://www.zluri.com/blog/access-certification
- (2024). Officiell produktsida för smartGRC. Hämtad från https://smartgrc.eu/
