Privilegerede konti hos MSP’en på tværs af kunder

En administratorkonto hos en driftsleverandør er ikke nødvendigvis kun en konto i leverandørens eget miljø. Den kan give adgang til servere, identitetsløsninger og cloudmiljøer hos flere kunder. Det gør kontiene til det første, en NIS2-kunde spørger til, når kunden vurderer jer som tjenesteudbyder. Spørgsmålet hviler på NIS 2-lovens krav om adgangskontrol og på bilagets punkt 11.3 i forordning (EU) 2024/2690 om privilegerede konti og systemadministrationskonti. Svaret ligger i, hvor langt hver konto rækker, og om I kan vise det.

Her beskrives, hvad kontiene skal kunne tåle, og hvad en test skal afprøve. Teksten er ikke juridisk rådgivning og ingen opskrift på opsætning.

Hvad punkt 11.3 siger

Forordningen gælder en bestemt kreds af digitale udbydere, herunder udbydere af administrerede tjenester og administrerede sikkerhedstjenester. Punkt 11.3.1 kræver politikker for forvaltning af privilegerede konti og systemadministrationskonti. Punkt 11.3.2 siger, at politikkerne skal:

Stærkt login · indføre stærke procedurer for identifikation, autentificering og autorisering, fx multifaktorautentificering.
Særlige konti · oprette konti, der udelukkende bruges til systemadministration.
Begrænsede beføjelser · individualisere og begrænse administrationsbeføjelserne mest muligt.
Kun til administration · fastsætte, at administrationskonti kun bruges ved forbindelse til systemadministrationssystemer.

Punkt 11.3.3 kræver, at rettighederne gennemgås med planlagte mellemrum, ændres ved organisatoriske ændringer, og at gennemgangen dokumenteres. For kunder, der ikke selv er under forordningen, er grundlaget NIS 2-lovens § 6, stk. 1, nr. 9 og 10, om adgangskontrol og multifaktorautentificering, hvor det er relevant. → Adgangskontrol og privilegerede konti

Hvorfor kontiene hos en MSP er noget særligt

Hos en almindelig virksomhed er en administratorkonto en risiko for virksomheden selv. Hos en driftsleverandør kan den samme konto være en risiko for alle de kunder, den har rettigheder hos. Kunden kan se, hvilke af jeres konti der findes i kundens eget miljø, men ikke om de samme personer eller konti også har rettigheder hos andre. Det overblik har kun I. → Delte platforme hos MSP’en

Fire typer konti fortjener særlig opmærksomhed:

Personlige administratorkonti · teknikernes egne konti, som de bruger i det daglige arbejde hos kunderne.
Fælles konti · konti, flere teknikere kender adgangen til, fx en lokal administratorkonto, der er ens hos flere kunder. → Delte konti og fælles adgange
Servicekonti · konti, som værktøjer til overvågning, backup eller opdatering bruger, og som ingen logger ind med.
Nødkonti · konti, der kun skal bruges, hvis den normale adgang svigter.

Hvad en test skal afprøve

En test af de privilegerede konti er ikke en optælling. Den undersøger, hvad en konto faktisk kan, hvis den bliver misbrugt. Spørgsmålene kan formuleres, så kunderne kan forstå svaret:

Rækkevidde · hvor mange kunder kan en enkelt konto nå, og svarer det til teknikerens opgaver?
Adskillelse · bruges administrationskonti kun til administration, eller kan de også læse mail og browse?
Login · kræver alle veje ind med en privilegeret konto mere end en adgangskode? → Multifaktorlogin som NIS2-foranstaltning
Oprydning · er konti fra tidligere ansatte og afsluttede kundeforhold faktisk lukket?
Servicekonti · har de flere rettigheder end opgaven kræver, og hos hvor mange kunder?

Testen skal omfatte de systemer, hvor rettighederne styres: jeres egen identitetsløsning, administrationsværktøjet og de steder, hvor adgangskoder til kundemiljøer opbevares. Dybden i test af Active Directory og Entra ID er beskrevet på penetration-test.dk. → Administrationsværktøjer

Test og gennemgang supplerer hinanden

Punkt 11.3.3 handler om en gennemgang af rettighederne, ikke om en test. Gennemgangen tjekker, om rettighederne svarer til det, der er besluttet. Testen tjekker, om det besluttede holder, når nogen forsøger at gå videre. En kunde kan bede om begge. Har I en dokumenteret gennemgang og en test, der bekræfter den, er det stærkere end hver for sig.

Hvad I viser kunderne

Hver kunde har brug for at vide, hvilke af jeres konti der har rettigheder hos kunden, og hvordan de er beskyttet. Kunden har ikke brug for listen over jeres andre kunder. Et svar kan derfor bestå af tre dele: en oversigt over de konti og roller, der har adgang hos netop den kunde, en kort beskrivelse af jeres regler for privilegerede konti, og et resumé af den seneste test med de fund, der vedrører kundens adgang.

Har testen vist et fund, der gælder alle kunder, fx en servicekonto med for brede rettigheder, så skal alle berørte kunder have den samme besked. Det gælder også kunder, der ikke har spurgt. Beskriv fundet i almindelige ord, hvad I har gjort, og hvornår rettelsen er kontrolleret. Undgå at sende tekniske detaljer om, hvordan kontoen kunne misbruges. → Fund, der rammer flere kunder

Et spørgeskema kan nøjes med at spørge, om I bruger multifaktorlogin. Svar på spørgsmålet, men overvej at tilføje, at servicekonti og nødkonti er omfattet af jeres gennemgang. Det er de konti, kunden ikke selv kan se.

Et tænkt eksempel

En driftsleverandør med tolv teknikere og omkring fyrre kunder får et spørgeskema fra en kommune, der spørger til administratorkonti. Leverandøren har multifaktorlogin på alle personlige konti. Testen viser dog, at en servicekonto til backup har administratorrettigheder hos samtlige kunder, og at to konti fra en tekniker, der er stoppet, stadig er aktive hos tre kunder. Leverandøren lukker de gamle konti samme dag, begrænser servicekontoens rettigheder til det, backup kræver, og fastlægger, hvornår rettighederne gennemgås næste gang. Kommunen får et resumé med fundene, rettelserne og datoen for den næste gennemgang.

Det skal I lade være med

At lade hver tekniker have rettigheder hos hele kundekredsen · adgangen bør svare til de kunder, teknikeren arbejder for.
At bruge den samme lokale administratoradgang hos flere kunder · én lækket adgangskode rammer dem alle.
At overse servicekonti · de logger ikke ind, men de kan have de bredeste rettigheder.
At lade administrationskonti bruges til mail og internet · det udvider risikoen uden grund.
At svare kunden med en politik alene · kunden kan bede om at se, at den virker.

Hvad kan og ikke kan konkluderes

En test kan vise, hvor langt jeres privilegerede konti rakte, og om login, adskillelse og oprydning holdt på testtidspunktet. Den kan ikke vise, at rettighederne bliver holdt ved lige bagefter, eller at teknikerne bruger dem korrekt. Det kræver jeres løbende gennemgang. Kunden vurderer selv, om dokumentationen passer til kundens krav.