Standarder för efterlevnad av molnsäkerhet – PCI DSS och GDPR

Standarder för efterlevnad av molnsäkerhet, som PCI DSS och GDPR, anger de säkerhets- och integritetsskyldigheter som gäller när du lagrar, bearbetar eller överför reglerad data på AWS, Azure eller GCP. De är viktiga eftersom en molnleverantörs egna certifieringar bara täcker en del av det delade ansvaret, resten är fortfarande din skyldighet, och att göra fel medför rejäla böter. Den rekommenderade åtgärden: koppla varje krav till vem, du eller CSP:n, som faktiskt kontrollerar det, innan du antar att "molnet är kompatibelt" täcker dig.

Publicerad: november 2020. Uppdaterad: augusti 2026. Granskad av Encryption Consultings Compliance Advisory Team.

Det här inlägget behandlar den allmänna bilden av molnefterlevnad för PCI DSS och GDPR. Om din specifika fråga är var PKI-nycklar, granskningsloggar och administrativ åtkomst fysiskt finns för datasuveränitetsändamål, går vår guide om datasuveränitet och regional efterlevnad djupare in på den kartläggningen över GDPR, NIS2, DORA och FedRAMP.

Vad är den delade ansvarsmodellen i molnet?

Modellen för delat ansvar är fördelningen av säkerhets- och efterlevnadsskyldigheter mellan dig och din molntjänstleverantör (CSP) , och var den gränsen går beror på vilken tjänstemodell du använder. En CSP ansvarar alltid för den fysiska säkerheten för sina datacenter och för att säkra infrastrukturen under den tjänst du konsumerar. Du ansvarar alltid för hur du konfigurerar och använder den tjänsten, dina data, dina åtkomstkontroller och dina egna efterlevnadsskyldigheter som läggs ovanpå. Att gå från infrastruktur som en tjänst (IaaS) till plattform som en tjänst (PaaS) till programvara som en tjänst (SaaS) flyttar mer av den tekniska bördan till CSP:n, men det flyttar aldrig själva efterlevnadsansvaret. Du måste fortfarande verifiera att CSP:n faktiskt uppfyller den standard du behöver och dokumentera att du gjorde det.

Hur tillämpas PCI DSS på molnmiljöer?

PCI DSS (Payment Card Industry Data Security Standard) gäller för din molnmiljö i det ögonblick kortinnehavarens data lagras, bearbetas eller överförs där, och det kräver validering av både CSP:ns infrastruktur och din egen användning av den. PCI DSS är en uppsättning säkerhetskrav, för närvarande version 4.0.1, skapade av betalkortsföretagen 2004 och underhålls av PCI Security Standards Council, och det gäller för alla företag som hanterar betalkortsdata oavsett storlek.

Ansvaret för varje krav är fortfarande uppdelat efter tjänstemodell. Tabellen nedan visar hur den uppdelningen vanligtvis sker, även om den exakta fördelningen alltid definieras i ditt kontrakt och intyg om överensstämmelse med CSP:n, och inte enbart antas utifrån tjänstemodellen.

PCI DSS-krav				Ansvarsfördelning för hantering av kontroller
				IaaS	PaaS	SaaS
Installera och underhåll nätverkssäkerhetskontroller för att skydda kortinnehavarens data				Klient och CSP	Klient och CSP	CSP
Tillämpa säkra konfigurationer på alla systemkomponenter, inga leverantörslevererade standardinställningar				Klient och CSP	Klient och CSP	CSP
Skydda lagrade kontodata				Klient och CSP	Klient och CSP	CSP
Skydda kortinnehavarens data med stark kryptografi under överföring över öppna, offentliga nätverk				Klient	Klient och CSP	CSP
Skydda alla system och nätverk från skadlig programvara				Klient	Klient och CSP	CSP
Utveckla och underhålla säkra system och programvara				Klient och CSP	Klient och CSP	Klient och CSP
Begränsa åtkomst till systemkomponenter och kortinnehavardata efter företagsbehov				Klient och CSP	Klient och CSP	Klient och CSP
Identifiera användare och autentisera åtkomst till systemkomponenter				Klient och CSP	Klient och CSP	Klient och CSP
Begränsa fysisk åtkomst till kortinnehavarens data				CSP	CSP	CSP
Logga och övervaka all åtkomst till systemkomponenter och kortinnehavardata				Klient och CSP	Klient och CSP	CSP
Testa regelbundet säkerheten i system och nätverk				Klient och CSP	Klient och CSP	CSP
Stöd informationssäkerhet med organisationens policyer och program				Klient och CSP	Klient och CSP	Klient och CSP

PCI DSS v4.0.1 har lagt till två krav som är värda att flagga specifikt för molndistributioner. Kryptering på disknivå kvalificerar inte längre som "kryptering i vila" i sig själv, förutom på flyttbara medier, så kryptering på full disk- eller volymnivå för kortinnehavardata som lagras i molnet behöver en kompenserande kontroll, såsom kryptering på fil- eller kolumnnivå. Och organisationer måste nu formellt granska de kryptografiska sviter och protokoll som faktiskt används minst en gång per år, inklusive aktiv övervakning av algoritmer eller protokoll som närmar sig utfasning, en granskning som är lätt att hoppa över i en molnmiljö där TLS-konfigurationen delvis hanteras av CSP:n.

Hur tillämpas GDPR på molnmiljöer?

GDPR (Allmänna dataskyddsförordningen) gäller alla organisationer, var som helst i världen, som samlar in eller behandlar personuppgifter för personer som befinner sig i EU, och den håller dig ansvarig för hur din CSP hanterar dessa uppgifter för din räkning, inte bara hur du själv hanterar dem. Företag utanför EU som behandlar uppgifter för EU-invånare måste utse en EU-representant och förbli ansvariga för böter och sanktioner oavsett var företaget självt är baserat.

GDPR:s kärnkrav, av vilka flera har direkta tekniska konsekvenser i en molnmiljö, är:

1. Laglig, rättvis och transparent behandling.
2. Syfte, data- och lagringsbegränsning. Samla endast in det som är nödvändigt och kassera personuppgifter när behandlingen är slutförd.
3. Den registrerades rättigheter. En person kan fråga vilka uppgifter du har om dem och hur de används.
4. Samtycke. Du måste inhämta samtycke för behandling utöver berättigade ändamål, och personen kan när som helst återkalla det.
5. Anmälan om personuppgiftsincident. Tillsynsmyndigheter måste informeras inom 72 timmar efter att din organisation blivit medveten om ett intrång, vilket helt och hållet är beroende av loggning och övervakning som faktiskt upptäcker intrånget i tid.
6. Sekretess genom design. Bygg in dataskydd i nya system och processer från början, inte som en eftertanke.
7. Konsekvensbedömningar för dataskydd. Genomför en sådan när du startar ett nytt projekt, en ny förändring eller en ny produkt som involverar betydande behandling av personuppgifter.
8. Dataöverföringar. Du förblir ansvarig för att GDPR-efterlevnaden även när en tredje part (inklusive din CSP) behandlar uppgifterna för din räkning.
9. Dataskyddsombud. Krävs när din organisation utför betydande behandling av personuppgifter.
10. Medvetenhet och utbildning. Anställda behöver förstå de GDPR-krav som är relevanta för deras roll.

För att faktiskt uppfylla dessa krav i en molnmiljö, vidta dessa ytterligare steg: ta reda på exakt var din CSP lagrar och bearbetar informationen; bekräfta vilka CSP-tjänster och konfigurationer som uppfyller din säkerhetsstandard och konfigurera dem därefter, eftersom GDPR-efterlevnad inte är automatisk bara för att CSP:n i sig är certifierad; upprätta ett databehandlingsavtal med varje CSP och molnapplikation du använder; samla in och bearbeta endast det du behöver; verifiera att databehandlingsavtalet faktiskt följs, inte bara undertecknas; och bekräfta att du kan radera en persons data på begäran från varje datakälla inom CSP:n, inte bara din primära databas.

Hur påverkar kontroll av krypteringsnycklar PCI DSS och GDPR-efterlevnad?

Var din krypteringsnyckel finns, inte bara om data är krypterade, är det som avgör vem som tekniskt sett kan komma åt reglerad data, och det är precis vad både PCI DSS-bedömare och GDPR-tillsynsmyndigheter i allt högre grad frågar om.

Modell för nyckelkontroll	Vad det betyder	Relevans för efterlevnad
Inbyggt (molnhanterat)	Nyckel genererad och lagrad i CSP:ns egen nyckelhanteringstjänst (AWS KMS, Azure Key Vault, GCP Cloud KMS)	Uppfyller PCI DSS krav på att skydda lagrade kontodata och dokumentera nyckelhanteringsprocedurer; CSP:n har tekniskt sett åtkomst till nyckelmaterialet, vilket vissa GDPR-databehandlingsavtal kräver att du lämnar ut till registrerade.
BYOK (ta med egen nyckel)	Du genererar nyckelmaterialet och importerar det till CSP:ns HSM	Visar viktig proveniens för revisionsändamål; lämnar fortfarande en användbar kopia inuti CSP:n efter import, så att CSP:n inte tas bort från ditt dataflödesdiagram
HYOK (håll din egen nyckel)	Nyckelmaterial lämnar aldrig din egen eller en extern nyckelhanterare från tredje part; CSP:n anropar den för varje operation	Det starkaste tekniska svaret på frågan "kan CSP:n läsa våra data", relevant där ett GDPR-avtal eller ett specifikt PCI DSS-omfattningsbeslut kräver det, på bekostnad av att göra din externa nyckelhanterares tillgänglighet till ett beroende för varje transaktion.

De flesta organisationer behöver inte HYOK för att klara en PCI DSS-bedömning eller uppfylla GDPR. Inbyggd molnnyckelhantering med dokumenterade procedurer täcker kravet för den stora majoriteten av användningsfallen. HYOK blir relevant specifikt när ett kontrakt, en tillsynsmyndighet eller ett databehandlingsavtal kräver bevis på att CSP:n inte kan komma åt informationen alls, inte som standard. Vår jämförelse mellan AWS KMS och Azure Key Vault och GCP KMS täcker hur varje leverantör faktiskt implementerar BYOK och HYOK om du behöver den detaljnivån.

Hur stöder IAM PCI DSS och GDPR-efterlevnad?

Båda standarderna kräver begränsning av åtkomst utifrån företags behov, PCI DSS nämner detta uttryckligen som en kontroll, och GDPR:s artikel 32 kräver "lämpliga tekniska och organisatoriska åtgärder" som tillsynsmyndigheter tolkar som att de inkluderar åtkomstkontroll.

1. Inventera varje identitet, människa och tjänst, med tillgång till reglerad data eller nycklar som skyddar den.
2. Tilldela ett unikt ID till varje person med systemåtkomst, aldrig en delad autentiseringsuppgift, vilket PCI DSS uttryckligen kräver.
3. Omfånga varje behörighet till det specifika system, den databas eller den nyckel som behövs, inte konto- eller projektomfattande åtkomst.
4. Separera de roller som administrerar krypteringsnycklar från de roller som använder dem för att kryptera eller dekryptera data.
5. Granska åtkomst i en fast takt, och omedelbart vid rollbyte eller uppsägning, eftersom både PCI DSS-bedömare och GDPR-revisioner behandlar inaktuell åtkomst som ett fynd.

Vad kräver PCI DSS och GDPR för nyckel- och autentiseringsrotation?

PCI DSS kräver att du definierar en kryptoperiod, den tid en nyckel kan användas, baserat på algoritmen, nyckellängden och känsligheten för de data den skyddar, och att du ersätter nycklar innan den perioden löper ut eller omedelbart om en nyckel misstänks vara komprometterad. GDPR anger inget specifikt rotationsintervall, men artikel 32:s krav på "state-of-the-art" säkerhetsåtgärder innebär att en nyckelrotationspolicy som inte har granskats på flera år i sig är en svag punkt som tillsynsmyndigheter kan peka på. I praktiken uppfyller du båda standarderna samtidigt genom att definiera en dokumenterad rotationspolicy per nyckel och faktiskt tillämpa den via ditt moln-KMS inbyggda rotationsfunktion snarare än en manuell kalenderpåminnelse.

Vilken loggning kräver PCI DSS och GDPR i molnet?

PCI DSS kräver att du loggar och övervakar all åtkomst till systemkomponenter och kortinnehavardata, och GDPR:s krav på 72-timmars anmälan av intrång är ogenomförbart i praktiken utan loggar som är tillräckligt detaljerade för att fastställa när ett intrång faktiskt startade.

• PCI DSS: Loggar måste registrera individuell användaråtkomst till kortinnehavarens data, alla åtgärder av privilegierade konton och all användning av identifierings- och autentiseringsmekanismer. Loggarna måste lagras och granskas enligt ett schema som din kvalitetssäkringsmakare kommer att be om att se bevis på.
• BRP: Artikel 30 kräver register över behandlingsaktivitet, och artikel 33:s 72-timmarsklocka börjar gälla från det att du blir medveten om ett intrång, vilket innebär att din loggning måste övervakas aktivt, inte bara lagras, för att starta klockan i tid snarare än veckor senare.
• I praktiken på de stora molnen: AWS CloudTrail, Azure Monitor diagnostikloggar och GCP Cloud Audit Logs tillhandahåller alla råmaterialet, men ingen av de tre möjliggör omfattande loggning som standard, utan var och en kräver ett uttryckligt konfigurationsbeslut per tjänst.

Vad kostar det att underhålla molnefterlevnad?

Kostnaden för molnefterlevnad är främst en personal- och processkostnad, inte en licenskostnad, årliga PCI DSS-bedömningar (självbedömningsformulär eller engagemang av en kvalificerad säkerhetsbedömare beroende på transaktionsvolym), det löpande arbetet med att upprätthålla en dokumenterad kryptografisk arkitektur och nyckelhanteringsprocedurer, samt den tekniska tiden som krävs för att konfigurera och övervaka loggning korrekt över varje molntjänst som omfattas. De molnbaserade tjänsterna i sig, KMS-nyckelavgifter, HSM-instanskostnader och logglagring är vanligtvis en liten del av den totala summan jämfört med bedömnings- och dokumentationsarbetet, vilket är en anledning till att organisationer underbudgeterar för efterlevnadsunderhåll efter den första lyckade granskningen.

Hur ser en arkitektur för efterlevnad av flera moln ut?

Att köra reglerade arbetsbelastningar över mer än ett moln multiplicerar kartläggningen av delat ansvar med hur många moln du än använder, såvida du inte standardiserar nyckelkontroll, IAM, rotation och loggningspolicy en gång, centralt, och tillämpar den konsekvent snarare än att låta varje molnteam tolka PCI DSS och GDPR oberoende av varandra.

För referensarkitekturen bakom den typen av centraliserad metod, se vår Multi-Cloud PKIaaS Architecture Guide och Education Centers översikt över nyckelhantering i flera moln.

Vilka är begränsningarna med att förlita sig på CSP-efterlevnadscertifieringar?

• En CSP:s certifiering täcker dess egen infrastruktur, inte din konfiguration av den. Ett AWS PCI DSS-intyg om efterlevnad gör inte din S3-bucketpolicy, IAM-behörigheter eller applikationskod kompatibel.
• SaaS begränsar men eliminerar inte dina skyldigheter. Även på SaaS är du fortfarande ansvarig för åtkomstkontroll av konton, dataklassificering och att bekräfta att leverantörens efterlevnad faktiskt täcker ditt specifika användningsfall.
• Inte alla molntjänster inom en CSP har samma certifiering. Att en CSP är PCI DSS- eller GDPR-kompatibel överlag betyder inte att varje enskild tjänst omfattas av ditt intyg om efterlevnad, du måste verifiera per tjänst.
• Efterlevnad är en tidpunktsbekräftelse, inte en kontinuerlig garanti. Konfigurationsavvikelser efter en bedömning är vanligt, och varken PCI DSS eller GDPR-efterlevnad är självunderhållande.

Beslutschecklista: Molnefterlevnad för PCI DSS och GDPR

1. Kartlägg varje PCI DSS-krav och GDPR-skyldighet utifrån om du, din CSP eller båda kontrollerar det, för er specifika tjänstemodell (IaaS, PaaS eller SaaS), anta inte enbart utifrån modellen.
2. Bestäm din nyckelkontrollmodell (inbyggd, BYOK eller HYOK) baserat på ett faktiskt kontraktuellt eller regulatoriskt krav, inte som standard.
3. Dokumentera er kryptografiska arkitektur och nyckelhanteringsprocedurer nu, PCI DSS v4.0.1 kräver det för tjänsteleverantörer och förväntas även som bevis för handlare.
4. Aktivera och centralt dirigera loggning för varje molntjänst inom ramen innan en bedömare eller ett intrång tvingar fram frågan.
5. Om ni arbetar i mer än ett moln, standardisera ovanstående en gång, centralt, snarare än att låta efterlevnadsstatusen skilja sig åt mellan molnteamen.

Vad skulle krypteringskonsulter rekommendera?

De organisationer som kämpar med molnefterlevnad är sällan de som saknar en specifik kontroll, de är de som aldrig kartlagt vem som äger vilken kontroll från första början, och upptäcker bristen under en utvärdering istället för före en sådan. Vi rekommenderar att man behandlar kartläggningen av delat ansvar som ett levande dokument, som granskas varje gång man inför en ny molntjänst, inte en engångsövning som görs vid den första molnmigreringen. Där nyckelhantering och dess dokumentation är bristen, jämför vår Cloud Data Protection-utvärdering er nuvarande ställning mot PCI DSS, GDPR och relaterade ramverk i AWS, Azure och GCP, och vårt HSM-as-a-Service- erbjudande ger er FIPS-validerad, centralt styrd nyckelförvaring som omfattar alla tre.

Vanliga frågor om partihandel med mat och dryck

Om min CSP är PCI DSS-certifierad, uppfyller jag då automatiskt kraven?

Nej. En CSP:s intyg om efterlevnad omfattar dess egen infrastruktur och de tjänster den driver direkt. Du ansvarar fortfarande för hur du konfigurerar dessa tjänster, dina åtkomstkontroller, din applikationskod och alla delar av kravmatrisen som faller på klienten enligt din specifika tjänstemodell.

Kräver GDPR att jag måste förvara EU-medborgares uppgifter fysiskt inom EU?

GDPR tillåter inte automatiskt överföringar utanför EU enligt specifika mekanismer (tillräcklighetsbeslut, standardavtalsklausuler, bindande företagsregler), men du är fortfarande ansvarig för att säkerställa att dessa skydd faktiskt gäller, och vissa sektorspecifika regler eller kundavtal kan kräva datalagring i EU oavsett vad GDPR i sig tillåter.

Måste jag använda HYOK för att vara PCI DSS- eller GDPR-kompatibel?

Nästan aldrig som standardkrav. Inbyggd molnnyckelhantering med dokumenterade procedurer uppfyller båda standarderna för den överväldigande majoriteten av användningsfallen. HYOK blir relevant när ett specifikt kontrakt, en tillsynsmyndighet eller ett databehandlingsavtal kräver bevis på att CSP:n inte alls kan komma åt dina data.

Vad har ändrats i PCI DSS v4.0.1 som specifikt påverkar molndistributioner?

Två förändringar sticker ut för molnmiljöer: kryptering på disknivå ensamt kvalificerar inte längre som kryptering i vila förutom på flyttbara medier, och organisationer måste nu formellt granska sina kryptografiska sviter och protokoll minst en gång per år, inklusive övervakning av algoritmer som närmar sig utfasning.

Hur snabbt behöver jag egentligen upptäcka ett intrång för att uppfylla GDPR:s 72-timmarskrav?

72-timmarsklockan startar när din organisation blir medveten om intrånget, inte när det inträffade, utan en loggningsuppsättning som bara avslöjar incidenter dagar eller veckor senare omintetgör i praktiken kravet. Centralt övervakad, aktivt varnad loggning är det som gör 72-timmarsfönstret möjligt i praktiken.

Har du en specifik fråga om molnefterlevnad enligt PCI DSS eller GDPR? Kontakta vårt team på [email protected ]