En praktisk guide

GDPR krever nye rutiner og løsninger for å fremme personvernet. Vi har laget en rett-på-sak oversikt over hvordan vi som digitalbyrå innfrir kravene.

Introduksjon

Dette er en bloggserie i to deler:

• Del 1: GDPR for digitale byråer (denne posten)
• Del 2: GDPR for nettsider

I denne posten viser vi hvordan designere, utviklere og sysadmin kan innfri GDPR-kravene. Rutinene fungerer også for andre roller, som prosjektledere og konsulenter. De er således nyttige for alle deltagende parter i et webprosjekt, og ikke bare for webbyrået. Håper du finner noe du kan stjele – vi støtter personvernet!

GDPR for designere

Personvern starter i designprosessen. Når UX-teamet vårt planlegger et webprosjekt, designer vi med personvern som førsteprioritet. Her er noen spørsmål vi stiller oss selv i designfasen:

• Hva slags brukerdata trenger vi egentlig?
• Hvor lenge har vi nytte av å lagre dataene?
• Hvordan kan vi opplyse brukeren om bruk av data vi samler inn, og hvordan dette kommer brukeren til gode? Dette er spesielt viktig for skjemaer.
• Kan noen av dataene anonymiseres eller pseudonymiseres?

Designernes funn deles med hele prosjektteamet for videre diskusjon: Bør noe funksjonalitet droppes? Bør vi etterspørre mindre informasjon? Den gylne personvernregel: Ikke lagre data om andre du ikke vil at andre skal lagre om deg!

GDPR for utviklere

Webutviklere benytter en rekke ulike systemer som kan inneholde persondata. Disse dataene skal ikke bare skjermes for sluttbrukere, men også fra utviklere. De fleste av GDPR-tiltakene går derfor på datasikkerhet.

Dette gjelder for eksempel:

• Lokalt utviklingsmiljø på utviklerens datamaskin
• Utviklingsserver, testserver og produksjonsserver
• Backupfiler
• Kodebase på versjonskontroll (Git)
• Tredjepartssystemer som e-postsystemer og analyseverktøy

Sikkerhetsmekanismer må selvsagt bygges inn i selve systemene (mer om dette i del 2!). Her skal vi fokusere på utviklernes rutiner.

Hver og én utvikler må jevnlig spørre seg to spørsmål:

1. Har jeg tilgang til personlige data på laptop eller server, uten at dette er nødvendig?
2. Er dataene jeg har tilgang til sikret mot et “worst case”-scenario?

Disse spørsmålene har vi brutt ned i to sett med rutiner: En éngangsrutine, og en ukentlig sjekk.

Webutviklerens éngangsrutine

Dette er en oversikt over ting man gjør én gang – set & forget:

• Bruk LastPass for passordlagring, og sett 16 tegns hovedpassord (Enterprise firmakonto)
• Sett sterkt passord på laptop
• Skru på tofaktorautentisering for G Suite (for å sikre e-post og dokumenter)
• Skru på tofaktorautentisering for Github.com
• Krev PIN-kode på telefonen (hyppig)
• Skru på Finn min Mac og Finn min iPhone, samt tillat fjernsletting
• Mac: Krev passord ved innlogging og etter dvale
• Mac: Skru på FileVault for kryptering (dette kan ta noen timer)

Frontkom bruker et Google regneark, der alle krysser av for at hvert punkt er utført.

Webutviklerens ukentlige rutine

Én gang i uken fyller våre utviklere inn et Google forms-skjema. Her setter de kryss for at rutinen er fulgt, og de kan også rapportere avvik.

• Jeg har ikke lokale personsensitive databaser, filer eller e-poster jeg ikke trenger.
• Jeg har ikke tilgang til databaser eller kodebaser jeg ikke lenger trenger.
• Jeg har ikke funnet avvik i våre prosjekter eller internsystemer siste uke.

Dersom man ikke kan svare bekreftende, må man fylle ut et felt med mer informasjon. Eksempelvis: “Jeg har visst fortsatt tilgang til Dropbox for kunde X, og der ligger backup av medlemsdatabasen deres.”

Denne seansen er nok ikke veldig spennende. På den annen side er det fort gjort å sette noen kryss. Og når avvik først skal rapporteres, er det vel like greit å ha det som en gjentakende hendelse i kalenderen?

En dedikert person går gjennom svarene hver uke.

Fun fact: Jeg har selv blitt kvitt gamle data om titusenvis av brukere – de fleste i form av CSV importfiler i gamle e-poster. Rutinen fungerer!

GDPR for sysadmin

Superbrukeren for infrastrukturen vår har et særskilt ansvar. Ved å rigge infrastrukturen lurt, gjør vi det vanskelig for ansatte å gjøre feil. Her er systemrutiner som øker sikkerheten og minsker faren for tilgangsblemmer:

Prosjektteam: Begrense tilgang

Vi er tydelige på å definere hvem som er innenfor og utenfor et prosjekt. En superbruker gir tilgang til prosjektsystemet kun for de som faktisk trenger dette. Når man ikke lenger jobber aktivt med et prosjekt, blir brukertilgangen fjernet.

Tilgang til kodebase kun for teamet

Tilgang til Git repositories gis kun til det relevante prosjektteamet. Hele Frontkom har altså ikke tilgang til alle prosjekter. For å få tilgang til Git, må man videre bruke en VPN-tilkobling. Dette minsker sjansen for at uvedkommende skal få innsyn i kode. Koden i seg selv inneholder sjelden persondata. Men om uvedkommende har tilgang til hele kodebasen kan dette utgjøre en sikkerhetsrisiko.

Servertilgang via SSH

Nå blir det litt teknisk: Webutviklere logger seg inn på servere via terminalen, men får kun tilgang dersom deres personlige nøkkel ligger i “authorized keys”-filen. Med egen Linux-brukere per prosjekt, gir vi kun tilgang til prosjektteamets nøkler. Det gjør det umulig å logge inn på en server uten at man er aktiv i prosjektet.

Backup av databaser er kryptert

Backups lagres kryptert på egne servere.

Wi-Fi og nett sikres

På kontorene våre benyttes WiFi-rutere fra anerkjente leverandører. Og like viktig: Vi har en rutine for å oppdatere firmware jevnlig. WiFi-rutere er nemlig et yndet mål for hackere. En svakhet her kan gi uvedkommende tilgang til alt som skrives i nettleseren.

Du skal ikke tåle så inderlig vel, de datainnbrudd som ikke rammer deg selv!

TL;DR

GDPR fremtvinger en rekke rutiner for hele bedriften. En god start er å spørre: Hvordan kan vi lagre minst mulig persondata, med størst mulig sikkerhet?

Bloggseriens del 1 handler om rutiner. Del 2 handler om produktet. Hvordan bør en webside eller applikasjon utformes for å innfri GDPR-kravene? Denne publiseres om et par uker.