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

In dit artikel worden de overwegingen beschreven voor een Azure Kubernetes Service-cluster (AKS) dat is geconfigureerd in overeenstemming met de Payment Card Industry Data Security Standard (PCI-DSS 3.2.1).

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 die beveiligde communicatie mogelijk maakt. Netwerkbesturingselementen worden in beide hub-spoke-netwerken geplaatst en volgen het Microsoft zero-trust-model. De besturingselementen kunnen worden afgestemd met de minste bevoegdheden voor het beveiligen van verkeer, zodat toegang op basis van de noodzaak om te weten. Bovendien kunt u verschillende benaderingen voor diepgaande verdediging 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 netwerk constructs, zoals firewallregels. Er zijn ook Kubernetes-eigen constructies die de verkeersstroom in het cluster bepalen, zoals de NetworkPolicy resource. We raden u ten zeerste aan de Kubernetes-documentatie te lezen om inzicht te krijgen in de belangrijkste concepten over geïsoleerde pods en beleidsregels voor in- en uit te voeren gegevens.

Een beveiligd netwerk en beveiligde systemen bouwen en onderhouden

Vereiste 1 — Installeer en onderhoud een firewallconfiguratie om gegevens van kaartaanduidingen te beveiligen.

Ondersteuning voor AKS-functies

AKS ondersteunt het implementeren van een cluster in een particulier virtueel netwerk als een privécluster. Communicatie tussen het cluster en de met AKS beheerde Kubernetes API-server vindt plaats via een vertrouwd netwerk. Met een privécluster kunt u Azure Virtual Network, netwerkbeveiligingsgroep (NSG) en andere ingebouwde netwerkbesturingselementen gebruiken om de volledige gegevensomgeving met kaartaanduidingen (CDE) te beveiligen. Dit verbiedt onbevoegde openbare toegang tussen internet en de omgeving. Zie Een privécluster maken voor meer informatie over het inrichten van Azure Kubernetes Service cluster.

Azure Firewall kunnen worden geïntegreerd met AKS en kunnen uitgaand verkeer van het cluster beperken. Dit is een belangrijk onderdeel van de CDE. De configuratie wordt eenvoudig gemaakt met een AKS FQDN-tag. Het aanbevolen proces wordt gegeven in Use Azure Firewall to protect Azure Kubernetes Service (AKS) Deployments (AKS)-implementaties.

Voor AKS-clusters is openbare internettoegang vereist om het beheerde besturingsvlak te bereiken. Beperk uitgaand verkeer naar internet met Azure Firewall en NSG's in het clustersubnet. Zie Control egress traffic for cluster nodes in Azure Kubernetes Service (AKS) voor meer informatie.

Uw verantwoordelijkheden

Vereiste	Verantwoordelijkheid
Vereiste 1.1	Stel firewall- en routerconfiguratiestandaarden vast en implementeert deze.
Vereiste 1.2	Bouw firewall- en routerconfiguraties die verbindingen tussen niet-vertrouwde netwerken en systeemonderdelen in de gegevensomgeving van de kaarthouder beperken.
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 gelijkwaardige functionaliteit op draagbare computerapparaten (inclusief bedrijfs- en/of werknemers-eigendom) die verbinding maken met internet wanneer ze zich buiten het netwerk bevinden (bijvoorbeeld laptops die worden gebruikt door werknemers) 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, in gebruik zijn en bekend zijn bij alle betrokken partijen.

Vereiste 2 — Gebruik geen standaardinstellingen van de leverancier voor systeemwachtwoorden en andere beveiligingsparameters.

Uw verantwoordelijkheden

Vereiste	Verantwoordelijkheid
Vereiste 2.1	Wijzig altijd de standaardinstellingen van de leverancier en verwijder of schakel onnodige standaardaccounts uit voordat u een systeem op het netwerk installeert.
Vereiste 2.2	Ontwikkel configuratiestandaarden voor alle systeemonderdelen. Zorg ervoor dat deze standaarden alle bekende beveiligingsproblemen aanpakken en consistent zijn met door de industrie geaccepteerde systeembeveiligingsstandaarden.
Vereiste 2.3	Versleutel alle beheerderstoegang buiten de console met behulp van sterke cryptografie.
Vereiste 2.4	Een inventaris onderhouden van systeemonderdelen die binnen het bereik van PCI DSS.
Vereiste 2.5	Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het beheren van standaardinstellingen van de leverancier en andere beveiligingsparameters worden gedocumenteerd, in gebruik zijn en bekend zijn bij alle betrokken partijen.
Vereiste 2.6	Providers van gedeelde hosting moeten de gehoste omgeving en kaartgegevens van elke entiteit beveiligen.

Vereiste 1.1

Stel firewall- en routerconfiguratiestandaarden op die het volgende omvatten:

Vereiste 1.1.1

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

Uw verantwoordelijkheden

Implementeert configuraties niet handmatig, bijvoorbeeld met behulp van de Azure Portal of de Azure CLI rechtstreeks. U wordt aangeraden Infrastructure as Code (IaC) te gebruiken. Met IaC wordt de infrastructuur beheerd via een beschrijvend model dat gebruikmaakt van een versiesysteem. Het IaC-model genereert steeds dezelfde omgeving wanneer het wordt toegepast. 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 firewallregel. Meer informatie wordt gegeven 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 toegang heeft tot netwerkbesturingselementen en deze kan wijzigen. Rollen definiëren en verantwoordelijkheden voor teams duidelijk maken. 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 wijzigingen in een netwerkconfiguratie moeten goedkeuren. 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

Als onderdeel van uw documentatie moet u een netwerkstroomdiagram onderhouden met het binnenkomende en uitgaande verkeer met besturingselementen voor beveiliging. Dit omvat verkeersstromen van andere netwerken, waaronder een draadloos netwerk naar de CDE. In het diagram worden ook stromen in het cluster weergegeven. Er zijn enkele specifieke vereisten voor diagrammen. Deze moeten de inbraaksensoren weergeven. De besturingselementen voor

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

Afbeelding 1.1.2 - Netwerkstroom

De beschrijving van deze stroom staat in de volgende secties.

U kunt de topologie van een virtueel Azure-netwerk weergeven als u Azure-Network Watcher. 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 met alle gegevensstromen van kaartaanduidingen tussen systemen en netwerken.

Uw verantwoordelijkheden

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

In het diagram moet worden weergegeven hoe gegevens van en naar de workload stromen 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 afbeeldingen weggelaten.

Vereiste 1.1.4

Vereisten voor een firewall bij elke internetverbinding en tussen een 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) is bijvoorbeeld binnen een DMZ beveiligd door een 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. Netwerkbesturingselementen moeten correct worden geconfigureerd voor een sterke beveiligingsstatus en moeten worden toegepast op:

• Communicatie tussen de co-locatieonderdelen binnen het cluster.
• 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 te inspecteren dat in beide richtingen stroomt, van en naar het cluster dat als host voor de CDE wordt gebruikt:

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

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

  Als onderdeel van het verwerken van een transactie of beheerbewerkingen, moet het cluster communiceren met externe entiteiten. Het cluster vereist bijvoorbeeld communicatie met het AKS-besturingsvlak, het verkrijgen van Windows en pakketupdates, en de interactie van de werkbelasting 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 gegevens exfiltratie. Door een firewall toe te voegen aan het verkeer dat uit het verkeer komt, wordt die bedreiging beperkt.

  We raden u aan zelfs communicatie tussen pods te versleutelen met TLS. Deze praktijk wordt weergegeven in de referentie-implementatie met het gebruik 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 op 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 meer NSG's toe te voegen die verkeerstypen aan subnetgrenzen toestaan of weigeren. Omdat elke knooppuntgroep zich in een toegewezen subnet, moet u specifiekere regels toepassen op basis van verwachte verkeerspatronen van uw workload.

• Kubernetes NetworkPolicy

  Standaard zijn er geen beperkingen voor pod-naar-pod-communicatie. U moet toepassen op NetworkPolicy communicatie binnen het cluster, beginnend met een zero-trust-netwerk en het openen van paden naar behoefte. De referentie-implementatie demonstreert zero-trust-netwerken in de a0005-i a0005-o naamruimten en . Op alle naamruimten (met uitzondering van , en andere door AKS opgegeven kube-system naamruimten) is een gatekeeper-system beperkende toepassing NetworkPolicy toegepast. De beleidsdefinitie is afhankelijk van de pods die worden uitgevoerd in deze naamruimten. Zorg ervoor dat u paden opent voor gereedheid, actualiteit en opstarttests. Open ook het pad naar zodat metrische gegevens oms-agent op knooppuntniveau kunnen worden verzonden. Overweeg het standaardiseren van poorten voor de workloads, zodat u een consistente en Azure Policy NetworkPolicy voor de toegestane containerpoorten kunt bieden.

Vereiste 1.1.5

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

Uw verantwoordelijkheden

U moet besturingselementen bieden 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 beschikt over de uitgebreide dekking van netwerkplanning tot alle configuraties, maar ook over de details van het eigendom. Zorg voor duidelijke verantwoordelijkheidslijnen en de rollen die hiervoor verantwoordelijk zijn.

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 netwerkverkeer. Ze zijn mogelijk ook verantwoordelijk voor de toewijzing van bedrijfsbrede virtuele netwerken en subnetten, en het plannen van IP-adressen.

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

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

Vereiste 1.1.6

Documentatie over zakelijke redenen en goedkeuring voor het gebruik van alle toegestane services, protocollen en poorten, 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, behalve voor poorten die expliciet zijn toegestaan. Documenteren van zakelijke redenen en gedocumenteerde beveiligingsfuncties als het gebruik van onveilige protocollen niet kan worden vermeden. Hier zijn enkele voorbeelden van de referentie-implementatie voor Azure Firewall. Firewallregels moeten uitsluitend worden beperkt tot de bijbehorende resources. Dat wil zeggen dat alleen verkeer van specifieke bronnen naar specifieke FQDN-doelen mag gaan. Hier zijn enkele gevallen om verkeer toe te staan.

Regel	Protocol:Poort	Bron	Doel	Reden
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 moeten toegang hebben tot het besturingsvlak voor beheerhulpprogramma's, status- en configuratiegegevens en informatie over welke knooppunten kunnen worden geschaald.
Veilige communicatie tussen Flux en GitHub.	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 GitHub privéopslagplaats.

Zie de officiële documentatie voor de Azure-service voor informatie over de vereiste poorten.

Vereiste 1.1.7

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

Uw verantwoordelijkheden

U moet ten minste om de zes maanden processen hebben om de netwerkconfiguraties en de regels binnen het bereik te controleren. Dit zorgt ervoor dat de beveiligingsgaranties actueel en geldig zijn. Controleer de volgende configuraties:

• Azure Firewall regels.
• NSG-regels.
• Azure Application Gateway en WAF-regels.
• Native Kubernetes-netwerkbeleid.
• Firewallbesturingselementen voor de toepasselijke Azure-resources. Deze architectuur maakt bijvoorbeeld gebruik van een regel op Azure Container Registry die alleen verkeer van een privé-eindpunt toestaat.
• Andere netwerkbesturingselementen die u hebt toegevoegd aan de architectuur.

Vereiste 1.2

Bouw firewall- en routerconfiguraties die verbindingen tussen niet-vertrouwde netwerken en systeemonderdelen in de gegevensomgeving van de kaarthouder beperken.

Uw verantwoordelijkheden

In deze architectuur is het AKS-cluster een belangrijk onderdeel van de gegevensomgeving van de kaarthouder (CDE). We raden u ten zeerste aan om het cluster als een privécluster te geïmplementeerd voor verbeterde beveiliging. In een privécluster is het netwerkverkeer tussen de door AKS beheerde Kubernetes API-server en uw knooppuntgroepen privé. De API-server wordt beschikbaar gemaakt via een privé-eindpunt in het netwerk van het cluster.

U kunt ook een openbaar cluster kiezen, maar let op mogelijke uitdagingen met deze optie. De API-server wordt blootgesteld aan internet. De DNS-record kan altijd worden detecteerbaar. U moet dus besturingselementen hebben om de cluster-API te beschermen tegen openbare toegang. Een benadering is het hebben van strenge besturingselementen via op rollen gebaseerd toegangsbesturingselement (RBAC) van Kubernetes, gekoppeld aan de geautoriseerde ip-bereikfunctie van AKS. Deze oplossing wordt echter niet aanbevolen voor clusters met gereguleerde workloads.

Bij het verwerken van gegevens van kaarthouders (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 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, maar zich buiten de workloadperimeter, het openbare internet, het bedrijfsnetwerk of virtuele netwerken in Azure of een ander cloudplatform. In deze architectuur is het virtuele netwerk dat als host voor de opbouwer van de afbeelding wordt gebruikt, 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écluster maken voor meer informatie over Azure Kubernetes Service clusters.

Vereiste 1.2.1

Beperk het binnenkomende en uitgaande verkeer tot wat nodig is voor de gegevensomgeving van de kaarthouder en weiger met name al het andere verkeer.

Uw verantwoordelijkheden

Azure Virtual Network niet rechtstreeks bereikbaar via het openbare internet. Al het binnenkomende (of inkomende) verkeer moet via een tussenliggende verkeersrouter gaan. 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 toe te staan.

• Azure Application Gateway geïntegreerde WAF onderschept al het http(s) verkeer voor toegangsverkeer en routeeert 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. Als er verkeer binnenkomt, worden verkeer door WAF-regels toegestaan of weigeren en wordt verkeer doorgeleid naar de geconfigureerde back-end. De CDE Application Gateway bijvoorbeeld door dit type verkeer te weigeren:

  • Al het verkeer dat niet met TLS is versleuteld.
  • Verkeer buiten het poortbereik voor communicatie tussen besturingsvlak en de Azure-infrastructuur.
  • Statustests aanvragen 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 is ingericht in een subnet van het hubnetwerk. Als u Azure Firewall als één toegangspunt wilt afdwingen, worden door de gebruiker gedefinieerde routes (UDR's) gebruikt op subnetten die het verkeer voor uitverkeer kunnen genereren. Dit omvat subnetten in niet-vertrouwde netwerken, zoals het virtuele netwerk van image builder. Nadat het verkeer de Azure Firewall, worden er verschillende scoped regels toegepast waarmee verkeer van specifieke bronnen naar specifieke doelen kan gaan.

  Zie Use Azure Firewall to protect Azure Kubernetes Service (AKS) Deployments (AKS) voor meer informatie.

Het cluster moet toegang hebben tot andere services via het openbare internet. Als u antimalwaresoftware van derden gebruikt, moet u de virusdefinities van een server via het openbare internet downloaden.

Interacties met eindpunten van andere Azure-services vinden plaats via internet. Zorg ervoor dat deze interacties veilig zijn. Als onderdeel van de normale bewerkingen moet het cluster bijvoorbeeld certificaten uit het beheerde sleutelopslag verkrijgen, afbeeldingen uit een containerregister halen, en meer. U kunt privékoppelingen gebruiken voor andere services, zoals Azure Key Vault en Azure Container Registry, om de voorgaande taken uit te voeren.

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

• De NSG's weigeren op subnetten met knooppuntgroepen SSH-toegang tot de knooppunten. Zorg dat er een proces is voor Just-In-Time-toegang in noodgevallen terwijl u het principe deny-all behoudt.
• De NSG, op het subnet met de jumpbox voor het uitvoeren van beheerhulpprogramma's, Azure Bastion verkeer in het hubnetwerk.
• De NSG's weigeren, op subnetten met de privé-eindpunten voor Azure Key Vault en Azure Container Registry, al het verkeer behalve van de interne load balancer en het verkeer via Azure Private Link.

Vereiste 1.2.2

Routerconfiguratiebestanden beveiligen en synchroniseren.

Uw verantwoordelijkheden

Een mechanisme hebben om de verschillen tussen de werkelijke geïmplementeerde status en de gewenste status te detecteren. Infrastructuur als code (IaC) is een uitstekende keuze voor dat doel. De sjablonen Azure Resource Manager bijvoorbeeld een record van de gewenste status.

De implementatie-assets, 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 volgen van de geïmplementeerde assets.

In het cluster moeten netwerkbesturingselementen zoals Kubernetes-netwerkbeleid ook de door de bron beheerde stroom volgen. In deze implementatie wordt Flux gebruikt als de GitOps-operator. Wanneer u een clusterconfiguratie zoals netwerkbeleid synchronist, kan uw Git-geschiedenis in combinatie met Flux- en API-logboeken een bron van de configuratiegeschiedenis 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 kaartaanduiding.

Uw verantwoordelijkheden

De AKS-knooppunten en de knooppuntgroepen mogen niet bereikbaar zijn via draadloze netwerken. Aanvragen voor 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

Rechtstreekse openbare toegang tussen internet en elk systeemonderdeel in de gegevensomgeving van de kaarthouder verbieden.

Uw verantwoordelijkheden

AKS-clusterknooppuntgroepen werken binnen het virtuele netwerk en zijn geïsoleerd van openbare netwerken zoals internet. Onderhoud isolatie door te voorkomen dat openbare IP's worden verbonden met clusterknooppunten en door NSG-regels toe te passen op de clustersubnetten om ervoor te zorgen dat internetverkeer wordt geblokkeerd. Zie de dmz-sectie voor meer informatie over beheerde toegang.

Het AKS-cluster heeft systeemknooppuntgroepen die als host voor essentiële systeempods worden gebruikt. Zelfs op de gebruikersknooppuntgroepen zijn er pods die andere services uitvoeren die deelnemen aan clusterbewerkingen. Pods kunnen bijvoorbeeld Flux uitvoeren om de clusterconfiguratie te synchroniseren met een GitHub-opslagplaats of de controller voor het verkeer om te gaan naar de workloadpods. Alle knooppunten moeten worden beveiligd, ongeacht het type knooppuntgroep.

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-server-eindpunt niet standaard beschikbaar is. Zie Een privécluster maken voor meer informatie over Azure Kubernetes Service clusters.

Interacties met andere eindpunten moeten ook worden beveiligd. Eén manier is door de communicatie via een particulier netwerk te beperken. U kunt bijvoorbeeld de cluster-pull-afbeeldingen van Azure Container Registry via een privékoppeling.

Vereiste 1.3.1

Implementeert een DMZ om het inkomende 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 knooppuntgroepknooppunten.
• Geen openbare load balancer voor de knooppunten. Verkeer binnen het cluster moet worden gerouteerd via interne load balancers.
• Stel alleen interne load balancers beschikbaar voor Azure Application Gateway geïntegreerd met WAF.
• Alle netwerkbesturingselementen moeten, indien van toepassing, bron-, doel-, poort- en protocolbeperkingen opgeven.
• Maak de API-server niet beschikbaar op internet. Wanneer u het cluster in de privémodus gebruikt, wordt het eindpunt niet beschikbaar gemaakt en vindt de communicatie tussen de knooppuntgroepen en de API-server plaats via een particulier netwerk.

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

Vereiste 1.3.2

Beperk het inkomende internetverkeer tot IP-adressen binnen de DMZ.

Uw verantwoordelijkheden

In het clusternetwerk hebt u een NSG op het subnet met de interne load balancer. Configureer regels om alleen verkeer te accepteren van een subnet Azure Application Gateway is geïntegreerd met WAF. Gebruik kubernetes in het AKS-cluster om het toegangsverkeer tot NetworkPolicies de pods te beperken.

Vereiste 1.3.3

Implementeert anti-adresvervalsings maatregelen om te detecteren en blokkeren dat vervalste bron-IP-adressen het netwerk binnenkomen.

Azure-verantwoordelijkheden

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

Vereiste 1.3.4

Sta niet onbevoegd uitgaand verkeer van de gegevensomgeving van de kaarthouder naar internet toe.

Uw verantwoordelijkheden

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

• Dwing al het uitgaande (uitgaande) verkeer van het AKS-cluster af om via de Azure Firewall. Door de gebruiker gedefinieerde routes (UDR's) hebben op clustersubnetten. Dit omvat subnetten met systeem- en gebruikers-knooppuntgroepen.
• Beperk uitgaand verkeer door NSG's toe te voegen aan subnetten met knooppuntgroepen.
• Gebruik Kubernetes om NetworkPolicies het toegangsverkeer van de pods te beperken.
• Gebruik een service-mesh om aanvullende beleidsregels af te handelen. Als u bijvoorbeeld alleen met TLS versleuteld verkeer tussen pods toestaat, kan de service-mesh-proxy de TLS-verificatie afhandelen. Dit voorbeeld wordt in deze implementatie gedemonstreerd. Envoy wordt geïmplementeerd als de proxy.
• Voorkom dat openbare IP-adressen aan de netwerken binnen de CDE worden toegelaten, tenzij door subnetten die expliciet zijn geautoriseerd, zoals de firewallsubnetten.

AKS vereist enige openbare internettoegang voor toegang tot het door Azure beheerde besturingsvlak. Het cluster wil bijvoorbeeld metrische gegevens en logboeken verzenden naar Azure Monitor. U kunt bereikregels instellen door de bron- en doel-FQDN-doelen of FQDN-tags op te geven. Hoewel het gebruik van tags het eenvoudiger maakt om de regels in te stellen, bevatten sommige tags mogelijk meer doelen dan u nodig hebt, waardoor de regel te ruim is. Controleer de tags om er zeker van te zijn dat deze de juiste doelen heeft die u nodig hebt. Overweeg het gebruik van expliciete regels voor toegevoegd besturingselement. U moet weten dat dit een afweging maakt tussen beheer en complexiteit, waaronder het verwijderen van regels die niet meer nodig zijn.

Zie Control egress traffic for cluster nodes in Azure Kubernetes Service (AKS) voormeer informatie.

Vereiste 1.3.5

Alleen tot stand gebrachte verbindingen met het netwerk toestaan.

Azure-verantwoordelijkheden

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

Vereiste 1.3.6

Systeemonderdelen die kaartgegevens (zoals een database) opslaan in een interne netwerkzone, gescheiden van de DMZ en andere niet-vertrouwde netwerken.

Uw verantwoordelijkheden

Uw opslagsystemen alleen beschikbaar maken via een particulier netwerk, bijvoorbeeld door gebruik te Private Link. Beperk ook de toegang vanaf 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

Maak geen privé-IP-adressen en routeringsgegevens bekend aan niet-geautoriseerde partijen.

Uw verantwoordelijkheden

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

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

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

Vereiste 1.4

Installeer persoonlijke firewallsoftware of gelijkwaardige functionaliteit op draagbare computerapparaten die verbinding maken met internet buiten het netwerk en die ook worden gebruikt voor toegang tot de CDE.

Uw verantwoordelijkheden

Het privécluster wordt beheerd door het AKS-besturingsvlak. U hebt niet 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 jumpbox met een air-gapped te gebruiken, waar u de opdrachten kunt uitvoeren. Ook het inkomende en uitgaande verkeer van de jumpbox moet worden beperkt en beveiligd. Als VPN wordt gebruikt voor toegang, moet u ervoor zorgen dat de clientmachine wordt beheerd door het bedrijfsbeleid en dat alle beleidsregels voor voorwaardelijke toegang zijn toegepast.

In deze architectuur is die jump box in een afzonderlijk subnet in het spoke-netwerk. Binnenkomende toegang tot de jump box wordt beperkt door gebruik te maken van een NSG die alleen toegang via Azure Bastion via SSH toestaat.

Als u bepaalde opdrachten wilt uitvoeren in de jumpbox, 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 jump box beperkt door gebruik te maken van een UDR die het verkeer van HTTPs via de Azure Firewall.

Vereiste 1.5

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

Uw verantwoordelijkheden

Het is essentieel dat u uitgebreide documentatie over het proces en het beleid bijhoudt. Dit geldt met name wanneer u de regels Azure Firewall het AKS-cluster segmenteren. Personen die met gereguleerde omgevingen werken, moeten worden geleid, geïnformeerd en gecentreerd om de beveiligingsgaranties te ondersteunen. Dit is met name belangrijk voor mensen met accounts met uitgebreide beheerdersbevoegdheden.

Vereiste 2

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

Vereiste 2.1

Wijzig altijd de standaardinstellingen die door de leverancier zijn opgegeven en verwijder of schakel onnodige standaardaccounts uit voordat u een systeem op het netwerk installeert.

Uw verantwoordelijkheden

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

• Schakel beheerderstoegang tot het containerregister uit.
• Zorg ervoor dat jumpboxs en buildagents gebruikersbeheerprocedures volgen, waardoor de benodigde systeemgebruikers worden verwijderd.
• Genereer of geef geen SSH-sleuteltoegang tot knooppunten aan de gebruiker met beheerderstoegang. Als toegang in noodgevallen nodig is, gebruikt u het Azure-herstelproces om Just-In-Time-toegang te krijgen.

Azure-verantwoordelijkheden

Azure Active Directory heeft wachtwoordbeleidsregels die worden afgedwongen voor de nieuwe wachtwoorden die door gebruikers worden verstrekt. Als u een wachtwoord wijzigt, is validatie van het oudere wachtwoord vereist. Beheerderswachtwoorden voor opnieuw instellen moeten worden gewijzigd bij volgende aanmeldingen.

Vereiste 2.1.1

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

Uw verantwoordelijkheden

Deze architectuur en de implementatie zijn niet ontworpen om on-premises of bedrijfsnetwerk transacties via draadloze verbindingen in de cloud uit te voeren. 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

Implementeert de aanbevelingen in de Azure-beveiligingsbenchmark. Het biedt één geconsolideerde weergave van Azure-beveiligingsaanbevelingen, die betrekking hebben op branchekaders zoals CIS, NIST, PCI-DSS 3.2.1 en andere. Gebruik Azure Security Center functies en Azure Policy te helpen bij het volgen van de standaarden. Azure-beveiligingsbenchmark is het standaardinitiatief voor Azure Security Center. Overweeg om extra geautomatiseerde controles in Azure Policy Azure Tenant Security Solution (AzTS) te bouwen.

Documenteren van de gewenste configuratietoestand van alle onderdelen in de CDE, met name voor AKS-knooppunten, jump box, buildagents en andere onderdelen die met het cluster communiceren.

Zie Azure Security Benchmark voor meer informatie.

Azure-verantwoordelijkheid

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

Vereiste 2.2.1

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

Uw verantwoordelijkheden

De belangrijkste strategie is om het vereiste segmentatieniveau te bieden. Eén manier is om binnen het bereik en buiten het bereik van onderdelen in afzonderlijke clusters te implementeren. Dit leidt tot hogere kosten voor de toegevoegde infrastructuur en de onderhoudsoverhead. Een andere benadering is om alle onderdelen in een gedeeld cluster op te zoeken. Segmentatiestrategieën gebruiken om de scheiding te behouden. U kunt bijvoorbeeld afzonderlijke knooppuntgroepen in een cluster hebben.

In de referentie-implementatie wordt de tweede benadering gedemonstreerd met een microservicetoepassing 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 zijn verdeeld over twee gebruikers-knooppuntgroepen. Met het gebruik van Kubernetes-taints worden pods binnen het bereik en buiten het bereik geïmplementeerd voor afzonderlijke knooppuntgroepen en delen ze nooit een knooppunt-VM.

Voor containertechnologieën wordt die segmentering 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. Deze mag geen identiteit op cluster- of knooppuntniveau overnemen.

Gebruik waar mogelijk externe opslag in plaats van opslag op knooppunt (in cluster). Houd clusterpods uitsluitend gereserveerd voor werk dat moet worden uitgevoerd als onderdeel van de verwerking van kaarthoudergegevens. Verplaats de bewerkingen buiten het bereik buiten het cluster. Deze richtlijnen zijn van toepassing op buildagents, niet-gerelateerde workloads of activiteiten zoals het hebben van een jumpbox in het cluster.

Vereiste 2.2.2

Schakel alleen de 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 inschakelen. Standaardinstellingen kunnen functies bevatten die u niet nodig hebt en die functies moeten mogelijk inzicht hebben in de workload. Een voorbeeld hiervan zijn de coderingen in het standaard SSL-beleid voor Azure Application Gateway. Controleer of het beleid te ruim is. Het wordt aanbevolen om een aangepast beleid te maken door alleen de coderingen te selecteren die u nodig hebt.

Voor onderdelen waar u volledige controle over hebt, verwijdert u alle onnodige systeemservices uit de afbeeldingen (bijvoorbeeld jumpboxs en buildagents).

Voor onderdelen waarbij u alleen inzicht hebt, zoals AKS-knooppunten, documenteert u wat Azure op de knooppunten installeert. Overweeg het DaemonSets gebruik van om aanvullende controles te bieden die nodig zijn voor deze cloudgecontroleeerde onderdelen.

Vereiste 2.2.3

Implementeert 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 wordt verzonden, zodat alleen veilige coderingen mogelijk zijn. De referentie-implementatie ondersteunt alleen TLS 1.2 en goedgekeurde coderingen.

Stel dat u een verouderd apparaat hebt dat moet communiceren met de CDE via Azure Application Gateway. Daarom moeten Application Gateway een onveilig protocol inschakelen. Documenter deze uitzondering en controleer of dat protocol buiten dat verouderde apparaat wordt gebruikt. Schakel dat protocol onmiddellijk uit nadat deze verouderde interactie is beëindigd.

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

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

Vereiste 2.2.4

Systeembeveiligingsparameters configureren 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 van de Open Policy Agent werkt in combinatie met Azure Policy om onjuiste configuraties op 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 die niet privé zijn, wordt ont:.

Zorg ervoor dat alle uitzonderingen zijn gedocumenteerd.

Azure-verantwoordelijkheden

Azure zorgt ervoor dat alleen geautoriseerde medewerkers beveiligingscontroles voor het Azure-platform kunnen configureren met behulp van multi-factor access controls en een gedocumenteerde zakelijke behoefte.

Vereiste 2.2.5

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

Uw verantwoordelijkheden

Installeer geen software op jumpboxs of bouw agents die niet deelnemen aan de verwerking van een transactie of waarneembaarheid bieden voor nalevingsvereisten, zoals beveiligingsagents. Deze aanbeveling geldt ook voor de clusterentiteiten, zoals DaemonSet en pods. Zorg ervoor dat alle installaties worden gedetecteerd en geregistreerd.

Vereiste 2.3

Versleutel alle beheerderstoegang buiten de console 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 weer.

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 Beheerportal toegang hebben tot hun service-/IaaS-consoles met sterke cryptografie.

Vereiste 2.4

Een inventaris onderhouden van systeemonderdelen die binnen het bereik van PCI DSS.

Uw verantwoordelijkheden

Alle Azure-resources die in de architectuur worden gebruikt, moeten correct worden getagd. De tags helpen bij de gegevensclassificatie en geven aan of de service binnen het bereik of buiten het bereik valt. Met taggen kunt u zoeken naar 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 verder ontwikkelt, kunnen resources die buiten het bereik vallen, binnen het bereik vallen, zelfs als ze indirect communiceren of zich naast de gegevens van de kaarthouder houden. Deze resources zijn onderhevig aan controle en kunnen deel uitmaken van een representatieve steekproef tijdens de controle. Overweeg taggen op een hoger niveau, op abonnements- en clusterniveau.

Zie handleiding voor beslissingen over resourcenaamgeving en -taggen voor meer informatie over overwegingen voor taggen.

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

Vereiste 2.5

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

Uw verantwoordelijkheden

Het is essentieel dat u uitgebreide documentatie bijhoudt over de processen en het beleid. Medewerkers moeten worden getraind in de beveiligingsfuncties en configuratie-instellingen van elke Azure-resource. Personen die met gereguleerde omgevingen werken, moeten worden geleid, geïnformeerd en gecentreerd om de beveiligingsgaranties te ondersteunen. Dit is met name belangrijk voor beheerdersaccounts met uitgebreide beheerdersbevoegdheden.

Vereiste 2.6

Providers van gedeelde hosting moeten de gehoste omgevings- en kaarthoudergegevens van elke entiteit beveiligen.

Uw verantwoordelijkheden

Azure biedt beveiligingsgaranties voor de gehoste omgeving die wordt gedeeld. Het wordt ten zeerste aanbevolen om toegewezen hosts te gebruiken voor AKS-knooppunten. Dat wil zeggen dat de berekening in één tenantmodel moet zijn.

Volgende stappen

Opgeslagen kaartaanduidingsgegevens beveiligen. Versleutel de overdracht van kaartgegevens over open openbare netwerken.