Unntakene fra GDPR er egentlig ganske greit, dersom det er annen lovgivning involvert så taper GDPR (litt tabloid). Feks vil lovgivning rundt finans kreve lagring i x antall år.
I tillegg er GDPR kun styrende for persondata. Akkurat hva som er persondata er fortsatt litt flytende, Børhaug bruker en vid definisjon - jeg tror det blir noen rettsaker i starten som vil avklare rettspraksis etterhvert.
Angående keal sine spørsmål om BBs vern av anonymitet. Vi tar anonymitet på alvor og vil ikke levere ut opplysninger uten videre. Våre brukere skal være trygge på at anonymiteten er ivaretatt. Samtidig står følgende i våre vilkår:
"ByggeBolig forbeholder seg retten å videreformidle din identitet, eller annen informasjon vi har om deg, i hendelse av alvorlige klager eller juridisk prosedyre som følge av dine poster."
Det er vel særlig formuleringen "alvorlige klager" som kan være vanskelig å håndtere. Så vidt jeg vet har vi aldri blitt satt på prøve i den sammenheng.
Og bland nå ikke SQL inn i debatten; det en detalj på siden av diskusjonen som ikke tar opp den originale problemstillingen.
Dette har da ingenting å gjøre med SQL per se. Som jeg understreket eksplisitt: jeg refererer til "SQL DELETE eller ekvivalent operasjon".
Debattenhar definitivt å gjøre med forskjellen mellom logisk sletting av data slik at de ikke er tilgjengelig gjennom ordinære databaseoperasjoner (om man bruker SQL eller annet), og å fysisk fjerne/overskrive informasjonen fra alle steder den befinner seg på fysisk disk, logg og backup. Skal vi tenke sikkerhet må vi ikke gå rundt og tro at bare vi legger dokumenter i papirkurven er de helt borte. Vi må ikke går rundt og tro at bare vi gjøre en database DELETE ( i SQL eller andre språk) forsvinner de totalt fra loggfiler og backups. Ikke hvis vi skal tenke IT-sikkerhet og personvern.
Hvis det er et problem at jeg eksemplifiserer logisk sletting i databaser ved "SQL DELETE (eller ekvivalent operasjon)" kan jeg gjerne uttrykke meg i mer abstrakte begreper videre i diskusjonen.
Akkurat hva som er persondata er fortsatt litt flytende, Børhaug bruker en vid definisjon - jeg tror det blir noen rettsaker i starten som vil avklare rettspraksis etterhvert.
Det kan vi håpe på... Men vi har hatt tilsvarende mangel på avklaring i annet lovverk der vi har gått i en generasjon eller to og håpet på en klar og entydig høyesterettsdom, uten at det har kommet.
Et karikert eksempel er åndsverksloven, hvor langt forbukerens rettigheter etter §12 strekker seg. Ingen ønsker noen avklaring: Rettighetshaverne vil ikke ha en klar linje som entydig bestemmer at forbrukeren har lov til sånn og slik kopiering; de ønsker å rasle med paragraf-knippet for å skremme folk bort fra å gjøre selv det de ubetinget har rett til. Forbrukerne ønsker heller ikke noen skarp linje som klart forteller når du går for langt; de ønsker å kunne tøye strikken så langt som overhodet mulig. Begge parter er "redd for" den klare avgrensingen som fratar dem retten til å skremme eller tøye strikken. Ingen presser på for en klargjørende HR-dom.
Situasjonen kan bli tilsvarende for persondata/personvern: Mange organisasjoner kan aktivt ønske ganske diffuse grenser, slik at de kan fortsette å lagre informasjon i "gråsonen"; de vil ikke ha forbudet. Personvern-aktivister ønsker heller ikke å bli stoppet av en HR-dom som gir arkiv-eieren full rett til å lagre visse typer info; de ønsker å kunne fortsette å presse på grensene, forfølge de som samler mer info enn forbrukerne ønsker.
Uansett: Det en HR-dom (eller flere) kan avklare er norsk praksis. Jeg var for en del år siden involvert i EU-direktiver rundt opphavsrett. I prinsippet skulle EU-direktivet "harmonisere" medlemslandenes lover: Formuleringen var opp til hvert enkelt medlemsland, men meningen skulle være den samme... Vi brukte høytlesing av ulike lands lovtekster, de som liksom skulle ha samme innhold, til selskapsunderholdning; det var ikke fritt for gapskratt. EU-direktiver kan være ekstremt formalistiske, og ofte blir formalisme forvekslet med entydighet i tolking. Det kan være himmelvidt fra virkeligheten
Og bland nå ikke SQL inn i debatten; det en detalj på siden av diskusjonen som ikke tar opp den originale problemstillingen.
Dette har da ingenting å gjøre med SQL per se. Som jeg understreket eksplisitt: jeg refererer til "SQL DELETE eller ekvivalent operasjon".
Debattenhar definitivt å gjøre med forskjellen mellom logisk sletting av data slik at de ikke er tilgjengelig gjennom ordinære databaseoperasjoner (om man bruker SQL eller annet), og å fysisk fjerne/overskrive informasjonen fra alle steder den befinner seg på fysisk disk, logg og backup. Skal vi tenke sikkerhet må vi ikke gå rundt og tro at bare vi legger dokumenter i papirkurven er de helt borte. Vi må ikke går rundt og tro at bare vi gjøre en database DELETE ( i SQL eller andre språk) forsvinner de totalt fra loggfiler og backups. Ikke hvis vi skal tenke IT-sikkerhet og personvern.
Hvis det er et problem at jeg eksemplifiserer logisk sletting i databaser ved "SQL DELETE (eller ekvivalent operasjon)" kan jeg gjerne uttrykke meg i mer abstrakte begreper videre i diskusjonen.
Det er flisespikking å i hele tatt nevne SQL når dette kun er et språk for å kommunisere med noen relasjonsdatabaser og GDPR omhandler all lagring av data – uansett medium eller teknologi. Å fokusere på databaser er jo en oppskrift på å drite seg ut når logger, filer, skylagre, etc, etc også omfattes av GDPR. Man må være rimelig mentalt begrenset for ikke å skjønne at et pålegg om å slette data også omfatter alle kopier man har liggende av data – backup, filkopier, redunante databaser, etc.
"SQL DELETE" blir destruktivt for debatten da det flytter fokus over på en liten detalj.
Hvorfor fokuserer du sa så intenst på SQL, og samtidig sier at det er "en liten detalj"?
Jeg har inntrykk av at du forsøker å insinuere at undertegnede er "rimelig mentalt begrenset" her, til tross for at nettopp det jeg forsøker å understreke så sterkt som mulig at "pålegg om å slette data også omfatter alle kopier man har liggende av data – backup, filkopier, redunante databaser, etc.".
Jeg forsøker å understreke hvor ressurskrevende og vanskelig det er. Ut fra min fagkunnskap om hvordan logging gjøres i databasesystemer, og hvordan seriøse aktører handterer sikkerhetskopier, "vet" jeg at det kan være så omfattende at en ikke ubetydelig andel installasjoner vil ha store problemer med å redegjøre for hvordan de handterer logger, sikkerehetskopier, replikater etc. for å garantere at alle spor av informasjonen er slettet innen 72 timer.
Du kan fortelle publikum at "Alt er tatt hånd om i henhold til EU-kravene", og når de spør om loggene, kan su svare: Jada, GDPR omfatter også loggene, ta det med ro! Så kommer en eller annen database-ekspert med litt mer ekle detaljspørsmål, og så blir det litt mer kremting og bortforklaring.
Som jeg nevnte tidligere: I Baneheia-saken ble det stilt kritiske spørsmå om det overhodet ville vært mulig å hente fram informasjonen hvis datoen hadde blitt overskredet for lovpålagt sletting. Telenor ble nødt til å innrømme at det nok ville vært mulig å hente fram fra offline langtidsbackup, selv om det ifølge loven skulle være slettet. Jeg ser ingen grunn til å tro at ikke det samme svaret bare kunne forekomme, men ville være det "normale" i dagens systemer: Vel, ja, etter loven skulle vi jo ha slettet det fra logger og sikringskopier, men det krever så stor innsats, med mange manuelle operasjoner, at ingen ville kunne misbruke den informasjonen selv om den ligger der.
Jeg tviler sterkt på at du kan stå som garantist for at total sletting innen 72 timer, fra logger og sikringskopier, faktisk blir utført i samtlige installasjoner som handterer persondata. Du kan stå som garantist for at de skulle gjøre det, men ikke for at de gjør det. Ikke engang at de har prosedyrene på plass for det. (Å slette enkelt-innslag i en databaselogg er ikke noe man har standard-prosedyrer for fra leverandøren av databasesystemet.)
Jeg insinuerer ikke at du har mentale begrensninger, jeg sier at de som ikke forstår at pålegg om å fjerne data også omfatter logger, cacher i databaser, tape backup eller hullkort om du er hipster – de burde holdes unna tastaturer de kan gjøre skade via. At Telenor gav blaffen i ditt eksempel er nok et langt mer sannsynlig scenario. Sikkerhet og lovlydighet er snakk om penger, tross alt.
Du misforstår også hensikten med forordningen når du påpeker at Telenors backuper ikke kan misbrukes – jo, det kan den. Telenor tar ikke backuper som ikke kan brukes. Retten til å bli glemt av Telenor er for at Telenor ikke skal kunne misbruke dataene. Gamle fjernbackuper er omfattet; synd om backup-løsningen din suger.
Hvis ikke du kan garantere at en personforekomst er slettet i databasen, loggen, cachen eller hva det nå er, så bør man finne noen som kan garantere det. Det er jo en grunn for at GDPR har gitt et gryende konsulentmarked. At det er ikke-trivielt er en av grunnen for at mange av oss har jobb.
Og til slutt: Få hodet ut av databasen! Lagring er så mye, mye mer enn databaser. Databaser er også langt mer enn relasjonsdatabaser.
Lagring er så mye, mye mer enn databaser. Databaser er også langt mer enn relasjonsdatabaser.
Jeg bruker database-begrepet for å få "folk flest" til å forholde seg aktivt til det. Da forstår de hva vi snakker om - selv om lagring kan skje på mange måter.
Jeg vokste opp med CODASYL - et begrep praktisk talt ukjent selv for databasefolk i dag! i studietiden, da proffen kom hjem fra USA og nesten med tårer i øynene fortalte om den faktisk eksisterende relasjondatabasen han hadde sett, som var sånn, ikke bare som en akademisk idé... Relasjonsdatabaser er bare en av mange datamodeller; modellen har ingen prinsipiell betydning for integritet, innsyn eller personvern.
Et større problem er at massevis av systemer presenteres som 'relasjondatabaser' som knapt er mer enn en ISAM-fil. De som nærmer seg relasjons-ideer svikter ofte på vesentlige punkter, både på ACID-egenskaper synlige for brukeren og i intern virkemåte. For eksempel: Spør du hvordan plassen administreres når data slettes, hva som skjer med en frigjort blokk, er det ofte vanskelig å få et klart og entydig svar. Stiller du spørsmål om hvordan man redigerer loggfil-innslaget som omfatter en hel post, men er bare enkelte felter i posten ifølge GDPR må slettes, men de øvrige felt i oppdateringen fortsatt skal ligge igjen in loggposten, da blir det et hakk vanskeligere. Ikke minst om loggposten er beskyttet av integritetsmekanismer av type sjekksum - å blanke ut persondata-felter krever ny sjekksum-beregning, og er du garantert at det ikke andre steder i systemet (f.eks. i andre loggposter) er bevart den gamle sjekksummen for integritetskonroll, så også den må oppdateres? Det kan føre til at den posten endrer sjekksum, og det hele gir en ripple lange veier framover.
Selv har jeg betydelig (faglig begrunnet) skepsis til relasjonsmodellen som Den Enste Datamodellen for datalagring, og jeg vil på ingen måte promotere den som Løsningen med stor L. Men jeg sier likevel 'databaser' (og sågar dette famøse 'SQL' ), primært for at 'vanlige folk' skal ha knagger å henge ting på.
På prinsipielt nivå blir lite annerledes med noe annet enn en datatabase, eller annet enn en relasjons-database. Det betyr litt for hvor en spion (/etterforskere / myndigheter) leter etter informasjon. For rene filer: De færreste filsystemer blanker ut diskblokker som frigjøres; det ville forsinke frigjøring betydelig. (Mange gjør det når frie blokker allokeres til en fil, in-memory, uten å gå ut på disken for å blanke den først.) I mine student-dager demonsterte en med-student hvordan han allokerte en megabyte-fil og hentet masse informasjon fra blokkene han fikk tildelt - i dette OSet ble ikke blokkene nullet ved tildeling. (Nulling av diskblokker var en idle-loop operasjon, men her var det en batch-orientert stormaskin som sjelden hadde tid til idle-looping.)
Nei, det er ikke bare "Hvis ikke du kan garantere at en personforekomst er slettet i databasen, loggen, cachen eller hva det nå er, så bør man finne noen som kan garantere det" - det er på nivå "Se, her er en appelsin, slutt å gråt nå!" Som regel anyder det at personforekomsten slett ikke er fullstendig slettet, men at du skal tro det!
Jo mer lettvint et svar er, jo mer skeptisk blir jeg - særlig når jeg er såpass mye inni faget at jeg vet hvor ikke-trivielt det er. Jeg vet nok til at jeg er sikker på at jeg kunne stille "litt for mange" plagsomme spørsmål også til konsulentene som tetter GDPR-hull. De fleste av dagens utviklere har liten forståelse for hva som skjer hele veien ned til den fysiske disken. De aller mest primitive forholder seg til et slettet dokument som absolutt slettet, selv når det ligger i søppelkassen. De litt mer avanserte tror at når en post ikke lenger ikke kan hentes fram på ordinær måte (for å unngå å provosere vil jeg her verken referere til språk eller operajoner. og ikke engang til typen programvare), da er posten absolutt slettet. Neste nivå er de som tror at bare informasjonen logisk slettes fra loggen, da er den absolutt slettet ... selv om et søk på disken, på binærnivå uten å være begrenset av indeks-tabeller, 'runs' eller hva det heter i ulike systemer), finner fram til den. Men om diskblokker slettes ved-deallokering: Hva med total disk-backup hver måned? Loggfiler som er sikkerhetskopiert til andre lokasjoner?
Jeg er ikke selv ekspert på sikkerhet, men har jobbet sammen med slike eksperter på et par prosjekter, med nok faglig bakgrunn til å forstå hvert enkelt ord av hva de formidlet. Jeg har sett hvordan de i likhet med kriminal-etterforskere er årvåkne på hver minste lille detalj som bør undersøkes, hvor kritiske de er til at 'dette er tatt hånd om'. Når en sikkerhetsekspert blir møtt med at 'Dette er tatt hånd om' er det 95% sjanse for at det betyr at det ikke er tatt hånd om, men at sikkehetseksperten skal overse det. Jeg har lært meg å være var på 'generelle forsikringer', og vet at i sikkerhetsarbeid skal man aldri, aldri godta noe fordi man ikke forstår alle detaljene. Forsikringer er det motsatte av hva de gir seg ut for: De er faresignaler, her må du være på vakt!
Min uerbødige påstand er at en stor del av de konsulentene som jobber med GDPR nok kan ha detaljforståelse av direktivet, men uten å ha detaljforståelse av hvordan data flyter i et lagringssystem, uavhengig av om det er en CODASYL- eller relasjons-database, en ISAM-fil eller en flat fil, uavhengig av typen filsystem. Eller rettere sagt: Ikke uavhengig av, men med full forståelse av samtlige alternativer.
Bare ekstremt spesialiserte og høykvalifisert konsulenter har slik dybde-forståelse. Og det er ikke nok av dem til å sikre at GDPR blir ivaretatt i alle aktuelle systemer.
For å konkretisere det (helt uavhengig av databasemodell. query-språk, filsystem, ....): Anta at jeg får anledning til å i dag registrere meg i et system med seksuil preferanse å være xyzzyfil (underforstått: Noe som ikke ville finnes i noen annen post, noe som ville være unikt - kanskje xyzzyfil ikke er unikt). Anta at jeg kan komme tilbake regelmessig i et halvt år, gjennom flere total-backups, og å få bekreftet at jeg kan lese ut denne preferansen, fra alle de systemer som er koblet sammen i nettverket.
Så, etter et halvt år ber jeg om at denne registreringen slettes, og 72 timer senere tar jeg kontroll over samtlige disker, loggfiler, online og offline backups, både på denne maskinen og på samtlige maskiner som gjennom nettverket har (eller kan ha) replikater av disse dataene.
Når jeg gjør et binærsøk på disken, helt uavhengig av filsystem, helt uavhengig av databasesystem eller applikasjon, så jeg ser blokker både fra slettede diskfiler, innslag i loggfiler, blokker innenfor en fil som ligger i en friliste, og i det hele tatt: absolutt alt, hvor sikkert er det at jeg aldri vil finne teksten "xyzzyfil"?
Det kan hende teksten er kryptert, men kunne databasesystemet dekryptere det før det ble slettet, da kan det også dekrypteres i ettertid; det er inen reell beskyttelse. Om "xyzzfil" ligger i klartekst eller kryptert er ikke av prinsipiell betydning. Hvis "xyzzfil" overhodet finnes på noen som helst disk, i allokerte eller frigjorte områder, inkludert samtlige sikkerhetskopier og logger, i det distribuerte systemet, da er i prinsippet et brudd på GDPR.
Det vil være vanskelig nok å få operatører tll å redegjøre for alle deres forekomster av logger og sikkerhets-kopier. I et heterogent DDBMs er det enda vanskeligere å få oversikt over alt som er av disker, loggfiler etc. For å være ærlig: Jeg tror neppe du behøver å hente inn samtlige replikater med sine logfiler og backups før du finner den første "xyzzyfil" ved binærsøk gjennom diskene fra blokk 0 og oppover.
Som en sjekk burde man naturligvis før slettingen logge inn på samtlige replikat-maskiner og verifisere at legning "xyzzyfil" er tilgjengelig der - både gjennom brukernivå-applikasjoner (enten det går gjennom en database med vilkårlig query-språk, eller annen mekanisme), og ved å søke på disker og (offline) logger for å verifisere at det er lagret persistent på noden. Så kan de samme stedene i de samme filene og lokasjonene oppsøkes direkte - men selvsagt kan også slettede data være flytet til andre steder, så det gjør ikke det fullstendige søket på disken unødvnedig.
Jeg har selvsagt ingen negativ holdning til at det blir holdt et øye med at hva folk som handterer personopplysninger "bør" og "kan" lagre er i samsvar med regelverket. Jeg bare tror ikke at normalt blir effektuert på en slik måte at 72 timer etter at en makør ("xyzzyfil") blir slettet (etter å ha figurert på maskinen i lengre tid og blitt replikert og sikkerhetskopiert i flere runder) ubetinget og absolutt vil være borte fra alle relevante online, offline logger og disker, og det samme på alle replkat-maskner.
Andre kan stole på det. Jeg er skeptisk, ihvertfall inntil jeg får en forklaring fra en ekspert som gir meg overbevisende svar på alle mine kritiske spørsmål.
I tillegg er GDPR kun styrende for persondata. Akkurat hva som er persondata er fortsatt litt flytende, Børhaug bruker en vid definisjon - jeg tror det blir noen rettsaker i starten som vil avklare rettspraksis etterhvert.
"ByggeBolig forbeholder seg retten å videreformidle din identitet, eller annen informasjon vi har om deg, i hendelse av alvorlige klager eller juridisk prosedyre som følge av dine poster."
Det er vel særlig formuleringen "alvorlige klager" som kan være vanskelig å håndtere. Så vidt jeg vet har vi aldri blitt satt på prøve i den sammenheng.
Dette har da ingenting å gjøre med SQL per se. Som jeg understreket eksplisitt: jeg refererer til "SQL DELETE eller ekvivalent operasjon".
Debattenhar definitivt å gjøre med forskjellen mellom logisk sletting av data slik at de ikke er tilgjengelig gjennom ordinære databaseoperasjoner (om man bruker SQL eller annet), og å fysisk fjerne/overskrive informasjonen fra alle steder den befinner seg på fysisk disk, logg og backup. Skal vi tenke sikkerhet må vi ikke gå rundt og tro at bare vi legger dokumenter i papirkurven er de helt borte. Vi må ikke går rundt og tro at bare vi gjøre en database DELETE ( i SQL eller andre språk) forsvinner de totalt fra loggfiler og backups. Ikke hvis vi skal tenke IT-sikkerhet og personvern.
Hvis det er et problem at jeg eksemplifiserer logisk sletting i databaser ved "SQL DELETE (eller ekvivalent operasjon)" kan jeg gjerne uttrykke meg i mer abstrakte begreper videre i diskusjonen.
Det kan vi håpe på... Men vi har hatt tilsvarende mangel på avklaring i annet lovverk der vi har gått i en generasjon eller to og håpet på en klar og entydig høyesterettsdom, uten at det har kommet.
Et karikert eksempel er åndsverksloven, hvor langt forbukerens rettigheter etter §12 strekker seg. Ingen ønsker noen avklaring: Rettighetshaverne vil ikke ha en klar linje som entydig bestemmer at forbrukeren har lov til sånn og slik kopiering; de ønsker å rasle med paragraf-knippet for å skremme folk bort fra å gjøre selv det de ubetinget har rett til. Forbrukerne ønsker heller ikke noen skarp linje som klart forteller når du går for langt; de ønsker å kunne tøye strikken så langt som overhodet mulig. Begge parter er "redd for" den klare avgrensingen som fratar dem retten til å skremme eller tøye strikken. Ingen presser på for en klargjørende HR-dom.
Situasjonen kan bli tilsvarende for persondata/personvern: Mange organisasjoner kan aktivt ønske ganske diffuse grenser, slik at de kan fortsette å lagre informasjon i "gråsonen"; de vil ikke ha forbudet. Personvern-aktivister ønsker heller ikke å bli stoppet av en HR-dom som gir arkiv-eieren full rett til å lagre visse typer info; de ønsker å kunne fortsette å presse på grensene, forfølge de som samler mer info enn forbrukerne ønsker.
Uansett: Det en HR-dom (eller flere) kan avklare er norsk praksis. Jeg var for en del år siden involvert i EU-direktiver rundt opphavsrett. I prinsippet skulle EU-direktivet "harmonisere" medlemslandenes lover: Formuleringen var opp til hvert enkelt medlemsland, men meningen skulle være den samme... Vi brukte høytlesing av ulike lands lovtekster, de som liksom skulle ha samme innhold, til selskapsunderholdning; det var ikke fritt for gapskratt. EU-direktiver kan være ekstremt formalistiske, og ofte blir formalisme forvekslet med entydighet i tolking. Det kan være himmelvidt fra virkeligheten
Det er flisespikking å i hele tatt nevne SQL når dette kun er et språk for å kommunisere med noen relasjonsdatabaser og GDPR omhandler all lagring av data – uansett medium eller teknologi. Å fokusere på databaser er jo en oppskrift på å drite seg ut når logger, filer, skylagre, etc, etc også omfattes av GDPR. Man må være rimelig mentalt begrenset for ikke å skjønne at et pålegg om å slette data også omfatter alle kopier man har liggende av data – backup, filkopier, redunante databaser, etc.
"SQL DELETE" blir destruktivt for debatten da det flytter fokus over på en liten detalj.
Jeg har inntrykk av at du forsøker å insinuere at undertegnede er "rimelig mentalt begrenset" her, til tross for at nettopp det jeg forsøker å understreke så sterkt som mulig at "pålegg om å slette data også omfatter alle kopier man har liggende av data – backup, filkopier, redunante databaser, etc.".
Jeg forsøker å understreke hvor ressurskrevende og vanskelig det er. Ut fra min fagkunnskap om hvordan logging gjøres i databasesystemer, og hvordan seriøse aktører handterer sikkerhetskopier, "vet" jeg at det kan være så omfattende at en ikke ubetydelig andel installasjoner vil ha store problemer med å redegjøre for hvordan de handterer logger, sikkerehetskopier, replikater etc. for å garantere at alle spor av informasjonen er slettet innen 72 timer.
Du kan fortelle publikum at "Alt er tatt hånd om i henhold til EU-kravene", og når de spør om loggene, kan su svare: Jada, GDPR omfatter også loggene, ta det med ro! Så kommer en eller annen database-ekspert med litt mer ekle detaljspørsmål, og så blir det litt mer kremting og bortforklaring.
Som jeg nevnte tidligere: I Baneheia-saken ble det stilt kritiske spørsmå om det overhodet ville vært mulig å hente fram informasjonen hvis datoen hadde blitt overskredet for lovpålagt sletting. Telenor ble nødt til å innrømme at det nok ville vært mulig å hente fram fra offline langtidsbackup, selv om det ifølge loven skulle være slettet. Jeg ser ingen grunn til å tro at ikke det samme svaret bare kunne forekomme, men ville være det "normale" i dagens systemer: Vel, ja, etter loven skulle vi jo ha slettet det fra logger og sikringskopier, men det krever så stor innsats, med mange manuelle operasjoner, at ingen ville kunne misbruke den informasjonen selv om den ligger der.
Jeg tviler sterkt på at du kan stå som garantist for at total sletting innen 72 timer, fra logger og sikringskopier, faktisk blir utført i samtlige installasjoner som handterer persondata. Du kan stå som garantist for at de skulle gjøre det, men ikke for at de gjør det. Ikke engang at de har prosedyrene på plass for det. (Å slette enkelt-innslag i en databaselogg er ikke noe man har standard-prosedyrer for fra leverandøren av databasesystemet.)
Jeg insinuerer ikke at du har mentale begrensninger, jeg sier at de som ikke forstår at pålegg om å fjerne data også omfatter logger, cacher i databaser, tape backup eller hullkort om du er hipster – de burde holdes unna tastaturer de kan gjøre skade via. At Telenor gav blaffen i ditt eksempel er nok et langt mer sannsynlig scenario. Sikkerhet og lovlydighet er snakk om penger, tross alt.
Du misforstår også hensikten med forordningen når du påpeker at Telenors backuper ikke kan misbrukes – jo, det kan den. Telenor tar ikke backuper som ikke kan brukes. Retten til å bli glemt av Telenor er for at Telenor ikke skal kunne misbruke dataene. Gamle fjernbackuper er omfattet; synd om backup-løsningen din suger.
Hvis ikke du kan garantere at en personforekomst er slettet i databasen, loggen, cachen eller hva det nå er, så bør man finne noen som kan garantere det. Det er jo en grunn for at GDPR har gitt et gryende konsulentmarked. At det er ikke-trivielt er en av grunnen for at mange av oss har jobb.
Og til slutt: Få hodet ut av databasen! Lagring er så mye, mye mer enn databaser. Databaser er også langt mer enn relasjonsdatabaser.
Jeg bruker database-begrepet for å få "folk flest" til å forholde seg aktivt til det. Da forstår de hva vi snakker om - selv om lagring kan skje på mange måter.
Jeg vokste opp med CODASYL - et begrep praktisk talt ukjent selv for databasefolk i dag! i studietiden, da proffen kom hjem fra USA og nesten med tårer i øynene fortalte om den faktisk eksisterende relasjondatabasen han hadde sett, som var sånn, ikke bare som en akademisk idé...
Et større problem er at massevis av systemer presenteres som 'relasjondatabaser' som knapt er mer enn en ISAM-fil. De som nærmer seg relasjons-ideer svikter ofte på vesentlige punkter, både på ACID-egenskaper synlige for brukeren og i intern virkemåte. For eksempel: Spør du hvordan plassen administreres når data slettes, hva som skjer med en frigjort blokk, er det ofte vanskelig å få et klart og entydig svar. Stiller du spørsmål om hvordan man redigerer loggfil-innslaget som omfatter en hel post, men er bare enkelte felter i posten ifølge GDPR må slettes, men de øvrige felt i oppdateringen fortsatt skal ligge igjen in loggposten, da blir det et hakk vanskeligere. Ikke minst om loggposten er beskyttet av integritetsmekanismer av type sjekksum - å blanke ut persondata-felter krever ny sjekksum-beregning, og er du garantert at det ikke andre steder i systemet (f.eks. i andre loggposter) er bevart den gamle sjekksummen for integritetskonroll, så også den må oppdateres? Det kan føre til at den posten endrer sjekksum, og det hele gir en ripple lange veier framover.
Selv har jeg betydelig (faglig begrunnet) skepsis til relasjonsmodellen som Den Enste Datamodellen for datalagring, og jeg vil på ingen måte promotere den som Løsningen med stor L. Men jeg sier likevel 'databaser' (og sågar dette famøse 'SQL'
På prinsipielt nivå blir lite annerledes med noe annet enn en datatabase, eller annet enn en relasjons-database. Det betyr litt for hvor en spion (/etterforskere / myndigheter) leter etter informasjon. For rene filer: De færreste filsystemer blanker ut diskblokker som frigjøres; det ville forsinke frigjøring betydelig. (Mange gjør det når frie blokker allokeres til en fil, in-memory, uten å gå ut på disken for å blanke den først.) I mine student-dager demonsterte en med-student hvordan han allokerte en megabyte-fil og hentet masse informasjon fra blokkene han fikk tildelt - i dette OSet ble ikke blokkene nullet ved tildeling. (Nulling av diskblokker var en idle-loop operasjon, men her var det en batch-orientert stormaskin som sjelden hadde tid til idle-looping.)
Nei, det er ikke bare "Hvis ikke du kan garantere at en personforekomst er slettet i databasen, loggen, cachen eller hva det nå er, så bør man finne noen som kan garantere det" - det er på nivå "Se, her er en appelsin, slutt å gråt nå!" Som regel anyder det at personforekomsten slett ikke er fullstendig slettet, men at du skal tro det!
Jo mer lettvint et svar er, jo mer skeptisk blir jeg - særlig når jeg er såpass mye inni faget at jeg vet hvor ikke-trivielt det er. Jeg vet nok til at jeg er sikker på at jeg kunne stille "litt for mange" plagsomme spørsmål også til konsulentene som tetter GDPR-hull. De fleste av dagens utviklere har liten forståelse for hva som skjer hele veien ned til den fysiske disken. De aller mest primitive forholder seg til et slettet dokument som absolutt slettet, selv når det ligger i søppelkassen. De litt mer avanserte tror at når en post ikke lenger ikke kan hentes fram på ordinær måte (for å unngå å provosere vil jeg her verken referere til språk eller operajoner. og ikke engang til typen programvare), da er posten absolutt slettet. Neste nivå er de som tror at bare informasjonen logisk slettes fra loggen, da er den absolutt slettet ... selv om et søk på disken, på binærnivå uten å være begrenset av indeks-tabeller, 'runs' eller hva det heter i ulike systemer), finner fram til den. Men om diskblokker slettes ved-deallokering: Hva med total disk-backup hver måned? Loggfiler som er sikkerhetskopiert til andre lokasjoner?
Jeg er ikke selv ekspert på sikkerhet, men har jobbet sammen med slike eksperter på et par prosjekter, med nok faglig bakgrunn til å forstå hvert enkelt ord av hva de formidlet. Jeg har sett hvordan de i likhet med kriminal-etterforskere er årvåkne på hver minste lille detalj som bør undersøkes, hvor kritiske de er til at 'dette er tatt hånd om'. Når en sikkerhetsekspert blir møtt med at 'Dette er tatt hånd om' er det 95% sjanse for at det betyr at det ikke er tatt hånd om, men at sikkehetseksperten skal overse det. Jeg har lært meg å være var på 'generelle forsikringer', og vet at i sikkerhetsarbeid skal man aldri, aldri godta noe fordi man ikke forstår alle detaljene. Forsikringer er det motsatte av hva de gir seg ut for: De er faresignaler, her må du være på vakt!
Min uerbødige påstand er at en stor del av de konsulentene som jobber med GDPR nok kan ha detaljforståelse av direktivet, men uten å ha detaljforståelse av hvordan data flyter i et lagringssystem, uavhengig av om det er en CODASYL- eller relasjons-database, en ISAM-fil eller en flat fil, uavhengig av typen filsystem. Eller rettere sagt: Ikke uavhengig av, men med full forståelse av samtlige alternativer.
Bare ekstremt spesialiserte og høykvalifisert konsulenter har slik dybde-forståelse. Og det er ikke nok av dem til å sikre at GDPR blir ivaretatt i alle aktuelle systemer.
For å konkretisere det (helt uavhengig av databasemodell. query-språk, filsystem, ....): Anta at jeg får anledning til å i dag registrere meg i et system med seksuil preferanse å være xyzzyfil (underforstått: Noe som ikke ville finnes i noen annen post, noe som ville være unikt - kanskje xyzzyfil ikke er unikt). Anta at jeg kan komme tilbake regelmessig i et halvt år, gjennom flere total-backups, og å få bekreftet at jeg kan lese ut denne preferansen, fra alle de systemer som er koblet sammen i nettverket.
Så, etter et halvt år ber jeg om at denne registreringen slettes, og 72 timer senere tar jeg kontroll over samtlige disker, loggfiler, online og offline backups, både på denne maskinen og på samtlige maskiner som gjennom nettverket har (eller kan ha) replikater av disse dataene.
Når jeg gjør et binærsøk på disken, helt uavhengig av filsystem, helt uavhengig av databasesystem eller applikasjon, så jeg ser blokker både fra slettede diskfiler, innslag i loggfiler, blokker innenfor en fil som ligger i en friliste, og i det hele tatt: absolutt alt, hvor sikkert er det at jeg aldri vil finne teksten "xyzzyfil"?
Det kan hende teksten er kryptert, men kunne databasesystemet dekryptere det før det ble slettet, da kan det også dekrypteres i ettertid; det er inen reell beskyttelse. Om "xyzzfil" ligger i klartekst eller kryptert er ikke av prinsipiell betydning. Hvis "xyzzfil" overhodet finnes på noen som helst disk, i allokerte eller frigjorte områder, inkludert samtlige sikkerhetskopier og logger, i det distribuerte systemet, da er i prinsippet et brudd på GDPR.
Det vil være vanskelig nok å få operatører tll å redegjøre for alle deres forekomster av logger og sikkerhets-kopier. I et heterogent DDBMs er det enda vanskeligere å få oversikt over alt som er av disker, loggfiler etc. For å være ærlig: Jeg tror neppe du behøver å hente inn samtlige replikater med sine logfiler og backups før du finner den første "xyzzyfil" ved binærsøk gjennom diskene fra blokk 0 og oppover.
Som en sjekk burde man naturligvis før slettingen logge inn på samtlige replikat-maskiner og verifisere at legning "xyzzyfil" er tilgjengelig der - både gjennom brukernivå-applikasjoner (enten det går gjennom en database med vilkårlig query-språk, eller annen mekanisme), og ved å søke på disker og (offline) logger for å verifisere at det er lagret persistent på noden. Så kan de samme stedene i de samme filene og lokasjonene oppsøkes direkte - men selvsagt kan også slettede data være flytet til andre steder, så det gjør ikke det fullstendige søket på disken unødvnedig.
Jeg har selvsagt ingen negativ holdning til at det blir holdt et øye med at hva folk som handterer personopplysninger "bør" og "kan" lagre er i samsvar med regelverket. Jeg bare tror ikke at normalt blir effektuert på en slik måte at 72 timer etter at en makør ("xyzzyfil") blir slettet (etter å ha figurert på maskinen i lengre tid og blitt replikert og sikkerhetskopiert i flere runder) ubetinget og absolutt vil være borte fra alle relevante online, offline logger og disker, og det samme på alle replkat-maskner.
Andre kan stole på det. Jeg er skeptisk, ihvertfall inntil jeg får en forklaring fra en ekspert som gir meg overbevisende svar på alle mine kritiske spørsmål.