Københavns Universitet

600 KU-ansatte har haft ulovlig adgang til 13.600 personers løn-data og CPR-numre

Via Version2 - , indsendt af arne_v

600 ansatte på Københavns Universitet har i en periode haft ulovlig adgang til 13.600 personers løn-statistik, der inkluderede privatadresser, eksamenskarakterer og CPR-numre.

Det viser en omfattende datascanning, som universitetet selv har afsluttet efter to måneder – sat i gang som forberedelse til GDPR.

IT-afdelingen har altså scannet alle databaser på KU efter CPR-numre, adresser og telefonnumre, og universitetet fandt ud af, at de har flere drev liggende rundt omkring, end de troede.

Lønstatistikken med de 13.600 personer er således ikke det eneste eksempel på datalæk fundet efter scanningen, men i alle tilfælde er det kun ansatte, der har haft adgang til de mange data.

Der har ikke været nogen form for logning der, hvor lønstatistikken lå, og derfor ved man ikke, om de mange data er blevet misbrugt, eller hvor længe de har ligget tilgængelige.

I de fleste tilfælde er de mange data endt på de forskellige drev, fordi man har delt dem skødesløst med andre medarbejdere – og flere medarbejdere end nødvendigt i tilfældet med lønstatistikken.

Københavns Universitet har nu lavet nye processer til at kontrollere de mange data, som bliver delt rundt blandt universitets mange medarbejdere – herunder dedikerede drev med logning.





Gå til bund
Gravatar

#1 kblood 28. maj 2018 20:01

Med alt dette GDPR lovgivning vi hører om for tiden... er CPR nummer som vi bruger til så utroligt mange ting egentlig ikke i modstrid med GDPR?
Gravatar

#2 arne_v 28. maj 2018 21:32

#1

Hvilken del af GDPR skulle CPR numre være i modstrid med?

Kravet om at der skal være et lovligt formål med at indsamle og opbevare data?

Kravet om at personer kan få oplyst hvilke data der gemmes?

Kravet om at personer kan få slettet data hvis de ikke længere er nødvendige?

Kravet om at der skal være styr på hvem der har adgang til data og hvad data bliver brugt til?

Kravet om at personer skal informeres hvis data bliver stjålet?

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#3 kblood 29. maj 2018 23:44

#2:
https://iapp.org/news/a/looking-to-comply-with-gdp...

CPR er ikke anonymt. Derfor er det ikke så godt at det bruges så bredt som det gør, specielt når det er så låst som det er til ens person. Vores CPR numre er sluppet ud så mange gange efterhånden, så hjælper det ikke at det bruges som brugernavn i så mange systemer.

Så ja, CPR er omfanget af GDPR, ved ikke hvorfor du ville tro det ikke skulle være. Man kan jo selvfølgelig stadigt bruge CPR, men ligesom man ikke må have f.eks. en kundes navn eller endda en medarbejdes navn eller initialer i sine tabeller generelt, så må man heller ikke have CPR numre der, den slags skal samles centralt.

Der er jo en grund til at det er et problem at de ansatte har haft adgang til disse data, selvom de rent faktisk var ansatte.
Gravatar

#4 arne_v 30. maj 2018 00:29

#2

Anonymization og pseudonymisation er to gode teknikker til GDPR compliance.

Og brug af CPR nummer udelukker begge.

Men hverken anonymization eller pseudonymisation er krav i GDPR. Bare muligheder.

Så jeg kan stadig ikke se hvorfor brug af CPR numre skulle være i modstrid med GDPR.

kblood (3) skrev:

CPR er ikke anonymt. Derfor er det ikke så godt at det bruges så bredt som det gør, specielt når det er så låst som det er til ens person. Vores CPR numre er sluppet ud så mange gange efterhånden, så hjælper det ikke at det bruges som brugernavn i så mange systemer.


Diskuterer vi om det er godt eller om det er en overtrædelse af GDPR?

kblood (3) skrev:

Så ja, CPR er omfanget af GDPR, ved ikke hvorfor du ville tro det ikke skulle være.


Det tror jeg skam heller ikke.

Jeg tror at CPR kan bruges uden at være i modstrid med GDPR.

Men CPR er naturligvis underlagt GDPR.

kblood (3) skrev:

Man kan jo selvfølgelig stadigt bruge CPR, men ligesom man ikke må have f.eks. en kundes navn eller endda en medarbejdes navn eller initialer i sine tabeller generelt, så må man heller ikke have CPR numre der, den slags skal samles centralt.


Der kan være mange gode grunde herunder relations-database normalisering til at bruge surrogat nøgler i tabeller.

Men jeg har ikke hørt at det skulle være et krav i GDPR.

Hvor kommer det fra?

EDIT: Udover det selvindlysende, at hvis man vælger pseudonymisation som teknik så er man nødt til at bruge surrogat nøgler.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#5 kblood 31. maj 2018 05:42

#4 Ja, jeg vil helt klart mene at der burde bruges surrogat nøgler, så CPR numre slet ikke var i deres system, men blev checket op imod et mere centralt system. Grunden til at man har det som en "god teknik" er jo så netop også fordi hvis man ikke bruger denne teknik er GDPR ikke til at overholde, for det er et krav ikke at holde på personlig brugerdata i mere end 5 år hvis det ikke er en aktiv kunder, aktiv partner og lignende, og det betyder derfor at alt med CPR på ville skulle slettes. Det kan de så måske også nu, men det ser nu lidt ud til at de har nogle afhængigheder imellem tabeller der kunne gøre det til et problem.
Gravatar

#6 arne_v 31. maj 2018 14:24

#5

Der kan være mange gode grunde.

Men jeg kan ikke se det som krævet af GDPR.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#7 kblood 31. maj 2018 20:02

#6 Som jeg skrev, er det nok lidt et indirekte krav, for hvis de ikke gør det, vil man i praksis ikke rigtigt kunne overholde det. Den slags som ikke er godt at finde ud af når først man har muret sig inde i dårlig kode og database skik.
Gravatar

#8 CBM 4. jun. 2018 17:45

UPS! Oh well
https://fricomputer.dk https://retrohardwareheaven.blogspot.com/ #ComeToTheDuckSide www.duckduckgo.com, AMD + ASUS = kvalitet! #BringBackTheKeyboard #JackOn SailfishOS rocks! 010000100110100101101110011000010111001001111001
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login