Övervaka åtgärder för ett AKS-baslinjekluster för en PCI-DSS 3.2.1 (del 7 av 9)

I den här artikeln beskrivs överväganden för ett AKS-kluster (Azure Kubernetes Service) som kör en arbetsbelastning i enlighet med Payment Card Industry Data Security Standard (PCI-DSS 3.2.1).

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

Ö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 innehåller information om åtgärder relaterade till konto- och hemlighetshantering. diagnostikinställningshantering; serverhantering; och andra resursåtkomståtgärder. 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 till AKS-klustret. Loggarna innehåller information om anroparen, tidpunkten då samtalet 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 en standardpraxis i Azure.

Alla loggar ska lagras i ett kundägt lagringskonto eller Azure Monitor-loggar. 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 endast 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 måste utlöses och händelserna. Användare kan också manuellt kontrollera den fullständiga loggen med Log Analytics med filtreringsfunktionen baserat på typen av aktivitet, innehållet i aktiviteten eller anroparen för aktiviteten.

Ditt ansvar

Krav	Ansvar
Krav 10.1	Implementera spårningsloggar 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 spårningsposter 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 spårningsloggar 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 spårningshistoriken 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 i tid. Processer för att hantera 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 regelbundet säkerhetssystem och processer

Stöd för AKS-funktioner

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

• Microsoft Defender for Containers innehåller många funktioner för säkerhetsgenomsökning. Defender for Containers söker till exempel igenom avbildningar som hämtats, push-överförts och importerats till containerregister och ger rekommendationer. Mer information finns i Sårbarhetsbedömning.

• Azure Monitor kan användas för att ange 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, autoheals AKS resursen i tid utan avbrott i systembearbetningen.

AKS-kluster skyddas av Azure Application Gateway med Web Application Firewall (WAF) och 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 upptäckta intrång och attacker. Mer information finns i Metodtips för nätverksanslutning och säkerhet i Azure Kubernetes Service (AKS).

Ditt ansvar

Krav	Ansvar
Krav 11.1	Implementera processer för att testa förekomsten av trådlösa åtkomstpunkter (802.11) och identifiera och identifiera alla auktoriserade och obehöriga trådlösa åtkomstpunkter varje kvartal.
Krav 11.2	Kör interna och externa nätverkssårbarhetsgenomsökningar minst kvartalsvis och efter betydande ändringar i nätverket (till exempel nya installationer av systemkomponenter, ändringar i nätverkstopologin, ändringar av brandväggsregler, produktuppgraderingar).
Krav 11.3	Implementera en metod för intrångstestning som innehåller följande:
Krav 11.4	Använd tekniker för intrångsidentifiering och/eller intrångsskydd för att upptäcka 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 personalen 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 varje vecka.
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 spårningsloggar för att länka all åtkomst till systemkomponenter till varje enskild användare.

Ditt ansvar

Vi rekommenderar att du använder granskningsåtgärder som utförs på varje komponent med hjälp av följande metoder:

• Azure Monitor-aktivitetslogg. Aktivitetsloggen innehåller information om typen och tiden för Azure-resursåtgärder. Den loggar även identiteten som startade åtgärden. Den är aktiverad som standard och informationen samlas in så snart resursåtgärden är klar. Granskningsloggen är skrivskyddad och kan inte tas bort.

  Data behålls i 90 dagar. För längre kvarhållningsalternativ bör du överväga att skicka aktivitetsloggposter till Azure Monitor-loggar och konfigurera en kvarhållnings- och arkivprincip.

  

• Azure Diagnostic-inställningar. Tillhandahåller diagnostik- och granskningsinformation om Azure-resurser och den plattform som inställningen gäller för. Vi rekommenderar att du aktiverar diagnostikinställningar för AKS och andra komponenter i systemet, till exempel Azure Blob Storage och Key Vault. Baserat på resurstypen kan du välja vilken typ av loggar och måttdata som ska skickas till ett mål. Diagnostikmålet måste uppfylla de kvarhållningsperioder som krävs.

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

    Aktivera kube-audit-admin för att se loggbaserade API-serveranrop som kan ändra tillståndet för klustret. Om du behöver en spårningslogg för alla API-serverinteraktioner (inklusive icke-ändrande händelser, till exempel läsbegäranden), aktiverar du kube-audit i stället. Dessa händelser kan vara produktiva, skapa brus och öka din förbrukningskostnad. De här loggarna innehåller information om åtkomst- och identitetsnamnet som används för att göra begäran.

    Aktivera guard loggar för att spåra hanterade Granskningar av Microsoft Entra-ID och rollbaserad åtkomstkontroll i Azure (RBAC).

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

  Mer information finns i Visa komponentloggarna för kontrollplanet.

  Den här referensimplementeringen aktiverar cluster-autoscaler, kube-controller-manager, kube-audit-adminoch guard loggar och vidarebefordrar till en Log Analytics-arbetsyta. Kvarhållningsperioden för arbetsytan är inställd på 90 dagar.

  

• Azure Kubernetes Service-diagnostik (AKS) hjälper till att identifiera och felsöka problem med klustret, till exempel nodfel. Den innehåller även nätverksspecifika diagnostikdata som inte kostar extra. Dessa data är vanligtvis inte användarassocierade, men de kan hjälpa till att korrelera systemändringar som användarna har gjort. Mer information finns i Azure Kubernetes Service-diagnostik.

De föregående spårningsmekanismerna bör implementeras vid tidpunkten för resursdistributionen. Azure Policy bör också vara aktivt 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 enskild person med rotbehörighet eller administrativ behörighet
• 10.2.3 Åtkomst till alla spårningsloggar
• 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 skapande av nya konton och utökade privilegier – samt alla ändringar, tillägg eller borttagningar till konton med rotbehörighet eller administrativ behörighet
• 10.2.6 Initiering, stopp eller pausning av granskningsloggarna
• 10.2.7 Skapa och ta bort objekt på systemnivå

Ditt ansvar

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 inkluderar status, tid och den identitet 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 Loggning av Log Analytics-arbetsytor för att se till att även åtkomsten till spårningsloggen loggas.
• Aktivera syslog-samling med Container Insights för att samla in säkerhets- och hälsohändelseloggar på AKS-nodnivå i Log Analytics-arbetsytan. Dessa loggar bör också matas in i din SIEM.
• Inkludera loggning av operativsystem och användningsgranskning för annan beräkning, till exempel byggagenter och hopprutor. Inaktivera åtkomst till systemen direkt som rot. Kontrollera att alla åtgärder utförs under en specifik identitet.
• Logga misslyckade åtkomstförsök. Detta omfattar åtkomstbegäranden till komponenter som Azure Storage, Azure Key Vault, AKS API-servern och eventuell RDP/SSH-åtkomst i andra system.
• Dra nytta av funktioner som erbjuds av säkerhetsagenter från tredje part för att analysera användarmönster i ditt AKS-kluster. Dessa funktioner kan vara användbara för granskningsdata med användaråtkomst.

Krav 10.3

Registrera minst följande spårningsposter för alla systemkomponenter för varje händelse:

• 10.3.1 Användaridentifiering
• 10.3.2 Typ av händelse
• 10.3.3 Datum och tid
• 10.3.4 Lyckad eller misslyckad indikation
• 10.3.5 Händelsens ursprung
• 10.3.6 Identitet eller namn på berörda data, systemkomponent eller resurs.

Ditt ansvar

Enligt beskrivningen i Krav 10.2 kan du hämta granskningsloggar från klustret genom att aktivera diagnostikinställning 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 på ett lagringskonto så att du kan fråga efter informationen.

Du vill till exempel visa den föregående uppsättningen med 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

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

Nödvändig information	Schema
Användaridentifiering	Käll-IP-adresser
Typ av händelse	Verb
Datum och tid	requestReceivedTimestamp
Indikering för lyckade eller misslyckade	responseStatus
Ursprung för händelse	användare
Identitet eller namn på berörda data, systemkomponenter eller resurser	objectRef

Information om huvudloggen finns i Visa komponentloggarna för kontrollplanet.

Krav 10.4

Använd tidssynkroniseringsteknik för att synkronisera alla kritiska systemklockor och tider och kontrollera 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 Tidsdata skyddas.
• 10.4.3 Tidsinställningar tas emot från branschgodkända tidskällor.

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

Ditt ansvar

AKS använder NTP från de underliggande Azure-värdarna och kräver inga utgående nätverkstrafikbidrag för att stödja NTP. Andra virtuella datorer som du lägger till i din CDE kan använda externa NTP-servrar som ntp.ubuntu.org (och dess pool) som tidssynkroniseringskälla. Ytterligare beräkning som du tar med i din CDE bör uttryckligen använda valfri NTP-källa och ska dokumenteras.

Krav 10.5

Begränsa visning av spårningsloggar till endast personer med ett jobbrelaterat behov.

• 10.5.1 Begränsa visning av spårningsloggar till personer med ett jobbrelaterat behov.
• 10.5.2 Skydda spårningsfiler från obehöriga ändringar.
• 10.5.3 Säkerhetskopiera omedelbart spårningsloggfiler till en centraliserad loggserver eller media som är svår att ändra.
• 10.5.4 Skrivloggar för extern teknik till en säker, centraliserad, intern loggserver eller medieenhet.
• 10.5.5 Använd programvara för filintegritetsövervakning 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 bör orsaka en avisering).

Ditt ansvar

Om du har flera loggningssynkroniseringar kan du skydda, granska, analysera och köra frågor mot spårningsdata. Planera dina topologier för spårningsspår för att balansera avvägningar mellan fullständig isolering av spårningsspår och hanteringsproblem.

Integrera loggar när det är möjligt. Fördelen är möjligheten att granska, analysera och köra frågor mot data effektivt. Azure har flera teknikalternativ. Du kan använda Azure Monitor-containerinsikter för att skriva loggar till en Log Analytics-arbetsyta. Ett annat alternativ är att integrera data i SIEM-lösningar (säkerhetsinformation och händelsehantering), till exempel Microsoft Sentinel. Andra populära alternativ från tredje part är Splunk, QRadar och ArcSight. Microsoft Defender för molnet och Azure Monitor stöder alla dessa lösningar. Dessa lösningar är endast tilläggsdatamottagare för att se till att spåret inte kan ändras.

Defender för molnet kan exportera resultat med konfigurerade intervall. Mer information finns i Kontinuerlig export.

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

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

Kontrollera att Log Analytics-arbetsytan stöder både drifts- och efterlevnadsbehov. Överväg en dedikerad arbetsyta för dina omfångskluster som vidarebefordras till SIEM-lösningen.

De flesta loggningar i AKS kommer från stdout/stderr och samlas in av Azure Monitor Container Insights. Om du har andra loggar som skapats manuellt kan du överväga att generera data på ett sätt som skickas till en betrodd vidarebefordran och 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 varje dag:
  • Alla säkerhetshändelser
  • Loggar för alla systemkomponenter som lagrar, bearbetar eller överför CHD och/eller SAD
  • Loggar för alla kritiska systemkomponenter
  • Loggar för alla servrar och systemkomponenter som utför säkerhetsfunktioner (till exempel brandväggar, system för intrångsidentifiering/intrångsskydd (IDS/IPS), autentiseringsservrar, omdirigeringsservrar för e-handel osv.).
• 10.6.2 Granska loggar för alla andra systemkomponenter regelbundet baserat på organisationens policyer och riskhanteringsstrategi, enligt organisationens årliga riskbedömning.
• 10.6.3 Uppföljningsfel och avvikelser som identifierades under granskningsprocessen.

Ditt ansvar

Azure Monitoring Services, Azure Monitor och Microsoft Defender för molnet, kan generera meddelanden eller aviseringar när de identifierar avvikande aktivitet. Dessa aviseringar innehåller kontextinformation som allvarlighetsgrad, status och aktivitetstid.

När aviseringar genereras har du en reparationsstrategi och granskar förloppet. Ett sätt är att spåra säkerhetspoängen i Microsoft Defender för molnet 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å kontrollera den fullständiga loggen i lagringen manuellt. I Azure Monitor-loggar kan du till exempel använda en filtreringsfunktion baserat på typen av aktivitet, innehållet i aktiviteten eller anroparen för aktiviteten.

Ha organisationsprinciper för att granska aviseringar och händelser regelbundet 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 göra det enklare att köra frågor. 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 spårningshistoriken 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).

Ditt ansvar

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

Krav 10.8

• 10.8.1 Ytterligare krav endast för tjänsteleverantörer: Svara på fel i kritiska säkerhetskontroller i 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 start till slut) för säkerhetsfelet

• Identifiera och dokumentera orsaker till fel, inklusive rotorsak och dokumentreparation 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 orsaken till fel upprepas – Återuppta övervakningen av säkerhetskontroller"

Ditt ansvar

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

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.

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 ditt övervakningsarbete måste personer utbildas i att aktivera och visa granskningsloggar och identifiera och åtgärda de vanliga riskerna. Detta är 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 och identifiera alla auktoriserade och obehöriga trådlösa åtkomstpunkter varje kvartal.

Externa nätverk ligger utanför omfånget för den här dokumentationen och måste utvärderas separat.

Ditt ansvar

Den här arkitekturen och dess implementering är inte utformade för att stödja lokala eller företagsnätverks-till-moln-transaktioner via trådlösa anslutningar. Överväganden finns i vägledningen i den officiella PCI-DSS 3.2.1-standarden.

Krav 11.2

Kör interna och externa nätverkssårbarhetsgenomsökningar minst kvartalsvis och efter eventuella betydande nätverksändringar, till exempel:

• Nya installationer av systemkomponenter
• Ändringar i nätverkstopologi
• Ändringar av brandväggsregel
• Produktuppgraderingar

Mer information finns i PcI(Payment Card Industry) Data Security Standard Approved Scanning Vendors (Godkända genomsökningsleverantörer).

Ditt ansvar

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 till exempel nu exponerat för det offentliga Internet? Är de nya brandväggsreglerna alltfö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 när det gäller din infrastruktur. Några exempel är:

• Konfiguration av NSG- eller Azure Firewall-regler
• Peering för virtuella nätverk
• DNS-inställningar
• Azure Private Link-konfigurationer
• Andra nätverkskomponenter

GÄLLER FÖR 11.2.1

Den kvartalsvisa genomsökningen av sårbarheter måste köras av kompetent personal med djup förståelse för azure-nätverk och Kubernetes-nätverksbegrepp. Mappa resultatet till Krav 6.1 med allvarlighetsgrad och lös objekt med hög prioritet. Om det finns betydande ändringar kör du genomsökningarna före den schemalagda kvartalsgenomsökningen. På så sätt kan du identifiera nya säkerhetsrisker så att du proaktivt kan åtgärda problem.

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

GÄLLER FÖR 11.2.2 Välj en godkänd genomsökningsleverantör (ASV) 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 innehåller följande:

• Baseras på branschgodkända penetrationstestmetoder (till exempel NIST SP800-115)
• Omfattar täckning för hela CDE-perimetern och kritiska system
• Inkluderar testning både i och utanför nätverket
• Innehåller testning för att verifiera eventuella kontroller för segmentering och omfångsminskning
• Definierar intrångstester på programnivå för att minst inkludera de sårbarheter som anges i krav 6.5
• Definierar intrångstester på nätverksnivå för att inkludera komponenter som stöder nätverksfunktioner och operativsystem
• Omfattar granskning och övervägande av hot och sårbarheter som har upplevts under de senaste 12 månaderna
• Anger kvarhållning av resultat från intrångstestning och resultat av reparationsaktiviteter.

Ditt ansvar

Utför intrångstester för att hitta säkerhetsluckor genom att samla in information, analysera sårbarheter och rapportering. 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ångstestet 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 omfattas i stor utsträckning. Utöka testmetoden till klusternätverk. Den här personen kräver stark erfarenhet av Kubernetes-nätverksbegrepp.

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

I en övning för intrångstestning kan utövarna behöva åtkomst till känsliga data för hela organisationen. Följ reglerna för engagemang för att se till att åtkomst 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 tekniker för intrångsidentifiering och/eller intrångsskydd för att upptäcka och/eller förhindra intrång i nätverket. Övervaka all trafik i perimetern för korthållardatamiljön och vid kritiska punkter i korthållardatamiljön. Varna personalen för misstänkta kompromisser.

Ditt ansvar

Skydda AKS-klustret genom att inspektera inkommande trafik med hjälp av en brandvägg för webbprogram (WAF). I den här arkitekturen förhindrar Azure Application Gateway med integrerad WAF intrång. Använd prevent-läget för att aktivt blockera de identifierade intrången och attackerna. Använd inte bara identifieringsläge . Mer information finns i Metodtips för nätverksanslutning och säkerhet i Azure Kubernetes Service (AKS).

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

Ett annat alternativ är att aktivera Azure Monitor Network Insights, som ger åtkomst till nätverksövervakningsfunktioner som Anslut ion Monitor, flödesloggning för nätverkssäkerhetsgrupper (NSG:er) och Trafikanalys.

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

Identifiera även avvikelser i trafikmönster genom att ansluta NSG-flödesloggar till en centraliserad SIEM-lösning, till exempel Microsoft Sentinel. I den här referensimplementeringen är loggarna i tilläggsläge, vilket minimerar ändringsspårningen 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) täcker de externa entiteterna för att identifiera ändringar.

Krav 11.5

Distribuera en lösning för ändringsspårning (till exempel en lösning för övervakning av filintegritet) för att varna personalen om obehörig ändring av kritiska systemfiler, konfigurationsfiler eller innehållsfiler. Konfigurera produkten så att den utför kritiska filjämförelser minst varje vecka.

Ditt ansvar

Kör en FIM-lösning (File Integrity Monitoring) i klustret tillsammans med en Kubernetes-medveten säkerhetsagent för att identifiera fil- och systemnivååtkomst som kan leda till ändringar på nodnivå. När du väljer en FIM-lösning ska du ha en tydlig förståelse för dess funktioner och identifieringsdjupet. Överväg programvara som utvecklats av välrenommerade leverantörer.

Kontrollera alla standardinställningar för FIM-verktyget för att säkerställa att värdena identifierar de scenarier som du vill ta upp och justera inställningarna på rätt sätt.

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

Alla andra 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.

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 dina testinsatser inkluderar du granskningarnas takt och granskningskriterierna. Se till att teamet förstår aspekter av intrångstestning. Ha en dokumenterad reparationsplan för att minska de risker som hittas.

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

Nästa steg

Underhålla en princip som hanterar informationssäkerhet för all personal.