Arkitektur för ett AKS-reglerat kluster för PCI-DSS 3.2.1 (del 2 av 9)

Den här artikeln beskriver en referensarkitektur för ett AKS-kluster (Azure Kubernetes Service) som kör en arbetsbelastning i enlighet med Payment Card Industry Data Security Standard (PCI-DSS 3.2.1). Den här arkitekturen fokuserar på infrastrukturen och inte på PCI-DSS 3.2.1-arbetsbelastningen.

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

Rekommendationerna och exemplen extraheras från den här tillhörande referensimplementeringen:

GitHub: Azure Kubernetes Service -baslinjeklustret (AKS) för reglerade arbetsbelastningar visar den reglerade infrastrukturen. Den här implementeringen tillhandahåller ett mikrotjänstprogram. Det ingår för att hjälpa dig att uppleva infrastrukturen och illustrera nätverks- och säkerhetskontrollerna. Programmet representerar eller implementerar inte en faktisk PCI DSS-arbetsbelastning.

Ladda ned en Visio-fil med den här arkitekturen.

Nätverksarkitekturen baseras på en topologi med nav-ekrar. Det virtuella hubbnätverket innehåller brandväggen för att styra utgående trafik, gatewaytrafik från lokala nätverk och ett tredje nätverk för SRE-klusteråtkomst (platstillförlitlighetstekniker). Det finns två virtuella ekernätverk. En eker innehåller AKS-klustret som är en komponent i korthållarmiljön (CDE) och är värd för PCI DSS-arbetsbelastningen. Den andra ekern skapar avbildningar av virtuella datorer som används för kontrollerad SRE-åtkomst till miljön.

Komponenter

Här är de viktigaste komponenterna som används i den här arkitekturen. Om du inte är bekant med dessa tjänster kan du läsa relaterade Azure-tjänster för länkar till produktdokumentationen.

Azure Firewall

Brandväggsinstansen skyddar utgående nätverkstrafik. Utan det här säkerhetsskiktet kan flödet kommunicera med en skadlig tjänst från tredje part som kan exfiltera känsliga företagsdata.

Azure Bastion

Baslinjearkitekturen tillhandahöll ett undernät för Azure Bastion, men etablerade inte resursen. Den här arkitekturen lägger till Azure Bastion i undernätet och ger säker åtkomst till en hoppruta.

Azure Image Builder

Den etableras i ett separat virtuellt nätverk och skapar VM-avbildningar med bassäkerhet och konfiguration. I den här arkitekturen är den anpassad för att skapa säkra nodbilder med hanteringsverktyg som Azure CLI och kubectlFlux CLI förinstallerade.

Skalningsuppsättningar för virtuella Azure-datorer för jump box-instanser

Ekernätverket har ytterligare beräkning för en hoppruta. Den här skalningsuppsättningen är avsedd att vara den reglerade åtkomstpunkten för att köra verktyg mot AKS-klustret, till exempel kubectl, efter behov.

Azure Application Gateway med integrerad brandvägg för webbprogram (WAF)

Azure Application Gateway lastbalanserar på Layer 7. WAF skyddar inkommande trafik från vanliga webbtrafikattacker. Instansen har en offentlig IP-konfiguration för klientdelen som tar emot användarbegäranden.

Azure Kubernetes Service (AKS)

Värdinfrastrukturen, som är en viktig del av korthållardatamiljön (CDE). AKS-klustret distribueras som ett privat kluster. Kubernetes API-servern exponeras därför inte för det offentliga Internet, och trafiken till API-servern är begränsad till ditt privata nätverk.

ACR-uppgifter

Ger ett automatiserat sätt att skapa och underhålla containeravbildningar.

Azure Key Vault

Lagrar och hanterar hemligheter som behövs för klusteråtgärder, till exempel certifikat och krypteringsnycklar.

Klusterkonfiguration

Här följer några viktiga ändringar från baslinjearkitekturen:

Segmentering av nodpool

I den här arkitekturen har klustret två användarnodpooler och en systemnodpool. Beräkningsalternativet för nodpoolerna förblir detsamma som i baslinjearkitekturen. Till skillnad från baslinjearkitekturen finns varje nodpool i ett dedikerat undernät för att tillhandahålla en extra nätverksisoleringsgräns mellan beräkningsnivåer.

PCI-DSS 3.2.1 kräver isolering av PCI-arbetsbelastningen från andra arbetsbelastningar när det gäller åtgärder och anslutning.

• Omfång: PCI-arbetsbelastningen, miljön där den finns och åtgärder.

• Utanför omfånget: Andra arbetsbelastningar som kan dela tjänster, men som är isolerade från komponenterna i omfånget.

Den viktigaste strategin är att tillhandahålla den nivå av separation som krävs. Det bästa sättet är att distribuera komponenter inom omfång och utanför omfånget i separata kluster. Nackdelen med att använda flera kluster är de högre kostnaderna för den extra infrastrukturen och underhållskostnaderna. Den här implementeringen samlokalsöker alla komponenter i ett delat kluster för enkelhetens skull. Om du väljer att följa modellen med ett kluster använder du en rigorös segmenteringsstrategi i klustret. Oavsett hur du väljer att behålla separationen bör du vara medveten om att när din lösning utvecklas kan vissa komponenter utanför omfånget bli omfångsbaserade.

I referensimplementeringen demonstrerar vi metoden för delat kluster genom att distribuera ett mikrotjänstprogram till ett enda kluster. Arbetsbelastningarna in-scope och out-of-scope segmenteras i två separata användarnodpooler. 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. Genom att använda Kubernetes-taints distribueras poddar inom omfång och utanför omfånget till separata noder och de delar aldrig en virtuell noddator eller nätverkets IP-utrymme.

Ingångskontrollant

Baslinjearkitekturen använde Traefik för ingresskontroll. I den här referensarkitekturen använder vi i stället Nginx. Den här ändringen visar att den här komponenten kan ändras baserat på dina arbetsbelastningars krav.

Privat Kubernetes API-server

Baslinjearkitekturen distribuerade AKS-klustret i offentligt läge. Det innebär att all kommunikation med DEN AKS-hanterade Kubernetes API-servern sker via det offentliga Internet. Detta är inte acceptabelt i den här arkitekturen eftersom PCI-DSS 3.2.1 förbjuder offentlig exponering för systemkomponenter. I den här reglerade arkitekturen distribueras klustret som ett privat kluster. Nätverkstrafiken till Kubernetes API-servern är begränsad till ditt privata nätverk. API-servern exponeras via en privat slutpunkt i klustrets nätverk. Säkerheten förbättras ytterligare med hjälp av nätverkssäkerhetsgrupper och andra inbyggda funktioner. Dessa beskrivs i Nätverkskonfiguration.

Podsäkerhet

När du beskriver arbetsbelastningens säkerhetsbehov använder du relevanta securityContext inställningar för dina containrar. Detta inkluderar grundläggande inställningar som fsGroup,runAsGrouprunAsUser / och inställning allowPrivilegeEscalation till false (om det inte krävs). Var tydlig med att definiera och ta bort Linux-funktioner och definiera dina SELinux-alternativ i seLinuxOptions.

Undvik att referera till avbildningar med deras taggar i distributionsmanifesten. Använd i stället det faktiska avbildnings-ID:t. På så sätt kan du på ett tillförlitligt sätt mappa resultatet av containergenomsökningen med det faktiska innehållet som körs i klustret. Du kan framtvinga det via Azure Policy för att avbildningsnamnet ska inkludera bild-ID-mönstret i det tillåtna reguljära uttrycket. Följ även den här vägledningen när du använder Dockerfile-instruktionen FROM .

Nätverkskonfiguration

Hub-ekrarna distribueras alla i separata virtuella nätverk, var och en i sitt privata adressutrymme. Som standard tillåts ingen trafik mellan två virtuella nätverk. Inom nätverket tillämpas segmentering genom att skapa undernät.

En kombination av olika Azure-tjänster och funktioner och inbyggda Kubernetes-konstruktioner ger den kontrollnivå som krävs. Här följer några alternativ som används i den här arkitekturen.

Undernätssäkerhet via nätverkssäkerhetsgrupper (NSG:er)

Det finns flera NSG:er som styr flödet in och ut ur klustret. Nedan följer några exempel:

• Klusternodpoolerna placeras i dedikerade undernät. För varje undernät finns det NSG:er som blockerar all SSH-åtkomst till virtuella noddatorer och tillåter trafik från det virtuella nätverket. Trafik från nodpoolerna är begränsad till det virtuella nätverket.

• All inkommande trafik från Internet fångas upp av Azure Application Gateway. NSG-regler ser till exempel till att:

  • Endast HTTPS-trafik tillåts i.
  • Trafik från Azure-kontrollplanet tillåts med hjälp av tjänsttaggar. Mer information finns i Tillåt åtkomst till några käll-IP-adresser.

• I de undernät som har Azure Container Registry-agenter tillåter NSG:er endast nödvändig utgående trafik. Till exempel tillåts trafik till Azure Key Vault, Microsoft Entra-ID, Azure Monitor och andra tjänster som containerregistret behöver prata med.

• Undernätet med hopprutan är avsett för hanteringsåtgärder. NSG-regeln i jump box-undernätet tillåter endast SSH-åtkomst från Azure Bastion i hubben och begränsade utgående anslutningar. Hopprutor har inte universell internetåtkomst och styrs i både undernätets NSG och Azure Firewall.

När dina arbetsbelastningar, systemsäkerhetsagenter och andra komponenter distribueras lägger du till fler NSG-regler som hjälper dig att definiera vilken typ av trafik som ska tillåtas. Trafiken ska inte passera dessa undernätsgränser. Eftersom varje nodpool finns i ett eget undernät, observerar du trafikmönstren och tillämpar sedan mer specifika regler.

Podd-till-pod-säkerhet med nätverksprinciper

Den här arkitekturen försöker implementera "noll förtroende"-principerna för Microsoft så mycket som möjligt.

Exempel på noll förtroendenätverk som koncept visas i implementeringen, inom namnrymderna a0005-i och a0005-o de namnområden som tillhandahålls av användaren. Varje arbetsbelastningsnamnområde bör ha en restriktiv NetworkPolicy tillämpad. Principdefinitionerna beror på vilka poddar som körs i dessa namnområden. Se till att du redovisar beredskap, livlighet och startavsökningar och tillåter mått som samlas in av Log Analytics-agenten. Överväg att standardisera på portar i dina arbetsbelastningar så att du kan tillhandahålla en konsekvent NetworkPolicy- och Azure Policy för tillåtna containerportar.

I vissa fall är detta inte praktiskt för kommunikation inom klustret. Alla namnområden som tillhandahålls av användaren kan inte använda ett nätverk med noll förtroende (det går till exempel cluster-baseline-settings inte att använda ett).

TLS-kryptering

Baslinjearkitekturen tillhandahåller TLS-krypterad trafik tills ingresskontrollanten i klustret, men podd-till-pod-kommunikationen är klar. I den här arkitekturen utökas TLS till poddar-till-podd-trafik, med certifikatutfärdarvering (CA). Denna TLS tillhandahålls av ett tjänstnät som framtvingar mTLS-anslutningar och verifiering innan kommunikation tillåts.

Implementeringen använder mTLS. mTLS-stöd kan implementeras med eller utan ett tjänstnät. Om du använder ett nät kontrollerar du att det är kompatibelt med valfri certifikatutfärdare. Den här implementeringen använder Open Service Mesh.

Ingresskontrollanten i den här implementeringen använder ett jokerteckencertifikat för att hantera standardtrafik när en ingressresurs inte innehåller något specifikt certifikat. Detta kan vara acceptabelt, men om din organisationsprincip inte tillåter användning av jokerteckencertifikat kan du behöva justera ingresskontrollanten för att inte använda ett jokerteckencertifikat.

Nätverksbegränsningar för Azure Key Vault

Alla hemligheter, nycklar och certifikat lagras i Azure Key Vault. Key Vault hanterar certifikathanteringsuppgifter, till exempel rotation. Kommunikationen med Key Vault sker via Azure Private Link. DNS-posten som är associerad med Key Vault finns i en privat DNS-zon så att den inte kan matchas från Internet. Detta förbättrar säkerheten, men det finns vissa begränsningar.

Azure Application Gateway stöder inte TLS-källcertifikat för HTTP-lyssnaren från Key Vault-instanser som exponeras med Private Link. Implementeringen distribuerar därför Key Vault i en hybridmodell. Den använder fortfarande Private Link för anslutningar som stöder det, men tillåter även offentlig åtkomst för Application Gateway-integrering. Om den här hybridmetoden inte är lämplig för distributionen flyttar du certifikathanteringsprocessen till Application Gateway. Detta lägger till hanteringskostnader, men sedan isoleras Key Vault-instansen helt. Mer information finns i:

• Azure Application Gateway och Key Vault-integrering
• Skapa en programgateway med TLS-avslutning med hjälp av Azure CLI.

DDoS-skydd

Om du har några virtuella nätverk med offentliga IP-adresser aktiverar du Azure DDoS Network Protection. I den här referensarkitekturen har undernätet som innehåller Application Gateway en offentlig IP-adress bifogad, så den är i omfånget för DDoS-skydd.

Azure DDoS Network Protection skyddar infrastrukturen och arbetsbelastningen från massbedrägeribegäranden. Sådana begäranden kan orsaka avbrott i tjänsten eller maskera en annan samtidig attack. Azure DDoS Network Protection kostar mycket och amorteras vanligtvis över många arbetsbelastningar som sträcker sig över många IP-adresser. Arbeta med nätverksteamet för att samordna täckningen för dina arbetsbelastningar.

Identitets- och åtkomsthantering

Definiera roller och ange åtkomstkontroll enligt rollens krav. Mappa roller till Kubernetes-åtgärder som är begränsade så snävt som praktiskt. Undvik roller som omfattar flera funktioner. Om flera roller fylls av en person tilldelar du den personen alla roller som är relevanta för motsvarande jobbfunktioner. Så även om en person är direkt ansvarig för både klustret och arbetsbelastningen skapar du dina Kubernetes ClusterRolesom om det fanns separata individer. Tilldela sedan den enskilda individen alla relevanta roller.

Minimera stående åtkomst, särskilt för konton med hög påverkan, till exempel SRE/Ops-interaktioner med klustret. AKS-kontrollplanet stöder både MICROSOFT Entra ID Privileged Access Management (PAM) just-in-time (JIT) och principer för villkorsstyrd åtkomst, vilket ger ytterligare ett lager av nödvändig autentiseringsverifiering för privilegierad åtkomst, baserat på de regler som du skapar.

Mer information om hur du använder PowerShell för att konfigurera villkorlig åtkomst finns i New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy och Remove-MgIdentityConditionalAccessPolicy.

Diskkryptering

När du utformar kryptering för vilande data bör du överväga lagringsdiskar, virtuella AKS-agentnoder, andra virtuella datorer och eventuella temporära diskar och operativsystemdiskar.

Lagringsdiskar

Som standard krypteras Azure Storage-diskar i vila med Microsoft-hanterade nycklar. Om du använder icke-tillfälliga operativsystemdiskar eller lägger till datadiskar rekommenderar vi att du använder kundhanterade nycklar för kontroll över krypteringsnycklarna. Kryptera utanför lagringslagret och skriv endast krypterade data till lagringsmediet. Kontrollera också att nycklarna aldrig ligger i anslutning till lagringsskiktet. Mer information finns i Byok (Bring Your Own Keys) med Azure-diskar.

Överväg att använda BYOK för andra diskar som kan interagera med klustret, till exempel dina Azure Bastion-frontade hopprutor. Om du väljer BYOK begränsas SKU-valet för virtuella datorer och regional tillgänglighet eftersom den här funktionen inte stöds på alla SKU:er eller regioner.

VM-värdar

Vi rekommenderar att du aktiverar funktionen encryption-at-host. Detta krypterar den virtuella datorns värd och eventuella tillfälliga operativsystem eller datadiskar som cachelagras på en virtuell datorvärd. Läs mer om stöd för virtuella datorer för värdbaserad kryptering.

Den funktionen utökas till data som lagras på den virtuella datorns värd för dina AKS-agentnoder via funktionen Värdbaserad kryptering . På samma sätt som BYOK kan den här funktionen begränsa alternativen för vm-SKU:n och regionen.

Du kan framtvinga dessa funktioner via Azure Policy.

Klustersäkerhetskopior (tillstånd och resurser)

Om din arbetsbelastning kräver lagring i klustret ska du ha en robust och säker process för säkerhetskopiering och återställning. Överväg tjänster som Azure Backup (för Azure Disks och Azure Files) för säkerhetskopiering och återställning av alla PersistentVolumeClaim. Det finns fördelar om säkerhetskopieringssystemet stöder inbyggda Kubernetes-resurser. Du kan komplettera din primära metod som stäms av klustret till ett välkänt tillstånd, med säkerhetskopieringssystemet för kritiska systemåterställningstekniker. Det kan till exempel hjälpa dig att identifiera och katalogisera systemtillståndsändringar över tid på Kubernetes-resursnivå.

Säkerhetskopieringsprocesser måste klassificera data i säkerhetskopian, oavsett om dessa data kom från klustret eller var externa till klustret. Om data finns i omfånget för PCI DSS 3.2.1 utökar du dina efterlevnadsgränser så att de inkluderar säkerhetskopieringens livscykel och mål, som ligger utanför klustret. Säkerhetskopior kan vara en attackvektor. När du utformar din säkerhetskopia bör du överväga geografiska begränsningar, kryptering i vila, åtkomstkontroller, roller och ansvarsområden, granskning, time-to-live och manipuleringsskydd.

Säkerhetskopieringssystem i kluster förväntas köras med hög behörighet under driften. Utvärdera risken och fördelen med att föra in en säkerhetskopieringsagent i klustret. Överlappar agentfunktionen en annan hanteringslösning i klustret? Vilken är den minsta uppsättning verktyg som du behöver för att utföra den här uppgiften utan att expandera attackytan?

Överväganden för Azure Policy

Azure-principer som tillämpas har vanligtvis inte arbetsbelastningsjusterade inställningar. I implementeringen tillämpar vi kubernetes-klustrets säkerhetsstandarder för begränsade Linux-baserade arbetsbelastningar, vilket är ett av de inbyggda principinitiativen. Det här initiativet tillåter inte justering av inställningar. Överväg att exportera det här initiativet och anpassa dess värden för din specifika arbetsbelastning. Du kan inkludera alla Gatekeeper deny Azure-principer under ett anpassat initiativ och alla audit Azure-principer under ett annat initiativ. Detta kategoriserar blockåtgärder från informationsprinciper.

Överväg att inkludera kube-system namnrymderna och gatekeeper-system till principer i granskningsprinciperna för ökad synlighet. Att inkludera dessa namnområden i neka-principer kan orsaka klusterfel på grund av en konfiguration som inte stöds.

Du kan framtvinga datakryptering genom att ange vissa Azure Policy-aviseringar. Du kan till exempel framtvinga BYOK med en avisering som identifierar kluster som inte har diskEncryptionSetID på klusterresursen. En annan princip kan identifiera om värdbaserad kryptering är aktiverad på agentPoolProfiles. Referensimplementeringen använder inga diskar i klustret och operativsystemdisken är tillfälliga. Båda dessa exempelprinciper finns på plats som en påminnelse om säkerhetsfunktionen. Principerna är inställda på audit, inte block.

Hantera avbildningar

Använd distributionslösa basavbildningar för dina arbetsbelastningar. Med dessa bilder minimeras säkerhetsytan eftersom kompletterande bilder, till exempel gränssnitt och pakethanterare, tas bort. En förmån är minskade CVE-träfffrekvenser.

Azure Container Registry stöder avbildningar som uppfyller avbildningsformatspecifikationen för Open Container Initiative (OCI). Detta, tillsammans med en antagningskontrollant som stöder validering av signaturer, kan säkerställa att du bara kör avbildningar som du har signerat med dina privata nycklar. Det finns lösningar med öppen källkod som SSE Connaisseur eller IBM Portieris som integrerar dessa processer.

Skydda containeravbildningar och andra OCI-artefakter eftersom de innehåller organisationens immateriella rättigheter. Använd kundhanterade nycklar och kryptera innehållet i dina register. Som standard krypteras data i vila med tjänsthanterade nycklar, men kundhanterade nycklar krävs ibland för att uppfylla regelefterlevnadsstandarder. Lagra nyckeln i ett hanterat nyckelarkiv, till exempel Azure Key Vault. Eftersom du skapar och äger nyckeln ansvarar du för åtgärder relaterade till nyckellivscykeln, inklusive rotation och hantering. Mer information finns i Kryptera registret med hjälp av en kundhanterad nyckel.

Driftåtkomst för Kubernetes API Server

Du kan begränsa kommandon som körs mot klustret, utan att nödvändigtvis skapa en driftsprocess baserad på hopprutor. Om du har en IAM-gated IT-automatiseringsplattform använder du de fördefinierade åtgärderna för att kontrollera och granska typen av åtgärder.

Skapa agenter

Pipelineagenter bör vara utanför omfånget för det reglerade klustret eftersom byggprocesser kan vara hotvektorer. Till exempel fungerar byggprocesser ofta med otestade och ej betrodda komponenter.

Det är vanligt att använda Kubernetes som en elastisk byggagentinfrastruktur, men kör inte den processen inom gränsen för den reglerade arbetsbelastningskörningen. Dina byggagenter bör inte ha direkt åtkomst till klustret. Ge till exempel bara byggagenter nätverksåtkomst till Azure Container Registry för att skicka containeravbildningar, helm-diagram och så vidare. Distribuera sedan via GitOps. Som vanligt bör bygg- och versionsarbetsflöden inte ha direkt åtkomst till ditt Kubernetes-kluster-API (eller dess noder).

Övervakningsåtgärder

Aktiviteter i klustret

Poddar i klustret omsagent som körs i kube-system är Log Analytics-samlingsagenten. De samlar in telemetri, skrapar container stdout och stderr loggar och samlar in Prometheus-mått. Du kan justera samlingsinställningarna genom att container-azm-ms-agentconfig.yaml uppdatera ConfigMap-filen. I den här referensimplementeringen aktiveras loggning över kube-system och alla dina arbetsbelastningar. Som standard kube-system undantas från loggning. Se till att du justerar logginsamlingsprocessen för att uppnå balanskostnadsmål, SRE-effektivitet när du granskar loggar och efterlevnadsbehov.

Säkerhetsövervakning

Använd Defender för containrar i Microsoft Defender för molnet för att visa och åtgärda säkerhetsrekommendationer och för att visa säkerhetsaviseringar på dina containerresurser. Aktivera Microsoft Defender-planer när de gäller för olika komponenter i korthållardatamiljön.

Integrera loggar så att du kan granska, analysera och köra frågor mot data effektivt. Azure har flera alternativ. Du kan aktivera AKS-diagnostikloggar och skicka dem till en Log Analytics-arbetsyta som ingår i Azure Monitor. Ett annat alternativ är att integrera data i SIEM-lösningar (säkerhetsinformation och händelsehantering), till exempel Microsoft Sentinel.

Enligt standarden är alla Log Analytics-arbetsytor inställda på en kvarhållningsperiod på 90 dagar. Överväg att konfigurera kontinuerlig export för långsiktig lagring. Lagra inte känslig information i loggdata och se till att åtkomsten till arkiverade loggdata omfattas av samma åtkomstkontroller som de senaste loggdata.

Ett fullständigt perspektiv finns i Microsoft Defender för molnet Onboarding Guide för företag. Den här guiden behandlar registrering, dataexport till dina SIEM-lösningar, svarar på aviseringar och skapar arbetsflödesautomatisering.

Relaterade Azure-tjänster

Här följer länkar till funktionsdokumentation för vissa viktiga komponenter i den här arkitekturen.

• Azure Kubernetes Service (AKS)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• Skalningsuppsättningar för virtuella Microsoft Azure-datorer
• Azure Application Gateway med integrerad brandvägg för webbprogram (WAF)
• Azure Container Registry-uppgifter
• Azure Key Vault

Nästa steg

Installera och underhålla en brandväggskonfiguration för att skydda korthållardata. Använd inte standardvärden som tillhandahålls av leverantören för systemlösenord och andra säkerhetsparametrar.