Kryptering av personuppgifter är användbar först när ni vet vilket hot den ska stoppa och vem som kan komma åt nycklarna. Att en molntjänst uppges vara krypterad säger inte om leverantörens support kan läsa innehållet, om exporter skyddas eller om en stulen dator var upplåst. Gör därför en bedömning per dataflöde och lagringsplats.
Målet är ett beslutsunderlag som visar vilka uppgifter som skyddas, i vilka situationer skyddet fungerar och hur ni kontrollerar det. Här får ni en arbetsgång och ett ifyllt exempel för ett fiktivt tjänsteföretag. Exemplet är en praktisk utformning, inte en föreskriven teknisk standard för alla svenska verksamheter.
Börja med risk och tillämpningsområde
Artikel 32 i GDPR nämner kryptering bland de åtgärder som kan vara lämpliga för en säkerhetsnivå som motsvarar risken. Bedöm bland annat uppgifternas karaktär, behandlingens sammanhang, möjliga konsekvenser för människor och hur sannolik en incident är. GDPR föreskriver inte en enda algoritm eller nyckellängd för varje situation.
IMY:s vägledning om kryptering beskriver behovsanalys, dokumentation, användarinstruktioner och skydd av nycklar. Den framhåller också att känsliga uppgifter behöver skyddas hela vägen vid överföring. För er analys innebär det att ni måste följa informationen genom mellansteg, inte bara kontrollera den första anslutningen.
Använd systemkartan för att hitta databaser, filytor, säkerhetskopior, mobiler och integrationer. Lägg till manuella exporter och supportärenden. De är lätta att missa eftersom de kanske inte syns i arkitekturdiagrammet. En fullständigt skyddad huvuddatabas hjälper föga om samma uppgifter skickas som en oskyddad bilaga.
Skilj överföring från lagring
Kryptering under överföring skyddar kommunikationen mellan vissa tekniska ändpunkter. En webbläsare kan kommunicera säkert med en webbserver samtidigt som servern skickar uppgifter vidare över en oskyddad intern anslutning. Rita därför ut var varje krypterad förbindelse börjar och slutar. Kontrollera även certifikatvalidering; en krypterad anslutning till fel mottagare löser inte problemet.
Kryptering vid lagring kan skydda exempelvis en avstängd dator, en databasfil eller en säkerhetskopia. Skyddet beror på hur dekryptering sker. En inloggad applikation kan fortfarande lämna ut personuppgifter till en angripare som övertagit ett behörigt konto. Databaskryptering ersätter därför inte åtkomstkontroll eller säkerhetsloggning.
Totalsträckskryptering innebär att innehållet skyddas mellan de avsedda slutpunkterna utan att mellanliggande tjänster får tillgång till klartext. Kontrollera exakt vilka funktioner som omfattas. Säkerhetskopiering, sökning, anslutna klienter och export kan ha andra egenskaper än själva meddelandeöverföringen. Även när innehållet skyddas kan metadata avslöja vem som kommunicerar med vem och när.
Gör en skyddsmatris som går att kontrollera
Beskriv både önskat skydd och ett konkret kontrollmoment. Följande exempel visar hur ett företag kan dokumentera tre olika behov utan att kalla alla lösningar ”krypterade och säkra”.
| Objekt | Risk att hantera | Beslutad lösning i exemplet | Kontroll och kvarvarande risk |
|---|---|---|---|
| Bärbara tjänstedatorer | Obehörig läser lagringen efter stöld | Fullständig diskkryptering och separat hanterad återställningsnyckel | Kontrollera täckning i enhetsregistret; upplåst dator kräver ytterligare bedömning |
| Överföring av löneunderlag | Fel mottagare eller avlyssning | Avgränsad portal med stark autentisering och krypterad överföring | Prova mottagarens behörighet och borttagning av åtkomst; mottagarens export är ett separat steg |
| Säkerhetskopior | Kopior röjs eller kan inte återställas | Krypterade kopior med begränsad åtkomst till både lagring och nycklar | Återställ ett prov med reservbehörighet; nyckelförlust kan göra kopian obrukbar |
Matrisen ska inte innehålla själva nycklarna, hemliga tokens eller lösenorden. Den ska ange var de hanteras, vem som ansvarar och vilka kontroller som har gjorts. Spara rapportdatum och identifiering av den kontrollerade miljön. En skärmbild från en testmiljö bevisar inte produktionssystemets inställningar.
Fördela ansvaret för nycklarnas livscykel
Nyckelhantering omfattar skapande, användning, lagring, byte, återställning och förstöring. Bestäm vilka roller som får utföra varje moment. Begränsa möjligheten för en och samma person att både hämta krypterade databaser och använda nycklarna utan kontroll. Utforma separationen efter hotbilden och den faktiska tjänstens möjligheter.
Koppla nyckelåtkomst till individuella tjänstekonton eller personliga administratörsidentiteter där det är lämpligt. Undvik att bygga driften på en anställds privata konto. Använd lösenords- och autentiseringspolicyn för hur dessa identiteter skyddas, men håll nyckelrutinen tydlig även när lösenord inte används.
Beskriv när nycklar ska bytas. En misstänkt kompromettering, en förändrad behörighetsmodell eller en teknisk rekommendation kan utlösa byte. Bestäm också en ordinarie översyn utifrån risk och teknik. Påstå inte att ett visst årligt byte är ett universellt GDPR-krav. Kontrollera om bytet påverkar gamla säkerhetskopior och hur data som skyddas med äldre nycklar fortfarande kan läsas när det behövs.
Pröva återställning och tillgänglighet
Ett företag kan förlora alla sina uppgifter trots fungerande säkerhetskopior om nycklarna försvinner tillsammans med produktionsmiljön. Ge därför återställningsrutinen ett eget scenario: ordinarie nyckeltjänst och administratör är otillgängliga. Kan en utsedd ersättare få rätt behörighet och återställa data inom verksamhetens behov?
Provet ska ske utan att ni skapar en oskyddad reservkopia av hemligheter. Dokumentera åtkomstbeslut, användning och efterföljande kontroll. Lägg beroendet i återställningsplanen och ange vad verksamheten gör under väntetiden i kontinuitetsplanen. Tillgänglighet och konfidentialitet behöver fungera tillsammans.
Tänk också på avvecklingen. Innan en nyckel förstörs måste ni veta vilka uppgifter som fortfarande behöver kunna återställas. Att radera en nyckel kan påverka flera datamängder samtidigt. Kontrollera kopior, repliker och eventuella skyldigheter att bevara underlag innan ni använder nyckelförstöring som del av en raderingsprocess.
Ställ rätt frågor till molnleverantören
Be leverantören förklara vem som kan dekryptera uppgifterna under normal drift, support och felsökning. ”Kundhanterad nyckel” kan innebära olika saker i olika tjänster. Fråga om tjänsten själv kan använda nyckeln, om administratörer kan exportera klartext och vilka loggar ni får tillgång till.
Om kryptering ska skydda mot åtkomst från en mottagare i ett tredjeland måste den tekniska konstruktionen fungera mot just den risken. Kryptering som mottagaren själv kan upphäva ger inte samma skydd som en konstruktion där nyckeln stannar hos en annan part. Integrera bedömningen i en överföringsanalys. Att kryptera en fil avgör inte ensamt vilket stöd som behövs för överföringen.
Begär även besked om utträde: i vilket format får ni data, vilka nycklar krävs och när tas leverantörens kopior bort? Lägg svaret i avtalsunderlaget. Ett exportformat som ingen längre kan dekryptera är ingen fungerande exitlösning.
Kontrollera anslutningen i rätt miljö
För en webbtjänst kan kontrollprotokollet ange domän, tjänsteägare, datum och vilka klienter som användes. Prova att ett ogiltigt certifikat avvisas och att personalen inte behöver klicka förbi varningar för att arbeta. Kontrollera även den automatiska integrationen; dess klient kan ha andra inställningar än webbläsaren. Dokumentera vilket felmeddelande som uppstår och vem som får larm när certifikatet snart går ut.
En godkänd kontroll av den publika webbplatsen täcker inte automatiskt administrationsgränssnitt, filöverföringar eller interna API:er. Ta med dem i samma inventering, men låt den tekniska specialisten välja den aktuella konfigurationen för respektive tjänst. Använd en separat kontroll av TLS och certifikat för dessa detaljer. På så sätt kan verksamhetens beslut om vilka flöden som ska skyddas följas upp utan att policydokumentet fylls med tekniska inställningar som snabbt kan förändras.
Bedöm kryptering konkret vid en incident
Anta att en medarbetare förlorar en tjänstedator. I första scenariot var datorn avstängd, krypteringen var aktiverad och nyckeln hade inte röjts. I det andra var datorn upplåst och hade en aktiv session till kundregistret. Samma krypteringsetikett ger inte samma riskbedömning.
Artikel 34.3 a kan innebära att information till drabbade inte krävs om lämpliga skyddsåtgärder har tillämpats på de berörda uppgifterna och gjort dem oläsbara för obehöriga. Det är inget automatiskt undantag från att bedöma anmälan enligt artikel 33. Utred även förlust av tillgång, möjlig ändring av data och vilka andra uppgifter som var åtkomliga. Dokumentera bevisen för den faktiska enhetsstatusen.
Skilj kryptering från andra tekniker
Krypterad information kan återställas med rätt nyckel. Lösenord bör normalt verifieras med en särskilt avsedd lösenordshashning, så att tjänsten inte behöver kunna visa användarens lösenord i klartext. Pseudonymisering ersätter i stället identifierare och hanterar kopplingen separat; se rutinen för kodnycklar. Ingen av etiketterna betyder automatiskt att uppgifterna är anonyma.
Avsluta granskningen med en åtgärdslista: oskyddat steg, ansvarig, vald lösning, kontroll och sista datum. Prioritera luckor där obehöriga faktiskt kan nå uppgifterna. Lägg principerna i er informationssäkerhetspolicy och kontrollera dem igen när en integration, leverantör eller klient ändras.