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.
GDPR i praktiken - mer läsning
Detta är del 3 och sista delen i ämnet, men här hittar du även de båda tidigare artiklarna. Del 1 handlar om hantering av data/arktiktektur och del 2 hur du skyddar data.
