GDPR for nettsider

En guide for webprosjekter

Personopplysninger skal være trygge, korrekte og tilgjengelige – og 100% kontrollert av brukeren selv. Slik løser vi dette i kundeprosjekter!

INTRO

Dette er en bloggserie i to deler:

Del 1: GDPR for digitale byråer

Del 2: GDPR for nettsider (denne posten)

GRUNNLEGGENDE GDPR-TILTAK FOR SAMTYKKE

De fleste spørsmålene vi får er om samtykke samtykke, cookies og personverninformasjon. Her følger de viktigste tiltakene.

Vi samler bare inn nødvendige persondata

Vi spør ikke etter personlige info fra brukeren for moro skyld. Trenger vi virkelig både e-post og mobilnummer? Hvis ja, skal det fremkomme klart for brukeren akkurat hvorfor.

En personvernside som beskriver hva slags data vi samler

Hvert nettsted får en side kalt Personvern. Her beskriver vi hva slags informasjon vi samler, hvorfor vi gjør det, og hvordan. Her beskriver vi også hvordan brukeren kan endre eller slette sine persondata – eksempelvis ved å kontakte support, eller logge inn på Min side.

OBS: Dette er ikke siden for juridisk og teknisk vissvass. Vi bruker enkle ord og et lettfattelig språk.

Cookies: La brukeren velge selv

Vi setter nesten alltid informasjonskapsler (cookies) på brukerens nettleser. I en popup informerer vi brukeren om hva slags cookies vi har tenkt til å plassere, og hvorfor. Brukeren må aktivt trykke på en knapp for å akseptere disse. Uten samtykke, ingen cookies. Nesten. Det er nemlig ikke alle cookies som krever samtykke, for eksempel cookies for et GDPR-vennlig oppsett av Google Analytics, eller for nødvendig CMS-funksjonalitet.

Slik ser vår popup ut for øyeblikket. Enkelt språk, med mulighet for å lese mer.

TRYGGE PERSONOPPLYSNINGER

Google Analytics settes opp GDPR-vennlig

Ved å bruke Google Tag Manager kan IP-adresser anonymiseres. IP-er er nemlig definert som persondata! I praksis betyr dette at siste del av IP settes til 0. Slik kan IP benyttes til omtrentlig geolokalisering, men ikke for å identifisere enkeltpersoner.

Dette gjøres ved å legge til parameteret anonymizeId i Google Analytics scriptet ditt.

ga(‘send’, ‘pageview’, {

‘anonymizeIp’: true

});

Bruker du Tag Manager, kan du gå til tag for Analytics, og velge More Settings -> Fields to Set og deretter opprette feltet ‘anonymizeIp’ med verdien ‘true’. Voilà!

Brukerdata som e-postadresse eller bruker-ID sendes aldri til Analytics. Dette ville forøvrig være et brudd på retningslinjene til Google, og du ville risikert at kontoen din blir lukket (også før GDPR).

Individuelle brukerdata slettes automatisk regelmessig – her trenger man ikke gjøre noe.

Datatrafikk er kryptert med TLS

Vi bruker HTTPS for all webkommunikasjon og API-er.

Kryptert backup

Dette gir beskyttelse av data også dersom uhellet er ute og backups blir stjålet.

Pseudonymisering av brukerdata

Noen ganger er det hensiktsmessig å bevare brukerdata for ettertiden, uten at det er relevant å koble disse direkte til personalia. Pseudonymisering vil si at identifiserende parametere erstattes med pseudonymer, som fremdeles vil være unike indikatorer.

I en database kan vi eksempelvis erstatte personens navn med en unik numerisk ID. Slike tiltak som gjør det vanskeligere å knytte personopplysninger til et individ – men ikke umulig. Pseudonymisering gjøres kun etter avtale med kunde.

Streng tilgangskontroll for admingrensesnitt

Ikke alle administratorer trenger tilgang til alle brukerdata – dette bør begrenses til en superadministrator. Der det er mulig begrenser vi slik administratorfunksjonalitet basert på IP-adresse, samt at vi benytter tofaktor autentisering.

Prosjektteam: Begrense tilgang

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

Tilgang til kodebase kun for teamet

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

Serverlogg

Våre logger registrerer IP-adresser av hensyn til sikkerhet og sporbarhet. Disse oppbevares så kort tid som mulig: Nok til at vi har tid til å undersøke IP ved et eventuelt datainnbrudd, men heller ikke lenger. Vår standard for dette er én uke.

Loggene inneholder ikke annen data som kan identifisere enkeltpersoner.

Personlige data i API-er beskyttes

Når våre API-er er datakilde for tredjeparter, implementerer vi kall for sletting av brukerdata. Dette gjør at brukere kan glemmes. Vi gjør ikke personlige data tilgjengelig for anonyme brukere.

Kvalitetskontroll av tredjepartstjenester

Før vi benytter tredjeparts API-er, sjekker vi om persondata kan slettes i deres system

Brukerdata delt med tredjeparter

Vi har oversiktstabeller som viser hva slags data som deles med hvilke tredjeparter. Dersom samtykke til deling trekkes tilbake, gjør vi kall for å slette brukeren fra tredjepartens database.

Servertilgang via SSH

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.

Vi lagrer ikke MAC-adresse, IMEI eller andre data som kan knyttes direkte til en enhet

For mobilapplikasjoner samler vi ikke data som identifiserer en enhet direkte. Vi knytter heller samtykke til brukerprofiler, slik at samtykke kan reverseres.

Vi tester applikasjonen for de vanligste sårbarhetene

Applikasjonen testes for OWASP Top 10 Application Security Risks før den lanseres. Dette tiltaket minsker sannsynligheten for datainnbrudd og lekkasjer.

KORREKTE PERSONOPPLYSNINGER

Brukere kan endre sine brukerprofil

Websystemet tillater at brukerprofildata endres – enten av brukeren selv, eller ved å henvende seg til supportavdelingen.

Brukerprofiler kan slettes fullstendig

Vi tillater at brukere fjernes fullstendig fra databasen. Databasen vil da fremstå som om brukeren aldri har vært der. Som regel besørger vi et administrasjonsgrensesnitt for denne operasjonen.

Vi sletter brukerdata som ikke lenger er nyttige

Brukerdata lagres ikke lenger enn nødvendig. Dersom vi er sikre på at dataene ikke er nyttige, vil de enten slettes eller anonymiseres. Som standard slettes unødvendige personopplysninger fra databasen ukentlig ved hjelp av en automatisert serveroppgave.

TILGJENGELIGE PERSONOPPLYSNINGER

Backups

Vi tar daglige backups av databaser. Disse krypteres og lagres i et annet datasenter enn noen av applikasjonsmiljøene.

Brukerdata kan eksporteres

Brukere kan bestille eksport av sine brukerdata. Eksporten er som regel en manuell prosess som resulterer i et strukturert dokument med data som ordrehistorikk eller meldinger.

Gjenoppretting ved havari av server eller kode

Vi har prosedyrer for gjenopprettelse av kode, database og harddisk. Disse beskrives i egne vedlegg.

RUTINER OG AVTALER

Frontkom sjekkliste for lanseringer

Før hver lansering, går teamet gjennom en 100 punkts sjekkliste. Denne omfatter blant annet testing og konfigurasjoner på applikasjoner og server, samt kickstart av rutiner og dokumentasjon for GDPR.

Databehandleravtale

Dersom leverandøren lagrer eller behandler persondata, er en databehandleravtale påkrevd. I denne bør de fleste av punktene over dekkes, samt en del juridiske finurligheter. Frontkom har laget sin egen avtale basert på rådene fra Datatilsynet. Denne vil vi snart dele med omverdenen – ta kontakt om du er interessert, eller har spørsmål om implementering av GDPR!

I bloggposten GDPR for digitale byråer beskriver vi mer inngående hvilke rutiner som bør være på plass hos prosjektleverandøren.