Roller og rettigheder i produktet: hvilke skal med i testen?

Kundernes brugere har forskellige roller i produktet, og hver kunde regner med, at en almindelig medarbejder ikke kan det samme som deres administrator. Svaret på, hvilke roller testen skal omfatte, hviler på en enkel regel: alle roller, der giver adgang til noget, som en anden rolle ikke må, skal være med. Ellers kan rapporten ikke sige, om grænserne mellem dem holder.

For et softwarehus er rollerne mere end en teknisk detalje. De er en del af det, I har lovet kunderne: at deres administrator bestemmer, hvem der ser hvad.

Rollerne er produktets egne regler

Et SaaS-produkt har typisk to slags grænser. Den ene går mellem kunderne. Den anden går inden for hver kunde, mellem de brugere, der har forskellige roller. Begge er jeres ansvar at bygge, men den anden er den, kunderne selv administrerer, og derfor den, de forventer virker, som skærmbillederne viser.

OWASP beskriver manglende kontrol af, om en bruger må bruge en bestemt funktion, som en af de udbredte risici for API’er. Pointen er, at mange roller, grupper og brugerhierarkier gør kontrollen svær at få rigtig. Jo flere roller produktet har, jo mere er der at teste. → Multi-tenant: test af adskillelsen mellem kunderne

Kortlæg rollerne, før testen bestilles

Begynd med en liste over de roller, produktet faktisk har, ikke de roller, der står i salgsmaterialet. Det kan være to forskellige lister. Over tid kommer der roller til, som blev lavet til en enkelt kunde, til en integration eller til en intern funktion.

For hver rolle skal I kunne svare på:

Hvad rollen må · hvilke data og funktioner den har adgang til.
Hvad rollen ikke må · det, der adskiller den fra rollen over den.
Hvem der tildeler den · kundens administrator, jeres support eller produktet selv.
Hvem der bruger den · kundens medarbejdere, kundens egne kunder, partnere eller maskiner.

Listen er nyttig for testeren, men også for jer. Den er grundlaget for at svare præcist, når en kunde spørger, hvem der kan se hvad.

Giv testeren listen som en enkel oversigt: roller på den ene led, de vigtigste funktioner og datatyper på den anden, og et kryds, hvor adgangen er tilsigtet. Testeren bruger oversigten til at vide, hvad der er en fejl, og hvad der er meningen. Uden den kan testeren rapportere en tilsigtet adgang som et fund eller overse en utilsigtet, fordi den ligner noget, produktet skal kunne.

Hvis det viser sig svært at lave oversigten, er det i sig selv et fund for produktteamet. En rollemodel, som ingen kan beskrive, er også svær at forklare for kunderne.

De roller, der hører med

Hvilke roller der skal med, afhænger af produktet. Disse er værd at overveje i et produkt til virksomheder:

Kundeadministrator · den, der opretter brugere og ændrer kundens opsætning.
Almindelig bruger · den daglige rolle, der har adgang til arbejdet, men ikke til opsætningen.
Begrænset bruger eller gæst · en rolle med adgang til en lille del, fx kun læsning eller kun ét projekt.
Eksterne brugere · kundens egne kunder, leverandører eller samarbejdspartnere, hvis produktet har en portal til dem.
Tekniske brugere · konti, som integrationer bruger, med rettigheder, der ikke altid følger en almindelig rolle.

Jeres egne medarbejderes adgang er et emne for sig, fordi den bevidst går på tværs af kunderne. → Supportadgang og administrationsmodul

Testeren skal have en konto i hver af de roller, der er med, og helst hos mere end én kunde. → Testlejere

Hvad testen afprøver i rollerne

Testen undersøger, om rollerne holder i praksis og ikke kun i brugerfladen. En knap, der er skjult for en almindelig bruger, er ikke det samme som en funktion, den almindelige bruger ikke kan bruge. Testen ser på tre retninger:

Opad · kan en rolle udføre noget, der er forbeholdt en rolle med flere rettigheder?
Til siden · kan en bruger se eller ændre en anden brugers data, når de har samme rolle, men ikke må se hinandens arbejde?
Over tid · mister en bruger adgangen, når rollen ændres eller fjernes, eller når brugeren deaktiveres?

Det sidste punkt kan blive overset. En kunde, der fjerner en tidligere medarbejders adgang, forventer, at den er væk med det samme.

Roller, kunderne selv kan definere

Nogle produkter lader kundens administrator lave egne roller ud fra en liste af rettigheder. Det giver kunderne frihed, men det betyder også, at der findes kombinationer, ingen hos jer har set. Testen kan ikke afprøve dem alle. Aftal i stedet, at testen ser på, om de enkelte rettigheder virker hver for sig, og om en administrator kan give mere, end de selv har.

Hvis kunderne kan lave egne roller, er det relevant at skrive i rapporten, hvordan det blev afgrænset. → Kundespecifikke tilpasninger og konfigurationer

Hvad fund i rollerne betyder for kunderne

Et fund, hvor en almindelig bruger kan nå administratorens funktioner, rammer alle kunder, der bruger produktet med flere roller. Kunderne vil spørge, om deres medarbejdere har kunnet se eller ændre noget, de ikke måtte, og det spørgsmål kræver, at I kan svare ud fra jeres logs.

Fund i rollerne kan også have lav teknisk alvorlighed og stadig være vigtige for en bestemt kunde, fx hvis en gæsterolle kan se navne på andre projekter. Forklar konsekvensen i kundens sprog. → Lav alvorlighed, stor bekymring: forklar et fund for kunden

Det skal I lade være med

Teste med en administratorkonto alene · så ses kun det, den stærkeste rolle kan.
Bruge salgsmaterialets rolleliste · produktet kan have flere roller end dem, der er beskrevet.
Glemme eksterne og tekniske brugere · de kan være dem, der har mest uklare rettigheder.
Stole på, at skjulte knapper er nok · testen skal se, om funktionen kan bruges, ikke om den vises.
Udelade fjernelse af adgang · kunderne regner med, at en deaktiveret bruger er ude.
Love kunderne, at roller ikke kan omgås · testen viser, hvad der blev fundet i de testede roller.

Hvad kan og ikke kan konkluderes

En test uden fund i rollerne viser, at testeren ikke kunne overskride grænserne mellem de roller, der var med, i den testede version. Den siger intet om roller, som ingen testkonto havde, eller om rollekombinationer, kunderne selv har lavet bagefter.

Tjekliste til rollerne i testen

☐ Findes der en opdateret liste over produktets roller?
☐ Er det beskrevet, hvad hver rolle må og ikke må?
☐ Har testeren en konto i hver relevant rolle?
☐ Er eksterne og tekniske brugere med?
☐ Er fjernelse og ændring af roller en del af testen?
☐ Er det besluttet, hvordan kundedefinerede roller afgrænses?

Kilder

OWASP API Security Top 10 2023: Broken Function Level Authorization: manglende kontrol af, om en bruger må bruge en funktion, og at mange roller, grupper og hierarkier gør kontrollen svær.

Senest gennemgået: oktober 2026.