Beveilig gegevens in een gereguleerd AKS-cluster voor PCI-DSS 3.2.1 (deel 4 van 9)

In dit artikel worden de overwegingen voor een AKS-cluster (Azure Kubernetes Service) beschreven waarmee een workload wordt uitgevoerd in overeenstemming met de Pci-DSS 3.2.1 (Payment Card Industry Data Security Standard).

Dit artikel maakt deel uit van een serie. Lees de inleiding.

Deze architectuur en de implementatie zijn gericht op infrastructuur en niet op de workload. Dit artikel bevat algemene overwegingen en aanbevolen procedures om u te helpen bij het nemen van ontwerpbeslissingen. Volg de vereisten in de officiële PCI-DSS 3.2.1-standaard en gebruik dit artikel als aanvullende informatie, indien van toepassing.

Kaartaanduidingsgegevens beveiligen

Vereiste 3: opgeslagen kaartaanduidingsgegevens beveiligen

Uw verantwoordelijkheden

Vereiste 3.1

Bewaar de gegevensopslag van de kaarthouder tot een minimum door beleid voor gegevensretentie en verwijdering te implementeren, procedures en processen die ten minste het volgende bevatten voor alle CHD-opslag (cardholder data):

• Het beperken van de hoeveelheid gegevensopslag en de retentietijd die vereist is voor wettelijke, wettelijke en zakelijke vereisten
• Processen voor het veilig verwijderen van gegevens wanneer ze niet meer nodig zijn
• Specifieke bewaarvereisten voor gegevens van de kaarthouder
• Een kwartaalproces voor het identificeren en veilig verwijderen van opgeslagen kaartaanduidingsgegevens die de gedefinieerde retentie overschrijden.

Uw verantwoordelijkheden

Sla de status niet op in het AKS-cluster. Als u ervoor kiest om CHD op te slaan, verkent u opties voor beveiligde opslag. Opties zijn Onder andere Azure Storage voor bestandsopslag of databases zoals Azure SQL Database of Azure Cosmos DB.

Houd zich strikt aan de standaardrichtlijnen voor het soort CHD dat kan worden opgeslagen. Definieer beleid voor gegevensretentie op basis van uw bedrijfsvereisten en het type opslag dat wordt gebruikt. Enkele belangrijke overwegingen zijn:

• Hoe en waar worden de gegevens opgeslagen?
• Worden de opgeslagen gegevens versleuteld?
• Wat is de bewaarperiode?
• Welke acties zijn toegestaan tijdens de bewaarperiode?
• Hoe verwijdert u de opgeslagen gegevens nadat de bewaarperiode is verlopen?

Beheerbeleidsregels hebben voor een aantal van deze keuzes. Ingebouwde Azure-beleidsregels dwingen deze keuzes af. U kunt bijvoorbeeld de volumetypen op de clusterpods beperken of schrijfbewerkingen weigeren in het hoofdbestandssysteem.

Bekijk deze lijst met beleidsdefinities en pas deze toe op het cluster, indien van toepassing.

Mogelijk moet u tijdelijk gegevens in de cache opslaan. U wordt aangeraden de gegevens in de cache te beveiligen terwijl deze worden verplaatst naar een opslagoplossing. Overweeg om de versleutelingsfunctie op basis van een host in te schakelen op AKS. Hiermee worden de gegevens versleuteld die zijn opgeslagen op knooppunt-VM's. Zie Host-gebaseerde versleuteling op Azure Kubernetes Service (AKS) voor meer informatie. Schakel ook een ingebouwd Azure-beleid in dat versleuteling van tijdelijke schijven en cache voor knooppuntgroepen vereist.

Wanneer u een opslagtechnologie kiest, verkent u de bewaarfuncties. Azure Blob Storage biedt bijvoorbeeld bewaarbeleid op basis van tijd. Een andere keuze is het implementeren van een aangepaste oplossing waarmee gegevens worden verwijderd volgens bewaarbeleid. Een voorbeeld hiervan is DLM (Data Lifecycle Management), waarmee activiteiten in de levenscyclus van gegevens worden beheerd. De oplossing is ontworpen met services zoals Azure Data Factory, Microsoft Entra ID en Azure Key Vault.

Zie De levenscyclus van gegevens beheren met Behulp van Azure Data Factory voor meer informatie.

Vereiste 3.2

Sla geen gevoelige verificatiegegevens op na autorisatie (zelfs niet als deze zijn versleuteld). Als gevoelige verificatiegegevens worden ontvangen, worden alle gegevens onherstelbaar weergegeven na voltooiing van het autorisatieproces.

Uw verantwoordelijkheden

(VAN TOEPASSING OP: Vereiste 3.2.1, Vereiste 3.2.2, Vereiste 3.2.3)

Het verwerken en beveiligen van gegevens is een probleem met workloads en valt buiten het bereik van deze architectuur. Hier volgen enkele algemene overwegingen.

Gevoelige verificatiegegevens bestaan volgens de standaard uit volledige traceergegevens, kaartvalidatiecode of -waarde en pincodegegevens. Als onderdeel van CHD-verwerking moet u ervoor zorgen dat verificatiegegevens niet worden weergegeven in bronnen zoals:

• Logboeken die worden verzonden vanuit de pods.
• Routines voor het afhandelen van uitzonderingen.
• Bestandsnamen.
• Caches.

Als algemene richtlijnen mogen verkopers deze informatie niet opslaan. Als er een document nodig is voor de zakelijke reden.

Vereiste 3.3

Masker PAN wanneer weergegeven (de eerste zes en laatste vier cijfers zijn het maximum aantal cijfers dat moet worden weergegeven), zodat alleen personeel met een legitieme bedrijfsbehoefte de volledige PAN kan zien.

Uw verantwoordelijkheden

Het primaire accountnummer (PAN) wordt beschouwd als gevoelige gegevens en blootstelling aan deze gegevens moet worden voorkomen. Een manier is om de weergegeven cijfers te verminderen door middel van maskering.

Implementeer geen gegevensmaskering in de workload. Gebruik in plaats daarvan constructies op databaseniveau. De Azure SQL-serviceregel, waaronder Azure Synapse Analytics, ondersteunt dynamische gegevensmaskering, waardoor de blootstelling aan de toepassingslaag wordt verminderd. Het is een beveiligingsfunctie op basis van beleid waarmee wordt gedefinieerd wie de ontmaskerde gegevens kan bekijken en hoeveel gegevens worden weergegeven via maskering. De ingebouwde methode creditcardmaskering toont de laatste vier cijfers van de aangewezen velden en voegt een constante tekenreeks toe als voorvoegsel in de vorm van een creditcard.

Zie Dynamische gegevensmaskering voor meer informatie.

Als u niet-gemaskeerde gegevens in uw cluster wilt opnemen, maskert u dit zo snel mogelijk.

Vereiste 3.4

Maak PAN onleesbaar waar deze is opgeslagen (inclusief op draagbare digitale media, back-upmedia en in logboeken) met behulp van een van de volgende methoden:

• Hashes in één richting op basis van sterke cryptografie (hash moet van de hele PAN zijn)
• Afkapping (hashing kan niet worden gebruikt om het afgekapte segment van PAN te vervangen)
• Indextokens en -pads (pads moeten veilig worden opgeslagen)
• Sterke cryptografie met bijbehorende processen en procedures voor sleutelbeheer.

Uw verantwoordelijkheden

Voor deze vereiste moet u mogelijk directe cryptografie in de workload gebruiken. PCI DSS-richtlijnen adviseren het gebruik van door de industrie geteste algoritmen, zodat ze opstaan voor echte aanvallen. Vermijd het gebruik van aangepaste versleutelingsalgoritmen.

De juiste technieken voor gegevensmaskering voldoen ook aan deze vereiste. U bent verantwoordelijk voor het maskeren van alle gegevens van het primaire accountnummer (PAN). De Azure SQL-servicelijn, waaronder Azure Synapse Analytics, biedt ondersteuning voor dynamische gegevensmaskering. Zie Vereiste 3.3.

Zorg ervoor dat PAN niet wordt weergegeven als onderdeel van uw werkstroomprocessen. Hier volgen enkele overwegingen:

• Houd PAN uit logboeken, zowel werkstroomlogboeken als (verwacht of onverwacht) uitzonderingsafhandelingslogboeken. Daarnaast mogen diagnostische gegevensstromen, zoals HTTP-headers, deze gegevens niet beschikbaar maken.

• Gebruik PAN niet als een cachezoeksleutel of als onderdeel van een bestandsnaam die door dit proces wordt gegenereerd.

• Uw klanten kunnen PAN opgeven in vrije tekstvelden die niet worden opgegeven. Zorg ervoor dat inhoudsvalidatie- en detectieprocessen aanwezig zijn voor vrije tekstvelden, waarbij alle inhoud wordt verwijderd die lijkt op PAN-gegevens.

Vereiste 3.4.1

Als schijfversleuteling wordt gebruikt (in plaats van databaseversleuteling op bestand- of kolomniveau), moet logische toegang afzonderlijk en onafhankelijk van systeemeigen verificatie- en toegangsbeheermechanismen worden beheerd (bijvoorbeeld door geen lokale gebruikersaccountdatabases of algemene aanmeldingsreferenties voor het netwerk te gebruiken). Ontsleutelingssleutels mogen niet worden gekoppeld aan gebruikersaccounts.

Uw verantwoordelijkheden

Sla in de regel de status niet op in het AKS-cluster. Gebruik een externe gegevensopslag die ondersteuning biedt voor versleuteling op opslag-engineniveau.

Alle opgeslagen gegevens in Azure Storage worden versleuteld en ontsleuteld met behulp van sterke cryptografie. Microsoft beheert de bijbehorende sleutels. Zelfbeheerde versleutelingssleutels hebben de voorkeur. Versleutel altijd buiten de opslaglaag en schrijf alleen versleutelde gegevens naar het opslagmedium, zodat de sleutels nooit grenzen aan de opslaglaag.

Met Azure Storage kunt u ook zelfbeheerde sleutels gebruiken. Zie Door de klant beheerde sleutels voor Azure Storage-versleuteling voor meer informatie.

Vergelijkbare mogelijkheden zijn beschikbaar voor databases. Zie Azure SQL Transparent Data Encryption met door de klant beheerde sleutel voor Azure SQL voor opties.

Zorg ervoor dat u uw sleutels opslaat in een beheerd sleutelarchief, zoals Azure Key Vault, Azure Managed HSM of een oplossing voor sleutelbeheer van derden.

Als u gegevens tijdelijk wilt opslaan, schakelt u de functie voor hostversleuteling van AKS in om ervoor te zorgen dat gegevens die zijn opgeslagen op VM-knooppunten zijn versleuteld.

Vereiste 3.5

Documenteer en implementeer procedures voor het beveiligen van sleutels die worden gebruikt voor het beveiligen van opgeslagen gegevens van de kaarthouder tegen openbaarmaking en misbruik.

Uw verantwoordelijkheden

Deze punten worden beschreven in de subsecties:

• Behoud de praktijk van toegang met minimale bevoegdheden voor de cryptografische sleutels.
• Azure Key Vault en Microsoft Entra-id zijn ontworpen ter ondersteuning van de vereisten voor autorisatie- en auditlogboekregistratie. Zie Verificatie aanvragen voor Azure Key Vault voor meer informatie.
• Beveilig alle gegevensversleutelingssleutels met een sleutelversleutelingssleutel die is opgeslagen op een cryptografisch apparaat.
• Als u zelfbeheerde sleutels gebruikt (in plaats van door Microsoft beheerde sleutels), hebt u een proces en documentatie voor het onderhouden van taken met betrekking tot sleutelbeheer.

Vereiste 3.5.1

Aanvullende vereiste voor alleen serviceproviders: behoud een gedocumenteerde beschrijving van de cryptografische architectuur die het volgende omvat:

• Details van alle algoritmen, protocollen en sleutels die worden gebruikt voor de beveiliging van gegevens van de kaarthouder, inclusief de sleutelsterkte en vervaldatum
• Beschrijving van het sleutelgebruik voor elke sleutel
• Inventaris van HSM's en andere SCD's die worden gebruikt voor sleutelbeheer

Uw verantwoordelijkheden

Een manier om gevoelige informatie (sleutels, verbindingsreeks s en andere) op te slaan, is het gebruik van de systeemeigen Kubernetes-resourceSecret. U moet versleuteling -at-rest expliciet inschakelen. U kunt ze ook opslaan in een beheerd archief, zoals Azure Key Vault. Van de twee benaderingen raden we u aan een beheerde winkelservice te gebruiken. Een voordeel is minder overhead in taken met betrekking tot sleutelbeheer, zoals sleutelrotatie.

Azure maakt standaard gebruik van door Microsoft beheerde sleutels voor alle versleutelde gegevens, per klant. Sommige services ondersteunen echter ook zelfbeheerde sleutels voor versleuteling. Als u zelfbeheerde sleutels gebruikt voor versleuteling-at-rest, moet u ervoor zorgen dat u rekening houdt met een proces en strategie die belangrijke beheertaken afhandelt.

Neem als onderdeel van uw documentatie informatie op met betrekking tot sleutelbeheer, zoals vervaldatum, locatie en onderhoudsplandetails.

Vereiste 3.5.2

Beperk de toegang tot cryptografische sleutels tot het minste aantal beheerders dat nodig is.

Uw verantwoordelijkheden

Minimaliseer het aantal personen dat toegang heeft tot de sleutels. Als u op groepen gebaseerde roltoewijzingen gebruikt, stelt u een terugkerend controleproces in om rollen te controleren die toegang hebben. Wanneer projectteamleden worden gewijzigd, moeten accounts die niet meer relevant zijn, worden verwijderd uit machtigingen. Alleen de juiste mensen moeten toegang hebben. Gebruik Microsoft Entra ID-toegangsbeoordelingen om regelmatig groepslidmaatschappen te controleren.

Overweeg om permanente machtigingen te verwijderen ten gunste van Just-In-Time-roltoewijzingen (JIT), activering van op tijd gebaseerde rollen en activering van rol op basis van goedkeuring. U kunt bijvoorbeeld Privileged Identity Management gebruiken.

Vereiste 3.5.3

Bewaar geheime en persoonlijke sleutels die worden gebruikt voor het versleutelen/ontsleutelen van gegevens van de kaarthouder in een (of meer) van de volgende formulieren:

• Versleuteld met een sleutelversleutelingssleutel die ten minste even sterk is als de sleutel voor gegevensversleuteling en die afzonderlijk van de sleutel voor gegevensversleuteling wordt opgeslagen
• Binnen een beveiligd cryptografisch apparaat (zoals een hardware (host) beveiligingsmodule (HSM) of PTS-goedgekeurd punt-of-interactieapparaat)
• Als ten minste twee onderdelen van de volledige lengte of sleutelshares, in overeenstemming met een door de branche geaccepteerde methode

Uw verantwoordelijkheden

Een PCI-DSS 3.2.1-workload moet meer dan één versleutelingssleutel gebruiken als onderdeel van de strategie voor data-at-rest-beveiliging. Een DATA Encryption Key (DEK) wordt gebruikt voor het versleutelen en ontsleutelen van de CHD, maar u bent verantwoordelijk voor een extra sleutelversleutelingssleutel (KEK) om die DEK te beveiligen. U bent ook verantwoordelijk voor het garanderen dat de KEK is opgeslagen in een cryptografisch apparaat.

U kunt Azure Key Vault gebruiken om de DEK op te slaan en Azure Dedicated HSM te gebruiken om de KEK op te slaan. Zie Wat is Azure Dedicated HSM?voor informatie over HSM-sleutelbeheer.

Vereiste 3.6

Documenteer en implementeer alle processen en procedures voor sleutelbeheer voor cryptografische sleutels die worden gebruikt voor versleuteling van gegevens van de kaarthouder, met inbegrip van het volgende:

Uw verantwoordelijkheden

(VAN TOEPASSING OP: Vereiste 3.6.1, Vereiste 3.6.2, Vereiste 3.6.3, Vereiste 3.2.4)

Als u Azure Key Vault gebruikt om geheimen zoals sleutels, certificaten en verbindingsreeks s op te slaan, moet u deze beveiligen tegen onbevoegde toegang. Microsoft Defender voor Key Vault detecteert verdachte toegangspogingen en genereert waarschuwingen. U kunt deze waarschuwingen bekijken in Microsoft Defender voor Cloud. Zie Microsoft Defender voor Key Vault voor meer informatie.

Volg de NIST-richtlijnen over sleutelbeheer. Zie deze artikelen voor meer informatie:

• Cryptografisch sleutelbeheer.
• SP 800-133 Rev. 2, Aanbeveling voor het genereren van cryptografische sleutels
• SP 800-57 Deel 1 Rev. 5, Aanbeveling voor Sleutelbeheer

Zie ook Microsoft Defender voor Key Vault.

Vereiste 3.6.7

Preventie van onbevoegde vervanging van cryptografische sleutels.

Uw verantwoordelijkheden

• Schakel diagnostische gegevens in voor alle sleutelarchieven. Gebruik Azure Monitor voor Key Vault. Hiermee worden logboeken en metrische gegevens verzameld en naar Azure Monitor verzonden. Zie Uw sleutelkluisservice bewaken met Azure Monitor voor Key Vault voor meer informatie.
• Geef alleen-lezenmachtigingen aan alle consumenten.
• U beschikt niet over vaste machtigingen voor beheergebruikers of principals. Gebruik in plaats daarvan Just-In-Time-roltoewijzingen (JIT), op tijd gebaseerde rolactivering en activering van rol op basis van goedkeuring.
• Maak een gecentraliseerde weergave door logboeken en waarschuwingen te integreren in SIEM-oplossingen (Security Information and Event Management), zoals Microsoft Sentinel.
• Actie ondernemen op waarschuwingen en meldingen, met name bij onverwachte wijzigingen.

Vereiste 3.6.8

Vereiste voor cryptografische sleutelbewaarders om formeel te erkennen dat ze hun verantwoordelijkheden voor sleutelbewaarders begrijpen en accepteren.

Uw verantwoordelijkheden

Documentatie onderhouden die de accountabiliteiten beschrijft van de partijen die verantwoordelijk zijn voor de werking van sleutelbeheer.

Vereiste 3.7

Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het beveiligen van opgeslagen gegevens van de kaarthouder worden gedocumenteerd, gebruikt en bekend zijn bij alle betrokken partijen.

Uw verantwoordelijkheden

Maak documentatie als algemene instructie plus een reeks up-to-date rolhandleidingen voor alle persona's. Voer nieuwe training en doorlopende training uit.

Het is essentieel dat u grondige documentatie over de processen en beleidsregels onderhoudt. Verschillende teams nemen deel om ervoor te zorgen dat gegevens in rust en onderweg worden beveiligd. Geef in uw documentatie rolrichtlijnen op voor alle persona's. De rollen moeten SRE, klantondersteuning, verkoop, netwerkbewerkingen, beveiligingsbewerkingen, softwaretechnici, databasebeheerders en andere omvatten. Personeel moet worden getraind in NIST-richtlijnen en strategieën voor data-at-rest om de vaardighedenset up-to-date te houden. Trainingsvereisten worden aangepakt in Vereiste 6.5 en Vereiste 12.6.

Vereiste 4: overdracht van kaartaanduidingsgegevens in open, openbare netwerken versleutelen

Uw verantwoordelijkheden

Vereiste 4.1

Gebruik sterke cryptografie- en beveiligingsprotocollen (bijvoorbeeld TLS, IPSEC, SSH, enzovoort) om gevoelige gegevens van de kaarthouder te beveiligen tijdens verzending via open, openbare netwerken, waaronder:

Uw verantwoordelijkheden

Kaarthoudergegevens (CHD) die via het openbare internet worden verzonden, moeten worden versleuteld. Gegevens moeten worden versleuteld met TLS 1.2 (of hoger), met beperkte coderingsondersteuning voor alle verzendingen. Biedt geen ondersteuning voor niet-TLS-naar-TLS-omleidingen voor gegevensoverdrachtservices.

Uw ontwerp moet een strategische keten van TLS-beëindigingspunten hebben. Wanneer gegevens via netwerkhops worden verzonden, onderhoudt u TLS bij hops waarvoor pakketinspectie is vereist. Op zijn minst beschikt u over het laatste TLS-beëindigingspunt op de toegangsbeheerresource van het cluster. Overweeg het verder te doen binnen de clusterbronnen.

Azure Policy gebruiken om het maken van resources te beheren:

• Het maken van een niet-HTTPS-toegangsbeheerobjectresource weigeren.
• Weiger het maken van een openbaar IP-adres of openbare load balancers in uw cluster om ervoor te zorgen dat webverkeer wordt getunneld via uw gateway.

Zie het overzicht van Azure-versleuteling voor meer informatie.

Vereiste 4.1.1

Zorg ervoor dat draadloze netwerken die gegevens van de kaarthouder verzenden of die zijn verbonden met de gegevensomgeving van de kaarthouder, gebruikmaken van aanbevolen procedures voor de branche (bijvoorbeeld IEEE 802.11i) om sterke versleuteling voor verificatie en verzending te implementeren.

Uw verantwoordelijkheden

Deze architectuur en de implementatie zijn niet ontworpen voor on-premises of bedrijfsnetwerk-naar-cloudtransacties via draadloze verbindingen. Raadpleeg voor overwegingen de richtlijnen in de officiële PCI-DSS 3.2.1-standaard.

Vereiste 4.2

Verzend nooit niet-beveiligde PA's door technologieën voor eindgebruikersberichten (bijvoorbeeld e-mail, chat, sms, chat, enzovoort).

Uw verantwoordelijkheden

Als voor uw workload e-mailberichten moeten worden verzonden, kunt u overwegen om een e-mailquarantainepoort te bouwen. Met deze validatie kunt u alle uitgaande berichten scannen op naleving en controleren of gevoelige gegevens niet zijn opgenomen. In het ideale geval moet u deze benadering ook overwegen voor klantondersteuningsberichten.

Validatie moet worden uitgevoerd op workloadniveau en het wijzigingsbeheerproces. De goedkeuringspoorten moeten de vereiste begrijpen.

Raadpleeg voor overwegingen de richtlijnen in de officiële PCI-DSS 3.2.1-standaard.

Vereiste 4.3

Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het versleutelen van verzendingen van gegevens van kaarthouders worden gedocumenteerd, gebruikt en bekend bij alle betrokken partijen.

Uw verantwoordelijkheden

Het is essentieel dat u grondige documentatie over de processen en beleidsregels onderhoudt. Dat geldt vooral wanneer u beleidsregels beheert over Transport Layer Security (TLS). Hier volgen enkele gebieden:

• Toegangspunten voor openbaar internet. Een voorbeeld is Azure-toepassing Gateway-ondersteuning voor TLS-coderingen.
• Netwerkhops tussen perimeternetwerk- en workloadpods.
• Pod-naar-pod-versleuteling (indien geïmplementeerd). Dit kan details bevatten over de configuratie van een service-mesh.
• Pod naar opslag (als onderdeel van de architectuur).
• Pod naar externe services, Azure PaaS-services die gebruikmaken van TLS, een betalingsgateway of een fraudedetectiesysteem.

Mensen die gereguleerde omgevingen gebruiken, moeten worden opgeleid, geïnformeerd en geïncentiveerd om de beveiligingsgaranties te ondersteunen. Dit is met name belangrijk voor mensen die deel uitmaken van het goedkeuringsproces vanuit een beleidsperspectief.

Volgende stappen

Bescherm alle systemen tegen malware en werk regelmatig antivirussoftware of -programma's bij. Veilige systemen en toepassingen ontwikkelen en onderhouden.