Din sökning innehåller för få tecken
Start Våra artiklar GDPR i praktiken - del 3

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. Den första artikeln handlade om vad som är viktigt att tänka på vid skapande av system som är compliant med GDPR och den andra berörde GDPR från ett säkerhetsmässigt perspektiv.

Klicka här för att läsa del 1
Klicka här för att läsa del 2

GDPR

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.

Verktyg
Det finns företag som säljer verktyg för att skapa testdatabaser utifrån produktionsdatabaser. Dessa gör väldigt bra presentationer om hur enkelt det är. Jag vill varna för att köpa in sådana verktyg, utan att först analysera vad som behöver göras. Det kan inget verktyg i världen göra åt er, vilket har blivit en dyr upptäckt för en del organisationer som inte bara investerat åtskilliga miljoner i dessa verktyg utan även tid och personella resurser på ett stickspår. Dessa verktyg kan däremot hjälpa oss på samma sätt som en skruvdragare oftast är bättre än en skruvmejsel, men vi måste själva välja typ av fästanordning beroende på tyngden hos det vi skall sätta upp och materialet i vägen. På samma sätt måste vi analysera systemet och ta fram våra behov innan vi väljer verktyg.  

Anpassa systemet i sig till test.
Ibland kan även system behöva anpassas för att bli lättare att testa. På Wikipedia kan du tex läsa historien om Konami koden. Vi behöver därför ställa oss frågan om vi kan göra förändringar i systemet, dess validering av data med hänvisning att det blir lättare att testa systemet, vilket kan göra det säkrare, hitta fler fel, men inte minst, utveckla system snabbare och med högre kvalitet.

Avslutningsvis
För att kunna hantera de regulatoriska och säkerhetsmässiga krav vi har på testdata och effektivt kunna hantera dessa bör ett helhetsgrepp tas från organisationens sida. Att hantera dessa frågor på systemnivå kan vara svårt, då det ibland krävs mycket resurser. Vi som arbetar med QA har länge hävdat att vi måste komma in tidigt för att se till att vi inte sätter ihop dåligt testade delar. Det är dock inte ovanligt att det finns en vilja att sätta ihop hela lösningen innan kvaliteten säkrats  i de enskilda systemdelarna och testa ”end to end” – ”för det är det viktigaste”. Det är lätt att tro att det sparar tid, men det är tvärtom. Det gör det nästan omöjligt att testa allt som behöver testas och när brister upptäcks är det svårt att hitta rotorsaken. Så kallade ”end to end” tester bör i första hand användas för att kontrollera att de tester vi tidigare gjort är korrekt utförda.

De svårigheter vi har med att skapa testdatabaser som fungerar i flöden mellan system är starkt påverkat av detta arbetssätt. System och systemdelar samt dess databaser är dåligt dokumenterade. De följer inte standarder och har dåligt definierade integrationer/överlämningspunkter (API), vilket gör det svårt att avgöra om det går att byta ut uppgifter i ett system utan att ställa till problem för andra.

Integrationspunkter är ofta ett mycket lämpligt ställe att utföra såväl manuella, som automatiska tester, vilket inte alltid görs. Istället testas källsystem genom att koppla ihop dem med det mottagande, varefter resultatet kontrolleras i användargränssnittet. Det som då görs är att testa att det ”blir rätt” utan att kontrollera att "rätt åtgärd utförts". Det är som att hoppa över stavnings och grammatikkollen i din ordbehandlare och förlita dig på att den som tar emot förstår vad du menar trots att det kan finnas syftnings och stavfel. Det kan bli rätt, men risken är stor att det inte blir det.

Med ett väl definierat API så är det lätt att upptäcka fel på ett tidigt stadium och rotorsakerna till dessa. Då slipper den inköpande organisationen även det ”blamegame” som annars kan bli fallet när det kommer till olika systemleverantörer vars system är sammankopplade. Det är heller inte helt ovanligt att företaget som ”gjort rätt” får rätta till sin fungerande lösning för att anpassa sig till den som är orsaken till problemet. På grund av GDPR har alla dessa frågor blivit ännu viktigare och det är inte hållbart att ta en kalkylerad risk och bryta mot lagen, vilket många fortfarande gör. Full efterlevnad av GDPR kan endast garanteras när ditt företag har rutiner i hela sin informationsinfrastruktur för att samla in, standardisera, förena, certifiera, skydda och sprida personuppgifter, såväl i utvecklings- som produktionsmiljön.

Jag hoppas att denna artikelserie har gett er en bättre förståelse för de krav som GDPR ställer på er organisation.

Om författaren

Anders M Olausson arbetar som QA-coach och QA-strateg för Zington Quality Management. Han är lösningsinriktad och har lätt för att förstå de egentliga utmaningarna och fokuserar på att lyfta företags kvalitetskompetens. Han är även en van utbildare, föreläsare, coach och mentor med specialistkompetens inom bl.a. GDPR.  Anders har erfarenhet av flertal branscher såsom media, myndighet, utbildning, GIS, tillverkningsindustri och persontransport.

Anders M Olausson
anders.m.olausson@zingtongroup.com