I ERP-systemet, CRM-systemet og HR-systemet ligger virksomhedens vigtigste data: kunder, priser, løn, leverandører og betalinger. Hvem der kan se og ændre hvad, styres af roller, og rollerne kan være vedligeholdt af IT på vegne af forretningen. Når en penetrationstest omfatter et forretningssystem, kan fundene vise, at nogle brugere kan mere, end de skal. Svaret på, hvad IT gør, hviler på at skille to spørgsmål ad: om systemet håndhæver de roller, der er sat op, og om de roller, der er sat op, er de rigtige. Det første er et spørgsmål til systemet og dets leverandør. Det andet er et spørgsmål til jer.
To slags fund om adgang
Systemet håndhæver ikke rollerne. En bruger med en begrænset rolle kan alligevel se eller ændre data, rollen ikke giver adgang til. OWASP placerer brudt adgangskontrol øverst i sin Top 10 og beskriver blandt andet, at kontrollen skal ske på serveren og ikke kun i brugerfladen. Fund af den type sidder i systemets kode og skal rettes af leverandøren eller udviklerne. → Købte løsninger og fordeling af fund
Rollerne giver for meget. Systemet gør præcis, hvad det er sat op til, men opsætningen giver brugerne flere rettigheder, end deres arbejde kræver. Det er et fund i administrationen, og det er IT og forretningen, der retter det.
Den anden slags fund kan fylde mest i rapporten, og den kan rettes uden at vente på nogen. Resten af gennemgangen handler derfor primært om den.
Fundtyper i rolleopsætningen
En test, der har testkonti med forskellige roller, kan finde:
- Brede standardroller · alle medarbejdere får samme rolle ved oprettelse, og rollen giver adgang til mere end det, de fleste skal bruge.
- Ophobede rettigheder · en medarbejder har skiftet afdeling og fået nye rettigheder uden at miste de gamle.
- Mange superbrugere · flere har fuld adgang til systemet, fordi det var nemmere end at finde den rigtige rolle.
- Manglende adskillelse af opgaver · samme bruger kan både oprette en leverandør og godkende betalinger til den.
- Konti efter fratrådte medarbejdere · konti i forretningssystemet, der ikke lukkes sammen med kontoen i Active Directory eller Entra ID.
- Konsulent- og leverandørkonti · adgang, der blev givet til et projekt og aldrig fjernet.
- Adgang uden om brugerfladen · rapportværktøjer, udtræk eller API’er, der giver adgang til data, rollen ellers skærmer for. → Overblik over API’er i driften
Testeren kan påvise, at en bestemt testkonto kan noget, den ikke burde. Testeren kan ikke afgøre, om jeres rigtige brugere har de rigtige roller. Det kræver en gennemgang, som kun I kan lave.
Hvem ejer rettighederne
Rettighederne i et forretningssystem har tre ejere, og fundene skal fordeles efter det:
- Forretningen · ved, hvilke opgaver den enkelte medarbejder har, og skal godkende, hvem der har adgang til hvad.
- IT · opretter og vedligeholder rollerne og tildeler dem efter forretningens ønsker.
- Leverandøren · ejer den kode, der håndhæver rollerne.
Uden forretningen kan IT ikke vide, om en rettighed er for bred. Uden IT bliver ændringerne ikke gennemført. Fundene skal derfor gennemgås sammen med ejerne af systemet i forretningen.
Det, testen skal have med
For at afprøve rollerne skal testeren have testkonti, der ligner rigtige brugere:
- Én konto pr. vigtig rolle · fx sagsbehandler, afdelingsleder, bogholder og administrator.
- To konti med samme rolle · så det kan afprøves, om den ene kan se den andens data, hvor det er relevant.
- Realistiske data · så der er noget at have eller ikke have adgang til. → Testmiljø til webtesten
- En oversigt over rollerne · med en kort beskrivelse af, hvad hver rolle skal kunne.
Den sidste oversigt er den vigtigste. Uden den kan testeren kun påvise, hvad en rolle kan, ikke om det er mere, end den skal.
Rettelser på begrebsniveau
Rettelserne handler om at gøre rollerne smallere og holde dem smalle:
- Roller efter opgaver · roller, der passer til bestemte jobfunktioner, frem for én bred standardrolle.
- Mindst mulig adgang · nye medarbejdere starter med det nødvendige og får mere ved behov. → Mindst mulig adgang i praksis
- Adskillelse af opgaver · de handlinger, der tilsammen kan misbruges, fordeles på forskellige personer.
- Færre superbrugere · fuld adgang forbeholdes dem, der administrerer systemet.
- Kobling til brugerstyringen · konti i forretningssystemet lukkes, når medarbejderen stopper, helst automatisk via fælles login.
- Periodisk gennemgang · forretningen godkender med faste mellemrum, hvem der har hvilke roller.
Stram gradvist. En rolle, der pludselig mister en rettighed, kan stoppe en arbejdsgang, ingen havde dokumenteret. → Skærpelser, brugerne mærker
Når systemet ligger hos en udbyder
Mange forretningssystemer kører ikke længere på egne servere, men som en tjeneste hos en udbyder. Det ændrer ikke ved, hvem der ejer rollerne. Udbyderen driver platformen, men det er jer, der beslutter, hvem der får hvilken rolle, og jer, der skal rydde op.
Det ændrer derimod ved, hvad der må testes. Udbyderens vilkår kan sætte grænser for test af tjenesten, og nogle udbydere kræver, at testen anmeldes på forhånd. Afklar det, før testen planlægges. Det mest relevante er måske alligevel ikke platformen, men jeres egen opsætning: hvilke roller I har oprettet, hvem der har dem, og hvilke integrationer der har adgang til data. Den del kan langt hen ad vejen gennemgås fra jeres egen administratoradgang, og den er jeres ansvar, uanset hvem der driver systemet. → Appregistreringer og samtykke
Hvordan I prioriterer
Begynd med de roller, der giver adgang til betalinger, løn og persondata, og med fund om manglende adskillelse af opgaver. Fund, hvor systemet ikke håndhæver rollerne, sendes til leverandøren med det samme, fordi ingen opsætning kan rette dem. Konti efter fratrådte medarbejdere og tidligere konsulenter kan lukkes hurtigt og bør ikke vente på et projekt.
Det skal I lade være med
- At lade IT afgøre alene, hvem der skal have hvad. Forretningen ved, hvad opgaverne kræver.
- At give fuld adgang for at undgå henvendelser. Det sparer tid nu og giver fund senere.
- At glemme konti i forretningssystemet, når en medarbejder stopper. De lukker ikke af sig selv.
- At ændre alle roller på én gang. Arbejdsgange stopper, og ændringerne bliver rullet tilbage.
- At behandle et fund i koden som et rolleproblem. Det kræver en rettelse fra leverandøren.
Hvad kan og ikke kan konkluderes
Testen viser, hvad testkontiene kunne se og ændre med de roller, de fik, og om systemet håndhævede rollerne i de funktioner, der blev afprøvet. Den kan ikke vise, om jeres rigtige brugere har de rigtige roller, eller om andre funktioner i systemet håndhæver adgangen på samme måde. Den kan heller ikke vise, om en rettighed tidligere er blevet misbrugt.
Kilder
- OWASP Top 10:2025 A01 Broken Access Control: brudt adgangskontrol som første kategori i 2025-udgaven, mindst mulig adgang, adgang nægtet som udgangspunkt og kontrol på serveren.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Inaktive konti og gamle computere i kataloget · Overblik over API’er i driften
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
