Skydda data i ett AKS-reglerat kluster för PCI-DSS 3.2.1 (del 4 av 9)

I den här artikeln beskrivs överväganden för ett AKS-kluster (Azure Kubernetes Service) som kör en arbetsbelastning i enlighet med Payment Card Industry Data Security Standard (PCI-DSS 3.2.1).

Den här artikeln ingår i en serie. Läs introduktionen.

Den här arkitekturen och implementeringen fokuserar på infrastruktur och inte på arbetsbelastningen. Den här artikeln innehåller allmänna överväganden och metodtips som hjälper dig att fatta designbeslut. Följ kraven i den officiella PCI-DSS 3.2.1-standarden och använd den här artikeln som ytterligare information, om tillämpligt.

Skydda korthållardata

Krav 3 – Skydda lagrade korthållardata

Ditt ansvar

Krav	Ansvar
Krav 3.1	Håll korthållardatalagring till ett minimum genom att implementera principer för kvarhållning och bortskaffande av data, procedurer och processer som innehåller minst följande för all chd-lagring (cardholder data):
Krav 3.2	Lagra inte känsliga autentiseringsdata efter auktorisering (även om de är krypterade). Om känsliga autentiseringsdata tas emot återger du alla data som inte kan återställas när auktoriseringsprocessen har slutförts.
Krav 3.3	Maskera PAN när det visas (de första sex och sista fyra siffrorna är det maximala antalet siffror som ska visas), så att endast personal med ett legitimt affärsbehov kan se hela PAN.
Krav 3.4	Gör PAN oläsligt var det än lagras (inklusive på bärbara digitala medier, säkerhetskopieringsmedia och i loggar) med någon av följande metoder:
Krav 3.5	Dokumentera och implementera procedurer för att skydda nycklar som används för att skydda lagrade korthållardata mot avslöjande och missbruk:
Krav 3.6	Dokumentera och implementera alla nyckelhanteringsprocesser och procedurer för kryptografiska nycklar som används för kryptering av korthållardata, inklusive följande:
Krav 3.7	Se till att säkerhetsprinciper och operativa procedurer för att skydda lagrade korthållardata dokumenteras, används och är kända för alla berörda parter.

Krav 4 – Kryptera överföring av korthållardata över öppna, offentliga nätverk.

Ditt ansvar

Krav	Ansvar
Krav 4.1	Använd starka kryptografi- och säkerhetsprotokoll (till exempel TLS, IPSEC, SSH osv.) för att skydda känsliga korthållardata under överföring över öppna, offentliga nätverk, inklusive följande:
Krav 4.2	Skicka aldrig oskyddade PAN:er av slutanvändarnas meddelandetekniker (till exempel e-post, snabbmeddelanden, SMS, chatt osv.).
Krav 4.3	Se till att säkerhetsprinciper och operativa procedurer för kryptering av överföring av korthållardata dokumenteras, används och är kända för alla berörda parter.

Krav 3.1

Håll korthållardatalagring till ett minimum genom att implementera principer för kvarhållning och bortskaffande av data, procedurer och processer som innehåller minst följande för all chd-lagring (cardholder data):

• Begränsa datalagringsmängden och kvarhållningstiden till den tid som krävs för juridiska krav, regelkrav och affärskrav
• Processer för säker borttagning av data när de inte längre behövs
• Specifika kvarhållningskrav för korthållardata
• En kvartalsprocess för att identifiera och på ett säkert sätt ta bort lagrade korthållardata som överskrider den definierade kvarhållningen.

Ditt ansvar

Lagra inte tillstånd i AKS-klustret. Om du väljer att lagra CHD kan du utforska alternativ för säker lagring. Alternativen omfattar Azure Storage för fillagring eller databaser som Azure SQL Database eller Azure Cosmos DB.

Följ strikt standardvägledningen om vilken typ av CHD som kan lagras. Definiera principer för datakvarhållning baserat på dina affärskrav och vilken typ av lagring som används. Några viktiga överväganden är:

• Hur och var lagras data?
• Krypteras lagrade data?
• Vad är kvarhållningsperioden?
• Vilka åtgärder tillåts under kvarhållningsperioden?
• Hur tar du bort lagrade data när kvarhållningsperioden har upphört att gälla?

Ha styrningsprinciper kring några av dessa alternativ. Inbyggda Azure-principer tillämpar dessa alternativ. Du kan till exempel begränsa volymtyperna på klusterpoddarna eller neka skrivåtgärder i rotfilsystemet.

Granska den här listan med principdefinitioner och tillämpa dem på klustret, i förekommande fall.

Du kan behöva cachelagera data tillfälligt. Vi rekommenderar att du skyddar cachelagrade data när de flyttas till en lagringslösning. Överväg att aktivera den värdbaserade krypteringsfunktionen i AKS. Detta krypterar data som lagras på virtuella noddatorer. Mer information finns i Värdbaserad kryptering på Azure Kubernetes Service (AKS). Aktivera också en inbyggd Azure-princip som kräver kryptering av tillfälliga diskar och cache för nodpooler.

När du väljer en lagringsteknik kan du utforska kvarhållningsfunktionerna. Azure Blob Storage tillhandahåller till exempel tidsbaserade kvarhållningsprinciper. Ett annat alternativ är att implementera en anpassad lösning som tar bort data enligt kvarhållningsprinciper. Ett exempel är DLM (Data Lifecycle Management), som hanterar datalivscykelaktiviteter. Lösningen har utformats med tjänster som Azure Data Factory, Microsoft Entra ID och Azure Key Vault.

Mer information finns i Hantera datalivscykeln med Hjälp av Azure Data Factory.

Krav 3.2

Lagra inte känsliga autentiseringsdata efter auktorisering (även om de är krypterade). Om känsliga autentiseringsdata tas emot återger du alla data som inte kan återställas när auktoriseringsprocessen har slutförts.

Ditt ansvar

(GÄLLER FÖR: Krav 3.2.1, Krav 3.2.2, Krav 3.2.3)

Bearbetning och skydd av data ligger utanför omfånget för den här arkitekturen. Här följer några allmänna överväganden.

Enligt standarden består känsliga autentiseringsdata av fullständiga spårningsdata, kortvalideringskod eller -värde och PIN-data. Som en del av CHD-bearbetningen kontrollerar du att autentiseringsdata inte exponeras i källor som:

• Loggar som genereras från poddarna.
• Rutiner för undantagshantering.
• Filnamn.
• Cache.

Som allmän vägledning bör handlarna inte lagra den här informationen. Om det finns ett behov dokumenterar du affärsmotiven.

Krav 3.3

Maskera PAN när det visas (de första sex och sista fyra siffrorna är det maximala antalet siffror som ska visas), så att endast personal med ett legitimt affärsbehov kan se hela PAN.

Ditt ansvar

Primärt kontonummer (PAN) anses vara känsliga data och exponering för dessa data måste förhindras. Ett sätt är att minska de siffror som visas genom maskering.

Implementera inte datamaskering i arbetsbelastningen. Använd i stället konstruktioner på databasnivå. Azure SQL-tjänstlinjen, inklusive Azure Synapse Analytics, stöder dynamisk datamaskering, vilket minskar exponeringen på programnivån. Det är en principbaserad säkerhetsfunktion som definierar vem som kan visa omaskerade data och hur mycket data som exponeras via maskering. Den inbyggda metoden kreditkortsmaskering exponerar de fyra sista siffrorna i de avsedda fälten och lägger till en konstant sträng som ett prefix i form av ett kreditkort.

Mer information finns i Dynamisk datamaskning.

Om du behöver ta in omaskerade data i klustret maskerar du så snart som möjligt.

Krav 3.4

Gör PAN oläsligt var det än lagras (inklusive på bärbara digitala medier, säkerhetskopieringsmedia och i loggar) med någon av följande metoder:

• Enkelriktade hashar baserade på stark kryptografi, (hash måste vara av hela PAN)
• Trunkering (hashning kan inte användas för att ersätta det trunkerade segmentet i PAN)
• Indextoken och kuddar (kuddar måste lagras på ett säkert sätt)
• Stark kryptografi med tillhörande nyckelhanteringsprocesser och procedurer.

Ditt ansvar

För det här kravet kan du behöva använda direkt kryptografi i arbetsbelastningen. PCI DSS-vägledning rekommenderar att du använder branschtestade algoritmer så att de klarar verkliga attacker. Undvik att använda anpassade krypteringsalgoritmer.

Lämpliga datamaskeringstekniker uppfyller också detta krav. Du ansvarar för att maskera alla panoreringsdata (Primärt kontonummer). Azure SQL-tjänsten, inklusive Azure Synapse Analytics, stöder dynamisk datamaskering. Se Krav 3.3.

Kontrollera att PAN inte exponeras som en del av dina arbetsflödesprocesser. Här följer några överväganden:

• Håll PAN borta från loggar, både arbetsflödesloggar och (förväntade eller oväntade) undantagshanteringsloggar. Diagnostikdataflöden, till exempel HTTP-huvuden, får inte heller exponera dessa data.

• Använd inte PAN som en cache-uppslagsnyckel eller som en del av något filnamn som genereras av den här processen.

• Dina kunder kan tillhandahålla PAN i textfält i fritt format som inte är opromterade. Se till att processer för innehållsverifiering och identifiering finns på plats för alla textfält i fritt format, och rensa allt innehåll som liknar PAN-data.

Krav 3.4.1

Om diskkryptering används (i stället för databaskryptering på fil- eller kolumnnivå) måste logisk åtkomst hanteras separat och oberoende av inbyggda mekanismer för operativsystemautentisering och åtkomstkontroll (till exempel genom att inte använda lokala användarkontodatabaser eller allmänna inloggningsuppgifter för nätverk). Dekrypteringsnycklar får inte associeras med användarkonton.

Ditt ansvar

Som en allmän regel ska du inte lagra tillstånd i AKS-klustret. Använd en extern datalagring som stöder kryptering på lagringsmotornivå.

Alla lagrade data i Azure Storage krypteras och dekrypteras med hjälp av stark kryptografi. Microsoft hanterar de associerade nycklarna. Självhanterade krypteringsnycklar föredras. Kryptera alltid utanför lagringslagret och skriv endast krypterade data till lagringsmediet, vilket säkerställer att nycklarna aldrig ligger i anslutning till lagringslagret.

Med Azure Storage kan du också använda självhanterade nycklar. Mer information finns i Kundhanterade nycklar för Azure Storage-kryptering.

Liknande funktioner är tillgängliga för databaser. Azure SQL-alternativ finns i Azure SQL transparent datakryptering med kundhanterad nyckel.

Se till att du lagrar dina nycklar i ett hanterat nyckelarkiv (Azure Key Vault, Azure Key Vault Managed Hardware Security Module (HSM) och andra).

Om du behöver lagra data tillfälligt aktiverar du funktionen för värdkryptering i AKS för att se till att data som lagras på VM-noder är krypterade.

Krav 3.5

Dokumentera och implementera procedurer för att skydda nycklar som används för att skydda lagrade korthållardata mot avslöjande och missbruk:

Ditt ansvar

Dessa punkter beskrivs i underavsnitten:

• Behåll praxis för åtkomst med lägsta behörighet för kryptografiska nycklar.
• Azure Key Vault och Microsoft Entra ID är utformade för att stödja auktoriserings- och granskningsloggningskraven. Mer information finns i Begära autentisering för Azure Key Vault.
• Skydda alla datakrypteringsnycklar med en nyckelkrypteringsnyckel som lagras på en kryptografisk enhet.
• Om du använder självhanterade nycklar (i stället för Microsoft-hanterade nycklar) har du en process och dokumentation för att underhålla uppgifter som rör nyckelhantering.

Krav 3.5.1

Ytterligare krav endast för tjänstleverantörer: Underhåll en dokumenterad beskrivning av den kryptografiska arkitekturen som innehåller:

• Information om alla algoritmer, protokoll och nycklar som används för skydd av korthållardata, inklusive nyckelstyrka och utgångsdatum
• Beskrivning av nyckelanvändningen för varje nyckel
• Inventering av alla HSM:er och andra SCD:er som används för nyckelhantering

Ditt ansvar

Ett sätt att lagra känslig information (nycklar, anslutningssträng och andra) är att använda den interna Kubernetes-resursenSecret. Du måste uttryckligen aktivera kryptering i vila. Du kan också lagra dem i ett hanterat arkiv, till exempel Azure Key Vault. Av de två metoderna rekommenderar vi att du använder en hanterad butikstjänst. En fördel är minskade kostnader för uppgifter som rör nyckelhantering, till exempel nyckelrotation.

Som standard använder Azure Microsoft-hanterade nycklar för alla krypterade data, per kund. Vissa tjänster stöder dock även självhanterade nycklar för kryptering. Om du använder självhanterade nycklar för kryptering i vila kontrollerar du att du står för en process och strategi som hanterar viktiga hanteringsuppgifter.

Som en del av dokumentationen innehåller du information om nyckelhantering, till exempel information om förfallodatum, plats och underhållsplan.

Krav 3.5.2

Begränsa åtkomsten till kryptografiska nycklar till det minsta antal vårdnadshavare som krävs.

Ditt ansvar

Minimera antalet personer som har åtkomst till nycklarna. Om du använder gruppbaserade rolltilldelningar konfigurerar du en återkommande granskningsprocess för att granska roller som har åtkomst. När projektteamets medlemmar ändras måste konton som inte längre är relevanta tas bort från behörigheter. Endast rätt personer ska ha åtkomst. Överväg att ta bort stående behörigheter till förmån för jit-rolltilldelningar (just-in-time), tidsbaserad rollaktivering och godkännandebaserad rollaktivering.

Krav 3.5.3

Lagra hemliga och privata nycklar som används för att kryptera/dekryptera korthållardata i ett (eller flera) av följande formulär hela tiden:

• Krypterad med en nyckelkrypteringsnyckel som är minst lika stark som datakrypteringsnyckeln och som lagras separat från datakrypteringsnyckeln
• Inom en säker kryptografisk enhet (till exempel en maskinvarusäkerhetsmodul (värd) (HSM) eller PTS-godkänd enhet för interaktionspunkt)
• Som minst två nyckelkomponenter eller nyckelaktier i full längd, i enlighet med en branschgodkända metod

Ditt ansvar

En PCI-DSS 3.2.1-arbetsbelastning måste använda mer än en krypteringsnyckel som en del av data-at-rest-skyddsstrategin. En datakrypteringsnyckel (DEK) används för att kryptera och dekryptera CHD, men du ansvarar för ytterligare en nyckelkrypteringsnyckel (KEK) för att skydda dessa DEK. Du ansvarar också för att säkerställa att KEK lagras i en kryptografisk enhet.

Du kan använda Azure Key Vault för att lagra DEK och använda Azure Dedicated HSM för att lagra KEK. Information om HSM-nyckelhantering finns i Vad är Azure Dedicated HSM?.

Krav 3.6

Dokumentera och implementera alla nyckelhanteringsprocesser och procedurer för kryptografiska nycklar som används för kryptering av korthållardata, inklusive följande:

Ditt ansvar

(GÄLLER FÖR: Krav 3.6.1, Krav 3.6.2, Krav 3.6.3, Krav 3.2.4)

Om du använder Azure Key Vault för att lagra hemligheter som nycklar, certifikat och anslutningssträng skyddar du det mot obehörig åtkomst. Microsoft Defender för Key Vault identifierar misstänkta åtkomstförsök och genererar aviseringar. Du kan visa aviseringarna i Microsoft Defender för molnet. Mer information finns i Microsoft Defender för Key Vault.

Följ NIST-vägledningen om nyckelhantering. Mer information finns i:

• Hantering av kryptografiska nycklar.
• SP 800-133 Rev. 2, rekommendation för kryptografisk nyckelgenerering
• SP 800-57 Del 1 Rev. 5, Rekommendation för nyckelhantering

Se även Microsoft Defender för Key Vault.

Krav 3.6.7

Förhindra obehörig ersättning av kryptografiska nycklar.

Ditt ansvar

• Aktivera diagnostik för alla nyckellager. Använd Azure Monitor för Key Vault. Den samlar in loggar och mått och skickar dem till Azure Monitor. Mer information finns i Övervaka din key vault-tjänst med Azure Monitor för Key Vault.
• Ge skrivskyddade behörigheter till alla konsumenter.
• Har inte stående behörigheter för alla huvudnamn för hanteringstjänsten. Använd i stället jit-rolltilldelningar (just-in-time), tidsbaserad rollaktivering och godkännandebaserad rollaktivering.
• Skapa en centraliserad vy genom att integrera loggar och aviseringar i siem-lösningar (säkerhetsinformation och händelsehantering), till exempel Microsoft Sentinel.
• Vidta åtgärder för aviseringar och meddelanden, särskilt vid oväntade ändringar.

Krav 3.6.8

Krav på att kryptografiska nyckelansvariga formellt ska erkänna att de förstår och accepterar sitt nyckelförvararansvar.

Ditt ansvar

Underhåll dokumentation som beskriver ansvarsområdena för de parter som ansvarar för nyckelhanteringens verksamhet.

Krav 3.7

Se till att säkerhetsprinciper och operativa procedurer för att skydda lagrade korthållardata dokumenteras, används och är kända för alla berörda parter.

Ditt ansvar

Skapa dokumentation som en allmän instruktion plus en serie uppdaterade rollguider för alla personer. Genomför nyanställda utbildningar och löpande utbildning.

Det är viktigt att du har omfattande dokumentation om processer och principer. Flera team deltar i att se till att data skyddas i vila och under överföring. I dokumentationen ger du rollvägledning för alla personer. Rollerna bör omfatta SRE, kundsupport, försäljning, nätverksåtgärder, säkerhetsåtgärder, programvarutekniker, databasadministratörer och andra. Personalen bör utbildas i NIST-vägledning och vilande datastrategier för att hålla kompetensuppsättningen uppdaterad. Utbildningskrav uppfylls i krav 6.5 och krav 12.6.

Krav 4.1

Använd starka kryptografi- och säkerhetsprotokoll (till exempel TLS, IPSEC, SSH och så vidare.) för att skydda känsliga korthållardata under överföring via öppna, offentliga nätverk, inklusive följande:

Ditt ansvar

Kortinnehavarens data (CHD) som överförs via det offentliga Internet måste krypteras. Data måste krypteras med TLS 1.2 (eller senare), med minskat chifferstöd för alla överföringar. Stöd inte för icke-TLS till TLS-omdirigeringar på några dataöverföringstjänster.

Din design bör ha en strategisk kedja med TLS-avslutningspunkter. När data färdas genom nätverkshopp ska du underhålla TLS vid hopp som kräver paketinspektion. Ha åtminstone den sista TLS-avslutningspunkten på klustrets ingressresurs. Överväg att ta det vidare i klusterresurserna.

Använd Azure Policy för att styra skapandet av resurser:

• Neka att någon icke-HTTPS-ingressresurs skapas.
• Neka skapande av offentliga IP-adresser eller offentliga lastbalanserare i klustret för att säkerställa att webbtrafiken dirigeras via din gateway.

Mer information finns i Översikt över Azure-kryptering.

Krav 4.1.1

Se till att trådlösa nätverk överför korthållardata eller är anslutna till korthållardatamiljön, använd branschtips (till exempel IEEE 802.11i) för att implementera stark kryptering för autentisering och överföring.

Ditt ansvar

Den här arkitekturen och implementeringen är inte utformade för att utföra lokala transaktioner eller företagstransaktioner mellan nätverk och moln via trådlösa anslutningar. Överväganden finns i vägledningen i den officiella PCI-DSS 3.2.1-standarden.

Krav 4.2

Skicka aldrig oskyddade PAN:er av slutanvändarnas meddelandetekniker (till exempel e-post, snabbmeddelanden, SMS, chatt osv.).

Ditt ansvar

Om din arbetsbelastning kräver att e-post skickas kan du överväga att skapa en karantänport för e-post. Den här valideringen ger dig möjlighet att genomsöka alla utgående meddelanden efter efterlevnad och kontrollera att känsliga data inte ingår. Helst bör du också överväga den här metoden för kundsupportmeddelanden.

Verifieringen bör göras på arbetsbelastningsnivå och ändringskontrollprocessen. Godkännandegrindarna bör förstå kravet.

Överväganden finns i vägledningen i den officiella PCI-DSS 3.2.1-standarden.

Krav 4.3

Se till att säkerhetsprinciper och operativa procedurer för kryptering av överföring av korthållardata dokumenteras, används och är kända för alla berörda parter.

Ditt ansvar

Det är viktigt att du har omfattande dokumentation om processer och principer. Det gäller särskilt när du hanterar principer för TLS (Transport Layer Security). Här är några områden:

• Offentliga ingresspunkter för Internet. Ett exempel är Stöd för Azure Application Gateway för TLS-chiffer.
• Nätverkshopp mellan perimeternätverks- och arbetsbelastningspoddar.
• Podd-till-poddkryptering (om den implementeras). Detta kan innehålla information om konfigurationen av ett tjänstnät.
• Podd till lagring (om en del av arkitekturen).
• Podd till externa tjänster, Azure PaaS-tjänster som använder TLS, en betalningsgateway eller ett system för bedrägeriidentifiering.

Personer som driver reglerade miljöer måste utbildas, informeras och uppmuntras att stödja säkerhetsgarantierna. Detta är särskilt viktigt för personer som ingår i godkännandeprocessen ur ett politiskt perspektiv.

Nästa steg

Skydda alla system mot skadlig kod och uppdatera regelbundet antivirusprogram eller program. Utveckla och underhålla säkra system och program.