Datatilsynet slår fast: Følsom backup skal slettes til tiden

Illustration: digitalista, BigStock
Der er ikke noget at spille om: Backup med persondata skal slettes, når tidsfristen udløber.

Datatilsynet har lagt nye retningslinjer for sletning af personoplysninger på bordet.

Der er ikke blot tale om almindeligt informationsmateriale, men en tekst af ‘normativ’ karakter, som Allan Frank, it-sikkerhedsspecialist og jurist i Datatilsynet, kalder det.

»Det er vores fortolkning af, hvad man skal gøre, når man sletter data.«

Det, der præciseres, er selve begrebet sletning:

Udgangspunkter for lovgivningen er, at man skal slette data, også i backup-systemer. Man skal slette alle de repræsentationer, man måtte have oplysningerne i, siger Allan Frank, som er it-sikkerhedsspecialist og jurist i Datatilsynet. Illustration: Københavns Universitet

»Vi prøver at forklare de dataansvarlige, hvad der skal til for at foretage en sletning af persondata på den rigtige måde – hvilke overvejelser, man skal igennem. Problemet er, hvordan man behandler slettefrister, hvordan man egentlig sletter oplysninger og følger op på det.«

Det er en af de ting, som Datatilsynet oplever, når de besøger virksomheder og organisationer.

»Man finder måske ud af, at en batch-kørsel ikke har slettet oplysninger. Hvis der ikke er efterfølgende kontrol, kan der ligge oplysninger.«

Udgangspunkter for lovgivningen er, at man skal slette data, også i backup-systemer. Man skal slette alle de repræsentationer, man måtte have oplysningerne i, som Allan Frank formulerer det.

Men det kan være svært at gøre, hvis backuppen eksempelvis er en krypteret og komprimeret database, med blandede oplysninger, og hvor man ikke nødvendigvis kan slette en enkeltstående post.

Krypter de følsomme poster i backuppen

Teamchef Hao Shen fra Nordeas platformshold har tidligere givet et bud på løsning af problematikken med personoplysninger, som skal slettes fra et system inden for en bestemt tidsfrist.

Det skete på Goto Copenhagen-konferencen, der blev afholdt i november måned.

Læs også: Sådan fik Nordea has på ‘Dødsstjernen’ med Kafka

Problemet er løst ude i den store verden, kunne han fortælle tilhørerne: Man krypterer blot posten, og når tidsperioden er udløbet, smides nøglen væk. Selv om posten stadig ligger et sted på en disk eller et bånd, kan den ikke læses.

Allan Frank kan godt se det fornuftige i fremgangsmåden, men pointerer, at en kryptering af oplysninger ikke er det samme som en sletning.

»Det er en teknisk måde at behandle sin backup på, så den ikke er læsbar. Det vil sige at man reelt efterfølgende kan anonymisere oplysningerne, hvis man benytter en godkendt krypteringsalgoritme.«

Men så skal man også være sikker på, at den måde, man gemmer og sletter krypteringsnøglen på, er en irreversibel proces:

»Man skal være sikker på, at man får ‘brændt’ nøglen, så indholdet aldrig kan genskabes. Men terminologisk er det altså ikke ‘sletning,’ men noget andet, man gør.«

Når nøglen smides væk, er der reelt set tale om en anonymisering – men så er man også uden for GDPR-forordningens rammer. Man gør det praktisk umuligt, med den gældende teknologi, at rekonstruere data.

Problematikken var i spil i november sidste år, da Version2 kunne afsløre, at Rigspolitiet gemmer oplysninger om bilers nummerplader i det såkaldte ANPG-system i 60 dage, hvor reglerne siger 30.

Læs også: Politiet har gemt ANPG-data i op til 60 dage - ANPG-lovbestemmelse siger max 30

»Du har backuppen, som understøtter driften, og så har du driften, som er det, der er omfattet af reglerne,« sagde Rigspolitiets databeskyttelseschef Christian Wiese Svanberg dengang til Version2.

Læs også: Rigspolitiet: ANPG-data skal slettes efter 30 dage - men ikke i backup-systemet

Andre regler for politiet

Men situationen er dog ikke helt den samme for politiet, som for virksomheder og offentlige myndigheder, hvor den slags forklaringer ikke er gangbar.

Allan Frank uddyber:

»Rigspolitiet hører under retshåndhævelsesdirektivet og retshåndhævelsesloven, som er et andet regelsæt, der dog minder en del om GDPR-forordningen, men hvor der større frihedsgrader, bl.a. til at lade være med at informere om de ting, man gør.«

For andre end ordensmagten lyder reglen ganske simpelt:

»Man må ikke have backup liggende, med mindre der er en god teknisk forklaring. Efter ‘retention-perioden’ skal backuppen slettes.«

Retention-perioden er den tid, hvor man af driftsmæssige hensyn kan få brug for at genindlæse backup’en.

»Backup skal kun opbevares så længe det er sagligt i forhold til at reetablere ens driftssetup efter et nedbrud.«

Mere præcist siger forordningen: Oplysningerne skal slettes så hurtigt som muligt, når formålet med oplysningerne ikke længere er til stede.

»Der er ingen ultimativ slette-frist. Men der kan være slette-frister i anden lovgivning, som for eksempel markedsføringslovens paragraf 10, arkivloven, og bogføringslovens bestemmelser om opbevaring af fakturaer i fem år, der medfører at sletning ikke kan ske før opbevaringskravet udløber.«

Samtykke kan trækkes tilbage

Virksomheder skal gøre kunder og brugere opmærksom på, hvilke regler der følges, på forhånd. Og hvis man ikke synes vilkårene er rimelige, kan man sige nej, fortæller Allan Frank.

»Hvis virksomheden lever op til reglerne om samtykke, er det en særlig type aftale mellem to parter.«

Hvis bruger- eller kundeaftalen er klar nok i forhold til formuleringen af vilkår, kan virksomheden opbevare data så længe, som de har gjort opmærksom på, med mindre samtykket tilbagekaldes.

Men udgangspunktet i forordningen er altså, at oplysninger skal slettes, når de ikke er nødvendige til de formål, de er indhentede til.

Men hvis jeg skriver det klart i min tjenestes betingelser, at jeg videreudnytter oplysninger efter kunden/brugeren har forladt tjenesten, er det så i orden?

»Efter omstændighederne kan det være det, men kun hvis man stadig har behandlingshjemmel, f.eks. hvis samtykket ikke kan betragtes som tilbagekaldt i og med man forlader tjenesten. Hvis man benytter samtykke som behandlingshjemmel, kan et samtykke trækkes tilbage ensidigt af den registrerede, og så skal al behandling baseret på samtykket ophøre og sletning skal ske,« slutter Allan Frank.

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

Det er godt med klare regler. Og ja backup og opbevaring er også databehandling punktum. Og det at kunne slette 'igennem' er altså security by design. Så det skal man altså kunne.
Der hvor jeg så mener at man må give lidt slack, er feks. at i en overgangsperiode at tillade feks kryptering og smid nøglen væk løsningen. igen så er Datatilsynets fortolkning af loven helt ny... (dermed ikke sagt at kyndige IT folk ikke sagde fra starten ikke godt så denne fortolkning komme) så lidt overgangs slack er nok nødvendig.

// Jesper

  • 6
  • 0
Bjarne Nielsen

Det er godt med klare regler.

Tja. Der er afsnit, som jeg gerne vil vifte under næsen på smålige systemejere, som valgte en meget bekvem form for (mis-)forståelse af reglerne, og det er er selvfølgelig altid rart at få ret på den måde.

Men på den anden side, så er der stadig rigeligt med "gummi" i formuleringerne. Et konkret eksempel er afsnittet som starter med flg. sætning:

Det er Datatilsynets opfattelse, at personoplysninger skal slettes fra backups mv., hvis dette er teknisk muligt.

...og med den formulering, så er der carte blanche til at fortsætte hidtidig praksis, især når dem, som man stiller krav til, også er dem, som skal afgøre, hvad som er "teknisk muligt".

Jeg tror ikke, at det i praksis kommer til at gøre den store forskel. Det er en efter min mening en papirtiger.

  • 8
  • 0
Jesper Frimann

...og med den formulering, så er der carte blanche til at fortsætte hidtidig praksis, især når dem, som man stiller krav til, også er dem, som skal afgøre, hvad som er "teknisk muligt".

Ikke helt..
Nu er jeg .. sådan blevet rimelig vant til at læse 'offentligt', og under punktet Procedure for sletning, skriver man følgende:

Som dataansvarlig bør man sikre sig, at der er taget stilling til hvilke procedurer, der skal følges, når personoplysninger skal slettes fra behandlingssystemerne. En sletteprocedure for et givent system, hvori der behandles personoplysninger, bør tage udgangspunkt i et flow, der følges fra det tidspunkt hvor en personoplysning når sin slettefrist, til sletningen er foretaget og bekræftet i systemet.

En sletteprocedure bør inkorporere både tekniske og organisatoriske overvejelser, da der i forbindelse med sletning løbende udføres både tekniske og organisatoriske handlinger.

I 'offentligt' er bør, at anse som værende 'det skal du altså'.
Jeg havde måske gerne set en lidt stærkere formulering, som f.eks. en præsisering af at når man nu skal lave security by design, så gælder det også sletning af data. Altså (i IT sprog) at man skal dælme sørge for når man designer en ny løsning, tage højde for sletning af data.. i hele løsnings stakken.

Jeg mener, at det kunne/burde man have pointeret kraftigere.

En anden problematik, er så at datatilsynet skriver i det sprog de skriver. Det er sådan set OK når man skriver til jurister og lignende, men der burde være vejledninger af mere teknisk karakter, rettet mod os IT folk.

// Jesper

  • 6
  • 0
Bjarne Nielsen

Det er sådan set OK når man skriver til jurister og lignende ...

Nu ved jeg ikke, hvad du mener med "...og lignende", men jeg har mødt mange systemejere og andre gatekeepers, som nok formelt set ligger i djøf-segmentet, men som tydeligvis havde mindre begreb skabt om jura end jeg (og så er det virkeligt slemt).

Jeg skal ikke kunne sige, om de var "vil-døve" eller bare ikke havde de evner; det kan være meget svært at se forskel. Jeg er meget enig i dine betragtninger om security by design, men det er dæleme nemt at være hjælpeløs, hvis det er ubekvemt eller ser ud til at koste.

PS: Arkitekter er ofte rimeligt godt inde i stoffet; det er bare ikke altid at man respekterer deres faglighed og indsigt endsige konsulterer dem :-).

  • 6
  • 0
Michael Cederberg

Deres holdning til kryptering+smid nøglen væk princippet viser at de ikke forstår kryptering. Når nøglen er væk er data væk og så er historien ikke længere. Hvis vi skal ud i "hvad nu hvis" så bliver håndtering af backup meget langhåret:

  • Hvad nu hvis der stadigvæk foreligger kopier af nøglen; tjaa ... hvad nu hvis der foreligger kopier af den ikke krypterede backup. Naturligvis skal data (og nøgler er data) håndteres forsvarligt.
  • Hvad nu hvis nogen finder en svaghed i krypteringen; tjaa ... hvad nu hvis nogen finder en metode til at læse gammelt "slettet" data fra harddisken/båndet [Hint: Dette er allerede muligt].

Princippet må være at data er slettet når der ikke er nogen kendt måde at tilgå data igen. "Smid nøglen væk" princippet er meget sikrere end blot at overskrive data.

  • 5
  • 6
Jesper Frimann

Nu ved jeg ikke, hvad du mener med "...og lignende", men jeg har mødt mange systemejere og andre gatekeepers, som nok formelt set ligger i djøf-segmentet, men som tydeligvis havde mindre begreb skabt om jura end jeg (og så er det virkeligt slemt).
Jeg skal ikke kunne sige, om de var "vil-døve" eller bare ikke havde de evner; det kan være meget svært at se forskel.

Ikke alle knive i skuffen er lige skarpe.. man kan dog mange gange undrer sig over, hvad spisepinde dog laver i kniv skuffen......

Jeg er meget enig i dine betragtninger om security by design, men det er dæleme nemt at være hjælpeløs, hvis det er ubekvemt eller ser ud til at koste.
PS: Arkitekter er ofte rimeligt godt inde i stoffet; det er bare ikke altid at man respekterer deres faglighed og indsigt endsige konsulterer dem :-).

Det er så manglen på konsekvens vi kommer til her.. det er en af de ting man skal vende sig til i det offentlige.. i forhold til det private.

Og ja, det at arkitekter er trænede til at sætte sig ind i ting, og relaterer sig til dem i forhold til IT-arkitektur

Jeg og nogle af mine kollegaer har brugt en stor del af sensommeren med, at læse GDPR og relateret dokumenter. Det blev til nogle tusinde sider, og jeg kan da godt se, at forståelsen og viden om GDPR er noget højere hos os, end hos så mange andre.......

// Jesper

  • 5
  • 0
Peter Valdemar Mørch

Når data nu ikke engang må findes i krypteret form selv hvis den private nøgle er slettet, så er det endegyldigt ude med blockchain løsninger hvordan data ligger on-chain, så vidt jeg kan se.

Så er man nødt til at lægge data i mutable store, of lægge en ID on-chain, og alle er tvunget til at stole på dette mutable store. Og så er blockchain til den slags stendød. 😥

Er der nogen der ellers kan se hvordan det skulle kunne lade sig gøre?

  • 2
  • 0
Jesper Nielsen

Så er man nødt til at lægge data i mutable store, of lægge en ID on-chain, og alle er tvunget til at stole på dette mutable store. Og så er blockchain til den slags stendød.

Hvad med at gemme en hash af payload (der ligger i mutable store) i blockchain? Så kan det ses, hvis der er ændret i payload — og man kan vælge ikke at stole på, hvad der står.

  • 2
  • 0
Tobias Tobiasen

Hvis man bruger kryptering+smid nøglen væk princippet hvor gemmer man så nøglen? For nøglen er jo vigtig ikke at miste for de brugere der ikke skal slettes. Hvordan sikrer man sig at man ikke ved et uheld (hacker angreb, sur medarbejder, virus, etc.) sletter de gode nøgler?

Ligger man nøglerne i en database og tager backup af den database? Men har man så ikke samme problem med nøgle database backuppen?

Eller er der noget jeg har overset?

  • 1
  • 0
Michael Cederberg

Fair pointe, men hvis reglerne siger "ikke må kunne genskabes på nogen kendt måde", så er tid ikke en faktor.

Jo. 10^50 år betyder at det ikke kan genskabes. Men hvis du vil den vej, så skal du også beskytte dig mod at nogen finder 10^128 aber med computere ... efter nogen tid har en af aberne produceret en backup mage til den slettede. Inden da har de dog sikkert skrevet Shakespeares samlede værker ...

Hvis man kan slette nøgler fra backups så kan man også slette det de kryptere i backups. Storm i et glas vand, på tværs for at være på tværs, etc.

Jeg gætter på du aldrig har prøvet at planlægge backup strategier. Det her er ikke noget der er biligt at håndtere.

Ligger man nøglerne i en database og tager backup af den database? Men har man så ikke samme problem med nøgle database backuppen?

Principielt kunne man printe nøglen ud på et stykke papir og lægge i en datomærket kuvert i et pengeskab. Processen er så at man fra tid til anden åbner pengeskabet og brænder et antal kuverter. Det er ganske nemt ...

  • 3
  • 0
Kenn Nielsen

Jo. 10^50 år betyder at det ikke kan genskabes.


Det er noget vrøvl at sige:
"fordi det vil tage 10^50 år at genskabe, så kan det ikke genskabes"

Men hvis du vil den vej, så skal du også beskytte dig mod at nogen finder 10^128 aber med computere ... efter nogen tid har en af aberne produceret en backup mage til den slettede. Inden da har de dog sikkert skrevet Shakespeares samlede værker ...


Tak for dén brilliante kommentar.
For der er ikke meget argument i dén.

Og selvom jeg vil medgive at data er irrelevante efter 10^50 år, så er det stadigvæk "at genskabe data på en kendt måde".

Computeraberne, derimod, de genopfinder data fuldstændigt afkoblet fra backup og databaser.
Men dét går jeg ud fra du vidste.

K

  • 0
  • 3
Bjarne Nielsen

men hvis reglerne siger "ikke må kunne genskabes på nogen kendt måde", så er tid ikke en faktor.

Kun i teorien, i praksis gør det hele forskellen.

Om ... lad os regne i runde tal ... 10^3 år er vi alle døde. Der er ca. 10^10 mennesker i verden og selv hvis hver af os fik 10^2 aber med hver deres computer, så vil sandsynligheden for et svar være 10^-35.

Men en menneskealder er uambitiøst. Universet er i omegnen af 10^10 år gammelt (give or take, jeg mener at have hørt 13,8 mia. år) og "big rip" forudsiger at vi bliver alvorlig udfordret af al for megen afstand om et antal år i samme størrelsesorden. Der er andre teorier, så lad os sige, at der er 10^12 år før det hele er lige meget.

Jeg kan godt blive ved, men det er ved at være fjollet. For der er stadig en meget lille chance, og et væddemål, som jeg til enhver tid ville være villig til at tage; bortset fra at det kan være ligemeget, når det engang bliver afgjort.

  • 0
  • 0
Poul-Henning Kamp Blogger

rincippet må være at data er slettet når der ikke er nogen kendt måde at tilgå data igen. "Smid nøglen væk" princippet er meget sikrere end blot at overskrive data.

Sandhedsværdien af det udsagn afhænger alene af om man tror mere på sandsynlighedsregning (men ignorerer worst-case) eller om man tror mere på at 40% af alle IT-fejl skyldes IT-folkene og operatørene.

  • 2
  • 0
Poul-Henning Kamp Blogger

Bestemt. Men hvor tålmodig er du?

Hvor heldig er du ?

Hvis f.eks CPR registeret krypteres med en nøgler per CPR nummer, har du 5 millioner gange bedre chance for at være heldig end hvis du leder efter en bestemt person.

Dertil kommer at det er meget svært og dyrt at lave mange gode tilfældige bits og endnu sværere og dyrere at bevise at man gør det.

  • 0
  • 0
Mogens Lysemose

Det er jo absurd at mene brute Force som tager 10^50 år er mulugt. Forstår du ikke den eksponentielle notation? Om 10^9 år har solen brændt jorden og dræbt alt liv her. Hvem bekymrer sig så om at lave brute Force for at skaffe adgang til persondata som er 1 Mia år gammel når jorden er død? Og man skulle fortsætte 48 gange så lang tid for at finde dine persondata. Det er jo absurd at påstå det er muligt endsige nogen skulle bekymre sig om det!
Det er kun menneskelige fejl der gør det muligt, at nøgler kan genfindes eller er fejlgeneret eller at persondata er kopieret eller printet eller andre menneskelige fejl.

  • 0
  • 0
Bjarne Nielsen

Hvis f.eks CPR registeret krypteres med en nøgler per CPR nummer, har du 5 millioner gange bedre chance for at være heldig end hvis du leder efter en bestemt person.

Arh, du har så 5 mio. forskellige ciphertexts i stedet for ens, og så er du vel lige vidt.

Men ellers vil jeg gerne give dig et forspring på 10^7 og stadig mene, at jeg har den gode side af det væddemål.

Dertil kommer at det er meget svært og dyrt at lave mange gode tilfældige bits og endnu sværere og dyrere at bevise at man gør det.

Det har du fuldkommen ret i, og der er også en lang række andre aspekter, som også er interessante (jeg sidder f.eks. og overvejer, hvad en beskedlængde markant kortere end bloklængden ville kunne føre til...). I øvrigt tog jeg oprindeligt flg. forbehold:

(forudsat at det er ikke gjort noget tåbeligt, som f.eks. drastisk reduktion af nøglerummet på en forudsigelig måde)

...og det dækker vel din indvending? (og ja, der skulle have stået "der" og ikke "det").

  • 0
  • 0
Kenn Nielsen

Det er jo absurd at mene brute Force som tager 10^50 år er mulugt. Forstår du ikke...?
Om 10^9 år har solen brændt jorden og dræbt alt liv her.
Hvem bekymrer sig så om at lave brute Force....?
....Det er jo absurd at påstå..... endsige nogen skulle bekymre sig om det!


Pointen var, - og er:
Hvis reglerne siger "..må ikke kunne genskabel med kendt teknik" - agtigt; så kan man - med sædvanlig iskold og lokumsagtig jura - slå hårdt ned på dén løsning.

Jeg er helt med på - som jeg skriver andetsteds - at data ikke vil være relevante efter 10⁵⁰ år.

IANAL; måske ikke alle dommere er IT-tåber, og måske er tid alligevel en faktor, når uansvarlighed skal bedømmes.
Men vi har før set at IT behandles som Voodoo, og sandheden for retten afhænger hvilken præst der spørges (og måske hvem der betaler hendes løn).

K

  • 0
  • 0
Malik Taaning

Det er imponerende at du kan forudsige hvilke muligheder vi har for at bryde kryptering om 2 eller 10 år...

Smid nøglen væk er ikke tilstrækkeligt, ikke med mindre man har mulighed for at droppe backuppen helt i det tilfælde at der findes en tilpas hurtig måde at bryde krypteringen på.

  • 1
  • 0
Michael Cederberg

Men dét går jeg ud fra du vidste.

Resultatet er det samme. Det må være det der tæller.

Sandhedsværdien af det udsagn afhænger alene af om man tror mere på sandsynlighedsregning (men ignorerer worst-case) eller om man tror mere på at 40% af alle IT-fejl skyldes IT-folkene og operatørene.

De to udsagn er ikke modsat rettet. Jeg håber sandelig at alle ingeniører forstår sandsynlighedsregning. Men at IT folk laver mange fejl kan vi godt blive enige om. Jeg er blot ret sikker på at der laves færre fejl når det handler om at destruere en nøgle end når det handler om at fjerne dele af en backup.

Hvis f.eks CPR registeret krypteres med en nøgler per CPR nummer, har du 5 millioner gange bedre chance for at være heldig end hvis du leder efter en bestemt person.

Det ville også være dumt at gøre. Og specielt i backup-sammenhæng vil det være usmart. TIl backup formål kan man i princippet generere en enkelt 128/256/512 bit nøgle og så kryptere alt data med AES i CBC mode. Så vil backup data blot være at opfatte som hvid støj med mindre man har nøglen. Kryptering er ikke en tryllestav der løser alle problemer men et præcisionsinstrument hvor man skal forstå brugen og have gode processer for nøglesikkerhed.

Dertil kommer at det er meget svært og dyrt at lave mange gode tilfældige bits og endnu sværere og dyrere at bevise at man gør det.

Tilfældige bits i denne sammenhæng er billige. Ydermere skal forsøget på at generere random bits holdes op mod det generelle sikkerhedsniveau i systemet. Der er ingen grund til at vælge NSA grade sikkerhed (med mindre det er omkostningsfrit) hvis der sidder en Ruko-lås på døren til virksomheden og serverrummet. Det samme gælder i øvrigt hele denne diskussion om brute force i 10^50 år ...

  • 0
  • 0
Jan Heisterberg

Dette er et teknisk forum, og det er derfor fair at diskutere teknik - og fortolkningen af samme.

Det er imidlertid vigtigt at huske, at Datatilsynet "klare regler" kun er et gæt på retstilstanden. Først nå eet eller flere tilfælde har været pådømt i retten kan vi kende retstilstanden.
Måske vil retten accepterer argumenter for kryptering, måske ikke.
Det vil afhænge af bevisets stilling.

Så indtil da .........

Men det er også, sandsynligvis, klart, at den praksis som Rigspolitiet har anvendt IKKE vil holde i retten.

  • 1
  • 0
Heino Svendsen

Det er sjovt jeg har lært at ordet "bør" bør undgås fordi det betyder "hvis du ikke har en god grund eller en anden tilsvarende løsning"

Ordet "bør" er i denne henseende rigtig vigtigt. Det giver myndighederne den "elastik", de har brug for for at kunne håndtere data, som de ønsker men samtidig mulighed for at hævde, at de overholder gældende anbefalinger og regler.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize