Efter bilagets punkt 11 i forordning 2024/2690 skal privilegerede konti have stærk identifikation, autentificering og autorisation, at administration sker fra særlige konti med individuelle og begrænsede beføjelser, og at administrationssystemer kun bruges til administration. Rettighederne gennemgås med planlagte mellemrum og efter organisatoriske ændringer.
For en udbyder, der administrerer kunders miljøer, er de privilegerede konti nøglerne til mange huse på én gang. Forordningen skelner ikke mellem udbydere og andre digitale enheder. At punktet vejer tungere hos en udbyder af administrerede tjenester, er en tolkning, men den følger af, hvad kontiene giver adgang til.
Hvad punkt 11 omfatter
Punkt 11 har syv underpunkter: 11.1 politik, 11.2 forvaltning af adgangsrettigheder, 11.3 privilegerede konti og systemadministrationskonti, 11.4 administrationssystemer, 11.5 identifikation, 11.6 autentificering og 11.7 multifaktor-autentificering.
Denne artikel gennemgår 11.3 og 11.4, der handler om de privilegerede konti og de systemer, de bruges fra. Den generelle adgangsstyring efter lovens krav er beskrevet i audit af adgangsstyringen, og autentificeringen i audit af MFA.
Privilegerede konti i punkt 11.3
Efter punkt 11.3.2 skal enheden, forenklet gengivet:
- bruge stærk identifikation, autentificering, såsom multifaktor-autentificering, og autorisation for privilegerede konti og systemadministrationskonti
- have særlige konti, der udelukkende bruges til systemadministration
- individualisere og begrænse beføjelserne for systemadministration
- lade systemadministrationskonti bruges alene til forbindelse til administrationssystemer.
Punkt 11.3.3 kræver, at rettighederne for privilegerede konti og systemadministrationskonti gennemgås med planlagte mellemrum og efter organisatoriske ændringer. Resultatet af gennemgangen dokumenteres.
To krav springer i øjnene. Det første er adskillelsen mellem den daglige konto og administratorkontoen. En tekniker, der læser mail og administrerer kunders servere fra samme konto, opfylder ikke kravet om særlige konti. Det andet er kravet om individualiserede beføjelser. Fælles administratorkonti, som flere bruger, gør det umuligt at se, hvem der gjorde hvad.
Administrationssystemer i punkt 11.4
Efter punkt 11.4.2 skal administrationssystemer kun bruges til systemadministration. De skal være logisk adskilt fra applikationssoftware, der ikke bruges til administration. Adgangen til dem skal være beskyttet med autentificering og kryptering.
Kravet hænger sammen med punkt 6.8.2 om et dedikeret administrationsnet. En arbejdsstation, der bruges til at administrere kundernes miljøer, bør ikke også bruges til at åbne mail og browse. Den sammenhæng er beskrevet i netarkitektur og segmentering.
Logningen af privilegeret adgang
Logningskravet i punkt 3.2.3, litra e, nævner, hvor det er relevant, den privilegerede adgang og administratorkontienes handlinger. Uden den logning kan enheden ikke vise, hvad de privilegerede konti er brugt til. Logningen er beskrevet i logning efter punkt 3.2.
Sådan prøver auditor punktet
Arbejdsgangen her er almindelig auditpraksis.
Første dokument er en liste over alle privilegerede konti og systemadministrationskonti, også dem hos kunderne, som udbyderen bruger. For hver konto ser auditor efter en ejer, et formål og en dato for seneste gennemgang. Konti uden ejer, fælles konti og konti for medarbejdere, der er stoppet, er klassiske fund.
Dernæst ser auditor efter, at de privilegerede konti er beskyttet med stærk autentificering, og at de ikke bruges til andet end administration. Et udtræk fra logningen af privilegeret adgang kan vise, om en administratorkonto er brugt til at åbne mail eller hente filer fra internettet.
Auditor beder også om dokumentationen for den seneste gennemgang efter 11.3.3. Er der sket en reorganisering, eller er en tekniker stoppet, ser auditor efter, at rettighederne blev gennemgået bagefter.
Til sidst ser auditor på administrationssystemerne. Hvor står de, hvem har adgang, og er de adskilt fra anden software?
Kontiene hos kunderne
For en udbyder er det svært at holde styr på de konti, teknikerne har i kundernes miljøer. Kontiene oprettes hos kunden, men bruges af udbyderens folk. Når en tekniker stopper, skal adgangen lukkes hos hver eneste kunde, vedkommende kunne komme ind hos. Auditor vælger derfor en tekniker, der er fratrådt, og kontrollerer hos et par af kunderne, at kontiene er spærret. Den kontrol er auditpraksis.
Hvad det kræver, og hvad det koster at lade være
Det kræver en liste over privilegerede konti med ejere, særskilte administratorkonti for hver tekniker, stærk autentificering, adskilte administrationssystemer og en fast gennemgang af rettighederne. For en udbyder skal listen også dække konti i kundernes miljøer.
Misbrug af en privilegeret konto hos en udbyder kan ramme alle de kunder, kontoen giver adgang til. Det er et af de scenarier, der gør punktet tungt i en audit og i et tilsyn.
Det skal I lade være med
- At bruge fælles administratorkonti · punkt 11.3.2 kræver individualiserede beføjelser.
- At administrere fra den daglige konto · systemadministration kræver særlige konti.
- At glemme gennemgangen efter en fratrædelse · punkt 11.3.3 kræver den efter organisatoriske ændringer.
Det skal auditten kunne vise
- ☐ En liste over privilegerede konti og systemadministrationskonti med ejer og formål.
- ☐ Særlige konti til administration og stærk autentificering af dem.
- ☐ Individualiserede og begrænsede beføjelser uden fælles konti.
- ☐ Administrationssystemer, der kun bruges til administration og er logisk adskilt.
- ☐ Dokumenterede gennemgange af rettighederne, også efter organisatoriske ændringer.
- ☐ Logning af privilegeret adgang og administrative konti.
Kilder
- Kommissionens gennemførelsesforordning (EU) 2024/2690 af 17. oktober 2024, bilaget punkt 3.2.3, 6.8.2, 11.3 og 11.4, https://publications.europa.eu/resource/celex/32024R2690, læst 12. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Træk en liste over alle konti med administratorrettigheder i jeres egne og kundernes miljøer, og sæt en ejer på hver.
Læs også: Personalesikkerhed i auditten · Aktiver efter punkt 12
→ Kontakt · Tlf. 70 13 63 23 · NIS2-audit hos Nielco IT
