Monitorování operací AKS základního clusteru pro PCI-DSS 3.2.1 (část 7 z 9)

Kubernetes Service
Azure Security Center
Monitor

Tento článek popisuje požadavky pro cluster Azure Kubernetes Service (AKS), který spouští úlohu v souladu s normou zabezpečení dat v odvětví platebních karet (PCI-DSS 3.2.1).

Tento článek je součástí série článků. Přečtěte si Úvod.

Důležité

Doprovodné materiály a doprovodná implementace implementují na AKS základní architektuře. Tato architektura závisí na topologii hvězdicové topologie. Virtuální síť rozbočovače obsahuje bránu firewall pro řízení provozu, provozu brány z místních sítí a třetí sítě pro údržbu. Koncová virtuální síť obsahuje cluster AKS, který poskytuje datové prostředí (CDE) pro držitele a hostuje úlohu PCI DSS.

GitHub s logem GitHub : Cluster pro řízené úlohy Azure Kubernetes Service (AKS) pro regulované úlohy ukazuje na regulované prostředí. Tato implementace znázorňuje použití revizí auditu prostřednictvím různých funkcí Azure Monitor. Obsahuje příklady síťových zkušebních bodů v rámci clusteru a prostředků, které komunikují s podsítí clusteru.

Pravidelné monitorování a testování sítí

Požadavek 10 — Sledování a monitorování veškerého přístupu k síťovým prostředkům a datům držitelů

Podpora funkcí AKS

Azure poskytuje kontejner Přehledy funkci, která monitoruje kontejnery, včetně clusterů AKS. Další informace najdete v tématu Přehled služby Container Insights.

AKS poskytuje protokoly auditu na více úrovních, které mohou být užitečné při proaktivní ochraně systému a dat. Protokoly aktivit poskytují informace o operacích, které souvisí s účtem a správou tajných kódů. Správa nastavení diagnostiky; Správa serveru; a další operace přístupu k prostředkům. Všechny protokoly jsou zaznamenávány s datem, časem, identitou a dalšími podrobnými informacemi. Můžete také přistupovat ke všem chronologickým záznamům všech volání rozhraní API provedených v clusteru AKS. To zahrnuje informace o volajícím, čase, kdy bylo volání provedeno, zdroji, kde bylo volání zahájeno, a tak dále. Další informace najdete v tématu povolení a kontrola protokolů roviny ovládacího prvku Kubernetes ve službě Azure Kubernetes Service (AKS).

RBAC (řízení přístupu na základě role) se dá použít ke správě zásad přístupu k prostředkům jako standardních postupů v Azure.

Všechny protokoly by se měly ukládat do účtu úložiště ve vlastnictví zákazníka nebo Log Analytics. Tímto způsobem můžete rychle vygenerovat přehledy z velkého objemu dat. Všechny protokoly jsou v oblasti uchovávány alespoň ve třech kopiích. Můžete mít více kopií tím, že povolíte zálohování mezi oblastmi nebo replikaci. Všechny položky protokolu jsou dostupné jenom prostřednictvím zabezpečených kanálů HTTP (s).

Rozhraní pro upozorňování Azure umožňuje konfigurovat výstrahy pro detekci podezřelého přístupu. Můžete nastavit, jaké výstrahy je třeba aktivovat, a události. Uživatelé také mohou ručně kontrolovat úplný protokol pomocí Log Analytics s možností filtrování na základě typu aktivity, obsahu aktivity nebo volající aktivity.

Vaše odpovědnosti

Požadavek Zodpovědní
Požadavek 10,1 Implementujte záznamy auditu a propojte veškerý přístup k součástem systému každému jednotlivému uživateli.
Požadavek 10,2 Implementací automatizovaného auditu pro všechny součásti systému můžete znovu sestavit tyto události:
Požadavek 10,3 Zaznamenejte alespoň následující záznamy o auditu pro všechny součásti systému pro každou událost:
Požadavek 10,4 Pomocí technologie pro synchronizaci času Synchronizujte všechny kritické systémové hodiny a časy a zajistěte, aby se pro získání, distribuci a ukládání času implementovaly následující.
Požadavek 10,5 Zabezpečené záznamy auditu, aby se nemohly změnit.
Požadavek 10,6 Zkontrolujte protokoly a události zabezpečení pro všechny součásti systému a Identifikujte anomálie nebo podezřelé aktivity.
Požadavek 10,7 Uchovat historii záznamu auditu po dobu nejméně jednoho roku, která je k dispozici minimálně po dobu tří měsíců k analýze (například online, Archivovaná nebo obnovitelné ze zálohy).
Požadavek 10,8 Další požadavky pro poskytovatele služeb: Odpovězte na chyby všech kritických ovládacích prvků zabezpečení včas. Procesy pro reagování na chyby v ovládacích prvcích zabezpečení musí zahrnovat
Požadavek 10,9 Zajistěte, aby zásady zabezpečení a provozní postupy pro monitorování veškerého přístupu k síťovým prostředkům a datům držitele byly dokumentovány, používány a byly známy všem postiženým stranám.

Požadavek 11 — Pravidelné testování systémů a procesů zabezpečení

Podpora funkcí AKS

AKS je integrovaný do služby monitorování Azure:

  • Azure Security Center poskytuje mnoho funkcí kontroly zabezpečení. Například Security Center prohledává obrázky, které byly načteny a vloženy do registrů kontejnerů, a poskytuje doporučení. Podrobnosti najdete v tématu Správa ohrožení zabezpečení – kontrola imagí kontejneru. Ke kontrole systémových souborů můžete také použít monitorování integrity souborů (FIM) .

  • Azure Monitor lze použít k nastavení výstrah na základě typu události pro ochranu integrity a zabezpečení systému. V případě, že v uzlech AKS dojde k očekávaným chybám systému, AKS se prostředek včas zacele bez přerušení na zpracování systému.

AKS clustery jsou chráněné pomocí Azure Application Gateway s firewallem webových aplikací (WAF). To se dá nakonfigurovat v režimu detekce, aby se mohly protokolovat výstrahy a hrozby. Silnější režim je režim prevence, který aktivně blokuje zjištěné vniknutí a útoky. Podrobnosti najdete v tématu osvědčené postupy pro připojení k síti a zabezpečení ve službě Azure Kubernetes Service (AKS).

Vaše odpovědnosti

Požadavek Zodpovědní
Požadavek 11,1 Implementujte procesy pro otestování přítomnosti bezdrátových přístupových bodů (802,11) a vyhledáte a identifikujte všechny autorizované a neautorizované bezdrátové přístupové body čtvrtletním základem.
Požadavek 11,2 Spuštění interní a externí chyby zabezpečení sítě prochází nejméně čtvrtletně a po jakékoli významné změně v síti (třeba při instalacích systémových součástí, změnách v síťové topologii, změnách pravidel brány firewall, upgradech produktů).
Požadavek 11,3 Implementujte metodologii pro testování průniku, který obsahuje následující:
Požadavek 11,4 K detekci a nebo prevenci vniknutí do sítě použijte techniky pro zabránění vniknutí nebo prevence vniknutí.
Požadavek 11,5 Nasaďte mechanizmus pro detekci změn (například nástroje pro monitorování integrity souborů), který upozorní pracovníky na neoprávněnou změnu (včetně změn, přidávání a odstraňování) důležitých systémových souborů, konfiguračních souborů nebo souborů obsahu. a nakonfigurujte software tak, aby prováděl kritické porovnání souborů alespoň týdně.
Požadavek 11,6 Ujistěte se, že zásady zabezpečení a provozní postupy pro monitorování a testování zabezpečení jsou popsány, používány a jsou známy všem postiženým stranám.

Požadavek 10,1

Implementujte záznamy auditu a propojte veškerý přístup k součástem systému každému jednotlivému uživateli.

Vaše odpovědnosti

Pro sledování operací provedených na jednotlivých součástech doporučujeme použít tyto způsoby:

  • Protokol aktivit. Tento protokol poskytuje informace o typu a času operací prostředků Azure. Také zaznamená identitu, která spustila operaci. Ve výchozím nastavení je povolená a informace se shromažďují hned po dokončení operace prostředku. Tento záznam auditu je jen pro zápis a nedá se odstranit.

    Data se uchovávají po dobu 90 dnů. Pro delší možnosti uchovávání informací zvažte odeslání položek protokolu aktivit do Azure Storage.

    Snímek obrazovky zobrazující protokol aktivit Azure

  • Nastavení diagnostiky. Poskytuje diagnostické a auditování informací o prostředcích Azure a platformě, na kterou se nastavení vztahuje. doporučujeme tuto možnost povolit pro AKS a další komponenty v systému, jako je například Azure Blob Storage a Key Vault. Na základě typu prostředku můžete zvolit kategorie protokolů a data metrik a odeslat je do cíle. Vaše diagnostická jímka musí splňovat požadovaná období uchování.

    • Nastavení diagnostiky pro AKS. Z poskytnutých kategorií AKS povolte protokoly auditu Kubernetes. To zahrnuje kube-audit nebo kube-audit-admin , a guard .

      Povolte kube-audit-admin , pokud chcete zobrazit volání serveru rozhraní API pro data protokolu, která by mohla upravovat stav clusteru. Pokud potřebujete záznam auditu všech interakcí serveru API (včetně nezměněných událostí, jako jsou například žádosti o čtení), povolte kube-audit místo toho možnost povolit. Tyto události mohou být Prolific, vytvářet hluk a přidávat je do nákladů. Tyto protokoly obsahují informace o přístupu a názvu identity, který se používá k vytvoření žádosti.

      Povolte guard protokoly a sledujte spravované audity Azure AD a řízení přístupu na základě role (RBAC) Azure.

    Kromě protokolů založených na uživatelích zvažte protokoly z roviny ovládacího prvku Kubernetes, včetně kube-apiserver a kube-controller-manager . Obvykle se nevztahují na uživatele, ale mohou popomáhat sladit změny systému, které uživatelé udělali.

    Další informace najdete v tématu zobrazení protokolů komponenty roviny ovládacího prvku.

    Tato referenční implementace umožňuje cluster-autoscaler protokoly,, kube-controller-manager kube-audit-admin a guard . Všechny tyto informace jsou odesílány do Log Analytics pracovního prostoru pro účely analýzy. Doba uchování je nastavená na 90 dní.

    Snímek obrazovky, který zobrazuje diagnostické nastavení A kB S.

  • Diagnostika služby Azure Kubernetes. Pomocí této funkce můžete detekovat a řešit potíže s clusterem, jako například selhání uzlu. K dispozici jsou také diagnostická data specifická pro síť. Tato funkce je k dispozici bez dalších nákladů. Tato data nejsou obvykle přidružená k uživatelům, ale mohou popomáhat sladit změny systému, které uživatelé udělali. Informace o této funkci najdete v tématu Diagnostika služby Azure Kubernetes.

Předchozí mechanismy auditu pro audit by se měly implementovat v době nasazování prostředků. Azure Policy by měl být i aktivní, aby se tyto konfigurace v CDE nechtěně nebo byly neoprávněně zakázané.

Požadavek 10,2

Implementací automatizovaného auditu pro všechny součásti systému můžete znovu sestavit tyto události:

  • 10.2.1 přístup k datům držitele všech uživatelů
  • 10.2.2 všechny akce prováděné jednotlivými uživateli s oprávněním root nebo správce.
  • 10.2.3 přístup ke všem revizním stopám
  • 10.2.4 neplatných logických pokusů o přístup
  • 10,2 5 použití a změny ověřovacích a ověřovacích mechanismů – mimo jiné pro vytváření nových účtů a zvýšení oprávnění – a všechny změny, přidání nebo odstranění účtů s oprávněními root nebo správce
  • 10.2.6 inicializace, zastavení nebo pozastavení protokolů auditu
  • 10.2.7 vytváření a mazání objektů na úrovni systému

Vaše odpovědnosti

AKS poskytuje protokoly auditu na více úrovních, jak je popsáno v tématu požadavek 10,1. Tady jsou některé klíčové body:

  • Protokoly aktivit ve výchozím nastavení poskytují informace o důležitých operacích prostředků Azure. Všechny protokoly obsahují stav, čas a identitu, která spustila operaci.
  • Povolte nastavení diagnostiky pro přístup ke všem záznamům všech volání rozhraní API, která provedla v clusteru AKS. Protokoly poskytují podrobnosti o žadateli, časové razítko, zdroji požadavku a obsahu žádosti. Ukládat protokoly v pracovním prostoru Log Analytics s příslušnou dobou uchování. Povolte protokolování Log Analytics pracovního prostoru, abyste měli jistotu, že se protokoluje i přístup k tomuto záznamu auditu.
  • Zahrňte protokolování auditu pro jiné výpočetní prostředky, jako jsou například agenti sestavení a pole s odkazy. Zakáže přístup k systémům přímo jako kořen. Tím se zajistí, že se všechny akce provádějí v rámci konkrétní identity.
  • Protokolovat neúspěšné pokusy o přístup to zahrnuje žádosti o přístup k součástem, jako jsou Azure Storage, Azure Key Vault, server rozhraní AKS API a veškerý přístup RDP/SSH na další výpočetní prostředky.
  • Využijte výhod funkcí nabízených agenty zabezpečení třetích stran, které mohou přispět k analýze uživatelských vzorců v rámci clusteru AKS. To může být užitečné pro data auditu přístupu uživatele.

Požadavek 10,3

Zaznamenejte alespoň následující záznamy o auditu pro všechny součásti systému pro každou událost:

  • Identifikace uživatele 10.3.1
  • 10.3.2 typ události
  • 10.3.3 datum a čas
  • oznámení o úspěchu nebo selhání 10.3.4
  • 10.3.5 původ události
  • 10.3.6 identitu nebo název ovlivněných dat, systémové součásti nebo prostředku.

Vaše odpovědnosti

Jak je popsáno v požadavku 10,2, můžete získat protokoly auditu z clusteru povolením nastavení diagnostiky pro AKS. Protokoly obsahují podrobné informace o událostech získat, vypsat, vytvořit, aktualizovat, odstranit, opravit a vystavit. Protokoly obsahují informace v seznamu v části požadavky. Protokoly uložte v účtu úložiště, abyste se mohli dotazovat na informace.

Chcete například zobrazit předchozí sadu informací pro události Kube-audit-admin spuštěním tohoto dotazu:

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

Snímek obrazovky, který ukazuje příklad diagnostiky.

Sada výsledků zobrazuje informace jako součást pole log_s.

Požadované informace Schéma
Identifikace uživatele SourceIPs
Typ události operace
Datum a čas requestReceivedTimestamp
Indikace úspěchu nebo neúspěchu responseStatus
Původ události uživatel
Identita nebo název ovlivněných dat, systémové součásti nebo prostředku objectRef

Informace o hlavním protokolu najdete v tématu zobrazení protokolů komponenty roviny ovládacího prvku.

Požadavek 10,4

Pomocí technologie pro synchronizaci času Synchronizujte všechny kritické systémové hodiny a časy a zajistěte, aby se pro získání, distribuci a ukládání času implementovaly následující.

  • 10.4.1 důležité systémy mají správný a konzistentní čas.
  • 10.4.2 data o čase jsou chráněná.
  • nastavení času 10.4.3 jsou přijímána z časových zdrojů přijatých v oboru.

Poznámka: jedním z příkladů technologie synchronizace času je protokol NTP (Network Time Protocol).

Vaše odpovědnosti

AKS používá NTP z podkladových hostitelů Azure a nevyžaduje žádné odchylky odchozích síťových přenosů, které by tuto podporu podporovaly. Jiné virtuální počítače, které přidáte do CDE, můžou jako svůj zdroj synchronizace času používat externí servery NTP, jako je ntp.ubuntu.org (a její fond). Všechny další výpočetní prostředky, které přinesete do své CDE, by měly explicitně používat zdroj NTP podle vašeho výběru a měly by se zdokumentovat.

Požadavek 10,5

Omezte zobrazování revizí auditu na ty, které souvisejí s úlohou.

  • 10.5.1 omezit zobrazení revizí auditu na ty, které jsou potřeba pro úlohy.
  • 10.5.2 chránit soubory protokolu auditu před neoprávněnými změnami.
  • 10.5.3 rychle zálohujte soubory protokolu auditu do centralizovaného protokolovacího serveru nebo média, která se obtížně mění.
  • 10.5.4 protokoly zápisu pro externí technologie do zabezpečeného, centralizovaného, interního serverového serveru nebo mediálního zařízení.
  • 10.5.5 pomocí sledování integrity souborů nebo softwaru pro detekci změn v protokolech zajistěte, aby se stávající data protokolu nedala měnit bez generování výstrah (i když nově přidávaná data by neměla způsobovat výstrahu).

Vaše odpovědnosti

Díky více synchronizacím protokolování se zvyšuje režie na zabezpečení, kontrolu, analýzu a dotazování dat pro záznam pro audit. Naplánujte topologie záznamu auditu, abyste vyrovnali kompromisy mezi úplným izolací záznamu auditu a aspekty správy.

Pokud je to možné, Integrujte protokoly. Výhodou je možnost efektivně kontrolovat, analyzovat a dotazovat data. Azure nabízí několik technologických možností. Azure Monitor můžete použít pro kontejnery k zápisu protokolů do pracovního prostoru Log Analytics. Další možností je integrovat data do řešení správy akcí a informací o zabezpečení (SIEM), jako je Azure Sentinel. Mezi další oblíbené volby třetích stran patří Splunk, QRadar a ArcSight. Azure Security Center a Azure Monitor všechna tato řešení podporují. Tato řešení jsou jen připojené datové jímky, které mají zajistit, že záznam nebude možné změnit.

Security Center můžete exportovat výsledky v nakonfigurovaných intervalech. Další informace najdete v tématu Průběžný export.

Všechny protokoly se uchovávají nejméně se třemi kopiemi v jedné oblasti. Jako strategii zálohování můžete mít více kopií povolením zálohování nebo replikace mezi oblastmi. Všechny položky protokolu jsou k dispozici pouze prostřednictvím zabezpečených kanálů HTTP/S.

Log Analytics a Azure Sentinel podporují různé řízení přístupu na základě role pro správu přístupu k záznamu auditu. Ujistěte se, že jsou role namapované na role a zodpovědnosti organizace.

Ujistěte se, že váš pracovní prostor služby Log Analytics podporuje požadavky na provoz i dodržování předpisů. Představte si vyhrazený pracovní prostor pro clustery v oboru, které předá řešení SIEM.

Většina protokolování v AKS pochází z stdout/stderr a bude ho shromažďovat Azure Monitor Container Insights. Pokud máte další ručně vytvořené protokoly, zvažte vysílání dat způsobem, který se odesílá do důvěryhodného datového proudu pro předávání a podrobuje se manipulaci.

Požadavek 10.6

Zkontrolujte protokoly a události zabezpečení pro všechny systémové komponenty a identifikujte anomálie nebo podezřelé aktivity.

  • 10.6.1 Kontrola následujících alespoň jednou denně:
    • Všechny události zabezpečení
    • Protokoly všech systémových komponent, které ukládají, zpracovávají nebo přenášejí CHD nebo SAD
    • Protokoly všech důležitých systémových komponent
    • Protokoly všech serverů a systémových komponent, které provádějí funkce zabezpečení (například brány firewall, systémy zjišťování neoprávněných vniknutí/ systémy ochrany před neoprávněnou vniknutí (IDS/IPS), ověřovací servery, servery pro přesměrování elektronického obchodování atd.).
  • 10.6.2 Pravidelné kontrolování protokolů všech ostatních součástí systému na základě zásad organizace a strategie řízení rizik podle ročního hodnocení rizik organizace.
  • 10.6.3 Následné výjimky a anomálie zjištěné během procesu revize

Vaše odpovědnosti

Monitorovací služby Azure, Azure Monitor a Azure Security Center, mohou generovat oznámení nebo upozornění, když detekují neobvyklé aktivity. Tyto výstrahy obsahují kontextové informace, jako je závažnost, stav a čas aktivity.

Při generování výstrah je k dispozici strategie nápravy a kontrola průběhu. Jedním ze možností je sledovat skóre zabezpečení v Azure Security Center a porovnat ho s historickými výsledky.

Centralizujte data v jednom zobrazení pomocí řešení SIEM, jako je Azure Sentinel. Integrace dat může poskytovat bohatý kontext výstrah.

Případně můžete ručně zkontrolovat celý protokol ve vašem úložišti. Například v Log Analytics můžete použít funkci filtrování na základě typu aktivity, obsahu aktivity nebo volajícího aktivity.

Mít zásady organizace k pravidelnému přehledu výstrah a událostí a plánování iniciativ s konkrétními cíli vylepšení. Pomocí vlastních uložených dotazů v Log Analytics můžete dokumentovat zamýšlené dotazy na protokol a usnadnit dotazování. Tím se zajistí, že tým ví, co je důležité zkontrolovat, protože se týká 10.6, a že všechna ruční úsilí zapojená do tohoto procesu se budou řídit konzistentním pracovním postupem.

Požadavek 10.7

Uchovávat historii záznamů auditu po dobu nejméně jednoho roku s okamžitě dostupnou analýzou minimálně tři měsíce (například online, archivovaná nebo restorovatelná ze zálohy).

Vaše odpovědnosti

Protokoly nejsou k dispozici po neomezenou dobu. Ujistěte se, že jsou zachované protokoly aktivit Azure a nastavení diagnostiky a že je možné se na to dotazovat. Pokud pro své prostředky povolíte nastavení diagnostiky, zadejte dobu uchovávání po dobu tří měsíců. Účty úložiště Azure používejte k dlouhodobé archivaci, aby je bylo možné použít k auditování nebo offline analýze. Implementujte své dlouhodobé řešení archivace tak, aby bylo v souladu s principem zápisu jednou a vícečetně.

Požadavek 10.8

  • 10.8.1 Další požadavek jenom na poskytovatele služeb: Včas reagovat na selhání všech důležitých bezpečnostních prvků. Procesy reakce na selhání v bezpečnostních prvcích musí zahrnovat:

  • Obnovení funkcí zabezpečení

  • Identifikace a zdokumentování doby trvání (od začátku do konce data a času) selhání zabezpečení

  • Identifikace a dokumentace příčin selhání, včetně hlavní příčiny, a dokumentace nápravy nutné k řešení hlavní příčiny

  • Identifikace a řešení všech problémů se zabezpečením, které vznikly během selhání

  • Proveďte posouzení rizik, abyste zjistili, jestli jsou v důsledku selhání zabezpečení potřeba další akce.

  • Implementace ovládacích prvků, které zabraňují opětovnému vzniku příčiny selhání – Obnovení monitorování bezpečnostních prvků

Vaše odpovědnosti

Pokud je to praktické, můžete mít výstrahy, které indikují existenci důležitých bezpečnostních prvků. Jinak se ujistěte, že proces auditu dokáže včas zjistit nedostatečnou očekávanou kontrolu zabezpečení. Zvažte řízení, jako jsou agenti zabezpečení běžící v clusteru AKS a řízení přístupu (IAM a síť) v zdrojích Azure. Sem patří nastavení, jako je kontrola, jestli je cluster AKS privátním clusterem, kontrola bodů vystavení sítě prostřednictvím pravidel skupiny zabezpečení sítě (NSG) nebo kontrola neočekávaných veřejných IP bodů. Zahrnují také neočekávané změny ve službě DNS, směrování sítě, bráně firewall a službě Azure AD.

Požadavek 10.9

Zajistěte, aby zásady zabezpečení a provozní postupy pro monitorování veškerého přístupu k síťovým prostředkům a datům o držitelích karet byly zdokumentovány, používat a známé všem ovlivněným stranám.

Vaše odpovědnosti

Je velmi důležité udržovat důkladnou dokumentaci týkající se procesů a zásad. Udržujte dokumentaci o vynucených zásadách. V rámci monitorování musí být lidé vytrénování v povolování a prohlížení protokolů auditu a identifikaci a nápravě běžných rizik. To je zvláště důležité pro lidi, kteří jsou součástí procesu schvalování z hlediska zásad.

Požadavek 11.1

Implementujte procesy pro testování přítomnosti bezdrátových přístupových bodů (802.11) a detekovat a identifikovat všechny autorizované a neoprávněné bezdrátové přístupové body čtvrtletně.

Externí sítě jsou mimo rozsah této dokumentace a musí se vyhodnocovat samostatně.

Vaše odpovědnosti

Tato architektura a implementace nejsou určené k provádění místních nebo podnikových transakcí mezi sítěmi a cloudy prostřednictvím bezdrátových připojení. Důležité informace najdete v pokynech v oficiálním standardu PCI-DSS 3.2.1.

Požadavek 11.2

Spusťte interní a externí kontroly ohrožení zabezpečení sítě alespoň čtvrtletně a po jakékoli významné změně v síti (například instalace nových systémových součástí, změny síťové topologie, úpravy pravidel brány firewall nebo upgrady produktů).

Další informace najdete v tématu Dodavatelé skenování schválených standardem zabezpečení dat v odvětví platebních karet (PCI).

Vaše odpovědnosti

Pracujte s procesem, který kontroluje změny v clusteru AKS, konfiguraci sítě, registrech kontejnerů a dalších komponentách architektury.

Pokud dojde ke změnám v síti, měl by se proces vyhodnotit, jestli je kontrola nezbytná. Je teď například cluster vystavený veřejnému internetu? Jsou nová pravidla brány firewall příliš pohotová? Jsou v clusteru nějaké mezery v zabezpečení toku mezi pody?

Mít jasnou a odsouhlasenou definici významných změn s ohledem na vaši infrastrukturu. Mezi příklady patří konfigurace pravidel NSG, pravidel Azure Firewall sítě, partnerských vztahů virtuálních sítí, nastavení DNS, Azure Private Link konfigurací sítě a dalších síťových komponent.

PLATÍ PRO 11.2.1

Čtvrtletní kontrolu ohrožení zabezpečení musí spustit kvalifikovaní pracovníci s hlubším porozuměním síťovým konceptům Azure a síťovým konceptům Kubernetes. Namapovat výsledky na požadavek 6.1 s úrovněmi závažnosti a vyřešit položky s vysokou prioritou Pokud dojde k významným změnám, spusťte kontroly před naplánovanou čtvrtletní kontrolou. To vám pomůže detekovat nová ohrožení zabezpečení, abyste mohli aktivně opravovat problémy.

Tato kontrola musí také zahrnovat sítě v clusteru (pod-pod).

PLATÍ PRO 11.2.2 Vyberte schváleného dodavatele skenování (ASV), který má rozsáhlé zkušenosti se sítěmi Azure a Kubernetes. Tím se zajistí hloubka a specifika navrhované nápravy.

Požadavek 11.3

Implementujte metodologii pro testování průniku, která zahrnuje následující:

  • Vychází z přístupů penetračního testování v oboru (například NIST SP800-115).
  • Zahrnuje pokrytí celé hraniční sítě CDE a důležitých systémů.
  • Zahrnuje testování zevnitř i mimo síť.
  • Zahrnuje testování pro ověření všech prvků segmentace a omezení rozsahu.
  • Definuje penetrační testy v aplikační vrstvě, které mají zahrnovat minimálně ohrožení zabezpečení uvedená v požadavku 6.5.
  • Definuje penetrační testy na síťové vrstvě tak, aby zahrnovaly komponenty, které podporují síťové funkce i operační systémy.
  • Zahrnuje posouzení a posouzení hrozeb a ohrožení zabezpečení za posledních 12 měsíců.
  • Určuje uchovávání výsledků penetračních testů a výsledky aktivit nápravy.

Vaše odpovědnosti

Proveďte testování průniku, abyste zjistili nedostatky zabezpečení shromažďováním informací, analýzou ohrožení zabezpečení a generováním sestav. Při řešení běžných scénářů a aktivit požadovaných k vytvoření směrného plánu doporučujeme postupovat podle oborových pokynů uvedených ve standardu PTES (Penetration Testing Execution Standard).

Specialista na penetrační testy by měl mít hloubkové znalosti o místních sítích a sítích Azure, aby se zajistilo, že se roční testy segmentace budou ve velké části pokrýt. Rozšiřte metodologii testování do sítí v clusteru. To vyžaduje silné zkušenosti s koncepty sítí Kubernetes.

Testy musí pokrýt aplikační a datové vrstvy běžící v CDE.

Ve cvičení testování průniku můžou praktičtí odborníci potřebovat přístup k citlivým datům pro celou organizaci. Postupujte podle pravidel zapojení a ujistěte se, že přístup a záměr nejsou zneužívány. Pokyny k plánování a provádění simulovaných útoků najdete v tématu Pravidla zapojení testování průniku.

Požadavek 11.4

K detekci nebo zabránění vniknutí do sítě použijte techniky detekce neoprávněných vniknutí nebo jejich prevence. Monitorujte veškerý provoz v hraničním prostředí dat držitelů karet i v kritických bodech datového prostředí držitelů karet a upozorní pracovníky na podezřelé ohrožení zabezpečení.

Vaše odpovědnosti

Chraňte cluster AKS tím, že prověříte příchozí provoz. Jedním z nich je použití Firewallu webových aplikací (WAF). V této architektuře Azure Application Gateway integrovaným WAF brání vniknutí. Režim prevence použijte k aktivnímu blokování zjištěných neoprávněných vniknutí a útoků. Nepoužívejte jenom režim detekce. Další informace najdete v tématu Osvědčené postupy pro síťové připojení a zabezpečení v Azure Kubernetes Service (AKS).

Alternativní možností je použít funkce zjišťování neoprávněných vniknutí a/nebo ochrany před neoprávněnou vniknutí Azure Firewall Premium. Další informace najdete v tématu IDPS.

Další možností je povolit Azure Monitor Network Přehledy.

Povolte Azure Defender plány tak, jak se vztahují na různé komponenty CDE. Pokud se například k ukládání SQL CHD používá Azure Azure Defender pro SQL, ujistěte se, že byla zjištěna neoprávněná vniknutí do datové vrstvy.

Můžete také detekovat anomálie ve vzorcích provozu propojením protokolů toku NSG do centralizovaného řešení SIEM, jako je Azure Sentinel. V této referenční implementaci jsou protokoly v režimu jen pro připojení, což minimalizuje sledování změn v protokolech auditu. Všechny protokoly, které se odesílaly do externích jímek pro dlouhodobé úložiště, ale nesmí být změněny. Musí postupovat podle přístupu write-once/read-many. Ujistěte se, že řešení monitorování integrity souborů (FIM) zahrnuje tyto externí entity a zjišťuje změny.

Požadavek 11.5

Nasaďte mechanismus detekce změn (například nástroje pro monitorování integrity souborů), který upozorní pracovníky na neoprávněné úpravy (včetně změn, přidání a odstranění) důležitých systémových souborů, konfiguračních souborů nebo souborů obsahu. a nakonfigurujte software tak, aby nejméně jednou týdně porovnání kritických souborů.

Vaše odpovědnosti

Ve vašem clusteru spusťte řešení monitorování integrity souborů (FIM) ve spojení s agentem zabezpečení s podporou Kubernetes, abyste detekovali přístup na úrovni souborů a systému, který by mohl vést ke změnám na úrovni uzlu. Při výběru řešení FIM jasně porozumit jeho funkcím a hloubkě detekce. Vezměte v úvahu software vyvinutý renomými dodavateli.

Důležité

Referenční implementace poskytuje zástupné DaemonSet nasazení pro spuštění antimalwarových agentů řešení FIM. Agent se spustí na každém virtuálním počítači uzlu v clusteru. Do tohoto nasazení umístěte svůj výběr antimalwarového softwaru.

Zkontrolujte všechna výchozí nastavení nástroje FIM a ujistěte se, že hodnoty detekují parametry, které chcete pokrýt, a odpovídajícím způsobem tato nastavení upravte.

Povolte řešení odesílání protokolů do řešení monitorování nebo ŘEŠENÍ SIEM, aby bylo možné generovat výstrahy. Dejte pozor na změny schématu protokolu nebo můžete nechat ujít kritická upozornění.

Všechny ostatní další výpočetní prostředky v CDE by měly mít povolené sledování změn.

Požadavek 11.6

Zajistěte, aby zásady zabezpečení a provozní postupy pro monitorování a testování zabezpečení byly zdokumentovány, používat a známé všem ovlivněným stranám.

Vaše odpovědnosti

Je velmi důležité udržovat důkladnou dokumentaci týkající se procesů a zásad. Udržujte dokumentaci o vynucených zásadách. Součástí testování je i frekvence hodnocení a kritéria revize. Ujistěte se, že tým rozumí aspektům penetračního testování. Zdokumentujte plán nápravy, který zmírní zjištěná rizika.

To je zvláště důležité pro lidi, kteří jsou součástí procesu schvalování z hlediska zásad.

Další

Udržujte zásady, které řeší zabezpečení informací pro všechny pracovníky.