Når en virksomhed bruger kryptering, er det naturligt at spørge, om data er beskyttet. Men der er et mere teknisk spørgsmål, som ofte får mindre opmærksomhed: Hvem kontrollerer de krypteringsnøgler, der beskytter virksomhedens information?
For krypteringsnøgler er ikke bare en teknisk detalje. De er en central del af sikkerhedsarkitekturen. Hvis du ikke ved, hvem der kontrollerer nøglerne, ved du heller ikke nødvendigvis, hvem der i sidste ende har kontrol over adgangen til de beskyttede data.
Kryptering er ikke det samme som kontrol
Når en leverandør siger, at en platform er krypteret, fortæller det ikke nødvendigvis hele historien.
Der findes forskellige modeller for, hvordan krypteringsnøgler genereres, opbevares og administreres.
I nogle løsninger håndterer leverandøren både systemet, dataene og nøglerne. I andre modeller får kunden større kontrol over nøglehåndteringen. Der findes også arkitekturer, hvor krypteringsnøgler holdes adskilt fra den primære datainfrastruktur.
De forskellige modeller har forskellige sikkerhedsmæssige konsekvenser.
Det centrale spørgsmål bliver derfor ikke kun:
“Er vores data krypteret?”
Men også:
“Hvem kan kontrollere de nøgler, der kan give adgang til dataene?”
Model 1: Leverandørkontrollerede nøgler
I en traditionel cloudmodel kan leverandøren stå for hele nøglehåndteringen.
Det kan gøre løsningen enkel at administrere. Virksomheden behøver ikke nødvendigvis selv håndtere nøglelivscyklus, rotation eller den underliggende infrastruktur.
Men det betyder samtidig, at en vigtig del af sikkerhedsmodellen ligger hos leverandøren.
Virksomheden bør derfor forstå:
- Hvor nøglerne opbevares
- Hvem der kan administrere dem
- Hvordan adgang til nøglerne kontrolleres
- Hvordan nøgler roteres
- Hvad der sker, hvis en bruger eller administrator mister adgang
- Hvordan nøgleadgang bliver logget
Det handler ikke om, at én model altid er rigtig eller forkert. Det handler om at forstå, hvor kontrollen faktisk ligger.
Model 2: Kundekontrollerede nøgler
En anden tilgang giver kunden større kontrol over krypteringsnøglerne.
Her kan virksomheden eksempelvis have større indflydelse på oprettelse, opbevaring, rotation og adgang til nøglerne.
Det kan være relevant for organisationer med særlige krav til datasikkerhed, compliance eller intern kontrol.
Men mere kontrol betyder også mere ansvar.
Hvis kunden selv kontrollerer kritiske nøgler, skal organisationen samtidig have processer for sikker opbevaring, adgangsstyring, rotation, backup og håndtering af nøglekompromittering.
En stærk sikkerhedsarkitektur handler derfor ikke nødvendigvis om at flytte alt ansvar til kunden. Det handler om at placere kontrollen på en måde, der passer til virksomhedens risikoprofil og krav.
Model 3: Separat nøgleinfrastruktur
En tredje tilgang er at adskille krypteringsnøgler fra den primære datainfrastruktur.
Tanken er enkel:
Hvis data og nøgler ikke befinder sig i samme sikkerhedsdomæne, bliver det sværere at kompromittere begge dele gennem den samme adgangsvej.
Det kan eksempelvis betyde, at en applikation kan håndtere krypterede data uden nødvendigvis at have permanent adgang til de nøgler, der kan dekryptere dem.
Denne form for separation kan være en vigtig del af en såkaldt defense-in-depth-strategi, hvor sikkerheden ikke afhænger af én enkelt kontrol.
Model 4: Adgang baseret på modtagerverifikation
Der findes også en anden vigtig dimension.
Selv hvis en besked er korrekt krypteret, skal systemet stadig kunne afgøre, hvem der skal have adgang til den.
Her bliver identitet og modtagerverifikation en del af sikkerhedsmodellen.
Det ændrer perspektivet fra:
“Vi krypterer e-mailen.”
til:
“Vi krypterer e-mailen og kontrollerer, hvem der får adgang til indholdet.”
Det er en væsentlig forskel.
Kryptering beskytter data. Identitetskontrol og adgangskontrol hjælper med at sikre, at beskyttelsen ikke gives til den forkerte modtager.
Hvad betyder det for virksomhedens sikkerhedsarkitektur?
Når virksomheder evaluerer sikker e-mail, bør de derfor se længere end på ord som “krypteret”, “sikkert” og “GDPR”.
De tekniske spørgsmål er mere interessante.
Hvor genereres nøglerne?
Hvor opbevares de?
Hvem kan få adgang til dem?
Hvordan verificeres modtagerens identitet?
Hvordan håndteres nøgleadgang?
Hvordan dokumenteres sikkerhedshændelser?
Og hvad sker der, hvis en nøgle eller en konto bliver kompromitteret?
Det er disse spørgsmål, der hjælper med at afsløre, hvordan en sikkerhedsløsning faktisk er bygget.
Permido: Sikkerhed handler om arkitekturen
Hos Permido er sikker e-mail ikke tænkt som et spørgsmål om blot at tilføje kryptering til en almindelig e-mail.
Permido anvender en sikkerhedsarkitektur, hvor kryptering, identitet, adgang og dokumentation spiller sammen.
Platformen er bygget til automatisk at beskytte følsom kommunikation, uden at medarbejderen nødvendigvis skal vælge eller aktivere kryptering manuelt. Permido beskriver blandt andet zero-touch-kryptering, hvor beskyttelsen håndteres automatisk som en del af kommunikationen.
Det betyder, at sikkerheden flyttes tættere på selve systemet og arbejdsgangen.
Samtidig giver Permidos dashboard virksomheden mulighed for at følge relevant information om beskeder, levering, kryptering og hændelser. Det gør det muligt at kombinere teknisk beskyttelse med dokumentation og kontrol.
Det vigtigste spørgsmål er ikke kun, om data er krypteret
Når en virksomhed vurderer en sikker e-mail-løsning, er “Bruger I kryptering?” derfor et ret begrænset spørgsmål.
Et bedre spørgsmål er:
“Hvordan fungerer jeres nøgle- og adgangsarkitektur?”
For kryptering er kun én del af sikkerheden.
Der findes forskellige måder at håndtere krypteringsnøgler på, og hver model placerer kontrol og ansvar forskellige steder. Derfor bør virksomheder forstå den arkitektur, der ligger bag sikkerhedsløftet.
For i sidste ende handler datasikkerhed ikke kun om, hvorvidt informationen er krypteret.
Det handler også om, hvem der har kontrol over beskyttelsen.
Hvem kontrollerer dine krypteringsnøgler?
Læs mere om Permidos sikkerhedsarkitektur på www.permido.dk.
Referencer
