Personuppgifter i molnet: så granskar du leverantörens dataskydd

Varför du behöver granska molnleverantören

I en molntjänst styr leverantören den IT-utrustning som hanterar och lagrar din information. Det innebär att leverantören – med personal och eventuella underleverantörer – kan ta del av uppgifterna, och att informationen kan behandlas i länder utanför EU med andra lagar och sämre skydd för integriteten. Granskningen bör därför utgå från vilka uppgifter som alls får ligga i tjänsten.

Skyddsnivån knyter an till EU/EES, inte bara EU: dataskyddsförordningen gäller i hela EES, som omfattar EU samt Island, Liechtenstein och Norge, och överföring av personuppgifter utanför EU/EES kan undergräva den höga skyddsnivån. Moderna molntjänster är dessutom gränsöverskridande – en verksamhet i ett land kan enkelt använda en tjänst som levereras från ett annat – vilket gör platsen för behandlingen till en av de första frågorna att ställa.

Lägg till leverantörens egen livslängd i riskbilden. Molntjänstleverantören kan lägga ner sin verksamhet eller bli uppköpt av ett annat företag, och din information kan då förstöras eller bli oåtkomlig för dig under kort eller lång tid. Att lagra information i en molntjänst är inte samma sak som att den är säkerhetskopierad.

Läs personuppgiftspolicyn före första uppladdningen

För att få använda en molntjänst skapar du vanligtvis ett konto och godkänner leverantörens personuppgiftspolicy. Den beskriver vad leverantören gör med din information – till exempel att viss information används för att utveckla tjänsten. Läs igenom policyn innan du skickar din information till leverantören.

Jämför policyns ändamål med vad du själv ska använda tjänsten till. Definitionen av personuppgifter är bred: varje upplysning som direkt eller indirekt avser en identifierad eller identifierbar levande person räknas, enligt artikel 4 i GDPR. Därför kan även kontouppgifter, supportärenden och metadata omfattas, inte bara filerna du laddar upp.

Kontrollera om leverantören anger sig som personuppgiftsansvarig eller personuppgiftsbiträde för de uppgifter du lägger in, vilka kategorier av uppgifter som samlas in utöver innehållet, och hur ändringar av villkoren aviseras. Om du inte får ett begripligt svar på de punkterna är det ett skäl att avstå från tjänsten för känsliga uppgifter.

Kartlägg var uppgifterna behandlas och vem som når dem

Be om en skriftlig lista över de länder och regioner där data lagras och behandlas, inklusive redundans- och backupkopior, och om leverantören förbehåller sig rätten att flytta eller replikera data mellan regioner. Eftersom informationen kan behandlas i länder utanför EU/EES med andra lagar och sämre integritetsskydd behöver du veta var behandlingen sker, inte bara var du själv sitter.

Begär en aktuell förteckning över underleverantörer med uppgift om vad varje underleverantör gör och i vilket land den verkar, samt rutinen för att meddela dig innan en ny underleverantör läggs till. Sedan EU-domstolen ogiltigförklarade Privacy Shield är det inte längre tillåtet att enbart hänvisa till det avtalet för att visa EU-kompatibilitet; bedömningen av om tillräckligt skydd finns ligger i stället hos det enskilda företaget, och bevisbördan ligger på det.

Kartlägg samtidigt åtkomstvägarna: kan leverantörens drift- eller supportpersonal läsa innehållet i klartext, sker det i så fall rutinmässigt eller bara vid ett supportärende, och loggas den åtkomsten? Svaret avgör om uppgifterna i praktiken är läsbara för någon annan än dig, oavsett vad krypteringsavsnittet i marknadsföringen säger.

Dela upp skyddet mellan dig och leverantören

Ansvaret för skyddet delas mellan dig och molntjänstleverantören, och uppdelningen ser olika ut beroende på om du kör IaaS, PaaS eller SaaS. Uppdelningen minskar ju högre upp i stacken du rör dig, men den försvinner aldrig helt – inte ens i en SaaS-lösning.

Leverantörens egna certifieringar täcker bara en del av det delade ansvaret; resten är fortfarande din skyldighet. Den rekommenderade åtgärden är att koppla varje krav till vem – du eller leverantören – som faktiskt kontrollerar det, innan du utgår från att 'molnet är kompatibelt' täcker din verksamhet.

Gör det som en tabell: lista kontrollerna (kryptering, nyckelhantering, identitets- och åtkomsthantering, loggning, incidenthantering, säkerhetskopiering, radering) och fyll i för varje tjänst vem som ansvarar. I en IaaS-lösning hamnar exempelvis operativsystem, patchning och åtkomstkonfiguration typiskt hos dig medan leverantören ansvarar för den underliggande infrastrukturen; i en SaaS-lösning sköter leverantören mer av driften, men du behåller ansvaret för vilka uppgifter du lägger in och vilka användare du ger åtkomst.

Kontrollera kryptering och vem som har nycklarna

Kontrollera först att förbindelsen till tjänsten är krypterad. Krypterade förbindelser markeras med https, där s-et står för secure, och med det lilla stängda hänglåset i adressfältet; du kan klicka på hänglåset för mer information om säkerheten för just den webbplatsen.

Kryptering under överföring säger inget om kryptering i vila – långt ifrån alla data krypteras i vila. Fråga därför separat om data krypteras i vila och under överföring, var kopiorna ligger, och var nycklarna förvaras.

Den avgörande frågan är vem som innehar nycklarna. Om du innehar krypteringsnyckeln hos molnleverantören (native cloud custody), hos dig men hanterad via leverantörens tjänst (BYOK) eller hos dig och utanför leverantörens kontroll (HYOK) påverkar direkt vem som tekniskt sett kan komma åt reglerade uppgifter, och frågan ställs i allt större utsträckning både av PCI DSS-bedömare och av GDPR-tillsynsmyndigheter. Räkna samtidigt med att bevisbördan hamnar hos dig: det är den enskilda organisationen som måste kunna visa att ingen extern organisation har kunnat ta del av uppgifterna, vilket är svårt att garantera enbart med hänvisning till att data är krypterad.

Granska åtkomst, autentisering och loggning

Fråga vilka som kan få administrativ åtkomst till din miljö och hur den åtkomsten styrks. Krav på stark autentisering för administrativa konton, separata konton för drift och support samt minsta möjliga behörighet är grunden; svenska anvisningar om stark autentisering, till exempel Ineras, kan användas i kravställningen.

Gå igenom rotationen av nycklar och autentiseringsuppgifter: hur ofta roteras krypteringsnycklar, klienthemligheter och API-token, vem kan återskapa dem, och vad händer med dem när en medarbetare med åtkomst slutar? Om ni använder mer än ett moln bör nyckelkontroller, IAM, rotation och loggning standardiseras centralt en gång, i stället för att stämmas av per plattform i efterhand.

Loggning måste vara aktiverad och centralt granskad, inte bara tekniskt tillgänglig från leverantören. Både GDPR:s 72-timmars anmälningsklocka för intrång och kraven på att spåra och övervaka åtkomst hänger på att loggar faktiskt samlas in och att någon läser dem. Bestäm därför vilka händelser som ska loggas, hur länge loggarna sparas, var de lagras och vem som får åtkomst – inklusive om du själv får ut leverantörens åtkomstloggar.

Fråga vad som händer vid intrång och avveckling

Ta reda på leverantörens supportvägar innan något går fel: information om hur du får hjälp, kontaktuppgifter och vilka supportfunktioner som finns. Kontrollera samtidigt vilka uppgifter supporten får se när du skickar in ett ärende, eftersom ärenden ofta innehåller skärmdumpar eller filer med personuppgifter.

Fråga hur incidenter hanteras: inom vilken tid du underrättas, vad rapporten ska innehålla och om du får tillgång till loggarna som beskriver händelsen. Anmälningsskyldigheten enligt GDPR utgår från en 72-timmarsklocka för intrång, och den är beroende av loggning som är aktiverad och centralt granskad – inte bara av att leverantören kan producera loggar på begäran.

Avveckling är en egen risk att avtala om. Leverantören kan lägga ner sin verksamhet eller bli uppköpt av ett annat företag, och din information kan då förstöras eller bli oåtkomlig för dig under kort eller lång tid. Bestäm därför i avtalet att du vid avslut får ut samtliga uppgifter i ett användbart, maskinläsbart format inom en angiven tid, samt att kopior hos leverantören och dess underleverantörer raderas och att raderingen bekräftas skriftligt.

Ställ kraven redan i upphandlingen

I offentlig upphandling ska dataskyddskraven ligga i förfrågningsunderlaget, inte läggas till i efterhand. Checklistan för offentlig upphandling och GDPR är tydlig på den punkten: ställ krav på dataskydd som standard och inbyggt dataskydd, och se till att GDPR-principerna finns med i förfrågningsunderlaget.

Börja med informationsklassificeringen – bestäm vilken känslighet uppgifterna har innan kraven formuleras. MSB har tagit fram rekommendationer för informationsklassning, riktlinjer för säkerhet i molntjänster och råd vid upphandling av informationssäkerhet som kan användas som utgångspunkt.

Krav som hör hemma i underlaget: i vilka länder uppgifterna får behandlas och att överföring utanför EU/EES inte sker utan rättslig grund, förteckning över underleverantörer med meddelanderutin vid ändringar, kryptering i vila och under överföring samt var nycklarna hanteras, stark autentisering för administrativ åtkomst, loggning som är aktiverad och centralt granskad, incidentrapportering inom avtalad tid, rätt till revision samt rutin för utlämning och radering vid avtalets slut. Följ upp i leverantörens svar vem – du eller leverantören – som faktiskt kontrollerar varje krav.

Grundläggande säkerhetskrav för molntjänster i Sverige

Frågor att ta med till leverantören

Var lagras och behandlas uppgifterna – i vilka länder och regioner, och omfattar det även backuper och repliker?

Vilka underleverantörer används, vad gör de, i vilka länder verkar de, och hur meddelas ändringar i förteckningen?

Kan leverantörens personal eller support läsa innehållet i klartext, och loggas i så fall den åtkomsten?

Krypteras data i vila och under överföring, och vem innehar nycklarna – leverantören, BYOK eller HYOK?

Vilka kan få administrativ åtkomst till vår miljö, och krävs stark autentisering för de kontona?

Hur ofta roteras nycklar, klienthemligheter och API-token, och vad händer med dem när en medarbetare med åtkomst slutar?

Är loggning aktiverad för administrativ åtkomst och dataåtkomst, var sparas loggarna, hur länge och vem granskar dem?

Får vi ut leverantörens åtkomstloggar vid en incident?

Inom vilken tid underrättas vi vid intrång, och vad innehåller rapporten?

Får vi ut samtliga uppgifter i ett maskinläsbart format vid avtalets slut, och inom vilken tid?

Bekräftas radering skriftligt, och gäller det även backuper och underleverantörer?

Vad händer med uppgifterna om leverantören läggs ned eller köps upp?