Lovene om privatliv kræver, at persondata er beskyttet med rimelig sikkerhed. For analytics betyder det, at du krypterer data undervejs (HTTPS) og i opbevaring (krypteret lager), styrer adgangen til data og holder øje med brud. Sikkerhed er ikke valgfrit. Det er et lovkrav og en forudsætning for at drive forretning.
Hvorfor kryptering er vigtig i analytics
Analysedata sendes over internettet. Uden kryptering kan alle på netværket opsnappe dem. En IP-adresse, et session-id eller data om brugerens adfærd uden kryptering afslører, hvad brugeren laver. Når du krypterer data undervejs, beskytter du mod opsnapning. Når du krypterer data i opbevaring, beskytter du mod uvedkommende adgang til dine servere.
Et lovkrav
GDPR kræver "kryptering eller pseudonymisering" af persondata. CCPA kræver "rimelig sikkerhed". Det er upræcist, men myndighederne forstår det sådan: kryptér følsomme data, især undervejs. Manglende kryptering bliver ofte nævnt som et brud, når der sker databrud.
Kryptering undervejs (HTTPS)
Hvad er HTTPS
HTTPS er HTTP over TLS (Transport Layer Security). Det krypterer al kommunikation mellem browseren og din server. Data undervejs kan ikke opsnappes og læses. HTTPS er mindstekravet til analytics, der følger reglerne om privatliv.
Sådan indfører du HTTPS
De fleste udbydere af hosting tilbyder HTTPS gratis (gratis certifikater). Sæt din hjemmeside op til at bruge HTTPS. Gør HTTPS obligatorisk (send HTTP videre til HTTPS), så al trafik er krypteret. Du kan se, om din side bruger HTTPS, i adresselinjen: der skal være et låseikon.
Sådan sikrer du, at hændelser sendes over HTTPS
Din analysekode skal sende hændelser over HTTPS. De fleste moderne analyseværktøjer bruger HTTPS som standard. Tjek det: går forespørgslerne til analytics i browserens netværksfane til https://... (og ikke http://)? Det skal de.
Har du egen analysekode, så sørg for, at forespørgslerne bruger HTTPS. Eksempel: POST https://din-server.com/api/events (ikke HTTP).
Kryptering i opbevaring
Data i opbevaring er data, der ligger på dine servere eller i databaser. Kryptering i opbevaring beskytter mod uvedkommende adgang, hvis din server bliver kompromitteret eller hacket.
Kryptering af databasen
Din analysedatabase skal være krypteret. De fleste udbydere af cloud (blandt andet Google Cloud) krypterer som standard. Tjek: står indstillingen for kryptering af databasen til "slået til"? Hvis ikke, så slå den til.
Til følsomme data (bruger-id'er, e-mailadresser) kan du overveje kryptering på kolonneniveau: kryptér bestemte kolonner og ikke hele databasen. Så kan du stadig søge i de krypterede data.
Kryptering af filer
Gemmer du analysedata i filer (logs, CSV-filer, eksporter), så kryptér filerne. Brug værktøjer til kryptering eller eksportér til krypteret lager (en krypteret lagerplads i skyen eller en krypteret harddisk). Lad ikke ukrypterede filer ligge og flyde.
Sikkerhedskopier
Sikkerhedskopier af analytics indeholder de samme data som dit live-system. Kryptér sikkerhedskopierne på samme måde som de live data. Er de ikke krypterede, afslører en stjålet sikkerhedskopi alt.
Adgangsstyring og datasikkerhed
Kryptering er kun en del af sikkerheden. Du skal også styre adgangen: hvem kan se analysedata?
Princippet om mindst mulig adgang
Hvert teammedlem må kun have adgang til de data, vedkommende har brug for. En marketinganalytiker har brug for trafik og konverteringer. Vedkommende har ikke brug for logs med IP-adresser. En udvikler, der retter en fejl, kan have brug for detaljerede logs. Når fejlen er rettet, så fjern adgangen igen. Start med begrænset adgang og udvid kun, når det er nødvendigt.
Adgang efter rolle
Opret roller i dit analyseværktøj: analytiker (kan se dashboards), administrator (kan ændre indstillinger) og support (kan se data om bestemte kunder). Giv teammedlemmerne roller efter deres job. Ret rollerne, når folk skifter job eller stopper. Gennemgå adgangen med jævne mellemrum.
Overvågning og logning
Log, hvem der ser hvilke data, og hvornår. Hvis nogen ser analysedata uden for almindelig arbejdstid eller på en usædvanlig måde, så advar dit sikkerhedsteam. Overvågning forebygger trusler indefra og opdager uautoriseret adgang hurtigt.
Håndtering af sikkerhedshændelser
Selv med sikkerhed kan der ske brud. Lav en plan: hvad gør du, hvis analysedata kommer ud?
Trin ved et databrud
1. Stop det: Stop bruddet. Er en server kompromitteret, så kobl den fra. Er adgangskoder lækket, så skift dem.
2. Undersøg det: Hvilke data kom ud? Hvor mange personer er berørt? Hvor længe var de udsat? Det afgør, hvem du skal give besked.
3. Giv besked: De fleste love kræver, at du giver de berørte besked inden for 30-72 dage (GDPR kræver 72 timer). Giv myndighederne besked, hvis det kræves. Vær åben om, hvad der skete, og hvad du gør ved det.
4. Ret op: Find og ret den underliggende årsag. Opdater systemerne, forbedr sikkerheden og ændr rutinerne, så det ikke sker igen.
Kryptering har sine grænser
Kryptering er stærk, men ikke en komplet løsning. En krypteret database bruger stadig hukommelsen (RAM) til at behandle forespørgsler. Data i hukommelsen er ikke krypterede. En angriber med adgang til kørende processer kan hente data fra hukommelsen. Kryptering beskytter mod nogle angreb (opsnapning på netværket og stjålne harddiske), men ikke mod alle (fysisk adgang til kørende servere).
Derfor skal kryptering kombineres med anden sikkerhed: fysisk sikring, adgangsstyring, overvågning og beredskab ved hændelser. Kryptering alene er ikke nok.
Hvordan slår jeg kryptering af databasen til hos min cloududbyder?
Hos de fleste udbydere er det en indstilling, du slår til i konsollen, og det koster som regel ikke noget ekstra. I Google Cloud SQL slår du kryptering og sikkerhedskopier til. Er kryptering slået til som standard på nye databaser, så tjek, at den også gælder for dine eksisterende. De kan ofte krypteres uden nedetid. Tjek status i udbyderens konsol.
Hvor meget påvirker kryptering i opbevaring hastigheden?
Meget lidt. Kryptering af databasen bruger 1-5 % mere CPU. Til det meste analytics kan man ikke mærke det. Kryptering af filer fylder også næsten ingenting på moderne udstyr. Prisen i hastighed er langt lavere end gevinsten i sikkerhed. Spring ikke kryptering over for at spare 1 % i hastighed.
Hvem styrer nøglerne til krypteringen, og hvad sker der, hvis de bliver væk?
Udbydere af cloud styrer nøglerne som standard. Nøglerne bliver automatisk sikkerhedskopieret. Mister du adgangen, så kontakt din udbyder, der kan genskabe den. Ved egen kryptering styrer du selv nøglerne, og mistede nøgler betyder, at data er væk for altid. Brug nøgler, som udbyderen styrer, medmindre du har en stærk løsning til styring af nøgler.
Hvad siger loven om tidsfrister, hvis vores analysedata bliver hacket?
GDPR: giv de berørte besked inden for 72 timer (strengt). CCPA: besked inden for 30 dage. LGPD: uden unødig forsinkelse. Føderale love: typisk 60 dage. Plan: opdag bruddet i løbet af timer og giv besked inden for 24 timer. Det kræver overvågning, beredskab og en juridisk gennemgang, der er klar til brug.
Hvordan gennemgår jeg, hvilke teammedlemmer der har adgang til analysedata?
De fleste analyseværktøjer har indstillinger for roller og rettigheder. Lav en liste over alle brugere, deres roller og de data, de ser. Gennemgå det hvert kvartal: fjern inaktive brugere, tag udvidet adgang væk og tjek, at rollerne passer til de nuværende job. Brug adgangslogs (hvem så hvad, og hvornår) til at opdage afvigelser. Det tager 1-2 timer hvert kvartal.
Hvordan tester jeg, at kryptering virker?
Undervejs: brug browserens netværksfane (den skal vise https://). I opbevaring: tjek udbyderens konsol (den skal vise, at kryptering er slået til). Tjek, at en sikkerhedskopi af databasen ikke kan læses uden nøgler. Test: eksportér krypterede data og prøv at åbne dem uden dekryptering (det skal mislykkes). Gem testresultaterne til brug ved revisioner.