Kundens brugere hos jer: roller og rettigheder i testen

Kundens medarbejdere bruger jeres løsning med forskellige opgaver. Nogle registrerer, andre godkender, og en enkelt administrerer kundens egne brugere. For en NIS2-kunde er det vigtigt, at hver rolle kun kan det, den skal, for det er kundens egen adgangskontrol, der i praksis ligger i jeres system. En test, der kun afprøver løsningen med én bruger, svarer ikke på det spørgsmål. Testen skal bruge de roller, kundens medarbejdere faktisk har.

Baggrunden er adgangskontrolpolitikkerne i NIS 2-lovens § 6, stk. 1, nr. 9, og de principper for tildeling af rettigheder, som forordning (EU) 2024/2690 beskriver. Teksten er ikke juridisk rådgivning.

Hvorfor rollerne er kundens sag

Kunden skal styre, hvem der har adgang til hvad, også når systemet ligger hos en leverandør. Gennemførelsesforordning (EU) 2024/2690 gælder direkte for bestemte digitale udbydere, fx cloud og administrerede tjenester, og er for andre kunder en udbredt model. Bilagets punkt 11.2.2, litra a, beder enheden tildele og tilbagekalde rettigheder efter princippet om “need to know”, princippet om mindste rettighed og princippet om adskillelse af opgaver.

Kunden kan kun leve op til det, hvis jeres løsning gør det muligt. Har en sagsbehandler i praksis samme rettigheder som en godkender, kan kunden ikke adskille opgaverne, uanset hvad kundens politik siger. Det er derfor, rollerne er et testspørgsmål og ikke kun et konfigurationsspørgsmål. → Adgangskontrol og privilegerede konti

Find de roller, der betyder noget

En løsning kan have flere roller, end kunden bruger. Start med kundens virkelighed, ikke med jeres rolleliste:

Den almindelige bruger · den medarbejder, der arbejder i løsningen hver dag.
Godkenderen · den, der kan frigive, betale, ændre status eller lukke en sag.
Kundens administrator · den, der opretter og fjerner kundens egne brugere.
Læseadgang · revisorer, ledere eller andre, der kun skal kunne se.
Jeres egen support · jeres medarbejdere, når de arbejder i kundens del af løsningen.

Spørg kunden, hvilke af dem der bruges, og om kunden har lavet egne roller. Spørg også, hvilke opgaver der efter kundens politik ikke må ligge hos samme person. Det er de grænser, testen skal afprøve.

Vælg hellere få roller, der afprøves grundigt, end mange, der kun når at blive logget ind med. En test med tre veludvalgte roller kan sige mere til kunden end en test, der har været forbi ti. Skriv i omfanget, hvilke roller der indgik, og hvorfor de blev valgt, så kunden kan se, at valget er gjort ud fra kundens brug.

Hvad testen kan belyse

Med de rigtige roller kan en test give svar på spørgsmål, kunden kan bruge:

Kan rollen mere, end den skal · om en almindelig bruger kan nå funktioner, der hører til godkenderen eller administratoren.
Kan rollen se for meget · om brugeren kan se data fra andre afdelinger, sager eller kunder.
Kan rollen udvide sig selv · om en bruger kan give sig selv eller andre flere rettigheder.
Holder adskillelsen · om den samme person kan både oprette og godkende, hvor kunden har forbudt det.
Følger rettighederne med ved ændringer · om en bruger, der skifter rolle, mister det gamle.

Det sidste svarer til bilagets punkt 11.2.2, litra b, om at rettigheder ændres ved ophør eller ændring af ansættelsen. Kunden kan beskrive procedurerne, men kun en afprøvning viser, at løsningen følger dem. Det samme gælder punkt 11.2.2, litra d, om at begrænse tredjeparters adgang i omfang og varighed, når jeres egen support arbejder i kundens del af løsningen.

Testkonti og testdata

En rolletest kræver konti, der svarer til de rigtige roller, men ikke tilhører rigtige medarbejdere. Aftal med kunden, hvem der opretter dem: I, kunden eller kundens administrator i løsningen. Får kundens administrator lov at gøre det, afprøver I samtidig, at oprettelsen fungerer som beskrevet.

Data er det andet spørgsmål. Bilagets punkt 6.2.2, litra e og f, beder enheden udvælge, beskytte og forvalte data i forbindelse med sikkerhedstest og rense og anonymisere testdata efter risikovurderingen. Foregår testen i produktion med rigtige data, skal kunden vide det og godkende det. Et testmiljø med opdigtede data kan være det bedre valg, hvis det svarer til produktionen. → Kundespecifik opsætning eller fælles platform

Når flere kunder deler løsningen

Bruger flere kunder samme løsning, er adskillelsen mellem kunderne lige så vigtig som adskillelsen mellem roller. En bruger med en almindelig rolle hos én kunde må ikke kunne nå en anden kundes data. Det spørgsmål kan kun belyses med testkonti hos mindst to kunder, og det kræver normalt et testmiljø eller testkunder, som I selv opretter. Rigtige kunders data må ikke blive en del af testen uden deres viden. → Kundeportalen, som NIS2-kundens medarbejdere logger ind på

Et tænkt eksempel

En leverandør af et indkøbssystem til en kommune har fire roller: indkøber, budgetansvarlig, godkender og kommunens administrator. Kommunen beder om dokumentation for, at rollerne holder, fordi dens politik siger, at den, der bestiller, ikke må godkende.

Leverandøren opretter en testkommune med de fire roller og en ekstra testkommune til at afprøve adskillelsen mellem kunder. Testen viser, at en indkøber kan godkende sin egen bestilling, når beløbet er under en grænse, som ingen hos kommunen kendte. Leverandøren gør grænsen synlig og lader kommunens administrator slå den fra. Dokumentationen beskriver fundet, rettelsen og hvilke roller der indgik. Adskillelsen mellem de to testkommuner holdt, og det står også i dokumentationen, fordi kommunen ellers ikke kan vide, at det blev afprøvet.

Det skal I lade være med

At teste med én administratorkonto · den viser intet om de andre roller.
At bruge rigtige medarbejderes konti · brug testkonti, oprettet til formålet.
At teste i produktion med rigtige data uden aftale · kunden skal vide og godkende det.
At glemme jeres egen support · den rolle kan have mest adgang.
At lade testkonti blive liggende · de skal fjernes, når testen er slut.

Hvad kan og ikke kan konkluderes

En rolletest kan vise, om de testede roller på testtidspunktet kunne mere eller se mere, end de skulle. Den kan ikke vise, at kunden tildeler rollerne korrekt i hverdagen, og den dækker ikke roller, der ikke indgik. Om rettighederne passer til kundens politik, vurderer kunden. Kommer der nye roller eller funktioner til, kan det være en grund til at afprøve rollerne igen. → Fælles login mellem jer og kunden

Tjekliste til rolletesten

☐ Har kunden oplyst, hvilke roller der bruges, og hvilke opgaver der skal adskilles?
☐ Er det aftalt, hvem der opretter testkontiene?
☐ Er jeres egen supportrolle med?
☐ Er der testkonti hos mindst to kunder, hvis løsningen deles?
☐ Er det aftalt, om testen bruger rigtige data eller testdata?
☐ Er det aftalt, hvem der fjerner testkontiene?