Netwerken van een gereguleerd AKS-cluster configureren voor PCI-DSS 3.2.1 (deel 3 van 9)

In dit artikel worden de netwerkoverwegingen voor een AKS-cluster (Azure Kubernetes Service) beschreven dat is geconfigureerd volgens de Pci-DSS 3.2.1 (Payment Card Industry Data Security Standard).

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

Het belangrijkste thema van de PCI-DSS 3.2.1-standaard is beveiliging. De hub-spoke-topologie is een natuurlijke keuze voor het instellen van een gereguleerde omgeving. Het is eenvoudiger om een infrastructuur te maken waarmee beveiligde communicatie mogelijk is. Netwerkbesturingselementen worden in beide hub-spoke-netwerken geplaatst en volgen het Microsoft Zero Trust-model. De besturingselementen kunnen worden afgestemd met minimale bevoegdheden om verkeer te beveiligen, waardoor toegang op basis van noodzaak tot kennis wordt gegeven. Daarnaast kunt u verschillende diepgaande verdedigingsmethoden toepassen door besturingselementen toe te voegen bij elke netwerkhop.

Wanneer u een workload host in een Kubernetes, is het niet voldoende om te vertrouwen op traditionele netwerkconstructies, zoals firewallregels. Er zijn ook Kubernetes-systeemeigen constructies die de stroom van verkeer binnen het cluster beheren, zoals de NetworkPolicy resource. We raden u ten zeerste aan de Kubernetes-documentatie te raadplegen om inzicht te hebben in de kernconcepten over geïsoleerde pods en inkomend en uitgaand beleid.

Een beveiligd netwerk en systemen bouwen en onderhouden

Vereiste 1: installeer en onderhoud een firewallconfiguratie om gegevens van de kaarthouder te beveiligen.

Ondersteuning voor AKS-functies

AKS biedt ondersteuning voor het implementeren van een cluster in een virtueel particulier netwerk als een privécluster. Communicatie tussen het cluster en de door AKS beheerde Kubernetes API-server verloopt via een vertrouwd netwerk. Met een privécluster kunt u Azure Virtual Network, Netwerkbeveiligingsgroep (NSG) en andere ingebouwde netwerkbesturingselementen gebruiken om de volledige CDE (CardHolder Data Environment) te beveiligen. Dit verbiedt onbevoegde openbare toegang tussen internet en de omgeving. Zie Een privé-Azure Kubernetes Service-cluster maken voor meer informatie over het inrichten van een dergelijk cluster.

Azure Firewall kan worden geïntegreerd met AKS en kan uitgaand verkeer van het cluster beperken. Dit is een belangrijk onderdeel van de CDE. De configuratie is eenvoudig met een AKS FQDN-tag. Het aanbevolen proces wordt gegeven in Azure Firewall gebruiken om AKS-implementaties (Azure Kubernetes Service) te beveiligen.

Voor AKS-clusters is openbare internettoegang vereist. Beperk uitgaand verkeer naar internet met behulp van Azure Firewall en NSG's in het clustersubnet. Zie Uitgaand verkeer beheren voor clusterknooppunten in Azure Kubernetes Service (AKS) voor meer informatie.

AKS ondersteunt optioneel de mogelijkheid om een HTTP-proxy te definiëren, die kan worden gebruikt voor aanvullende uitgaande verkeersbeheer en -bewaking voor het cluster. De clusterknooppunten gebruiken de opgegeven HTTP-proxyconfiguratie voor het routeren van uitgaand verkeer. Ook wordt een MutatingWebhook geregistreerd om de proxygegevens tijdens het maken in te voeren in de pods, dus het wordt aanbevolen dat workloads dezelfde proxygegevens overnemen. Pods kunnen proxygegevens overschrijven, dus het wordt aanbevolen om naast een Azure Firewall een HTTP-proxy te gebruiken.

AKS-clusters moeten worden gemaakt met de NetworkPolicy-invoegtoepassing. In AKS hebt u de optie tussen Azure of Calico, als uw Network Policy-invoegtoepassing. Met Calico-netwerkbeleid kunt u Kubenet of Azure CNI gebruiken. Voor Azure Network Policy kunt u alleen Azure CNI (niet Kubenet) gebruiken. Netwerkbeleid voor Windows-knooppunten wordt alleen ondersteund met Calico. Zowel Azure- als Calico Network Policy-invoegtoepassingen zijn open source. Zie het uitgebreide technische document over PCI-oplossingen voor meer informatie over Project Calico, waarin veel van de onderstaande firewallvereisten worden aangepakt.

Uw verantwoordelijkheden

Vereiste	Verantwoordelijkheid
Vereiste 1.1	Stel firewall- en routerconfiguratiestandaarden in en implementeer deze.
Vereiste 1.2	Bouw firewall- en routerconfiguraties waarmee verbindingen tussen niet-vertrouwde netwerken en eventuele systeemonderdelen in de gegevensomgeving van de kaarthouder worden beperkt.
Vereiste 1.3	Verbied directe openbare toegang tussen internet en elk systeemonderdeel in de gegevensomgeving van de kaarthouder.
Vereiste 1.4	Installeer persoonlijke firewallsoftware of equivalente functionaliteit op draagbare computerapparaten (inclusief bedrijf en/of werknemer) die verbinding maken met internet wanneer ze zich buiten het netwerk bevinden (bijvoorbeeld laptops die door werknemers worden gebruikt) en die ook worden gebruikt voor toegang tot de CDE.
Vereiste 1,5	Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het beheren van firewalls worden gedocumenteerd, gebruikt en bekend zijn bij alle betrokken partijen.

Vereiste 1.1

Stel firewall- en routerconfiguratiestandaarden vast en implementeer deze met het volgende:

Vereiste 1.1.1

Een formeel proces voor het goedkeuren en testen van alle netwerkverbindingen en wijzigingen in de firewall- en routerconfiguraties.

Uw verantwoordelijkheden

Implementeer geen configuraties handmatig, zoals met behulp van Azure Portal of de Azure CLI rechtstreeks. We raden u aan Infrastructure as Code (IaC) te gebruiken. Met IaC wordt de infrastructuur beheerd via een beschrijvend model dat gebruikmaakt van een versiebeheersysteem. Het IaC-model genereert elke keer dat het wordt toegepast dezelfde omgeving. Veelvoorkomende voorbeelden van IaC zijn Azure Resource Manager of Terraform. Als IaC geen optie is, moet u een goed gedocumenteerd proces hebben voor het bijhouden, implementeren en veilig implementeren van wijzigingen in firewallregels. Meer informatie vindt u als onderdeel van vereiste 11.2.

U moet een combinatie van verschillende netwerkbesturingselementen gebruiken, waaronder Azure Firewall, netwerkbeveiligingsgroepen (NSG's) en de Kubernetes-resource NetworkPolicy .

Minimaliseer het aantal personen dat netwerkbesturingselementen kan openen en wijzigen. Definieer rollen en duidelijke verantwoordelijkheden voor teams. Het netwerkteam van een organisatie valideert bijvoorbeeld de wijzigingen volgens het governancebeleid dat door IT-teams is ingesteld. Een gated goedkeuringsproces hebben waarbij personen en processen betrokken zijn om wijzigingen in een netwerkconfiguratie goed te keuren. Het proces moet een stap bevatten voor het testen van alle netwerkbesturingselementen. Gedetailleerde documentatie over het proces.

Vereiste 1.1.2

Huidig netwerkdiagram dat alle verbindingen identificeert tussen de gegevensomgeving van de kaarthouder en andere netwerken, met inbegrip van draadloze netwerken

Uw verantwoordelijkheden

Onderhoud als onderdeel van uw documentatie een netwerkstroomdiagram met daarin het binnenkomende en uitgaande verkeer met beveiligingscontroles. Dit omvat de verkeersstroom van andere netwerken, waaronder elk draadloos netwerk naar de CDE. In het diagram moeten ook stromen in het cluster worden weergegeven. Er zijn enkele specifieke vereisten voor diagrammen, ze moeten de inbraaksensoren weergeven. De besturingselementen voor

In deze afbeelding ziet u het netwerkdiagram van de referentie-implementatie.

Download een Visio-bestand van dit diagram.

Afbeelding 1.1.2 - Netwerkstroom

De beschrijving van deze stroom vindt u in de volgende secties.

U kunt de topologie van een virtueel Azure-netwerk bekijken als u Azure Network Watcher hebt. U kunt alle resources in een virtueel netwerk, de resources die zijn gekoppeld aan resources in een virtueel netwerk en de relaties tussen de resources weergeven.

Vereiste 1.1.3

Huidig diagram waarin alle gegevens van de kaarthouder in systemen en netwerken worden weergegeven.

Uw verantwoordelijkheden

Neem als onderdeel van uw documentatie een gegevensstroomdiagram op dat laat zien hoe gegevens in rust en in transit worden beveiligd.

In het diagram ziet u hoe gegevens stromen van en naar de workload en welke informatie van de ene resource naar de andere wordt doorgegeven. Zorg ervoor dat het diagram actueel blijft. Voeg een stap toe als onderdeel van het wijzigingsbeheerproces om het gegevensstroomdiagram bij te werken.

Omdat deze architectuur is gericht op de infrastructuur en niet op de workload, hebben we hier illustraties weggelaten.

Vereiste 1.1.4

Vereisten voor een firewall bij elke internetverbinding en tussen elke gedemilitariseerde zone (DMZ) en de interne netwerkzone.

Uw verantwoordelijkheden

Een duidelijke definitie hebben van wat de grens van een DMZ definieert. De gegevensomgeving van de kaarthouder (CDE) bevindt zich bijvoorbeeld binnen een DMZ die wordt beveiligd door firewall, netwerkbeleid en andere besturingselementen. Zie Cloud DMZ voor meer informatie.

Voor een PCI DSS-infrastructuur bent u verantwoordelijk voor het beveiligen van de CDE met behulp van netwerkbesturingselementen om onbevoegde toegang tot en van het netwerk met de CDE te blokkeren. Netwerkcontroles moeten correct worden geconfigureerd voor een sterke beveiligingspostuur en ze moeten worden toegepast op:

• Communicatie tussen de onderdelen in het cluster met een puntkomma.
• Communicatie tussen de workload en andere onderdelen in vertrouwde netwerken.
• Communicatie tussen de workload en het openbare internet.

Deze architectuur maakt gebruik van verschillende firewalltechnologieën om verkeer in beide richtingen te inspecteren, van en naar het cluster dat als host fungeert voor de CDE:

• Azure-toepassing Gateway Integrated Web Application Firewall (WAF) wordt gebruikt als de verkeersrouter en voor het beveiligen van inkomend (inkomend) verkeer naar het cluster.

• Azure Firewall wordt gebruikt om al het uitgaande (uitgaande) verkeer van elk netwerk en de bijbehorende subnetten te beveiligen.

  Als onderdeel van het verwerken van transactie- of beheerbewerkingen moet het cluster communiceren met externe entiteiten. Het cluster vereist bijvoorbeeld communicatie met het AKS-besturingsvlak, het ophalen van Windows- en pakketupdates en de interactie van de workload met externe API's. Sommige van deze interacties kunnen via HTTP zijn en moeten worden beschouwd als aanvalsvectoren. Deze vectoren zijn doelen voor een man-in-the-middle-aanval die kan leiden tot gegevensexfiltratie. Als u een firewall toevoegt aan uitgaand verkeer, wordt deze bedreiging beperkt.

  Het is raadzaam om zelfs pod-to-pod-communicatie tls-versleuteld te laten zijn. Deze praktijk wordt weergegeven in de referentie-implementatie met behulp van een mTLS-mesh.

• NSG's worden toegevoegd om verkeer tussen het cluster en andere onderdelen binnen de infrastructuur te beveiligen. In de referentie-implementatie zijn er bijvoorbeeld NSG's in het subnet met knooppuntgroepen die SSH-toegangspogingen blokkeren. Alleen verkeer van het virtuele netwerk is toegestaan.

  Wanneer u onderdelen aan de architectuur toevoegt, kunt u overwegen om meer NSG's toe te voegen die verkeerstypen toestaan of weigeren op subnetgrenzen. Omdat elke knooppuntgroep zich in een toegewezen subnet bevindt, past u specifiekere regels toe op basis van verwachte verkeerspatronen van uw workload.

• Kubernetes NetworkPolicy

  Standaard gelden er geen beperkingen voor pod-naar-pod-communicatie. U moet van toepassing zijn NetworkPolicy op communicatie in het cluster, te beginnen met een netwerk zonder vertrouwen en indien nodig paden openen. De referentie-implementatie demonstreert netwerken zonder vertrouwen in de a0005-i en a0005-o naamruimten. Alle naamruimten (met uitzondering kube-systemvan, gatekeeper-systemen andere door AKS geleverde naamruimten) zijn beperkt NetworkPolicy toegepast. De beleidsdefinitie is afhankelijk van de pods die in deze naamruimten worden uitgevoerd. Zorg ervoor dat u paden opent voor gereedheid, levendigheid en opstarttests. Open ook het pad zodat oms-agent metrische gegevens op knooppuntniveau kunnen worden verzonden. Overweeg poorten te standaardiseren voor de workloads, zodat u een consistent NetworkPolicy en Azure Policy kunt bieden voor de toegestane containerpoorten.

Vereiste 1.1.5

Beschrijving van groepen, rollen en verantwoordelijkheden voor het beheer van netwerkonderdelen.

Uw verantwoordelijkheden

U moet besturingselementen opgeven voor de netwerkstromen en de betrokken onderdelen. De resulterende infrastructuur heeft verschillende netwerksegmenten, elk met veel besturingselementen en elk besturingselement met een doel. Zorg ervoor dat uw documentatie niet alleen de volledige dekking heeft van netwerkplanning tot alle configuraties, maar ook over de details van het eigendom. Zorg voor duidelijke regels verantwoordelijkheid en de rollen die verantwoordelijk zijn voor hen.

Weet bijvoorbeeld wie verantwoordelijk is voor het beheer van het beveiligen van het netwerk tussen Azure en internet. In een onderneming is het IT-team verantwoordelijk voor de configuratie en het onderhoud van Azure Firewall-regels, Web Application Firewall (WAF), NSG's en ander verkeer tussen netwerken. Ze kunnen ook verantwoordelijk zijn voor de toewijzing van virtuele netwerken en subnetten in de hele onderneming en ip-adresplanning.

Op workloadniveau is een clusteroperator verantwoordelijk voor het onderhouden van Zero Trust via netwerkbeleid. Daarnaast kunnen verantwoordelijkheden communicatie omvatten met het Azure-besturingsvlak, Kubernetes-API's en bewakingstechnologieën.

Begin altijd met een strategie voor alles weigeren. Geef alleen toestemming als er een zakelijke behoefte of een reden voor een rol is.

Vereiste 1.1.6

Documentatie van zakelijke redenen en goedkeuring voor het gebruik van alle services, protocollen en poorten die zijn toegestaan, inclusief documentatie over beveiligingsfuncties die zijn geïmplementeerd voor deze protocollen die als onveilig worden beschouwd.

Uw verantwoordelijkheden

Gedetailleerde documentatie over de services, protocollen en poorten die worden gebruikt in de netwerkbesturingselementen. Alles weigeren, met uitzondering van expliciet toegestane poorten. Documenteer zakelijke redenen en gedocumenteerde beveiligingsfuncties als het gebruik van onveilige protocollen niet kan worden vermeden. Hier volgen enkele voorbeelden van de referentie-implementatie voor Azure Firewall. Firewallregels moeten uitsluitend worden afgestemd op hun gerelateerde resources. Dat wil gezegd: alleen verkeer van specifieke bronnen mag naar specifieke FQDN-doelen gaan. Hier volgen enkele gevallen om verkeer toe te staan.

Regel	Protocol:Poort	Bron	Doel	Uitvulling
Veilige communicatie tussen de knooppunten en het besturingsvlak toestaan.	HTTPS:443	Geautoriseerde IP-adresbereiken die zijn toegewezen aan de clusterknooppuntgroepen	Lijst met FQDN-doelen in het AKS-besturingsvlak. Dit wordt opgegeven met de AzureKubernetesService FQDN-tag.	De knooppunten hebben toegang nodig tot het besturingsvlak voor beheerhulpprogramma's, status- en configuratiegegevens en informatie over welke knooppunten kunnen worden geschaald.
Veilige communicatie tussen Flux en GitHub toestaan.	HTTPS:443	AKS-knooppuntgroepen	github.com, api.github.com	Flux is een integratie van derden die wordt uitgevoerd op de knooppunten. De clusterconfiguratie wordt gesynchroniseerd met een persoonlijke GitHub-opslagplaats.

Vereiste 1.1.7

Vereiste om firewall- en routerregelsets ten minste om de zes maanden te controleren.

Uw verantwoordelijkheden

Laat ten minste om de zes maanden processen uitvoeren om de netwerkconfiguraties en de scoped regels te controleren. Zo zorgt u ervoor dat de beveiligingsgaranties actueel en geldig zijn. Controleer de volgende configuraties:

• Azure Firewall-regels.
• NSG-regels.
• Azure-toepassing Gateway- en WAF-regels.
• Systeemeigen Kubernetes-netwerkbeleid.
• Firewallbesturingselementen voor de toepasselijke Azure-resources. Deze architectuur maakt bijvoorbeeld gebruik van een regel in Azure Container Registry die alleen verkeer vanaf een privé-eindpunt toestaat.
• Alle andere netwerkbesturingselementen die u aan de architectuur hebt toegevoegd.

Vereiste 1.2

Bouw firewall- en routerconfiguraties waarmee verbindingen tussen niet-vertrouwde netwerken en eventuele systeemonderdelen in de gegevensomgeving van de kaarthouder worden beperkt.

Uw verantwoordelijkheden

In deze architectuur is het AKS-cluster een belangrijk onderdeel van de CDE (CardHolder Data Environment). We raden u ten zeerste aan om het cluster als een privécluster te implementeren voor verbeterde beveiliging. In een privécluster is netwerkverkeer tussen de door AKS beheerde Kubernetes API-server en uw knooppuntgroepen privé. De API-server wordt weergegeven via een privé-eindpunt in het netwerk van het cluster.

U kunt ook een openbaar cluster kiezen, maar dit ontwerp wordt echter niet aanbevolen voor clusters met gereguleerde workloads. De API-server wordt blootgesteld aan internet. De DNS-record kan altijd worden gedetecteerd. U moet dus besturingselementen hebben om de cluster-API beveiligd te houden tegen openbare toegang. Als het gebruik van een openbaar cluster vereist is, is het raadzaam om strikte besturingselementen te hebben via op rollen gebaseerd toegangsbeheer (RBAC) van Kubernetes, gekoppeld aan de functie geautoriseerde IP-adresbereiken van AKS om te beperken wie toegang heeft tot de AKS-API-server. Deze oplossing wordt echter niet aanbevolen voor clusters met gereguleerde workloads.

Bij het verwerken van kaarthoudergegevens (CHD) moet het cluster communiceren met netwerken die worden beschouwd als vertrouwd en niet-vertrouwd. In deze architectuur worden beide hub-spoke-netwerken binnen de perimeter van de PCI-DSS 3.2.1-workload beschouwd als vertrouwde netwerken.

Niet-vertrouwde netwerken zijn netwerken buiten die perimeter. Deze categorie omvat de andere hubs en spokes die zich mogelijk in dezelfde infrastructuur bevinden, maar zich buiten de perimeter van de werkbelasting, het openbare internet, het bedrijfsnetwerk of virtuele netwerken in Azure of een ander cloudplatform bevinden. In deze architectuur is het virtuele netwerk dat als host fungeert voor de opbouwfunctie voor installatiekopieën niet vertrouwd omdat het geen rol speelt bij chD-verwerking. De interactie van de CDE met dergelijke netwerken moet worden beveiligd volgens de vereisten. Met dit privécluster kunt u Azure Virtual Network, een NSG en andere ingebouwde functies gebruiken om de hele omgeving te beveiligen.

Zie Een privé-Azure Kubernetes Service-cluster maken voor meer informatie over privéclusters.

Vereiste 1.2.1

Beperk inkomend en uitgaand verkeer tot het verkeer dat nodig is voor de gegevensomgeving van de kaarthouder en wijs al het andere verkeer specifiek af.

Uw verantwoordelijkheden

Azure Virtual Network kan standaard niet rechtstreeks worden bereikt via het openbare internet. Al het binnenkomende (of inkomend) verkeer moet een tussenliggende verkeersrouter doorlopen. Alle onderdelen in het netwerk kunnen echter openbare eindpunten bereiken. Dat uitgaande (of uitgaande) verkeer moet expliciet worden beveiligd, zodat alleen beveiligde coderingen en TLS 1.2 of hoger zijn toegestaan.

• Azure-toepassing Gateway geïntegreerd WAF onderschept al het VERKEER dat via HTTP(S) binnenkomend verkeer en routeert geïnspecteerd verkeer naar het cluster.

  Dit verkeer kan afkomstig zijn van vertrouwde of niet-vertrouwde netwerken. Application Gateway wordt ingericht in een subnet van het spoke-netwerk en beveiligd door een NSG. Wanneer verkeer binnenkomt, worden WAF-regels toegestaan of geweigerd en wordt verkeer doorgestuurd naar de geconfigureerde back-end. Application Gateway beveiligt de CDE bijvoorbeeld door dit type verkeer te weigeren:

  • Al het verkeer dat niet tls-versleuteld is.
  • Verkeer buiten het poortbereik voor communicatie van het besturingsvlak vanuit de Azure-infrastructuur.
  • Statustests die worden verzonden door andere entiteiten dan de interne load balancer in het cluster.

• Azure Firewall wordt gebruikt om al het uitgaande (uitgaande) verkeer van vertrouwde en niet-vertrouwde netwerken te beveiligen.

  Azure Firewall wordt ingericht in een subnet van het hubnetwerk. Als u Azure Firewall wilt afdwingen als één uitgaand punt, worden door de gebruiker gedefinieerde routes (UDR's) gebruikt voor subnetten die uitgaand verkeer kunnen genereren. Dit omvat subnetten in niet-vertrouwde netwerken, zoals het virtuele netwerk van de opbouwfunctie voor installatiekopieën. Nadat het verkeer Azure Firewall heeft bereikt, worden verschillende regels binnen het bereik toegepast waarmee verkeer van specifieke bronnen naar specifieke doelen kan gaan.

  Zie Azure Firewall gebruiken om AKS-implementaties (Azure Kubernetes Service) te beveiligen voor meer informatie.

• Optioneel is het mogelijk om een HTTP-proxy te gebruiken voor het bewaken en beveiligen van uitgaand (uitgaand) verkeer, van het cluster naar externe resources.

  Naast een firewall willen sommige organisaties mogelijk een HTTP-proxy gebruiken om extra besturingselementen voor uitgaand verkeer te hebben. U wordt aangeraden nog steeds de door de gebruiker gedefinieerde routes naar de firewall te laten gaan en uitgaand verkeer te beperken om alleen naar de HTTP-proxy te gaan. Als een pod met deze instelling de proxy probeert te overschrijven, kan de firewall het uitgaand verkeer nog steeds blokkeren.

  Zie http-proxyondersteuning in Azure Kubernetes Service voor meer informatie.

Het cluster heeft mogelijk toegang nodig tot andere services via het openbare internet. Als u een antimalwaresoftware van derden gebruikt, moeten de virusdefinities van een server via het openbare internet worden opgehaald.

Interacties met eindpunten van andere Azure-services bevinden zich boven de Azure-backbone. Als onderdeel van de reguliere bewerkingen moet het cluster bijvoorbeeld certificaten ophalen uit het beheerde sleutelarchief, installatiekopieën ophalen uit een containerregister, enzovoort. Zorg ervoor dat deze interacties privé en veilig zijn met behulp van Azure Private Link.

Naast firewallregels en particuliere netwerken worden NSG-stromen ook beveiligd via regels. Hier volgen enkele voorbeelden van deze architectuur waarbij de CDE wordt beveiligd door verkeer te weigeren:

• De NSG's op subnetten met knooppuntgroepen weigeren SSH-toegang tot de knooppunten. Zorg ervoor dat er een proces is ingesteld voor just-in-time-toegang, terwijl het principe voor het weigeren van alles nog steeds wordt gehandhaafd.
• De netwerkbeveiligingsgroep, op het subnet met de jumpbox voor het uitvoeren van beheerhulpprogramma's, weigert al het verkeer, met uitzondering van Azure Bastion in het hubnetwerk.
• De NSG's op subnetten met de privé-eindpunten naar Azure Key Vault en Azure Container Registry weigeren al het verkeer, met uitzondering van de interne load balancer en het verkeer via Azure Private Link.

Vereiste 1.2.2

Beveilig en synchroniseer routerconfiguratiebestanden.

Uw verantwoordelijkheden

Een mechanisme hebben om de delta te detecteren tussen de werkelijke geïmplementeerde status en de gewenste status. Infrastructure as Code (IaC) is een uitstekende keuze voor dat doel. Azure Resource Manager-sjablonen hebben bijvoorbeeld een record met de gewenste status.

De implementatieassets, zoals ARM-sjablonen, moeten door de bron worden beheerd, zodat u de geschiedenis van alle wijzigingen hebt. Verzamel informatie uit azure-activiteitenlogboeken, implementatiepijplijnlogboeken en Azure-implementatielogboeken. Deze bronnen helpen u bij het behouden van een spoor van geïmplementeerde assets.

In het cluster moeten netwerkbesturingselementen, zoals Kubernetes-netwerkbeleid, ook de brongestuurde stroom volgen. In deze implementatie wordt Flux gebruikt als de GitOps-operator. Wanneer u een clusterconfiguratie zoals netwerkbeleid synchroniseert, kan uw Git-geschiedenis in combinatie met Flux- en API-logboeken een configuratiegeschiedenisbron zijn.

Vereiste 1.2.3

Installeer perimeterfirewalls tussen alle draadloze netwerken en de gegevensomgeving van de kaarthouder en configureer deze firewalls om te weigeren of, als verkeer nodig is voor zakelijke doeleinden, alleen geautoriseerd verkeer toestaan tussen de draadloze omgeving en de gegevensomgeving van de kaarthouder.

Uw verantwoordelijkheden

De AKS-knooppunten en de knooppuntgroepen mogen niet bereikbaar zijn vanuit draadloze netwerken. Aanvragen naar de Kubernetes-API-server moeten ook worden geweigerd. Toegang tot deze onderdelen is beperkt tot geautoriseerde en beveiligde subnetten.

Over het algemeen beperkt u de toegang van on-premises verkeer naar het spoke-netwerk.

Vereiste 1.3

Verbied directe openbare toegang tussen internet en elk systeemonderdeel in de gegevensomgeving van de kaarthouder.

Uw verantwoordelijkheden

AKS-clusterknooppuntgroepen werken binnen het virtuele netwerk en zijn geïsoleerd van openbare netwerken, zoals internet. Behoud isolatie door te voorkomen dat openbare IP-adressen worden gekoppeld aan clusterknooppunten en door NSG-regels toe te passen op de clustersubnetten om ervoor te zorgen dat internetverkeer wordt geblokkeerd. Zie de sectie DMZ voor meer informatie over gecontroleerde toegang.

Het AKS-cluster heeft systeemknooppuntgroepen die kritieke systeempods hosten. Zelfs in de gebruikersknooppuntgroepen zijn er pods die andere services uitvoeren die deelnemen aan clusterbewerkingen. Pods kunnen bijvoorbeeld Flux uitvoeren om clusterconfiguratie te synchroniseren met een GitHub-opslagplaats of de ingangscontroller om verkeer naar de workloadpods te routeren. Ongeacht het type knooppuntgroep moeten alle knooppunten worden beveiligd.

Een ander essentieel systeemonderdeel is de API-server die wordt gebruikt voor het uitvoeren van systeemeigen Kubernetes-taken, zoals het onderhouden van de status van het cluster en de configuratie. Een voordeel van het gebruik van een privécluster is dat het API-servereindpunt niet standaard wordt weergegeven. Zie Een privé-Azure Kubernetes Service-cluster maken voor meer informatie over privéclusters.

Interacties met andere eindpunten moeten ook worden beveiligd. Eén manier is door communicatie via een particulier netwerk te beperken. Laat het cluster bijvoorbeeld installatiekopieën ophalen uit Azure Container Registry via een privékoppeling.

Vereiste 1.3.1

Implementeer een DMZ om inkomend verkeer te beperken tot alleen systeemonderdelen die geautoriseerde openbaar toegankelijke services, protocollen en poorten bieden.

Uw verantwoordelijkheden

Hier volgen enkele best practices:

• Configureer geen openbare IP-adressen op de knooppunten van de knooppunten.
• Gebruik Azure Policy om ervoor te zorgen dat Kubernetes geen openbare load balancer beschikbaar maakt. Verkeer binnen het cluster moet worden gerouteerd via interne load balancers.
• Alleen interne load balancers beschikbaar maken voor Azure-toepassing Gateway geïntegreerd met WAF.
• Alle netwerkbesturingselementen moeten waar van toepassing bron-, doel-, poort- en protocolbeperkingen opgeven.
• Maak de API-server niet beschikbaar op internet. Wanneer u het cluster uitvoert in de privémodus, wordt het eindpunt niet weergegeven en wordt de communicatie tussen de knooppuntgroepen en de API-server via een particulier netwerk uitgevoerd.

Gebruikers kunnen een perimeternetwerk implementeren om AKS-clusters te beveiligen. Zie Cloud DMZ voor meer informatie.

Vereiste 1.3.2

Beperk inkomend internetverkeer naar IP-adressen binnen de DMZ.

Uw verantwoordelijkheden

Zorg in het clusternetwerk voor een NSG in het subnet met de interne load balancer. Configureer regels om alleen verkeer te accepteren van subnet dat Azure-toepassing Gateway heeft geïntegreerd met WAF. Gebruik Kubernetes NetworkPolicies in het AKS-cluster om inkomend verkeer naar de pods te beperken.

Vereiste 1.3.3

Implementeer anti-adresvervalsingsmaatregelen om vervalste bron-IP-adressen in het netwerk te detecteren en te blokkeren.

Azure-verantwoordelijkheden

Azure implementeert netwerkfilters om vervalst verkeer te voorkomen en binnenkomend en uitgaand verkeer te beperken tot vertrouwde platformonderdelen.

Vereiste 1.3.4

Sta niet toe dat niet-geautoriseerd uitgaand verkeer van de gegevensomgeving van de kaarthouder naar internet wordt verzonden.

Uw verantwoordelijkheden

Hier volgen manieren waarop u niet-geautoriseerd uitgaand verkeer kunt blokkeren:

• Dwing al het uitgaande (uitgaande) verkeer van het AKS-cluster af om via Azure Firewall te gaan met behulp van door de gebruiker gedefinieerde routes (UDR's) op alle clustersubnetten. Dit omvat subnetten met systeem- en gebruikersknooppuntgroepen.
• Beperk uitgaand verkeer door NSG's toe te voegen aan subnetten met knooppuntgroepen.
• Gebruik Kubernetes NetworkPolicies om uitgaand verkeer van de pods te beperken.
• Gebruik een service-mesh om aanvullende beleidsregels af te handelen. Als u bijvoorbeeld alleen TLS-versleuteld verkeer tussen pods toestaat, kan de service-mesh-proxy de TLS-verificatie verwerken. Dit voorbeeld wordt in deze implementatie gedemonstreerd. Envoy wordt geïmplementeerd als de proxy.
• Voorkomen dat openbare IP-adressen aan de netwerken in de CDE worden opgeslagen, tenzij subnetten expliciet zijn geautoriseerd, zoals de firewallsubnetten.
• Gebruik een HTTP-proxy, naast Azure Firewall, om uitgaand (uitgaand) verkeer van het AKS-cluster naar internet te beperken.
• Gebruik Azure Monitor Private Link Service (AMPLS) om logboeken van Container Insights te laten verzenden via een beveiligde, privéverbinding met Azure Monitor. Inzicht in de impact van het inschakelen van AMPLS.

Zie Uitgaand verkeer beheren voor clusterknooppunten in Azure Kubernetes Service (AKS) voor meer informatie.

Vereiste 1.3.5

Alleen tot stand gebrachte verbindingen in het netwerk toestaan.

Azure-verantwoordelijkheden

Azure implementeert netwerkfilters om vervalst verkeer te voorkomen en binnenkomend en uitgaand verkeer te beperken tot vertrouwde platformonderdelen. Het Azure-netwerk wordt gescheiden om klantverkeer te scheiden van beheerverkeer.

Vereiste 1.3.6

Plaats systeemonderdelen die gegevens van de kaarthouder (zoals een database) opslaan in een interne netwerkzone, gescheiden van de DMZ en andere niet-vertrouwde netwerken.

Uw verantwoordelijkheden

Stel uw opslagsystemen alleen beschikbaar via een particulier netwerk, bijvoorbeeld met behulp van Private Link. Beperk ook de toegang van de subnetten van de knooppuntgroep waarvoor dit is vereist. Houd de status buiten het cluster en in een eigen toegewezen beveiligingszone.

Vereiste 1.3.7

Geef geen privé-IP-adressen en routeringsgegevens door aan onbevoegde partijen.

Uw verantwoordelijkheden

Om aan deze vereiste te voldoen, is een openbaar AKS-cluster geen optie. Een privécluster bewaart DNS-records van het openbare internet met behulp van een privé-DNS-zone. Het is echter nog steeds mogelijk om een privé-AKS-cluster te maken met een openbaar DNS-adres. Daarom is het raadzaam deze functie expliciet uit te schakelen door deze instelling in te stellen enablePrivateClusterPublicFQDN om openbaarmaking van het privé-IP-adres van uw besturingsvlak te false voorkomen. Overweeg azure Policy te gebruiken om het gebruik van privéclusters zonder openbare DNS-records af te dwingen.

Gebruik ook een privé-DNS-zone voor routering tussen het subnet waarop Azure-toepassing Gateway is geïntegreerd met WAF en het subnet met de interne load balancer. Zorg ervoor dat geen HTTP-antwoorden privé-IP-gegevens bevatten in de headers of hoofdtekst. Zorg ervoor dat logboeken die MOGELIJK IP- en DNS-records bevatten, niet worden weergegeven buiten operationele behoeften.

Een Azure-service die is verbonden via Private Link heeft geen openbare DNS-record die uw IP-adressen weergeeft. Uw infrastructuur moet optimaal gebruikmaken van Private Link.

Vereiste 1.4

Installeer persoonlijke firewallsoftware of equivalente functionaliteit op draagbare computingapparaten die verbinding maken met internet wanneer ze zich buiten het netwerk bevinden en die ook worden gebruikt voor toegang tot de CDE.

Uw verantwoordelijkheden

Het privécluster wordt beheerd door het AKS-besturingsvlak. U hebt geen rechtstreeks toegang tot knooppunten. Voor het uitvoeren van beheertaken moet u beheerhulpprogramma's zoals kubectl gebruiken vanuit een afzonderlijke rekenresource. Een optie is om een air-gapped jump box te gebruiken waar u de opdrachten kunt uitvoeren. Ook moet binnenkomend en uitgaand verkeer van de jumpbox worden beperkt en beveiligd. Als VPN wordt gebruikt voor toegang, moet u ervoor zorgen dat de clientcomputer wordt beheerd door bedrijfsbeleid en dat alle beleidsregels voor voorwaardelijke toegang aanwezig zijn.

In deze architectuur bevindt die jumpbox zich in een afzonderlijk subnet in het spoke-netwerk. Binnenkomende toegang tot de jumpbox wordt beperkt met behulp van een NSG die alleen toegang via Azure Bastion via SSH toestaat.

Als u bepaalde opdrachten in de jumpbox wilt uitvoeren, moet u openbare eindpunten bereiken. Bijvoorbeeld eindpunten die worden beheerd door het Azure-beheervlak. Dat uitgaande verkeer moet veilig zijn. Net als bij andere onderdelen in het spoke-netwerk wordt uitgaand verkeer van de jumpbox beperkt met behulp van een UDR waarmee HTTPs-verkeer via Azure Firewall wordt gedwongen.

Vereiste 1,5

Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het beheren van firewalls worden gedocumenteerd, gebruikt en bekend zijn bij alle betrokken partijen.

Uw verantwoordelijkheden

Het is essentieel dat u grondige documentatie over het proces en beleid onderhoudt. Dit geldt met name wanneer u Azure Firewall-regels beheert die het AKS-cluster segmenteren. Mensen operationele gereguleerde omgevingen moeten worden opgeleid, geïnformeerd en geïncentiveerd om de beveiligingsgaranties te ondersteunen. Dit is met name belangrijk voor personen met accounts die brede beheerdersbevoegdheden krijgen.

Vereiste 2: gebruik geen door de leverancier geleverde standaardwaarden voor systeemwachtwoorden en andere beveiligingsparameters.

Uw verantwoordelijkheden

Vereiste	Verantwoordelijkheid
Vereiste 2.1	Wijzig altijd de door de leverancier geleverde standaardinstellingen en verwijder of schakel overbodige standaardaccounts uit voordat u een systeem op het netwerk installeert.
Vereiste 2.2	Ontwikkel configuratiestandaarden voor alle systeemonderdelen. Verzeker u ervan dat deze standaarden alle bekende beveiligingsproblemen aanpakken en consistent zijn met door de branche geaccepteerde systeembeveiligingsstandaarden.
Vereiste 2.3	Versleutel alle niet-consolebeheerderstoegang met behulp van sterke cryptografie.
Vereiste 2.4	Onderhoud een inventaris van systeemonderdelen die binnen het bereik van PCI DSS vallen.
Vereiste 2.5	Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het beheren van de standaardinstellingen van leveranciers en andere beveiligingsparameters worden gedocumenteerd, gebruikt en bekend bij alle betrokken partijen.
Vereiste 2.6	Gedeelde hostingproviders moeten de gehoste omgeving en gegevens van de kaarthouder van elke entiteit beveiligen.

Gebruik geen door de leverancier geleverde standaardwaarden voor systeemwachtwoorden en andere beveiligingsparameters

Vereiste 2.1

Wijzig altijd de door de leverancier geleverde standaardinstellingen en verwijder of schakel overbodige standaardaccounts uit voordat u een systeem op het netwerk installeert.

Uw verantwoordelijkheden

De standaardinstellingen van leveranciers moeten worden gewijzigd. Standaardinstellingen zijn algemene aanvalsvectoren en maken het systeem gevoelig voor aanvallen. Hier volgen enkele overwegingen:

• Beheerderstoegang in het containerregister uitschakelen.
• Zorg ervoor dat jump boxes en buildagents de procedures voor gebruikersbeheer volgen, waardoor de benodigde systeemgebruikers worden verwijderd.
• Genereer of geef geen SSH-sleuteltoegang tot knooppunten voor beheerdersgebruikers. Als er noodtoegang nodig is, gebruikt u het Azure-herstelproces om Just-In-Time-toegang te krijgen.

Azure-verantwoordelijkheden

Microsoft Entra ID heeft wachtwoordbeleidsregels die worden afgedwongen voor de nieuwe wachtwoorden die door gebruikers worden verstrekt. Als u een wachtwoord wijzigt, is validatie van een ouder wachtwoord vereist. Beheer opnieuw instellen van wachtwoorden moet worden gewijzigd na de volgende aanmelding.

Vereiste 2.1.1

Voor draadloze omgevingen die zijn verbonden met de gegevensomgeving van de kaarthouder of het verzenden van gegevens van de kaarthouder, wijzigt u de standaardinstellingen van alle draadloze leveranciers tijdens de installatie, inclusief maar niet beperkt tot standaard draadloze versleutelingssleutels, wachtwoorden en SNMP-communitytekenreeksen.

Uw verantwoordelijkheden

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

Vereiste 2.2

Ontwikkel configuratiestandaarden voor alle systeemonderdelen.

Uw verantwoordelijkheden

Implementeer de aanbevelingen in de Azure-beveiligingsbenchmark. Het biedt één geconsolideerde weergave van Azure-beveiligingsaanbevelingen, met betrekking tot brancheframeworks zoals CIS, NIST, PCI-DSS 3.2.1 en andere. Gebruik Microsoft Defender voor Cloud functies en Azure Policy om te helpen bij te houden op basis van de standaarden. Azure-beveiligingsbenchmark is het standaardinitiatief voor Microsoft Defender voor Cloud. Overweeg om aanvullende geautomatiseerde controles te bouwen in Azure Policy en Azure Tenant Security Solution (AzTS).

Documenteer de gewenste configuratiestatus van alle onderdelen in de CDE, met name voor AKS-knooppunten, jumpbox, buildagents en andere onderdelen die met het cluster communiceren.

Zie De Azure-beveiligingsbenchmark voor meer informatie.

Azure-verantwoordelijkheid

Azure biedt beveiligingsconfiguratiestandaarden die consistent zijn met door de branche geaccepteerde beveiligingsstandaarden. De normen worden ten minste jaarlijks herzien.

Vereiste 2.2.1

Implementeer slechts één primaire functie per server om te voorkomen dat functies waarvoor verschillende beveiligingsniveaus zijn vereist, naast elkaar op dezelfde server aanwezig zijn. (Webservers, databaseservers en DNS moeten bijvoorbeeld worden geïmplementeerd op afzonderlijke servers.)

Uw verantwoordelijkheden

De belangrijkste strategie is om het vereiste segmentatieniveau te bieden. Een manier is om onderdelen binnen het bereik en buiten het bereik te implementeren in afzonderlijke clusters. Begrijp dat dit leidt tot hogere kosten voor de toegevoegde infrastructuur en de onderhoudsoverhead. Een andere benadering is om alle onderdelen in een gedeeld cluster te zoeken. Gebruik segmentatiestrategieën om de scheiding te behouden. U kunt bijvoorbeeld afzonderlijke knooppuntgroepen binnen een cluster hebben.

In de referentie-implementatie wordt de tweede benadering gedemonstreerd met een microservicestoepassing die is geïmplementeerd in één cluster. De toepassing heeft twee sets services: de ene set heeft pods binnen het bereik en de andere is buiten het bereik. Beide sets worden verdeeld over twee gebruikersknooppuntgroepen. Met het gebruik van Kubernetes-taints worden binnen- en buitenbereikpods geïmplementeerd in afzonderlijke knooppuntgroepen en delen ze nooit een knooppunt-VM.

Voor containertechnologieën wordt deze segmentatie standaard geleverd omdat slechts één exemplaar van een container verantwoordelijk is voor één functie in het systeem.

De workload moet een door pod beheerde identiteit gebruiken. Het mag geen identiteit op cluster- of knooppuntniveau overnemen.

Gebruik waar mogelijk externe opslag in plaats van opslag op het knooppunt (in het cluster). Houd clusterpods exclusief gereserveerd voor werk dat moet worden uitgevoerd als onderdeel van de werking van de gegevensverwerking van de kaarthouder. Verplaats de buiten bereikbewerkingen buiten het cluster. Deze richtlijnen zijn van toepassing op het bouwen van agents, niet-gerelateerde workloads of activiteiten, zoals het hebben van een jumpbox in het cluster.

Vereiste 2.2.2

Schakel alleen benodigde services, protocollen, daemons, enzovoort in, zoals vereist voor de functie van het systeem.

Uw verantwoordelijkheden

Bekijk de functies en de implicaties voordat u ze inschakelt. Standaardinstellingen bevatten mogelijk functies die u niet nodig hebt en die functies hebben mogelijk inzicht in de workload nodig. Een voorbeeld hiervan zijn de coderingen in het standaard SSL-beleid voor Azure-toepassing Gateway. Controleer of het beleid te ruim is. De aanbeveling is om een aangepast beleid te maken door alleen de coderingen te selecteren die u nodig hebt.

Verwijder alle overbodige systeemservices uit de installatiekopieën (bijvoorbeeld jumpboxs en buildagents) voor onderdelen waar u de volledige controle over hebt.

Documenteer wat Azure op de knooppunten installeert voor onderdelen waarvoor u alleen zichtbaarheid hebt, zoals AKS-knooppunten. DaemonSets Overweeg om aanvullende controle te bieden die nodig is voor deze cloudgestuurde onderdelen.

Vereiste 2.2.3

Implementeer aanvullende beveiligingsfuncties voor alle vereiste services, protocollen of daemons die als onveilig worden beschouwd.

Uw verantwoordelijkheden

Application Gateway heeft een geïntegreerde WAF en onderhandelt over de TLS-handshake voor de aanvraag die naar het openbare eindpunt is verzonden, zodat alleen veilige coderingen worden toegestaan. De referentie-implementatie ondersteunt alleen TLS 1.2 en goedgekeurde coderingen.

Stel dat u een verouderd apparaat hebt dat via Azure-toepassing Gateway moet communiceren met de CDE. Hiervoor moet Application Gateway een onveilig protocol inschakelen. Documenteer die uitzondering en bewaak of dat protocol buiten dat verouderde apparaat wordt gebruikt. Schakel dat protocol onmiddellijk na die verouderde interactie uit.

Application Gateway mag ook niet reageren op aanvragen op poort 80. Voer geen omleidingen uit op toepassingsniveau. Deze referentie-implementatie heeft een NSG-regel die poort 80-verkeer blokkeert. De regel bevindt zich in het subnet met Application Gateway.

Als een workload in uw cluster niet aan het organisatiebeleid voor beveiligingsnalevingsprofielen of andere besturingselementen (bijvoorbeeld limieten en quota) kan voldoen, controleert u of de uitzondering wordt gedocumenteerd. U moet controleren om ervoor te zorgen dat alleen verwachte functionaliteit wordt uitgevoerd.

Vereiste 2.2.4

Configureer systeembeveiligingsparameters om misbruik te voorkomen.

Uw verantwoordelijkheden

Alle Azure-services die in de architectuur worden gebruikt, moeten de aanbevelingen van de Azure-beveiligingsbenchmark volgen. Deze aanbevelingen geven u een beginpunt voor het selecteren van specifieke beveiligingsconfiguratie-instellingen. Vergelijk ook uw configuratie met de basislijn-implementatie voor die service. Zie Beveiligingsbasislijnen voor Azure voor meer informatie over de beveiligingsbasislijnen.

De toegangscontroller open policy-agent werkt in combinatie met Azure Policy om onjuiste configuraties in het cluster te detecteren en te voorkomen. Stel dat er een organisatiebeleid is dat geen openbare IP-toewijzingen op de knooppunten toestaat. Wanneer een dergelijke toewijzing wordt gedetecteerd, wordt deze gemarkeerd voor controle of geweigerd op basis van de actie die is opgegeven in de beleidsdefinitie.

Op infrastructuurniveau kunt u beperkingen toepassen op het type en de configuratie van Azure-resources. Gebruik Azure Policy om deze gevallen te voorkomen. In deze referentie-implementatie is er een beleid dat het maken van AKS-clusters weigert die niet privé zijn.

Zorg er regelmatig voor dat alle uitzonderingen worden gedocumenteerd en gecontroleerd.

Azure-verantwoordelijkheden

Azure zorgt ervoor dat alleen geautoriseerd personeel beveiligingsmaatregelen van het Azure-platform kan configureren met behulp van meervoudige toegangsbeheer en een gedocumenteerde bedrijfsbehoefte.

Vereiste 2.2.5

Verwijder alle overbodige functionaliteit, zoals scripts, stuurprogramma's, functies, subsystemen, bestandssystemen en onnodige webservers.

Uw verantwoordelijkheden

Installeer geen software op jumpboxs of bouwagents die niet deelnemen aan de verwerking van een transactie of waarneembaarheid bieden voor nalevingsvereisten, zoals beveiligingsagenten. Deze aanbeveling is ook van toepassing op de clusterentiteiten, zoals DaemonSet pods. Zorg ervoor dat alle installaties zijn gedetecteerd en geregistreerd.

Vereiste 2.3

Versleutel alle niet-consolebeheerderstoegang met behulp van sterke cryptografie.

Uw verantwoordelijkheden

Alle beheerderstoegang tot het cluster moet worden uitgevoerd met behulp van de console. Maak het besturingsvlak van het cluster niet beschikbaar.

Azure-verantwoordelijkheden

Azure zorgt ervoor dat het gebruik van sterke cryptografie wordt afgedwongen bij het openen van de hypervisorinfrastructuur. Het zorgt ervoor dat klanten die de Microsoft Azure Management Portal gebruiken, toegang hebben tot hun service/IaaS-consoles met sterke cryptografie.

Vereiste 2.4

Onderhoud een inventaris van systeemonderdelen die binnen het bereik van PCI DSS vallen.

Uw verantwoordelijkheden

Alle Azure-resources die in de architectuur worden gebruikt, moeten correct worden gelabeld. De tags helpen bij gegevensclassificatie en geven aan of de service binnen of buiten het bereik valt. Met zorgvuldige tagging kunt u query's uitvoeren op resources, een inventaris bijhouden, kosten bijhouden en waarschuwingen instellen. Onderhoud ook periodiek een momentopname van die documentatie.

Vermijd het taggen van resources binnen het bereik of buiten het bereik op een gedetailleerd niveau. Naarmate de oplossing zich ontwikkelt, kunnen resources buiten het bereik binnen het bereik komen, zelfs als ze indirect communiceren of grenzen aan de gegevens van de kaarthouder. Deze resources zijn onderworpen aan controle en kunnen deel uitmaken van een representatieve steekproef tijdens de controle. Overweeg taggen op een hoger niveau, op abonnements- en clusterniveau.

Zie de handleiding voor beslissingen over namen en taggen van resources voor informatie over overwegingen voor taggen.

Tag in-clusterobjecten door Kubernetes-labels toe te passen. Op deze manier kunt u objecten ordenen, een verzameling objecten selecteren en inventariseren.

Vereiste 2.5

Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het beheren van de standaardinstellingen van leveranciers en andere beveiligingsparameters worden gedocumenteerd, gebruikt en bekend bij alle betrokken partijen.

Uw verantwoordelijkheden

Het is essentieel dat u grondige documentatie over de processen en beleidsregels onderhoudt. Personeel moet worden getraind in de beveiligingsfuncties en configuratie-instellingen van elke Azure-resource. Mensen operationele gereguleerde omgevingen moeten worden opgeleid, geïnformeerd en geïncentiveerd om de beveiligingsgaranties te ondersteunen. Dit is met name belangrijk voor beheerdersaccounts die brede beheerdersbevoegdheden krijgen.

Vereiste 2.6

Gedeelde hostingproviders moeten de gehoste omgeving en gegevens van de kaarthouder van elke entiteit beveiligen.

Uw verantwoordelijkheden

Azure biedt beveiligingsgaranties voor alle gehoste omgevingsonderdelen die worden gedeeld. Het wordt ten zeerste aanbevolen om uw AKS-knooppunten te behandelen als een toegewezen host voor deze workload. Dat wil gezegd: alle berekeningen moeten zich in één tenantmodel bevinden en niet worden gedeeld met andere workloads die u mogelijk gebruikt.

Als volledige rekenisolatie gewenst is op het niveau van de Azure-infrastructuur, kunt u Azure Dedicated Host toevoegen aan een AKS-cluster (Azure Kubernetes Service). Deze aanbieding biedt fysieke servers die zijn toegewezen aan uw workload, zodat u AKS-knooppunten rechtstreeks in deze ingerichte hosts kunt plaatsen. Deze architectuurkeuze heeft aanzienlijke impact op kosten en capaciteitsplanning en is niet gebruikelijk voor de meeste scenario's.

Volgende stappen

Bescherm opgeslagen gegevens van de kaarthouder. Versleutel de overdracht van gegevens van de kaarthouder in open, openbare netwerken.

Verwante resources

• AKS-architectuurontwerp (Azure Kubernetes Service)
• Inleiding van een gereguleerd AKS-cluster voor PCI-DSS 3.2.1 (deel 1 van 9)
• Architectuur van een gereguleerd AKS-cluster voor PCI-DSS 3.2.1 (deel 2 van 9)
• Basislijnarchitectuur voor een AKS-cluster (Azure Kubernetes Service)
• AKS-basislijn voor clusters met meerdere regio's