Konfigurera nätverk för ett AKS-reglerat kluster för PCI-DSS 3.2.1 (del 3 av 9)

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

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

Huvudtemat i PCI-DSS 3.2.1-standarden är säkerhet. Topologin hub-spoke är ett naturligt val för att konfigurera en reglerad nätverksmiljö. Det är enklare att skapa en infrastruktur som möjliggör säker kommunikation. Nätverkskontroller placeras i båda hub-spoke-nätverken och följer Microsofts nollförtroendemodell. Kontrollerna kan justeras med minsta möjliga behörighet för att skydda trafiken, vilket ger åtkomst på behovsbasis. Dessutom kan du använda flera djupgående skyddsmetoder genom att lägga till kontroller på varje nätverkshopp och lager.

När du är värd för en arbetsbelastning i en Kubernetes räcker det inte att förlita sig på traditionella nätverkskonstruktioner, till exempel brandväggsregler. Det finns också Kubernetes-inbyggda konstruktioner som styr trafikflödet i klustret, till exempel resursen NetworkPolicy . Vi rekommenderar starkt att du läser Kubernetes-dokumentationen för att förstå grundläggande begrepp om isolerade poddar samt principer för ingress och utgående trafik.

Skapa och underhålla ett säkert nätverk och system

Krav 1 – Installera och underhålla en brandväggskonfiguration för att skydda korthållardata

Stöd för AKS-funktioner

AKS stöder distribution av ett kluster i ett privat virtuellt nätverk som ett privat kluster. Kommunikationen mellan klustret och DEN AKS-hanterade Kubernetes API-servern sker via ett betrott nätverk. Med ett privat kluster kan du använda Azure Virtual Network, Nätverkssäkerhetsgrupp (NSG) och andra inbyggda nätverkskontroller för att skydda hela korthållardatamiljön (CDE). Den här konfigurationen förbjuder obehörig offentlig åtkomst mellan Internet och miljön. Mer information om hur du etablerar ett sådant kluster finns i Skapa ett privat Azure Kubernetes Service-kluster.

Azure Firewall kan integreras med AKS och kan begränsa utgående trafik från klustret, vilket är en viktig komponent i CDE. Konfigurationen är enkel med en AKS FQDN-tagg. Den rekommenderade processen finns i Använda Azure Firewall för att skydda Distributioner av Azure Kubernetes Service (AKS).

AKS-kluster kräver viss offentlig Internetåtkomst. Begränsa utgående trafik till Internet med hjälp av Azure Firewall och NSG:er i klustrets undernät. Mer information finns i Kontrollera utgående trafik för klusternoder i Azure Kubernetes Service (AKS).

AKS kan också ha stöd för möjligheten att definiera en HTTP-proxy, som kan användas för ytterligare utgående trafikkontroll och övervakning för klustret. Klusternoderna använder den angivna HTTP-proxykonfigurationen för att dirigera utgående trafik. Dessutom är en MutatingWebhook registrerad för att mata in proxyinformationen i poddarna vid skapandetillfället, så vi rekommenderar att arbetsbelastningar kan ärva samma proxyinformation. Poddar kan åsidosätta proxyinformation, så vi rekommenderar att du använder en HTTP-proxy utöver en Azure Firewall.

AKS-kluster ska skapas med plugin-programmet NetworkPolicy. I AKS har du flera alternativ för plugin-programmet Nätverksprincip, inklusive Calico, Azure Network Policy Management och Cilium. Med Calico-nätverksprincip kan du antingen använda Kubenet eller Azure CNI. För Azure Network Policy Management kan du bara använda Azure CNI (inte Kubenet). Både Azure- och Calico Network Policy-plugin-program är öppen källkod. Mer information om Project Calico finns i det omfattande white paper för PCI-lösningen, som hanterar många av brandväggskraven nedan.

Ditt ansvar

Krav	Ansvar
Krav 1.1	Upprätta och implementera konfigurationsstandarder för brandvägg och router.
Krav 1.2	Skapa brandväggs- och routerkonfigurationer som begränsar anslutningar mellan ej betrodda nätverk och eventuella systemkomponenter i korthållardatamiljön.
Krav 1.3	Förhindra direkt offentlig åtkomst mellan Internet och alla systemkomponenter i korthållardatamiljön.
Krav 1.4	Installera personlig brandväggsprogramvara eller motsvarande funktioner på bärbara datorenheter (inklusive företag och/eller personalägda) som ansluter till Internet utanför nätverket (till exempel bärbara datorer som används av anställda) och som också används för att få åtkomst till CDE.
Krav 1.5	Se till att säkerhetsprinciper och operativa procedurer för att hantera brandväggar dokumenteras, används och är kända för alla berörda parter.

Krav 1.1

Upprätta och implementera konfigurationsstandarder för brandväggar och routrar som innehåller följande:

Krav 1.1.1

En formell process för att godkänna och testa alla nätverksanslutningar och ändringar i brandväggs- och routerkonfigurationerna.

Ditt ansvar

Implementera inte konfigurationer manuellt, till exempel genom att använda Azure-portalen eller Azure CLI direkt. Vi rekommenderar att du använder Infrastruktur som kod (IaC). Med IaC hanteras infrastrukturen via en beskrivande modell som använder ett versionshanteringssystem. IaC-modellen genererar samma miljö varje gång den tillämpas. Vanliga exempel på IaC är Bicep, Azure Resource Manager-mallar (ARM-mallar) eller Terraform. Om IaC inte är ett alternativ kan du ha en väldokumenterad process för att spåra, implementera och distribuera brandväggsregeländringar på ett säkert sätt. Mer information finns som en del av krav 11.2.

Du måste använda en kombination av olika nätverkskontroller, inklusive Azure Firewall, nätverkssäkerhetsgrupper (NSG:er) och Kubernetes-resursen NetworkPolicy .

Minimera antalet personer som kan komma åt och ändra nätverkskontroller. Definiera roller och tydliga ansvarsområden för team. En organisations nätverksteam verifierar till exempel ändringarna enligt de styrningsprinciper som angetts av IT-teamen. Ha en gated approval process som involverar personer och processer för att godkänna ändringar i alla nätverkskonfigurationer. Processen bör innehålla ett steg för att testa alla nätverkskontroller. Ha detaljerad dokumentation som beskriver processen.

Krav 1.1.2

Aktuellt nätverksdiagram som identifierar alla anslutningar mellan korthållardatamiljön och andra nätverk, inklusive trådlösa nätverk

Ditt ansvar

Som en del av dokumentationen underhåller du ett nätverksflödesdiagram som visar inkommande och utgående trafik med säkerhetskontroller. Detta inkluderar trafikflöde från andra nätverk, inklusive alla trådlösa nätverk till CDE. Diagrammet bör också visa flöden i klustret. Det finns vissa specifika krav för diagram, inklusive att de ska visa intrångssensorer och eventuella kontroller som tillämpas.

Den här bilden visar nätverksdiagrammet för referensimplementeringen.

Ladda ned en Visio-fil med det här diagrammet.

Bild 1.1.2 – Nätverksflöde

Beskrivningen av det här flödet finns i följande avsnitt.

Du kan visa topologin för ett virtuellt Azure-nätverk om du har Azure Network Watcher. Du kan visa alla resurser i ett virtuellt nätverk, de resurser som är kopplade till resurser i ett virtuellt nätverk och relationerna mellan resurserna.

Krav 1.1.3

Aktuellt diagram som visar alla korthållardataflöden mellan system och nätverk.

Ditt ansvar

Som en del av dokumentationen innehåller du ett dataflödesdiagram som visar hur data skyddas i vila och under överföring.

Diagrammet bör visa hur data flödar till och från arbetsbelastningen och vilken information som skickas från en resurs till en annan. Kontrollera att diagrammet är aktuellt. Lägg till ett steg som en del av ändringshanteringsprocessen för att uppdatera dataflödesdiagrammet.

Eftersom den här arkitekturen fokuserar på infrastrukturen och inte arbetsbelastningen har vi utelämnat illustrationer här.

Krav 1.1.4

Krav för en brandvägg vid varje Internetanslutning och mellan alla demilitariserade zoner (DMZ) och den interna nätverkszonen.

Ditt ansvar

Ha en tydlig definition av vad som definierar gränsen för en DMZ. Till exempel kan korthållardatamiljön (CDE) ligga inom en DMZ som skyddas av en brandvägg, nätverksprinciper och andra kontroller. Mer information finns i Cloud DMZ.

För en PCI DSS-infrastruktur ansvarar du för att skydda CDE med hjälp av nätverkskontroller för att blockera obehörig åtkomst till och från nätverket som innehåller CDE. Nätverkskontroller måste konfigureras korrekt för en stark säkerhetsstatus och de måste tillämpas på:

• Kommunikation mellan de samlokaliserade komponenterna i klustret.
• Kommunikation mellan arbetsbelastningen och andra komponenter i betrodda nätverk.
• Kommunikation mellan arbetsbelastningen och det offentliga Internet.

Den här arkitekturen använder olika brandväggstekniker för att inspektera trafik som flödar i båda riktningarna, till och från klustret som är värd för CDE:

• Azure Application Gateway används som trafikrouter och dess integrerade brandvägg för webbprogram (WAF) används för att skydda inkommande (inkommande) trafik till klustret.

• Azure Firewall används för att skydda all utgående trafik (utgående) från alla nätverk och dess undernät.

  Som en del av bearbetningen av en transaktion eller hantering måste klustret kommunicera med externa slutpunkter. Klustret kan till exempel kräva kommunikation med AKS-kontrollplanet, kommunikation med operativsystem och paketuppdateringssystem och många arbetsbelastningar interagerar med externa API:er. Vissa av dessa interaktioner kan vara via HTTP och bör betraktas som attackvektorer. Dessa vektorer är mål för en man-in-the-middle-attack som kan resultera i dataexfiltrering. Om du lägger till en brandvägg i utgående trafik minimeras det hotet.

  Vi rekommenderar att även pod-till-pod-kommunikation är TLS-krypterad. Den här metoden visas i referensimplementeringen med hjälp av ömsesidig TLS-autentisering (mTLS).

• NSG:er läggs till för att skydda trafiken mellan klustret och andra komponenter i infrastrukturen. I referensimplementeringen finns det till exempel NSG:er i undernätet med nodpooler som blockerar alla SSH-åtkomstförsök. Endast trafik från det virtuella nätverket tillåts.

  När du lägger till komponenter i arkitekturen kan du överväga att lägga till fler NSG:er som tillåter eller nekar trafiktyper vid undernätsgränser. Eftersom varje nodpool finns i ett dedikerat undernät tillämpar du mer specifika regler baserat på förväntade trafikmönster för din arbetsbelastning.

• Kubernetes-objekt NetworkPolicy används för att styra kommunikation i klustret.

  Som standard finns det inga begränsningar för podd-till-poddkommunikation. Du måste tillämpa NetworkPolicy på kommunikation i klustret, börja med ett nätverk med noll förtroende och öppna sökvägar efter behov. Referensimplementeringen visar nätverk med noll förtroende i namnrymderna a0005-i och a0005-o . Alla namnområden (utom kube-system, gatekeeper-systemoch andra AKS-angivna namnområden) har restriktiva nätverksprinciper. Principdefinitionen beror på vilka poddar som körs i dessa namnområden. Se till att du öppnar sökvägar för beredskap, livlighet och startavsökningar. Öppna också sökvägen till oms-agent så att mått på nodnivå kan skickas. Överväg att standardisera portar mellan arbetsbelastningarna så att du kan tillhandahålla en konsekvent NetworkPolicy och Azure Policy för de tillåtna containerportarna.

Krav 1.1.5

Beskrivning av grupper, roller och ansvarsområden för hantering av nätverkskomponenter.

Ditt ansvar

Du måste tillhandahålla kontroller för nätverksflödena och de komponenter som ingår. Den resulterande infrastrukturen kommer att ha flera nätverkssegment, var och en med många kontroller och varje kontroll med ett syfte. Kontrollera att dokumentationen har en bredd på täckningen, från nätverksplanering till alla konfigurationer som tillämpas. Den bör också innehålla information om ägarskapet, med tydliga ansvarslinjer och de roller som är ansvariga för dem.

Du kan till exempel veta vem som ansvarar för styrningen av att skydda nätverk mellan Azure och Internet. I ett företag ansvarar IT-teamet vanligtvis för konfiguration och underhåll av Azure Firewall-regler, WAF-regler (Web Application Firewall), NSG:er och annan trafik mellan nätverk. De kan också ansvara för allokering av virtuella nätverk och undernät i hela företaget samt planering av IP-adresser.

På arbetsbelastningsnivå ansvarar en klusteroperator för att upprätthålla Noll förtroende via nätverksprinciper. Ansvarsområden kan också omfatta kommunikation med Azure-kontrollplanet, Kubernetes-API:er och övervakningstekniker.

Börja alltid med en strategi för att neka alla. Ge endast behörighet när det finns ett affärsbehov eller en rollmotivering.

Krav 1.1.6

Dokumentation om affärsmotivering och godkännande för användning av alla tjänster, protokoll och portar som tillåts, inklusive dokumentation om säkerhetsfunktioner som implementerats för de protokoll som anses vara osäkra.

Ditt ansvar

Ha detaljerad dokumentation som beskriver de tjänster, protokoll och portar som används i nätverkskontrollerna. Neka alla förutom uttryckligen tillåtna portar. Dokumentera affärsmotivering och dokumenterade säkerhetsfunktioner om det inte går att undvika att använda osäkra protokoll. Här följer några exempel från referensimplementeringen för Azure Firewall. Brandväggsregler måste begränsas enbart till deras relaterade resurser. Det vill: endast trafik från specifika källor tillåts gå till specifika FQDN-mål.

Här följer några exempel där du kan tillåta trafik:

Regel	Protokoll:Port	Källa	Mål	Justering
Tillåt säker kommunikation mellan noderna och kontrollplanet.	HTTPS:443	Auktoriserade IP-adressintervall som tilldelats klusternodpoolerna	Lista över FQDN-mål i AKS-kontrollplanet. Detta anges med taggen AzureKubernetesService FQDN.	Noderna behöver åtkomst till kontrollplanet för hanteringsverktyg, tillstånds- och konfigurationsinformation samt information om vilka noder som kan skalas.
Tillåt säker kommunikation mellan Flux och GitHub.	HTTPS:443	AKS-nodpooler	github.com, api.github.com	Flux är en tredjepartsintegrering som körs på noderna. Den synkroniserar klusterkonfigurationen med en privat GitHub-lagringsplats.

Krav 1.1.7

Krav på att granska brandväggs- och routerregeluppsättningar minst var sjätte månad.

Ditt ansvar

Ha processer minst var sjätte månad för att granska nätverkskonfigurationerna och de begränsade reglerna. Detta säkerställer att säkerhetsgarantierna är aktuella och giltiga. Kontrollera att du granskar dessa konfigurationer:

• Azure Firewall-regler.
• NSG-regler.
• Azure Application Gateway- och WAF-regler.
• Interna Kubernetes-nätverksprinciper.
• Brandväggskontroller på tillämpliga Azure-resurser. Den här arkitekturen använder till exempel en regel i Azure Container Registry som endast tillåter trafik från en privat slutpunkt.
• Andra nätverkskontroller som du har lagt till i arkitekturen.

Om du har dragit tillbaka några arbetsbelastningar eller ändrat klustrets konfiguration sedan föregående granskning är det viktigt att kontrollera att alla antaganden du gjorde om nödvändiga brandväggsundantag eller NSG-regler fortfarande är giltiga.

Krav 1.2

Skapa brandväggs- och routerkonfigurationer som begränsar anslutningar mellan ej betrodda nätverk och eventuella systemkomponenter i korthållardatamiljön.

Ditt ansvar

I den här arkitekturen är AKS-klustret en viktig komponent i korthållardatamiljön (CDE). Vi rekommenderar starkt att klustret distribueras som ett privat kluster för ökad säkerhet. I ett privat kluster är nätverkstrafik mellan DEN AKS-hanterade Kubernetes API-servern och dina nodpooler privata. API-servern exponeras via en privat slutpunkt i klustrets nätverk.

Du kan också välja ett offentligt kluster, men den här designen rekommenderas dock inte för kluster som innehåller reglerade arbetsbelastningar. API-servern kommer att exponeras för Internet. DNS-posten kan alltid identifieras. Därför måste du ha kontroller för att skydda kluster-API:et från offentlig åtkomst. Om du behöver använda ett offentligt kluster är den rekommenderade metoden att ha strikta kontroller via Rollbaserade Åtkomstkontroller för Kubernetes (RBAC), tillsammans med funktionen AKS-auktoriserade IP-intervall för att begränsa vem som kan komma åt AKS API-servern. Den här lösningen rekommenderas dock inte för kluster som innehåller reglerade arbetsbelastningar.

När du bearbetar kortinnehavarens data (CHD) måste klustret interagera med nätverk som anses vara betrodda och ej betrodda. I den här arkitekturen anses båda hub-spoke-nätverken inom perimetern för PCI-DSS 3.2.1-arbetsbelastningen vara betrodda nätverk.

Ej betrodda nätverk är nätverk utanför den perimetern. Exempel på ej betrodda nätverk är:

• De andra hubbarna och ekrarna som kan finnas i samma infrastruktur, men som ligger utanför arbetsbelastningsperimetern.
• Det offentliga Internet.
• Företagsnätverket.
• Andra virtuella nätverk i Azure eller någon annan molnplattform.

I den här arkitekturen är det virtuella nätverket som är värd för avbildningsverktyget inte betrott eftersom det inte har någon roll att spela i CHD-hanteringen. CDE:s interaktion med sådana nätverk bör skyddas enligt kraven. Med det här privata klustret kan du använda virtuella nätverk, NSG:er och andra inbyggda funktioner för att skydda hela miljön.

Information om privata kluster finns i Skapa ett privat Azure Kubernetes Service-kluster.

Krav 1.2.1

Begränsa inkommande och utgående trafik till det som är nödvändigt för korthållardatamiljön och neka specifikt all annan trafik.

Ditt ansvar

Virtuella Azure-nätverk kan inte nås direkt från det offentliga Internet. All inkommande trafik (eller inkommande) trafik måste gå via en mellanliggande trafikrouter. Som standard kan dock alla komponenter i nätverket nå offentliga slutpunkter. Du kan inaktivera det beteendet genom att konfigurera ett privat undernät eller genom att använda en UDR för att skicka all utgående trafik via en brandvägg. Den utgående (eller utgående) trafiken måste uttryckligen skyddas för att endast tillåta säkra chiffer och TLS 1.2 eller senare.

• Azure Application Gateways integrerade WAF fångar upp all HTTP(S) inkommande trafik och vägar som inspekterats trafik till klustret.

  Den här trafiken kan komma från betrodda eller ej betrodda nätverk. Application Gateway etableras i ett undernät i ekernätverket och skyddas av en NSG. När trafiken flödar in, tillåter eller nekar WAF-regler och Application Gateway dirigerar trafik till den konfigurerade serverdelen. Application Gateway skyddar till exempel CDE genom att neka den här typen av trafik:

  • All trafik som inte är TLS-krypterad.
  • Trafik utanför portintervallet för kontrollplanskommunikation från Azure-infrastrukturen.
  • Hälsoavsökningsbegäranden som skickas av andra entiteter än den interna lastbalanseraren i klustret.

• Azure Firewall används för att skydda all utgående trafik (utgående) från betrodda och ej betrodda nätverk.

  Azure Firewall etableras i ett undernät i hubbnätverket. För att framtvinga Azure Firewall som enskild utgående punkt används användardefinierade vägar (UDR) på undernät som kan generera utgående trafik. Detta omfattar undernät i ej betrodda nätverk, till exempel det virtuella avbildningsverktygets virtuella nätverk. När trafiken når Azure Firewall tillämpas flera begränsade regler som gör att trafik från specifika källor kan gå till specifika mål.

  Mer information finns i Använda Azure Firewall för att skydda Distributioner av Azure Kubernetes Service (AKS).

• Du kan också använda en HTTP-proxy för att övervaka och skydda utgående trafik (utgående) från klustret till externa resurser.

  Förutom en brandvägg kanske vissa organisationer vill använda en HTTP-proxy för att ha ytterligare kontroller för utgående trafik. Vi rekommenderar att du fortfarande låter de användardefinierade vägarna gå till brandväggen och begränsa utgående trafik till att bara gå till HTTP-proxyn. Med den här konfigurationen kan brandväggen fortfarande blockera utgående trafik om en podd försöker åsidosätta proxyn.

  Mer information finns i HTTP-proxystöd i Azure Kubernetes Service.

Klustret kan kräva åtkomst till andra tjänster via det offentliga Internet. Om du till exempel använder ett program mot skadlig kod från tredje part måste du hämta virusdefinitionerna från en server via det offentliga Internet.

Interaktioner med slutpunkter för andra Azure-tjänster sker via Azure-stamnätet. Som en del av de vanliga åtgärderna måste klustret till exempel hämta certifikat från det hanterade nyckelarkivet, hämta avbildningar från ett containerregister och så vidare. Se till att dessa interaktioner är privata och säkra med Hjälp av Azure Private Link.

Förutom brandväggsregler och privata nätverk skyddas även trafikflöden via NSG-regler. Här följer några exempel från den här arkitekturen där CDE skyddas genom att neka trafik:

• NSG:er på undernät som har nodpooler nekar all SSH-åtkomst till noderna. Se till att du har en process på plats för just-in-time-nödåtkomst samtidigt som principen neka alla upprätthålls.
• En NSG i undernätet som har hopprutan för att köra hanteringsverktyg nekar all trafik förutom från Azure Bastion i hubbnätverket.
• NSG:er för undernät som har de privata slutpunkterna till Azure Key Vault och Azure Container Registry nekar all trafik förutom från den interna lastbalanseraren och trafiken via Azure Private Link.

Krav 1.2.2

Skydda och synkronisera routerkonfigurationsfiler.

Ditt ansvar

Ha en mekanism för att identifiera deltat mellan det faktiska distribuerade tillståndet och önskat tillstånd. Infrastruktur som kod (IaC) är ett bra val för detta ändamål. Till exempel upprätthåller Bicep-filer eller Azure Resource Manager-mallar (ARM-mallar) en post med önskat tillstånd.

Distributionstillgångarna, till exempel Bicep-filer, måste vara källstyrda så att du har historiken för alla ändringar. Samla in information från Azure-aktivitetsloggar, pipelineloggar för distribution och Azure-distributionsloggar. Dessa källor hjälper dig att hålla koll på distribuerade tillgångar.

I klustret bör även nätverkskontroller som Kubernetes-nätverksprinciper följa det källkontrollerade flödet. I den här implementeringen används Flux som GitOps-operator. När du synkroniserar en klusterkonfiguration, till exempel nätverksprinciper, kan din Git-historik kombinerad med Flux- och API-loggar vara en konfigurationshistorikkälla.

Krav 1.2.3

Installera perimeterbrandväggar mellan alla trådlösa nätverk och korthållardatamiljön och konfigurera dessa brandväggar för att neka eller, om trafik är nödvändig för affärsändamål, endast tillåta auktoriserad trafik mellan den trådlösa miljön och korthållardatamiljön.

Ditt ansvar

AKS-noderna och nodpoolerna får inte nås från trådlösa nätverk. Begäranden till Kubernetes API-servern måste också nekas. Åtkomsten till dessa komponenter är begränsad till auktoriserade och skyddade undernät.

I allmänhet begränsar du åtkomsten från lokal trafik till ekernätverket.

Krav 1.3

Förhindra direkt offentlig åtkomst mellan Internet och alla systemkomponenter i korthållardatamiljön.

Ditt ansvar

AKS-klusternodpooler fungerar i det virtuella nätverket och isoleras från offentliga nätverk, till exempel Internet. Upprätthålla isolering genom att förhindra associationen av offentliga IP-adresser till klusternoder och genom att tillämpa NSG-regler på klustrets undernät för att se till att Internettrafiken blockeras. Information om kontrollerad åtkomst finns i avsnittet DMZ.

AKS-klustret har systemnodpooler som är värdar för kritiska systempoddar. Även i användarnodpoolerna finns det poddar som kör andra tjänster som deltar i klusteråtgärder. Poddar kan till exempel köra Flux för att synkronisera klusterkonfigurationen till en GitHub-lagringsplats eller ingresskontrollanten för att dirigera trafik till arbetsbelastningspoddarna. Oavsett typ av nodpool måste alla noder skyddas.

En annan viktig systemkomponent är DEN API-server som används för att utföra interna Kubernetes-uppgifter, till exempel upprätthålla tillståndet för klustret och konfigurationen. En fördel med att använda ett privat kluster är att API-serverslutpunkten inte exponeras som standard. Information om privata kluster finns i Skapa ett privat Azure Kubernetes Service-kluster.

Interaktioner med andra slutpunkter måste också skyddas. Ett sätt är att begränsa kommunikationen via ett privat nätverk. Låt till exempel klustret hämta avbildningar från Azure Container Registry via en privat länk.

Krav 1.3.1

Implementera en DMZ för att begränsa inkommande trafik till endast systemkomponenter som tillhandahåller auktoriserade offentligt tillgängliga tjänster, protokoll och portar.

Ditt ansvar

Här följer viss bästa praxis:

• Konfigurera inte offentliga IP-adresser på nodpoolnoderna.
• Använd Azure Policy för att säkerställa att Kubernetes inte exponerar en offentlig lastbalanserare. Trafik i klustret måste dirigeras via interna lastbalanserare.
• Exponera endast interna lastbalanserare för Azure Application Gateway som är integrerat med WAF.
• Alla nätverkskontroller bör i förekommande fall ange begränsningar för källa, mål, port och protokoll.
• Exponera inte API-servern för Internet. När du kör klustret i privat läge exponeras inte slutpunkten och kommunikationen mellan nodpoolerna och API-servern är över ett privat nätverk.

Användare kan implementera ett perimeternätverk för att skydda AKS-kluster. Mer information finns i Cloud DMZ.

Krav 1.3.2

Begränsa inkommande Internettrafik till IP-adresser i DMZ.

Ditt ansvar

I klusternätverket har du en NSG i undernätet med den interna lastbalanseraren. Konfigurera regler för att endast acceptera trafik från undernät som har Azure Application Gateway integrerat med WAF. I AKS-klustret använder du Kubernetes NetworkPolicies för att begränsa inkommande trafik till poddarna.

Krav 1.3.3

Implementera åtgärder mot förfalskning för att identifiera och blockera förfalskade käll-IP-adresser från att komma in i nätverket.

Azure-ansvarsområden

Azure implementerar nätverksfiltrering för att förhindra falsk trafik och begränsa inkommande och utgående trafik till betrodda plattformskomponenter.

Krav 1.3.4

Tillåt inte obehörig utgående trafik från korthållardatamiljön till Internet.

Ditt ansvar

Här är sätt på vilka du kan blockera obehörig utgående trafik:

• Framtvinga all utgående trafik (utgående) från AKS-klustret för att gå igenom Azure Firewall med hjälp av användardefinierade vägar (UDR) på alla klusterundernät. Detta omfattar undernät med system- och användarnodpooler.
• Begränsa utgående trafik genom att lägga till NSG:er i undernät med nodpooler.
• Använd Kubernetes NetworkPolicies för att begränsa utgående trafik från poddarna.
• Använd ett tjänstnät för att hantera ytterligare principer. Om du till exempel bara tillåter TLS-krypterad trafik mellan poddar kan tjänstnätproxyn hantera TLS-verifieringen. Det exemplet visas i den här implementeringen. Envoy distribueras som proxy.
• Förhindra tillägg av offentliga IP-adresser till nätverken i CDE såvida inte av undernät som uttryckligen har auktoriserats, till exempel brandväggsundernäten.
• Använd en HTTP-proxy utöver Azure Firewall för att begränsa utgående trafik (utgående) från AKS-klustret till Internet.
• Använd Azure Monitor Private Link Service (AMPLS) för att få loggar från Container Insights skickade via en säker, privat anslutning till Azure Monitor. Förstå effekten av att aktivera AMPLS.

Mer information finns i Kontrollera utgående trafik för klusternoder i Azure Kubernetes Service (AKS).

Krav 1.3.5

Tillåt endast "etablerade" anslutningar till nätverket.

Azure-ansvarsområden

Azure implementerar nätverksfiltrering för att förhindra falsk trafik och begränsa inkommande och utgående trafik till betrodda plattformskomponenter. Azure-nätverket är åtskilt för att skilja kundtrafik från hanteringstrafik.

Krav 1.3.6

Placera systemkomponenter som lagrar korthållardata (till exempel en databas) i en intern nätverkszon, åtskilda från DMZ och andra ej betrodda nätverk.

Ditt ansvar

Exponera dina lagringssystem endast via ett privat nätverk, till exempel med hjälp av Private Link. Begränsa också åtkomsten från nodpoolens undernät som kräver det. Håll tillståndet borta från klustret och i en egen dedikerad säkerhetszon.

Krav 1.3.7

Lämna inte ut privata IP-adresser och routningsinformation till obehöriga parter.

Ditt ansvar

För att uppfylla detta krav är ett offentligt AKS-kluster inte ett alternativ. Ett privat kluster håller DNS-poster utanför det offentliga Internet med hjälp av en privat DNS-zon. Det är dock fortfarande möjligt att skapa ett privat AKS-kluster med en offentlig DNS-adress. Därför rekommenderar vi att du uttryckligen inaktiverar den här funktionen genom att ange enablePrivateClusterPublicFQDN för att false förhindra avslöjande av kontrollplanets privata IP-adress. Överväg att använda Azure Policy för att framtvinga användning av privata kluster utan offentliga DNS-poster.

Använd också en privat DNS-zon för routning mellan det undernät som har Azure Application Gateway integrerat med WAF och det undernät som har den interna lastbalanseraren. Se till att inga HTTP-svar innehåller någon privat IP-information i rubrikerna eller brödtexten. Se till att loggar som kan innehålla IP- och DNS-poster inte exponeras utanför driftbehoven.

En Azure-tjänst som är ansluten via Private Link har ingen offentlig DNS-post som exponerar dina privata IP-adresser. Din infrastruktur bör använda Private Link optimalt.

Krav 1.4

Installera personlig brandväggsprogramvara eller motsvarande funktioner på alla bärbara datorenheter som ansluter till Internet utanför nätverket och som också används för att komma åt CDE.

Ditt ansvar

Det privata klustret hanteras av AKS-kontrollplanet. Du har inte direkt åtkomst till noder. För att utföra administrativa uppgifter måste du använda hanteringsverktyg som kubectl från en separat beräkningsresurs. Ett alternativ är att använda en luftgapad hoppruta där du kan köra kommandona. Även inkommande och utgående trafik från hopprutan måste vara begränsad och säker. Om VPN används för åtkomst kontrollerar du att klientdatorn hanteras av företagets princip och att alla principer för villkorlig åtkomst är på plats.

I den här arkitekturen finns hopprutan i ett separat undernät i ekernätverket. Inkommande åtkomst till hopprutan begränsas med hjälp av en NSG som endast tillåter åtkomst via Azure Bastion via SSH.

Om du vill köra vissa kommandon i hopprutan måste du nå offentliga slutpunkter. Till exempel slutpunkter som hanteras av Azure-hanteringsplanet. Den utgående trafiken måste vara säker. På samma sätt som andra komponenter i ekernätverket begränsas utgående trafik från hopprutan med hjälp av en UDR som tvingar HTTPS-trafik att gå igenom Azure Firewall.

Krav 1.5

Se till att säkerhetsprinciper och operativa procedurer för att hantera brandväggar dokumenteras, används och är kända för alla berörda parter.

Ditt ansvar

Det är viktigt att du har omfattande dokumentation om processen och principerna. Detta gäller särskilt när du hanterar Azure Firewall-regler som delar upp AKS-klustret. Personer som driver reglerade miljöer måste utbildas, informeras och uppmuntras för att stödja säkerhetsgarantierna. Detta är särskilt viktigt för personer med konton som beviljas breda administrativa privilegier.

Krav 2 – Använd inte standardvärden som tillhandahålls av leverantören för systemlösenord och andra säkerhetsparametrar

Ditt ansvar

Krav	Ansvar
Krav 2.1	Ändra alltid standardvärden som tillhandahålls av leverantören och ta bort eller inaktivera onödiga standardkonton innan du installerar ett system i nätverket.
Krav 2.2	Utveckla konfigurationsstandarder för alla systemkomponenter. Se till att dessa standarder hanterar alla kända säkerhetsrisker och är konsekventa med branschgodkända systemhärdningsstandarder.
Krav 2.3	Kryptera all administrativ åtkomst som inte är konsolbaserad med hjälp av stark kryptografi.
Krav 2.4	Underhålla en inventering av systemkomponenter som finns i omfånget för PCI DSS.
Krav 2.5	Se till att säkerhetsprinciper och operativa procedurer för att hantera leverantörens standardvärden och andra säkerhetsparametrar dokumenteras, används och är kända för alla berörda parter.
Krav 2.6	Delade värdleverantörer måste skydda varje entitets värdbaserade miljö och korthållardata.

Använd inte standardvärden som tillhandahålls av leverantören för systemlösenord och andra säkerhetsparametrar

Krav 2.1

Ändra alltid standardvärden som tillhandahålls av leverantören och ta bort eller inaktivera onödiga standardkonton innan du installerar ett system i nätverket.

Ditt ansvar

Standardinställningarna som tillhandahålls av leverantörer måste ändras. Standardinställningarna är vanliga attackvektorer och gör systemet utsatt för attacker. Här följer några överväganden:

• Inaktivera administratörsåtkomst i containerregistret.
• Se till att hopprutor och byggagenter följer användarhanteringsprocedurerna och tar bort systemanvändare som inte behövs.
• Generera eller ge inte SSH-nyckelåtkomst till noder till administratörsanvändare. Om nödåtkomst krävs använder du Azure-återställningsprocessen för att få just-in-time-åtkomst.

Azure-ansvarsområden

Microsoft Entra-ID har lösenordsprinciper som tillämpas på de nya lösenord som tillhandahålls av användare. Om du ändrar ett lösenord krävs verifiering av det äldre lösenordet. Ett lösenord som har återställts av en administratör måste ändras när användaren loggar in nästa år.

Krav 2.1.1

För trådlösa miljöer som är anslutna till korthållardatamiljön eller överför korthållardata ändrar du ALLA trådlösa leverantörsstandarder vid installationen, inklusive men inte begränsat till standardsträngar för trådlös kryptering, lösenord och SNMP-communitysträngar.

Ditt ansvar

Den här arkitekturen och implementeringen är inte utformade för att göra lokala eller företagsnätverk till molntransaktioner via trådlösa anslutningar. Överväganden finns i vägledningen i den officiella PCI-DSS 3.2.1-standarden.

Krav 2.2

Utveckla konfigurationsstandarder för alla systemkomponenter.

Ditt ansvar

Implementera rekommendationerna i Microsoft Cloud Security Benchmark. Den innehåller en enda samlad vy över Azures säkerhetsrekommendationer som omfattar branschramverk som CIS, NIST, PCI-DSS 3.2.1 och andra. Använd Microsoft Defender för molnet-funktioner och Azure Policy för att spåra mot standarderna. Azure Security Benchmark är standardinitiativet för Microsoft Defender för molnet. Överväg att skapa ytterligare automatiserade kontroller i Azure Policy och Azure Tenant Security Solution (AzTS).

Dokumentera önskat konfigurationstillstånd för alla komponenter i CDE, särskilt för AKS-noder, jump box, byggagenter och andra komponenter som interagerar med klustret.

Mer information finns i Microsoft Cloud Security Benchmark.

Azure-ansvar

Azure tillhandahåller säkerhetskonfigurationsstandarder som överensstämmer med branschgodkända härdningsstandarder. Standarderna ses över minst varje år.

Krav 2.2.1

Implementera endast en primär funktion per server för att förhindra funktioner som kräver olika säkerhetsnivåer från att samexistera på samma server. (Till exempel bör webbservrar, databasservrar och DNS implementeras på separata servrar.)

Ditt ansvar

Den viktigaste strategin är att tillhandahålla den segmenteringsnivå som krävs. Ett sätt är att distribuera omfångs- och out-of-scope-komponenter i separata kluster. Förstå att detta resulterar i ökade kostnader för den extra infrastrukturen och underhållskostnaderna. En annan metod är att samplacera alla komponenter i ett delat kluster. Använd segmenteringsstrategier för att upprätthålla separationen. Du kan till exempel ha separata nodpooler i ett kluster.

I referensimplementeringen demonstreras den andra metoden med ett mikrotjänstprogram som distribueras till ett enda kluster. Programmet har två uppsättningar tjänster: en uppsättning har poddar i omfånget och den andra är utanför omfånget. Båda uppsättningarna är spridda över två användarnodpooler. Med kubernetes-taints distribueras poddar inom omfång och utanför omfånget till separata nodpooler och de delar aldrig en virtuell noddator.

För containertekniker tillhandahålls segmenteringen som standard eftersom endast en instans av en container ansvarar för en funktion i systemet.

Varje arbetsbelastningspodd bör använda sin egen identitet. Den får inte ärva någon identitet på klusternivå eller nodnivå.

Använd extern lagring i stället för på nodlagring (i klustret) där det är möjligt. Håll klusterpoddar reserverade enbart för arbete som måste utföras som en del av bearbetningen av kortinnehavarens data. Flytta åtgärderna utanför omfånget utanför klustret. Den här vägledningen gäller för byggagenter, orelaterade arbetsbelastningar eller aktiviteter som att ha en hoppruta i klustret.

Krav 2.2.2

Aktivera endast nödvändiga tjänster, protokoll, daemoner osv., som krävs för systemets funktion.

Ditt ansvar

Granska funktionerna och konsekvenserna innan du aktiverar dem. Standardinställningarna kan innehålla funktioner som du inte behöver, och dessa funktioner kan behöva insyn i arbetsbelastningen. Ett exempel på detta är chiffer i standardprincipen för SSL för Azure Application Gateway. Kontrollera om principen är alltför tillåtande. Rekommendationen är att skapa en anpassad princip genom att bara välja de chiffer du behöver.

För komponenter där du har fullständig kontroll tar du bort alla onödiga systemtjänster från avbildningarna. Granska till exempel bilderna för hopprutor och byggagenter och ta bort eventuella komponenter som inte behövs.

För komponenter där du bara har synlighet, till exempel AKS-noder, dokumenterar du vad Azure installerar på noderna. Överväg att använda DaemonSets för att tillhandahålla ytterligare granskning som krävs för dessa molnkontrollerade komponenter.

Krav 2.2.3

Implementera ytterligare säkerhetsfunktioner för nödvändiga tjänster, protokoll eller daemoner som anses vara osäkra.

Ditt ansvar

Application Gateway har en integrerad WAF och förhandlar om TLS-handskakningen för den begäran som skickas till dess offentliga slutpunkt, vilket endast tillåter säkra chiffer. Referensimplementeringen stöder endast TLS 1.2 och godkända chiffer.

Anta att du har en äldre enhet som måste interagera med CDE via Azure Application Gateway. För att uppfylla det kravet måste Application Gateway aktivera ett osäkert protokoll. Dokumentera undantaget och övervaka om protokollet används utöver den äldre enheten. Inaktivera protokollet omedelbart efter att den äldre interaktionen har avbrutits.

Application Gateway får inte svara på begäranden på port 80. Utför inte omdirigeringar på programnivå. Den här referensimplementeringen har en NSG-regel som blockerar port 80-trafik. Regeln finns i undernätet med Application Gateway.

Om en arbetsbelastning i klustret inte kan följa organisationens princip kring säkerhetsefterlevnadsprofiler eller andra kontroller (till exempel gränser och kvoter) kontrollerar du att undantaget är dokumenterat. Du måste övervaka för att säkerställa att endast förväntade funktioner utförs.

Krav 2.2.4

Konfigurera systemsäkerhetsparametrar för att förhindra missbruk.

Ditt ansvar

Alla Azure-tjänster som används i arkitekturen måste följa rekommendationerna från Microsoft Cloud Security Benchmark. De här rekommendationerna ger dig en startpunkt för att välja specifika inställningar för säkerhetskonfiguration. Jämför även konfigurationen med baslinjeimplementeringen för den tjänsten. Mer information om säkerhetsbaslinjer finns i Säkerhetsbaslinjer för Azure.

Open Policy Agent-antagningskontrollanten fungerar tillsammans med Azure Policy för att identifiera och förhindra felkonfigurationer i klustret. Anta att det finns en organisationsprincip som inte tillåter offentliga IP-allokeringar på noderna. När en sådan allokering identifieras markeras den för granskning eller nekas baserat på den åtgärd som anges i principdefinitionen.

På infrastrukturnivå kan du tillämpa begränsningar för typen och konfigurationen av Azure-resurser. Använd Azure Policy för att förhindra felkonfigurationer. I den här referensimplementeringen finns det en princip som nekar skapandet av AKS-kluster som inte är privata.

Se till att alla undantag dokumenteras och granskas regelbundet.

Azure-ansvarsområden

Azure ser till att endast behörig personal kan konfigurera säkerhetskontroller för Azure-plattformen med hjälp av kontroller för multifaktoråtkomst och ett dokumenterat affärsbehov.

Krav 2.2.5

Ta bort alla onödiga funktioner, till exempel skript, drivrutiner, funktioner, undersystem, filsystem och onödiga webbservrar.

Ditt ansvar

Installera inte programvara på hopprutor eller byggagenter som inte deltar i bearbetningen av en transaktion eller ger observerbarhet för efterlevnadskrav, till exempel säkerhetsagenter. Den här rekommendationen gäller även för klusterentiteter, till exempel DaemonSet och poddar. Kontrollera att alla installationer har identifierats och loggats.

Krav 2.3

Kryptera all administrativ åtkomst som inte är konsolbaserad med hjälp av stark kryptografi.

Ditt ansvar

All administrativ åtkomst till klustret ska göras med hjälp av -konsolen. Exponera inte klustrets kontrollplan.

Azure-ansvarsområden

Azure säkerställer att användningen av stark kryptografi tillämpas vid åtkomst till hypervisor-infrastrukturen. Det säkerställer att kunder som använder Azure-portalen kan komma åt sina tjänst- och värdkonsoler med hjälp av stark kryptografi.

Krav 2.4

Underhålla en inventering av systemkomponenter som finns i omfånget för PCI DSS.

Ditt ansvar

Alla Azure-resurser som används i arkitekturen måste taggas korrekt. Taggarna hjälper till med dataklassificering och anger om tjänsten är inom omfånget eller utanför omfånget. Noggrann taggning gör att du kan fråga efter resurser, hålla en inventering, hjälpa till att spåra kostnader och ange aviseringar. Underhåll även en ögonblicksbild av dokumentationen med jämna mellanrum.

Undvik att tagga resurser i omfång eller utanför omfånget på detaljerad nivå. När lösningen utvecklas kan out-of-scope-resurser bli omfångsbaserade även om de indirekt interagerar eller ligger i anslutning till kortinnehavarens data. Dessa resurser är föremål för granskning och kan ingå i ett representativt urval under granskningen. Överväg att tagga på en högre nivå, på prenumerations- och klusternivå.

Information om taggningsöverväganden finns i beslutsguiden för namngivning och taggning av resurser.

Tagga objekt i klustret genom att använda Kubernetes-etiketter. På så sätt kan du ordna objekt, välja en samling objekt och rapportera inventering.

Krav 2.5

Se till att säkerhetsprinciper och operativa procedurer för att hantera leverantörens standardvärden och andra säkerhetsparametrar dokumenteras, används och är kända för alla berörda parter.

Ditt ansvar

Det är viktigt att du har omfattande dokumentation om processer och principer. Personalen bör utbildas i säkerhetsfunktionerna och konfigurationsinställningarna för varje Azure-resurs. Personer som driver reglerade miljöer måste utbildas, informeras och uppmuntras för att stödja säkerhetsgarantierna. Dessa steg är särskilt viktiga för alla personer som beviljas breda administrativa privilegier.

Krav 2.6

Delade värdleverantörer måste skydda varje entitets värdbaserade miljö och korthållardata.

Ditt ansvar

Azure tillhandahåller säkerhetsgarantier för alla värdbaserade miljökomponenter som delas. Vi rekommenderar starkt att du behandlar dina AKS-noder som en dedikerad värd för den här arbetsbelastningen. Det vill sa att all beräkning ska finnas i en enda klientorganisationsmodell och inte delas med andra arbetsbelastningar som du kan använda.

Om fullständig beräkningsisolering önskas på Azure-infrastrukturnivå kan du lägga till En dedikerad Azure-värd i ett AKS-kluster (Azure Kubernetes Service). Det här erbjudandet tillhandahåller fysiska servrar som är dedikerade till din arbetsbelastning, så att du kan placera AKS-noder direkt i dessa etablerade värdar. Det här arkitekturvalet har betydande kostnadskonsekvenser och kräver noggrann kapacitetsplanering. Det är inte typiskt för de flesta scenarier.

Nästa steg

Skydda lagrade korthållardata. Kryptera överföring av korthållardata över öppna, offentliga nätverk.

Relaterade resurser

• Arkitekturdesign för Azure Kubernetes Service (AKS)
• Introduktion av ett AKS-reglerat kluster för PCI-DSS 3.2.1 (del 1 av 9)
• Arkitektur för ett AKS-reglerat kluster för PCI-DSS 3.2.1 (del 2 av 9)
• Baslinjearkitektur för ett AKS-kluster (Azure Kubernetes Service)
• AKS-baslinje för kluster i flera regioner