Adgangskontrol og privilegerede konti: hvordan test belyser foranstaltningen

Når en NIS2-kunde spørger til jeres adgangskontrol, kan kunden have brug for at vide to ting: hvem der kan komme ind i det, I leverer, og hvem der kan ændre det. Svaret hviler på NIS 2-lovens § 6, stk. 1, nr. 9, om adgangskontrolpolitikker og, for visse digitale udbydere, på punkt 11 i bilaget til gennemførelsesforordning 2024/2690.

En test kan vise, om rettighederne i praksis følger det, jeres politik og aftalen med kunden beskriver. Den kan ikke vise, at politikken er god, eller at rettighederne bliver gennemgået, som de skal. Derfor betaler det sig at skille kundens spørgsmål ad, før I vælger, hvad der skal afprøves.

Hvor kravet kommer fra

§ 6, stk. 1, nr. 9, i NIS 2-loven nævner personalesikkerhed, adgangskontrolpolitikker og forvaltning af aktiver som én af de ti foranstaltninger, kunden skal have. Bestemmelsen svarer til artikel 21, stk. 2, litra i, i NIS2-direktivet. Loven siger ikke, hvordan adgangskontrollen skal indrettes, og den nævner ikke leverandørens systemer særskilt.

Mere detaljeret er bilaget til forordning 2024/2690. Forordningen gælder kun for bestemte digitale udbydere, bl.a. cloud, datacentre, udbydere af administrerede tjenester og administrerede sikkerhedstjenester, onlinemarkedspladser og tillidstjenester. Er jeres kunde en af dem, eller er I det selv, gælder punkterne direkte for den pågældende. Andre kunder kan bruge dem som en beskrivelse af, hvad de forventer. → NIS 2-lovens § 6

Tre punkter i forordningen, som rammer leverandører

Bilagets punkt 11 handler om adgangskontrol. Tre af underpunkterne er dem, leverandører især kan møde i en kundes spørgsmål:

Punkt 11.2.2, litra d · adgangsrettigheder skal tage højde for tredjeparters adgang, herunder leverandører og tjenesteudbydere, navnlig ved at begrænse rettighederne i omfang og varighed.
Punkt 11.3 · politikker for privilegerede konti og systemadministrationskonti, med stærk autentificering, særlige konti til administration og så få og individuelle beføjelser som muligt.
Punkt 11.4 · administrationssystemer bruges kun til administration, holdes logisk adskilt fra anden software og beskyttes med autentificering og kryptering.

Punkt 11.3.3 kræver desuden, at rettighederne til privilegerede konti gennemgås med planlagte mellemrum, og at resultatet dokumenteres. Det er et krav om en proces, ikke om en test.

Det, en test kan belyse

En sikkerhedstest af adgangskontrol holder den beskrevne opsætning op mod den faktiske. Inden for det aftalte omfang kan den svare på spørgsmål som disse:

Rollerne · kan en almindelig bruger hos kunden se eller ændre noget, der hører til en anden rolle eller en anden kunde? → Kundens brugerroller
Administrationsadgangen · er de konti, jeres medarbejdere bruger til at drifte kundens løsning, adskilt fra almindelige konti og beskyttet som aftalt?
Supportadgangen · åbnes adgangen kun, når den er godkendt, og lukkes den igen bagefter? → Supportadgang i testen
Fælles konti · findes der konti, som flere personer deler, og er de kendt og godkendt?
Rester · findes der konti fra tidligere medarbejdere, gamle integrationer eller afsluttede projekter, som stadig virker?

Svarene er konkrete og knyttet til det tidspunkt, testen blev udført. De siger noget om, hvordan rettighederne så ud den dag, ikke om hvordan de bliver styret over tid.

Det, testen ikke svarer på

En stor del af kundens spørgsmål om adgangskontrol handler om styring. Hvem godkender en ny rettighed? Hvornår bliver rettighederne gennemgået? Hvad sker der, når en medarbejder stopper? Det besvares af jeres procedurer og af dokumentation for, at de bliver fulgt, fx referater fra gennemgange af rettigheder.

Bilagets punkt 11.5.3 tillader kun identiteter, der deles af flere personer, når det er nødvendigt af forretningsmæssige eller driftsmæssige årsager og er godkendt og dokumenteret. Om et delt login er godkendt, kan en test ikke afgøre. Den kan kun vise, at det findes. → Delte konti og fælles adgange

Multifaktorlogin ligger tæt op ad emnet, men har sin egen bestemmelse i § 6, stk. 1, nr. 10, og i bilagets punkt 11.7. → Multifaktorlogin som foranstaltning

Forberedelsen afgør, hvad resultatet kan bruges til

En test af adgangskontrol giver kun et brugbart svar, hvis den har noget at måle imod. Skriv før testen ned, hvilke roller der findes, hvad hver rolle må, og hvilke konti jeres egne medarbejdere og underleverandører bruger over for kunden. Den beskrivelse er testens målestok, og den er samtidig det dokument, kunden får mest ud af ved siden af resultatet.

Aftal også, hvilke konti testeren får. Skal testen vise, om en almindelig bruger kan nå mere end tilladt, skal testeren have netop en almindelig brugerkonto. Skal supportadgangen afprøves, skal det ske efter den samme godkendelse, som jeres medarbejdere bruger i hverdagen. Ellers belyser testen en situation, der ikke findes i drift.

Et tænkt eksempel

En leverandør af et vagtplanssystem til en region får et spørgsmål i regionens leverandørvurdering: Beskriv, hvordan leverandørens privilegerede adgang til løsningen er begrænset og kontrolleret. Leverandøren har en politik for området, men har aldrig fået den afprøvet.

Leverandøren deler svaret i to. Politikken og referatet fra den seneste gennemgang af administratorrettighederne vedlægges som beskrivelse af styringen. En test med et aftalt omfang afprøver, om en almindelig brugerrolle kan nå administrative funktioner, og om supportadgangen kun virker efter godkendelse. Resultatet sendes som et resumé med fund og status på rettelser, så regionen kan se både styringen og det, der faktisk er afprøvet.

Det skal I lade være med

At svare med en testrapport alene · den viser tilstanden på én dag, ikke at rettighederne bliver gennemgået.
At udelade jeres egne driftskonti · kundens interesse kan ligge netop i de konti, der kan ændre alt.
At give testeren fuld administratoradgang uden aftale · rollerne i testen skal svare til det, der skal belyses.
At skrive, at adgangskontrollen er NIS2-godkendt · der findes ingen sådan godkendelse.
At glemme konti hos jeres egne leverandører · har en underleverandør adgang til kundens data, hører den med i billedet.

Hvad kan og ikke kan konkluderes

En test kan vise, at bestemte roller og konti på et bestemt tidspunkt kun gav den adgang, de skulle, eller at de gav mere. Den kan ikke vise, at kunden lever op til § 6, eller at jeres styring af rettigheder virker over tid. Teksten er ikke juridisk rådgivning. Dækker jeres adgang mange kunder fra én platform, bliver spørgsmålet større. → Privilegerede konti hos MSP’en

Tjekliste, før I svarer kunden

☐ Ved I, om kunden henviser til loven, forordningen eller begge?
☐ Er kundens spørgsmål delt i styring og afprøvning?
☐ Er jeres administrations- og supportkonti med i testens omfang?
☐ Har testeren fået konti, der svarer til de roller, der skal afprøves?
☐ Er delte og gamle konti opgjort, før testen begynder?
☐ Kan I vedlægge dokumentation for den seneste gennemgang af rettigheder?

Kilder

NIS 2-loven, lov nr. 434 af 6. maj 2025: § 6, stk. 1, nr. 9 og 10.
NIS2-direktivet (EU) 2022/2555: artikel 21, stk. 2, litra i.
Gennemførelsesforordning (EU) 2024/2690: artikel 1 (hvem forordningen gælder for) og bilagets punkt 11.2.2, litra d, 11.3, 11.4, 11.5.3 og 11.7.
SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 9.b om adgangskontrol, herunder leverandørers og serviceudbyderes rettigheder.

Senest gennemgået: oktober 2026.