Det är viktigt att bygga in integritet från början när man bygger en mjukvara eller en IT-tjänst. Det är många saker att tänka på som tillsammans skapar ”inbyggd integritet”. Här följer en sammanfattning och några råd. Tänk på att integritetsskydd inte bara är en etisk fråga utan även en affärsmässig. Ett dåligt integritetsskydd kan skrämma bort kunder.
På engelska heter det ”privacy by design”, alternativt ”embedded privacy”, det som på svenska heter ”inbyggd integritet”. De tre viktigaste principerna är dessa:
- Samla inte in mer data än vad syftet verkligen kräver
- Minska informationens känslighet (både initialt och med tiden)
- Tillgång till informationen ska vara på en strikt need-to-know-basis.
Skräckexempel ur verkligheten saknas inte. Den svenska vårdens system för patientjournaler, exempelvis, tillämpar motsatsen till den tredje principen. Alla inom vården har nämligen tillgång till allt. En sjukgymnast som behandlar ett skadat knä kan läsa om sin patients eventuella besök på psyket. Det är inte ”inbyggd integritet” utan snarare ”inbyggd integritetsstöld”. Hur kan våra skattepengar användas så oprofessionellt? Nåväl, här följer en sammanfattning av hur man bygger in integritet i system.
1. Syfte och datainsamling
När ett system som ska innehålla personuppgifter planeras ska man börja med att definiera dess syfte. Det är oerhört viktigt, både av etiska och juridiska skäl. Behandling av personuppgifter är nämligen bara tillåten i den utsträckning som det är nödvändigt för att uppfylla syftet.
Utgående ifrån syftet ska man bara samla in den information som verkligen behövs – inte all information som råkar finnas tillgänglig. Sedan gäller det att stå emot frestelsen att lite senare göra sig skyldig till ändamålsglidning. Vad är det? Jo, efter en tid säger någon i organisationen: ”All den här intressanta informationen kan vi ju faktiskt använda för xxx också”. Detta är en torped under vattenlinjen för den personliga integriteten – och tyvärr vanligt förekommande.
2. Minimera känsligheten
När informationen är insamlad vidtar nästa fas – att minimera känsligheten. Det kan göras vid systemdesignen på flera sätt, och alla användbara metoder bör kombineras. Är det nödvändigt med personnummer? Är det nödvändigt med identiteter över huvud taget? Om det går bör så mycket data som möjligt anonymiseras så snabbt det går. Är det omöjligt? Men kanske kan uppgifterna då åtminstone pseudonymiseras? Om det inte går att göra från början kanske det åtminstone kan göras efter en tid? Bygg i så fall från början in denna fördröjda anonymisering eller pseudonymisering.
Ett annat sätt att minska känsligheten i informationen är att lagra grupptillhörighet istället för information på en mera detaljerad nivå. Ett exempel: En internetbokhandel kan minska känsligheten i sin databas genom att lagra att en viss kund har köpt en bok i kategorin ”politisk litteratur” istället för att lagra att han/hon har köpt ”Det kommunistiska manifestet”.
Ett tredje sätt är att successivt gallra. Kanske viss information bara behövs det första året? Bygg då redan från början in en automatisk rutin som kastar bort den efter ett år. Eller anonymiserar, eller åtminstone pseudonymiserar. Bäst är anonymisering, inte bara för integritetsskyddets skull utan även för att Personuppgiftslagen då inte längre gäller. Det senare är praktiskt för företaget eller organisationen.
3. Begränsa tillgången
Tillgången till databasen ska begränsas så mycket det går. Användarna bör delas upp i kategorier, och varje kategori ska bara kunna få ut den information som verkligen är nödvändig för just de användarnas behov. Motsatsen till hur svenska patientjournaler hanteras, alltså. Även när det gäller hämtning av information ur databasen ska en avstämning mot syftet göras. Krävs det verkligen att kategori y får tillgång till information z för att syftet ska uppfyllas?
Riskanalys och datasäkerhet
Som en del i inbyggd integritet måste man också göra en riskalanlys i planeringsfasen. Vilka risker finns och var uppstår dessa? Exempelvis kanske man kommer fram till att hoten huvudsakligen utgörs av hackare, företagets normala användare samt systemadministratören. Då måste man analysera var och hur dessa grupper har möjlighet att sätta in stöten, så att säga, och bygga ett skydd mot det. Skyddet är vanligen både tekniskt och administrativt (i form av rutiner).
Data måste skyddas både under transport och lagring. Kryptering är ofta en bra början, men inte tillräcklig. Det beror förstås på att det finns en nyckel någonstans, och att det finns personal som ska komma åt informationen (dock bara för legitima syften, och utan att den kan läckas efteråt av misstag). Ett hot som ofta förbises är systemadministratören. En illvillig eller slarvig sådan kan ofta åstadkomma stor skada för integriteten.
Det måste också finnas en loggning av all tillgång till databasen, liksom rutiner för att verkligen följa upp loggfilen. Detta är till och med ett krav i Personuppgiftslagen. Och naturligtvis ska inte systemadministratören kunna manipulera loggfilen.
Ska man gå på djupet måste man konstatera att det utvecklande företagets egna programmerare också utgör ett hot. De skulle kunna bygga in dolda bakdörrar som ger dem själva möjlighet att gå förbi alla spärrar, exempelvis. Men i ett sådant här nyhetsbrev måste man begränsa sig. Jag arbetar med konsulthjälp för IT-företag avseende inbyggd integritet, och håller också föreläsningar i ämnet. Tag gärna kontakt för en förutsättningslös diskussion om du är intresserad.
Visste du förresten att Personuppgiftslagen kommer att ersättas av en EU-gemenssam lag? Den är inte färdigskriven än, och kan komma att träda i kraft tidigast 2016.
Pär Ström