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 Azure Kubernetes Service-kluster (AKS) 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 arbetsbelastningen PCI-DSS 3.2.1.

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

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

GitHub: Azure Kubernetes Service (AKS) Baslinjekluster för reglerade arbetsbelastningar visar den reglerade infrastrukturen. Den här implementeringen tillhandahåller ett mikrotjänstprogram. Den 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.

Nätverksarkitekturen baseras på en topologi av nav och 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. Det finns två virtuella ekernätverk. En eker innehåller AKS-klustret som är en komponent i kortinnehavarens miljö (CDE) och är värd för PCI DSS arbetsbelastningen. De andra ekrarna skapar avbildningar av virtuella datorer som används för kontrollerad SRE-åtkomst till miljön.

Komponenter

Här är huvudkomponenterna 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äkerhetslagret kan flödet kommunicera med en skadlig tredjepartstjänst som kan exfiltrera 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 Azure Bastion i undernätet. Det ger säker åtkomst till en jumpbox.

Azure Image Builder

Etableras i ett separat virtuellt nätverk. Skapar VM-avbildningar med grundläggande säkerhet och konfiguration. I den här arkitekturen är den anpassad för att skapa säkra nodavbildningar med hanteringsverktyg som Azure kubectl CLI, och Flux CLI förinstallerade.

Azure Virtual Machine Scale Sets för jump box-instanser

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

Azure Application Gateway med integrerad Web Application Firewall (WAF)

Azure Application Gateway belastningsutjämning i lager 7. WAF skyddar inkommande trafik från vanliga webbtrafikattacker. Instansen har en OFFENTLIG IP-konfiguration för serversidan 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

Tillhandahåller 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 är några viktiga ändringar från baslinjearkitekturen:

Segmentering av nodpool

I den här arkitekturen har klustret två användarnodpooler och en systemnodpool. Beräkningsvalet för nodpoolerna förblir detsamma. Varje nodpool finns i ett dedikerat undernät för att tillhandahålla en extra gräns för nätverksisolering mellan beräkningsnivåer.

PCI-DSS 3.2.1 kräver isolering av PCI-arbetsbelastningen från andra arbetsbelastningar vad gäller drift och anslutning.

• Inomfå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 de komponenter som ingår i omfånget.

Nyckelstrategin är att tillhandahålla den nödvändiga separationsnivån. Det bästa sättet är att distribuera omfångs- och out-of-scope-komponenter i separata kluster. Den lägre sidan ökar kostnaderna för den extra infrastrukturen och underhållskostnaderna. Den här implementeringen sam lokaliserar alla komponenter i ett delat kluster för enkelhetens skull. Om du väljer att följa den modellen använder du en rigorös segmenteringsstrategi i klustret. Oavsett hur du väljer att upprätthålla separationen bör du vara medveten om att när din lösning utvecklas kan vissa komponenter utanför omfånget bli begränsade.

I referensimplementering demonstreras den andra metoden med ett mikrotjänstprogram distribuerat till ett enda kluster. Arbetsbelastningar inom och utanför omfånget är indelade i två separata användarnodpooler. 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 noder och de delar aldrig en virtuell nod eller nätverkets IP-utrymme.

Ingress-kontrollant

Kubernetes-indatakontrollanten i klustret har ändrats till NGINX. I baslinjearkitekturen använde Traefik. 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 är 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 alla 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 din arbetsbelastnings säkerhetsbehov använder du relevanta securityContext inställningar för dina containrar. Detta inkluderar grundläggande inställningar som fsGroup , och inställning till falskt runAsUser / runAsGroupallowPrivilegeEscalation (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 bilder med deras taggar i dina distributionsmanifest. Använd i stället det faktiska avbildnings-ID:t. På så sätt kan du på ett tillförlitligt sätt mappa sökresultat för containrar med det faktiska innehållet som körs i klustret. Du kan framtvinga det via Azure Policy för avbildningsnamn för att 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 FROM Dockerfile-instruktionen.

Nätverkskonfiguration

Alla nav-ekrar distribueras i separata virtuella nätverk, var och en i sitt privata adressutrymme. Som standard tillåts ingen trafik mellan två virtuella nätverk. Segmentering tillämpas i nätverket genom att undernät skapas.

En kombination av olika Azure-tjänster och -funktioner och inbyggda Kubernetes-konstruktioner ger den kontrollnivå som krävs. Här är 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. Här är några exempel:

• Klusternodpoolerna placeras i dedikerade undernät. För varje undernät finns det NSG:er som blockerar SSH-åtkomst till nod-VM:ar 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. Mer information finns i Tillåt åtkomst till några käll-IP-adresser.

• På de undernät som har Azure Container Registry tillåter NSG:er endast nödvändig utgående trafik. Trafik tillåts till exempel att Azure Key Vault, Azure Active Directory, Azure Monitor och andra tjänster som containerregistret behöver prata med.

• Undernätet med jumpbox är avsett för hanteringsåtgärder. NSG-regeln tillåter endast SSH-åtkomst från Azure Bastion i hubben och begränsade utgående anslutningar. Jumpboxar 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 sitt eget undernät bör du observera trafikmönstren och sedan tillämpa mer specifika regler.

Pod-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örtroende nätverk som ett koncept visas i implementeringen av a0005-i och a0005-o användarbaserade namnrymder. Alla namnområden för arbetsbelastningar bör ha en begränsande NetworkPolicy tillämpad. Principdefinitionerna beror på vilka poddar som körs i dessa namnområden. Se till att du tar hänsyn till beredskap, realtidsinställningar och startavsökningar och tillåtna för mått som samlas in av Log Analytics-agenten. Överväg att standardisera 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 i klustret. Alla namnområden som anges av användaren kan inte använda ett nätverk utan förtroende cluster-baseline-settings (till exempel kan inte använda ett).

TLS-kryptering

Baslinjearkitekturen tillhandahåller TLS-krypterad trafik tills ingress-kontrollanten i klustret, men pod-till-pod-kommunikationen är tydlig. I den här arkitekturen utökas TLS till podd-till-pod-trafik med certifikatutfärdarvalidering. Denna TLS tillhandahålls av ett tjänstnät, som tillämpar 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 måste du se till att det är kompatibelt med den certifikatutfärdare du väljer. Den här implementeringen använder Open Service Mesh.

Ingress-kontrollanten i den här implementeringen använder ett jokerteckencertifikat för att hantera standardtrafik när en ingressresurs inte innehåller ett specifikt certifikat. Detta kan vara acceptabelt, men om organisationens princip inte tillåter användning av jokerteckencertifikat kan du behöva justera ingresskontrollanten så att den inte använder ett jokerteckencertifikat.

Azure Key Vault nätverksbegränsningar

Alla hemligheter, nycklar och certifikat lagras i Azure Key Vault. Key Vault hanterar certifikathanteringsuppgifter, till exempel rotation. Kommunikationen med Key Vault är över Azure Private Link. DNS-posten som är Key Vault är 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-certifikat för HTTP-lyssnare 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 hybrid metoden inte är lämplig för distributionen flyttar du certifikathanteringsprocessen till Application Gateway. Detta lägger till hanteringskostnader, men sedan Key Vault instansen helt isolerad. 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

Aktivera Azure DDoS Protection Standard för virtuella nätverk med ett undernät som innehåller Application Gateway med en offentlig IP-adress. På så sätt skyddas infrastrukturen och arbetsbelastningen från falska massbegäranden. Sådana begäranden kan orsaka avbrott i tjänsten eller maskera en annan samtidig attack. Azure DDoS innebär en betydande kostnad och amorteras vanligtvis över många arbetsbelastningar som sträcker sig över många IP-adresser. Samarbeta med nätverksteamet för att samordna täckningen för din arbetsbelastning.

Identitetsåtkomsthantering

Definiera roller och ange åtkomstprinciper enligt kraven för rollen. Mappa roller till Kubernetes-åtgärder som är begränsade som praktiska. Undvik roller som sträcker sig över flera funktioner. Om flera roller fylls av en person tilldelar du 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 kubernetes som om det ClusterRoles fanns separata personer. Tilldela sedan den enskilda personen 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 Just-In-Time (JIT) för Azure AD Privileged Access Management (PAM). Principer för villkorsstyrd åtkomst kan ge ytterligare 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 Villkorsstyrd åtkomst för Azure AD.

Diskkryptering

När du utformar kryptering för vilodata bör du överväga lagringsdiskar, virtuella datorer med AKS-agentnoder, andra virtuella datorer och eventuella tillfälliga diskar och operativsystemdiskar.

Storage diskar

Som standard krypteras Azure Storage 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 kund hanterade nycklar för kontroll över krypteringsnycklarna. Kryptera utanför lagringslagret och skriv endast krypterade data till lagringsmediet. Kontrollera också att nycklarna aldrig ligger intill lagringsskiktet.

Mer information finns i Bing egna nycklar (BYOK) med Azure-diskar.

Överväg att använda BYOK för alla andra diskar som kan interagera med klustret, till exempel Azure Bastion-frontade jumpboxar. 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 datorvärden och eventuella tillfälliga operativsystem eller datadiskar som cachelagras på en virtuell datorvärd. Läs mer om vm-stöd för värdbaserad kryptering.

Funktionen utökas till de data som lagras på VM-värden för dina AKS-agentnoder via funktionen värdbaserad kryptering. På samma sätt som med BYOK kan den här funktionen begränsa dina SKU-alternativ för virtuella datorer och regioner.

Du kan tillämpa dessa funktioner via Azure Policy.

Klustersäkerhetskopior (tillstånd och resurser)

Om din arbetsbelastning kräver lagring i klustret bör 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-diskar och Azure Files) för säkerhetskopiering och återställning av PersistantVolumeClaim alla . Det finns fördelar om säkerhetskopieringssystemet stöder interna Kubernetes-resurser. Du kan komplettera din primära metod som synkroniserar klustret med ett välkänt tillstånd, med säkerhetskopieringssystemet för kritiska systemåterställningstekniker. Det kan till exempel vara till hjälp vid identifiering av drift och katalogisering av systemtillståndsändringar över tid på Kubernetes-resursnivå.

Säkerhetskopieringsprocesser måste klassificera data i säkerhetskopian inom eller utanför klustret. Om data finns i omfånget för PCI DSS 3.2.1 utökar du efterlevnadsgränserna så att de omfattar livscykeln och målet för säkerhetskopieringen, som kommer att finnas utanför klustret. Säkerhetskopieringar kan vara en attackvektor. När du utformar säkerhetskopieringen 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 klustret 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 agentkapaciteten en annan hanteringslösning i klustret? Vilken är den minsta uppsättningen verktyg som du behöver för att utföra den här uppgiften utan att expandera angreppsytan?

Azure Policy överväganden

Normalt har inte Azure-principer som tillämpas arbetsbelastningsre tunede inställningar. I implementeringen tillämpar vi Kubernetes-klustrets säkerhetsstandarder för poddsäkerhet för Linux-baserade arbetsbelastningar, som inte tillåter inställningsjustering. Ö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. På så sätt kategoriseras blockera åtgärder från endast informationsprinciper.

Överväg att inkludera kube-systemgatekeeper-system namnrymderna och i principer i dina kube-system ökad synlighet. Om dessa namnområden inkluderas i neka-principer kan det 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 Host-Based kryptering är aktiverat på agentPoolProfiles . Referensimplementering använder inte några 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 distributionsbaserade basavbildningar för dina arbetsbelastningar. Med dessa bilder minimeras säkerhetsytan eftersom tilläggsbilder, till exempel gränssnitt och pakethanterare, tas bort. En fördel är minskade CVE-träffpriser.

Azure Container Registry stöder avbildningar som uppfyller OCI-avbildningsformatspecifikationen (Open Container Initiative). Detta tillsammans med en antagningskontrollant som stöder validering av signaturer kan se till 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 egendom. Använd kund hanterade nycklar och kryptera innehållet i dina register. Som standard krypteras data i vila med tjänst hanterade nycklar, men kundbaserade 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 som rör nyckellivscykeln, inklusive rotation och hantering. Mer information finns i Kryptera registret med en kund hanterad 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 driftprocess som baseras på hopprutor. Om du har en IAM-gated IT-automatiseringsplattform kan du använda de fördefinierade åtgärderna för att kontrollera och granska typen av åtgärder.

Bygga agenter

Pipelineagenter bör vara utanför det reglerade klustret eftersom byggprocesser kan vara hotvektorer. Det är vanligt att använda Kubernetes som en elastisk byggaragentinfrastruktur, men kör inte den processen inom gränsen för den reglerade arbetsbelastningskörningen. Dina byggaragenter bör inte ha direkt åtkomst till klustret. Ge till exempel bara byggaragenter nätverksåtkomst till Azure Container Registry push-containeravbildningar, Helm-diagram och så vidare. Distribuera sedan via GitOps. Som en vanlig metod bör bygg- och lanseringsarbetsflöden inte ha direkt åtkomst till ditt Kubernetes-kluster-API (eller dess noder).

Övervakningsåtgärder

Aktiviteter i klustret

De klusterpoddar omsagent som körs i är Log kube-system Analytics-samlingsagenten. De samlar in telemetri, tar bort container stdout och loggar och samlar in stderr Prometheus-mått. Du kan finjustera dess samlingsinställningar genom att uppdatera container-azm-ms-agentconfig.yaml ConfigMap-filen. I den här referensimplementering aktiveras loggning kube-system över och alla dina arbetsbelastningar. Som standard kube-system undantas från loggning. Se till att du justerar logginsamlingsprocessen för att uppnå balans mellan kostnadsmål, SRE-effektivitet när du granskar loggar och efterlevnadsbehov.

Säkerhetsövervakning

Använd Microsoft Defender för molnet för att visa och åtgärda säkerhetsrekommendationer. Visa även säkerhetsaviseringar för dina resurser. 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 fråga efter data effektivt. Azure erbjuder flera teknikalternativ. Du kan använda Azure Monitor att skriva loggar till en Log Analytics-arbetsyta. Ett annat alternativ är att integrera data i lösningar för säkerhetsinformation och händelsehantering (SIEM), till exempel Microsoft Sentinel.

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

Ett fullständigt perspektiv finns i Microsoft Defender for Cloud Enterprise Onboarding Guide. Den här guiden behandlar registrering, dataexporter till dina SIEM-lösningar, svarar på aviseringar och skapar arbetsflödesautomation.

Relaterade Azure-tjänster

Här finns länkar till funktionsdokumentation för några viktiga komponenter i den här arkitekturen.

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

Nästa

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