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

Den här artikeln beskriver överväganden för ett Azure Kubernetes Service-kluster (AKS) 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

Dina ansvarsområden

Krav	Ansvar
Krav 3.1	Behåll korthållardatalagringen till ett minimum genom att implementera principer för kvarhållning och tömning av data, procedurer och processer som omfattar minst följande för all korthållardatalagring (CHD):
Krav 3.2	Lagra inte känsliga autentiseringsdata efter auktorisering (även om de är krypterade). Om känsliga autentiseringsdata tas emot kan alla data inte å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ärs behov kan se hela PAN.
Krav 3.4	Rendera PAN oläsbart överallt där det lagras (inklusive på bärbara digitala media, säkerhetskopieringsmedia och 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 i öppna, offentliga nätverk.

Dina ansvarsområden

Krav	Ansvar
Krav 4.1	Använda stark 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 med hjälp av tekniker för slutanvändarmeddelanden (till exempel e-post, snabbmeddelanden, SMS, chatt osv.).
Krav 4.3	Se till att säkerhetsprinciper och operativa procedurer för kryptering av överföringar av korthållardata dokumenteras, används och är kända för alla berörda parter.

Krav 3.1

Behåll korthållardatalagringen till ett minimum genom att implementera principer för kvarhållning och tömning av data, procedurer och processer som omfattar minst följande för all korthållardatalagring (CHD):

• Begränsa datalagringsmängden och kvarhållningstiden till den som krävs för juridiska krav, regler och affärskrav
• Processer för säker borttagning av data när de inte längre behövs
• Särskilda 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.

Dina ansvarsområden

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

Följ enbart standardvägledningen om vilken typ av CHD som kan lagras. Definiera principer för datalagring baserat på dina affärskrav och vilken typ av lagring som används. Några viktiga saker att tänka på:

• 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 gått ut?

Ha styrningsprinciper kring några av dessa alternativ. Inbyggda Azure-principer framtvingar 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, om tillämpligt.

Du kan behöva cachelagra data tillfälligt. Vi rekommenderar att du skyddar cachelagrade data när de flyttas till en lagringslösning. Överväg att aktivera funktionen för värdbaserad kryptering i AKS. Detta krypterar de data som lagras på nod-VM:ar. Mer information finns i Värdbaserad kryptering på Azure Kubernetes Service (AKS). Aktivera också en inbyggd Azure-princip som kräver kryptering av temporära diskar och cachelagring för nodpooler.

När du väljer lagringsteknik kan du utforska kvarhållningsfunktionerna. Azure Blob Storage till exempel tidsbaserade kvarhållningsprinciper. Ett annat alternativ är att implementera en anpassad lösning som tar bort data enligt bevarandeprinciper. Ett exempel är Data Lifecycle Management (DLM), som hanterar datalivscykelaktiviteter. Lösningen har utformats med tjänster som Azure Data Factory, Azure Active Directory (Azure AD) 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 kan alla data inte återställas när auktoriseringsprocessen har slutförts.

Dina ansvarsområden

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

Bearbetning och skydd av data ligger utanför den här arkitekturens omfattning. Här är några allmänna överväganden.

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

• Loggar som genereras från poddarna.
• Undantagshanteringsrutiner.
• Filnamn.
• Cache.

Som allmänna riktlinjer bör säljarna inte lagra den här informationen. Om det finns ett behov dokumenterar du affärsberättigandet.

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ärs behov kan se hela PAN.

Dina ansvarsområden

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 via maskering.

Implementera inte datamaskning i arbetsbelastningen. Använd i stället konstruktioner på databasnivå. Azure SQL tjänstlinje, 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 avmaskerade data och hur mycket data som exponeras via maskering. Den inbyggda metoden för kreditkortsmaskering visar de sista fyra siffrorna i de angivna fälten och lägger till en konstant sträng som ett prefix i form av ett kreditkort.

Mer information finns i Dynamisk datamaskering.

Om du behöver föra in avmaskerade data i klustret ska du maskera så snart som möjligt.

Krav 3.4

Rendera PAN oläsbart överallt där det lagras (inklusive på bärbara digitala media, säkerhetskopieringsmedia och loggar) med någon av följande metoder:

• Envägs-hashs baserade på stark kryptografi (hash måste vara av hela PAN)
• Trunkering (hashing kan inte användas för att ersätta det trunkerade segmentet i PAN)
• Indextoken och lägg (lägg måste lagras på ett säkert sätt)
• Stark kryptografi med associerade processer och procedurer för nyckelhantering.

Dina ansvarsområden

För det här kravet kan du behöva använda direktkryptografi i arbetsbelastningen. PCI DSS rekommenderar att du använder branschtestade algoritmer så att de står upp för verkliga attacker. Undvik att använda anpassade krypteringsalgoritmer.

Lämpliga datamaskeringstekniker uppfyller också detta krav. Du ansvarar för att maskera alla data för primärt kontonummer (PAN). Azure SQL tjänster, 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 är några saker att tänka på:

• Håll PAN utanför loggar, både arbetsflödesloggar och (förväntade eller oväntade) undantagshanteringsloggar. Dessutom får inte diagnostikdataflöden, till exempel HTTP-huvuden, 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 friformstextfält som inte harprompterats. Se till att processerna för innehållsvalidering och -identifiering finns på plats för alla friformstextfält 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 interna mekanismer för operativsystemautentisering och åtkomstkontroll (till exempel genom att inte använda lokala användarkontodatabaser eller allmänna autentiseringsuppgifter för nätverksinloggning). Dekrypteringsnycklar får inte associeras med användarkonton.

Dina ansvarsområden

Lagra inte tillstånd i AKS-klustret som en allmän regel. 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älv hanterade krypteringsnycklar rekommenderas. Kryptera alltid utanför lagringslagret och skriv endast krypterade data till lagringsmediet, så att nycklarna aldrig ligger intill lagringslagret.

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

Liknande funktioner är tillgängliga för databaser. Alternativ för Azure SQL finns i Azure SQL transparent datakryptering med kund hanterad nyckel.

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

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 krypteras.

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:

Dina ansvarsområden

Dessa punkter beskrivs i underavsnitten:

• Behåll praxis för åtkomst med minsta behörighet för de kryptografiska nycklarna.
• Azure Key Vault och Azure Active Directory är utformade för att stödja kraven på auktorisering och granskningsloggning. Mer information finns i Begär autentisering för Azure Key Vault.
• Skydda alla datakrypteringsnycklar med en nyckelkrypteringsnyckel som lagras på en kryptografisk enhet.
• Om du använder själv hanterade nycklar (i stället för Microsoft-hanterade nycklar) ska du ha 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: Upprätthåll en dokumenterad beskrivning av den kryptografiska arkitektur som innehåller:

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

Dina ansvarsområden

Ett sätt att lagra känslig information (nycklar, anslutningssträngar och andra) är att använda den interna Kubernetes-resursen. Secret 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 i 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älv hanterade nycklar för kryptering. Om du använder själv hanterade nycklar för kryptering i vila ska du se till att du tar hänsyn till en process och strategi som hanterar nyckelhanteringsuppgifter.

Som en del av dokumentationen bör du inkludera information som rör nyckelhantering, till exempel förfallotid, plats och underhållsplaninformation.

Krav 3.5.2

Begränsa åtkomsten till kryptografiska nycklar till det minsta antal undersökningsnycklar som krävs.

Dina ansvarsområden

Minimera antalet personer som har åtkomst till nycklarna. Om du använder gruppbaserade rolltilldelningar kan du konfigurera 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örigheterna. 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 en (eller flera) av följande former hela tiden:

• Krypterad med en nyckelkrypterande nyckel som är minst lika stark som den datakrypterande nyckeln 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 interaktionspunktsenhet)
• Som minst två fullständiga nyckelkomponenter eller nyckelresurser, i enlighet med en branschledande metod

Dina ansvarsområden

En PCI-DSS 3.2.1-arbetsbelastning måste använda mer än en krypteringsnyckel som en del av dataskyddsstrategin för vilodata. 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 deK. Du ansvarar också för att säkerställa att KEK lagras på 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:

Dina ansvarsområden

(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 att lagra hemligheter som nycklar, certifikat och anslutningssträngar ska du skydda den mot obehörig åtkomst. Microsoft Defender för Key Vault identifierar misstänkta åtkomstförsök och genererar aviseringar. Du kan visa dessa aviseringar 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, Recommendation for Cryptographic Key Generation
• 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.

Dina ansvarsområden

• Aktivera diagnostik på 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 Monitoring your key vault service with Azure Monitor for Key Vault.
• Ge skrivskyddade behörigheter till alla konsumenter.
• Ha inte behörighet 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 lösningar för säkerhetsinformation och händelsehantering (SIEM), 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 nyckelförarna formellt ska bekräfta att de förstår och godkänner sitt nyckelföraransvar.

Dina ansvarsområden

Underhålla dokumentation som beskriver kontohanteringen för de parter som ansvarar för nyckelhanteringen.

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.

Dina ansvarsområden

Skapa dokumentation som en allmän instruktion plus en serie uppdaterade rollguider för alla personer. Utföra utbildning för nyanställda och kontinuerlig utbildning.

Det är viktigt att du underhåller omfattande dokumentation om processer och principer. Flera team deltar i att se till att data skyddas i vila och under överföring. Ge rollvägledning för alla personer i dokumentationen. Rollerna bör omfatta SRE, kundsupport, försäljning, nätverksåtgärder, säkerhetsåtgärder, programvarutekniker, databasadministratörer med mera. Personal bör utbildas i NIST-vägledning och strategier för vilodata för att hålla kompetensuppsättningen uppdaterad. Utbildningskraven behandlas i Krav 6.5 ochKrav 12.6.

Krav 4.1

Använd stark 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:

Dina ansvarsområden

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öder inte icke-TLS till TLS-omdirigeringar på dataöverföringstjänster.

Din design bör ha en strategisk kedja av TLS-avslutningspunkter. När data skickas via nätverkshopp bör du underhålla TLS vid hopp som kräver paketinspektion. Åtminstone ha den slutliga TLS-avslutningspunkten vid klustrets ingressresurs. Överväg att ta det längre inom klusterresurserna.

Använd Azure Policy att styra skapandet av resurser:

• Neka skapande av en icke-HTTPS-ingressresurs.
• Neka skapande av offentliga IP-adresser eller offentliga lastbalanserare i klustret för att säkerställa att webbtrafiken går 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 branschens bästa praxis (till exempel IEEE 802.11i) för att implementera stark kryptering för autentisering och överföring.

Dina ansvarsområden

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

Krav 4.2

Skicka aldrig oskyddade PAN med hjälp av tekniker för slutanvändarmeddelanden (till exempel e-post, snabbmeddelanden, SMS, chatt osv.).

Dina ansvarsområden

Om din arbetsbelastning kräver att du skickar e-post bör du överväga att skapa en karantänport för e-post. Med den här verifieringen kan du söka igenom alla utgående meddelanden för kompatibilitet och kontrollera att känsliga data inte ingår. Vi rekommenderar att du även överväger den här metoden för meddelanden från kundsupporten.

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

Information 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öringar av korthållardata dokumenteras, används och är kända för alla berörda parter.

Dina ansvarsområden

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

• In- och utgångspunkter för offentligt Internet. Ett exempel är Azure Application Gateway stöd för TLS-chiffer.
• Nätverkshopp mellan perimeternätverk och arbetsbelastningspoddar.
• Pod-to-pod-kryptering (om det implementeras). Detta kan innehålla information om konfigurationen av ett tjänstnät.
• Pod 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 använder reglerade miljöer måste utbildas, informeras och ges incitament för att stödja säkerhetsgarantin. Detta är särskilt viktigt för personer som ingår i godkännandeprocessen ur ett principperspektiv.

Nästa

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