Ballerup: KMD overtrådte dataaftale - flyttede persondata til hacket udviklingsserver

Illustration: PathDoc / BigStock
KMD har i strid med databehandleraftale flyttet persondata fra kommunens system til KMD's udviklingsplatform, som blev hacket. Det omfatter ifølge KMD foreløbigt 25 personnumre for borgere i kommunen.

KMD har overtrådt sin databehandleraftale med Ballerup Kommune ved at it-selskabet på egen hånd har kopieret data fra kommunens system til KMD’s udviklingsserver. Det kommer nu frem i forbindelse med sagen om hackingen af et KMD-system, som Version2 kunne afsløre tidligere på ugen.

Læs også: KMD anmeldt til Datatilsynet efter landsdækkende server-hack

Den ulovlige dataoverflytning fremgår af Ballerups anmeldelse til Datatilsynet, som Version2 har fået aktindsigt i:

»Såvidt oplyst fra KMD A/S, har KMD i strid med databehandleraftalen flyttet persondata fra kommunens anvendelse af KMD Nexus' til KMD's udviklingsplatform. Der har siden være indbrud på KMD's udviklingsplatform, hvorfor der er risiko for at disse persondata er lækket. Det omfatter ifølge KMD foreløbigt 25 personnumre for borgere i Ballerup kommune.«

Hackingen af KMD's Nexus-system har medført brud på persondatasikkerheden i form af lækkede cpr-numre - hvilket altså kunne ske fordi der lå persondata på udviklingsplatformen. Det vides på nuværende tidspunkt ikke om der er sket offentliggørelse, ændring , tilintetgørelse eller tab af personoplysninger.

46 anmeldelser af databrud

Ballerup er langt fra alene om at have anmeldt lækket til Datatilsynet. Tilsynet har tidligere oplyst til Version2, at d. 9. maj 2019 har man journaliseret 46 anmeldelser om brud på persondatasikkerheden i forbindelse med en sikkerhedshændelse vedrørende KMD Nexus. Flere anmeldelser kan komme til senere.

Ballerup Kommune modtog besked fra KMD om bruddet d. 26. april. KMD oplyste endvidere at sikkerheden var genoprettet. Hændelsens varighed er endnu ikke oplyst fra KMD.

Ifølge anmeldelsen til Datatilsynet vides det ikke, om der har været interesse for persondata, idet bruddet har bestået i at mine bitcoins på en udviklingsserver i KMDs miljø.

Men persondata har været tilgængelige under bitcoin mining-indbruddet på udviklingsserveren.

KMD har oplyst til kommunen, at firmaet har fjernet de uautoriserede adgange. Som en ekstra sikkerhedsforanstaltning har Ballerup kommune efterfølgende ændret adgangskoder til driftsmiljøet.

Kommunen har taget kontakt til KMD og bedt firmaet dokumentere overholdelse af databehandleraftalen.

KMD har ingen kommentarer til de nye oplysninger.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Christian Münster
  • Jo flere love, jo flere lov brud

Hvordan skal jeg teste min kode op i mod rigtig data, hvis ikke jeg må bruge rigtig data?

Vi kopier PROD data ned i UAT og QA flere gange om året.
Samtidig overskiver vi kunders email adresser i de to miljøer.
Men hvis vi overskrev andet, ville mange af vores integrations tests da miste deres værdi.

Hvis de alle hedder Test Testsen på testgade nr. 1, så får vi jo ikke testet de hundehoveder der bruger & tegn i deres titel, som vores parser måske ikke lige har taget hånd om. (endnu)
Eller en anden dum ting, vi først finder i PROD, når vi ruller ud.

ps. Det er fedt han lige tilføjer de ændrede adgangskoden til miljøerne, for at øge sikkerheden.
Fordi; jo tierer man ændrer adgangskode, jo mere sikker er man.

  • 0
  • 8
Claus Bobjerg Juul

Hvis de alle hedder Test Testsen på testgade nr. 1, så får vi jo ikke testet de hundehoveder der bruger & tegn i deres titel, som vores parser måske ikke lige har taget hånd om. (endnu)

Få kunden til at oprette et preprod miljø (eller hvad du nu vil kalde det), hvor driften implementere den ændring/test du ønsker afviklet. Ja der skal være noget debug/logging slået til så den fejl der måtte komme kan blive rapporteret til dig.

  • 2
  • 0
Henrik Størner

Det er min erfaring at testsystemer er et mega stort problem når det handler om persondata.

Det er muligt at anonymisere data, når man flytter produktionsdata over til et testmiljø, men det er besværligt. Og så springer man tit over hvor gærdet er for lavt og tager en rå kopi. Men så skal man pinedød have eksakt samme adgangsstyring, firewalls, logning og alle mulige andre sikkerhedsforanstaltninger på sit testsystem. Og det har man ofte ikke, fordi det er besværligt.

Udviklere og testere vil ikke have besvær. Men hvis et system indeholder produktionsdata så skal det håndteres som et produktionssystem. Og det er tydeligvis ikke sket her.

  • 7
  • 0
Kim Hjortholm

At bruge produktionsdata med personhenførbare oplysninger til test er en gammel uskik i IT som GDPR heldigvis har sat en stopper for.

Som udvikler/tester kan jeg sagtens følge at man synes det er nemmere med kopi af produktion (er selv testmgr), men som kunde eller borger er jeg ikke interesseret i at alle mulige tilfældige personer har adgang til at kigge på min personlige data og normalt er der heller ikke givet tilsagn til at data må bruges til test formål.

Et element af testdesign er at forholdes sig til hvordan man håndterer de personfølsomme data hvis testdata kopieres fra produktion til test

Der findes metoder og værktøjer til anonymisering af testdata, men det koster penge og tid så er noget man skal vænne sig at disponere med at det indgår.

  • 3
  • 0
Bjarne Nielsen

Der findes metoder og værktøjer til anonymisering af testdata, ...

Kan du give nogle pointere?

Jeg er særligt interesseret i hvilke "sikkerhedsgarantier", som de kan stille (og på hvilken baggrund de stiller dem), og i særlig grad, hvordan de håndterer den iboende modstrid imellem at jo sværere reidentifikation er, jo mindre interessant er data.

Er der f.eks. tale om omkodning af udvalgte identifikatorer (PII), for så taler vi næppe om reelt anonymitet, men snarere om pseudonymitet? Er der tale om, at man helt fjerner PII, for selv der er der stor risiko for reidentifikation.

Jeg mangler kort sagt stadig at se et eksempel på, hvordan man har formået at bringe risikoen for reidentifikation ned på et acceptabelt niveau uden at datasættet samtidigt ville blive betragtet som værende værdiløst; jeg kender til gengæld adskillige eksempler på, at man har påstået det, men at man var stoppet alt for tidligt i processen.

En efterhånden klassisk artikel, som illustrerer udfordringerne, er denne:
https://science.sciencemag.org/content/347/6221/536.full

Her viser man, at der er betydeligt potentiale for reidentifikation i et "anonymiseret" datasæt over kreditkortkøb (fire tilfældigt valgte tid/sted for en person var nok til unikt at udpege 90% af individerne, og dermed afsløre alle deres køb).

Der er klart, jo mere man ved, jo bedre er man stillet, og at kende ca. beløbet øger sandsynligheden for reidentifikation - men allerede ved bare to tid/sted koordinater (uden beløb), så er 40% af individerne i datasættet unikt udpeget.

Der kigges også på, hvad der sker, hvis nøjagtigheden af tid/sted falder, og ja, det gør det sværere, men selv ved unøjagtige koordinater er det muligt at udpege betydende andele af individerne i datasættet.

Dette studie er ikke enestående- en anden klassiker er Netflix/IMDB sagen. Australien er også kommet i problemer med "anonyme" sundhedsdata.

Og lige nu sidder jeg og læser en artikel om en forsker, som sagsøgte staten Californien for at få udleveret "anonymiserede" datasæt over advokater med møderet til hans forskning - selvom forskeren (med hjælp fra såkaldte "anonymiseringseksperter") havde foreslået fire forskellige "anonymiseringsmetoder", som tog direkte udgangspunkt i kendskab til det konkrete domæne, og havde sat parametrene usædvanligt højt (f.eks. binstørrelse på 11), så viser artiklen at det var utilstrækkeligt. Ironisk nok var en af kilderne til alment tilgængelige eksterne data, som de brugte til reidentifikation, forskerens egen tidligere offentliggjorde forskning.

Kort sagt, bare fordi at man siger at det er anonymt, betyder ikke at det faktisk er det.

Og derfor tror jeg meget mere på pre-prod miljøer og trinvis udrulning, end jeg tror på "anonymiserede" produktionsdata i udviklingsmiljøerne.

  • 2
  • 0
Christian Münster

Hørt Bjarne.

Det er så nemt at opsætte regler og gemme sig bag en lov - men det er teknikerne der typisk skal rode trådene ud, fordi man ikke har tænkt konsekvensen af lovgivningen igennem.

Test data der ikke afgiver et realistisk billede af virkeligheden, er ikke realistisk data og derfor ubrugelig i selv samme test.

  • 0
  • 3
Per Jørgensen

Giver slet ikke mening i min verden - Så må de jo ansætte en skoledreng tiul at oprette fiktive personer i deres TEST database.

Tja vi tester da absaolut også på vores udviklingsplatforme - Men det er med en testdatabase og ikke en produktionsdatabase - med reelle data.

Kan da slet ikke se hvorfor det overhovedet er lovligt at flytte de data over til et udviklingsmiljø? Er da abolut klar over det vil koste nogle timer - men efter det er oprettet en gang behøves dette ikke mere. Og hvis deres test består af 25 personer - giver det sgu slet ikke ,mening at det er nødvendigt at kopiere LIVE data

  • 0
  • 0
Klavs Klavsen

IMHO - så BØR det være således at man til udvikling og test, har designet sit system, så man kan genere alle de data typer man har behov for (inkl. hvad man tror kan fejle osv. osv. - istedet for at stole på at "virkeligheden" - er repræsentativ for alle fejl).

Derudover, så kan man have et staging system - hvor man snapshot'er produktionsdata til - og kører opgraderingen der først og tester på faktiske prod data (som de så ud ved snapshot tid).

Staging setup'et skal selvfølgelig have samme beskyttelse som prod - så man ikke bare forbindet til det, fra de andre miljøer.

  • 0
  • 0
Per Gøtterup

Hvorfor skal man bruge et hastigt opsat (læs: fyldt med sikkerhedshuller) system til test?

Jeg plejer at kunne få gennemtrumfet et miljø med test, staging og produktion i samme sikre opsætning. Serverne er principielt sat helt ens op og er derfor lige sikre, hvilket de også skal være for at være så identiske som muligt med produktion. Staging skal være 100% identisk med produktion så det rent faktisk kan agere stand-in for produktion hvis det skal være nødvendigt. Testmiljøet er derfor lige så sikkert som produktion og kan derfor fint indeholde rigtige data.

  • 1
  • 0
Hans Nielsen

Staging skal være 100% identisk med produktion så det rent faktisk kan agere stand-in for produktion hvis det skal være nødvendigt


Rigtig set, så har man samtidigt en backup, hvor man kan flytte produktion over på. Eller man kan lave fall back/fall over.

Men grunden til at dette ikke sker ved KMD, er sikkert at det det tager tid (dyrt), kræver mandskab og indsigt (dyrt) og er besværligt (dyrt).

Også længe at GDPR bøder ikke koster på bundlinjen, så kan det ikke betale sig. Det koster sikkert også bonuser til chefer, også længe at sikkerhed ikke giver bonuser, så sker det ikke noget.

Hvis GDPR indholdt mulighed for fængselstraf, og meget store personlige børder, til ledelse og ansvarlige, i grove eller gentagelse tilfælde. Så ville vi ikke se sådan noget, som det her.

  • 0
  • 0
Klavs Klavsen

Testmiljøet er derfor lige så sikkert som produktion og kan derfor fint indeholde rigtige data.

Det er altså ikke korrekt. Det drejer sig AFAIK primært om HVEM der har adgang til data (seperation of duties) - og udviklere skal IKKE have adgang til rigtig personfølsom data - men de har behov for (til test formål) at kunne en masse ting i test som ville give dem adgang til PII data, som de ikke må have adgang til - såfremt test systemet indeholdt rigtig PII data.

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