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

Den här artikeln beskriver överväganden för ett Azure Kubernetes Service-kluster (AKS) 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 för PCI-DSS 3.2.1-standarden är säkerhet. Topologin av nav och ekrar är ett naturligt val för att skapa en reglerad miljö. Det är enklare att skapa en infrastruktur som möjliggör säker kommunikation. Nätverkskontroller placeras i båda hubb-ekernätverken och följer Microsofts nollförtroendemodell. Kontrollerna kan finjusteras med minsta behörighet för att skydda trafiken, vilket ger åtkomst på ett behöver-till-vet-basis. Dessutom kan du använda flera djup defense-in-depth-metoder genom att lägga till kontroller vid varje nätverkshopp.

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

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 AKS-hanterad Kubernetes API-server är över 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). Detta förhindrar 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änd Azure Firewall för att skydda Azure Kubernetes Service-distributioner (AKS).

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

Dina ansvarsområden

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å alla bärbara datorenheter (inklusive företagsägda 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 åtkomst till CDE:n.
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 2– Använd inte standardinställningar från leverantören för systemlösenord och andra säkerhetsparametrar.

Dina ansvarsområden

Krav	Ansvar
Krav 2.1	Ändra alltid standardvärdena från 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 åtgärda alla kända säkerhetsproblem och är konsekventa med bransch accepterade systemhärdningsstandarder.
Krav 2.3	Kryptera all administrativ åtkomst som inte är konsol med hjälp av stark kryptografi.
Krav 2.4	Upprätthålla en förteckning över systemkomponenter som omfattas av PCI DSS.
Krav 2.5	Se till att säkerhetsprinciper och operativa procedurer för hantering av leverantörsstandarder 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ärdmiljö och korthållardata.

Krav 1.1

Upprätta och implementera konfigurationsstandarder för brandvägg och router som omfattar 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.

Dina ansvarsområden

Implementera inte konfigurationer manuellt, till exempel genom att använda Azure Portal 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 versionssystem. IaC-modellen genererar samma miljö varje gång den tillämpas. Vanliga exempel på IaC är Azure Resource Manager eller Terraform. Om IaC inte är ett alternativ har du en väldokumenterad process för att spåra, implementera och distribuera ändringar av brandväggsregler 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) och Kubernetes-resursen. NetworkPolicy

Minimera antalet personer som kan komma åt och ändra nätverkskontroller. Definiera roller och tydliggjort ansvarsområden för teamen. Till exempel validerar en organisations nätverksteam ändringarna enligt de styrningsprinciper som angetts av IT-teamen. Ha en process för gated-godkännande som inbegriper personer och processer för att godkänna ändringar i en nätverkskonfiguration. 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 eventuella trådlösa nätverk

Dina ansvarsområden

Som en del av dokumentationen bör du upprätthålla 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 särskilda krav för diagram, de bör visa intrångssensorerna. Kontrollerna för

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

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.

Dina ansvarsområden

Ta med ett dataflödesdiagram som visar hur data skyddas i vila och under överföring som en del av dokumentationen.

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 hålls 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 på arbetsbelastningen har vi utelämnat bilder här.

Krav 1.1.4

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

Dina ansvarsområden

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

För en PCI DSS infrastruktur ansvarar du för att skydda CDE:en genom att använda nätverkskontroller för att blockera obehörig åtkomst till och från nätverket med CDE:en. Nätverkskontroller måste konfigureras korrekt för en stark säkerhetsstatus och de måste tillämpas på:

• Kommunikation mellan de samplacerade 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:en:

• Azure Application Gateway en integrerad brandvägg för webbaserade program (WAF) används som trafikrouter och för att skydda inkommande (inkommande) trafik till klustret.

• Azure Firewall används för att skydda all utgående (utgående) trafik 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 entiteter. Klustret kan till exempel kräva kommunikation med AKS-kontrollplanet, hämta Windows uppdateringar och paketuppdateringar samt arbetsbelastningens interaktion med externa API:er. Vissa av dessa interaktioner kan vara över HTTP och bör betraktas som attackvektorer. Dessa vektorer är mål för en man-i-mitten-attack som kan leda till datafiltrering. Genom att lägga till en brandvägg för utgående trafik minimeras det hotet.

  Vi rekommenderar att även kommunikation mellan poddar är TLS-krypterad. Den här praxis visas i referensimplementering med hjälp av ett mTLS-nät.

• NSG:er läggs till för att skydda trafiken mellan klustret och andra komponenter i infrastrukturen. I referensimplementering 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 bör 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 ska du tillämpa mer specifika regler baserat på förväntade trafikmönster för din arbetsbelastning.

• Kubernetes NetworkPolicy

  Som standard finns det inga begränsningar för kommunikation mellan poddar. Du måste tillämpa på klusterkommunikation, från ett nollförtroendenätverk NetworkPolicy och öppna sökvägar efter behov. Referensimplementering visar nollförtroendenätverk i a0005-ia0005-o namnrymderna och . Alla namnrymder (utom kube-systemgatekeeper-system , och andra AKS-angivna namnområden) har begränsad NetworkPolicy tillämpas. Principdefinitionen beror på vilka poddar som körs i dessa namnområden. Se till att du öppnar sökvägar för beredskap, livelines och startavsökningar. Öppna också sökvägen till oms-agent så att mått på nodnivå kan skickas. Överväg att standardisera portar i arbetsbelastningarna så att du kan tillhandahålla en konsekvent och NetworkPolicy 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.

Dina ansvarsområden

Du måste ange 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 inte bara har den omfattande täckningen från nätverksplanering till alla konfigurationer utan även information om ägarskapet. Ha tydliga ansvarsrader och de roller som ansvarar för dem.

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

På arbetsbelastningsnivå ansvarar en klusteroperatör för att upprätthålla Zero-Trust via nätverksprinciper. Ansvarsområdena kan även omfatta kommunikation med Azure-kontrollplanet, Kubernetes-API:er och övervakningstekniker.

Börja alltid med en "neka alla"-strategi. Ge behörighet endast när det finns ett affärs behov eller en rollberättigande.

Krav 1.1.6

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

Dina ansvarsområden

Ha detaljerad dokumentation som beskriver de tjänster, protokoll och portar som används i nätverkskontrollerna. Neka alla utom uttryckligen tillåtna portar. Dokumentera affärsberättigande 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 referensimplementering för Azure Firewall. Brandväggsregler måste vara begränsade till sina relaterade resurser. Det innebär att endast trafik från specifika källor tillåts gå till specifika FQDN-mål. Här är några fall för att tillåta trafik.

Regel	Protokoll:Port	Källa	Mål	Motivering
Tillåt säker kommunikation mellan noderna och kontrollplanet.	HTTPS:443	Auktoriserade IP-adressintervall som tilldelats till klusternodpoolerna	Lista över FQDN-mål i AKS-kontrollplanet. Detta anges med AzureKubernetesService taggen 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 integrering från tredje part som körs på noderna. Klusterkonfigurationen synkroniseras med en privat GitHub lagringsplats.

Information om vilka portar som krävs finns i den officiella dokumentationen för Azure-tjänsten.

Krav 1.1.7

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

Dina ansvarsområden

Ha processer minst var sjätte månad för att granska nätverkskonfigurationerna och de begränsade reglerna. Detta ser till att säkerhetsgarantin är aktuell och giltig. Kontrollera att du granskar dessa konfigurationer:

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

Krav 1.2

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

Dina ansvarsområden

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ätverkstrafiken mellan den AKS-hanterade Kubernetes API-servern och dina nodpooler privat. API-servern exponeras via en privat slutpunkt i klustrets nätverk.

Du kan också välja ett offentligt kluster, men vara medveten om potentiella utmaningar med det här alternativet. API-servern exponeras mot Internet. DNS-posten kan alltid upptäckas. Därför måste du ha kontroller för att hålla kluster-API:et skyddat från offentlig åtkomst. En metod är att ha nära kontroller via Kubernetes rollbaserade åtkomstkontroller (RBAC), tillsammans med funktionen för auktoriserade IP-intervall i AKS. 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 i perimetern för PCI-DSS 3.2.1-arbetsbelastningen vara betrodda nätverk.

Ej betrodda nätverk är nätverk utanför den perimetern. Den här kategorin innehåller andra hubbar och ekrar som kan finnas i samma infrastruktur, men som ligger utanför arbetsbelastningens perimeter, offentliga Internet, företagsnätverket eller virtuella nätverk i Azure eller en annan molnplattform. I den här arkitekturen är det virtuella nätverket som är värd för bildbyggaren inte betrodd 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 Azure Virtual Network, en NSG 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 den som krävs för korthållardatamiljön och neka all annan trafik.

Dina ansvarsområden

Azure-tjänster kan Virtual Network nås direkt av det offentliga Internet. All inkommande (eller ingress)trafik måste gå via en mellanliggande trafikrouter. Alla komponenter i nätverket kan dock nå offentliga slutpunkter. Den utgående (eller utgående)trafiken måste uttryckligen skyddas så att endast säkra chiffer och TLS 1.2 eller senare tillåts.

• Azure Application Gateway integrerad WAF fångar upp all HTTP(S)-ingresstrafik och dirigerar inspekterad 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 dirigerar trafik till den konfigurerade servern. Till exempel Application Gateway 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 (utgående) trafik från betrodda och ej betrodda nätverk.

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

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

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

Interaktioner med slutpunkter för andra Azure-tjänster är via Internet. Se till att dessa interaktioner är säkra. Som en del av de vanliga åtgärderna behöver klustret till exempel hämta certifikat från det hanterade nyckelarkivet, hämta avbildningar från ett containerregister och så vidare. Du kan använda privata länkar för andra tjänster, till exempel Azure Key Vault och Azure Container Registry, för att utföra föregående uppgifter.

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

• NSG:erna i undernät som har nodpooler nekar all SSH-åtkomst till dess noder. Ha en process på plats för just-in-time-åtkomst vid akutfall samtidigt som principen neka alla upprätthålls.
• NSG:n i undernätet som har jumpboxen för att köra hanteringsverktyg nekar all trafik förutom från Azure Bastion i hubbnätverket.
• NSG:erna i undernät som har privata slutpunkter till Azure Key Vault och Azure Container Registry nekar all trafik förutom från den interna lastbalanseraren och trafiken över Azure Private Link.

Krav 1.2.2

Skydda och synkronisera routerkonfigurationsfiler.

Dina ansvarsområden

Ha en mekanism för att identifiera delta mellan det faktiska distribuerade tillståndet och det önskade tillståndet. Infrastruktur som kod (IaC) är ett bra val för detta ändamål. Exempel: Azure Resource Manager-mallar har en post med önskat tillstånd.

Distributionstillgångarna, till exempel ARM-mallar, måste vara källkontrollerade så att du har historiken över alla ändringar. Samla in information från Azure-aktivitetsloggar, distributionspipelineloggar och Azure-distributionsloggar. Dessa källor hjälper dig att hålla reda på distribuerade tillgångar.

I klustret bör nätverkskontroller som Kubernetes-nätverksprinciper också 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 i kombination med Flux- och API-loggar vara en källa för konfigurationshistorik.

Krav 1.2.3

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

Dina ansvarsområden

AKS-noderna och nodpoolerna får inte kunna nås från trådlösa nätverk. Dessutom måste begäranden till Kubernetes API-servern 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.

Dina ansvarsområden

AKS-klusternodpooler fungerar i det virtuella nätverket och isoleras från offentliga nätverk, till exempel Internet. Upprätthåll 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 Internettrafik blockeras. Information om kontrollerad åtkomst finns i DMZ-avsnittet.

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 ingress-kontrollanten för att dirigera trafik till arbetsbelastningens poddar. Oavsett typen 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 att underhålla klustrets tillstånd 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 över ett privat nätverk. Till exempel kan 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.

Dina ansvarsområden

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

• Konfigurera inte offentliga IP-adresser på nodpoolnoderna.
• Ha ingen offentlig lastbalanserare framför noderna. Trafiken i klustret måste dirigeras via interna lastbalanserare.
• Exponera endast interna lastbalanserare för att Azure Application Gateway integrerad med WAF.
• Alla nätverkskontroller bör ange begränsningar för källa, mål, port och protokoll, om tillämpligt.
• Gör inte API-servern exponerad 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 inom DMZ.

Dina ansvarsområden

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 integrerad med WAF. I AKS-klustret använder du Kubernetes NetworkPolicies för att begränsa ingresstrafik 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 förfalskning av 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.

Dina ansvarsområden

Här är några sätt att blockera obehörig utgående trafik:

• Tvinga all utgående (utgående) trafik från AKS-klustret att gå Azure Firewall. Ha användardefinierade vägar (UDR: er) i klusterundernät. Detta inkluderar 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ätsproxyn hantera TLS-verifieringen. Det exemplet visas i den här implementeringen. Envoy distribueras som proxy.
• Förhindra tillägg av offentliga IP-adresser i nätverken inom CDE om inte undernät uttryckligen auktoriserats, till exempel brandväggsundernät.

AKS kräver viss offentlig Internetåtkomst för att få åtkomst till det Azure-hanterade kontrollplanet. Klustret vill till exempel skicka mått och loggar till Azure Monitor. Du kan ange begränsade regler genom att ange käll- och mål-FQDN-mål eller FQDN-taggar. Även om användningen av taggar gör det enklare att ange regler kan vissa taggar innehålla fler mål än du behöver, vilket gör regeln för tillåtande. Granska taggarna för att se till att den har precis rätt mål som du behöver. Överväg att använda explicita regler för extra kontroll. Förstå att detta innebär en kompromiss av hantering och komplexitet, inklusive att ta bort regler som inte längre behövs.

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 förfalskning av 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 som är åtskild från DMZ och andra ej betrodda nätverk.

Dina ansvarsområden

Exponera dina lagringssystem endast över ett privat nätverk, till exempel genom att använda Private Link. Begränsa också åtkomsten från de undernät för nodpooler som kräver det. Håll tillståndet utanför 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.

Dina ansvarsområden

För att uppfylla det här kravet ä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 till för att förhindra avslöjande av false kontrollplanets privata IP-adress. Överväg att Azure Policy för att framtvinga användningen av privata kluster utan offentliga DNS-poster.

Använd också en privat DNS-zon för routning mellan undernätet som har Azure Application Gateway integrerad 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 huvudena eller brödtexten. Se till att loggar som kan innehålla IP- och DNS-poster inte exponeras utanför driftsbehoven.

En Azure-tjänst som är ansluten via Private Link har ingen offentlig DNS-post som exponerar dina 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:en.

Dina ansvarsområden

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 air-gapped jump box där du kan köra kommandona. Inkommande och utgående trafik från hoppboxen måste också 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 hoppboxen i ett separat undernät i ekernätverket. Inkommande åtkomst till jumpboxen 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 hoppboxen måste du nå offentliga slutpunkter. Till exempel slutpunkter som hanteras av Azure-hanteringsplanet. Den utgående trafiken måste vara säker. Precis som med andra komponenter i ekernätverket begränsas utgående trafik från jumpboxen med hjälp av en UDR som tvingar HTTPs-trafik att gå 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.

Dina ansvarsområden

Det är viktigt att du underhåller omfattande dokumentation om processen och principerna. Detta gäller särskilt när du hanterar Azure Firewall som segmenterar AKS-klustret. Personer som arbetar med reglerade miljöer måste utbildas, informeras och ges incitament för att stödja säkerhetsgarantin. Detta är särskilt viktigt för personer med konton som beviljas omfattande administratörsbehörighet.

Krav 2

Använd inte standardvärden från leverantören för systemlösenord och andra säkerhetsparametrar

Krav 2.1

Ändra alltid standardinställningarna från leverantören och ta bort eller inaktivera onödiga standardkonton innan du installerar ett system i nätverket.

Dina ansvarsområden

Standardinställningarna som tillhandahålls av leverantörer måste ändras. Standardinställningarna är vanliga attackvektorer och gör systemet känsligt för attacker. Här är några saker att tänka på:

• Inaktivera administratörsåtkomst i containerregistret.
• Se till att jumpboxar och bygga agenter följer användarhanteringsprocedurer, vilket tar bort systemanvändare som behövs.
• Generera eller tillhandahåll inte SSH-nyckelåtkomst till noder till administratörsanvändaren. Om åtkomst vid akutfall krävs använder du Azure-återställningsprocessen för att få just-in-time-åtkomst.

Azure-ansvarsområden

Azure Active Directory lösenordsprinciper som tillämpas på de nya lösenord som tillhandahålls av användarna. Om du ändrar ett lösenord krävs validering av äldre lösenord. Lösenord för administratörsåterställning måste ändras vid efterföljande inloggning.

Krav 2.1.1

För trådlösa miljöer som är anslutna till korthållardatamiljön eller som överför korthållardata ändrar du standardinställningarna för alla trådlösa leverantörer vid installationen, inklusive men inte begränsat till standard trådlösa krypteringsnycklar, lösenord och SNMP-gruppsträngar.

Dina ansvarsområden

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

Krav 2.2

Utveckla konfigurationsstandarder för alla systemkomponenter.

Dina ansvarsområden

Implementera rekommendationerna i Prestandatest för Azure-säkerhet. Den ger en 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 molnfunktioner och Azure Policy för att spåra mot standarderna. Benchmark för Azure-säkerhet är standardinitiativ för Microsoft Defender for Cloud. Överväg att skapa ytterligare automatiserade kontroller i Azure Policy och Azure Tenant Security Solution (AzTS).

Dokumentera det önskade konfigurationstillståndet för alla komponenter i CDE, särskilt för AKS-noder, jump box, byggaragenter och andra komponenter som interagerar med klustret.

Mer information finns i Prestandatest för Azure-säkerhet.

Azure-ansvar

Azure tillhandahåller säkerhetsstandarder som är konsekventa med bransch accepterade härdningsstandarder. Standarderna granskas minst en gång per å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 vara samtidigt på samma server. (Till exempel bör webbservrar, databasservrar och DNS implementeras på separata servrar.)

Dina ansvarsområden

Nyckelstrategin ä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 sam lokalisera 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 referensimplementering demonstreras den andra metoden med ett mikrotjänstprogram distribuerat till ett enda kluster. Programmet har två uppsättningar tjänster: en uppsättning har omfångsbaserade poddar 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 nod-dator.

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

Arbetsbelastningen bör använda podd-hanterad 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. Behåll klusterpoddar som är reserverade enbart för arbete som måste utföras som en del av bearbetningen av kortinnehavarens data. Flytta åtgärderna utanför klustret. Den här vägledningen gäller för byggaragenter, orelaterade arbetsbelastningar eller aktiviteter, till exempel att ha en jumpbox i klustret.

Krav 2.2.2

Aktivera endast nödvändiga tjänster, protokoll, daemons osv. som krävs för funktionen i systemet.

Dina ansvarsområden

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 SSL-standardprincipen för Azure Application Gateway. Kontrollera om principen är för tillåtande. Rekommendationen är att skapa en anpassad princip genom att bara välja de chiffer som du behöver.

För komponenter där du har fullständig kontroll tar du bort alla onödiga systemtjänster från avbildningarna (till exempel jumpboxar och bygga agenter).

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

Krav 2.2.3

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

Dina ansvarsområden

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

Anta att du har en äldre enhet som behöver interagera med CDE:en via Azure Application Gateway. Därför 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 upphört.

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

Om en arbetsbelastning i klustret inte kan följa organisationens policy för säkerhetsefterlevnadsprofiler eller andra kontroller (till exempel begränsningar 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.

Dina ansvarsområden

Alla Azure-tjänster som används i arkitekturen måste följa rekommendationerna från Azures säkerhetstest. De här rekommendationerna ger dig en startpunkt för att välja specifika säkerhetskonfigurationsinställningar. 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 på typen och konfigurationen av Azure-resurser. Använd Azure Policy för att förhindra dessa fall. I den här referensimplementering finns det en princip som nekar skapandet av AKS-kluster som inte är privata.

Kontrollera att alla undantag är dokumenterade.

Azure-ansvarsområden

Azure ser till att endast auktoriserad personal kan konfigurera azure-plattformens säkerhetskontroller med hjälp av multifaktoråtkomstkontroller och ett dokumenterat affärs behov.

Krav 2.2.5

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

Dina ansvarsområden

Installera inte programvara på jumpboxar eller bygga agenter 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 som DaemonSet och poddar. Kontrollera att alla installationer har identifierats och loggats.

Krav 2.3

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

Dina ansvarsområden

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

Azure-ansvarsområden

Azure ser till att användningen av stark kryptografi framtvingas vid åtkomst till hypervisor-infrastrukturen. Det säkerställer att kunder som använder Microsoft Azure Hanteringsportal kan komma åt sina tjänst-/IaaS-konsoler med stark kryptografi.

Krav 2.4

Upprätthåll en förteckning över systemkomponenter som omfattas av PCI DSS.

Dina ansvarsområden

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 eller utanför omfånget. Med hjälp av noggrann taggning kan du fråga efter resurser, hålla ett lager, spåra kostnader och ställa in aviseringar. Behåll även en ögonblicksbild av dokumentationen med jämna mellanrum.

Undvik att tagga omfångs- eller out-of-scope-resurser på detaljerad nivå. När lösningen utvecklas kan resurser utanför omfånget bli begränsade även om de indirekt interagerar eller ligger intill kortinnehavarens data. Dessa resurser granskas och kan ingå i ett representativt exempel 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 klusterobjekt 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 hantering av leverantörsstandarder och andra säkerhetsparametrar dokumenteras, används och är kända för alla berörda parter.

Dina ansvarsområden

Det är viktigt att du underhåller omfattande dokumentation om processer och principer. Personal bör utbildas i säkerhetsfunktionerna och konfigurationsinställningarna för varje Azure-resurs. Personer som arbetar med reglerade miljöer måste utbildas, informeras och ges incitament för att stödja säkerhetsgarantin. Detta är särskilt viktigt för administratörskonton som beviljas bred administratörsbehörighet.

Krav 2.6

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

Dina ansvarsområden

Azure tillhandahåller säkerhetssäkerhet för den värdmiljö som delas. Vi rekommenderar starkt att du använder dedikerade värdar för AKS-noder. Det innebär att beräkningen ska finnas i en enda klientmodell.

Nästa steg

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