Journalnummer: 2020-442-6168
Resume
Datatilsynet traf den 23. februar 2022 afgørelse i en sag, hvor 30 kommuner i slutningen af 2019 og starten af 2020 havde anmeldt et brud på persondatasikkerheden til Datatilsynet.
Bruddet omhandlede, at en fejl i Aula medførte, at det fra den 24. november 2019 til den 20. december 2019 var muligt for en bruger A at tilgå en anden bruger B’s sikre filer i Aula, hvis bruger B ikke var logget ud af computeren, og bruger A loggede ind med eget NemID. Sikre filer er et område i Aula med følsomme personoplysninger, der kræver ekstra login.
Fejlen skyldtes en programmeringsfejl hos Netcompany i forbindelse med udviklingen af en ændring til loginløsningen i Aula.
Til brug for sagen indhentede Datatilsynet en udtalelse fra Gentofte Kommune, som var én af de 30 kommuner, der havde haft et sikkerhedsbrud, samt Kombit og Netcompany.
Datatilsynet fandt, at Kombit ikke havde levet op til reglerne om behandlingssikkerhed, da Kombit ikke havde sikret, at der blev foretaget tilstrækkelig test af Aula i forbindelse med ændringen af koden i Aula.
Datatilsynet lagde vægt på, at en fejl i udviklingen af løsningen medførte, at der ikke var korrekt styring af adgangsrettigheder i Aula.
Datatilsynet lagde endvidere vægt på, at Netcompany og Kombit ikke kunne blive enige om, hvilke tests der kunne forventes udført i forbindelse med udviklingsprojektet, og at de ikke kunne blive enige om, hvorvidt Netcompany agerede som underdatabehandler eller ej.
På den baggrund udtalte Datatilsynet alvorlig kritik af Kombit.
1. Afgørelse
Efter en gennemgang af sagen finder Datatilsynet, at der er grundlag for at udtale alvorlig kritik af, at Kombits behandling af personoplysninger – som databehandler – ikke er sket i overensstemmelse med reglerne i databeskyttelsesforordningens[1] artikel 32, stk. 1.
Nedenfor følger en nærmere gennemgang af sagen og en begrundelse for Datatilsynets afgørelse.
2. Sagsfremstilling
Det fremgår af sagen, at en fejl i Aula medførte, at hvis bruger A loggede ind i Aula, og efterlod computeren uden at lukke/logge af, hvorefter bruger B tilgik computeren, hvor bruger A var logget ind, og bruger B tilgik indhold, der krævede ”step up” i sikkerhedsniveau, ville bruger B blive bedt om at indtaste sit NemID. Her skulle systemet udelukkende godtage bruger A’s NemID. Hvis bruger B indtastede sit eget NemID, fik bruger B imidlertid uberettiget adgang til bruger A’s indhold.
Det fremgår videre af sagen, at det login til Aula, som bruger A foretog, var et en-faktor-login i form af UNI-login. Det efterfølgende login med NemID var et to-faktor-login, der gav det nødvendige ”step up” i autorisation, som gav adgang til følsomme og fortrolige personoplysninger i et område kaldet ”sikre filer”.
Kommunerne blev bekendt med bruddet efter henvendelse fra Kombit.
2.1. Gentofte Kommunes bemærkninger
Gentofte Kommune har oplyst, at det ikke er muligt at oplyse, hvor mange personer, der havde mulighed for at opnå uautoriseret adgang til personoplysninger i den periode, hvor bruddet stod på, da udnyttelsen af fejlen forudsatte, at brugeren i strid med kommunens retningslinjer havde overladt sit udstyr til en anden bruger. I den forbindelse har Gentofte Kommune oplyst, at der var oprettet ca. 1.500 brugerprofiler til kommunens medarbejdere, der potentielt har haft mulighed for adgang til hinandens sikre filer.
Gentofte Kommune har endvidere oplyst, at ”sikre filer” er et særligt område af Aula-systemet, hvor der er forøget sikkerhed for at kunne tilgå disse i form af krav om indlogning via NemID, og at det var denne ekstra sikkerhed, der pga. en programmeringsfejl ikke fungerede som den skulle, idet Aula ved en fejl accepterede ethvert NemID, og ikke kun det NemID, som tilhørte den bruger, der oprindeligt havde logget ind – og som ikke havde sørget for at logge ud inden computeren blev overladt til en anden bruger.
Herudover har Gentofte Kommune oplyst, at hvad der præcis ligger af typer af personoplysninger i ”sikre filer” er i nogen grad op til de enkelte skoler og Aulateams, da der ikke kan laves en så præcis anvendelsesstrategi, at der kan styres centralt hvilke følsomme oplysninger der skal ligge i ”sikre filer” – men anvendelsesstrategien anfører, at følsomme personoplysninger skal ligge i ”sikre filer”, og ikke andre steder i Aula. Det fremgår desuden af anvendelsesstrategien, at Aula ikke er et sagsbehandlingssystem. ”Sikre filer” i Aula indeholder derfor primært observationer af børn og klasser, og ikke sagsbehandling, da dette foregår i kommunens ESDH-system.
Gentofte Kommune har oplyst, at i alt 7684 elever i kommunen er berørt af bruddet. Hver enkelt lærer vil dog kun have adgang til information om ca. 100-200 brugere.
Endelig har Gentofte Kommune oplyst, at det ikke er kommunens vurdering, at deres brugere efterlader computere ulåst, og at computere automatisk låses efter få minutters inaktivitet. Derudover vil det normalt kun være medarbejdere underlagt tavshedspligt, der eventuelt har anvendt en fælles computer.
2.2. Netcompanys bemærkninger
Netcompany har oplyst, at der i forbindelse med den anmeldte hændelse var sket en programmeringsfejl under udviklingen af en ændring til loginløsningen i Aula. Der var tale om en menneskelig fejl foretaget af en udvikler hos Netcompany. Fejlen bestod i en programmeringsfejl i softwarens kildekode, der utilsigtet satte en såkaldt autentifikationstest ud af spil på den ene af Aulas loginløsninger. Autentifikationstesten er implementeret på alle Aulas loginløsninger og er en ekstra sikkerhedsforanstaltning, der sikrer, at den bruger, der er logget ind, er den samme bruger, som den, der forsøger at tilgå de særligt følsomme områder af Aula. Dette med henblik på at beskytte brugernes personoplysninger mest muligt.
Netcompany har endvidere oplyst, at til trods for Netcompanys omfattende tests, der gennemføres hver eneste gang en ny kode idriftsættes, blev fejlen ikke opdaget, inden den nye kode blev implementeret i Aula. Netcompany har bemærket hertil, at den berørte loginløsning også tidligere var blevet gennemtestet, og at der ikke var grundlag for at tro, at den nye kildekode ville påvirke den pågældende loginløsning i forbindelse med implementeringen.
Netcompany har anført, at der i Aula-projektet er tale om løbende videreudvikling, vedligeholdelse og drift af systemet. Det er derfor vigtigt at holde skarp sondring mellem, hvornår Netcompany optræder som underdatabehandler, og hvornår Netcompany ikke optræder som underdatabehandler, idet sidstnævnte bl.a. er tilfældet under udviklingen og vedligeholdelsen af Aula.
Herudover har Netcompany oplyst, at fejlen – og en del af årsagen til bruddet – er sket i designet/programmeringen af Aula, og dermed som led i udviklingen af løsningen. Da udviklingen af software, som f.eks. Aula, ikke udgør en databehandlingsaktivitet, har Netcompany anført, at Netcompany ikke har ageret som hverken dataansvarlig, databehandler eller underdatabehandler i forbindelse med udviklingen af Aula og i forbindelse med det opståede databrud.
I den forbindelse har Netcompany anført, at databruddet alene kunne opstå i et tilfælde, hvor en anden bruger undlod at logge ud af sin profil i strid med interne retningslinjer og normal brugeradfærd.
Netcompany har oplyst, at en lang række oplysninger i Aula kan tilgås ved brug af en-faktor-login enten via Uni-login eller IdP-login (for medarbejdere). Dette efter ønske fra kommunerne og Kombit om, at det skulle være nemt at tilgå Aula, da det var en bekymring, at brugerne ikke ville benytte Aula, hvis adgangskontrollen var for besværlig. Følsomme og fortrolige oplysninger kan kun tilgås ved to-faktor-login. Aula blev oprindeligt bygget op sådan, at de områder, der indeholdt følsomme oplysninger, f.eks. ”sikre filer” eller ”følsomme beskeder”, krævede et ekstra login, i form af NemID.
I både Uni- og IdP-loginløsningen loggede brugerne oprindeligt ind i Aula med brugernavn og adgangskode (en-faktor), hvorefter de skulle bruge deres NemID (to-faktor) til at logge ind på ny for at tilgå følsomme områder i Aula, idet der her skete et såkaldt ”step-up” i sikkerheden.
Netcompany har endvidere oplyst, at på et tidspunkt ønskede kommunerne og Kombit at implementere en løsning i IdP-loginløsningen, hvor det blev muligt at foretage to-faktor-login (”step-up”) ved brug af et lokal IdP i stedet for NemID, således at man loggede ind med et lokalt idP (en-faktor) og ”steppede up” med et lokal idP (to-faktor). I overensstemmelse med processerne i en it-udviklingskontrakt blev der derfor den 8. oktober 2018 udarbejdet en ændringsanmodning (”ÆA43 – step-up med Lokal IdP”). Ændringen blev sat til idriftsættelse med release 1.1.5 den 24. november 2019.
Da release 1.1.5 blev idriftsat den 24. november 2019 opstod der en fejl i Aulas håndtering af UNI-loginløsningen. Det skete ved, at der blev introduceret en kode i release 1.1.5, som utilsigtet satte den automatiske autentifikationstest i UNI-loginløsningen ud af spil, så det ikke længere blev sikret, at brugeren logget ind i Aula, var den samme bruger, som den der forsøgte at ”steppe-up” ved tilgang til de følsomme områder i Aula. Der var tale om en menneskelig fejl i programmeringen foretaget af en udvikler hos Netcompany. Netcompany modtog besked om fejlen kl. 8.30 den 20. december 2019 og havde løst fejlen efter fire timer.
Netcompany har gjort gældende, at når den specifikke situation, som den foreliggende alligevel kan opstå – hvor bruger A ikke logger ud af sin Aula-profil og efterlader sin computer ulåst, hvorefter bruger B kan tilgå bruger A’s profil og derfra forsøge at ”steppe-up” med eget NemID – så skyldes det, at hverken Netcompany, F-secure (som udførte en ekstra penetrationstest i forbindelse med release 1.1.5), Kombit eller kommunerne havde grund til at tro, at den nye programmeringskode, der alene vedrørte IdP-loginløsningen, ville kunne påvirke UNI-loginløsningen, og at der derfor var behov for at teste UNI-loginløsningen yderligere. UNI-loginløsningen var tidligere blevet gennemtestet, uden der blev fundet fejl i løsningen, og der var heller ikke nogen grund til at tro, at der ville opstå fejl i løsningen ved implementeringen af release 1.1.5.
Endelig har Netcompany gjort gældende, at det var godkendt af Kombit, at det alene var IdP-loginløsningen, der blev testet i forbindelse med releasen, og at alle testrutiner på Aula derudover og under hele projektet er blevet vurderet og godkendt i overensstemmelse med processerne under en udviklingsaftale.
2.3. Kombits bemærkninger
Indledningsvist har Kombit anført, at som totalleverandør af Aula-løsningen behandler Netcompany personoplysninger. Denne behandling sker udelukkende på kommunernes vegne til de af kommunerne angivne formål, da Kombit har pålagt Netcompany de samme databeskyttelsesforpligtelser, som Kombit har fået pålagt af kommunerne. Det er derfor Kombits vurdering, at der er tale om en underdatabehandlerkonstruktion i forholdet mellem Kombit og Netcompany.
Efter Kombits opfattelse ændres det faktum, at der er tale om en underdatabehandlerkonstruktion mellem Kombit og Netcompany ikke af, at Netcompany, som en del af de samlede ydelser der skal leveres under kontrakten løser opgaver, der ikke direkte medfører behandling af personoplysninger. Kombit er derfor ikke enig med Netcompany i, at der skal sondres imellem, hvornår Netcompany optræder som underdatabehandler, og hvornår Netcompany ikke optræder som underdatabehandler.
Kombit har oplyst, at Kombit i ændringsanmodningen ÆA 43 – Step-up med lokal IdP ønskede en ny funktionalitet i Aula. Kombit stillede ikke krav om, hvordan Netcompany skulle ændre i Aulas kode for at opnå den nye funktionalitet, da Kombits kendskab til løsningen ikke var på et sådant detaljeringsniveau, at det ville kunne lade sig gøre for Kombit at skrive en kravsspecifikation til ændringen på kode-niveau.
I den forbindelse har Kombit oplyst, at Netcompany i ÆA 43 pkt. 3.5 har anført:
”Udarbejdelse og eksekvering af test cases relateret til denne ændringsanmodning vil blive udført ifm. de releases som de forskellige dele vil bliver leveret i. Der vil blive udført funktionel test og regressionstest fokuseret omkring de områder, hvor der er lavet funktionelle ændringer”.
Efter Kombits opfattelse er det Netcompany, der er nærmest til at afgøre scope for den funktionelle test og regressionstest, da det er Netcompany, der har viden om, hvor der er sket ændringer i koden foranlediget af ÆA 43. I ÆA 43 har Netcompany vurderet, at da der er tale om udvidelse af login og lokal IdP-håndteringen – en komplekst model som kræver særlig setup til test, er estimeringsprofilen ’Ekstra test’ anvendt. Kombit har oplyst, at det fremgår af ÆA 43, at 118 timer er afsat til ”test” og 31 timer til ”ekstra test – API versionering”. Ved godkendelse af ændringsanmodningen havde Kombit derfor opfattelsen af, at Netcompany havde testet alle dele af loginløsningerne, hvor der var foretaget funktionelle ændringer. I den forbindelse har Kombit har anført, at Kombit ikke specifikt havde godkendt, at det udelukkende var IdP-løsningen, der blev testet.
Kombit har anført, at Netcompany burde være nærmest til at sikre, at der udføres tilstrækkeligt tests, når Netcompany foretager ændringer i løsningen, da Netcompany er nærmest til at vurdere, hvordan de ændringer der gennemføres af deres udviklere, vil påvirke andre dele af Aula-løsningen.
3. Begrundelse for Datatilsynets afgørelse
Datatilsynet lægger på baggrund af det til sagen oplyste til grund, at det fra den 24. november 2019 til den 20. december 2019 var muligt for en bruger at tilgå en anden brugers sikre filer i Aula, hvis vedkommende ikke var logget ud af computeren.
Datatilsynet lægger på den baggrund til grund, at der er sket en uautoriseret adgang til personoplysninger, hvorfor tilsynet finder, at der er sket et brud på persondatasikkerheden, jf. databeskyttelsesforordningens artikel 4, nr. 12.
Datatilsynet lægger endvidere til grund, at fejlen opstod på grund af en programmeringsfejl i release 1.1.5, som vedrørte IdP-loginløsningen, der satte brugerautentifikation i forbindelse med ”step-up” ud af spil på UNI-loginløsningen, og at der var tale om en menneskelig fejl.
Det følger af databeskyttelsesforordningens artikel 32, stk. 1, at den dataansvarlige og databehandleren skal træffe passende tekniske og organisatoriske foranstaltninger for at sikre et sikkerhedsniveau, der passer til de risici, der er ved den dataansvarliges behandlinger af personoplysninger.
Der påhviler således den dataansvarlige og databehandleren en pligt til at identificere de risici, den dataansvarliges behandling udgør for de registrerede og til at sikre, at der indføres passende sikkerhedsforanstaltninger, der beskytter de registrerede mod disse risici.
Det er Datatilsynets opfattelse, at kravet jf. artikel 32 om passende sikkerhed normalt vil indebære, at alle sandsynlige fejlscenarier bør testes i forbindelse med udviklingen og ændring af software, hvor der behandles personoplysninger.
Datatilsynet finder, at Kombit – ved ikke at have sikret, at der blev foretaget tilstrækkelig test af Aula, herunder i UNI-loginløsningen, i forbindelse med ændringen af koden i Aula – ikke har truffet passende organisatoriske og tekniske foranstaltninger for at sikre et sikkerhedsniveau, der passer til de risici, der er ved Kombits behandling af personoplysninger, jf. databeskyttelsesforordningens artikel 32, stk. 1.
Datatilsynet har herved lagt vægt på, at en fejl i udviklingen af løsningen medførte, at der ikke var korrekt styring af adgangsrettigheder i Aula.
Datatilsynet har endvidere lagt vægt på, at Netcompany og Kombit ikke kunne blive enige om, hvilke tests der kunne forventes udført i forbindelse med udviklingsprojektet, og at samme parter ikke ses at være enige om, hvorvidt Netcompany agerede som underdatabehandler eller ej, hvilket kan føre til mangler i behandlingssikkerheden. Det er Datatilsynets opfattelse, at det i instruksen fra den dataansvarlige, skal stå klart hvorledes, en sådan uenighed skal håndteres. Det er endvidere Datatilsynets opfattelse, at ingen underdatabehandler, på egen hånd kan træffe beslutninger om konkrete forhold, omkring hvilken sikkerhed der er fornøden, når de ændringer der skal udføres, reelt berører behandlinger, der alene sker under den dataansvarliges ansvar og instruks, og dette ikke entydigt kan udledes af den dataansvarliges instruks til databehandleren.
Efter en gennemgang af sagen finder Datatilsynet, at der er grundlag for at udtale alvorlig kritik af, at Kombits behandling af personoplysninger – som databehandler – ikke er sket i overensstemmelse med reglerne i databeskyttelsesforordningens artikel 32, stk. 1.
I forhold til valget af sanktion har Datatilsynet som skærpende omstændigheder lagt vægt på:
- At omfanget af bruddet ikke har kunnet afdækkes, men alene i Gentofte Kommune var der ca. 1.500 personer, hvis adgang kunne misbruges under de rette omstændigheder.
- At de berørte oplysninger kan være beskyttelsesværdige oplysninger om mange mindreårige personer. I Gentofte Kommune alene kunne de vedrøre flere tusinde, uden at det kunne afdækkes nærmere.
- At der ikke synes at være klarhed over ansvarsfordelingen mellem Kombit og Netcompany.
Som formildende omstændigheder har Datatilsynet lagt vægt på:
- At der er tale om begrænset adgang for personer, der normalt har adgang til samme type oplysninger.
- At fejlen alene kunne udnyttes i kombination med, at en bruger ikke beskyttede sit login.
[1] Europa-Parlamentets og Rådets forordning (EU) 2016/679 af 27. april 2016 om beskyttelse af fysiske personer i forbindelse med behandling af personoplysninger og om fri udveksling af sådanne oplysninger og om ophævelse af direktiv 95/46/EF (generel forordning om databeskyttelse).