Övervaka driften av ett AKS-baslinjekluster för ett PCI-DSS 3.2.1 (del 7 av 9)

Kubernetes Service
Azure Security Center
Monitor

Den här artikeln beskriver överväganden 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 artikeln ingår i en serie. Läs introduktionen.

Viktigt

Vägledningen och den tillhörande implementeringen bygger på AKS-baslinjearkitekturen. Den arkitekturen baseras på en topologi av nav och ekrar. Det virtuella hubbnätverket innehåller brandväggen för att styra utgående trafik, gateway-trafik från lokala nätverk och ett tredje nätverk för underhåll. Det virtuella ekernätverket innehåller AKS-klustret som tillhandahåller korthållardatamiljön (CDE) och är värd för PCI DSS arbetsbelastningen.

GitHub logotypGitHub: Azure Kubernetes Service (AKS) Baslinjekluster för reglerade arbetsbelastningar visar en reglerad miljö. Implementeringen illustrerar användningen av granskningshistorik via olika Azure Monitor funktioner. Den innehåller exempel på nätverkstestpunkter i klustret och resurser som interagerar med klustrets undernät.

Övervaka och testa nätverk regelbundet

Krav 10– Spåra och övervaka all åtkomst till nätverksresurser och korthållardata

Stöd för AKS-funktioner

Azure tillhandahåller funktionen Container Insights som övervakar containrar, inklusive AKS-kluster. Mer information finns i Översikt över containerinsikter.

AKS tillhandahåller granskningsloggar på flera nivåer som kan vara användbara för att skydda systemet och data proaktivt. Aktivitetsloggar ger information om åtgärder relaterade till konto- och hemlighetshantering; hantering av diagnostikinställningar; serverhantering; och andra åtgärder för resursåtkomst. Alla loggar registreras med datum, tid, identitet och annan detaljerad information. Du kan också komma åt alla kronologiska poster för alla API-anrop som görs i AKS-klustret. Detta inkluderar information om anroparen, tid när anropet gjordes, källan där anropet initierades och så vidare. Mer information finns i Aktivera och granska Kubernetes-kontrollplansloggar i Azure Kubernetes Service (AKS).

RBAC (rollbaserad åtkomstkontroll) kan användas för att hantera resursåtkomstprincipen som standard i Azure.

Alla loggar ska lagras i ett kundägt lagringskonto eller i Log Analytics. På så sätt kan du snabbt generera insikter från en stor mängd data. Alla loggar sparas med minst tre kopior i en region. Du kan ha fler kopior genom att aktivera säkerhetskopiering eller replikering mellan regioner. Alla loggposter är bara tillgängliga via skyddade HTTP-kanaler.

Med Azures aviseringsramverk kan du konfigurera aviseringar för att identifiera misstänkt åtkomst. Du kan ange vilka aviseringar som ska utt sparkas och händelserna. Användare kan också manuellt kontrollera den fullständiga loggen med Log Analytics med filtreringsfunktion baserat på aktivitetstyp, aktivitetinnehåll eller anropare av aktiviteten.

Dina ansvarsområden

Krav Ansvar
Krav 10.1 Implementera granskningshistorik för att länka all åtkomst till systemkomponenter till varje enskild användare.
Krav 10.2 Implementera automatiserade granskningsloggar för alla systemkomponenter för att rekonstruera följande händelser:
Krav 10.3 Registrera minst följande granskningsloggposter för alla systemkomponenter för varje händelse:
Krav 10.4 Med hjälp av tidssynkroniseringsteknik synkroniserar du alla kritiska systemklockor och -tider och ser till att följande implementeras för att hämta, distribuera och lagra tid.
Krav 10.5 Skydda granskningshistoriken så att de inte kan ändras.
Krav 10.6 Granska loggar och säkerhetshändelser för alla systemkomponenter för att identifiera avvikelser eller misstänkt aktivitet.
Krav 10.7 Behåll granskningslogghistoriken i minst ett år, med minst tre månader omedelbart tillgängliga för analys (till exempel online, arkiverad eller återställningsbar från säkerhetskopia).
Krav 10.8 Ytterligare krav endast för tjänstleverantörer: Svara på fel i kritiska säkerhetskontroller inom rimlig tid. Processer för att svara på fel i säkerhetskontroller måste inkludera
Krav 10.9 Se till att säkerhetsprinciper och operativa procedurer för övervakning av all åtkomst till nätverksresurser och korthållardata dokumenteras, används och är kända för alla berörda parter.

Krav 11– Testa säkerhetssystem och processer regelbundet

Stöd för AKS-funktioner

AKS är integrerat med Azure-övervakningstjänster:

  • Microsoft Defender for Cloud har många funktioner för säkerhetsgenomsökning. Till exempel genomsöker Defender for Cloud avbildningar som hämtas och push-skickas till containerregister och ger rekommendationer. Mer information finns i Sårbarhetshantering – genomskanning av containeravbildningar. Du kan också använda övervakning av filintegritet (FIM) för att kontrollera systemfiler.

  • Azure Monitor kan användas för att ställa in aviseringar baserat på händelsetyp för att skydda systemets integritet och säkerhet. När det finns förväntade systemfel på AKS-noder, avdelar AKS automatiskt resursen inom rimlig tid utan avbrott i systembearbetningen.

AKS-kluster skyddas av Azure Application Gateway med Web Application Firewall (WAF). Detta kan konfigureras i identifieringsläge för att logga aviseringar och hot. Ett starkare läge är det förebyggande läget, som aktivt blockerar identifierade intrång och attacker. Mer information finns i Metodtips för nätverksanslutning och säkerhet i Azure Kubernetes Service (AKS).

Dina ansvarsområden

Krav Ansvar
Krav 11.1 Implementera processer för att testa förekomsten av trådlösa åtkomstpunkter (802.11) och identifiera alla auktoriserade och obehöriga trådlösa åtkomstpunkter kvartalsvis.
Krav 11.2 Kör interna och externa nätverkssäkerhetsproblem genomsökningar minst kvartalsvis och efter betydande ändringar i nätverket (till exempel nya systemkomponentinstallationer, ändringar i nätverkstopologin, ändringar av brandväggsregler, produktuppgraderingar).
Krav 11.3 Implementera en metod för intrångstest som omfattar följande:
Krav 11.4 Använd intrångsidentifiering och/eller intrångsskydd för att identifiera och/eller förhindra intrång i nätverket.
Krav 11.5 Distribuera en mekanism för ändringsidentifiering (till exempel övervakningsverktyg för filintegritet) för att varna personal om obehöriga ändringar (inklusive ändringar, tillägg och borttagningar) av kritiska systemfiler, konfigurationsfiler eller innehållsfiler; och konfigurera programvaran för att utföra kritiska filjämförelser minst en gång i veckan.
Krav 11.6 Se till att säkerhetsprinciper och operativa procedurer för säkerhetsövervakning och -testning dokumenteras, används och är kända för alla berörda parter.

Krav 10.1

Implementera granskningshistorik för att länka all åtkomst till systemkomponenter till varje enskild användare.

Dina ansvarsområden

Vi rekommenderar att du använder följande sätt för att spåra åtgärder som utförs på varje komponent:

  • Aktivitetslogg. Den här loggen innehåller information om typen och tiden för Azure-resursåtgärder. Den loggar också identiteten som startade åtgärden. Den är aktiverad som standard och informationen samlas in så snart resursåtgärden är klar. Den här granskningsloggen är skrivskyddad och kan inte tas bort.

    Data sparas i 90 dagar. För längre kvarhållningsalternativ kan du skicka aktivitetsloggposter till Azure Storage.

    Skärmbild som visar Azure-aktivitetsloggen.

  • Diagnostikinställning. Tillhandahåller diagnostik- och granskningsinformation för Azure-resurser och den plattform som inställningen gäller för. Vi rekommenderar att du aktiverar detta för AKS och andra komponenter i systemet, till exempel Azure Blob Storage och Key Vault. Baserat på resurstypen kan du välja kategorier av loggar och måttdata och skicka dem till ett mål. Diagnostik mottagare måste uppfylla de kvarhållningsperioder som krävs.

    • Diagnostikinställning för AKS. Aktivera Kubernetes-granskningsloggar från de angivna AKS-kategorierna. Detta inkluderar kube-audit eller kube-audit-admin och guard .

      Aktivera kube-audit-admin för att se api-serveranrop för loggdata som kan ändra klustrets tillstånd. Om du behöver en granskningslogg för alla API-serverinteraktioner (inklusive icke-modifierande händelser såsom läsbegäranden) aktiverar du kube-audit i stället. Dessa händelser kan vara produktiva, skapa brus och öka kostnaden. De här loggarna innehåller information om det åtkomst- och identitetsnamn som används för att göra begäran.

      Aktivera guard loggar för att spåra hanterade Azure AD- och Azure-granskningar för rollbaserad åtkomstkontroll (RBAC).

    Förutom de användarbaserade loggarna bör du överväga loggar från Kubernetes-kontrollplanet, kube-apiserver inklusive och kube-controller-manager . Dessa är vanligtvis inte användarrelaterade, men kan hjälpa till att korrelera systemändringar som användare har gjort.

    Mer information finns i Visa kontrollplanets komponentloggar.

    Den här referensimplementering cluster-autoscaler aktiverar kube-controller-managerkube-audit-admin loggarna , , guard och . All den informationen skickas till en Log Analytics-arbetsyta för analys. Kvarhållningsperioden är inställd på 90 dagar.

    Skärmbild som visar diagnostikinställningen A K S.

  • Azure Kubernetes Service Diagnostics. Använd den här funktionen för att identifiera och felsöka problem med klustret, till exempel nodfel. Nätverksspecifika diagnostikdata ingår också. Den här funktionen är tillgänglig utan extra kostnad. Dessa data är vanligtvis inte användarrelaterade, men kan hjälpa till att korrelera systemändringar som användare har gjort. Information om den här funktionen finns i Azure Kubernetes Service Diagnostics.

De föregående mekanismerna för granskningsloggar bör implementeras vid tidpunkten för resursdistributionen. Azure Policy bör också vara aktiv för att säkerställa att dessa konfigurationer inte oavsiktligt eller skadligt inaktiveras i din CDE.

Krav 10.2

Implementera automatiserade granskningsloggar för alla systemkomponenter för att rekonstruera följande händelser:

  • 10.2.1 Alla enskilda användare har åtkomst till korthållardata
  • 10.2.2 Alla åtgärder som vidtas av en person med rot- eller administratörsbehörighet
  • 10.2.3 Åtkomst till alla granskningsloggar
  • 10.2.4 Ogiltiga logiska åtkomstförsök
  • 10.2 5 Användning av och ändringar av identifierings- och autentiseringsmekanismer – inklusive men inte begränsat till att skapa nya konton och utökade privilegier – och alla ändringar, tillägg eller borttagningar av konton med rot- eller administratörsbehörigheter
  • 10.2.6 Initiering, stopp eller pausing av granskningsloggarna
  • 10.2.7 Generering och borttagning av objekt på systemnivå

Dina ansvarsområden

AKS tillhandahåller granskningsloggar på flera nivåer, enligt beskrivningen i Krav 10.1. Här är några viktiga punkter:

  • Som standard innehåller aktivitetsloggar information om kritiska Azure-resursåtgärder. Alla loggar innehåller status, tid och identiteten som startade åtgärden.
  • Aktivera diagnostikinställningar för att få åtkomst till alla poster för alla API-anrop som görs i AKS-klustret. Loggarna innehåller information om beställaren, tidsstämpeln, källan för begäran och innehållet i begäran. Lagra loggarna på en Log Analytics-arbetsyta med en lämplig kvarhållningsperiod. Aktivera Log Analytics-arbetsyteloggning för att se till att även åtkomst till den här spårningsloggen loggas.
  • Inkludera granskningsloggning för annan beräkning, till exempel byggaragenter och jumpboxar. Inaktivera åtkomst till systemen direkt som rot. Detta säkerställer att alla åtgärder utförs under en specifik identitet.
  • Logga misslyckade åtkomstförsök. Detta inkluderar åtkomstbegäranden till komponenter som Azure Storage, Azure Key Vault, AKS API-servern och eventuell RDP/SSH-åtkomst på ytterligare beräkning.
  • Dra nytta av funktioner som erbjuds av säkerhetsagenter från tredje part och som kan hjälpa dig att analysera användarmönster i ditt AKS-kluster. Detta kan vara användbart för granskningsdata för användaråtkomst.

Krav 10.3

Registrera minst följande granskningsloggposter för alla systemkomponenter för varje händelse:

  • 10.3.1 Användaridentifiering
  • 10.3.2 Händelsetyp
  • 10.3.3 Datum och tid
  • 10.3.4 Indikation på lyckad eller misslyckad
  • 10.3.5 Händelsens ursprung
  • 10.3.6 Identitet eller namn på berörda data, systemkomponent eller resurs.

Dina ansvarsområden

Enligt beskrivningen i Krav 10.2kan du hämta granskningsloggar från klustret genom att aktivera diagnostikinställningen för AKS. Loggarna innehåller detaljerad information om hämta, lista, skapa, uppdatera, ta bort, korrigera och publicera händelser. Loggarna innehåller information i listan under Krav. Lagra loggarna i ett lagringskonto så att du kan köra frågor mot informationen.

Du vill till exempel visa den föregående uppsättningen information för kube-audit-admin-händelser genom att köra den här frågan:

AzureDiagnostics
| where Category == 'kube-audit-admin'
| project TimeGenerated, ResourceId, log_s,  pod_s
| top 200 by TimeGenerated desc

Skärmbild som visar ett diagnostikexempel.

Resultatuppsättningen visar informationen som en del av log_s fältet.

Nödvändig information Schema
Användaridentifiering SourceIPs
Typ av händelse Verb
Datum och tid requestReceivedTimestamp
Indikation på lyckad eller misslyckad responseStatus
Händelsens ursprung användare
Identitet eller namn på berörda data, systemkomponent eller resurs objectRef

Information om huvudloggen finns i Visa kontrollplanets komponentloggar.

Krav 10.4

Med hjälp av tidssynkroniseringsteknik synkroniserar du alla kritiska systemklockor och -tider och ser till att följande implementeras för att hämta, distribuera och lagra tid.

  • 10.4.1 Kritiska system har rätt och konsekvent tid.
  • 10.4.2 Tid då data skyddas.
  • 10.4.3 Tidsinställningar tas emot från bransch accepterade tidskällor.

Obs! Ett exempel på tidssynkroniseringsteknik är NTP (Network Time Protocol).

Dina ansvarsområden

AKS använder NTP från de underliggande Azure-värdarna och kräver inte några tillåtna utgående nätverkstrafik för detta. Andra virtuella datorer som du lägger till i din CDE kan använda externa NTP-servrar, till exempel ntp.ubuntu.org (och dess pool) som tidssynkroniseringskälla. Eventuella ytterligare beräkningar som du använder i din CDE bör uttryckligen använda valfri NTP-källa och bör dokumenteras.

Krav 10.5

Begränsa visningen av granskningsloggar till de med jobbrelaterade behov.

  • 10.5.1 Begränsa visning av granskningsloggar till de med jobbrelaterade behov.
  • 10.5.2 Skydda granskningsloggfiler från obehöriga ändringar.
  • 10.5.3 Servera snabbt granskningsloggfiler till en centraliserad loggserver eller media som är svår att ändra.
  • 10.5.4 Skriv loggar för extern teknik till en säker, centraliserad, intern loggserver eller medieenhet.
  • 10.5.5 Använd övervakning av filintegritet eller ändringsidentifiering i loggar för att säkerställa att befintliga loggdata inte kan ändras utan att generera aviseringar (även om nya data som läggs till inte ska orsaka en avisering).

Dina ansvarsområden

Att ha flera loggningssynkroniseringar ökar arbetet med att skydda, granska, analysera och köra frågor mot spårningsloggdata. Planera dina topologier för granskningsloggar för att balansera kompromisser mellan fullständig isolering av granskningsloggar och hanteringsproblem.

Integrera loggar när det är möjligt. Fördelen är möjligheten att granska, analysera och fråga efter data effektivt. Azure erbjuder flera teknikalternativ. Du kan använda Azure Monitor för containrar för 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. Andra populära alternativ från tredje part är Splunk, QRadar och ArcSight. Microsoft Defender för moln och Azure Monitor stöd för alla dessa lösningar. Dessa lösningar är data mottagare med endast tillägg för att se till att spåren inte kan ändras.

Defender for Cloud kan exportera resultat med konfigurerade intervall. Mer information finns i Löpande export.

Alla loggar sparas med minst tre kopior i en region. Som en strategi för säkerhetskopiering kan du ha fler kopior genom att aktivera säkerhetskopiering eller replikering mellan regioner. Alla loggposter är bara tillgängliga via skyddade HTTP/S-kanaler.

Log Analytics och Microsoft Sentinel stöder olika rollbaserade åtkomstkontroller för att hantera åtkomst till granskningsloggar. Kontrollera att rollerna är mappade till organisationens roller och ansvarsområden.

Kontrollera att Log Analytics-arbetsytan har stöd för både åtgärder och efterlevnadsbehov. Tänk dig en dedikerad arbetsyta för dina kluster inom omfång, som vidarebefordrar till DIN SIEM-lösning.

De flesta loggning i AKS kommer från stdout/stderr och samlas in av Azure Monitor Container Insights. Om du har ytterligare manuellt skapade loggar bör du överväga att skicka data på ett sätt som skickas till en betrodd vidaresänd dataström och som inte kan manipuleras.

Krav 10.6

Granska loggar och säkerhetshändelser för alla systemkomponenter för att identifiera avvikelser eller misstänkt aktivitet.

  • 10.6.1 Granska följande minst dagligen:
    • Alla säkerhetshändelser
    • Loggar över alla systemkomponenter som lagrar, bearbetar eller överför CHD och/eller SAD
    • Loggar över alla kritiska systemkomponenter
    • Loggar med alla servrar och systemkomponenter som utför säkerhetsfunktioner (till exempel brandväggar, intrångsidentifieringssystem/intrångsskyddssystem (IDS/IPS), autentiseringsservrar, omdirigeringsservrar för e-handel osv.)."
  • 10.6.2 Granska loggar för alla andra systemkomponenter regelbundet baserat på organisationens principer och riskhanteringsstrategi, baserat på organisationens årliga riskbedömning.
  • 10.6.3 Följ upp undantag och avvikelser som identifierats under granskningsprocessen.

Dina ansvarsområden

Azure-övervakningstjänster, Azure Monitor och Microsoft Defender for Cloud, kan generera meddelanden eller aviseringar när de identifierar avvikande aktivitet. Aviseringarna innehåller sammanhangsinformation som allvarlighetsgrad, status och aktivitetstid.

När aviseringar genereras bör du ha en åtgärdsstrategi och granska förloppet. Ett sätt är att spåra säkerhetspoängen i Microsoft Defender for Cloud och jämföra den med historiska resultat.

Centralisera data i en enda vy med hjälp av SIEM-lösningar, till exempel Microsoft Sentinel. Integrering av data kan ge omfattande aviseringskontext.

Du kan också manuellt kontrollera den fullständiga loggen i lagringen. I Log Analytics kan du till exempel använda en filtreringsfunktion baserat på typen av aktivitet, innehållet i aktiviteten eller aktivitetens anropare.

Ha organisationsprinciper för att regelbundet granska aviseringar och händelser och planera initiativ med specifika förbättringsmål. Använd anpassade sparade frågor i Log Analytics för att dokumentera avsedda loggfrågor och för att göra frågor enklare. Detta säkerställer att teamet vet vad som är viktigt att granska när det gäller 10.6 och att alla manuella åtgärder som ingår i den här processen följer ett konsekvent arbetsflöde.

Krav 10.7

Behåll granskningslogghistoriken i minst ett år, med minst tre månader omedelbart tillgängliga för analys (till exempel online, arkiverad eller återställningsbar från säkerhetskopia).

Dina ansvarsområden

Loggar är inte tillgängliga på obestämd tid. Se till att Azure-aktivitetsloggar och diagnostikinställningar bevaras och kan efterfrågas. Ange en kvarhållningsperiod på tre månader när du aktiverar diagnostikinställningar för dina resurser. Använd Azure Storage-konton för långsiktig arkivering, så att de kan användas för granskningar eller offlineanalys. Implementera din långsiktiga arkiveringslösning så att den överensstämmer med principen om skriv en gång, läs många.

Krav 10.8

  • 10.8.1 Ytterligare krav endast för tjänstleverantörer: Svara på fel i kritiska säkerhetskontroller inom rimlig tid. Processer för att svara på fel i säkerhetskontroller måste innehålla:

  • Återställa säkerhetsfunktioner

  • Identifiera och dokumentera varaktigheten (datum och tid från början till slut) för säkerhetsfelet

  • Identifiera och dokumentera orsaker till fel, inklusive rotorsaken och dokumentera de åtgärder som krävs för att åtgärda rotorsaken

  • Identifiera och åtgärda eventuella säkerhetsproblem som uppstod under felet

  • Utföra en riskbedömning för att avgöra om ytterligare åtgärder krävs till följd av säkerhetsfelet

  • Implementera kontroller för att förhindra att felorsaken upprepas – Återuppta övervakningen av säkerhetskontroller

Dina ansvarsområden

När det är praktiskt bör du ha aviseringar som anger att det finns kritiska säkerhetskontroller. Annars bör du se till att granskningsprocessen kan identifiera bristen på en förväntad säkerhetskontroll inom rimlig tid. Överväg kontroller, till exempel säkerhetsagenter som körs i AKS-klustret och åtkomstkontroller (IAM och nätverk) på Azure-resurser. Inkludera inställningar som att kontrollera om AKS-klustret är ett privat kluster, söka efter nätverksexponeringspunkter via regler för nätverkssäkerhetsgrupp (NSG) eller söka efter oväntade offentliga IP-adresser. Inkludera även oväntade ändringar i DNS, nätverksroutning, brandvägg och Azure AD.

Krav 10.9

Se till att säkerhetsprinciper och operativa procedurer för övervakning av all åtkomst till nätverksresurser och 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. Underhåll dokumentation om de framtvingade principerna. Som en del av ditt övervakningsarbete måste personer utbildas i att aktivera och visa granskningsloggar och identifiera och åtgärda vanliga risker. Detta är särskilt viktigt för personer som ingår i godkännandeprocessen ur ett principperspektiv.

Krav 11.1

Implementera processer för att testa förekomsten av trådlösa åtkomstpunkter (802.11) och identifiera alla auktoriserade och obehöriga trådlösa åtkomstpunkter kvartalsvis.

Externa nätverk omfattas inte av den här dokumentationen och måste utvärderas separat.

Dina ansvarsområden

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

Krav 11.2

Kör interna och externa nätverkssäkerhetsproblem genomsökningar minst kvartalsvis och efter betydande ändringar i nätverket (till exempel nya systemkomponentinstallationer, ändringar i nätverkstopologin, ändringar av brandväggsregler, produktuppgraderingar).

Mer information finns i PCI (Payment Card Industry) Data Security Standard Approved Scanning Vendors.

Dina ansvarsområden

Ha en process som söker efter ändringar i AKS-klustret, nätverkskonfigurationen, containerregister och andra komponenter i arkitekturen.

Om det finns ändringar i nätverket bör processen utvärdera om en genomsökning är nödvändig. Är klustret nu till exempel exponerat för det offentliga Internet? Är de nya brandväggsreglerna för tillåtande? Finns det några säkerhetsluckor i flödet mellan poddarna i klustret?

Ha en tydlig och överenskommen definition av betydande ändringar vad gäller din infrastruktur. Några exempel kan vara konfiguration av NSG-regler, Azure Firewall-regler, peering för virtuella nätverk, DNS-inställningar, Azure Private Link konfigurationer och andra nätverkskomponenter.

GÄLLER FÖR 11.2.1

Kvartalsgenomsökningen efter säkerhetsrisker måste köras av kvalificerad personal med djup förståelse för nätverksbegreppen i Azure och Kubernetes. Mappa resultatet till Krav 6.1 med allvarlighetsgrad och lös högprioriterade objekt. Om det finns betydande ändringar kör du genomsökningarna före den schemalagda kvartalsgenomsökningen. Detta hjälper dig att identifiera nya säkerhetsrisker så att du kan åtgärda problem proaktivt.

Den här genomsökningen måste även innehålla nätverk i klustret (pod-till-pod).

GÄLLER FÖR 11.2.2 Välj en ASV (Approved Scanning Vendor) som har omfattande erfarenhet av Azure-nätverk och Kubernetes. Detta ger djup och specificitet i föreslagna åtgärder.

Krav 11.3

Implementera en metod för intrångstestning som omfattar följande:

  • Baseras på bransch accepterade metoder för intrångstestning (till exempel NIST SP800-115)
  • Omfattar täckning för hela CDE-perimetern och kritiska system
  • Omfattar testning både inom och utanför nätverket
  • Omfattar testning för att verifiera eventuella kontroller för segmentering och omfångsminskning
  • Definierar intrångstester på programnivå som minst inkluderar de säkerhetsrisker som anges i krav 6.5
  • Definierar intrångstester på nätverkslager för att inkludera komponenter som stöder nätverksfunktioner samt operativsystem
  • Omfattar granskning och övervägande av hot och sårbarheter under de senaste 12 månaderna
  • Anger kvarhållning av penetrationstestresultat och reparationsaktiviteter.

Dina ansvarsområden

Utför intrångstester för att hitta säkerhetsluckor genom att samla in information, analysera sårbarheter och rapportera. Vi rekommenderar att du följer branschriktlinjerna i PTES (Penetration Testing Execution Standard) för att hantera vanliga scenarier och de aktiviteter som krävs för att upprätta en baslinje.

Intrångstestare bör ha en djup förståelse för lokala nätverk och Azure-nätverk för att säkerställa att de årliga segmenteringstesterna täcks i stor utsträckning. Utöka testmetoden till klusternätverk. Detta kräver stark erfarenhet av Kubernetes-nätverksbegrepp.

Testerna måste omfatta de program- och datalager som körs i CDE:en.

I en intrångstestningsövning kan utövare behöva åtkomst till känsliga data för hela organisationen. Följ reglerna för engagemang för att se till att åtkomsten och avsikten inte missbrukas. Vägledning om hur du planerar och kör simulerade attacker finns i Intrångstestningsregler för engagemang.

Krav 11.4

Använd intrångsidentifiering och/eller intrångsskyddstekniker för att identifiera och/eller förhindra intrång i nätverket. Övervaka all trafik i perimetern för korthållardatamiljön samt vid kritiska punkter i korthållardatamiljön och varna personalen för misstänkta komprometterade.

Dina ansvarsområden

Skydda AKS-klustret genom att inspektera inkommande trafik. Ett sätt är att använda en brandvägg för webbaserade program (WAF). I den här arkitekturen förhindrar Azure Application Gateway med integrerad WAF intrång. Använd förhindra-läget för att aktivt blockera identifierade intrång och attacker. Använd inte bara identifieringsläget. Mer information finns i Metodtips för nätverksanslutning och säkerhet i Azure Kubernetes Service (AKS).

Ett alternativt alternativ är att använda intrångsidentifiering och/eller intrångsskyddsfunktioner i Azure Firewall Premium. Mer information finns i IDPS.

Ett annat alternativ är att aktivera Azure Monitor Network Insights.

Aktivera Microsoft Defender-planer när de gäller för olika komponenter i CDE:n. Om Azure SQL används för att lagra CHD ser Microsoft Defender for SQL till att datalagerintrång identifieras.

Identifiera även avvikelser i trafikmönster genom att ansluta NSG-flödesloggar till en central siem-lösning, till exempel Microsoft Sentinel. I den här referensimplementering är loggarna i läget för endast tillägg, vilket minimerar spårning av ändringar i granskningsloggar. Alla loggar som skickas till externa mottagare för långsiktig lagring får dock inte ändras. De måste följa metoden write-once/read-many. Kontrollera att FIM-lösningen (File Integrity Monitoring) omfattar de externa entiteterna för att identifiera ändringar.

Krav 11.5

Distribuera en mekanism för ändringsidentifiering (till exempel övervakningsverktyg för filintegritet) för att meddela personal om obehöriga ändringar (inklusive ändringar, tillägg och borttagningar) av kritiska systemfiler, konfigurationsfiler eller innehållsfiler; och konfigurera programvaran för att utföra kritiska filjämförelser minst en gång i veckan.

Dina ansvarsområden

I klustret kör du en FIM-lösning (file integrity monitoring) tillsammans med en Kubernetes-medveten säkerhetsagent för att identifiera åtkomst på fil- och systemnivå som kan resultera i ändringar på nodnivå. När du väljer en FIM-lösning bör du ha en tydlig förståelse för dess funktioner och djupidentifiering. Överväg programvara som utvecklats av välkända leverantörer.

Viktigt

Referensimplementeringen tillhandahåller en platshållardistribution DaemonSet för att köra en FIM-lösningsagent för program mot skadlig programvara. Agenten körs på varje virtuell nod i klustret. Placera ditt val av program mot skadlig programvara i den här distributionen.

Kontrollera alla standardinställningar för FIM-verktyget för att säkerställa att värdena identifierar de parametrar som du vill täcka och justerar inställningarna på lämpligt sätt.

Aktivera lösningen för att skicka loggar till din övervaknings- eller SIEM-lösning så att de kan generera aviseringar. Var medveten om ändringar i loggschemat, eller så kan du missa kritiska aviseringar.

Alla andra ytterligare beräkningar i CDE bör ha ändringsspårning aktiverat.

Krav 11.6

Se till att säkerhetsprinciper och operativa procedurer för säkerhetsövervakning och -testning 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 ditt testarbete inkluderar du gransknings- och granskningskriterierna. Se till att teamet förstår aspekterna av intrångstestning. Ha en dokumenterad åtgärdsplan för att minska riskerna.

Detta är särskilt viktigt för personer som ingår i godkännandeprocessen ur ett principperspektiv.

Nästa

Upprätthåll en princip som hanterar informationssäkerhet för all personal.