GDPR i praktiken

Det här är tre bloggposter som först publicerades på min dåvarande arbetsgivare Claremonts (numera Vass) blogg.

Del 1 https://www.vasscompany.se/insikter/artiklar/gdpr-i-praktiken-del-1/

Del 2 https://www.vasscompany.se/insikter/artiklar/gdpr-i-praktiken-del-2

Del 3 https://www.vasscompany.se/insikter/artiklar/gdpr-i-praktiken-del-3

GDPR i praktiken – del 1

Det görs ofta feltolkningar, främst på grund av dålig kommunikation mellan jurister och de som hanterar tekniken, vilket kan leda till att man inte sällan bryter mot lagen utan att vara medveten om det. I värsta fall bryter man medvetet mot lagen för man vet inte hur man skall hantera utmaningarna med GDPR. Jag har i flera år jobbat tätt ihop med systemutvecklare, databasexperter, jurister mm och presenterar i denna artikelserie min syn på vad som är viktigt för att skapa GDPR kompatibla system.

Jag hävdar att om man hanterar GDPR-problematiken kommer det oftast att löna sig eftersom vi samtidigt kan rätta till de brister i systemen GDPR problematiken synliggör, varför vi bör se de utgifter som det medför som en investering och inte en kostnad.

De krav som GDPR ställer på våra system kan i många fall ses som ett lackmuspapper som påvisar om systemen är byggda på ”rätt” sätt. GDPR bygger i stora delar på PUL, som röstades igenom 1995. Det är med andra ord svårt att hävda att det inte funnits tillräckligt med tid att rätta till brister. Många företag hanterar GDPR-frågan genom att vänta och se för ”det kommer inte att drabba oss först i alla fall”, men lagen är tämligen klar och är man inte ett jättelitet företag så är det dags att ta tag i frågan och börja agera nu. Jakob Söderbaum, skrev i sin artikel bland annat om hur ett antal stora företag fått mycket höga böter och det är bara en tidsfråga innan det kommer att drabba även mindre företag.

Men det är inte enbart negativt att tvingas ta tag i denna fråga, för det kan samtidigt ses som en chans att betala tillbaka på den tekniska skuld vi har och få mer välbyggda och bättre fungerande system genom att dra nytta av de verktyg och processer som sätts upp för att kunna hantera GDPR.

Hantera data/arkitektur

Enkelt uttryckt är en personuppgift allt som kan identifiera en person, enskilt eller genom att pussla ihop information från flera källor. Skatteverket har en bra artikel om vad en personuppgift är på sin webbplats.

GDPR ställer krav på oss.

Vi behöver veta:  

    • Varför vi samlar in data 

    • Vad vi sparat om enskilda personer 

    • Var uppgifterna är lagrade  

    • Hur vi använder dem 

Vi behöver kunna ge de som personuppgifterna rör möjlighet att:  

    • Läsa vad som finns om dem 

    • Rätta felaktigheter 

    • Dra tillbaka samtycke och därmed bli borttagen ur systemet. 

    • I vissa fall kan kunden även kräva att uppgifter skall kunna överlämnas till en annan organisation, sk portabilitet. 

När vi inte längre har skäl att behålla personuppgifterna så måste de tas bort 

    • Vill vi ha kvar personuppgifter så behöver de anonymiseras så man inte kan spåra dess ursprung till en specifik person.

När en person begär att få ut uppgifter från alla dessa system och eventuellt begär att data skall rättas eller ta tillbaka medgivande så måste vi ha en process för att se till att det utförs. Det kan vara tekniskt komplicerat då det på grund av andra lagar, såsom bokföringslagen, måste finnas kvar vissa uppgifter. Data som en kund vill ta bort kan även vara mycket värdefull för företaget och kan kanske sparas i en annan form, tex som anonymiserad. För att det i så fall skall vara möjligt är det viktigt att skapa en lösning för det i tid, inte när kunden vill bli borttagen.  

Dessa krav påverkar hur ett system byggs/byggs om. Det är därför viktigt att ha en helhetssyn på systemen och dess data. Det är inte ovanligt att personuppgifter är spridda i många system. Dessa kan ligga i såväl den egna serverhallen som i molnlösningar. Data kan även ligga hos leverantörer av en tjänst och i allra värsta fall, ostrukturerat på fildelningsytor, personalens laptops och/eller USB-minnen. Inget av detta behöver vara olagligt i sig, men gör det svårt att uppfylla tidigare nämnda krav. För att göra det extra komplicerat så finns det personuppgifter i utvecklingsmiljöer där det ställs ännu hårdare krav, vilket vi återkommer till i den sista artikeln i denna serie. 

Arkitektur 

I en artikel är det svårt att skriva vad man ska och inte ska göra då det är många faktorer som skiljer mellan företag och system. Det kommer därför att bli fråga om saker som bör tas hänsyn till vid skapande, ombyggnad och inte minst vid inköp av system. För att kunna hantera GDPR är det viktigt att ha en väl genomtänkt systemarkitektur som gör det enkelt att uppfylla dessa krav. I många fall kan det även automatiseras vilket bland andra Facebook gjort. Att automatisera flödet kan vara en stor fördel för att underlätta portabilitet, vilket är ett krav för vissa branscher.

Konsolidera personuppgifter 

Uppgiftsminimering samt lagringsminimering är två av de sju grundläggande principerna för att en organisation skall ha rätt (enligt artikel 5 och 6) att behandla personuppgifter. Därför bör dessa lagras på så få platser som möjligt i företagets systempark. Övriga system bör kunna läsa in dessa uppgifter när de behövs, men helst inte lagra dem. Det förenklar skyddet av personuppgifter, och gör det avsevärt enklare att hantera dem när det krävs. Det gör det även enklare att hantera produktionsdata i testmiljöer.  

Tänk på att inte använda uppgifter som räknas som personuppgifter som primärnycklar. Detta på grund av att personuppgifter i princip inte får/kan användas i testsyfte och därför måste kunna bytas ut. Personnummer (inklusive, de fyra sista siffrorna) bör heller inte användas för att läsa ut ålder, kön osv. Mer om detta i tredje artikeln.  

Kommunikation

Det finns många saker som gör e-post till ett olämpligt verktyg att skicka personuppgifter med. Det är mycket svårt att kontrollera spårbarheten och det är i de flesta fall inte möjligt att garantera att överföringen sker på ett säkert sätt.  Man kan inte hävda att e-post är tekniskt olagligt för hantering av personuppgifter men det kan komplicera vårt arbete med att följa lagen. Om man behöver ta emot tex ansökningshandlingar denna väg skall processen vara beskriven och följas. Undvik därför i mesta möjliga mån att skicka uppgifterna i klartext utan dela dem via filer på gemensamma lagringsytor eller system som är avsedda för ändamålet. Detta kan medföra andra utmaningar som man måste vara medveten om, som exempelvis hur säkert personuppgifterna sparas, eller i vilket land data lagras. Om man tagit emot eller skickat personuppgifter via epost bör dessa tas bort och sparas på annan plats, tex i därför avsett system.

Användarupplevelsen

Användarupplevelsen gäller för alla kategorier av användare av systemet och det är lönsamt att tidigt hantera denna fråga. Det är enklare att göra lättanvända system som sparar tid och blir säkrare att använda om man tar in denna kompetens på ett tidigt stadium. Som användare räknas samtliga som hanterar hela eller delar av systemen och deras behov måste alla beaktas. Dvs inte bara de sk slutanvändarna utan även administratörer, systemoperatörer, produktägare osv.    

    • Det kan krävas utbildning, manualer och hjälptexter för att det skall vara lätt att använda systemet men man bör sträva efter att systemet skall vara självförklarande och feltolerant.  

Då uppgifterna kan vara av mycket känslig art så är det viktigt att se till att systemet är så tydligt att det är lätt att göra rätt och svårt att göra fel, bl.a. för att dessa inte skall hamna i händerna på fel personer.

GDPR ställer även hårda krav på skyddet av data vilket jag tar upp i nästa artikel. Personuppgifter är värdefulla data och det kan i vissa fall få ödesdigra konsekvenser om de hamnar i fel händer. Säkerhet är svårt att få till men inte jättesvårt att förstå på ett övergripande plan. 

 

GDPR i praktiken – del 2

Detta är den andra delen i artikelserien som handlar om vilka utmaningar vi ställs inför när vi ska hantera personuppgifter. I denna del kommer säkerhet och skyddande av personuppgifter att behandlas. Den första delen handlade om vad som är viktigt att tänka på vid skapande av system som är compliant med GDPR.

Skydd av personuppgifter enligt GDPR

Det talas ofta om vilken data som får sparas enligt GDPR, men lagen ställer även stränga krav på hur personuppgifter skyddas, så att de inte förstörs eller stjäls. Det är därför svårt för ett företag av storlek att hävda att de inte haft möjlighet att genomföra de åtgärder som nämns i denna artikel. Man kan inte heller hävda okunskap om man råkar ut för en incident. Det är även viktigt att förstå att om vi outsourcar personuppgifterna till tredje part så avsäger vi oss inte ansvaret, vilket gör att man måste kontrollera att de uppfyller sitt uppdrag. Att låta en tredje part hantera data kan i sig vara en säkerhetsrisk.

Denna artikel är inte en lista på åtgärder som måste hanteras för att följa GDPR. Den innehåller övergripande information och exempel på tekniska och organisatoriska säkerhetsåtgärder som tillsammans behövs för att skydda personuppgifter. Skyddsåtgärder skall inte ses som något som görs i efterhand och som bockas av på en lista, utan måste vara integrerat i utvecklingsprocessen och integration av system. De måste ses som en helhet då de tillsammans med säkerhetstänk utgör ett skyddsnät. GDPR ställer inga orimliga krav på säkerhet och hur konfidentiella uppgifter bör skyddas då dessa ändå bör hanteras av organisationen för att se till att den dagliga verksamheten ej riskeras.

När en person begär att få ett registerutdrag är det viktigt att det hanteras på ett säkert sätt. Det har visat sig allt för enkelt att ringa eller maila utan att behöva styrka sin identitet på ett säkert sätt. Även denna process måste det finnas en processbeskrivning för, så att uppgifterna inte skall hamna i fel händer. Denna artikel belyser på ett bra sätt hur enkelt det kan vara att få ut uppgifter utan att styrka sin identitet. Man kan därför dra nytta av de kartläggningar och åtgärder GDPR tvingar oss att utföra då vi bör hantera säkerheten oavsett lagar och förordningar. Skillnaden jämfört med tidigare är att numera är okunskap och slarv även straffbart.

GDPR som drivkraft för förbättrad cybersäkerhet

I artikeln GDPR i praktiken – del 1 skrev jag att man kan se GDPR som ett lackmuspapper som ger svar på om vi gjort ”rätt”. Se därför arbetet med att skapa en säker IT-miljö som en investering och inte en kostnad som tvingats fram. Enligt en färsk undersökning gjord av IBM Security and Ponemon Institute så tar det i Skandinavien i snitt 299 dagar från incident inträffar tills den upptäcks och löses. Undersökningen ser ett klart samband mellan hur lång tid det tar att upptäcka intrånget och kostnaden för den. Den genomsnittliga kostnaden för företag per intrång är 22 miljoner kronor vilket främst baseras på att kunderna förlorar förtroendet. Det är tydligt att det kan bli väldigt dyrt om säkerheten i företaget är bristfällig. Många företag är dessutom dåliga på att upptäcka incidenter, vilket i sig kan ses som både olagligt och förenat med betydande affärsrisker. Enligt samma undersökning kommer en fjärdedel av alla företag drabbas av intrång inom de närmaste 2 åren vilket manar till eftertanke.

Enlighet en undersökning som konsultfirman RSM lät utföra så börjar GDPR att få en positiv inverkan på cybersäkerheten inom EU. Nästan tre fjärdedelar (73%) av företagen hävdar att GDPR har uppmuntrat dem att förbättra hanteringen av kunddata och 62% säger att det har fått dem att öka sina investeringar i cybersäkerhet. Det återstår dock mycket att göra, men 21 % av företagen erkänner att de fortfarande inte har någon strategi för cybersäkerhet på plats.

Säkerhetstänk

Säkerhet måste baseras på såväl tekniska- som processutvecklings och utbildningsåtgärder då inget system per automatik kan identifiera och förhindra alla sätt att ta sig in i system utan behörighet. Att bli avlurad uppgifter genom så kallad ”social engineering” är numera ett av de vanligaste sätten att ta sig in i system och för denna typ av intrång kan tekniska lösningar inte skydda till 100%. Teknik kan däremot försvåra intrång och minimera skadeverkningar. Personal bör därför utbildas i grundläggande säkerhetstänk och man behöver förankra varför man eventuellt begränsar deras rättigheter. Exempel: Det finns ofta goda skäl till att organisationen blockerar fildelningstjänster som Dropbox och Google drive. Men risken är då stor att användarna istället skickar filer i e-post eller bär omkring på okrypterade USB-stickor, vilket oftast är en allvarligare risk. En IT-avdelning måste prioritera användarnas behov, vilket ofta innebär att erbjuda alternativa lösningar till de man anser osäkra. Annars är risken stor att personal medvetet går runt blockeringar för att de inte förstår varför de finns, vilket kan skapa större säkerhetsrisker än de som blockerats.

Många företag verkar tro att en brandvägg för att stänga ute obehöriga och att ge personer olika rättigheter till filareor och system räcker, vilket det sällan gör. Den första regeln inom säkerhet är att hantera sin nätverksmiljö som om man alltid hade obehöriga i nätverket. Klientdatorer och servrar bör hanteras som om de befann sig på ett publikt nätverk. Många företag planerar just nu för att konsulter och anställda skall kunna ta med sig sin egen utrustning, vanligtvis benämnt ”Bring Your Own Device” (BYOD) vilket i förhållande till GDPR och annat integritetsansvar blir oerhört komplext om man bara förlitar sig på en brandvägg. De flesta arbetar förebyggande mot intrång, men man bör även bevaka om det trots allt sker. En väldigt grov jämförelse skulle kunna vara att lås och övriga skydd för ett hus är förebyggande då det försvårar intrång. Tjuvlarmet är bevakande och larmar om någon tar sig förbi skyddet. Det senare saknas ofta, även på stora företag med hög budget.

Skyddsåtgärder

IT kommissionen finns inte längre, men det material de skapade går fortfarande att nå och ”HANTERING AV IT-INCIDENTER – vem gör vad och hur?” är ett bra dokument att utgå ifrån när man planerar skyddsåtgärder.

Där delas skyddsåtgärder upp i fyra huvudområden:
Proaktiva (förebyggande), t.ex. i form av införande av behörighetskontrollsystem eller incidentrapporteringssystem.

    • Aktiva (operativa), t.ex. i form accesskontroll i realtid eller säkerhetsloggning

    • Reaktiva (detektiva och korrigerande), t.ex. i form av intrångsdetektering eller incidentrespons i realtid

    • Postaktiva (återställande), t.ex. i form av återstartsystem och återhämtningsprocedurer

I dokumentet finns även utmärkta exempel på hur man skall gå tillväga vid ett dataintrång.

Här följer ett axplock av vad man bör tänka på när man som organisation hanterar data. 

Behörighetskontroll/Rättigheter

Det är viktigt att tänka på att personer som skall ha tillgång till data kan, såväl medvetet som omedvetet, bryta mot GDPR. De kan göra det för egen vinnings skull, för att de är tvingade, för att de styrs av processer som inte är GDPR-anpassade eller av brist på kompetens. De kan även omedvetet ha läckt inloggningsuppgifter eller ha en trojan i sitt system. Därför bör man inte ha rättigheter till mer än vad man behöver för sitt arbete. Att ge personer rättigheter baserat på deras titel istället för deras roll, behov eller kompetens, har visat sig vara mycket riskabelt. Det är mycket vanligt att man för vissa system delar inloggningsuppgifter, vilket i sig inte är förbjudet, men är klart olämpligt då det försvårar intrångsdetektering.

Segmentering

Segmentering gör det enklare att skydda de känsligaste delarna av en organisations nätverk. Om någon person eller trojan/virus lyckats ta sig in i ett nätverk så når de inte alla datorer/servrar. Det kan ge organisationen tid på sig att hantera intrånget och minimera följdverkningarna. Segmentering kan liknas vid ett företag med kontorslandskap uppdelat på olika avdelningar. Inom kontorslandskapet kan alla kommunicera fritt. Allt som kommunicerar mellan dessa avdelningar passerar en brandvägg där grundregeln vanligtvis är det motsatta mot inom avdelningen (nätverkssegmentet), dvs allt som inte är tillåtet (öppnat) är förbjudet (blockerat). I brandväggen kan man exempelvis välja att bara tillåta vissa språk (protokoll/portar) och vilka (servrar/klienter) personer man får kommunicera med. Man kan dela upp (segmentera) företaget på en mängd olika sätt, tex baserat på avdelning, hur känsliga uppgifter personalen hanterar, typ av serverhall osv.

Kryptering

Okrypterad datakommunikation är mycket enkelt att avlyssna, vilket innebär att alla känsliga uppgifter bör krypteras även inom nätverket. Tänk på att oviktiga data tillsammans med andra lika oviktiga kan avslöja mycket känsliga uppgifter. Mängden data gör det därför väldigt svårt att avgöra om den tillsammans med annan data är känslig eller ej. Det är därför säkrast att ha som policy att all kommunikation skall krypteras. Det är även viktigt att inloggningsuppgifter alltid är krypterade och inte skickas i klartext, vilket gäller såväl mellan system/servrar som när klientdatorer är uppkopplade mot system. Filer och hårdvara kan stjälas, vilket innebär att såväl hårddiskar som data bör vara krypterade. Annars kan man plocka ur hårddisken och enkelt läsa den utan att ha tillgång till inloggningsuppgifter.

Antivirus

Antivirusprogram tror jag att de flesta vet hur de fungerar så dessa tänker jag inte gå in på djupare på. Men man måste vara medveten om att de måste hållas uppgraderade och att grundinställningarna inte alltid räcker på ett företag.

IDS (Intrångsdetektering / Intrusion Detection System)

IDS används för att på olika sätt detektera intrångsförsök. Om någon trots allt gör ett intrång så måste vi kunna upptäcka det och inom 72 timmar rapportera det till personer som uppgifterna gäller och, om det är allvarligt, till Datainspektionen. Mer om vad som klassas som intrång och hur man skall hantera det kan du läsa hos Datainspektionen. Att sätta rättigheter baserat på vad man behöver tillgång till kan ibland försvåra arbetet på ett oacceptabelt sätt, vilket är fallet för bl.a. polisen och sjukvården. De hanterar denna utmaning genom att ge tillgång till nästan alla uppgifter till samtliga anställda och istället bevaka hur de används och av vem. 

Det finns många saker jag inte tagit upp i denna artikel, så betrakta därför denna artikel som en övergripande beskrivning över hur komplext det kan vara att skydda data. Därför bör inte säkerhet hanteras på slutet, utan beaktas i alla installationer, inköp, utbildningar etc. Det går helt enkelt inte att lösa säkerhetsutmaningarna på slutet genom att låsa in allt i säkerhetslösning och samtidigt kräva att systemen skall vara enkla och flexibla.  Det blir lite som att låsa in alla dokument i ett kassaskåp. Det är säkert, men blir väldigt svårt att arbeta med.

I den tredje och sista artikeln kommer jag att ta upp utvecklingsmiljöer och testdatabaser. Trots att lagen snart är ett år gammal ställer GDPR till stort huvudbry, och då i synnerhet i utvecklingsmiljön. Jag berättar vad man bör tänka på när man skapar testdatabaser och vilka övriga utmaningar vi ställs inför. 

GDPR i praktiken – del 3

Detta är den tredje delen i serien som handlar om de utmaningar vi ställs inför när vi ska hantera GDPR ur ett tekniskt perspektiv.

Utmanande men lönsamt

Den största utmaningen som GDPR ställer på oss är oftast i utvecklingsmiljön, vilket sällan uppmärksammas. Det är här vi kan kontrollera om våra system klarar oförutsägbara händelser och uppgifter som ännu ej matats in. Som jag tidigare skrivit om är det mycket svårt att använda personuppgifter i utvecklingsmiljöer utan att bryta mot lagen, vilket betyder att vi måste byta ut dessa mot fiktiva. Detta kan vara mycket svårt, och beror ofta på att vi byggt in beroenden till specifikt data i våra system. Databaser är sällan tillräckligt väl dokumenterade vilket gör att arbetet med att skapa testdatabaser måste itereras fram för att vi skall kunna vara säkra på att de fungerar

Jag får ofta höra att det är omöjligt eller oförsvarligt dyrt att anpassa sig till GDPR, men lagstiftningen tar inte hänsyn till det. Har ett felaktigt beslut tagits som nu orsakar problem är det viktigt enligt GDPR att hantera den tekniska skulden. Den kunskap vi får av detta kan vi även använda till att hantera konfidentiella data samt skapa anpassade testdatabaser som underlättar testandet vilket resulterar i system med bättre kvalitet. Det innebär att arbetet med att lösa de krav GDPR ställer på oss kan bli lönsamt.

Varför kan vi inte använda produktionsdatabaserna i utvecklingsmiljöerna? 

Först och främst måste vi tänka på att lagen inte gör något undantag gällande var data sparas och att vi ”bara testar”. Det innebär att vi måste ställa exakt samma krav på datahanteringen i utvecklingsmiljö som i produktionsmiljön. Vi måste även ha skäl för att använda personuppgifter i testsyfte, vilket oftast betyder att vi behöver ett specifikt medgivande då ett generellt inte räcker. Men även om vi får samtycke kan vi inte hantera dessa personuppgifter utan restriktioner.

Här följer en kort sammanfattning av vad som krävs av oss gällande att hantera personuppgifter. En mer detaljerad kravställning finns beskrivet i första delen av denna artikelserie.

Vi måste veta:

– Var data är lagrat.
– Vad vi har sparat om enskilda personer.

Vi måste:

– Låta personer läsa vad som finns om dem.
– Ge personer möjlighet att rätta felaktigheter.
– Kunna ta bort uppgifter.
– Skydda data från obehörigt användande.

Detta gäller i samtliga testmiljöer, såsom utvecklares laptops, test och stage. Det är därför ofta svårt, för att inte säga omöjligt, att använda personuppgifter på ett lagligt sätt i testmiljöer.

Städa bort oväsentligt data

Det har ofta sagts att ett visst data har varit ”bra att ha” för framtida bruk. Något som nu är problematiskt då vi har en massa ”skräp” som inte alltid är så lätt att bli av med. Att ta bort allt vi inte behöver, även om det i vissa fall är lagligt att behålla, förenklar arbetet med att skapa och underhålla system och testdatabaser. Att göra detta i samband med, eller innan vi sätter igång arbetet med att ta bort personuppgifter från utvecklingsmiljöerna kan kraftigt förenkla arbetet med testdatabaser. Vi måste även ha i åtanke att allt vi lagrar har en kostnad, inte bara för datalagring, utan även för administration för att hålla den giltig och för att det komplicerar datastrukturerna. 

Skapa testdatabaser

När vi ersätter personuppgifter med fiktivt data, är det även önskvärt att se över hur vi byter ut alla typer av data. Anledningen till detta kommer att tas upp senare.

Det är många faktorer att ta hänsyn till vid skapande av testdatabaser. Här presenteras några:
– Hur får vi tillgång till databasen?
– Vad är det för data vi skall hantera?
– Vem/vilka skall göra jobbet? Säkerhetsklassning?
– Vem/vilka förstår hur den är uppbyggd och kan analysera den?
– Hur gör vi det på ett ”säkert” sätt då den kan innehålla mycket känsliga och konfidentiella data?
– Hur säkrar vi att personuppgifter inte kommer ut i testmiljöer?
– Vilket data behöver vi för att testa?

Hur säkrar vi att det inte går att identifiera personer genom att ”pussla” ihop uppgifter. Det är inte lovligt att peka ut ”någon” i en mindre grupp heller.

Vilken/vilka teknik/er skall vi använda? Anonymisering, pseudonymisering, tokenisering, obfuskering osv?

Hur testar vi att den maskerade databasen fungerar i testmiljön?

Hur testar vi att den maskerade databasen fungerar i stagemiljön tillsammans med andra system?

Kan vi automatisera denna process?

Det är inte troligt att det kommer att fungera felfritt vid första försöket, utan data måste itereras fram på samma sätt som vi utvecklar kod och testar den.

Det finns två grundläggande metoder för att skapa fiktivt data.

1. Maskera data.
Genom att ta produktionsdata och förändra det på ett sådant sätt att det inte går att spåra ursprunget till källan.

2. Generera data. (Syntetisera)
Utifrån algoritmer och listor skapas data helt utan koppling till individer.

Oavsett vilken metod som används krävs det en mycket god förståelse för hur databasen ser ut. Exempelvis: Vilka fält som innehåller personuppgifter, hur de används, och mycket annat. Det är viktigt att förstå fältegenskaper, såsom längd på data, hur det är formaterat, vilka tecken som är tillåtna och så vidare. Det är ofta effektivast att skapa fiktiva data utifrån givna algoritmer där hänsyn tas till variationer som kan komma att uppstå i produktion. Detta kan dock vara svårt att genomföra om det inte gjorts från början, varför det då kan vara lämpligare att skapa testdatabaser baserat på produktionsdata

Personnummer

Personnummer är extra känsligt, då risken inte får tas att generera andra personers personnummer. Det är endast de som är tillhandahållna av skatteverket som får användas. Dessa består av nästan 20000, varav lite över 5000 ligger i åldersspannet 18-65 år. Det är strängt förbjudet att generera fungerande personnummer som riskerar att bli en levande persons personnummer. Det är även viktigt att tänka på att vi har invandring och att det händer att personer av olika skäl får ett nytt personnummer vilket gör att vi inte heller får peka ut någon som kan tänkas få ett oanvänt. Detta kan bli problematiskt om det finns behov av att ha många personer i databasen och personnumren används till att läsa ut ålder och kön.

Konfidentiella uppgifter

Att ta kontroll över ett systems databaser är en förutsättning för att vi skall kunna bli GDPR-kompatibla. Vad vore då mer lämpligt än att nyttja detta fullt ut? På samma sätt som vi hanterar GDPR kan vi hantera konfidentiella uppgifter. Det finns alltid risker med att använda konfidentiella uppgifter i utvecklingsmiljöer och det är en risk i sig att ta bort allt data av en viss typ så att denna del inte testas.

Testbarhet

Vi får även chansen att skapa data som är bättre lämpade att testa med då vi har olika behov i olika faser. Det finns de som hävdar att det enda som går att använda i testmiljöer är produktionsdata för att det inte går att förutse allt som till slut hamnar i databaserna. Detta är en feltolkning som bygger på bristande kontroll. Vi behöver testa systemen med data som utmanar dem genom att se till att det finns extrem data som är tillåtet och med data som är felaktigt för att kontrollera hur det hanteras och så vidare. Testdatabaser bör heller inte vara något som är statiskt. Beroende på var i utvecklingskedjan vi är behöver vi olika typer av data. Med anpassad data underlättar vi utvecklingen, kommer fortare framåt och hittar lättare fel än om vi använder samma testdatabas under hela utvecklingscykeln. Här följer några exempel på databaser som kan hjälpa oss under utveckling, integrationer och test.

”Lagom data”

Felfritt data som inte innehåller några som helst ytterligheter, konstiga tecken etc. Det underlättar de första stegen i komplicerade integrationer. Det går att vara tämligen säker på att innehållet i databasen inte skapar problem.

Gränsvärdesdata

Felfri/udda data, men med ytterligheter som skall fungera.

Felaktigt data

Data med kända fel som vi/systemet skall hitta.

Otillåtet data

Tecken och formatering etc som ej skall få finnas, men som kan ”slinka in” i systemet via integrationer etc. Anledningen till detta är att se hur systemen hanterar dem och att ingenting som stoppas in kan resultera i att system kraschar eller blir osäkra.

Framtida data

Beroende på lagar, fler roller med mera kan vi hantera förändringar i personnummersystemet, som exempelvis om det inte längre är möjligt att utläsa kön. Vad händer om Transportstyrelsen ändrar formatet på registreringsskylten, osv?

Anpassat data

Data för bestämt testsyfte.

Volym

Stora mängder data. 

När vi fått processen att fungera så är frågan om vi någonsin behöver tillgång till produktionsdatat igen. Troligtvis behöver vi inte det.

 

Märkt , ,