GDPR i affärsverksamhet (Softa)! – Känsliga uppgifter och hur man inför dem i en databas

Om du har hängt med så här långt läser du nu den tredje artikeln i min GDPR-serie. Grattis! När du läser det här är det bara 100 dagar kvar tills GDPR införs. I den här artikeln ska vi titta på efterlevnad inom IT-Softa-verksamhet och hur det är kopplat till GDPR i framtiden.

Efterlevnad inom IT-Softa-affärsverksamhet?

När jag säger Softa menar jag ”slappna av” på svenska. Den här artikeln skrevs särskilt för utvecklare, arkitekter och fullfjädrade programmerare, för att uppmuntra er alla att också slappna av. Du är inte ensam med dina tankar och jag vill att du ska veta det. Softa-verksamhet är en förkortning av programvaruutveckling och integrationsarbete.

Softa ger slutanvändarna ett verktyg för att utföra sitt arbete. På ett sätt är det som att skapa ett verktyg för att göra ett hål i väggen. Ibland är verktyget en tjänst som innebär att någon utför jobbet åt en, andra gånger är det en hammare som du använder för att slå i väggen med och ibland är det helt enkelt något explosivt. Med Softa-affärsverksamhet kan det antingen vara ett projekt du påbörjar från scratch eller ett av alla de integrerade verktygen att interagera med. Andra gånger är det bara ett sätt att tillhandahålla data och ge ett visuellt användargränssnitt för vyn till dessa.

I samtliga fall gäller samma sak: den måste vara utformad för att leverera något till någon.

GDPR-karta

Många verktyg och programvaror är helt enkelt för gamla och föråldrade idag. Kompatibiliteten saknas, då de har 30 år på nacken och inte kan användas för att arbeta i dagens nya system. Så jag ber de ägare av företag som läser det här att medge sin brist på efterlevnad. Vad är din nästa lösning? Ta tid på dig; det kan kosta mer nu, men det kommer vara en bra långsiktig investering.

Databaser

Du kanske redan har haft en första kontakt med Microsoft SQL. Jag vet att tekniska människor hatar mig när jag säger det men jag anser att Excel-blad är en databas och att de fungerar på samma sätt som SQL. (Ja, jag vet att de inte gör det, men det är trevligt att göra saker enkla)

Om du har data i din databas i ett fält och börjar känna dig obehaglig till mods över att det är en tydlig text och synligt kanske du lägger manken till lite och krypterar dina data. Du kan göra samma sak i Excel, men det är inte längre till någon nytta för den användare som försöker läsa dessa data.

När du har krypterade data blir nästa fråga: hur ska denna krypterade version av dina data distribueras?

Det finns alltså ett otal sätt att kryptera data i en databas. Utmärkt, efterlever vi kraven nu? Jag är ledsen, men svaret är nej.

Nästa fråga är: varför samlar ni ens in den där informationen till att börja med?

Behöver verkligen en videouthyrningsfirma veta ditt personnummer? Kan UID-koden (unified identifier) bara vara ett löpnummer från 100? Jag vet många fall då databashanterare samlar in information som de inte bör samla in.

Så nästa gång du utformar en databas och fattar ett beslut om vad du ska inkludera i den bör du fundera lite över vilka data du behöver. Kom ihåg att vem som helst som använder databasen i framtiden är en ”registeransvarig” som är ansvarig för att rapportera vad som samlades in och varför till användarna.

Med dessa två faktorer i åtanke skulle jag kunna säga att Softa-återförsäljare har en högre efterlevnad och förmodligen är bättre än 80 procent av de återstående alternativen.

Känsliga data

Du kanske har hört att det i många länder finns program som myndighetsaktörer använder för att samla in medicinska data i en stor, strukturerad databas. I Finland kallas det för Kanta-projektet. En direkt översättning skulle vara ”databas”. Så jag hänvisar till föregående avsnitt. Och vad händer om det är obligatoriskt att samla in känsliga data? Vad är ens känsliga data? I detta Kanta-projekt är det medicinska data, vilket jag alltid anser är känsliga data. Det innebär att det är obligatoriskt att ha ett personnummer och min personliga information. Jag förstår det. Det jag innerligt hoppas är att de som utformat databasen visste vad de höll på med med tanke på den typ av data det handlar om, vilket även gör det frestande för hackare att prova och se hur väl skyddade dessa data är. Jag ser ett stort hot i hur nästa generations dataarkitekter kommer att använda denna information.

Så när du har känsliga data i din databas bör du först tänka igenom hur du ska spåra användningen av dessa data. Du bör ha ett databasverktyg som gör det möjligt att markera när någon får åtkomst till informationen. Jag är exempelvis intresserad av vem som kan se i Kanta att jag är laktosintolerant och varför de behöver den informationen. Första steget är naturligtvis att markera i en databas vilka fält som är känsliga. I medicinska databaser är sjukdom ett känsligt ämne, men det kan ditt medlemskap i ett fackförbund också vara (i en bild i övre högra hörnet). I många medicinska system kallades det för ”tassavtryck”, vilket hänvisade till det papper på vilket du faktiskt lämnade ditt fingeravtryck. Du kan lägga till en tagg eller en inmatning i databasen så att människor kan få åtkomst till informationen. En polis kan exempelvis inte bara gå in bara på kul för att se om grannen har förlorat sina licenser. De behöver en ANLEDNING för att göra det.

I vissa system skulle det kallas för granskningslogg. Jag skulle inte rekommendera SQL här utan tvekan. I många filsystem har det funnits i åratal, men används sällan. Och låt mig påminna om att på den gamla goda tiden kallades filsystem i UX-fält för databaser. Om vi går tillbaka till känsliga data så bör man också komma ihåg det jag skrev i min förra artikel – användaren har också rätt att bli bortglömd.

Den politiska frågan

Gäller mina rättigheter enligt GDPR, känsliga data och rätten att bli bortglömd, i fallet med Kanta? Vad skulle EU-kommissionen säga om jag prövade mina rättigheter gentemot en myndighetsaktör? Jag antar att jag skulle förlora fallet? Jag är intresserad av att höra era tankar nedan.

Några avslutande ord

Det finns många olika sätt att angripa ämnet programvaruverksamhet, utveckling och integration. Hur levererar de informationen från sina system till någon annan, exempelvis externa reklamföretag? Som vi kan se är listan över möjliga brott mot efterlevnaden oändlig.

Har du som återförsäljare av programvara personliga erfarenheter av att inte ha tänkt på GDPR? Kom du på senare att du borde ha gjort det? Handlade det om en teknisk lösning eller datastruktur?

Nästa artikel publiceras tisdagen den 27 februari – det blir den sista i serien. Fortsätt läsa! Glöm inte att dela med dig av dina intressanta tankar.

P.S. Referensuppgifter du kanske är intresserad av: https://thehackernews.com/2017/07/sweden-data-breach.html
Se även avsnittet ”here is what happened.” Skulle det kunna hända dig?