Delte konti og fælles adgange mellem jer og kunden

En konto, som flere af jeres medarbejdere deler for at komme ind hos kunden, er praktisk i hverdagen, men den gør det umuligt at se, hvem der var logget ind, og svær at lukke, når én af dem stopper. For en NIS2-kunde er sådanne fælles adgange et kendt risikopunkt, og de kan blive spurgt til i leverandørvurderingen. Før de kan testes, skal det være klart, hvem der ejer kontoen, hvem der må godkende en test af den, og hvad der skal ske bagefter.

Svaret afhænger af, hvor kontoen findes, og hvem der har oprettet den. Teksten er ikke juridisk rådgivning.

Hvad reglerne siger om fælles identiteter

Gennemførelsesforordning (EU) 2024/2690 gælder direkte for bestemte digitale udbydere, fx cloud, datacentre og administrerede tjenester. Andre NIS2-kunder kan bruge den som skabelon for, hvad de spørger leverandører om. Bilagets punkt 11.5 handler om identiteter:

Én identitet, én person · punkt 11.5.2, litra b, siger, at en brugeridentitet skal forbindes med en enkelt person.
Fælles identiteter som undtagelse · punkt 11.5.3 tillader identiteter, der er tildelt flere personer, kun hvis det er nødvendigt af forretningsmæssige eller driftsmæssige årsager, og hvis det er underlagt en udtrykkelig godkendelsesproces og dokumenteres.
Tredjeparters adgang · punkt 11.2.2, litra d, beder enheden begrænse leverandørers og tjenesteudbyderes adgangsrettigheder i omfang og varighed.

ENISA’s tekniske vejledning, som ikke er bindende, siger, at fælles identiteter bør undgås, medmindre de er strengt nødvendige. Den giver eksempler på beskyttelse, bl.a. multifaktorlogin, mindst mulige rettigheder, tidsbegrænset adgang, logning og muligheden for at knytte brugen af en fælles identitet tilbage til den enkelte person. → Adgangskontrol og privilegerede konti

Hvor de fælles adgange kan findes

Fælles adgange mellem leverandør og kunde kan opstå uden, at nogen har besluttet det:

Supportkontoen hos kunden · én konto, som hele supportteamet bruger.
Administratorkontoen i jeres system · en konto, som både kundens IT og jeres teknikere kender adgangskoden til.
Servicekonti · konti til integrationer og automatik, som ingen personligt logger ind med, men hvis adgangsoplysninger flere kender.
Nødkonti · konti, der skal bruges, hvis det normale login ikke virker.
Konti i tredjeparts værktøjer · fx et fælles login til en platform, I og kunden begge bruger.

Nogle af dem kan begrundes. En nødkonto er netop beregnet til den situation, hvor de personlige konti ikke virker. Andre findes kun, fordi det var hurtigere at oprette én konto end fem. Gennemgå dem derfor én for én, før testen bestilles. → Jeres supportadgang til kunden

Hvem ejer kontoen

Ejerskabet afgør, hvem der kan give tilladelse til en test:

Kontoen findes hos kunden · kunden ejer den, selv om I bruger den. En test kræver kundens skriftlige tilladelse.
Kontoen findes hos jer · I ejer den, men hvis kunden har adgang, bør kunden kende til testen.
Kontoen findes hos en tredjepart · platformens egne regler for test gælder, og der kan kræves accept.

Er ejerskabet uklart, er det i sig selv et fund, der er værd at rette, før testen går i gang. Den, der ejer en konto, skal også kunne lukke den. → Afgrænsning mod kundens eget miljø

Hvad testen kan belyse

En test af de fælles adgange kan vise, hvad de giver adgang til, om de er beskyttet med mere end en adgangskode, og om brugen kan spores til en person. Den kan også vise, om tidligere medarbejdere eller tidligere leverandører stadig kan bruge dem, fordi adgangskoden aldrig blev skiftet.

Testen kan ikke afgøre, om den fælles adgang er nødvendig. Det er en vurdering, I og kunden må træffe ud fra driften. Testen kan til gengæld give et grundlag for vurderingen ved at vise, hvad adgangen faktisk kan. → Privilegerede konti hos MSP’en

Efter testen

En test af en fælles konto betyder, at testeren har kendt eller fundet dens adgangsoplysninger. Bagefter bør adgangskoden skiftes, og det bør dokumenteres, at det er sket. Hvis testen viste, at kontoen kan erstattes af personlige konti, kan det være den bedste rettelse. Hvis den skal bestå, bør begrundelsen, godkendelsen og beskyttelsen skrives ned, så kunden kan se, at punkt 11.5.3’s undtagelse er taget alvorligt.

Aftal også, hvem der skifter adgangskoden, når kontoen ejes af kunden. Hvis I skifter den, skal kunden have besked. Hvis kunden skifter den, skal I have den nye på en sikker måde, så driften ikke stopper. Det lyder banalt, men en fælles konto, der pludselig ikke virker, kan føre til, at nogen opretter en ny med samme svagheder.

Et tænkt eksempel

En leverandør af et system til styring af en fødevarevirksomheds kølerum bruger én konto, “service”, til at logge ind hos kunden. Fem teknikere kender adgangskoden, og den er ikke skiftet, siden to af dem stoppede. Kunden spørger i sin årlige leverandøropfølgning, hvem der kan logge ind.

Leverandøren skifter adgangskoden med det samme og aftaler med kunden, at testeren må afprøve, hvad kontoen giver adgang til. Testen viser, at kontoen har administratorrettigheder på kundens server, selv om den kun bruges til at læse temperaturer. Kunden opretter fem personlige konti med multifaktorlogin og begrænsede rettigheder, og leverandøren beholder én nødkonto, der kun åbnes efter aftale. Ændringen dokumenteres i et kort notat til kunden, som kunden kan lægge ved sin leverandøropfølgning.

Det skal I lade være med

At teste en konto hos kunden uden tilladelse · den ejes af kunden.
At lade adgangskoden stå uændret efter testen · den er kendt af flere end før.
At beholde fælles konti af vane · undtagelsen kræver en begrundelse.
At glemme servicekonti · de kan være delt, selv om ingen logger ind med dem.
At skjule fælles adgange for kunden · kunden spørger efter dem af en grund.

Hvad kan og ikke kan konkluderes

En test kan vise, hvad de fælles adgange kunne bruges til, og om de var beskyttet på testtidspunktet. Den kan ikke afgøre, om de er nødvendige, og den kan ikke i sig selv opfylde kundens krav om sporbarhed. Det kræver ændringer i måden, adgangene bruges på. Forordningens punkt 11.5.3 beskriver, hvornår fælles identiteter kan accepteres. Om jeres er det, vurderer kunden ud fra aftalen og sin risikovurdering. → Fælles login mellem jer og kunden