Åtkomsthantering av ett AKS-baslinjekluster för en PCI-DSS 3.2.1 (del 6 av 9)

Den här artikeln beskriver övervägandena 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.

Kubernetes har inbyggd rollbaserad åtkomstkontroll (RBAC) som hanterar behörigheter till Kubernetes API. Det finns flera inbyggda roller med specifika behörigheter eller åtgärder för Kubernetes-resurser. Azure Kubernetes Service (AKS) stöder de inbyggda rollerna och anpassade roller för detaljerad kontroll. Dessa åtgärder kan auktoriseras (eller nekas) till en användare via Kubernetes RBAC.

Den här arkitekturen och implementeringen är inte utformade för att tillhandahålla kontroller för fysisk åtkomst till lokala resurser eller datacenter. En fördel med att vara värd för din CDE i Azure, till skillnad från din plattform vid gränsen eller i ditt datacenter, är att begränsning av fysisk åtkomst oftast redan hanteras via Säkerhet för Azure-datacenter. Det finns inget ansvar för organisationen när det gäller hantering av fysisk maskinvara.

Implementera kraftfulla åtgärder för åtkomstkontroll

Krav 7 – Begränsa åtkomsten till korthållardata per företag behöver veta

Stöd för AKS-funktioner

AKS är helt integrerat med Microsoft Entra ID som identitetsprovider.

Du behöver inte hantera separata användaridentiteter och autentiseringsuppgifter för Kubernetes. Du kan lägga till Microsoft Entra-användare för Kubernetes RBAC. Den här integreringen gör det möjligt att utföra rolltilldelningar till Microsoft Entra-användare. Microsoft Entra RBAC stöder rolldefinitioner, till exempel visningsprogram, skrivare, tjänstadministratör, klusteradministratör som inbyggda roller. Du kan också skapa anpassade roller för mer detaljerad kontroll.

Som standard är Azure RBAC inställt på att neka alla så att en resurs inte kan nås utan beviljad behörighet. AKS begränsar SSH-åtkomsten till AKS-arbetsnoder och använder AKS-nätverksprincip för att styra åtkomsten till arbetsbelastningar i poddarna.

Mer information finns i Använda Azure RBAC för Kubernetes-auktorisering och Skydda klustret med Azure Policy.

Ditt ansvar

Krav	Ansvar
Krav 7.1	Begränsa åtkomsten till systemkomponenter och korthållardata till endast de personer vars jobb kräver sådan åtkomst.
Krav 7.2	Upprätta ett åtkomstkontrollsystem för systemkomponenter som begränsar åtkomsten baserat på en användares behov av att känna till och är inställt på "neka alla" om det inte uttryckligen tillåts.
Krav 7.3	Se till att säkerhetsprinciper och operativa procedurer för att begränsa åtkomsten till korthållardata dokumenteras, används och är kända för alla berörda parter.

Krav 7.1

Begränsa åtkomsten till systemkomponenter och korthållardata till endast de personer vars jobb kräver sådan åtkomst.

Ditt ansvar

Här följer några överväganden:

• Kontrollera att implementeringen är i linje med organisationens krav och med efterlevnadskraven för identitetshantering.
• Minimera stående behörigheter, särskilt för konton med kritisk påverkan.
• Följ principen om åtkomst med lägsta behörighet. Ge precis tillräckligt med åtkomst för att slutföra uppgiften.

Krav 7.1.1

Definiera åtkomstbehov för varje roll, inklusive:

• Systemkomponenter och dataresurser som varje roll behöver åtkomst till för sin jobbfunktion
• Behörighetsnivå som krävs (till exempel användare, administratör osv.) för åtkomst till resurser.

Ditt ansvar

Definiera roller baserat på de uppgifter och ansvarsområden som krävs för komponenterna i omfånget och deras interaktion med Azure-resurser. Du kan börja med breda kategorier, till exempel:

• Omfång efter Azure-hanteringsgrupper, prenumerationer eller resursgrupper
• Azure Policy för arbetsbelastningen eller prenumerationen
• Containeråtgärder
• Hemlighetshantering
• Bygg- och distributionspipelines

Även om definitionen av roller och ansvarsområden inom dessa områden kan associeras med din teamstruktur, fokuserar du på arbetsbelastningens krav. Till exempel vem som ansvarar för att upprätthålla säkerhet, isolering, distribution och observerbarhet. Här följer några exempel:

• Beslut om programsäkerhet, Kubernetes RBAC, nätverksprinciper, Azure-principer och kommunikation med andra tjänster.
• Konfiguration och underhåll av Azure Firewall, brandvägg för webbprogram (WAF), nätverkssäkerhetsgrupper (NSG:er) och DNS-konfiguration.
• Övervaka och åtgärda serversäkerhet, korrigering, konfiguration och slutpunktssäkerhet.
• Ange riktning för användning av RBAC, Microsoft Defender för molnet, administratörsskyddsstrategi och Azure Policy för att styra Azure-resurser.
• Incidentövervaknings- och svarsteam. Undersöka och åtgärda säkerhetsincidenter i säkerhetsinformation och händelsehantering (SIEM) eller Microsoft Defender för molnet.

Formalisera sedan definitionen genom att fastställa vilken åtkomstnivå som krävs för rollen med avseende på arbetsbelastningen och infrastrukturen. Här är en enkel definition för illustrativa syften.

Roll	Ansvar	Åtkomstnivåer
Programägare	Definiera och prioritera funktioner som överensstämmer med affärsresultat. De förstår hur funktioner påverkar arbetsbelastningens efterlevnadsomfång och balanserar kundens dataskydd och ägarskap med affärsmål.	Läsåtkomst till loggar och mått som genereras av programmet. De behöver inte behörighet för att få åtkomst till arbetsbelastningen eller klustret.
Programutvecklare	Utveckla programmet. All programkod omfattas av utbildning och kvalitetsgrindar som upprätthåller processer för efterlevnad, attestering och versionshantering. Kan hantera bygg-pipelines, men vanligtvis inte distributionspipelines.	Läs åtkomst till Kubernetes-namnområden och Azure-resurser som ingår i arbetsbelastningens omfång. Ingen skrivåtkomst för att distribuera eller ändra något tillstånd i systemet.
Programoperatorer (eller SRE)	Ha en djup förståelse för kodbasen, observerbarheten och åtgärderna. Utför live-plats-sortering och felsökning. Tillsammans med programutvecklare kan du förbättra programmets tillgänglighet, skalbarhet och prestanda. Hantera distributionspipelinen "sista milen" och hjälp med att hantera byggpipelines.	Mycket privilegierat inom omfånget för programmet som innehåller relaterade Kubernetes-namnområden och Azure-resurser. Har troligen stående åtkomst till delar av Kubernetes-klustret.
Infrastrukturägare	Utforma en kostnadseffektiv arkitektur, inklusive dess anslutning och komponenternas funktioner. Omfånget kan omfatta molntjänster och lokala tjänster. Bestäm funktioner för datakvarhållning, funktioner för affärskontinuitet och andra.	Åtkomst till plattformsloggar och kostnadsställedata. Ingen åtkomst krävs i klustret.
Infrastrukturoperatörer (eller SRE)	Åtgärder relaterade till klustret och beroende tjänster. Skapa, distribuera och starta pipelinen för klustret där arbetsbelastningen distribueras. Ange målnodpooler och förväntade storleks- och skalningskrav. Övervaka hälsotillståndet för containern som är värd för infrastruktur och beroende tjänster.	Läsbehörighet till arbetsbelastningsnamnområden. Högprivilegierad åtkomst för klustret.
Princip, säkerhetsägare	Ha expertis om säkerhets- eller regelefterlevnad. Definiera principer som skyddar säkerhets- och regelefterlevnad för företagets anställda, dess tillgångar och företagets kunders. Fungerar med alla andra roller för att säkerställa att principen tillämpas och kan granskas i varje fas.	Läs åtkomst till arbetsbelastningen och klustret. Även åtkomst till logg- och granskningsdata.
Nätverksoperatorer	Allokering av företagsomfattande virtuella nätverk och undernät. Konfiguration och underhåll av Azure Firewall, WAF, NSG:er och DNS-konfiguration.	Högprivilegierad i nätverksskiktet. Ingen skrivbehörighet i klustret.

Krav 7.1.2

Begränsa åtkomsten till privilegierade användar-ID:er till de lägsta behörigheter som krävs för att utföra jobbansvar.

Ditt ansvar

Baserat på jobbfunktionerna strävar du efter att minimera åtkomsten utan att orsaka störningar. Här följer viss bästa praxis:

• Identiteten bör ha precis tillräckligt med åtkomst för att slutföra en uppgift.
• Minimera stående behörigheter, särskilt för identiteter med kritisk påverkan som har åtkomst till komponenter i omfånget.
• Lägg till extra begränsningar där det är möjligt. Ett sätt är att tillhandahålla villkorlig åtkomst baserat på åtkomstkriterier.
• Utför en regelbunden granskning och granskning av användare och grupper som har åtkomst i dina prenumerationer, även för läsåtkomst. Undvik att bjuda in externa identiteter.

Krav 7.1.3

Tilldela åtkomst baserat på den enskilda personalens arbetsklassificering och funktion.

Ditt ansvar

Fastställ behörigheter baserat på den enskilde personens tydligt tilldelade jobbuppgifter. Undvik parametrar som systemet eller anställningen för medarbetaren. Ge åtkomsträttigheter till en enskild användare eller till en grupp.

Här följer några exempel.

Jobbklassificering	Roll
En produktägare definierar omfånget för arbetsbelastningen och prioriterar funktioner. Balanserar kundens dataskydd och ägarskap med affärsmål. Behöver åtkomst till rapporter, kostnadsställe eller Azure-instrumentpaneler. Ingen åtkomst krävs för behörigheter på kluster- eller klusternivå.	Programägare
En programvarutekniker utformar, utvecklar och containeriserar programkoden. En grupp med stående läsbehörigheter inom definierade omfång i Azure (till exempel Application Insights) och arbetsbelastningens namnområden. Dessa omfång och behörigheter kan skilja sig mellan förproduktions- och produktionsmiljöer.	Programutvecklare
En platstillförlitlighetstekniker utför live-site-sortering, hanterar pipelines och konfigurerar programinfrastruktur. Gruppera A med fullständig kontroll inom deras allokerade namnområden. Stående behörigheter krävs inte. Grupp B för dagliga åtgärder för arbetsbelastningen. Den kan ha stående behörigheter inom deras allokerade namnområden, men är inte mycket privilegierade.	Programoperatorer
En klusteroperator utformar och distribuerar ett tillförlitligt och säkert AKS-kluster till plattformen. Ansvarar för att upprätthålla klustrets upptid. Gruppera A med fullständig kontroll inom deras allokerade namnområden. Stående behörigheter krävs inte. Grupp B för dagliga åtgärder för arbetsbelastningen. Den kan ha stående behörigheter inom deras allokerade namnområden, men är inte mycket privilegierade.	Infrastrukturoperatörer
En nätverkstekniker allokerar företagsomfattande virtuella nätverk och undernät, lokalt till molnanslutning och nätverkssäkerhet.	Infrastrukturoperatörer

Krav 7.1.4

Kräv dokumenterat godkännande av auktoriserade parter som anger nödvändiga behörigheter.

Ditt ansvar

Ha en gated process för att godkänna ändringar i roller och behörigheter, inklusive den första tilldelningen av privilegier. Se till att dessa godkännanden är dokumenterade och tillgängliga för inspektion.

Krav 7.2

Upprätta ett åtkomstkontrollsystem för systemkomponenter som begränsar åtkomsten baserat på en användares behov av att känna till och är inställt på "neka alla" om det inte uttryckligen tillåts.

Ditt ansvar

Efter att ha följt krav 7.1 bör du ha utvärderade roller och ansvarsområden som gäller för din organisation och arbetsbelastningen. Alla komponenter i arkitekturen som finns i omfånget måste ha begränsad åtkomst. Detta omfattar AKS-noder som kör arbetsbelastningen, datalagring, nätverksåtkomst och alla andra tjänster som deltar i bearbetningen av kortinnehavarens data (CHD).

Baserat på roller och ansvarsområden tilldelar du roller till infrastrukturens rollbaserade åtkomstkontroll (RBAC). Den mekanismen kan vara:

• Kubernetes RBAC är en inbyggd Kubernetes-auktoriseringsmodell som styr åtkomsten till Kubernetes-kontrollplanet som exponeras via Kubernetes API-servern. Den här uppsättningen behörigheter definierar vad du kan göra med API-servern. Du kan till exempel neka en användare behörighet att skapa eller till och med lista poddar.
• Azure RBAC är en Microsoft Entra ID-baserad auktoriseringsmodell som styr åtkomsten till Azure-kontrollplanet. Det här är en association mellan din Microsoft Entra-klientorganisation och din Azure-prenumeration. Med Azure RBAC kan du bevilja behörighet att skapa Azure-resurser, till exempel nätverk, ett AKS-kluster och hanterade identiteter.

Anta att du måste ge behörigheter till klusteroperatorerna (mappade till rollen infrastrukturoperatör). Alla personer som har tilldelats ansvaret för infrastrukturoperatören tillhör en Microsoft Entra-grupp. Enligt 7.1.1 kräver den här rollen den högsta behörigheten i klustret. Kubernetes har inbyggda RBAC-roller, till exempel , som cluster-adminuppfyller dessa krav. Du måste binda Microsoft Entra-gruppen för infrastrukturoperator till genom att cluster-admin skapa rollbindningar. Det finns två metoder. Du kan välja de inbyggda rollerna. Eller om de inbyggda rollerna inte uppfyller dina krav (till exempel om de kan vara alltför tillåtande) skapar du anpassade roller för dina bindningar.

Referensimplementeringen visar föregående exempel med hjälp av inbyggd Kubernetes RBAC. Samma association kan utföras med Azure RBAC. Mer information finns i Kontrollera åtkomsten till klusterresurser med rollbaserad Åtkomstkontroll i Kubernetes och Microsoft Entra-identiteter i Azure Kubernetes Service.

Du kan välja behörighetsomfång på klusternivå eller på namnområdesnivå. För roller som har begränsade ansvarsområden, till exempel programoperatorer, tilldelas behörigheterna på namnområdesnivå för arbetsbelastningen.

Dessutom behöver rollerna även Azure RBAC-behörigheter så att de kan utföra sina uppgifter. Klusteroperatorn måste till exempel komma åt Azure Monitor via portalen. Infrastrukturoperatörsrollen måste därför ha rätt RBAC-tilldelning.

Förutom personer och deras roller har Azure-resurser och till och med poddar i klustret hanterade identiteter. Dessa identiteter behöver en uppsättning behörigheter via Azure RBAC och måste vara noggrant begränsade baserat på de förväntade uppgifterna. Azure Application Gateway måste till exempel ha behörighet att hämta hemligheter (TLS-certifikat) från Azure Key Vault. Den får inte ha behörighet att ändra hemligheter.

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

• Underhåll noggrann dokumentation om varje roll och tilldelade behörigheter. Håll tydlig skillnad om vilka behörigheter som är JIT och vilka som står.

• Övervaka rollerna för ändringar, till exempel i tilldelningsändringar eller rolldefinitioner. Skapa aviseringar om ändringar även om de förväntas få insyn i avsikterna bakom ändringarna.

Krav 7.2.1

Täckning av alla systemkomponenter

Ditt ansvar

Här följer några metodtips för att upprätthålla åtgärder för åtkomstkontroll:

• Har inte stående åtkomst. Överväg att använda JUST-In-Time AD-gruppmedlemskap. Den här funktionen kräver Microsoft Entra Privileged Identity Management.

• Konfigurera principer för villkorlig åtkomst i Microsoft Entra-ID för klustret. Detta medför ytterligare begränsningar för åtkomsten till Kubernetes-kontrollplanet. Med principer för villkorlig åtkomst kan du kräva multifaktorautentisering, begränsa autentiseringen till enheter som hanteras av din Microsoft Entra-klientorganisation eller blockera icke-typiska inloggningsförsök. Tillämpa dessa principer på Microsoft Entra-grupper som är mappade till Kubernetes-roller med hög behörighet.

  Kommentar

  Både JIT och teknikval för villkorlig åtkomst kräver Microsoft Entra ID P1 eller P2.

• Inaktivera SSH-åtkomst till klusternoderna helst. Den här referensimplementeringen genererar inte SSH-anslutningsinformation för det ändamålet.

• Alla ytterligare beräkningar, till exempel hopprutor, måste nås av behöriga användare. Skapa inte allmänna inloggningar som är tillgängliga för hela teamet.

Krav 7.2.2

Tilldelning av behörigheter till individer baserat på jobbklassificering och funktion.

Ditt ansvar

Baserat på 7.1.3 kommer det att finnas många roller som ingår i klusteråtgärder. Utöver azure-standardresursrollerna måste du definiera åtkomstens omfattning och process.

Tänk till exempel på klusteroperatorns roll. De bör ha en tydligt definierad spelbok för klustertriageaktiviteter. Hur skiljer sig den åtkomsten från arbetsbelastningsteamet? Beroende på din organisation kan de vara desamma. Här är några saker att tänka på:

• Hur ska de komma åt klustret?
• Vilka källor tillåts för åtkomst?
• Vilka behörigheter ska de ha i klustret?
• När tilldelas dessa behörigheter?

Kontrollera att definitionerna är dokumenterade i styrningsdokumentationen, policyn och utbildningsmaterialen kring arbetsbelastningsoperatören och klusteroperatorn.

Krav 7.2.3

Standardinställningen "neka alla".

Ditt ansvar

När du startar konfigurationen börjar du med principer med noll förtroende. Gör undantag efter behov och dokumentera dem i detalj.

• Kubernetes RBAC implementerar neka alla som standard. Åsidosätt inte genom att lägga till mycket tillåtande klusterrollbindningar som inverterar inställningen neka alla.

• Azure RBAC implementerar också neka alla som standard. Åsidosätt inte genom att lägga till RBAC-tilldelningar som inverterar inställningen neka alla.

• Alla Azure-tjänster, Azure Key Vault och Azure Container Registry har nekat alla behörigheter som standard.

• Alla administrativa åtkomstpunkter, till exempel en hoppruta, bör neka all åtkomst i den inledande konfigurationen. Alla utökade behörigheter måste uttryckligen definieras för att neka alla regler.

Krav 7.3

Se till att säkerhetsprinciper och operativa procedurer för att begränsa åtkomsten till korthållardata 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. Detta inkluderar Azure- och Kubernetes RBAC-principer och organisationsstyrningsprinciper. Personer driftreglerade miljöer måste utbildas, informeras och uppmuntras för att stödja säkerhetsgarantierna. Detta är särskilt viktigt för personer som ingår i godkännandeprocessen ur ett politiskt perspektiv.

Krav 8 – Identifiera och autentisera åtkomst till systemkomponenter

Stöd för AKS-funktioner

På grund av AKS- och Microsoft Entra-integrering kan du dra nytta av ID-hanterings- och auktoriseringsfunktioner, inklusive åtkomsthantering, hantering av identifierarobjekt med mera. Mer information finns i AKS-hanterad Microsoft Entra-integrering.

Ditt ansvar

Krav	Ansvar
Krav 8.1	Definiera och implementera principer och procedurer för att säkerställa korrekt hantering av användaridentifiering för icke-konsumentanvändare och administratörer på alla systemkomponenter enligt följande:
Krav 8.2	Förutom att tilldela ett unikt ID ska du säkerställa korrekt användarautentiseringshantering för icke-konsumentanvändare och administratörer på alla systemkomponenter genom att använda minst en av följande metoder för att autentisera alla användare:
Krav 8.3	Skydda all enskild administrativ åtkomst som inte är konsolbaserad och all fjärråtkomst till CDE med hjälp av multifaktorautentisering.
Krav 8.4	Dokumentera och kommunicera autentiseringsprocedurer och principer och procedurer till alla användare, inklusive:
Krav 8.5	Använd inte grupp-, delade eller generiska ID:er, lösenord eller andra autentiseringsmetoder på följande sätt:
Krav 8.6	Om andra autentiseringsmekanismer används (till exempel fysiska eller logiska säkerhetstoken, smartkort, certifikat osv.) måste användningen av dessa mekanismer tilldelas på följande sätt:
Krav 8.7	All åtkomst till alla databaser som innehåller korthållardata (inklusive åtkomst av program, administratörer och alla andra användare) begränsas på följande sätt:
Krav 8.8	Se till att säkerhetsprinciper och operativa procedurer för identifiering och autentisering dokumenteras, används och är kända för alla berörda parter.

Krav 8.1

Definiera och implementera principer och procedurer för att säkerställa korrekt hantering av användaridentifiering för icke-konsumentanvändare och administratörer på alla systemkomponenter enligt följande:

• 8.1.1 Tilldela alla användare ett unikt ID innan de får åtkomst till systemkomponenter eller korthållardata.
• 8.1.2 Kontrollera tillägg, borttagning och ändring av användar-ID, autentiseringsuppgifter och andra identifierarobjekt.
• 8.1.3 Återkalla omedelbart åtkomsten för alla avslutade användare.
• 8.1.4 Ta bort/inaktivera inaktiva användarkonton inom 90 dagar.
• 8.1.5 Hantera ID:er som används av tredje part för åtkomst, support eller underhåll av systemkomponenter via fjärråtkomst enligt följande:
  • Aktiverad endast under den tidsperiod som behövs och inaktiveras när den inte används.
  • Övervakas när den används.
• 8.1.6 Begränsa upprepade åtkomstförsök genom att låsa ut användar-ID:t efter högst sex försök.
• 8.1.7 Ange varaktigheten för utelåsning till minst 30 minuter eller tills en administratör aktiverar användar-ID:t.
• 8.1.8 Om en session har varit inaktiv i mer än 15 minuter måste användaren autentisera igen för att återaktivera terminalen eller sessionen.

Ditt ansvar

Här är övergripande överväganden för det här kravet:

GÄLLER FÖR: 8.1.1, 8.1.2, 8.1.3

Dela eller återanvänd inte identiteter för funktionellt olika delar av CDE. Använd till exempel inte ett teamkonto för att komma åt data eller klusterresurser. Kontrollera att identitetsdokumentationen är tydlig om att inte använda delade konton.

Utöka det här identitetsobjektet till hanterade identitetstilldelningar i Azure. Dela inte användarhanterade identiteter mellan Azure-resurser. Tilldela varje Azure-resurs en egen hanterad identitet. När du använder Microsoft Entra-arbetsbelastnings-ID i AKS-klustret ser du på samma sätt till att varje komponent i din arbetsbelastning får sin egen identitet i stället för att använda en identitet som är bred i omfånget. Använd aldrig samma hanterade identitet i förproduktion och produktion.

Åtkomst och identitetsalternativ för Azure Kubernetes Service (AKS)

GÄLLER FÖR: 8.1.2, 8.1.3, 8.1.4

Använd Microsoft Entra-ID som identitetsarkiv. Eftersom klustret och alla Azure-resurser använder Microsoft Entra-ID tillämpas inaktivering eller återkallande av Microsoft Entra-ID-åtkomst automatiskt på alla resurser. Om det finns komponenter som inte backas upp direkt av Microsoft Entra-ID kontrollerar du att du har en process för att ta bort åtkomsten. SSH-autentiseringsuppgifter för åtkomst till en hoppruta kan till exempel behöva tas bort explicit om användaren inte längre är giltig.

GÄLLER FÖR: 8.1.5

Dra nytta av Microsoft Entra business-to-business (B2B) som är utformat för att vara värd för konton från tredje part, till exempel leverantörer, partner, som gästanvändare. Bevilja lämplig åtkomstnivå med hjälp av villkorliga principer för att skydda företagsdata. Dessa konton måste ha minimala stående behörigheter och obligatoriska förfallodatum. Mer information finns i Vad är gästanvändaråtkomst i Microsoft Entra B2B.

Din organisation bör ha ett tydligt och dokumenterat mönster för leverantör och liknande åtkomst.

GÄLLER FÖR: 8.1.6, 8.1.7, 8.1.8

Ditt ansvar

Microsoft Entra ID tillhandahåller en funktion för smart utelåsning för att låsa ut användare efter misslyckade inloggningsförsök. Det rekommenderade sättet att implementera utelåsningar är med principer för villkorsstyrd åtkomst i Microsoft Entra.

Implementera utelåsningen för komponenter som stöder liknande funktioner men som inte backas upp med Microsoft Entra-ID (till exempel SSH-aktiverade datorer, till exempel en jump box). Detta säkerställer att utelåsningar är aktiverade för att förhindra eller använda långsamma åtkomstförsök.

AKS-noder är inte utformade för att användas rutinmässigt. Blockera direkt SSH eller Fjärrskrivbord till klusternoder. SSH-åtkomst bör endast betraktas som en del av avancerade felsökningsåtgärder. Åtkomsten bör övervakas noggrant och omedelbart återställas efter att den specifika händelsen har slutförts. Om du gör detta bör du vara medveten om att eventuella ändringar på nodnivå kan göra att klustret inte stöds.

Krav 8.2

Förutom att tilldela ett unikt ID ska du säkerställa korrekt användarautentiseringshantering för icke-konsumentanvändare och administratörer på alla systemkomponenter genom att använda minst en av följande metoder för att autentisera alla användare: Något du känner till, till exempel ett lösenord eller lösenfras, Något du har, till exempel en tokenenhet eller ett smartkort, Något du är, t.ex. biometrisk.

• 8.2.1 Med stark kryptografi gör du alla autentiseringsuppgifter (till exempel lösenord/fraser) olästa under överföring och lagring på alla systemkomponenter.
• 8.2.2 Verifiera användaridentiteten innan du ändrar autentiseringsautentiseringsuppgifter– till exempel utföra lösenordsåterställning, etablera nya token eller generera nya nycklar.
• 8.2.3 Lösenord/fraser måste uppfylla följande:
  • Kräv en minsta längd på minst sju tecken.
  • Innehåller både numeriska och alfabetiska tecken.
• 8.2.4 Ändra användarlösenord/lösenfraser minst en gång var 90:e dag.
• 8.2.5 Tillåt inte att en person skickar in ett nytt lösenord/en ny fras som är samma som något av de fyra senaste lösenorden/fraserna som han eller hon har använt.
• 8.2.6 Ange lösenord/fraser för första gången och vid återställning till ett unikt värde för varje användare och ändra omedelbart efter den första användningen.

Ditt ansvar

Konfigurera principer för villkorlig åtkomst i Microsoft Entra-ID för klustret. Detta medför ytterligare begränsningar för åtkomsten till Kubernetes-kontrollplanet.

Flera av de föregående kraven hanteras automatiskt av Microsoft Entra ID. Här följer några exempel:

• Lösenordssäkerhet

  Microsoft Entra ID innehåller funktioner som framtvingar användning av starka lösenord. Till exempel blockeras svaga lösenord som tillhör den globala listan över förbjudna lösenord. Det här är inte tillräckligt skydd. Överväg att lägga till funktionen Microsoft Entra Password Protection för att skapa en organisationsspecifik förbudslista. En lösenordsprincip tillämpas som standard. Vissa principer kan inte ändras och omfattar några av de föregående kraven. Dessa inkluderar förfallodatum för lösenord och tillåtna tecken. Den fullständiga listan finns i Microsoft Entra-lösenordsprinciper. Överväg att använda avancerade funktioner som kan tillämpas med principer för villkorlig åtkomst, till exempel de som baseras på användarrisk, som identifierar läckta användarnamn och lösenordspar. Mer information finns i Villkorlig åtkomst: Användarriskbaserad villkorlig åtkomst.

  Kommentar

  Vi rekommenderar starkt att du överväger lösenordslösa alternativ. Mer information finns i Planera en distribution av lösenordsfri autentisering i Microsoft Entra-ID.

• Verifiering av användaridentitet

  Du kan använda principen för villkorlig åtkomst för inloggningsrisk för att identifiera om autentiseringsbegäran utfärdades av den begärande identiteten. Begäran verifieras mot hotinformationskällor. Dessa inkluderar lösenordsspray och IP-adressavvikelser. Mer information finns i Villkorlig åtkomst: Inloggningsriskbaserad villkorlig åtkomst.

Du kan ha komponenter som inte använder Microsoft Entra-ID, till exempel åtkomst till hopprutor med SSH. I sådana fall använder du kryptering av offentlig nyckel med minst RSA 2048-nyckelstorlek. Ange alltid en lösenfras. Ha en valideringsprocess som spårar kända godkända offentliga nycklar. System som använder offentlig nyckelåtkomst får inte exponeras för Internet. I stället bör all SSH-åtkomst tillåtas via en mellanhand, till exempel Azure Bastion, för att minska effekten av en läcka med privata nycklar. Inaktivera direkt lösenordsåtkomst och använd en alternativ lösning utan lösenord.

Krav 8.3

Skydda all enskild administrativ åtkomst som inte är konsolbaserad och all fjärråtkomst till CDE med hjälp av multifaktorautentisering. Obs! Multifaktorautentisering kräver att minst två av de tre autentiseringsmetoderna (se Krav 8.2 för beskrivningar av autentiseringsmetoder) används för autentisering. Att använda en faktor två gånger (till exempel att använda två separata lösenord) anses inte vara multifaktorautentisering.

Ditt ansvar

Använd principer för villkorlig åtkomst för att framtvinga multifaktorautentisering, särskilt på administrativa konton. Dessa principer rekommenderas för flera inbyggda roller. Tillämpa dessa principer på Microsoft Entra-grupper som är mappade till Kubernetes-roller med hög behörighet.

Den här principen kan förstärkas ytterligare med ytterligare principer. Här följer några exempel:

• Du kan begränsa autentiseringen till enheter som hanteras av din Microsoft Entra-klientorganisation.
• Om åtkomsten kommer från ett nätverk utanför klusternätverket kan du framtvinga multifaktorautentisering.

Mer information finns i:

• Villkorsstyrd åtkomst: Kräv MFA för administratörer
• Anvisningar: Kräv hanterade enheter för åtkomst till molnappar med villkorsstyrd åtkomst
• Anvisningar: Kräv MFA för åtkomst från ej betrodda nätverk med villkorsstyrd åtkomst

Krav 8.4

Dokumentera och kommunicera autentiseringsprocedurer och principer och procedurer till alla användare, inklusive:

• Vägledning för att välja starka autentiseringsuppgifter
• Vägledning för hur användare ska skydda sina autentiseringsuppgifter
• Instruktioner för att inte återanvända tidigare använda lösenord
• Instruktioner för att ändra lösenord om det finns någon misstanke om att lösenordet kan komprometteras.

Ditt ansvar

Underhåll dokumentation om de framtvingade principerna. Som en del av din utbildning om identitetsregistrering ger du vägledning för procedurer för lösenordsåterställning och organisationens metodtips för att skydda tillgångar.

Krav 8.5

Använd inte grupp-, delade eller generiska ID:er, lösenord eller andra autentiseringsmetoder på följande sätt:

• Allmänna användar-ID:t är inaktiverade eller borttagna.
• Delade användar-ID:er finns inte för systemadministration och andra kritiska funktioner.
• Delade och generiska användar-ID:er används inte för att administrera några systemkomponenter.

Ditt ansvar

Dela eller återanvänd inte identiteter för funktionellt olika delar av klustret eller poddarna. Använd till exempel inte ett teamkonto för att komma åt data eller klusterresurser. Kontrollera att identitetsdokumentationen är tydlig om att inte använda delade konton.

Inaktivera rotanvändare i CDE. Inaktivera användningen av lokala Kubernetes-konton så att användarna inte kan använda den inbyggda --admin åtkomsten till kluster i CDE.

Krav 8.6

Om andra autentiseringsmekanismer används (till exempel fysiska eller logiska säkerhetstoken, smartkort, certifikat osv.) måste användningen av dessa mekanismer tilldelas på följande sätt:

• Autentiseringsmekanismer måste tilldelas till ett enskilt konto och delas inte mellan flera konton.
• Fysiska och/eller logiska kontroller måste finnas för att säkerställa att endast det avsedda kontot kan använda den mekanismen för att få åtkomst.

Ditt ansvar

Se till att all åtkomst till CDE tillhandahålls på identiteter per användare och att den utökas till alla fysiska eller virtuella token. Detta omfattar all VPN-åtkomst till CDE-nätverket, vilket säkerställer att företags åtkomst till punkt-till-plats (om någon) använder certifikat per användare som en del av det autentiseringsflödet.

Krav 8.7

All åtkomst till alla databaser som innehåller korthållardata (inklusive åtkomst av program, administratörer och alla andra användare) begränsas på följande sätt:

• All användaråtkomst till, användarfrågor och användaråtgärder i databaser sker via programmatiska metoder.
• Endast databasadministratörer har möjlighet att komma åt eller fråga databaser direkt.
• Program-ID:t för databasprogram kan endast användas av programmen (och inte av enskilda användare eller andra icke-programprocesser).

Ditt ansvar

Ge åtkomst baserat på roller och ansvarsområden. Personer kan använda sin identitet, men åtkomsten måste begränsas på grund av behov av kunskap, med minimala stående behörigheter. Personer bör aldrig använda programidentiteter och databasåtkomstidentiteter får aldrig delas.

Om möjligt kan du komma åt databasen från program via hanterad identitet. Annars begränsar du exponeringen för anslutningssträng och autentiseringsuppgifter. Använd Kubernetes-hemligheter för att lagra känslig information i stället för att behålla dem på platser där de är lätta att identifiera, till exempel podddefinition. Ett annat sätt är att lagra och läsa in hemligheter till och från ett hanterat arkiv, till exempel Azure Key Vault. Med hanterade identiteter aktiverade i ett AKS-kluster måste det autentisera sig mot Key Vault för att få åtkomst.

Krav 8.8

Se till att säkerhetsprinciper och operativa procedurer för identifiering och autentisering 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. Underhåll dokumentation om de framtvingade principerna. Som en del av din utbildning om identitetsregistrering ger du vägledning för procedurer för lösenordsåterställning och organisationens metodtips för att skydda tillgångar. Personer driftreglerade miljöer måste utbildas, informeras och uppmuntras för att stödja säkerhetsgarantierna. Detta är särskilt viktigt för personer som ingår i godkännandeprocessen ur ett politiskt perspektiv.

Krav 9 – Begränsa fysisk åtkomst till korthållardata

Stöd för AKS-funktioner

Det finns inga tillämpliga AKS-funktioner för det här kravet.

Ditt ansvar

Den här arkitekturen och implementeringen är inte utformade för att tillhandahålla kontroller för fysisk åtkomst till lokala resurser eller datacenter. Överväganden finns i vägledningen i den officiella PCI-DSS 3.2.1-standarden.

Här följer några förslag på hur du tillämpar tekniska kontroller:

• Justera tidsgränser för sessioner i all administrativ konsolåtkomst, till exempel hopprutor i CDE, för att minimera åtkomsten.

• Justera principer för villkorlig åtkomst för att minimera TTL på Azure-åtkomsttoken från åtkomstpunkter, till exempel Azure-portalen. Mer information finns i följande artiklar:

  • Konfigurera autentiseringsessionshantering med villkorsstyrd åtkomst
  • Konfigurerbara tokenlivslängder – Microsofts identitetsplattform

• För molnbaserad CDE finns det inget ansvar för att hantera fysisk åtkomst och maskinvara. Förlita dig på fysiska och logiska kontroller för företagsnätverk.

• Minimera export av CHD-säkerhetskopior till lokala mål. Använd lösningar som finns i Azure för att begränsa fysisk åtkomst till säkerhetskopior.

• Minimera säkerhetskopieringar lokalt. Om detta krävs bör du vara medveten om att det lokala målet kommer att finnas i omfånget för granskning.

Nästa steg

Spåra och övervaka all åtkomst till nätverksresurser och korthållardata. Testa regelbundet säkerhetssystem och processer.