Statsansatte har fået lækket navne, cpr-numre og funktioner på internettet

En liste med 590 af Kriminalforsorgens ansatte og tidligere ansatte var tilgængelig fra 20. december 2017 til 8. januar 2018.

I 20 dage hen over årsskiftet lå hundredvis af statsansattes cpr-numre, navne, funktioner og ansættelsessted frit tilgængeligt på internettet på en testside, som it-leverandøren Miracle arbejdede med.

Det skriver Politiken.

Datalækket blev opdaget, da en ansat i Kriminalforsorgen på en tilfældig søndag googlede sit eget navn og fik rækken af fortrolige oplysninger frem på skærmen.

Kriminalforsorgen, Udenrigsministeriet og Socialstyrelsen bekræfter lækket over for dagbladet, men det er uvist hvor mange der er ramt af lækket.

»Det er fuldkommen absurd, at en så sikkerhedsfikseret institution som vores ikke har styr på, at følsomme data kan slippe ud via en it-leverandør. Det er menneskeligt at fejle, men det her kan have så uoverskuelige konsekvenser for den enkelte, at det bare ikke må ske«, siger Kim Østerbye, formand i Fængselsforbundet, til Politiken.

PET har vurderet, at de fortrolige data ikke er kommet til uvedkommendes kendskab.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Sune Marcher

Full disclosure: jeg arbejder for Miracle, og har ikke noget med hverken den berørte kunde eller systemer at gøre.

Før folk begynder at spekulere i hvordan den slags ting kan ske: https://miracle.dk/adgang-kundeinformation-via-sikkerhedshul-miracles-te... - den blev publiceret 11. Januar, og er blevet skubbet frem i dag, så den ligger forrest på vores hjemmeside.

Jeg kan ikke se Politikens artikel, da den er bag en paywall... men har på fornemmelsen de ikke har ovennævnte link.

  • 8
  • 0
René Nielsen

Hvor ville jeg ønske at vore politikkere forstår at der er enormt meget sikkerhed i ikke at have den slags oplysninger ”på nettet”.

Det offentlige burde kører på et lukket netværk, med egne fast linjer og kun kunne tilgås via godkendte enheder.

Som borger skulle man logge på via en tynd klient a la Citrix som firewallmæssigt overvåges af f.eks. NCC eller en anden kompetent statsenhed.

Alt kan hackes – jeg ved det godt, men ovenstående udelukker kolossalt mange menneskelige fejl som dagligt rulles op i medierne, ligesom det i betydelig omfang øger ”detection risk” overfor hackere.

  • 3
  • 1
Bjarne Nielsen

Hvor ville jeg ønske at vore politikkere forstår at der er enormt meget sikkerhed i ikke at have den slags oplysninger ”på nettet”.

Der er enormt meget sikkerhed i ikke at have den slags oplysninger. Punktum. Vi kunne f.eks. kalde det "data-minimering".

Når jeg læser Miracles redegørelse (tak, Sune), så er "fadæsen", at et system, som slet ikke burde indeholde den slags oplysninger, ved en fejl kom på nettet.

Vi kan så have en lang diskussion om, hvorfor det system kom på nettet, og hvordan vi forhindrer det fremadrettet. Men fadæsen er IMHO at systemet kom til at indeholde den slags oplysninger i første omgang.

Ja, det kan være utroligt praktisk, at man kan dele ud af fortrolige oplysninger med samarbejdspartnere og leverandører. Og man kan så gemme sig bag tavshedserklæringer og revisionserklæringer, men faktum er, at man så sætter andre hensyn (og min påstand er, at det som regel i bund og grund er et spørgsmål om bekvemmelighed) over sikkerhed.

  • 13
  • 0
Simon Mikkelsen

Når jeg læser Miracles redegørelse (tak, Sune), så er "fadæsen", at et system, som slet ikke burde indeholde den slags oplysninger, ved en fejl kom på nettet.

Jeg læser det mest, som de har et system til sagshåndtering mm, som ikke må indeholde personfølsomme oplysninger. Men fordi der ikke er en sikker vej at sende disse, når det er nødvendigt, bliver de alligevel lagt i systemet.

At et forkert projekt ved et uheld bliver gjort offentligt tilgængeligt, er en træls sag, men systemer med følsomme og ikke-følsomme oplysninger burde ikke være blandet sådan sammen. Og det var jo heller ikke intentionen.

Det er en klassiker, at oplysninger slipper ud, fordi folk ikke har et sted at gøre af personfølsomme oplysninger, og det er alt for bøvlet at få det.

  • 6
  • 0
Sune Marcher

Når jeg læser Miracles redegørelse (tak, Sune), så er "fadæsen", at et system, som slet ikke burde indeholde den slags oplysninger, ved en fejl kom på nettet.


Jeg ved ikke om systemet ikke burde være på nettet - vi arbejder nogle gange med integrationer mod JIRA, så jeg tænker det giver fin mening at et testsystem kan nås udefra.

Men det naturligvis ikke ske, heller ikke for et testsystem, at data bliver eksponeret til nettet uden auth!

Jeg ved ikke præcist hvad der gik galt (og hvis jeg gjorde, ville jeg ikke udtale mig offentligt om kunder) - så følgende er personlige, generelle holdninger:

Når vi som udviklere laver systemer, så tænk lidt ekstra brugervenlighed ind. Jeg ved ikke om det havde hjulpet i vores situation, men ting som "du er ved at ændre rettigheder for en gruppe med 100+ medlemmer" eller "du er ved at gøre 100+ sider offentligt tilgængelige" er advarsler jeg personligt godt ville have i bruger/rettighedshåndtering.

Sørg for at opdrage både kollegaer og kunder til at behandle personfølsomme data forsvarligt. Kæden er som bekendt ikke stærkere end det svageste led.

Hvis du skal overføre prod-data til test-systemer, så overvej kraftigt hvad behovene er, og sørg for at få scrubbet personfølsomme oplysninger. (Igen: jeg ved ikke om det i vores tilfælde har været prod->testdata der gik galt, det er en generel betragning).

Jeg har i anden sammenhæng måtte eskalere en sag hos en kunde (og modtage en ordentlig sviner fra en seniorudvikler hos dem om "ikke at være samarbejdsvillig") fordi jeg påpegede at en feature til frit at migrere data på tværs prod og test-systemer ikke var en super god idé, og at de nødvendige data allerede var på test... men selvom "vi er jo bare er kokke, for fa'en" har vi ansvar der rækker udover blindt at følge en kravspec.

  • 5
  • 0
Jesper Nielsen

Så Google og den ansatte i kriminalforsorgen er ikke uvedkommende?

Jeg tænker, at PET forholder sig til Sikkerhedscirkulæret, når de skal afgøre, om der er lækket fortrolige oplysninger. I Sikkerhedscirkulæret står der, at klassificeringen FORTROLIGT:

[...] skal anvendes om informationer, hvis videregivelse uden dertil indhentet bemyndigelse ville kunne forvolde Danmark eller landene i NATO eller EU skade.

Og det er der ikke umiddelbart tale om i dette tilfælde — selvom det er et drønærgerligt læk.

  • 1
  • 0
Peter Stricker

Jeg tænker, at PET forholder sig til Sikkerhedscirkulæret, når de skal afgøre, om der er lækket fortrolige oplysninger.


Det kunne være en rimelig forklaring på PET's konklusion. Men det rejser så spørgsmålet, om PET er de rette til at konkludere.

Fra artiklen:

fik rækken af fortrolige oplysninger frem

Når ansattes identitet kobles med funktion og ansættelsessted, så kan det da ikke afvises at det kan forvolde skade.

  • 2
  • 0
Sune Marcher

Jeg tænker, at PET forholder sig til Sikkerhedscirkulæret, når de skal afgøre, om der er lækket fortrolige oplysninger. I Sikkerhedscirkulæret står der, at klassificeringen FORTROLIGT:


Det kunne være interessant at vide om PET har haft snakket med Google, eller de bare har lavet FORTROLIGT-vurderingen, som du nævner.

Men det er der nok ikke nogen af os almindelige dødelige, der får svar på :)

  • 1
  • 0
Finn Aarup Nielsen

1) Hvis det ligger i Google's cache, så kan jeg ikke se hvordan folk fra Danmark kan afgøre om data er "kommet til uvedkommendes kendskab". Udfra Google's snippet kan man jo læse lidt.

2) Som jeg forstår på processerne hos Wikimedia, skal der to til at gennemfører ændring (udover en continuous integration Jenkins bot): Programmøren der committer og en reviewer via Gerrit-værktøjet. Så to skal dumme sig, - ikke at det er umuligt. Det er muligt at små udviklingshuse ikke kan gøre det.

3) Hvis kunden har adgang til bug-tracking-systemet Jira (som Miracles skriver), kan det vel være meget svært at undgå at en kunden oploader følsom data. Man kan måske have CPR regexp filter, eller en (anden) form for moderator-funktion? Det kræver også en pædagogisk opdragelse af kunden.

  • 0
  • 0
Benny Lyne Amorsen

Hvis det ligger i Google's cache, så kan jeg ikke se hvordan folk fra Danmark kan afgøre om data er "kommet til uvedkommendes kendskab". Udfra Google's snippet kan man jo læse lidt.


Man kan ikke afgøre det med sikkerhed, men ville de fleste ikke klikke på linket i Google hvis de så det? Eller har de tænkt "wow, det er godt nok superfedt og farligt det her, vi sørger lige for at hente cachen men ikke selve siden, for så kan vi spores!"

Måske undervurderer jeg hvor kløgtige danske kriminelle er...

  • 0
  • 0
Sune Marcher

Man kan ikke afgøre det med sikkerhed, men ville de fleste ikke klikke på linket i Google hvis de så det? Eller har de tænkt "wow, det er godt nok superfedt og farligt det her, vi sørger lige for at hente cachen men ikke selve siden, for så kan vi spores!"


Jeg tænker at en almindelig person, der tilfældigivs fandt den slags i en Google-søgning, nok ikke ville tænke nærmere over det, og klikke på linket. En person der målrettet søgte ville måske klikke på cache-linket - eller være ligeglad, fordi vedkommende var via TOR eller et par "lånte" proxyer.

Hm, hvor meget cacher Google egentligt? Jeg vil umiddelbart gætte på at personoplysningerne har været i en .csv/whatever attached til en Jira ticket.

  • 0
  • 0
Log ind eller Opret konto for at kommentere