Kundeportalen, som NIS2‑kundens medarbejdere logger ind på

En portal, hvor kundens medarbejdere logger ind for at bestille, indberette, se data eller styre en tjeneste, flytter en del af kundens arbejde over i jeres system. For en NIS2-kunde betyder det, at kundens brugere, kundens data og måske kundens beslutninger ligger hos jer. Kunden vil derfor vide, om portalen holder kundens data adskilt fra andres, om kun de rette medarbejdere kan logge ind, og om kunden selv kan styre, hvem der har adgang.

En test af portalen er sandsynligvis det, kunden har tænkt på, når kravet nævner jeres løsning. Teksten er ikke juridisk rådgivning.

Hvorfor kunden ser portalen som sin egen risiko

NIS 2-lovens § 6, stk. 1, nr. 4, handler om forsyningskædesikkerhed, herunder forholdet til direkte leverandører. Når kundens medarbejdere bruger jeres portal til at levere kundens egen tjeneste, er portalen en del af den kæde, kunden skal styre.

Gennemførelsesforordning (EU) 2024/2690 gælder direkte for bestemte digitale udbydere, fx cloud, administrerede tjenester og onlinemarkedspladser, men andre kunder kan låne dens formuleringer. Bilagets punkt 5.1.2, litra c, nævner IKT-tjenesternes generelle kvalitet og modstandsdygtighed som kriterium ved valg af leverandør. Punkt 5.1.4, litra a, nævner cybersikkerhedskrav til leverandører i kontrakten. Er portalen jeres tjeneste til kunden, er det her, kravene lander. → Kundens krav til jeres løsning

Det, kunden vil vide

Kundens spørgsmål om portalen kan falde i fem grupper:

Login · om kundens medarbejdere logger ind med multifaktorlogin eller via kundens egen identitetsløsning.
Roller · om kundens superbrugere kan styre, hvem der må hvad, og om rollerne faktisk begrænser adgangen.
Adskillelse · om kundens data er adskilt fra andre kunders, også i eksport, rapporter og søgning.
Livscyklus · om en medarbejder, der stopper hos kunden, mister adgangen, når kunden lukker kontoen.
Sporbarhed · om kunden kan se, hvem der har gjort hvad i portalen.

Punkterne afspejler forordningens krav til kundens egne systemer, fx punkt 11.2.2 om tildeling og tilbagekaldelse af rettigheder og punkt 11.7 om multifaktorlogin. Kunden kan ikke opfylde dem for de medarbejdere, der arbejder i jeres portal, hvis portalen ikke understøtter dem. Spørgsmålene er derfor ikke kun en kontrol af jer, men også kundens måde at få sine egne foranstaltninger til at række ind i jeres system. → Multifaktorlogin som NIS2-foranstaltning

Hvad testen skal dække

En test af portalen bør tage udgangspunkt i de roller, kundens medarbejdere har. Testeren skal have konti, der svarer til en almindelig bruger, en superbruger og gerne en bruger hos en anden kunde, så adskillelsen kan afprøves. Uden de konti kan testen kun belyse det, der kan nås uden login, og det er ikke nødvendigvis det, kunden er mest bekymret for.

Testen bør også omfatte de funktioner, der flytter data ud af portalen: eksport, rapporter, filer og forbindelser videre til andre systemer. Det kan være her, adskillelsen mellem kunder svigter.

Tænk også på de dele af portalen, kundens medarbejdere ikke ser til daglig: funktioner til nulstilling af adgangskoder, invitationer af nye brugere og den side, hvor superbrugeren ændrer roller. De er ikke altid i fokus ved udvikling, men de afgør, om kunden reelt styrer adgangen. Og hvis jeres egne supportmedarbejdere kan logge ind som en kundes bruger for at hjælpe, hører den funktion også med i testen. OWASP’s Web Security Testing Guide er en åben og udbredt reference for, hvad en test af en webløsning kan omfatte, og kan nævnes i testplanen. → Kundens brugere hos jer

Når portalen også er en app. Har kundens medarbejdere adgang via en mobilapp, er appen en anden vej ind til de samme data. Den kan gemme oplysninger på telefonen og kalder serverens funktioner gennem et API, som ikke nødvendigvis bruges på samme måde af portalen i browseren. En test af portalen dækker derfor ikke automatisk appen. Aftal, om appen og det API, den bruger, skal med i omfanget. → API’et, kunden kalder

Når portalen bruger kundens login

En NIS2-kunde kan foretrække, at medarbejderne logger ind i portalen med kundens egen identitetsløsning. Det lægger multifaktorlogin og fratrædelse over hos kunden, hvilket kunden kan se som en fordel. Til gengæld skal testen afprøve, om portalen stoler på det rigtige: om den kun accepterer brugere fra kundens løsning, og om en bruger fra én kunde på nogen måde kan få adgang til en anden kundes data efter login. Testen kan kræve, at kunden stiller en testbruger til rådighed i sin identitetsløsning, så det bør aftales i god tid. → Fælles login mellem jer og kunden

Fælles portal eller kundens egen version

Er portalen fælles for mange kunder, kan én test dække flere kunder, hvis den afprøver adskillelsen grundigt. Har kunden en særlig opsætning, egne integrationer eller egne roller, kan det være nødvendigt at teste kundens version særskilt. Hvordan et softwarehus håndterer kundekravet til en rapport om et fælles produkt, behandles på pentestrapport.dk. → Kundespecifik opsætning eller fælles platform

Et tænkt eksempel

En leverandør af en portal til indberetning af affaldsdata har ti kommuner og fem private affaldsselskaber som brugere. Et af selskaberne er omfattet af NIS2 og beder om dokumentation for, at selskabets data er beskyttet.

Leverandøren lader portalen teste med konti for en almindelig bruger og en superbruger hos to forskellige kunder. Testen viser, at superbrugeren hos én kunde kan se navnene på brugere hos en anden kunde via en søgefunktion. Leverandøren retter fejlen, får den afprøvet igen og sender selskabet et resumé med fundet, rettelsen og dato for den nye afprøvning. Selskabet beder også om, at medarbejderne fremover logger ind med selskabets egen identitetsløsning, hvilket leverandøren tager med i næste version. Indtil da aftales det, at selskabet hver måned får en liste over aktive brugere, så selskabet selv kan lukke konti for medarbejdere, der er stoppet.

Det skal I lade være med

At teste portalen uden konti · det vigtigste ligger bag login.
At glemme eksport og rapporter · data forlader portalen den vej.
At love, at portalen opfylder kundens NIS2-krav · kunden vurderer selv sine krav.
At bruge rigtige kundedata i testen · brug testkonti og testdata, hvor det kan lade sig gøre.
At undlade at fortælle kunden om fund, der angår adskillelsen · det er kundens data, det drejer sig om.

Hvad kan og ikke kan konkluderes

En test af portalen kan vise, om de afprøvede roller og funktioner holdt kundens data adskilt og adgangen begrænset på testtidspunktet. Den viser ikke, at kundens egne superbrugere tildeler rettigheder korrekt, og den dækker ikke de dele af kundens arbejde, der foregår uden for portalen. Om portalen samlet lever op til kundens krav, afgør kunden ud fra aftalen og sin vurdering af jer. → Hvad skal kunden have?