Kryptering skal redusere risikoen for at uvedkommende får lese opplysninger. Virkningen avhenger av hvor krypteringen skjer, hvem som har nøklene og hvilke angrep løsningen beskytter mot. En kryptert disk kan beskytte en mistet bærbar maskin, men hindrer ikke nødvendigvis en innlogget bruker i å eksportere hele kunderegisteret. Begynn derfor med dataflyten og trusselen, ikke med et generelt krav om at alt skal være kryptert.
Artikkel 32 i GDPR nevner kryptering som et mulig sikkerhetstiltak i en risikobasert vurdering. Den gir ingen universell teknisk konfigurasjon for alle behandlinger. NSMs grunnprinsipper kan støtte arbeidet med beskyttelse og vedlikehold. Valgene nedenfor er en praktisk fremgangsmåte, og konkrete algoritmer, protokoller og produktinnstillinger må kontrolleres mot oppdatert dokumentasjon før innføring.
Beskriv opplysningenes vei
Tegn flyten fra innsamling til bruk, deling, sikkerhetskopiering og sletting. Ta med mellomlagring, eksportfiler og feilhåndtering. En fil kan være kryptert under overføring, men ligge åpent i mottakerens nedlastingsmappe etterpå. Det er hele kjeden som bestemmer hvem som kan få tilgang, og hvor beskyttelsen opphører.
Koble gjennomgangen til kartlegging av IT-systemer. Registrer systemeier, datakategorier, mottakere og tekniske administratorer. Beskriv om leverandøren kan lese innholdet som del av driften. En påstand om kryptering sier ikke i seg selv at leverandøren mangler tilgang til klartekst eller nøkler.
Skill beskyttelse under transport og lagring
Kryptering under transport beskytter forbindelsen mellom bestemte endepunkter. Undersøk hvor forbindelsen avsluttes, eksempelvis hos en tjenesteleverandør eller mellomliggende komponent, og om en ny forbindelse etableres videre. En sikker nettleserforbindelse dokumenterer ikke hvordan data sendes fra applikasjonen til andre tjenester.
Kryptering ved lagring beskytter data under bestemte forutsetninger, blant annet avhengig av hvor nøkkelen finnes. Beskriv om tiltaket beskytter mot tap av fysisk utstyr, tilgang til lagringsmediet eller andre scenarioer. Hvis programmet automatisk dekrypterer for alle som har en bred brukerrolle, må tilgangsstyringen fortsatt vurderes. Kryptering og autorisasjon utfører forskjellige oppgaver.
Vurder når ende-til-ende-beskyttelse er nødvendig
Noen løsninger er laget slik at bare bestemte endebrukere kan dekryptere innholdet. Dette kan gi sterkere vern mot mellomledd, men påvirker også søk, gjenoppretting, integrasjoner og support. Undersøk konkret hvem som kan få tilgang, hvordan mottakere legges til og hva som skjer hvis nøkkelen mistes.
Ikke likestill markedsord med dokumenterte egenskaper. Be leverandøren forklare hvilke data funksjonen omfatter, hvilke metadata som fortsatt er synlige, og hvilke unntak som finnes. Et system kan beskytte meldingsinnhold uten å skjule hvem som kommuniserer og når. Vurder om den gjenværende informasjonen er relevant for risikoen virksomheten forsøker å redusere.
Arbeidsark for krypteringsbeslutningen
| Felt | Spørsmål som må besvares |
|---|---|
| Dataflyt | Hvilke opplysninger og hvilke endepunkter omfattes? |
| Trussel | Hvem eller hva skal tiltaket beskytte mot? |
| Metode | Hvor skjer kryptering og dekryptering? |
| Nøkkel | Hvem oppretter, bruker, oppbevarer og tilbakekaller den? |
| Klartekst | Hvor finnes lesbart innhold før eller etter kryptering? |
| Drift | Hvordan håndteres endring, feil og tap? |
| Kontroll | Hvilket bevis viser at oppsettet virker? |
| Begrensning | Hvilke relevante scenarioer er fortsatt åpne? |
Arbeidsarket bør være kort nok til å brukes per flyt. Et felles teknisk vedlegg kan beskrive standardoppsettet, men avvik må fremgå. Unngå å skrive hemmelige nøkler eller passord i selve vurderingen. Dokumentasjonen skal forklare ansvar og løsning uten å bli en samling av midler til å omgå beskyttelsen.
Gjør nøkkelhåndtering til en egen arbeidsoppgave
En nøkkel trenger en eier, en beskrivelse av bruken og en plan for endring eller tap. Avklar hvilke personer og systemer som kan bruke den, og hvordan tilgangen godkjennes. Vurder om samme nøkkel beskytter for mange uavhengige miljøer. En hendelse kan få større konsekvens dersom produksjon, test og sikkerhetskopier deler samme tilgang uten tydelig behov.
Planlegg rotasjon eller annen utskifting ut fra løsningen og risikoen, og kontroller at gamle data fortsatt kan håndteres når det er nødvendig. Feil nøkkelbytte kan gjøre legitime opplysninger utilgjengelige. Det motsatte problemet er at gamle nøkler beholdes uten oversikt. Dokumenter hva som avvikles, hva som må bevares begrenset og hvem som kan godkjenne bruken.
Beskytt eksport og deling
Fastsett hvordan ansatte deler filer med personopplysninger når vanlig systemtilgang ikke kan brukes. Velg en godkjent kanal og kontroller mottakeren før overføring. Hvis tilgang gis gjennom en lenke, må dere forstå om lenken kan videresendes, om mottakeren må identifisere seg og når tilgangen opphører. Kryptert transport kompenserer ikke for en lenke som gir hvem som helst adgang.
Knytt reglene til IT-reglementet, slik at ansatte vet hva de skal gjøre i en konkret situasjon. Beskriv også hvordan feil mottaker håndteres. En kryptert fil som sendes sammen med dekrypteringsmiddelet til feil person, kan fortsatt gi full tilgang. Overføring av innhold og tilgangsmiddel må vurderes som én praktisk arbeidsflyt.
Kontroller sikkerhetskopier og gjenoppretting
Sikkerhetskopier kan inneholde store mengder opplysninger og må inngå i vurderingen. Undersøk hvor de lagres, hvem som kan hente dem ut og hvor nøklene oppbevares. Hvis både kopien og nøkkelen blir utilgjengelige i samme hendelse, hjelper det lite at sikkerhetskopieringen har meldt teknisk suksess.
Demonstrer gjenoppretting gjennom en avgrenset og godkjent øvelse. Bruk gjenopprettingsplanen for å kontrollere rekkefølge, tilgang og faglig resultat. Beskriv om øvelsen omfattet hele dataflyten eller bare én komponent. Et vellykket uttrekk av en kryptert fil viser ikke alene at applikasjonen kan bruke den etter en større hendelse.
Hypotetisk eksempel: mistet bærbar maskin
En tenkt ansatt mister en bærbar maskin på reise. Virksomheten undersøker om diskbeskyttelsen var aktiv, hvordan innloggingen var sikret og om maskinen var låst. Den vurderer også lokale eksportfiler, registrerte økter og eventuelle tilganger til skytjenester. Den kan ikke konkludere om hele hendelsen bare ut fra at modellen støtter diskkryptering.
Gjennomgangen finner dokumentasjon på den faktiske konfigurasjonen og vurderer behov for å tilbakekalle økter. Hendelsen behandles etter avviksrutinen. Kryptering kan ha betydning for risiko og tiltak, men vurderingen må bygge på om beskyttelsen faktisk var virksom i den konkrete situasjonen. Eksemplet er konstruert og beskriver ingen virkelig tilsynssak.
Vurder leverandørtilgang og tredjeland separat
En skyleverandør kan tilby kryptering og samtidig behandle opplysninger i klartekst for kunden. Kartlegg teknisk tilgang, support og eventuelle overføringer. Dersom en tredjelandsoverføring er aktuell, må dere gjennomføre riktig vurdering av grunnlag og beskyttelse. Overføringsvurdering TIA behandler dette som en egen oppgave.
Ikke anta at kundestyrte nøkler alene fjerner alle overføringsspørsmål. Den konkrete arkitekturen, hvem som kan få tilgang og hvor behandlingen skjer, er avgjørende for analysen. Dokumenter hva tiltaket faktisk endrer. Et produktnavn eller en avkrysset funksjon bør ikke brukes som erstatning for beskrivelsen av dataflyten.
Følg opp den tekniske tilstanden
Hold oversikt over sertifikater, protokoller og komponenter som må vedlikeholdes. Bruk en egen kontroll av TLS og sertifikater for forbindelser. Endringer i leverandørtjenester eller klienter kan påvirke hvilke egenskaper som faktisk gjelder. Eieren må vite hvilke varsler som krever handling og hvem som utfører endringen.
Bevar kontrollresultater som viser miljø, tidspunkt og omfang. Unngå brede formuleringer som «all informasjon er sikkert kryptert» hvis bare enkelte lag eller systemer er kontrollert. Et presist resultat kan si at bestemte enheter hadde aktiv lagringskryptering ved kontrollen, eller at en bestemt forbindelse brukte godkjent oppsett. Slik blir dokumentasjonen forståelig og mulig å etterprøve.
Ta en beslutning som kan oppdateres
Avslutt hver vurdering med valgt løsning, restrisiko og ansvar for oppfølging. Angi hvilke endringer som skal utløse ny vurdering, for eksempel nye mottakere, annen nøkkelforvaltning eller flytting til en ny tjeneste. Denne forbindelsen mellom teknikk og beslutning gjør at kryptering blir et vedlikeholdt sikkerhetstiltak fremfor et ord i et avtalevedlegg.
Kontroller hva leverandørens rapport faktisk dekker
En rapport kan beskrive leverandørens generelle drift eller et bestemt kontrollmiljø. Undersøk om den gjelder tjenesten dere bruker, hvilken periode den dekker og hvilke kundestyrte innstillinger som faller utenfor. Hvis kunden selv må aktivere en funksjon, trenger dere egen bekreftelse på at dette er gjort. Skillet er særlig nyttig ved nye miljøer, hvor standardoppsettet kan avvike fra det etablerte produksjonsmiljøet.
Registrer åpne punkter som konkrete spørsmål med ansvarlig mottaker. «Kryptering bekreftes senere» gir ingen tydelig oppgave. «Systemeier skal bekrefte hvilke roller som kan bruke nøkkelen i produksjonsmiljøet før oppstart» kan følges opp. Dokumentasjonen bør støtte beslutningen om faktisk bruk og vise når en manglende forutsetning hindrer den planlagte behandlingen.