- Formålet med Privacy by Design og Privacy by Default er at sikre, at selve designet og grundindstillingerne i løsningen gør det umuligt eller i hvert tilfælde meget svært at misbruge data, hvis det skulle slippe ud, siger Gert Læssø Mikkelsen, ph.d. i kryprografi og leder af Security Lab på Alexandra Instituttet. (Foto Stig Andersen).
Den 25. maj 2018 træder den nye EU-databeskyttelsesforordning i kraft i Danmark. Et af de overordnede mål med forordningen er at sikre den enkelte borgers ret til beskyttelse af personoplysninger – en ret som de senere år har været under stærkt pres på grund af både offentlige og kommercielle aktørers stadig mere effektive indsamling og anvendelse af persondata.
Forordningen indeholder en lang række elementer, der skal understøtte dette formål. Store bøder ved overtrædelse af forordningen og under visse omstændigheder krav om ansættelse af en Data Protection Office (DPO) har været de mest omtalte elementer, men der er andre vigtige bestemmelser i forordningen, som har direkte indflydelse på den måde, man designer og udvikler it-løsninger på. Forordningen indeholder således krav om ”databeskyttelse gennem design” og ”databeskyttelse gennem standardindstillinger”, nok bedre kendt som henholdsvis Privacy by Design og Privacy by Default.
Datalæk vil ske
– Erfaringerne viser, at når man designer nye it-løsninger, så skal udgangspunktet være, at der vil ske datalæk, hvor personoplysninger slipper ud. Præmissen med, at vi designer et system og bagefter beskytter det med diverse sikkerhedstiltag, holder ganske enkelt ikke. Formålet med Privacy by Design og Privacy by Default er netop at sikre, at selve designet og grundindstillingerne i løsningen gør det umuligt, eller i hvert tilfælde meget svært at misbruge data, hvis de skulle slippe ud, forklarer Gert Læssø Mikkelsen, ph.d. i kryptografi og leder af Security Lab på Alexandra Instituttet.
Beskyttelse af data skal således være en helt naturlig og integreret del af løsningen, og det må ikke være noget, der aktivt skal skal slås til i nogle indstillinger – løsningen skal være født med beskyttelsen slået til.
Selve konceptet Privacy by Design (PbD) blev udviklet i 1990’erne og publiceret i 2009 af Ann Cavoukian, der fra 1997 til 2014 var Information and Privacy Commissioner i den canadiske provins Ontario. Konceptet blev formuleret i syv grundprincipper som eksempelvis, at ”privacy er embedded i designet, at ”privacy er default”, og at privacy ikke må betyde, at man giver køb på ”full functionality”. I dag er disse principper de facto-definitionen af PbD-konceptet (se faktaboks).
Teknisk implementering
Rent teknisk implementeres PbD gennem en lang rækker teknologier og udviklingsprincipper, der går under betegnelsen Privacy Enhancing Technologies. Det handler blandt andet om anonymisering, pseudonymisering, dataminimering, kryptering, Information Lifecycle Management og andet, der bevirker, at koblingen mellem en fysisk person og persondata ikke er umiddelbart tilgængelig, og at data ikke indsamles og opbevares, ud over hvad der er nødvendigt i forhold til den specifikke anvendelse.
– Meget af det, som rent teknisk understøtter PbD, er allerede kendte discipliner. Pointen er, at man skal huske at tænke dem ind fra starten af designprocessen, siger Gert Læssø Mikkelsen, der henviser til otte guidelines defineret af ENISA (European Network and Information Security Agency) som gode og operationelle i forhold til den tekniske implementering af PbD (se faktaboks).
Birgitte Kofod Olsen, partner i Carve Consulting og i bestyrelsen for ”tænkehandletanken” DataEthics, peger også på ENISA’s guidelines som en rigtigt god indgang til PbD.
– ENISA foreslår to tilgange til implementering af tekniske løsninger i forhold til beskyttelse af persondata – en dataorienteret strategi og en procesorienteret. I deres guidelines er der gode eksempler på, hvordan databeskyttelsen kan tænkes ind fra starten på en måde, der opfylder databeskyttelsesforordningens krav, og de burde efter min mening være standard-tjeklister for alle udviklere, siger hun.
Privacy by Policy ikke tilstrækkeligt
Ifølge databeskyttelsesforordningens artikel 25 om ”Databeskyttelse gennem design og databeskyttelse gennem standardindstillinger” skal den dataansvarlige implementere ”passende tekniske og organisatoriske foranstaltninger”, der kan opfylde forordningens krav om beskyttelse af de registreredes persondata. Det er således ikke tilstrækkeligt at indføre procedurer og politikker i sin organisation til sikring af databeskyttelsen – såkaldt Privacy by Policy – der skal anvendes værktøjer fra teknikkassen.
– Der ligger to supplerende krav i forordningen: en organisatorisk og en teknisk. I praksis betyder det, at politikker og procedurer skal sætte rammen for, hvordan man arbejder med Privacy by Design og Privacy by Default, og at de tekniske løsninger skal være udviklet på en måde, så de i sig selv bidrager til, at databehandlingen foregår i overenstemmelse med principper som formålsbestemthed, nødvendighed, korrekthed og opbevaringsbegrænsning, forklarer Birgitte Kofod Olsen.
Ifølge Gert Læssø Mikkelsen har offentlige og private virksomheders tilgang til persondatabeskyttelse hidtil ligget mere inden for Privacy by Policy end Privacy by Design. Det håber han, at databeskyttelsesforordningen kan ændre på.
– Jeg håber, at den nye forordning kan fungere som en katalysator, der virkelig kan rette fokus på det her område og få både offentlige og private virksomheder til at tage det alvorligt. Vi har jo allerede lovkrav på det her område, men de bliver desværre ikke efterlevet i særligt høj grad, siger han.
Samme billede ser Birgitte Kofod Olsen:
– Det kan jo ikke udelukkes, at nogle virksomheder i praksis allerede har implementeret PbD for at leve op til den nuværende lovgivning, men det er ikke mit indtryk, at en sådan tilgang er særlig udbredt. I den nye forordning bliver det til gengæld et retligt krav, at man implementerer PbD, siger hun.
Eksisterende systemer
Der er i forordningen ikke noget krav om, at eksisterende systemer skal redesignes ud fra principperne i PbD. De eksisterende systemer skal dog kunne understøtte, at de øvrige bestemmelser i forordningen overholdes, og større ændringer i eksisterende løsninger kan udløse krav om PbD.
– Da meget af databehandlingen efter maj 2018 jo vil foregå på ”gammelt” udstyr, vil man skulle tjekke sine løsninger med henblik på at fastslå, om databehandlings- og sikkerhedskravene kan opfyldes. Og ved større ændringer af eksisterende løsninger og services eller indkøb af nye vil det være nødvendigt at forholde sig til behovet for PbD, siger Birgitte Kofod Olsen.
Gert Læssø Mikkelsen kan frygte, at det forhold kan få nogle virksomheder til at køre videre med ældre, halvdårlige systemer for at undgå at skulle investere i en PbD-implementering.
– Jeg synes faktisk ikke, at forordningens krav til PbD er så høje, at det kan bruges som en undskyldning for at undlade at udskifte ældre systemer, siger han.
I det hele taget mener han ikke, at PbD i sig selv kan betragtes som et fordyrende element.
– I starten er det selvfølgelig en investering, men dels vil den øgede sikkerhed kunne betyde besparelser i driften, dels vil det efterhånden forhåbentlig bliver indarbejdet som en fuldstændig naturlig og integreret del af systemudvikling, mener Gert Læssø Mikkelsen, som klart ser en rolle for de tekniske medarbejdere i forhold til PbD.
– Systemarkitekterne bør tænke PbD ind som en helt naturlig ting, og den enkelte udvikler skal også altid have det i baghovedet. Det er vigtigt, at udviklerne til hver en tid kan komme med indspark til, hvordan man sikrer databeskyttelsen med tekniske løsninger og ikke blot gennem politikker og procedurer, siger han.
