Fælles login mellem jer og kunden

Når kundens medarbejdere logger ind i jeres løsning med det login, de bruger på arbejdet, hænger jeres adgangskontrol sammen med kundens. Kunden afgør, hvem der er medarbejder, og hvordan de logger ind; I afgør, hvad de får adgang til, når de er inde. For en NIS2-kunde er den kobling en del af adgangskontrollen, og en test skal derfor se på begge sider af den, uden at nogen af parterne tester den andens system uden lov.

Kravet hviler på NIS 2-lovens § 6, stk. 1, nr. 9 og 10, om adgangskontrol og multifaktorautentificering. Teksten er ikke juridisk rådgivning.

Tre former for fælles login

Fælles login dækker over flere opsætninger, og de giver forskellige testspørgsmål:

Kundens login i jeres løsning · kundens medarbejdere bruger kundens identitetstjeneste, fx Microsoft Entra ID, til at komme ind hos jer.
Jeres medarbejdere i kundens identitetstjeneste · kunden opretter jeres teknikere som gæster eller brugere hos sig.
En fælles tjeneste · begge parter logger ind i en tredje tjeneste, som en af jer har valgt.

Find ud af, hvilken af dem kunden spørger til. Der kan være mere end én i spil, og de kan have forskellige ejere.

Hvad reglerne lægger vægt på

Gennemførelsesforordning (EU) 2024/2690 er bindende for bestemte digitale udbydere, fx cloud, datacentre og administrerede tjenester. Den kan også bruges af andre kunder som skabelon, når de skriver krav til leverandører. Bilagets afsnit 11 om adgangskontrol har tre punkter, der rammer et fælles login direkte:

Unikke identiteter · punkt 11.5.2 beder enheden oprette unikke identiteter og knytte en brugeridentitet til én person. Fælles identiteter er kun tilladt efter punkt 11.5.3, når der er et forretningsmæssigt eller driftsmæssigt behov, en udtrykkelig godkendelse og dokumentation.
Autentificeringens styrke · punkt 11.6.2, litra a, siger, at styrken skal passe til klassifikationen af det, der tilgås.
Multifaktor · punkt 11.7 handler om flere faktorer eller kontinuerlig autentificering, hvor det er relevant.

Punkt 11.2.2, litra b, om at rettigheder ændres, når en ansættelse ophører eller ændres, kan være det, der i praksis svigter i et fælles login. → Adgangskontrol og privilegerede konti

Hvad en test kan belyse

En test af et fælles login handler mindre om selve indlogningen og mere om det, der sker omkring den:

Hvem der lukkes ind · om jeres løsning kun accepterer brugere fra kundens egen identitetstjeneste og ikke fra andre.
Hvad brugeren får · om rollen i jeres løsning svarer til det, kunden har tildelt, og ikke kan udvides af brugeren selv.
Hvad der sker ved fratrædelse · om en medarbejder, kunden har lukket, også mister adgangen hos jer.
Reservekonti · om der findes lokale konti ved siden af det fælles login, og hvordan de er beskyttet.
Adskillelse mellem kunder · om en bruger fra én kunde kan nå en anden kundes data.

Det sidste punkt er særligt vigtigt, hvis flere kunder logger ind i samme løsning. Et fund dér rammer ikke kun den kunde, der bestilte testen. → Kundens brugere hos jer

Hvem giver tilladelsen?

Et fælles login går på tværs af to ejere. Jeres løsning og jeres opsætning af koblingen kan I lade teste på eget initiativ. Kundens identitetstjeneste er kundens, og en test, der rører den, kræver kundens skriftlige godkendelse. Ligger tjenesten hos en platformsleverandør, gælder platformens egne regler for test også.

I praksis kan testeren få testbrugere fra kunden, oprettet i kundens identitetstjeneste med de roller, der skal afprøves. Så kan testen foregå i jeres løsning uden at angribe kundens tjeneste. Aftal, hvem der opretter og sletter brugerne, og hvornår. → Afgrænsning mod kundens eget miljø

Kundens egen opsætning af multifaktorlogin ligger hos kunden. Viser testen, at jeres løsning ikke håndhæver det krav, kunden forventer, er det et fund hos jer. Viser den, at kundens regler tillader login uden ekstra faktor, er det kundens fund, og det skal formuleres sådan.

Når jeres folk er brugere hos kunden

Den omvendte situation er lige så almindelig: kunden opretter jeres teknikere som brugere i kundens identitetstjeneste, så de kan arbejde i kundens systemer. Her er det kunden, der ejer kontiene, men jer, der bruger dem. Kunden kan spørge, om kontiene er personlige, om de kun bruges fra jeres beskyttede maskiner, og om I melder fratrædelser hurtigt nok til, at kunden kan lukke dem.

En test hos jer kan belyse de maskiner og processer, kontiene bruges fra. Selve kontiene og deres rettigheder hos kunden er kundens at teste, og kunden kan vælge at gøre det i sin egen gennemgang af leverandøradgange. Aftal, hvem der dokumenterer hvad, så begge dele bliver dækket.

Et tænkt eksempel

En leverandør af et vagtplanssystem til et hospital lader hospitalets medarbejdere logge ind med hospitalets eget login. Hospitalet beder om dokumentation for, at adgangen er under kontrol.

Hospitalet opretter tre testbrugere med hver sin rolle. Testen viser, at rollerne bliver overført korrekt, men at en bruger, hospitalet har spærret, kan blive ved med at arbejde i en åben session i flere timer. Den viser også, at leverandørens egne supportkonti logger ind uden om det fælles login med kun en adgangskode. Leverandøren afkorter sessionerne og lægger supportkontiene under multifaktorlogin. Dokumentationen skelner mellem leverandørens fund og det, hospitalet selv skal tage stilling til.

Det skal I lade være med

At teste kundens identitetstjeneste uden godkendelse · den hører til kundens miljø.
At glemme reservekontiene · lokale konti ved siden af det fælles login kan blive overset.
At bruge rigtige medarbejderes konti i testen · brug testbrugere, kunden har oprettet.
At lade fund i kundens opsætning stå som jeres · placér hvert fund hos den rette ejer.
At afslutte uden oprydning · testbrugere skal slettes, når testen er slut.

Hvad kan og ikke kan konkluderes

En test kan vise, hvordan koblingen mellem kundens login og jeres løsning opførte sig på testtidspunktet, med de roller og testbrugere, der indgik. Den viser ikke, at kundens identitetstjeneste er sikker i sig selv, og den dækker ikke roller eller opsætninger, der kom til senere. Om koblingen lever op til kundens krav, vurderer kunden ud fra sin egen risikovurdering. Generel viden om, hvordan en penetrationstest afgrænses, findes på penetrationtest.dk. → Delte konti og fælles adgange

Tjekliste til et fælles login

☐ Er det klart, hvilken form for fælles login kunden spørger til?
☐ Har kunden godkendt den del af testen, der berører kundens identitetstjeneste?
☐ Har kunden oprettet testbrugere med de roller, der skal afprøves?
☐ Er reservekonti og supportkonti med i omfanget?
☐ Er adskillelsen mellem kunder med, hvis flere kunder bruger løsningen?
☐ Er det aftalt, hvem der sletter testbrugerne bagefter?