Flerfaktorgodkendelse, ofte kaldet MFA, er en anden kontrol oven på en adgangskode: en kode fra en app, en sms eller en fysisk nøgle. Spørgsmålet om dette er obligatorisk for en softwarevirksomhed kan ikke besvares med et simpelt ja eller nej, fordi NIS2-direktivet ikke foreskriver en specifik teknik. Artikel 21 forpligter organisationer, der falder under pligten til at tage passende foranstaltninger, til adgangskontrol og flerfaktorgodkendelse, og tilsynsmyndigheder ser herved på, hvor risikoen er størst.
For en softwarevirksomhed er det i praksis to helt forskellige steder: den udviklingslinje, som du selv bruger, og den software, som du leverer til kunder. Begge kræver en egen vurdering, og denne vurdering er ikke lige streng alle steder.
To steder hvor flerfaktorgodkendelse spiller en rolle
Det første sted er internt: det miljø, hvor dine udvikler arbejder. Kildekode, udviklingsstien, cloudkonsoller og de systemer, som du bruger til at udrullere til produktion. Det andet sted er i selve produktet: hvis den software, som du bygger eller leverer, har en loginskærm, er flerfaktorgodkendelse også et emne der, både for dine egne brugere og for dine kunders slutbrugere. Et sikkerhedsspørgeskema fra en opdragsgiver spørger næsten altid om begge dele, ofte i separate spørgsmål, som er formuleret anderledes end du ville forvente.
Ved adgang til din udviklingslinje
Her ligger den stærkeste forventning. Den, der kan få adgang til kildekoden, den der kan udrullere til produktion, og den der har administratorrettigheder i cloudmiljøet, udgør den største risiko, hvis en adgangskode kun bliver stjålet eller genbrugt. For disse konti gælder flerfaktorgodkendelse i næsten ethvert sikkerhedsrammeværk som en grundlæggende foranstaltning, og det er også det, som tilsynsmyndigheder og kunder først forventer. Versionsstyring, udviklingsstien selv og især enhver konto med rettigheder til at udrullere kode til produktion, hører i praksis uden undtagelse bag en anden fase.
Det bør også omfatte et blik på, hvem der faktisk stadig har brug for denne adgang. En dokumentation, som viser, hvem der må få adgang til hvert system og hvorfor, gør det lettere at besvare dette spørgsmål i et spørgeskema med et konkret svar i stedet for med en antagelse. hvordan adgangskontrol og flerfaktorgodkendelse forklares pr. emne giver der et udgangspunkt for.
Ved den software, som du leverer
Det andet niveau er selve softwaren. Hvis dit produkt har en loginfunction, kommer spørgsmålet om, hvorvidt du tilbyder flerfaktorgodkendelse, næsten altid tilbage i et sikkerhedsspørgeskema, og nogle gange endda som en kontraktlig betingelse. Det er en anden vurdering end ved din egen udviklingslinje: her handler det ikke om, hvad du selv bruger, men om hvad du leverer til din kunde. En opdragsgiver, der selv falder under pligten til at tage passende foranstaltninger, skal efter artikel 21 også vurdere sin forsyningskæde, og spørgsmålet om, hvorvidt dit produkt understøtter stærk godkendelse, hører til her.
Svaret behøver ikke at være, at det er obligatorisk overalt aktiveret. Ofte er det tilstrækkeligt at vise, at muligheden findes, at brugerne opfordres til det, og at du har en plan for at udvide det, hvor risikoen begrunder det.
Hvor det er mindre indlysende
Ikke alle konti eller miljøer stiller de samme krav til sikkerhedsforanstaltninger. Et testmiljø uden rigtige kundedata, et internt dokumentationssystem med kun læseadgang, eller et isoleret værktøj som en enkelt udvikler bruger lejlighedsvist, kræver ikke samme niveau af sikkerhed som en konto med adgang til produktionsmiljøet. Pligten til at træffe passende foranstaltninger betyder, at tiltag skal tilpasses risiciene, ikke at samme høje sikkerhedsniveau skal påføres alt. Tilsynsmyndighederne vurderer dette på grundlag af proportionalitet, og det betyder, at en velbegrundet beslutning om ikke at implementere flerfaktorgodkendelse et bestemt sted er lige så meget en del af en dokumentation som de steder, hvor det bruges.
Her er dokumentationen af valget det vigtigste ord. Et valg uden begrundelse ser let ud som en fejl på en spørgeskema, mens samme valg med en kort forklaring ofte er præcis det svar, som en kontraktpart er på udkig efter.
Hvad det betyder for samtalen med en kontraktpart
En kontraktpart som sender et spørgeskema, ønsker som regel ikke at vide, om du opfylder enhver bestemmelse, men om du ved, hvor dine risici ligger, og om du håndterer dem bevidst. For flerfaktorgodkendelse betyder det: kunne vise, hvad der er implementeret på udviklingsstien, hvad der er implementeret i produktet, og hvorfor resten er indrettet anderledes. Hvis du har dokumenteret det per system med status og ansvarlig, behøver du ikke at søge svar igen, når næste spørgeskema ankommer.
Om og hvordan det helt præcist slår ud for din egen organisation, afhænger af din rolle i værdistrømmen og af, hvad dine kunder specifikt spørger om; rådspørg ved tvivl direktivets tekst selv eller en rådgiver. Hvis du først vil vide, hvor du står, giver den gratis kontrol i nogle få spørgsmål en første indikation, og en forklaring på hvor informationen kommer fra viser hvordan denne indikation er blevet til.
Hvis du vil læse bredere om hvordan dette emne hænger sammen med de øvrige foranstaltninger fra pligten til at træffe passende foranstaltninger, finder du det i oversigten over emner pr. situation. Quick-scan og videnbase er frit tilgængelige uden at du behøver at oprette en konto.