Hvordan lagre personopplysninger i applikasjonen?

Vi har selv valgt å bygge en sentral identitetstjeneste for oppbevaring av alle personidentifiserende opplysninger i egne applikasjoner, inkludert både MailRisk og websidene våre.

Fordi bruk av denne tjenesten blir det enkleste valget når nye behandlingsbehov melder seg for personopplysninger, tvinger vi alltid oss selv til å gjøre det riktig.

Den viktigste suksessfaktoren er grunnlaget som ble lagt tidlig i utviklingsprosessen, gjennom risikovurdering av hvordan personopplysninger håndteres i kontekst av hele virksomheten. Dette gav oss en klar prioritering på at tjenesten skulle etableres, og at innebygd personvern er nødvendig.

Selv om ulike applikasjoner har individuelle behov for behandling av personopplysninger, kan vi isolere personidentifiserende attributter til ett bestemt sted i arkitekturen. Dersom en av applikasjonene skulle utsettes for hacking, vil det være langt vanskeligere for en angriper å ramme enkeltpersoner fordi de kun finner pseudonyme applikasjonsdata der. Dersom identitetstjenesten skulle rammes i stedet, medfører ikke dette alene at brukernes data fra applikasjonene blir eksponert.

Orden på behandlingsgrunnlag

En annen fordel er at vi alltid kan koble behandlingsgrunnlag, formål, kilde og oppbevaringstid mot alle personer i databasen, på ett sted.

Som databehandler på vegne av kunder som bruker MailRisk, har vi klare instruksjoner for behandling av data gjennom tjeneste- og databehandleravtalen. Så snart en bruker åpner MailRisk for første gang, opprettes brukeren i identitetstjenesten basert på en pseudonym bruker-ID som vi mottar fra den lokale Outlook-klienten. Samtidig hekter vi på attributtet "processor" for behandlingsgrunnlag, samt "app-access" som formål. I tillegg lagrer vi som kilde den spesifikke URL for siden som brukeren initierte i applikasjonen. Med prinsippet om dataminimalisering som utgangspunkt, trenger vi faktisk ikke noe mer info om brukeren enn dette.

Markedsføring er et helt annet kapittel, og vi inviterer blant annet besøkende til å abonnere på nyhetsbrevet vårt. Det kunne jo være lettvint å lage en egen tabell for e-postadresser til mottakere av nyhetsbrev, i samme applikasjon som ligger til grunn for nettsidene. Like fullt har vi lagd en integrasjon mot identitetstjenesten vår til dette formålet også.

Med nyhetsbrevet er det imidlertid vi selv som har definert formålet for databehandlingen. Dette gjør at vi er behandlingsansvarlig, og må skaffe til veie et juridisk grunnlag for å lagre e-post-adressen abonnenter oppgir til oss. For de oppføringene som er kunder allerede, legger vi inn "contract" (eller "legitimate interest") som juridisk grunnlag i databasen.

For de som registrerer seg selv via nettsidene, må vi derimot bruke "consent" (samtykke) som grunnlag. Her blir det også viktig at vi har en referanse til hvor og når dette samtykket ble gitt, og ikke minst hva det ble gitt samtykke til.

Fordi vi benytter Git med versjonering for all håndtering av kode, inkludert utrulling av layout og tekst til nettsidene våre, kan vi alltid finne igjen hvilken formulering av registreringsskjemaet som til enhver tid var publisert på nett. Et alternativ kan også være at kopi av samtykke-teksten legges i et eget databasefelt sammen med personopplysningene som ble gitt.

Økt anvedelse av kryptering

En annen fordel opplever vi med praktisk implementasjon av kryptering for utvalgte felter. Så snart man begynner å kryptere data i databasen, gjelder det å sikre at absolutt all skriving skjer med krypterte data, og at all lesing vil levere dekryptere data.

Dersom personidentifiserende attributter var spredt omkring i forskjellige databaser og tabeller kan det bli vanskelig å holde oversikt over hva som er kryptert eller ikke. Ikke minst blir det blir lettere for utvikleren å glemme at nye felt må krypteres, hvis mulig.

Innenfor identitetstjenesten vår er alltid standardtilnærmingen at data skal krypteres, med mindre vi har et godt begrunnet behov for å sortere eller søke på feltet. Slik kan vi kraftig redusere risiko relatert til et sikkerhetsbrudd, i tilfelle uvedkommende skulle få tilgang til databasen. Så lenge krypteringsnøkkelen ikke ligger på databaseserveren for identitetstjenesten, må en angriper lykkes på langt flere områder før vi eventuelt har identifiserbare personopplysninger på avveie.

Ikke bare personvern

Med GDPR like rundt hjørnet, er det naturligvis enkelt å prioritere personvernvennlige løsninger. Selv om personvern er viktig, opplever vi det generelt nyttig å bygge en robust infrastruktur som både øker datakvalitet og forenkler vedlikehold gjennom veldefinerte og løst koblede tjenester.

Ikke minst blir det mye enklere for oss å håndheve datasubjektenes rettigheter og demonstrere samsvar med lovverket. Begge deler er helt grunnleggende forutsetninger for å bygge skalerbare produkter og en skalerbar virksomhet langt inn i framtiden.

Lite hadde vært mer frustrerende enn å oppleve at personvernreglene ble et hinder for vår evne til innovasjon!

For anvendelse av MailRisk som sikkerhetsprodukt, kan våre kunder med klare holdepunkter i fortalen til GDPR benytte legitime interesser som behandlingsgrunnlag overfor ansatte. Da trenger man ikke samtykke. Med innebygd personvern og dataminimalisering som utgangspunkt, kan vi likevel gi brukerne selv anledning til å oppgi identifiserende opplysninger på eget initiativ. Det kan jo være kjekt å gi seg til kjenne når man samler poeng og konkurrerer å bli «månedens svindeljeger» i MailRisk?