Multifaktorlogin som NIS2‑foranstaltning: hvad en test kan vise kunden

Multifaktorlogin er en af de få foranstaltninger, NIS 2-loven nævner ved navn, og derfor også et punkt, der kan stå tidligt i et kravbilag til leverandører. Kunden vil vide, om login til jeres løsning og jeres adgang til kundens systemer kræver mere end en adgangskode. Grundlaget er lovens § 6, stk. 1, nr. 10, om brug af løsninger med multifaktorautentificering eller kontinuerlig autentificering, hvor det er relevant, og for visse digitale udbydere bilagets punkt 11.7 i forordning (EU) 2024/2690.

En test kan vise, om foranstaltningen virker, der hvor den er aftalt. Den kan ikke vise, at den er det rigtige valg alle steder. Vægten ligger derfor på foranstaltningen og dens dokumentation, ikke på teknikken bag en test. Teksten er ikke juridisk rådgivning.

Hvad lov og forordning siger

Lovens § 6, stk. 1, nr. 10, er kort og indeholder forbeholdet “hvor det er relevant”. SAMSIK’s vejledning om foranstaltninger uddyber, at enhedens brugere, it-komponenter og andre aktiver skal autentificeres med multifaktor eller kontinuerlig autentificering, hvor det vurderes relevant, ud fra en risikovurdering og aktivets klassifikation. Vejledningen anbefaler multifaktor ved fjernadgang, til administrative systemer, til følsomme eller fortrolige data og til systemer med høj værdi eller stor konsekvens ved kompromittering.

Forordningens punkt 11.7.1 kræver for de relevante enheder, at brugere autentificeres med flere faktorer eller kontinuerlig autentificering, hvor det er relevant, i overensstemmelse med klassifikationen af det aktiv, der tilgås. Punkt 11.7.2 kræver, at autentificeringens styrke passer til den klassifikation. → NIS 2-lovens § 6

Hvor kundens krav rammer jer

Kravet i loven gælder kundens egne systemer. Det rammer jer på mindst tre måder:

Jeres adgang til kunden · når jeres medarbejdere logger på kundens systemer for at yde support eller drift. → Jeres supportadgang til kunden
Kundens brugere hos jer · når kundens medarbejdere logger på jeres portal eller løsning.
Jeres egne administratorer · når jeres medarbejdere administrerer den platform, kundens data ligger på.

Det er især de to sidste, kunden ikke selv kan kontrollere, og derfor spørger kunden jer. Er login fælles mellem jer og kunden, fx via kundens egen brugerstyring, skal det aftales, hvem der står for hvilken del. → Fælles login mellem jer og kunden

Hvad en test kan belyse

En test af foranstaltningen kan svare på konkrete spørgsmål, der er aftalt på forhånd:

Dækning · kræves anden faktor på alle de adgangsveje, der er aftalt, eller findes der veje ind, hvor kravet ikke gælder?
Roller · kræves der stærkere login for roller med vide rettigheder end for almindelige brugere, som punkt 11.7.2 lægger op til?
Undtagelser · er de undtagelser, der findes, kendte, begrundede og begrænsede?
Gendannelse · kan kravet omgås, når en bruger har glemt sin faktor eller skal have en ny?

Svarene giver kunden noget, en erklæring om “MFA er slået til” ikke kan. De viser, om foranstaltningen holder i praksis på de steder, kunden er afhængig af. Hvordan testen udføres, hører hjemme i testplanen og testerens metode. → Fra effektivitetskrav til testplan

Det, en test ikke kan vise

En test er et øjebliksbillede af det omfang, den dækkede. Den kan ikke vise:

At valget af metode er det rigtige · fx om en bestemt type anden faktor er stærk nok til den klassifikation, kunden har givet sine data.
At alle brugere altid bruger den · nye konti og ændringer efter testen er ikke dækket.
At politikken bag er fulgt · fx at undtagelser bliver godkendt og fjernet igen.

ENISA’s vejledning til forordningen, som ikke er bindende, nævner som eksempler på dokumentation opsætningen af løsningen, log, der viser at multifaktor bruges, og en adgangspolitik, der beskriver, hvilke metoder der bruges til hvilke roller. Den anbefaler også at vælge metoder, der kan modstå phishing, hvor det er muligt. Sådan dokumentation supplerer testen og dækker den tid, testen ikke gør. → Adgangskontrol og privilegerede konti

Kontinuerlig autentificering som alternativ

Loven og forordningen nævner kontinuerlig autentificering som et alternativ til flere faktorer. SAMSIK beskriver det som løbende kontrol af en brugers eller et systems identitet under en aktiv session ud fra adfærd og sammenhæng, fx forsøg fra et ukendt sted, fra en ny enhed eller på et usædvanligt tidspunkt. De to kan også kombineres, så der kræves en ekstra faktor, når noget ser mistænkeligt ud.

Bruger I sådan en løsning i stedet for eller ud over anden faktor, skal I kunne forklare kunden, hvornår den slår til, og hvad der sker så. En test kan afprøve nogle af reglerne, men ikke alle de situationer, de skal fange. Dokumentationen af reglerne og af, hvordan de følges op, bliver derfor vigtigere her end ved klassisk multifaktor.

Et tænkt eksempel

En leverandør af et system til planlægning af hjemmepleje får et spørgsmål fra en kommune: “Bruger I multifaktorautentificering i henhold til NIS2?” Leverandøren svarer ikke bare ja. Svaret beskriver, at kommunens brugere logger på via kommunens egen brugerstyring, hvor kommunen selv står for kravet, at leverandørens administratorer altid skal bruge anden faktor, og at supportadgang til kommunens installation sker gennem en løsning med anden faktor og tidsbegrænset adgang.

Leverandøren vedlægger resultatet af en test, der afprøvede de tre adgangsveje, og skriver, at testen fandt én ældre adgang til administrationen uden krav om anden faktor, som nu er lukket og efterprøvet. Kommunen kan bruge svaret i sin egen vurdering, fordi det skelner mellem kommunens ansvar og leverandørens.

Det skal I lade være med

At svare ja uden at sige hvor · kunden har brug for at vide, hvilke adgangsveje der er dækket.
At glemme jeres egne administratorer · de kan have de bredeste rettigheder.
At lade gamle adgangsveje leve · en undtagelse, ingen kender, er ikke dækket af politikken.
At kalde en opsætning testet, fordi den er slået til · en test afprøver, om den holder.
At skrive teknik ind i svaret til kunden · beskriv foranstaltningen og resultatet.

Hvad kan og ikke kan konkluderes

En test kan vise, at multifaktor blev krævet på de aftalte adgangsveje på testtidspunktet, eller at det ikke gjorde. Den kan ikke alene vise, at metoden er stærk nok til kundens data, eller at kravet fortsat håndhæves. Sammen med en beskrevet adgangspolitik og log giver testen kunden et grundlag for sin egen vurdering. Om kunden lever op til § 6, stk. 1, nr. 10, vurderer kunden og kundens myndighed. → Privilegerede konti hos MSP’en