Säkerhet i kod: GDPR och dataskydd för svenska utvecklare

När man pratar om cybersäkerhet tänker många på avancerade hackers som bryter sig in i servrar från mörka källare. Men i verkligheten sker de flesta säkerhetsöverträdelser (data breaches) på grund av små misstag i koden hos helt vanliga företag. I Europa, och i synnerhet Sverige, är säkerhet i kod inte bara en teknisk utmaning – det är ett strikt lagkrav. Sedan GDPR (Allmänna dataskyddsförordningen) infördes har kraven på hur svenska utvecklare hanterar användardata blivit enorma. Företag som missköter sin datalagring riskerar böter i mångmiljonklassen. Som utvecklare måste du ha Security by Design i ryggmärgen.

Privacy by Design (Inbyggt dataskydd)

Konceptet Privacy by Design innebär att säkerhet och integritet ska byggas in i mjukvarans arkitektur från dag ett, inte klistras på som ett plåster i efterhand. När ett svenskt team planerar en ny funktion i sin app, är den första frågan aldrig 'Hur sparar vi all data?', utan snarare 'Behöver vi verkligen spara denna data?'.

Om du bygger ett nyhetsbrev behöver du spara användarens e-postadress. Men behöver du spara deras postnummer eller födelsedatum? Om svaret är nej, ska den koden aldrig skrivas. Konceptet kallas för uppgiftsminimering (data minimization). Genom att inte lagra känslig information skapar du heller inget värde för hackers. Man kan inte stjäla data som inte finns.

Personuppgifter (PII) och Kryptering

Under GDPR är definitionen av en Personuppgift extremt bred. Det är all information som direkt eller indirekt kan identifiera en levande person. Det inkluderar namn och personnummer, men också IP-adresser, geografisk plats och ibland till och med cookies i webbläsaren.

När du hanterar sådana data (ofta kallat PII, Personally Identifiable Information), är kryptering ett absolut krav. I källkoden måste data krypteras både när den vilar i databasen och när den skickas över nätverket via HTTPS. Särskilt lösenord får aldrig sparas i klartext. De måste hashas och saltas med verktyg som bcrypt. Om du någonsin ser ett lösenord i klartext i en svensk databas, har företaget brutit mot lagen.

Samtycke (Consent) och användarens makt

Som frontend-utvecklare kommer du att lägga oproportionerligt mycket tid på flöden för samtycke. Det är därför du ständigt ser cookie-banners på svenska webbplatser. Enligt lagen måste användaren ge ett uttryckligt och frivilligt samtycke innan du får sätta igång dina analysverktyg (som Google Analytics) eller marknadsföringskakor.

Utöver samtycke ger lagen användaren 'Rätten att bli glömd'. Det innebär att du som backend-utvecklare måste designa systemet så att när en användare klickar på 'Radera mitt konto', ska deras data faktiskt rensas från alla databaser och backuper inom en viss tid. Det duger inte att bara ändra status i databasen till isActive = false. Datan måste anonymiseras eller utplånas.

Tredjepartsverktyg och Sårbarheter

Moderna applikationer byggs ofta genom att man drar in externa paket och beroenden (som npm-paket i Node.js). Dessa tredjepartsverktyg sparar enormt mycket tid, men de är också den vanligaste vägen in för hackers. En av dina viktigaste rutiner som svensk utvecklare är att ständigt granska koden för kända sårbarheter (vulnerabilities).

Verktyg som GitHub Dependabot skannar din källkod dagligen och larmar om något bibliotek har ett kortsiktigt säkerhetshål. Det är ditt ansvar att snabbt uppdatera versionerna och rulla ut (driftsätta) lagningen i produktion.

Kulturen kring säkerhet

Om du hittar en säkerhetsbrist eller gör ett misstag, förväntas du i Sverige att omedelbart flagga det, inte gömma det. Transparens är nyckeln. Vid en dataläcka (data breach) har företaget bara 72 timmar på sig att rapportera incidenten till Integritetsskyddsmyndigheten (IMY), annars väntar katastrofala böter. Att vara en skicklig utvecklare i Sverige innebär därför att du skyddar både företagets och användarnas digitala liv med största respekt och vaksamhet.