Testdatahantering i relation till GDPR : En studie om risker, maktförhållande, dominans och utanförskap som en följd av GDPR

Örebro universitet

Handelshögskolan – Informatik Uppsatsarbete, 15 hp

Handledare: Andreas Ask Examinator: Mathias Hatakka HT18 - 2019-01-11

Testdatahantering i relation till GDPR

En studie om risker, maktförhållande, dominans och utanförskap som en följd av

GDPR

Sammanfattning

Efter att General Data Protection Regulation (i fortsättningen förkortat GDPR) i maj 2018 ersatte den tidigare Personuppgiftslagen har verksamheter som bearbetar och lagrar

personuppgifter behövt ändra sina arbetssätt för att leva upp till kraven som GDPR ställer på dem. Denna förändring har inte minst påverkat hur verksamheterna arbetar med

testdatahantering där personuppgifter ingår i deras testdata. Studien granskar därav hur verksamheter numera arbetar med testdata samt vilka teknikval de gjort efter GDPRs införande. Syftet med denna studie är vidare att undersöka de risker som finns med de tekniker som finns för att hantera testdata i relation till GDPR. Datainsamligen har

genomförts med kvalitativ ansats genom litteratursökning och intervjuer inom ämnesområdet testdatahantering.

Studiens resultat visar att det föreligger risker i främst arbetssättet, snarare än val av metod och teknik. Konsekvenser av den centrala aktören GDPR blir makt över verksamheters arbetssätt och inte metoder eller tekniker i deras renaste form.

Innehållsförteckning

1. INTRODUKTION... 7

1.1. INLEDNING ... 7

1.2. BAKGRUND & TIDIGARE FORSKNING ... 7

1.3. FRÅGESTÄLLNING OCH SYFTE ... 8

1.4. PROBLEMATISERING AV FORSKNINGSFRÅGA ... 9 1.5. AVGRÄNSNING ... 9 2. TEORI ... 9 2.1. ACTOR-NETWORK THEORY ... 9 FIGUR 2.1.1. ...11 3. METOD...12 3.1. VAL AV ANSATS ...12 3.2. LITTERATURSÖKNING ...12 3.3. DATAINSAMLING ...13 3.3.1. DATAANALYS ...14 3.4. TILLÄMPNING AV ANT...15 3.5. ETIK ...16 3.6. METODKRITIK ...16

4. RESULTAT & ANALYS ...16

4.1. NÄTVERKET ...16

4.2. RELATIONER I NÄTVERKET ...18

4.2.1. ANONYMISERING SOM METOD ...18

4.2.2. PSEUDONYMISERING SOM METOD ...20

4.3 TEKNIKER FÖR PSEUDONYMISERING...20 4.3.1. KRYPTERING ...21 4.3.2. MASKERING ...21 4.3.3. HASHKODNING ...22 4.3.4. KRYPTOGRAFISK HASHNING ...23 4.4. TEKNIKER FÖR ANONYMISERING ...23 4.5. TEKNIKNEUTRALITET ENLIGT GDPR ...24 4.6. ARBETSSÄTT ...24

4.6.1. BEHÖRIGHETSHANTERING & TILLGÅNG ...24

4.6.2. RISKBEDÖMNING SOM ARBETSSÄTT ...27

4.6.3. PRIVACY BY DESIGN SOM ARBETSSÄTT (EN DEL AV GDPR) ...27

4.7. SAMMANFATTNING AV RELATIONER ...28

5. DISKUSSION ...29

5.1. NÄTVERKETS AKTÖRER & RELATIONER ...29

5.3. VILKA TEKNIKER FINNS DET FÖR ATT HANTERA TESTDATA GENTEMOT GDPR OCH VILKA RISKER KAN

DESSA TEKNIKER INNEBÄRA? ...31

6. SLUTSATS OCH BIDRAG ...33

6.1. SLUTSATS ...33

6.2. BIDRAG & FÖRSLAG PÅ FRAMTID FORSKNING ...34

Centrala begrepp

Nedan presenteras de centrala begrepp som uppsatsen kommer att beröra.

General Data Protection Regulation: GDPR gäller inom hela Europeiska unionen. GDPR gäller alla typer av verksamheter oavsett vem det är som behandlar personuppgifterna. (Datainspektionen, 2018)

Risk: En risk innebär att något oönskvärt skulle inträffa, dvs att negativa konsekvenser skulle uppkomma till följd av en händelse eller hantering. (”Risk”, u.å)

Data: Data i sig innehåller inte information utan det är något som utvinns ur en process där data ingår. (Langefors, 1995)

Testdata: Den data som specifikt har identifierats till att användas vid mjukvarutestning. Viss testdata kan användas på ett bekräftande sätt där det t.ex. finns en funktion som kräver att man anger ett namn och inputen, dvs det namn som angivits, ska i sin tur producera ett förväntat resultat.(Datainspektionen, 2014)

Test: Med hjälp av tester säkerställer man kvalitén i ett system och reducerar bland annat utvecklings- och förvaltningskostnader. Kvalité innebär vidare att samtliga egenskaper hos en produkt eller tjänst tillfredsställer underförstådda eller uttalade behov. (Eriksson, 2007) Testerna utgörs dels av funktionella- och prestandatester som i sin tur förekommer i 3 olika faser; system-, integrations- och acceptanstester. (Datainspektionen, 2014)

Produktions- och testmiljö: Innan ett system eller nya funktioner kan implementeras i ett nytt eller befintligt system bör de testas och verifieras, vilket de gör i en s.k testmiljö. Med testmiljö menas då i den miljö som testerna sker i, i enlighet med processer, rutiner och allmänt erkända riktlinjer för den aktuella verksamheten eller industrin. Denna miljö är då skild från den faktiska produktionsmiljön där systemet är i bruk av riktiga användare. De funktioner som i produktionsmiljö t.ex. skulle innebära mailutskick, är avstängda i testmiljön för att inte användarna av systemet ska påverkas. (Datainspektionen, 2014)

Personuppgifter: Information som kan identifiera eller associeras med en levande person. Uppgifterna kan vara i form av t.ex. namn, fotografi, kreditkortsuppgifter, personnummer, adress eller ljudinspelningar som kan knytas an till någon. Detta innebär då att all

information som kan kopplas till en levande person är klassat som en personuppgift. Ett registreringsnummer på någons bil kan t.ex. kopplas till en fysisk person medan

registreringsnumret på en företagsbil som nyttjas av flera personer inte kan kopplas till en enskild individ inte är en personuppgift. (Datainspektionen, 2014)

Känslig data: Beskriver data som i fel händer kan användas för att skada eller äventyra personlig integritet. Generellt definieras känslig data som att om den går förlorad löper det stor risk att skapa skadliga konsekvenser för en privatperson eller verksamhet. Med skadliga

konsekvenser menas de konsekvenser som kan uppstå när data går förlorad som kan skada viktiga samt rättsliga överenskommelser eller avtal. Detta kan t.ex. göra stor skada på en verksamhets organisationella rykte men också finansiella- eller affärshemligheter kan gå förlorade eller hamna i fel händer. (Ohm, 2015)

Relationsdatabas: Databasen är organiserad enligt relationsmodellen, vilket innebär att data representeras och lagras i tabeller. Tabellerna överlappar om de har en gemensam nyckel, dvs en rad i vardera tabell som representerar samma data. (Padron-Mccarthy & Risch, 2018)

1. Introduktion

1.1. Inledning

Ett fall där testdatahanteringen innehållande information om privatpersoner inte skett på ett korrekt sätt är t.ex. fallet med SJ 2014. Personalen som genomförde testerna på

verksamhetens kundsystem misstog sig i tron om att de arbetat i testmiljö egentligen arbetat i produktionsmiljö. Detta resulterade i sin tur i konsekvenser för SJs kunder då deras

personuppgifter användes i produktionsmiljö, dvs det riktiga systemet som egentligen är avsett att nyttjas av kunden själv. Flera kunder påverkades då bl.a. av att fakturor och biljetter skickades till dem. (Datainspektionen, 2014) Detta fall visar på sårbarheten hos

personuppgifter om deras lagring och bearbetning i samband med att test inte reglerats utifrån en organisatorisk standard. (Narayanan, 2017)

Politiker inom Europeiska Unionen (i fortsättningen förkortat EU) har länge diskuterat möjligheten att införa nya regler gällande skyddandet av personlig data. Som följd av detta trädde den 25 maj 2018 en ny förordning i kraft som ersatte Personuppgiftslagen (i

fortsättningen förkortat PUL). (Datainspektionen, u.å) Lagen känd som

dataskyddsförordningen eller GDPR, har i syfte att skydda medborgares personuppgifter samt se över hur personuppgifter bearbetas och lagras. Detta innebär i sin tur att informationen måste bearbetas på ett korrekt sätt för att säkerställa att lagar och föreskrifter följs och att tester som genomförs med denna information är tillförlitlig. (Art.5 EU 2016/679)

Detta möjliggör för EU att genom denna förordning reglera makt. (Nature, 2018).

Vidare så lagras och bearbetas information om privatpersoner med hjälp av olika metoder och tekniker. Detta kan leda till utanförskap i den bemärkelse att de metoder och tekniker som finns för just lagring och bearbetning av data som inte uppfyller kraven i GDPR inte används i lika stor utsträckning, vilket innebär att det uppkommer dominansförhållande mellan dessa aktörer i form av metoder och tekniker i relation till GDPR. (Oates, 2006)

Vi kan då fråga oss om det kan ha uppstått ett maktförhållande, utanförskap och dominans bland aktörerna och deras relationer i och med GDPRs införande?

1.2. Bakgrund & tidigare forskning

Testdata i sig är data som används vid test av mjukvara och den kan t.ex. vara verklig

produktionsdata, produktionsdata som anonymiserats eller vara fiktiv. (SJ, 2014) Beroende på vilka typer av tester som en verksamhet vill genomföra, kan hanteringen av testdata skilja sig åt. Den tidigare forskning som finns om testdatahantering handlar bl.a. om att förbättra och förenkla hantering av testdata med hjälp av mjukvara som verktyg. Det gör det möjligt för utvecklarna som testar att anpassa sin testdata utifrån förändrade krav eller uppdaterade versioner av programvaran som testerna körs på. (Nagowah och Doorgah, 2012) I fallet med SJ (se ovan) var det t.ex. verklig data som användes i vad de trodde var test och där

hanteringen av testdata fick konsekvenser. Den tidigare forskningen knyter an till denna problematik av testdatahantering men lyfter inte de risker som valet av teknik, i samband med hanteringen, kan medföra.

Forskarna Manikas och Eichenlaub har även undersökt hur bättre hantering av testdata kan förbättra kvalitén och reducera kostnaderna för en verksamhet som t.ex. säljer en produkt. I en stor produktion anses det viktigt att samla mycket testdata för att succesivt och effektivt öka kvalitén på sin produkt vilket gör deras tidigare forskning industriellt nischad. De menar på att en bättre hantering av testdata som sedan används för att öka hela processens kvalité med resultatet lägre kostnad per produkt såld. (Manikas & Eichenlaub, 1989)

GDPR är, som tidigare beskrivet i kapitel 1.1., en förordning som syftar till att

skydda medborgares personuppgifter samt se över hur personuppgifter bearbetas och lagras. 2012 lades lagförslaget om GDPR fram och mycket av den forskningen som gjorts mellan 2012 (EU, 2018) och 2018 när den blev lag, har varit studier som speglar spekulationer och hypoteser kring vilken inverkan GDPR skulle komma att ha på t.ex. medicinbranschen (McCall, 2018) och internet som en användarcentrerad platform (Sobolewski, Mazur & Paliski,2017)

Tidigare forskning beskriver också att pseudonymisering inte är en definition under GDPR som beskriver personlig data men att all data som går under den definitionen är personlig data. Det gör det möjligt att i forskning kunna använda sig av pseudonymiserad data och att personliga uppgifter hanteras korrekt utifrån GDPR. (Mackey & Elliot, 2018)

Kunskapsbehovet som identifierats i samband med granskning av tidigare forskning inom ämnesområdet är att den forskning som existerar för testdatahantering i relation till GDPR mestadels har koncentrerats på hur verksamheter (vilket i våran studie innefattar två myndigheter) kan effektivisera sin testdatahantering utifrån GDPR.

Detta innebär då att den forskning som finns inom ämnesområdet, till större del täcker upp aspekter som gynnar verksamheter och inte lika mycket de risker som verksamheter egentligen tar när de arbetar med testdata och personuppgifter, se fallet med SJ ovan.

Vi menar därav på att en studie som koncentrerar sig på hur verksamheter egentligen praktiserar den nya lagen och vilka risker/nackdelar kontra chanser/fördelar GDPR har inneburit vad det gäller verksamheternas testdatahantering och risker, behövs. Genom att sedan betrakta denna problematik ur ett ANT-perspektiv (se Teoriavsnitt) kan vi tydliggöra relationerna mellan de olika aktörerna och på ett tydligare sätt kartlägga konsekvenserna som GDPR inneburit för verksamheterna.

1.3. Frågeställning och syfte

Hur arbetar verksamheter med testdatahantering?

Vilka tekniker finns det för att hantera testdata gentemot GDPR och vilka risker kan dessa tekniker innebära?

Syftet är att undersöka de risker som finns med de tekniker som finns för att hantera testdata i relation till GDPR.

1.4. Problematisering av forskningsfråga

GDPR är en lagstiftning som påverkar alla aktörer som lagrar eller bearbetar personuppgifter (Narayanan, 2017). Detta innebär i sin tur att en verksamhet, som arbetar med lagring eller bearbetning av personuppgifter, är beroende av fungerande arbetssätt som är förenliga med bestämmelserna i GDPR. Med detta som grund är det vidare viktigt att undersöka hur verksamheters arbetssätt kan se ut och med vilka metoder och tekniker som arbetssätten realiseras genom. Alla metoder och tekniker som en verksamhet väljer att arbeta utifrån i samband med lagring och bearbetning av personuppgifter ska vara riskbaserade enligt GDPR (Art.76 EU 2016/679). Detta ger i sin tur upphov till frågan om vilka risker verksamheter egentligen tar i samband med val av metod och teknik, speciellt om den data som de använder i sina tester av mjukvaror är riktiga personuppgifter. Alla aktörer, dvs metoder, tekniker, arbetssätt och verksamheter förenas kring aktören GDPR, vilket gör GDPR till en central aktör och tillsammans bildar de ett nätverk där de existerar i relation till varandra. Detta nätverk blir, givet beskrivningen ovan och det identifierade kunskapsbehovet, aktuellt för granskning vad gäller testdatahantering i relation till GDPR.

1.5. Avgränsning

Vi har valt att undersöka två större verksamheter som behandlar personuppgifter i sin

testdatahantering då mindre verksamheter inte besitter samma volym lagrade personuppgifter. Nätverket är avgränsat utifrån vårt teoretiska ramverk ANT (se Teoriavsnitt) och hur ANT definierar aktörer och relationer. De aktörer som identifierats är avgränsade till att endast ha en relation till GDPR då det är centralt i vår frågeställning. Vi kommer inte att undersöka privatpersoner som aktör då det inte har någon relevans i samband med frågeställningen eller nätverket. Inom GDPR har vi avgränsat oss till att endast undersöka metoder kopplat till lagring och bearbetning av personuppgifter då det blir relevant i relation till studiens frågeställning och syfte. Teknikerna som undersökts i studien, är de tekniker som

verksamheterna eller litteraturen lyfter fram. Vi har endast undersökt hanteringen av testdata utifrån teknikerna och därav avgränsat oss från implementation av tekniker, dvs. vi

undersöker vad teknikerna gör inte hur de fungerar. Vidare undersöker vi specifikt de risker som myndigheterna själva identifierat parallellt med GDPR för att uppfylla syftet och besvara frågeställningen.

2. Teori

2.1. Actor-Network Theory

Vi bedömer att det teoretiska ramverket Actor-Network Theory (i fortsättningen förkortat ANT) är en lämplig teori eftersom vi vill se över maktförhållandena mellan aktörer och hur de

påverkar varandra. Denna studie är baserad på ANT då den inte gör en distinktion mellan mänskliga och omänskliga beståndsdelar som man inom ANT kallar för aktörer som tillsammans bildar ett nätverk. En mänsklig aktör är någonting som har motivationer,

intentioner och önskningar till skillnad från en omänsklig aktör som har förmågan att svara på förändring i ett nätverk. När dessa aktörer enas kring något så skapas ett nätverk och om någon av aktörerna skulle tas bort från nätverket slutar nätverket att existera och ett nytt nätverk uppstår. (Law, 2007) Övergripande bygger ANT på aktörer, deras relationer som i sin tur bildar ett specifikt nätverk.

ANT är ett teoretiskt angreppssätt på social teori där allt socialt (aktörer) existerar i ett nätverk i relation till varandra. ANT menar på att ingenting existerar utanför de relationerna och ingen extern social kraft utanför nätverket kan påverka hur de olika aktörerna interagerar med varandra. Grunden i ANT är att undersöka hur nätverk är upprättade och underhållna för att uppnå ett specifikt ändamål. (Carroll, Richardson & Whelan, 2012)

ANT bygger på att beskriva ett fenomen istället för att förklara det, dvs den beskriver hur och inte varför ett fenomen har vissa grunder. (Law, 2007) Detta styrker också Mol (2010) med sin syn på att ANT ska generera, omvandla, översätta och berika ett fenomen, vilket blir berättande istället för förklarande. Därav kan man se ANT som ett verktyg för att beskriva hur något är eller inte är. Genom att använda sig av ANT så ger det en mer övergripande

beskrivande bild av hur mänskliga och omänskliga aktörer interagerar med varandra istället för att, som inom social teori, där dessa aktörer skiljs åt. Detta innebär, inom ramen för denna studie, att vi kommer att undersöka hur verksamheter arbetar med testdatahantering och inte varför de arbetar som de gör.

Inom ANT ser man till interaktionen mellan olika aktörer istället för självaste aktören som en självständig beståndsdel då aktören får sin mening genom relationerna till andra aktörer. Detta innebär även att en aktör inte kan plockas bort ur nätverket då den har en kontextuell

påverkan på resten av relationerna i nätverket. Aktören är trots allt en effekt av sina relationer med andra aktörer, vilket gör hela nätverket till ett komplext sådant. Om fallet dock skulle vara att man vill analysera dess karaktäristiska drag och attribut så kan aktören isoleras, men inte i något annat syfte. (Law & Hassard,1999)

Eftersom att aktörer är effekter av relationer i ett nätverk, innebär det även att de inte kan innehålla handlingar då det är deras relationella dimension som genererar instanser av handling, dvs. aktörernas relationer till varandra skapar potentiell handling (aktantialitet). (Law & Hassars, 1999) Detta kan t.ex. innebära att aktören “Polis” existerar som en effekt av relationen till aktören “Lag” och verkar för att upprätthålla lag. När det gäller generering av aktantialitet så genereras det i förhandling och det är i denna process som aktörer genereras och omdefinieras i deras olika sammanhang. Eftersom att aktörer, enligt ANT, existerar i handling så innebär det att relationen mellan två aktörer likt lagar och polis befinner sig i ett ständigt förändrat tillstånd. (Law, 1999) I relation till vårt ämnesområde så motsvarar det relationen mellan GDPR och verksamheter som måste och kommer att påverka varandra. Dvs.

att de aktörer som är inkluderade i nätverket existerar utifrån sina relationer till varandra där handlingar mellan aktörer sker i relationen som är upprättad mellan dem.

Se figur 2.1.1 som är ett schematiskt exempel på ett enkelt nätverk bestående av det vi tar upp ovan gällande polis och lag.

3. Metod

3.1. Val av ansats

Studienhar genomförts med en kvalitativ ansats där vi i vår datainsamling skapat frågor till de kvalitativa studier där vi valt att göra intervjuer, som beskrivs i avsnitt3.3. (Oates, 2006) Intervjuerna har genomförts på två större verksamheter, eftersom att vi utifrån vår

frågeställning är intresserade av att veta hur dem, som aktörer, arbetar med testdatahantering. Utifrån den datainsamling som vi genomfört, har vi jämfört och dragit slutsater utifrån ett ANT-perspektiv, vilket innebär att vi identifierat aktörer och relationerna dem emellan. Utöver den kvalitativa ansatsen har vi även utgått ifrån vetenskaplig litteratur och tidigare forskning då detta är en vetenskaplig studie.

3.2. Litteratursökning

Webster och Watson (2002) rekommenderar ett strukturerat tillvägagångssätt när man ska söka litteratur, vilket innebär att man bör utgå ifrån etablerade databaser. Vi har då utgått ifrån Ämnesguiden för Informatik via Örebro universitets hemsida där ett flertal databaser finns listade.

Ytterligare källor som vi utgått ifrån är bl.a. Nationalencyklopedin då det är forskare som författat texterna. Vi har även använt Datainspektionen som en källa då vi anser att dem, som statlig tillsynsmyndighet, lägger en grund för hur andra verksamheter inom samma område ska arbeta. Ett kriterium har varit att litteraturen måste vara skriven på engelska eller svenska för att vi ska ha förutsättningarna att inte misstolka innehållet på grund av fel i översättningen.

Då informatik är ett brett ämnesområde så har vi valt att inte bara avgränsar vårt sökande till informatik utan också tittar på forskning som kan ha en koppling till informatik. Därför har vi valt att också söka efter artiklar rörande GDPR som har en koppling till testdatahantering och dess tekniker. Vi har även sökt efter litteratur som behandlar GDPR i sin helhet och som gett oss bättre förståelse för regelverket. (Webster & Watson, 2002)

När vi sökt efter litteratur har vi följt Webster och Watsons (2002) rekommendation och använt oss av vedertagna databaser när vi sökt litteratur, främst databasen Primo som innehåller det mesta av Örebro universitets samlingar litteratur. IEEE Explore är en teknikorienterad databas som vi har använt för att hitta litteratur med fokus på tekniska aspekter av ämnesområdet vi valt.

Sökorden vi har valt för att hitta litteratur som matchar ämnesområdet är “gdpr”, “gdpr test data”, “test data management”, “gdpr research”, “tools test data”, “test data”, “testdata”, “test data generation” och “personal data”, “gdpr sensitive data*”, “cryptogrphic hash function”, “kryptografi”, “kryptografisk hashning”, “kryptografisk hashfunktion”, “maskning”, “masking”, “hashtabell”, “hash table”, “hash function”, “masking technique”, “pseudonymization technique”, “pseudonymization gdpr”.

När vi har sökt litteratur har vi använt trunkering vilket innebär att sätta en asterisk efter eller innan ett ord för att inkludera resultat som börjar eller slutar med det ordet man sökt efter. Vi har också sökt genom att använda frassökning för att begränsa resultatlistan till att använda precis den sökningen vi angivit. De sökningar som gett flest träffar har varit “test data” och “test data tools”.”Test data” gav oss 343 484 träffar och ”test data tools” gav oss 1 560 014 träffar. Då vi fick väldigt många träffar, utgick vi först från titeln på en artikel för att bedöma om den var relevant till vårt forskningsområde. Därefter läste vi artikelns abstract för att få en djupare förståelse för artikelns innehåll. Genom att tillämpa detta tillvägagångssätt gick det att avgränsa den höga sökträffsmängden. Övriga sökningar gav mindre träffar då vi använde frassökning som tex. ”gdpr test data” som då endast gav 2 träffar. Valet av de artiklar som användes var baserade på relevans. Med relevans menas i detta fall artiklar som hade en direkt koppling till testdata, GDPR eller tekniker som vi kunde se användes vid

hanteringen av testdata. Då vi fick många träffar i både Primo och IEEExplore valde vi att använda oss av de källor som vi ansåg gav oss tillräckligt med underlag för att gå vidare med studien.

Vi har analyserat litteraturen ur ett ANT-perspektiv och letat efter kopplingar mellan de aktörer som rapporten behandlar, som t.ex.; GDPR, verksamheter och tekniker. All litteratur vi funnit har inte visat på kopplingar mellan de olika aktörerna och därför inte tagits med i resultatet, dock har vi hittat data som vi kunnat använda som kunskapsunderlag i rapporten. Detta underlag har hjälpt oss att förstå vilka aktörer som är relevanta att undersöka i relation till avgränsningen i denna studie.

3.3. Datainsamling

Då vi har intervjuat två personer som är verksamma inom testdatahantering vid två större verksamheter, Verksamhet 1 och Verksamhet 2. Person 1 arbetar som enhetschef på sin verksamhets IT-avdelning och person 2 arbetar som IT-säkerhetsansvarig vid sin verksamhet. De har gett en beskrivande bild av hur de hanterar och arbetar inom ämnet testdatahantering. Vi bedömde innan intervjun att en ostrukturerad intervju var lämplig då respondenternas svar blir empiriskt grundande för vårt resultat. Enligt Oates (2006) är en ostrukturerad intervju mest lämpad där den som blir intervjuad får mer spelrum i ämnet och där personen påverkas så lite som möjligt av oss som intervjuar. Det hjälper oss som forskare att därefter skapa en förståelse över hur relationer mellan aktörer i testdatahantering påverkar varandra, framförallt hur GDPR som en icke mänsklig aktör påverkar nätverket. Därför ville vi ge respondenten så mycket utrymme som möjligt där vi som intervjuar är med och påverkar så lite som möjligt.

Även om det enligt Oates finns alternativ till helt ostrukturerade intervjuer likt

semi-strukturerade intervjuer och semi-strukturerade intervjuer var vår bedömning att vi inte i lika stor utsträckning kan förstå hur dessa aktörer agerar inom ramen för det nätverk vi definierat. I och med det ansåg vi att ostrukturerade intervjuer passade vår forskningsfråga eftersom att vi ville få respondenterna att svara utifrån deras verksamhet.

Enligt Oates (2006) är det viktigt att ha varit i kontakt med respondenten innan intervjun för att säkerställa deras position i verksamheten då det skapar en förståelse för oss om vilken typ av frågor vi behöver ställa. Genom det anser Oates (2006) också att trovärdigheten ökar inför respondenterna vilket i sin tur leder till att vi som intervjuare lämnar ett mer seriöst intryck samt visar att de är en relevant källa i våran forskning. De ämnen vi frågat kring består av, “testdatahantering” och “tekniker” som är kopplade till GDPR. Frågorna och ämnena har också skickats till respondenterna i god tid innan intervjuerna ägt rum för att ge dem tid att fundera och förbereda deras svar. Frågorna vi ställt är öppna frågor som “varför”, “hur” och “vad” då det möjliggör för diskussion och ger oss ett mer omfattande svar och öppnar upp för diskussion. Då det är respondenten som driver samtalet kan vi med hjälp av följdfrågor skapa möjlighet till mer uttömmande svar vilket ger oss större mängd data att utgå ifrån i analysen. Detta innebär vidare att vi får en större förståelse för hur aktörerna i nätverket agerar i relation till varandra. Samtidigt så ger vi respondenten möjlighet att tala fritt så vi får en så tydlig och ärlig bild av just deras verksamhet som möjligt. Detta kan vi i vår tur sätta i relation till de aktörer vi undersökt och se över om verksamheterna faktiskt gör som det är tänkt att de ska göra enligt regelboken. Våra intervjuer har spelats in och vi har antecknat och ställt

följdfrågor som dykt upp under intervjun. Då vi har spelat in kan vi i lugn och ro efter

intervjuerna gå igenom materialet igen och göra en djupare analys och transkribera svaren. Vi är medvetna om risken med att de vi intervjuar kan påverkas och blir nervösa av att intervjun spelas in därav vikten av att ha en god relation innan intervjun genomförts. (Oates, 2006)

Efter intervjuerna har vi transkriberat våra inspelningar och skrivit ner de svar vi fått samt noterat där följdfrågor har dykt upp. Då vi genomförde en ostrukturerad intervju där

respondenten fick tala fritt antecknade vi endast följdfrågor som dök upp under intervjun. På det sättet kunde vi ha fullt fokus på respondenten och försäkra oss om att vi fick svar på och kunde samla den information som var nödvändig för vårt resultat. Transkribering av

intervjuerna har skickats till våra respondenter innan vi skapat vår analys. Detta för att säkerställa att den överensstämmer med vad respondenten talat om och att den motsvarar deras uppfattning om vad de har sagt. Verksamhet 1 valde efter att ha tagit del av

transkriberingen att be oss stryka en del av den data vi samlat från dem. Detta har lett till att empirin från verksamhet 1 är mindre än den empiri som finns för verksamhet 2. Enligt Oates (2006) bör citat från intervjuerna framgå i studien då empiri är i sin klaraste form när den citeras.

Varje intervju pågick i cirka en och en halv timme och efter transkribering uppskattar vi att vi kunnat samla ungefär en timme data för vår analys och resultat per intervju. Vi har också tagit del av respondenternas dataskyddspolicy för att sätta respondenternas svar i relation till vad verksamheterna säger sig göra.

3.3.1. Dataanalys

Vi har i efterhand lyssnat på inspelningarna och utifrån vår teoretiska ansats ANT kunna identifiera aktörer och deras relationer till varandra inom studiens avgränsade ämnesområde testdatahantering. Vi har då under analysen av den insamlade datan kunnat se att vissa aktörer

ingår i andra och vissa aktörer behöver brytas isär till en egen. T.ex. ansåg vi att aktören personal kunde ingå i aktören verksamhet istället för att ha de som två separata aktörer. Säkerhetspolicys praktiseras exempelvis av personalen inom en verksamhet, vilket gör att de blir egenskaper hos aktören verksamhet. Varken säkerhetspolicys eller personal behöver därmed separeras från aktören verksamhet i denna studie då de inte granskas eller analyseras i relation till frågeställningen och syftet. Vidare har vi identifierat metoder och tekniker som två separata aktörer då de existerar i relation i varandra där metoder endast kan realiseras genom en teknik och där teknik kategoriseras in i en metod. Teknikerna som analyserats i denna studie har därefter valts ut utifrån det som framkommit i litteratursökningen och den insamlade empirin. Bedömningen av vilka tekniker som är relevanta har gjorts utifrån kontexten för den insamlade empirin. För att t.ex. förstå vad en krypterad hashfunktion är så är det nödvändigt att veta vad kryptering och hashning är.

Sammanfattningsvis har vi genom vår dataanalys identifierat olika aktörer och därefter byggt ett nätverk. Sedan har en noggrann övervägning, kategoriserat dem för att se om de går att bryta isär eller bör tillhöra samma aktör. Detta för att skapa ett strukturerat nätverket där relationerna mellan aktörerna blir väsentliga.

3.4. Tillämpning av ANT

I vårempiriska studie har vi samlat och tolkat data för att sedan skapa en förståelse för hur aktörer i nätverket skapar mening genom de relationer som finns mellan aktörerna i nätverket. Myers & Walsham (1998) menar att ANT är ett bra verktyg för detta. Att samla, analysera och tolka data så att nätverken och dess relationer kan förstås utifrån den mening som aktörer ger dem. Genom de intervjuer vi genomfört har vi identifierat aktörer och deras relationer till varandra samt det nätverk som de befinner sig inom. Givet detta kommer vi att kartlägga aktörer samt deras relationer sinsemellan för att tydliggöra hur de tillsammans bildar ett aktörsnätverk samt se vad det finns för maktförhållanden. Oates (2006) talar om

maktförhållanden, sammanstötningar, utanförskap och dominans. Då vi har identifierat flera aktörer i ett nätverk blir det givet att det uppstår ett maktförhållande, då någon form av maktförhållande alltid uppstår där det finns två eller fler aktörer inblandade. Vi har, utifrån Oates (2006), syn på maktförhållanden och sammanstötningar mellan de aktörer vi identifierat och hur dessa måste anpassa sig efter varandra. Därefter har vi sett över vad detta inneburit för aktörerna och om detta eventuellt lett till någon dominans eller utanförskap mellan dem. Genom att applicera Oates perspektiv ser vi att våran ANT-teori blir mer lämpad då vi kan jämföra aktörers olika maktförhållanden och påverkan på varandra som i sin tur påverkar nätverket vi undersöker.

Då vi har kunnat identifiera aktörer, deras relationer och utifrån det satt dem inom ramen för ett nätverk och samtidigt applicerat det på Oates perspektiv så bedömer vi att ANT är en lämplig teori att grunda vår studie på.

3.5. Etik

Etik har varit en aspekt vi tagit i beaktande i samband med vår datainsamling då vi interagerat med andra människor i våra intervjuer. Därför har de som intervjuats informerats om och givit sitt samtycke om att samtalen under intervjuerna spelats in. Innan intervjuerna ägt rum har respondenterna informerats om studiens syfte och även efter intervjuerna tagit del av

respektive transkribering. Detta för att säkerställa att vi uppfattat respondenterna korrekt samt att de ska kunna förtydliga aspekter som de upplever att de varit otydliga om. Det ger dem också möjlighet att se att vi inte har påstått någonting som de inte gjort. Därefter har vi tolkat deras svar utifrån vår teoretiska grund.

3.6. Metodkritik

Två respondenter kan anses vara en för liten grund för att få tillförlitlig data. Vi är medvetna om detta men då intervjuerna blev så pass långa (tidsmässigt) så gjorde vi bedömningen att mängden data som vi samlade in, var av tillräcklig mängd för att kunna presentera ett tillförlitligt resultat.

Vi är vidare även medvetna om bredden och komplexiteten som ANT innefattar. Dock har vi valt att anpassa teorin och därav valt ut de delar som vi anser vara lämpliga för att ge oss den teoretiska ansats vi anser uppfyller vår studies behov. Detta kan vara problematiskt då det kan anses att vissa väsentliga delar av ANT inte används. Vi anser dock att i förhållande till omfattningen på denna studie blir det mer lämpat att endast tillämpa vissa delar av ANT för att få den teoretiska grund vi anser oss behöva för att genomföra den aktuella studien.

4. Resultat & analys

4.1. Nätverket

Nätverket som resultatet och analysen är byggd på är baserat på den sociala situationen kring testdatahantering där GDPR är centralt. Den centrala aktören är GDPR och aktanter under GDPR-aktören är t.ex. lagar och regler. Andra aktörer som inkluderas i nätverket är

verksamhet, tekniker, metoder och arbetssätt där alla har en relation och påverkar varandra på ett eller annat sätt. Skulle en av dessa aktörer försvinna faller hela nätverket och nätverket testdatahantering som vi undersökt skulle upphöra att existera. Existensen skulle upphöra då vi anser att alla aktörer är nödvändiga för att få en förståelse samt grund för testdatahantering i verksamheter. Figur 4.1.1. presenterar alla identifierade och dess relationer sinsemellan.

GDPR som aktör: GDPR är en lagstiftning som alla verksamheter, som behandlar eller lagrar personuppgifter, måste följa. Förordningen existerar utanför de resterande aktörerna i nätverket och identifieras därav som en egen aktör.

personuppgiftsansvarig som ser till att lämpliga tekniska och organisatoriska skyddsåtgärder vidtas. Se citat ur GDPR artikel 34 3a:

“Den personuppgiftsansvarige har genomfört lämpliga tekniska och organisatoriska skyddsåtgärder och dessa åtgärder tillämpats på de personuppgifter som påverkades av personuppgiftsincidenten, i synnerhet sådana som ska göra uppgifterna oläsbara för alla personer som inte är behöriga att få tillgång till personuppgifterna, såsom kryptering. “

Metoder som aktör: GDPR ställer krav på hur data och information lagras och behandlas och förespråkar därmed olika metoder för det. Dessa metoder är pseudonymisering och anonymisering. Men anonymisering och pseudonymisering, i sig, är inte tekniker utan de realiseras genom tekniker som t.ex. kryptering. (se citat ovan).

Verksamhet 1 använder metoden anonymisering för all deras data för att försäkra sig om att de förhåller sig till GDPR, citat:

“Verksamhet 1 anonymiserar all testdata vilket vi inte gjorde innan GDPR.” Person 1 (personlig kommunikation, 5 december, 2018)

Verksamhet 2 förhåller sig i större utsträckning till pseudonymisering

“Vi ger ju vår data till andra ganska så ofta och då arbetar vi med pseudonymisering.” Person 2 (personlig kommunikation, 3 december, 2018)

Givet detta identifierar vi metoder som aktör.

Verksamhet som aktör: Verksamheters anställda som behandlar och lagrar personuppgifter är skyldiga att följa GDPR. Eftersom att vi har intervjuat anställda inom olika verksamheter identifierade vi verksamhet som aktör då de är skyldiga att förhålla sig till GDPR. Då det blir verksamheten som bär ansvaret så identifierade vi verksamheten som en aktör och inte den som är anställd.

Arbetssätt som aktör: Verksamheter måste praktisera ett fungerande arbetssätt för att deras arbete ska vara förenligt med GDPRs bestämmelser. Verksamhet 2 exemplifierar ett arbetssätt på följande sätt:

“Vår huvudtes är att minimera tillgången till persondata och det kan göras på flera olika sätt. Det är första är att begränsa åtkomsten genom behörighetshantering och det andra är att ha testdata som inte baseras på produktionsdata.” Person 2 (personlig kommunikation, 3 december, 2018)

Sammanfattningsvis; Givet ovan, blir GDPR en central aktör i nätverket då den står för ett maktförhållande i relation till de andra identifierade aktörerna. Alla andra aktörer är obligerade att följa bestämmelserna i GDPR.

Figur 4.1.1

4.2. Relationer i nätverket

GDPR, som aktör, talar om olika metoder som verksamheter kan utgå ifrån för att uppfylla lagen. Här identifierar vi metoder och verksamheter som fristående aktörer som existerar i relation till aktören GDPR. En av de metoderna som nämns i förordningen är anonymisering av data. Enligt GDPR är anonymiserad data ett sätt att anonymisera personuppgifter i den utsträckning att aktören inte längre kan identifieras. Kopplingen mellan personuppgifterna och aktören tas bort helt, dvs det går inte ens att återfå ursprunglig information om man har kompletterande uppgifter till den ursprungliga informationen. Denna typ av bearbetning av data är vanlig när man arbetar med data i testmiljö i forsknings- och statistiksammanhang. Anonymisering är även en metod som aktören Verksamhet 1 arbetar utifrån efter GDPRs införande.

“Vi anonymiserar all testdata innan vi lägger/använder informationen i våra testmiljöer” Person 1 (personlig kommunikation, 5 december, 2018)

Verksamheten anonymiserade (även kallat avidentifiera) redan delar av sin testdata innan GDPR infördes men inte förens efter det så anonymiserade de all testdata som användes inom verksamhetens testmiljö (personlig kommunikation, 3 december 2018). (Data Protection

Verksamhet 1 ser anonymisering som det tryggaste sättet att säkerställa att personlig data inte sprids vid test och att det inte hamnar i fel händer, detta inkluderar även deras egna anställda som arbetar i testmiljö. Detta innebär då att testpersonalen, dvs verksamhetens egna anställda, kan identifieras som aktörer då de existerar i relation till verksamheten som i sin tur skapar verksamhetens arbetssätt. Arbetssättet i sig kan identifieras som en aktör då den existerar i relation till verksamheten och GDPR, dvs verksamheten måste ha ett arbetssätt som är i linje med GDPRs bestämmelser. Verksamhet 1 menar vidare på att anonymisering även underlättar deras behörighetshantering då testpersonalen lättare kan tillgå testdata eftersom det inte kräver att dem har högsta säkerhetsklassnigarna. Vidare så krävs det inte att besluten som måste till för att köra testdata från produktionsmiljöer är fattade på någon högre nivå. De förklarar fördelarna med detta arbetssätt på följande sätt:

“Fördelen är givetvis säkerheten, d.v.s. vi kan med säkerhet veta att personuppgifter inte sprids vid test. Fördelen är också att det är enklare att få tillgång till testdata eftersom det inte krävs att dem som testar har högsta säkerhetsklassningarna vidare så krävs det inte att besluten som måste till för att köra testdata från produktionsmiljöer är fattade på hög nivå.” Person 1 (personlig kommunikation, 5 december, 2018)

Vidare menar Verksamhet 1 på att denna typ av hantering, dvs anonymisering, gör att

verksamheter faller lite under radarn för GDPR vilket kan underlätta för verksamheten i vissa aspekter. Dock identifierar de fortfarande själva svårigheter med att enbart använda

anonymisering. De beskriver problematiken på följande vis:

“Nackdelarna är givetvis svårigheten att testa hela kedjorna av inblandad information. Information som ligger i olika databaser kan vara en del i en helhet där personuppgiften är själva ID-begreppet.” Person 1 (personlig kommunikation, 5 december, 2018)

I vidare diskussioner med Verksamhet 1, kunde en åtgärd som tagits vid identifieras:

“Vi måste ”nyckla” testdata på likartat sätt oberoende av vilken databas informationen tillhör/ligger i för att kunna genomföra tester av hela kedjor. Detta är ett bekymmer för närvarande.” Person 1 (personlig kommunikation, 5 december, 2018)

Detta innebär då att åtgärden inneburit att Verksamhet 1 behövt hantera samma testdata, som finns i olika databaser, på ett likartat sätt oberoende av vilken databas informationen ligger i för att kunna genomföra tester av hela kedjor. Ett exempel på ett sådant test är

integrationstester. Ett integrationstest innebär att man vill testa interaktionen mellan det system som man utvecklar/uppdaterar med de system som finns hos tredje part. Detta kräver testdata av verksamheten som genomför testerna såväl som av den verksamhet som är tredjepart. Denna testdata bör finnas lagrad i en testdatabas som gemensamt tagits fram i överenskommelse mellan alla inblandade aktörer, t.ex. verksamheter, myndigheter och kreditkortsbolag. (Datainspektionen, 2014)

Att “nyckla” data för att kunna genomföra sådana typer av tester identifierar Verksamhet 1 som ett problem för närvarande. (Person 1, personlig kommunikation, 3 december, 2018)

4.2.2. Pseudonymisering som metod

En annan typ av anonymisering som ingår i aktören metod, är pseudonymisering.

Pseudonymisering, till skillnad från anonymisering, innebär att ursprunglig informationen kan kopplas tillbaka till en privatperson om man har kompletterande uppgifter. Den ursprungliga informationen ersätts med data som gör att privatpersonen blir oidentifierbar utan

kompletterande information, som då lagras separat från den andra informationen som inte anses vara kompletterande. Ett exempel på detta är personnummer, där flera personer kan vara födda samma år, månad och dag och där den kompletterande informationen som identifierar privatpersonen då är de 4 sista siffrorna i personnumret. Pseudonymisering rekommenderas av GDPR då information blir mindre tillgänglig för den som är obehörig att ta del utav den. Emellertid kan personuppgifter och annan känslig information fortfarande kopplas till en privatperson och därför kräver GDPR att metoder som pseudonymisering hanterar konsekvenser därefter. (Data Protection Commission, u.å) Verksamhet 2 menar även dem, i linje med GDPR, att hanteringen av testdata bör klassificeras utifrån hur känslig den är, dvs testdatahanteringen ska vara riskbaserad. (Personlig kommunikation, 3 december, 2018) Oavsett åtgärder för dataskydd, bör man beakta negativa konsekvenser som kan uppstå om någon obehörig skulle häva pseudonymiseringen. Konsekvenserna är många och de kan vara i form av att privatpersoners rättigheter eller frihet inskränks, att de tar fysisk, immateriell eller materiell skada i form av t.ex. diskriminering, identitetsstöld eller bedrägeri. (Art.75 EU 2016/679)

Verksamhet 1 behöver inte hantera sådan problematik då de anonymiserar sin testdata. ”Eftersom vi avidentifierar all testdata så behöver vi inte pseudonymisera.” Person 1 (personlig kommunikation, 5 december, 2018)

Trots att GDPR infördes 2018 och trycker på att pseudonymisering är att föredra så finns det länder som redan innan GDPRs införande började behandla sin anonymiserade data som pseudonymiserad data. England har exempelvis under en längre tid behandlat anonymiserad data som pseudonymiserad data när de delar med sig av den till en tredje part eller när de genomför integrationstester mot en tredje parts system. Detta innebär då att tredje parten inte besitter ursprunglig data eller t.ex. krypteringsnyckeln (se avsnitt för Tekniker för

pseudonymisering) så de kan omöjligen spåra data till en specifik privatperson. (Rumbold & Pierscionek, 2017)

4.3 Tekniker för pseudonymisering

För att en metod ska kunna vara applicerbar, utifrån GDPR, blir det nödvändigt att aktören teknik tillämpas. Detta blir nödvändigt då GDPR förespråkar tillämpningen av

pseudonymisering och anonymisering av personuppgifter då det kan minska riskerna för de registrerade privatpersonerna och underlätta för de ansvariga att fullgöra sina skyldigheter vad gäller dataskydd. För att uppnå det blir det nödvändigt att tillämpa en teknik som är specifik för valet av metod. Trots att GDPR förespråkar pseudonymisering så utesluter det inte att

andra åtgärder kan vidtas för att skydda data. (Art.28 EU 2016/679) En typ av

pseudonymiseringsteknik som nämns i lagen är t.ex. kryptering och denna teknik syftar till att höja säkerheten av dataskydd genom att redigera data och göra det ”oläsbart” för den som är obehörig till att ta del utav den.

4.3.1. Kryptering

Kryptering appliceras vanligtvis på kommunikationssystem men även på hanteringen av testdata. För att något som krypterats ska kunna avkrypteras och återgå till sin ursprungliga form, måste den som är behörig till att ta del av datan ha tillgång till krypteringsnyckeln som användes vid krypteringen samt ha kunskap om den algoritm som har använts för att kryptera den från början. (Johannesson, u.å) Denna nyckel bör kunna föras över från sändaren till mottagaren på ett säkert sätt som minimerar risken för att obehöriga kommer åt eller hackar den kanal som nyckeln förs över på. För att kryptering ska vara optimalt behöver man även uppdatera krypteringsnycklarna och byta ut de gamla för att minimera risken att nyckeln sprids till obehöriga. Vidare bör man även undvika att använda samma nycklar på flera olika ställen utifall en obehörig skulle komma åt dem. Det hade gett den obehörige större tillgång till originaldata än om det var olika nycklar på olika krypterade delar information. (Singh, 2000)

4.3.2. Maskering

En annan typ av pseudonymiseringsteknik är maskering, vilket innebär att man maskerar vissa ordinarie parametrar i en specifik del av information som eventuellt kan identifiera någon. Processen för maskeringen innebär i sin tur processen av att skapa realistisk data baserad på verklig data, detta kan t.ex. vara data som kunder uppger i produktionsmiljö, utan att avslöja den verkliga datan. Syftet med detta är att skydda känslig information från att avslöjas. Genom att ersätta den verkliga datan med slumpmässiga karaktärer eller annan del information, skyddas den känsliga informationen till viss del och den maskerade datan bör inte längre kunna identifiera en privatperson. Denna teknik används vanligtvis på hemsidor som innehåller personnummer eller kortnummer där man t.ex. ersätter de 4 sista siffrorna i ett personnummer med bokstäver. Således är det då den maskerade datan som lagras i databasen och inte den verkliga datan men de har samma format men olika värden. Det är på så sätt möjligt att använda databasen i testmiljö. Den verkliga datan lagras i en separat databas som kräver behörighet av specifika personer som t.ex. utvecklarna och inte testarna. (Kuacharoen, 2014).

Verksamhet 2 menar även dem på samma sak som Kuacharoen (2014) och trycker på att det måste finnas en medvetenhet hos ansvariga inom verksamheten vad gäller att se sambandet mellan behörighet och teknik. Det gäller då inte enbart maskering utan det gäller i allmänhet att ansvariga inom en verksamhet bör vara medvetna om att personer med högre behörighet även har behörighet att ändra tillbaka data till sitt ursprungsformat. Verksamhet 2

exemplifierar detta genom att förklara det som följande:

“Det finns olika tekniker på olika nivåer och man ska vara medveten om att om man har en högre behörighet så har man möjlighet att ändra tillbaka datan. Om vi t.ex. använder maskning då är det bra att dem som sitter i databaserna inte har så höga behörigheter som dem som sitter och utvecklar. Det är en typ av åtgärd men vi ser risker med

behörigheterna.” Person 2 (personlig kommunikation, 3 december, 2018)

Om maskering används är det alltså att föredra att de som sitter och genomför tester i

databaserna inte har lika höga behörigheter som de som sitter och utvecklar. Det är en typ av åtgärd men riskerna kvarstår om behörighetshanteringen inte sköts på ett korrekt sätt.

För att återkoppla till tekniken maskering bör en annan aspekt tas i beaktande vad det gäller optimering av maskering, vilket är att datastrukturer bör bibehållas under samtliga

maskerings-operationer mellan databasens olika kolumner, rader och tabeller. Om nyckeln i en tabell t.ex. ändras så måste det i sin tur ske en identisk ändring i alla relaterade tabeller. En utmaning med detta är att känslig information måste tas bort helt i testmiljön men samtidigt måste den interna relationsdatabasen vara intakt, dvs ändringar som görs på en nyckel i en tabell måste även göras på associerade nycklar till den tabellen. (Padron-Mccarthy & Risch, 2018) Trots att maskering inom testmiljö syftar till att b.la. maskera känsliga personuppgifter så föreligger ändå risken för att känsliga personuppgifter avslöjas med hjälp av vanliga personuppgifter. Ett exempel på hur enbart maskeringen av namn och adress inte är hållbart för att anonymisera eller pseudonymisera data är en tidigare studie utförd av Sweeney (2000) där man upptäckte att 87% av befolkningen i USA kunde identifieras utifrån en kombination av 3 delar information om varje person (postkod, födelsedatum och kön).

4.3.3. Hashkodning

Hashkodning är en typ av kryptografisk metod som syftar till att ge en snabb åtkomst till data. En hashtabell är i sin tur en typ av datastruktur där lagring av data sker på numrerade platser i en tabell, dvs index. Tabellens olika rader består av olika element (t.ex. namn, adress,

telefonnummer) och för varje element beräknas en hashkod, med hjälp av en hashfunktion, som resulterar i ett heltal och som i sin tur avgör elementets index i tabellen. Genom att söka efter element utifrån deras index, kan snabbheten på sökningar i en hashtabell öka.

Elementens index, som beräknas utifrån en hashfunktion, kan innebära kollisioner mellan olika elements index. När detta sker brukar olika hashfunktioner kunna leta upp en ny placering åt elementen eller så lagras elementen i ett separat

lagringsutrymme. (”Hashkodning”, u.å) I grund och botten så är kollisioner oundvikliga men med väldefinierade hashfunktioner som löser kollisionen bör de flesta elementen få unika hashkoder. (Joyce & Dale, 2016) Som en parantes till det ovannämnda kan en förenklad variant av en sorts hashfunktions roll i lagrandet av data kunna förklaras på följande sätt: Du väljer ett lösenord till din användare på en hemsida och lösenordet får endast bestå utav en siffra. Du väljer siffran 5 men hemsidans databas kommer inte ihåg siffran 5 som ditt lösenord utan den har en algoritm i hashfunktionen som multiplicerar ditt lösenord med 7 och lagrar därför bara siffran 35. Ditt riktiga lösenord, 5, lagras alltså inte någonstans i databasen utan

loggas du in då inputen som du angivit beräknats i hashfunktionen och resulterat i 35. Om du istället hade matat in 4 så hade hashfunktionen inte låtit dig gå vidare med inloggningen då det hade resulterat i 28. Lösenordet lagras alltså inte i klartext, vilket kan vara betryggande utifall någon obehörig hade fått tillgång till databasen.

En hashfunktion kan alltså även fungera som en platsfördelare likaså som en algoritm för att matcha inmatat lösenord gentemot det som lagrats i databasen.

4.3.4. Kryptografisk hashning

Det finns även en teknik som kombinerar kryptering och hashning vilket innebär att den data som krypteras går igenom en hashfunktion som hashar koden på en avsevärd högre

säkerhetsnivå än vanlig hashning och kryptering. Egenskaperna som en hashfunktion bör ha för att kvalificera som en krypterad sådan är bl.a. att den ska vara effektiv, med detta menas då att den inte ska ta lång tid att genomföras i relation till sitt ändamål. Den ska även vara kollisionsresistent, dvs undvika kollisioner så gott det går och den ska även kunna dölja/hasha information på en så hög nivå att det inte ska gå att spåra tillbaka någonting till den

ursprungliga informationen. Målet i slutändan är, såsom med många tekniker, att den lagrade informationen ska se slumpmässig ut. (Alkandari, Al-Shaikhli & Alahmad, 2013)

Sammanfattningsvis vad det gäller tekniker så kan de tillsammans i detta sammanhang

identifieras som en aktör då de baseras på metoder, dvs de existerar som en effekt av metoder.

4.4. Tekniker för anonymisering

Verksamhet 2 har tidigare inte använt anonymisering i samma utsträckning som Verksamhet 1, dock så har Verksamhet 2 visat ett intresse för metoden. De har börjat titta närmare på tekniker som involverar syntetisk data. Syntetisk data är då en typ av data som kan genereras i processen av anonymisering av data och som baseras på ett riktigt dataset, dvs verklig data. Syntetisk data anses vara en möjlig lösning på konfidentiella problem då den syntetiska datan som genererats utifrån verklig data även har samma attribut/egenskaper som verklig data. (Elliot, Fairweather, Olsen & Pampaka, 2016) Verksamhet 2 uttrycker sitt intresse för tekniken på följande vis:

“Det som vi ser utifrån omvärlden är att syntetisk data är spännande då det är exakt samma data men som man kan vrida och vända på men är ej kopplad till en riktig individ. T.ex. Kurt Nilssons personnummer har bytts ut mot ett fejkat och hans namn har bytts ut och det finns ett intresse i vår omvärld om att man ska kunna publicera ut sånt mer då det är mer intresserade informationen. Då skulle det kunna göra mycket mer med datan beroende på verksamhet.” Person 2 (personlig kommunikation, 3 december, 2018)

De beskriver även ytterligare hur de vill gå vidare med syntetisk data och utmaningen som de ser med det.

“Syntetisk testdata i större omfattning är ju egentligen hur vi vill gå vidare i nästa steg och det kan ju vara värt att nämna lite. Det är sådant vi börjar titta på ännu mer, dock vet vi om dess komplexitet.” Person 2 (personlig kommunikation, 3 december, 2018)

Verksamhet 2 arbetar i dagsläget redan med syntetisk data, det är dock inget standardiserat inom verksamheten. Det är, som konstaterat ovan, något som de önskar arbeta mer med i framtiden.

“Vi arbetar också med syntetisk data i vissa system idag i mindre omfattning som inte har några kopplingar till riktiga individer då nya identiteter upprättas. Vår verksamhet har ett egenutvecklat system som genererar syntetiskt testdata, det arbetar bl.a. med verktyget X och kör tester på samtliga system och inte enskilda, dvs integrationstester. Systemen byggs inkrementellt för att undvika att något faller mellan stolarna. Genom att ha egenutvecklade verktyg och generering av testdata så får vi en ökad komplexitet.” Person 2 (personlig kommunikation, 3 december, 2018)

Hittills menar alltså Verksamhet 2 att syntetisk data har varit en framgångsrik teknik, trots att den inte används/använts i så stor utsträckning, men att de även därför strävar efter att

eventuellt kunna arbeta med det i större utsträckning i framtiden. Det ska dock kunna motiveras och följas upp. Se citat nedan.

“Om det är möjligt använd program för att generera syntetisk testdata automatiskt, det har varit framgångsrikt hos oss. Var noggranna att dokumentera skäl och vägval.” Person 2 (personlig kommunikation, 3 december, 2018)

4.5. Teknikneutralitet enligt GDPR

För att förebygga att allvarliga risker uppstår i form av att reglerna för GDPR kringgås, ska skyddet av fysiska personer vara teknikneutralt, dvs oberoende av teknik som används i samband med lagrandet av personuppgifter, ska lagen följas. Skyddet som GDPR innebär ska vara applicerbart på både manuell och automatiserad behandling av personuppgifter där personuppgifterna är avsedda att ingå i något slags register, om de inte redan ingår i ett

dvs. (Art.15 EU 2016/679). Teknikneutralitet innebär även att hänsyn ska tas när det kommer till nätidentifierare, som t.ex. utrustning, kakor, IP-adresser och andra identifierare som kan spåras tillbaka till en fysisk person. Spåren kan i sin tur kombineras med unika identifierare som därefter skapar profiler för fysiska personer och identifierar dem. (Art.30 EU 2016/679)

4.6. Arbetssätt

4.6.1. Behörighetshantering & tillgång

Verksamhet 2, till skillnad från Verksamhet 1, arbetar i större utsträckning med pseudonymisering och lägger i nuläget stor tyngd på behörighetshantering inom sin verksamhet. Dvs de lägger tyngd på aktören arbetssätt. Med Verksamhet 2s egna ord:

“Vår huvudtes är att minimera tillgången till persondata och det kan göras på flera olika sätt. Det är första är att begränsa åtkomsten genom behörighetshantering och det andra är att ha testdata som inte baseras på produktionsdata.” Person 2 (personlig kommunikation, 3 december, 2018)

Vidare utvecklar de vad som menas med de två olika sätten och med testdata som baseras på produktion innebär det då att produktionen av testdata sker inom verksamheten och IT-teamet. Ibland anser dem dock att det kan bli problematiskt om man ska göra stora lasttester och då är det viktigt att först medvetet veta att man använder riktig data som test och i vilka miljöer det används i och begränsa behörigheten genom behörighetsstyrning. Verksamhet 2 beskriver problematiken mer utvecklat nedan:

“Utmaningen vi ser med testdata är inte främst inom systemtester utan det är när man ska göra större lasttester och man verkligen vill att det ska vara riktig data för att se att allting verkligen fungerar (Acceptans test).” Vi har tydliga riktlinjer gällande miljöer när vi jobbar t.ex. testmiljö och i utvecklingsmiljö då försöker vi jobba med testdata (ej produktionsdata) men sen när man ska gå till acceptanstest och produktionstest på en större skala då har man färre som har behörigheter och riktig data, dvs en annan användargrupp. Användarna får testa olika scenarier för att se att allting funkar. Det är en ibland en framkomlig väg.” Person 2 (personlig kommunikation, 3 december, 2018)

Person 2 går vidare med att förklara väsentligheten av behörighetskontroller i samband med de olika testerna som genomförs.

“Vi tittar på att skilja på acceptans och last ännu mer. Det tar tid att hela tiden ta fram ny testdata och vill man vara riktigt säker på att det verkligen funkar så gäller det att ha rutiner för det och då är det återigen viktigt med behörigheter så att de som sitter och utvecklar och de på test inte har samma behörigheter.“ Person 2 (personlig kommunikation, 3 december, 2018)

Ett exempel på vad ett lasttest innebär kan t.ex. vara att en grupp användare ska genomföra en specifik uppgift och samtidigt vill man mäta laddtiden i samband med att uppgiften

genomförs. (Jiang, Hassan, 2015). Det ska då även finnas ett start-och slutdatum, dvs när testerna är klara så ska testdata tas bort (raderas). Det föreligger risker om detta inte görs då det kan ligga kvar i projektet och när man skapar ett nytt projekt så ligger det kvar i

databasen. Vidare föreligger då en risk att fel personer kan få tillgång till tidigare data. Verksamhet 2 identifierar det som sitt ansvar att ta bort och gallra testdata som baserats på produktionsdata då de till stor del bara lånar data. (Personlig kommentar, 3 december, 2018)

“Det föreligger risker om detta inte görs då det kan ligga kvar i projektet och när man skapar ett nytt projekt så ligger det kvar i databasen. Fel personer kan få tillgång till tidigare data. Vi har ju ett ansvar att ta bort och gallra då vi bara lånar data.” Person 2 (personlig kommunikation, 3 december, 2018)

Allt detta leder tillbaka till det faktum att rätt person ska ha rätt tillgång till rätt data. Man ska alltså inte i onödan, som obehörig, komma åt data som man verkligen inte måste ha åtkomst till för att kunna genomföra sina arbetsuppgifter. Som tidigare beskrivet vill Verksamhet 2 minimera åtkomsten till persondata och det är även det som är grunden i GDPR och i den tidigare lagen PUL. Då Verksamhet 2, innan GDPR, arbetat utifrån PUL så det är inget nytt dock så har fokuset på GDPR ökat då verksamheter i allmänhet bl.a. riskerar höga

bötesbelopp om lagen överträds eller om de saknar en PBD (se avsnitt om Privacy by Design) (Personlig kommentar, 3 december, 2018)

Ett ökat fokus har vidare inneburit att Verksamhet 2:s dataskyddsombud betonat vikten av att ha ordning på testdata och att alltid använda testdata som ej är produktionsdata t.ex.

personuppgifter, i så stor utsträckning som möjligt. Om det dock skulle finnas starka skäl till att ej kunna tillverka testdata utan att använda produktionsbaserat testdata så är det viktigt att verksamheten har koll på informationen och inför säkerhetsmekanismer. Verksamhet 2 utvecklar ytterligare vad innebörden av ett sådant undantag hade inneburit:

“Kopior av produktionsdata och skarp data ska endast i undantagsfall användas i test och utvecklingssyfte och endast under förutsättning att det inte går att säkerställa funktionaliteten. Undantaget ska beslutas av den som äger informationen, vilket är någon inom verksamheten, efter det tar vi ställning om skälet är tillräckligt. Detta ska även dokumenteras och vara ett aktivt val, dvs inget slumpmässigt och omotiverat.” Person 2 (personlig kommunikation, 3 december, 2018)

Tillgången till produktionsdata ska alltså endast finnas i undantagsfall där det måste användas i test- och utvecklingssyfte för att säkerställa funktionaliteten av ett system. Undantaget ska beslutas av den som äger informationen, vilket är någon inom verksamheten och detta ska även dokumenteras och vara ett aktivt val som kan motiveras.

Metodiken som Verksamhet 2 utgår ifrån varierar men ett vanligt fall är att ta befintlig data och sedan anonymisera den genom att t.ex. ta bort personnummer och efternamn. I nuläget undersöker de närmare hur detta kan bli en större del i deras arbete genom att titta närmare på maskering. Vidare så betonar de att det finns olika tekniker på olika nivåer och att man bör vara medveten om att om man har en högre behörighet så har man möjlighet att ändra tillbaka data, därför är det säkraste att nyttja syntetisk testdata. Om de t.ex. använder maskering då är det viktigt att de som sitter och hanterar databaserna inte har samma behörigheter som utvecklarna. Det är en typ av åtgärd för att minimera risk. Dock är det ibland svårt att arbeta med syntetisk data då det tar lång tid och kostar pengar.

Verksamhet 2 strävar även efter att skilja på acceptans- och lasttester ännu mer. Med acceptanstest menas att man testar för att se om kraven på ett system uppfylls (se avsnitt Behörighetskontroll för exemplifiering av lasttest). Att ta fram testdata är tidskrävande för verksamheten och utan fungerande rutiner blir det problematiskt. De anser att en

Ännu en viktig säkerhetsaspekt som Verksamhet 2 anser bör beaktas är att det inte enbart kan föreligga risker i samband med behörighetshantering utan även på vart testdata lagras i form av t.ex. lokala hårddiskar och USB-stickor. (Personlig kommunikation, 3 december, 2018) 4.6.2. Riskbedömning som arbetssätt

Innan behandling av personuppgifter påbörjas, bör verksamheten ifråga göra en

riskbedömning och se över databehandlingsform, sammanhang, ändamål och omfattning. (Art.76 EU 2016/679) Riskbedömningen bör därefter grundas på om behandlingen av den aktuella data innefattar stora eller små risker. Det föreligger exempelvis en större risk att en fysisk person kommer till skada om känslig data avslöjas än om vanliga personuppgifter avslöjas. (Art.51 EU 2016/679) Om man vidare skulle finna risker som inte kan åtgärdas med de medel som verksamheten har tillhanda, ska verksamheten vända sig till en

tillsynsmyndighet, (Art.94 EU 2016/679) vilket i Sverige då är Datainspektionen. (Datainspektionen, 2018)

För att upprätthålla ett dataskydd och säkerställa att GDPR följs rekommenderar GDPR att verksamheter använder sig utav tekniker såsom kryptering eller liknande tekniker för att pseudonymisera data. Oavsett vilken åtgärd eller teknik som används bör det säkerställa lämplig säkerhetsnivå i förhållande till de risker som identifierats, typen av personuppgifter som behandlas (t.ex. känslig personuppgifter) och andra aspekter som kan spela roll inom en viss verksamhet. (Art.83 EU 2016/679)

4.6.3. Privacy by design som arbetssätt (en del av GDPR)

En annan aspekt som GDPR täcker upp är inbyggt dataskydd som standard för IT-system, sk. Privacy by design (i fortsättningen förkortat PBD). PBD innefattar även att det inom varje organisation ska finnas en personuppgiftsansvarig som genomför tekniska åtgärder och ser till att kraven i GDPR uppfylls och efterlevs för att de registrerades rättigheter ska skyddas. Detta ansvar innefattar både valet av åtgärd och därefter självaste behandlingen av

personuppgifterna. Pseudonymisering är en typ av sådan åtgärd och den ska vara utformad enligt principerna för att dataskydd ska kunna genomföras effektivt, t.ex. genom

uppgiftsminimering. De nödvändiga skyddsåtgärderna ska alltså integreras i behandlingen. Dessa åtgärder ska grundas på den senaste utvecklingen, genomförandekostnader,

behandlingens art, omfattning, sammanhang och ändamål samt riskerna av varierande sannolikhetsgrad och allvar för individens rättigheter och friheter. (Se avsnitt om

Riskbedömning) Den personuppgiftsansvarige ska även, enligt PDB, beakta om hur mängden insamlade personuppgifter lagras, behandlas och tiden för deras lagring och tillgänglighet. Framför allt ska dessa åtgärder säkerställa att personuppgifter i standardfallet inte utan den enskildes medverkan görs tillgängliga för ett obegränsat antal fysiska personer. (Art.25 EU 2016/679)

I grund och botten innebär denna standardisering att hänsyn ska tas redan i startskedet av systemutvecklingen för att säkerställa att kraven i GDPR efterlevs och att den registrerades

rättigheter skyddas. Detta innefattar även att personuppgifter inte ska behandlas i onödan, det kan exempelvis handla om information som inte ska samlas, delas ut eller visas i onödan. Verksamhet 2 exemplifierar detta i sin PDB-policy på följande sätt:

“Om till exempel ett ärendehanteringssystem kan göra mer med personuppgifter än vad som är tillåtet enligt ändamålet så är det viktigt att det är möjligt att begränsa och spärra de funktionerna för handläggare innan systemet tas i drift.” Person 2 (personlig kommunikation, 3 december, 2018)

Detta innebär då, som tidigare beskrivet, att verksamheten ska eftersträva att utforma IT-system där så få personuppgifter som möjligt ska samlas in och hanteras. Man bör därför alltid ha ändamålet i åtanke och utforma personuppgiftshanteringen utifrån det. Verksamhet 2 ger olika exempel på några strategier för hur detta kan uppnås. citerat från Verksamhet 2s dataskyddspolicy:

“Olika sätt att minska integritetsriskerna kan vara att:

• Begränsa sig till uppgifter som endast indirekt pekar ut en individ,

• begränsa sig till uppgifter som är mindre känsliga,

• ersätta namn, till exempel med pseudonymer,

• inte rutinmässigt ha med personnummer som fält i databaser.”

Tidigare i avsnitt om Behörighetsstyrning diskuteras Verksamhet 2 behörighetsstyrning men det är även viktigt att lyfta fram att verksamheten, enligt sin PBD policy, även arbetar med kryptering av lagrad information. Enligt policyn bör det finnas möjlighet till kryptering vid kommunikation över internet, i databaser och på mobila enheter. För att säkerheten ska upprätthållas ytterligare bör man även genomföra “säker utplåning” (PBD-policyn) dvs förstöring och borttagning av data efter att hela eller delar av ett system tagits ur drift och skrotats för att undvika risken av att data läcker ut i efterhand.

Viktigt att poängtera är att trots att denna uppsats mestadels trycker på att Verksamhet 2 arbetar med pseudonymisering så innebär det inte att anonymisering är en utesluten åtgärd då det faktiskt rekommenderas i deras PDB-policy. Detta gäller exempelvis i fall där man gör utdrag för rapporter och statistik och ska kunna välja bort den information som inte är relevant.

4.7. Sammanfattning av relationer

För att sammanfatta ovanstående relationer mellan aktörerna; GDPR, som även inkluderar PBD, finns till för att skydda privatpersoner vars personuppgifter finns lagrade hos olika verksamheter. Verksamheterna använder i sin tur olika metoder, som tillämpas genom olika tekniker, för att leva upp till GDPR. Mycket av verksamheternas arbete för att uppfylla GDPR hänger på hur personalen hanterar personuppgifterna genom hela utveckling- och