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

---

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 för alla systemkomponenter på följande sätt:

• 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 att komma åt, stödja eller underhålla systemkomponenter via fjärråtkomst på följande sätt:
  • Aktiveras endast under den tidsperiod som krävs och inaktiveras när den inte används.
  • Övervakas när det används.
• 8.1.6 Begränsa upprepade åtkomstförsök genom att låsa ut användar-ID efter högst sex försök.
• 8.1.7 Ange låsningstiden 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.

Dina ansvarsområden

Här är några ö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:en. Använd till exempel inte ett teamkonto för att komma åt data eller klusterresurser. Kontrollera att identitetsdokumentationen är tydlig med att inte använda delade konton.

Utöka identitetens huvudnamn till hanterade identitetstilldelningar i Azure. Dela inte användar hanterade identiteter mellan Azure-resurser. Tilldela varje Azure-resurs sin egen hanterade identitet. När du använder Azure AD-poddidentitet i AKS-klustret bör du på samma sätt se till att varje komponent i din arbetsbelastning får sin egen identitet i stället för att använda en identitet som har ett brett omfång. 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 Azure AD som identitetsarkiv. Eftersom klustret och alla Azure-resurser använder Azure AD tillämpas inaktivering eller återkallande av Azure AD-åtkomst på alla resurser automatiskt. Om det finns komponenter som inte backas upp direkt av Azure AD kontrollerar du att du har en process för att ta bort åtkomst. SSH-autentiseringsuppgifter för åtkomst till en jumpbox kan till exempel behöva explicit borttagning om användaren inte längre är giltig.

GÄLLER FÖR: 8.1.5

Dra nytta av Azure AD 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å genom att använda 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 Azure Active Directory 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

Dina ansvarsområden

Azure AD tillhandahåller en funktion för smart utlåsning som låser ut användare efter misslyckade inloggningsförsök. Det rekommenderade sättet att implementera utelåsningar är med principer för villkorsstyrd åtkomst i Azure AD.

Implementera utelåsningen för komponenter som stöder liknande funktioner men som inte backas upp med Azure AD (till exempel SSH-aktiverade datorer, till exempel en jumpbox). Detta säkerställer att utelåsningar aktiveras för att förhindra eller förhindra missbruk av försök till långsam åtkomst.

AKS-noder är inte utformade för att användas regelbundet. Blockera direkt SSH eller fjärrskrivbord till klusternoder. SSH-åtkomst bör endast betraktas som en del av avancerad felsökning. Åtkomsten bör övervakas noggrant och återställas omgående när den specifika händelsen har slutförts. Om du gör detta bör du vara medveten om att ändringar på nodnivå kan leda till att klustret inte har stöd.

Krav 8.2

Förutom att tilldela ett unikt ID bör du säkerställa korrekt hantering av användarautentisering 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 en lösenfras, Något du har, till exempel en tokenenhet eller smartkort, Något du är, till exempel en biometrik.

• 8.2.1 Med stark kryptografi kan du inte läsa alla autentiseringsuppgifter (till exempel lösenord/fraser) under överföring och lagring på alla systemkomponenter.
• 8.2.2 Verifiera användaridentitet innan du ändrar autentiseringsuppgifter– till exempel utföra lösenordsåterställningar, 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 ett nytt lösenord/en ny fras som är samma som något av de senaste fyra lösenorden/fraserna som personen 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.

Dina ansvarsområden

Konfigurera principer för villkorlig åtkomst i Azure AD för klustret. Detta innebär ytterligare begränsningar för åtkomsten till Kubernetes-kontrollplanet.

Flera av de föregående kraven hanteras automatiskt av Azure AD. Här är några exempel:

• Lösenordssäkerhet

  Azure AD innehåller funktioner som framtvingar användning av starka lösenord. Till exempel blockeras svaga lösenord som tillhör listan över globala förbjudna lösenord. Det här är inte tillräckligt skydd. Överväg att lägga till azure AD-lösenordsskyddsfunktionen för att skapa en organisationsspecifik förbjudningslista. En lösenordsprincip tillämpas som standard. Vissa principer kan inte ändras och täcker några av de föregående kraven. Exempel på detta är förfallotid för lösenord och tillåtna tecken. En fullständig lista finns i Lösenordsprinciper för Azure AD. Ö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.

  Anteckning

  Vi rekommenderar starkt att du överväger lösenordslösa alternativ. Mer information finns i Planera en distribution av lösenordslös autentisering i Azure Active Directory.

• Verifiering av användaridentitet

  Du kan använda principen för villkorlig åtkomst för inloggningsrisk för att identifiera om autentiseringsbegäran har utfärdats av den begärande identiteten. Begäran verifieras mot hotinformationskällor. Exempel på sådana är lösenordsavvikelser och IP-adressavvikelser. Mer information finns i Villkorlig åtkomst: Riskbaserad villkorlig åtkomst för inloggning.

Du kan ha komponenter som inte använder Azure AD, till exempel åtkomst till jumpboxar med SSH. I sådana fall använder du kryptering med 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 mot 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 privat nyckelläcka. 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.

Dina ansvarsområden

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

Den här principen kan ytterligare stärkas med ytterligare principer. Här är några exempel:

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

Mer information finns i:

• Villkorlig åtkomst: Kräv MFA för administratörer
• Gör så här: Kräv hanterade enheter för åtkomst till molnapp med villkorlig åtkomst
• Gör så här: Kräv MFA för åtkomst från ej betrodda nätverk med villkorlig åtkomst

Krav 8.4

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

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

Dina ansvarsområden

Underhåll dokumentation om de framtvingade principerna. Som en del av din utbildning om registrering av identiteter kan du ge vägledning för procedurer för lösenordsåterställning och bästa praxis för organisationens skydd av tillgångar.

Krav 8.5

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

• Allmänna användar-ID:er inaktiveras eller tas bort.
• Delade användar-ID:er finns inte för systemadministration och andra viktiga funktioner.
• Delade och allmänna användar-ID:er används inte för att administrera några systemkomponenter.

Dina ansvarsområden

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 med 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 --admin inbyggda åtkomsten till kluster i CDE:en.

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 inte delas mellan flera konton.
• Fysiska och/eller logiska kontroller måste finnas på plats för att säkerställa att endast det avsedda kontot kan använda den mekanismen för att få åtkomst.

Dina ansvarsområden

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 inkluderar all VPN-åtkomst till CDE-nätverket, vilket säkerställer att företags punkt-till-plats-åtkomst (om det finns några) använder certifikat per användare som en del av autentiseringsflödet.

Krav 8.7

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

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

Dina ansvarsområden

Ge åtkomst baserat på roller och ansvarsområden. Personer kan använda sin identitet, men åtkomsten måste begränsas på ett behovsent sätt, med minimala stående behörigheter. Användare 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ängar och autentiseringsuppgifter. Använd Kubernetes-hemligheter för att lagra känslig information i stället för att lagra dem på platser där de enkelt kan identifieras, till exempel podddefinition. Ett annat sätt är att lagra och läsa in hemligheter till och från ett hanterat lager, till exempel Azure Key Vault. När hanterade identiteter är aktiverade i ett AKS-kluster måste de 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.

Dina ansvarsområden

Det är viktigt att du underhåller omfattande dokumentation om processer och principer. Underhåll dokumentation om de framtvingade principerna. Som en del av din utbildning om registrering av identiteter kan du ge vägledning för procedurer för lösenordsåterställning och bästa praxis för organisationens skydd av tillgångar. 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 som ingår i godkännandeprocessen ur ett principperspektiv.

Krav 9

Begränsa fysisk åtkomst till korthållardata

Dina ansvarsområden

Den här arkitekturen och implementeringen är inte utformad för att ge kontroller för fysisk åtkomst till lokala resurser eller datacenter. Information finns i vägledningen i den officiella PCI-DSS 3.2.1-standarden.

Här är några förslag på hur du kan använda tekniska kontroller:

• Finjustera tidsgränser för sessioner i alla administrativa konsolåtkomster, till exempel hopprutor i CDE, för att minimera åtkomsten.

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

  • Konfigurera autentiseringsessionshantering med villkorsstyrd åtkomst
  • Konfigurerbara livslängder för token – 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 företagsnätverkskontroller.

• 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 omfattas av granskning.

Nästa steg

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

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.

Kubernetes har inbyggd rollbaserad åtkomstkontroll (RBAC) som hanterar behörigheter till Kubernetes-API:et. Det finns flera inbyggda roller med specifika behörigheter eller åtgärder på Kubernetes-resurser. Azure Kubernetes Service (AKS) stöder dessa inbyggda roller 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 utformad för att ge 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 huvudsakligen redan hanteras via Azures datacentersäkerhet. Det finns inga ansvarsområden för organisationen vid hantering av fysisk maskinvara.

Implementera åtgärder för stark åtkomstkontroll

Krav 7– Begränsa åtkomsten till korthållardata efter företag behöver känna till

Stöd för AKS-funktioner

AKS är helt integrerat med Azure Active Directory (Azure AD) som identitetsprovider.

Du behöver inte hantera separata användaridentiteter och autentiseringsuppgifter för Kubernetes. Du kan lägga till Azure AD-användare för Kubernetes RBAC. Den här integreringen gör det möjligt att göra rolltilldelningar till Azure AD-användare. Azure AD RBAC stöder rolldefinitioner, till exempel läsare, 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 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-auktoriseringoch Skydda klustret med Azure Policy.

Dina ansvarsområden

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älld på "neka alla" om det inte tillåts specifikt.
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 8 –Identifiera och autentisera åtkomst till systemkomponenter

Stöd för AKS-funktioner

På grund av AKS- och Azure AD-integrering kan du utnyttja funktionerna för ID-hantering och auktorisering, inklusive åtkomsthantering, objekthantering för identifierare med mera. Mer information finns i AKS-hanterad Azure Active Directory integrering.

Dina ansvarsområden

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 för alla systemkomponenter på följande sätt:
Krav 8.2	Förutom att tilldela ett unikt ID bör du säkerställa korrekt hantering av användarautentisering 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, principer och procedurer till alla användare, inklusive:
Krav 8.5	Använd inte grupp-, delad eller generisk ID, 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 för program, administratörer och alla andra användare) är begränsad 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 9– Begränsa fysisk åtkomst till korthållardata

Krav 7.1

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

Dina ansvarsområden

Här är några saker att tänka på:

• Kontrollera att implementeringen är anpassad efter 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 minsta behörighet. Ange 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.

Dina ansvarsområden

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 runt dessa områden kan associeras med din teamstruktur, fokuserar du på kravet på arbetsbelastningen. Till exempel vem som ansvarar för att upprätthålla säkerhet, isolering, distribution och observerbarhet. Här är 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 webbaserade program (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 moln, administratörsskyddsstrategi och Azure Policy styra Azure-resurser.
• Incidentövervaknings- och svarsteam. Undersöka och åtgärda säkerhetsincidenter inom säkerhetsinformation och händelsehantering (SIEM) eller Microsoft Defender för moln.

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 illustrerande ändamål.

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 att komma åt arbetsbelastningen eller klustret.
Programutvecklare	Utveckla programmet. All programkod omfattas av träning och kvalitetsgrindar som upprätthåller processer för efterlevnad, atterstation och versionshantering. Kan hantera bygg-pipelines, men vanligtvis inte distributionspipelines.	Läsåtkomst till Kubernetes-namnrymder och Azure-resurser som ingår i arbetsbelastningens omfattning. Ingen skrivåtkomst för distribution eller ändring av systemets tillstånd.
Programoperatorer (eller SRE)	Ha en djup förståelse för kodbasen, observerbarheten och åtgärderna. Gör treddering och felsökning av livewebbplatser. Tillsammans med programutvecklare kan du förbättra programmets tillgänglighet, skalbarhet och prestanda. Hantera distributionspipelinen "last-mile" och hantera bygg-pipelines.	Hög privilegier inom omfånget för programmet som innehåller relaterade Kubernetes-namnrymder och Azure-resurser. Har troligen stående åtkomst till delar av Kubernetes-klustret.
Infrastrukturägare	Utforma en kostnadseffektiv arkitektur, inklusive dess anslutning och funktionerna i komponenterna. Omfånget kan omfatta molntjänster och lokala tjänster. Bestäm funktioner för databevarande, funktioner för affärskontinualitet med mera.	Å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 bootstrap-pipelinen för klustret där arbetsbelastningen distribueras. Ange målnodpooler och förväntade storleks- och skalningskrav. Övervaka hälsotillståndet för containervärdinfrastrukturen och beroende tjänster.	Läsåtkomst till namnområden för arbetsbelastningar. Högbehörighetsåtkomst för klustret.
Princip, säkerhetsägare	Ha kunskaper om efterlevnad för säkerhet eller regelefterlevnad. Definiera principer som skyddar företagets anställdas säkerhet och regelefterlevnad, dess tillgångar och företagets kunders tillgångar. 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ög privilegierad i nätverkslagret. Ingen skrivbehörighet i klustret.

Krav 7.1.2

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

Dina ansvarsområden

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

• Identiteten bör ha precis tillräcklig åtkomst för att slutföra en uppgift.
• Minimera stående behörigheter, särskilt för kritiska påverkansidentiteter som har åtkomst till omfångskomponenter.
• Lägg till ytterligare begränsningar där det är möjligt. Ett sätt är att tillhandahålla villkorlig åtkomst baserat på åtkomstkriterier.
• Genomför en regelbunden granskning och granskning av användare och grupper som har åtkomst i dina prenumerationer, även för läsbehörighet. Undvik att bjuda in externa identiteter.

Krav 7.1.3

Tilldela åtkomst baserat på enskild personals jobbklassificering och funktion.

Dina ansvarsområden

Fastställa behörigheter baserat på personens tydligt tilldelade jobbuppgifter. Undvik parametrar som systemet eller den anställdas tid. Ge åtkomstbehörighet till en enskild användare eller till en grupp.

Här är några exempel.

Jobbklassificering	Roll
En produktägare definierar arbetsbelastningens omfattning och prioriterar funktioner. Balanserar kundens dataskydd och ägarskap med affärsmål. Behöver åtkomst till rapporter, kostnadsstället eller Azure-instrumentpaneler. Ingen åtkomst krävs för behörigheter på kluster- eller klusternivå.	Programägare
En programvarutekniker designar, utvecklar och containeriserar programkoden. En grupp med stående läsbehörigheter inom definierade omfång i Azure (till exempel Application Insights) och arbetsbelastningens namnrymder. Dessa omfång och behörigheter kan skilja sig åt mellan förproduktions- och produktionsmiljöer.	Programutvecklare
En tekniker för platstillförlitlighet hanterar, hanterar pipelines och uppsättningar av programinfrastruktur. Grupp A med fullständig kontroll inom sina allokerade namnrymder. Stående behörigheter krävs inte. Grupp B för dagliga åtgärder i arbetsbelastningen. Den kan ha stående behörigheter inom sina allokerade namnrymder, men har inte hög behörighet.	Programoperatorer
En klusteroperatör utformar och distribuerar ett tillförlitligt och säkert AKS-kluster till plattformen. Ansvarar för att upprätthålla klustrets upptid. Grupp A med fullständig kontroll inom sina allokerade namnrymder. Stående behörigheter krävs inte. Grupp B för dagliga åtgärder i arbetsbelastningen. Den kan ha stående behörigheter inom sina allokerade namnrymder, men har inte hög behörighet.	Infrastrukturoperatörer
En nätverkstekniker allokerar virtuella nätverk och undernät för hela företaget, lokalt till molnanslutningar och nätverkssäkerhet.	Infrastrukturoperatörer

Krav 7.1.4

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

Dina ansvarsområden

Ha en begränsad process för att godkänna ändringar i roller och behörigheter, inklusive den inledande tilldelningen av behörigheter. Se till att dessa godkännanden är dokumenterade och tillgängliga för granskning.

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älld på "neka alla" om det inte tillåts specifikt.

Dina ansvarsområden

Efter följande krav 7.1bör du ha utvärderat roller och ansvarsområden som gäller för din organisation och arbetsbelastningen. Alla komponenter i arkitekturen som är inom omfång måste ha begränsad åtkomst. Detta inkluderar de 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 här mekanismen kan vara:

• Kubernetes RBAC är en ursprunglig Kubernetes-auktoriseringsmodell som styr åtkomsten till Kubernetes-kontrollplanetsom 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 Azure AD-baserad auktoriseringsmodell som styr åtkomsten till Azure-kontrollplanet. Det här är en association mellan din Azure AD-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 behöver ge behörighet till klusteroperatorerna (mappad till rollen infrastrukturoperatör). Alla personer som har tilldelats infrastrukturoperatörens ansvarsområden tillhör en Azure AD-grupp. Enligt 7.1.1 kräver den här rollen högsta behörighet i klustret. Kubernetes har inbyggda RBAC-roller, till cluster-admin exempel , som uppfyller dessa krav. Du måste binda Azure AD-gruppen för infrastrukturoperatören till genom cluster-admin att 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 för tillåtande) skapar du anpassade roller för dina bindningar.

Referensimplementering visar föregående exempel med hjälp av intern Kubernetes RBAC. Samma association kan utföras med Azure RBAC. Mer information finns i Kontrollera åtkomsten till klusterresurser med hjälp av rollbaserad åtkomstkontroll i Kubernetes och Azure Active Directory 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 Azure RBAC-behörigheter så att de kan utföra sina uppgifter. Klusteroperatorn måste till exempel ha åtkomst 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 även poddar i klustret hanterade identiteter. Dessa identiteter behöver en uppsättning behörigheter via Azure RBAC och måste vara begränsade baserat på förväntade uppgifter. Till exempel Azure Application Gateway 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 de tilldelade behörigheterna. Håll en tydlig skillnad mellan 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 för alla systemkomponenter

Dina ansvarsområden

Här är några metodtips för att underhålla åtkomstkontrollmått:

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

• Konfigurera principer för villkorlig åtkomst i Azure AD för klustret. Detta innebä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 Azure AD-klient eller blockera icke-typiska inloggningsförsök. Tillämpa dessa principer på Azure AD-grupper som mappas till Kubernetes-roller med hög behörighet.

  Anteckning

  Både JIT- och teknikval för villkorlig åtkomst kräver Azure AD Premium.

• Vi rekommenderar att du inaktiverar SSH-åtkomst till klusternoderna. Den här referensimplementering genererar inte SSH-anslutningsinformation för detta ändamål.

• Alla ytterligare beräkningar, till exempel jumpboxar, måste kommas åt 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 enskilda användare baserat på jobbklassificering och funktion.

Dina ansvarsområden

Baserat på 7.1.3 finns det många roller som ingår i klusteråtgärder. Utöver standardresursrollerna i Azure måste du definiera omfattningen och processen för åtkomst.

Överväg till exempel klusteroperatorrollen. De bör ha en tydligt definierad spelbok för klusterdeklareringsaktiviteter. Hur skiljer sig åtkomsten från arbetsbelastningsteamet? Beroende på din organisation kan de vara desamma. Här är några saker att tänka på:

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

Se till att definitionerna dokumenteras i styrningsdokumentation, policyer och utbildningsmaterial kring arbetsbelastningsoperatorn och klusteroperatorn.

Krav 7.2.3

Standardinställningen "neka alla".

Dina ansvarsområden

När du startar konfigurationen börjar du med noll förtroendeprinciper. 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-Azure Key Vault och Azure Container Registry har nekat alla behörigheter som standard.

• Alla administrativa åtkomstpunkter, till exempel en jumpbox, ska neka all åtkomst i den inledande konfigurationen. Alla förhöjda behörigheter måste definieras uttryckligen till regeln Neka alla.

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.

Dina ansvarsområden

Det är viktigt att du underhåller omfattande dokumentation om processer och principer. Detta inkluderar Azure- och Kubernetes RBAC-principer och organisationsstyrningsprinciper. 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 som ingår i godkännandeprocessen ur ett principperspektiv.