En alvorlig sikkerhedshændelse har gjort en borgers fuldmagt tilgængelig for uvedkommende, oplyser Digitaliseringsstyrelsen i en pressemeddelelse.
Fra den 24. til den 29. januar kunne 1.400 borgere se en fremmed persons fuldmagt, hvis de havde logget på sundhed.dk. Det var der 14 personer, der gjorde.
En af de 14 borgere, som så den, kontaktede sundhed.dk, som igen kontaktede Digitaliseringsstyrelsen. To timer efter var fuldmagten gemt væk, sikkerhedshullet var lukket og den berørte var kontaktet.
»Det er meget uheldigt at sådan noget kunne ske, for den borger som fik kompromitteret sine oplysninger, og for de 14 personer, som helt ufrivilligt så en fremmeds personlige informationer,« siger Adam Lebech, vicedirektør i Digitaliseringsstyrelsen.
»Vi kontaktede så hurtigt som muligt alle de berørte og beklagede fejlen, for det var ikke betryggende for systemets sikkerhed. Desuden har vi underrettet Datatilsynet om fejlen,« fortæller han.
Samkørsel af systemer var skyld i fejl
Problemet skyldes delvist en fejl i fuldmagtsløsningen, Digital Fuldmagt, som er udviklet af NNIT, hvor det har været muligt at oprette en fuldmagt uden at indtaste cpr-nummer. Det var netop det, en borger havde gjort den 24. januar, da han oprettede fuldmagt til en pårørende på Sundhed.dk. Det er den ene del af problemet.
Den anden del ligger i samkøringen på tværs af de forskellige it-systemer, hvor Digitaliseringsstyrelsen stadig arbejder på afdække de præcise omstændigheder. I mindst ét af de systemer, har det været muligt at registrere sig uden at indtaste et cpr-nummer.
Tilsammen betyder de to designfejl, at alle brugere, der har oprettet sig uden cpr-nummer, har fået adgang til en fuldmagt, der var oprettet uden et cpr-nummer.
»Det er sådan med samkøringer af forskellige systemer, at det kan være meget svært at forudse, hvad der kan gå galt, og der kan være meget uheldige sammenfald,« siger Adam Lebech
»Fejlen ved den ene leverandørs system kom ved samkøringen til at spille sammen med en anden leverandørs system, og så får man det her hul, som var ekstremt svært at forudse på forhånd,« forklarer han.
Digitaliseringsstyrelsen er stødt på endnu et eksempel, i forbindelse med en flytning, men i dette tilfælde blev materialet ikke set af nogen. Også dette er rapporteret til Datatilsynet, og de berørte er underrettede.
Tomt CPR var en uhensigtsmæssig opsætning
Ud af de 1.400, der har haft mulig adgang til en fremmed persons fuldmagt, nåede 14 borgere, fra den 24. til den 29. januar, at logge på sundhed.dk og helt ufrivilligt, få adgang til en fuldmagt fra den uheldige borger. Den 29. blev han kontaktet af Digitaliseringsstyrelsen, som beklagede, at hans personfølsomme oplysninger var blevet delt.
»Vi er sikre på, at hullet er lukket, og at problemet ikke kan opstå igen. Det vi mangler at svare på er; hvordan kunne det overhovedet ske, at man kunne oprette en digital fuldmagt med et tomt cpr-nummer,« siger Adam Lebech
Digitaliseringsstyrelsen har fjernet alle registranter med tomt cpr-nummer, indført et tjek, så man ikke i fremtiden kan oprette sig under tomt cpr-nummer, og desuden kontaktet alle de berørte. De arbejder netop nu på en fuldstændig afklaring af, hvad der gik galt.
Opdateret klokken 12:40 med præciseringer.
Rimelig uklart hvor mange personer vi har med at gøre her.
Så er det 14 mennesker der potential har kunne se fuldmagten fra 1400 personer.
1400 borger har været oprettet med CPR = <null>.
Fuldmagten skulle vises for borgere med Cpr = <null>.
14 borgere med CPR = <null> har været logget ind i perioden.
1400 ville have kunnet se det, og 14 nåede faktisk at gøre det.
"»Det er sådan med samkøringer af forskellige systemer, at det kan være meget svært at forudse, hvad der kan gå galt, og der kan være meget uheldige sammenfald,« siger Adam Lebech"
"Fejlen ved den ene leverandørs system kom ved samkøringen til at spille sammen med en anden leverandørs system, og så får man det her hul, som var ekstremt svært at forudse på forhånd,« forklarer han."
Måske at man skal lade være med at tillade alle disse samkøringer? F.eks. i diverse forskningsprojekter, genomcenter osv - for her gælder vel det samme, at det kan være utroligt svært at forudse, hvad der kan gå galt?
Man kunne f.ex. gøre noget så fornuftigt, som at implementere GUI (website mm. - som oftest udgør langt den største del af koden - og dermed den største kilde til sikkerhedsproblemer) separat fra koden der implementerer forretningsfunktionalitet (såsom at levere samtykke data til websitet via f.ex. REST/SOAP interface) og så kunne forretningsfunktionalitet koden CHECKE at det pågældende NemID Token rent faktisk passede med det CPR nr. der var tilknyttet det pågældende samtykke.
Og når man adskiller GUI og forretningsfunktionalitet, ville man i en så simpel funktion som "opret samtykke" - aldrig tillade at man kunne oprette et samtykke for "null" cprnr.. Det bliver ligesom lidt tydeligere hvad man laver :)
Man kunne jo også validere hvad man får fra eksterne systemer sådan at man f.eks. tjekkede for man fik noget tilbage der ikke havde et CPR nr.?
Hvis man følger princippet med "Minimum trust, maximum trustworthiness" så kommer man langt.
… men tager man sit arbejde som it-udvikler alvorligt, så sker den slags altså ikke. Dette stinker langt væk af amatørarbejde og folk der ikke aner, hvad de har med at gøre. Det kan godt være de synes it-udvikling er "ekstremt svært", men så skal de måske finde sig et andet arbejde – de skal i hvert fald ikke arbejde med personfølsomme oplysninger.
Digitaliseringsstyrelsen har fjernet alle registranter med tomt cpr-nummer, indført et tjek, så man ikke i fremtiden kan oprette sig under tomt cpr-nummer
Og hvad så med dem der ikke har et CPR nummer? (der er nok ikke så mange, men der skal nok være nogen)
Der er fuld CPR validering, hvis der er et CPR.
Software har altid fejl.
Jeg plejer at sige, at hvis det tager en uge at lave en funktionalitet, så skal man påregne to uger til at teste og debugge den.
De sidste to uger glemmer de fleste når de estimerer en opgave.