Konfigurace sítě regulovaného clusteru AKS pro PCI-DSS 3.2.1 (část 3 z 9)

Tento článek popisuje aspekty sítí pro cluster Azure Kubernetes Service (AKS), který je nakonfigurovaný v souladu se standardem PCI-DSS 3.2.1 ( Payment Card Industry Data Security Standard).

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

Hlavním tématem standardu PCI-DSS 3.2.1 je zabezpečení. Hvězdicová topologie je přirozenou volbou pro nastavení regulovaného prostředí. Je jednodušší vytvořit infrastrukturu, která umožňuje zabezpečenou komunikaci. Síťové ovládací prvky jsou umístěny v hvězdicových sítích a řídí se modelem nulové důvěryhodnosti Microsoftu. Ovládací prvky je možné ladit s nejnižšími oprávněními pro zabezpečení provozu a poskytnout tak přístup na základě potřeby. Kromě toho můžete použít několik přístupů hloubkové ochrany přidáním ovládacích prvků v každém segmentu směrování sítě.

Pokud hostujete úlohu v Kubernetes, nestačí spoléhat se na tradiční síťové konstrukce, jako jsou pravidla brány firewall. Existují také nativní konstrukty Kubernetes, které řídí tok provozu v clusteru, například NetworkPolicy prostředek. Důrazně doporučujeme odkazovat na dokumentaci Kubernetes, abyste porozuměli základním konceptům izolovaných podů a zásadám příchozího a výchozího přenosu dat.

Vytváření a údržba zabezpečené sítě a systémů

Požadavek 1 – Instalace a údržba konfigurace brány firewall pro ochranu dat držitelů karet

Podpora funkcí AKS

AKS podporuje nasazení clusteru v privátní virtuální síti jako privátního clusteru. Komunikace mezi clusterem a serverem rozhraní API Kubernetes spravovaným službou AKS je přes důvěryhodnou síť. Pomocí privátního clusteru můžete pomocí služby Azure Virtual Network, skupiny zabezpečení sítě (NSG) a dalších integrovaných síťových ovládacích prvků zabezpečit celé datové prostředí (CDE). Tím se zakáže jakýkoli neoprávněný veřejný přístup mezi internetem a prostředím. Podrobnosti o tom, jak takový cluster zřídit, najdete v tématu Vytvoření privátního clusteru Azure Kubernetes Service.

Azure Firewall je možné integrovat s AKS a omezit odchozí provoz z clusteru, což je klíčovou komponentou CDE. Konfigurace je snadná pomocí značky plně kvalifikovaného názvu domény AKS. Doporučený postup najdete v části Použití služby Azure Firewall k ochraně nasazení služby Azure Kubernetes Service (AKS).

Clustery AKS vyžadují určitý veřejný přístup k internetu. Omezte odchozí provoz na internet pomocí služby Azure Firewall a skupin zabezpečení sítě v podsíti clusteru. Informace najdete v tématu Řízení výchozího přenosu dat pro uzly clusteru ve službě Azure Kubernetes Service (AKS).

AKS volitelně podporuje možnost definovat proxy server HTTP, který lze využít pro další řízení odchozího provozu a monitorování clusteru. Uzly clusteru používají pro směrování odchozího provozu zadanou konfiguraci proxy serveru HTTP. MutatingWebhook je také zaregistrovaný k vložení informací o proxy serveru do podů při vytváření, takže se doporučuje, aby úlohy mohly dědit stejné informace o proxy serveru. Pody můžou přepsat informace o proxy serveru, proto se doporučuje používat kromě služby Azure Firewall i proxy server HTTP.

Clustery AKS by se měly vytvořit pomocí modulu plug-in NetworkPolicy. V AKS máte jako modul plug-in Network Policy možnost mezi Azure nebo Calico. Se zásadami sítě Calico můžete použít Kubenet nebo Azure CNI. Pro Službu Azure Network Policy můžete použít pouze Azure CNI (nikoli Kubenet). Zásady sítě pro uzly Windows se podporují jenom u Calico. Moduly plug-in Azure i Calico Network Policy jsou opensourcové. Další informace o Project Calico najdete v komplexním dokumentu white paper o řešení PCI, který řeší řadu níže uvedených požadavků na bránu firewall.

Vaše odpovědnosti

Požadavek	Odpovědnost
Požadavek 1.1	Vytvořte a implementujte standardy konfigurace brány firewall a směrovače.
Požadavek 1.2	Sestavte konfiguraci brány firewall a směrovače, která omezují připojení mezi nedůvěryhodnými sítěmi a všemi systémovými komponentami v datovém prostředí držitelů karet.
Požadavek 1.3	Zakázat přímý veřejný přístup mezi internetem a libovolnou systémovou komponentou v datovém prostředí karet.
Požadavek 1.4	Nainstalujte software osobní brány firewall nebo ekvivalentní funkce na všechna přenosná výpočetní zařízení (včetně společnosti nebo zaměstnance), která se připojují k internetu mimo síť (například přenosné počítače používané zaměstnanci) a které se používají také pro přístup k CDE.
Požadavek 1.5	Ujistěte se, že zásady zabezpečení a provozní postupy pro správu bran firewall jsou zdokumentované, používané a známé všem ovlivněným stranám.

Požadavek 1.1

Vytvořte a implementujte standardy konfigurace brány firewall a směrovače, které zahrnují následující:

Požadavek 1.1.1

Formální proces schvalování a testování všech síťových připojení a změn konfigurace brány firewall a směrovače.

Vaše odpovědnosti

Neimplementujte konfigurace ručně, například přímo pomocí webu Azure Portal nebo Azure CLI. Doporučujeme používat infrastrukturu jako kód (IaC). U IaC se infrastruktura spravuje prostřednictvím popisného modelu, který používá systém správy verzí. Model IaC generuje stejné prostředí při každém použití. Mezi běžné příklady IaC patří Azure Resource Manager nebo Terraform. Pokud IaC není možnost, máte dobře zdokumentovaný proces pro sledování, implementaci a bezpečné nasazení změn pravidel brány firewall. Další podrobnosti jsou uvedeny jako součást požadavku 11.2.

Budete muset použít kombinaci různých síťových ovládacích prvků, včetně služby Azure Firewall, skupin zabezpečení sítě (NSG) a prostředku Kubernetes NetworkPolicy .

Minimalizujte počet lidí, kteří můžou přistupovat k síťovým ovládacím prvkům a upravovat je. Definujte role a jasné zodpovědnosti týmům. Například síťový tým organizace ověří změny podle zásad správného řízení, které nastavily IT týmy. Mít uváděný schvalovací proces, který zahrnuje lidi a procesy ke schválení změn jakékoli konfigurace sítě. Tento proces by měl obsahovat krok pro testování všech síťových ovládacích prvků. Potřebujete podrobnou dokumentaci, která popisuje proces.

Požadavek 1.1.2

Aktuální síťový diagram, který identifikuje všechna připojení mezi datovým prostředím držitelů karet a dalšími sítěmi, včetně všech bezdrátových sítí

Vaše odpovědnosti

V rámci dokumentace udržujte diagram toku sítě, který zobrazuje příchozí a odchozí provoz pomocí bezpečnostních prvků. To zahrnuje tok provozu z jiných sítí, včetně jakékoli bezdrátové sítě do CDE. Diagram by měl také zobrazovat toky v rámci clusteru. Diagramy musí obsahovat určité specifické požadavky, které by měly zobrazovat senzory vniknutí. Ovládací prvky pro

Tento obrázek znázorňuje síťový diagram referenční implementace.

Stáhněte si soubor Visia tohoto diagramu.

Obrázek 1.1.2 – Tok sítě

Popis tohoto toku je v následujících částech.

Pokud máte Azure Network Watcher, můžete si prohlédnout topologii virtuální sítě Azure. Můžete zobrazit všechny prostředky ve virtuální síti, prostředky přidružené k prostředkům ve virtuální síti a vztahy mezi prostředky.

Požadavek 1.1.3

Aktuální diagram znázorňující všechny toky dat držitelů karet napříč systémy a sítěmi

Vaše odpovědnosti

Součástí dokumentace je diagram toku dat, který ukazuje, jak jsou neaktivní uložená a přenášená data chráněná.

Diagram by měl ukázat, jak data proudí do a z úlohy a jaké informace se předávají z jednoho prostředku do druhého. Ujistěte se, že je diagram aktuální. Přidejte krok jako součást procesu správy změn a aktualizujte diagram toku dat.

Vzhledem k tomu, že se tato architektura zaměřuje na infrastrukturu a ne na úlohu, vynechali jsme zde ilustrace.

Požadavek 1.1.4

Požadavky na bránu firewall při každém připojení k internetu a mezi libovolnou zónou demilitarizované sítě (DMZ) a interní zónou sítě.

Vaše odpovědnosti

Mají jasnou definici toho, co definuje hranice DMZ. Například datové prostředí držitelů karet (CDE) je v dmZ zabezpečené bránou firewall, zásadami sítě a dalšími ovládacími prvky. Další informace naleznete v tématu Cloud DMZ.

V případě infrastruktury PCI DSS zodpovídáte za zabezpečení CDE pomocí síťových ovládacích prvků, které blokují neoprávněný přístup k síti pomocí CDE a z této sítě. Síťové ovládací prvky musí být správně nakonfigurované pro stav silného zabezpečení a musí se použít na:

• Komunikace mezi spolulokovanými komponentami v clusteru
• Komunikace mezi úlohou a dalšími komponentami v důvěryhodných sítích
• Komunikace mezi úlohou a veřejným internetem

Tato architektura používá různé technologie brány firewall ke kontrole toku provozu v obou směrech do a z clusteru, který je hostitelem CDE:

• Aplikace Azure Brána firewall webových aplikací (WAF) se používá jako směrovač provozu a k zabezpečení příchozího (příchozího) provozu do clusteru.

• Azure Firewall slouží k zabezpečení veškerého odchozího (výchozího) provozu z jakékoli sítě a jejích podsítí.

  V rámci zpracování transakcí nebo operací správy bude cluster muset komunikovat s externími entitami. Cluster může například vyžadovat komunikaci s řídicí rovinou AKS, získáním aktualizací Windows a balíčků a interakcí úloh s externími rozhraními API. Některé z těchto interakcí můžou být přes protokol HTTP a měly by se považovat za vektory útoku. Tyto vektory jsou cíle útoku man-in-the-middle, který může vést k exfiltraci dat. Přidání brány firewall pro výchozí přenosy zmírní toto ohrožení.

  Doporučujeme, aby i komunikace mezi pody byla šifrovaná protokolem TLS. Tento postup je znázorněn v referenční implementaci s použitím sítě mTLS.

• Skupiny zabezpečení sítě se přidávají k zabezpečení provozu mezi clusterem a dalšími komponentami v rámci infrastruktury. Například v referenční implementaci existují skupiny zabezpečení sítě v podsíti s fondy uzlů, které blokují všechny pokusy o přístup SSH. Je povolený pouze provoz z virtuální sítě.

  Při přidávání komponent do architektury zvažte přidání dalších skupin zabezpečení sítě, které povolují nebo zakazují typy provozu na hranicích podsítě. Vzhledem k tomu, že každý fond uzlů je ve vyhrazené podsíti, použijte konkrétnější pravidla na základě očekávaných vzorů provozu vaší úlohy.

• Kubernetes NetworkPolicy

  Ve výchozím nastavení neexistují žádná omezení komunikace mezi pody. Je potřeba použít NetworkPolicy komunikaci v clusteru, počínaje sítí s nulovou důvěryhodností a otevřením cest podle potřeby. Referenční implementace demonstruje sítě nulové důvěryhodnosti v oborech a0005-i názvů a a0005-o obory názvů. Všechny obory názvů (s výjimkou kube-systemgatekeeper-system, a dalších oborů názvů poskytované službou AKS) mají omezující NetworkPolicy použití. Definice zásady závisí na podech spuštěných v těchto oborech názvů. Ujistěte se, že otevíráte cesty pro připravenost, aktuálnost a spouštěcí testy. Otevřete také cestu k oms-agent tomu, aby se mohly odesílat metriky na úrovni uzlu. Zvažte standardizaciportůch NetworkPolicy

Požadavek 1.1.5

Popis skupin, rolí a odpovědností za správu síťových komponent

Vaše odpovědnosti

Budete muset poskytnout ovládací prvky pro toky sítě a související komponenty. Výsledná infrastruktura bude mít několik segmentů sítě, každý s mnoha ovládacími prvky a každý ovládací prvek s účelem. Ujistěte se, že vaše dokumentace má nejen šířku pokrytí od plánování sítě až po všechny konfigurace, ale také podrobnosti o vlastnictví. Mít jasné odpovědnosti a role, které jsou za ně zodpovědné.

Například víte, kdo zodpovídá za zásady správného řízení zabezpečení sítě mezi Azure a internetem. V podniku zodpovídá IT tým za konfiguraci a údržbu pravidel služby Azure Firewall, firewallu webových aplikací (WAF), skupin zabezpečení sítě a dalších přenosů mezi sítěmi. Můžou také odpovídat za přidělování virtuálních sítí a podsítí pro celou organizaci a plánování IP adres.

Na úrovni úloh zodpovídá operátor clusteru za udržování nulové důvěryhodnosti prostřednictvím zásad sítě. Odpovědnost může také zahrnovat komunikaci s řídicí rovinou Azure, rozhraními API Kubernetes a technologiemi monitorování.

Vždy začněte strategií odepřít vše. Udělit oprávnění pouze v případě, že existuje obchodní potřeba nebo odůvodnění role.

Požadavek 1.1.6

Dokumentace obchodního odůvodnění a schválení pro použití všech povolených služeb, protokolů a portů, včetně dokumentace funkcí zabezpečení implementovaných pro tyto protokoly, které jsou považovány za nezabezpečené.

Vaše odpovědnosti

Podrobné informace o službách, protokolech a portech používaných v síťových ovládacích prvcích Odepřít všechny kromě explicitně povolených portů. Zdokumentujte obchodní odůvodnění a zdokumentované funkce zabezpečení, pokud se použití nezabezpečených protokolů nedá vyhnout. Tady je několik příkladů z referenční implementace služby Azure Firewall. Pravidla brány firewall musí být vymezena výhradně na související prostředky. To znamená, že do konkrétních cílů plně kvalifikovaného názvu domény může přejít pouze provoz z konkrétních zdrojů. Tady je několik případů povolení provozu.

Pravidlo	Protokol:port	Zdroj	Cíl	Zarovnání do bloku
Umožňuje zabezpečenou komunikaci mezi uzly a řídicí rovinou.	HTTPS:443	Autorizované rozsahy IP adres přiřazené fondům uzlů clusteru	Seznam cílů plně kvalifikovaného názvu domény v řídicí rovině AKS Toto je určeno značkou plně kvalifikovaného AzureKubernetesService názvu domény.	Uzly potřebují přístup k řídicí rovině pro nástroje pro správu, informace o stavu a konfiguraci a informace o tom, které uzly je možné škálovat.
Povolte zabezpečenou komunikaci mezi Fluxem a GitHubem.	HTTPS:443	Fondy uzlů AKS	github.com,api.github.com	Flux je integrace třetí strany, která běží na uzlech. Synchronizuje konfiguraci clusteru s privátním úložištěm GitHubu.

Požadavek 1.1.7

Požadavek na kontrolu pravidel brány firewall a směrovače alespoň každých šest měsíců.

Vaše odpovědnosti

Požádejte procesy alespoň každých šest měsíců, abyste zkontrolovali konfigurace sítě a pravidla s vymezeným oborem. Tím zajistíte, že bezpečnostní záruky jsou aktuální a platné. Zkontrolujte tyto konfigurace:

• Pravidla služby Azure Firewall
• Pravidla NSG.
• Aplikace Azure Pravidla brány a WAF.
• Nativní zásady sítě Kubernetes
• Ovládací prvky brány firewall pro příslušné prostředky Azure Tato architektura například používá pravidlo ve službě Azure Container Registry, které povoluje pouze provoz z privátního koncového bodu.
• Všechny ostatní síťové ovládací prvky, které jste přidali do architektury.

Požadavek 1.2

Sestavte konfiguraci brány firewall a směrovače, která omezují připojení mezi nedůvěryhodnými sítěmi a všemi systémovými komponentami v datovém prostředí držitelů karet.

Vaše odpovědnosti

V této architektuře je cluster AKS klíčovou součástí datového prostředí držitelů karet (CDE). Důrazně doporučujeme, aby byl cluster nasazený jako privátní cluster pro lepší zabezpečení. V privátním clusteru je síťový provoz mezi serverem rozhraní Kubernetes API spravovaným AKS a fondy uzlů privátní. Server rozhraní API je vystaven prostřednictvím privátního koncového bodu v síti clusteru.

Můžete také zvolit veřejný cluster, ale tento návrh se nedoporučuje pro clustery obsahující regulované úlohy. Server rozhraní API bude vystavený na internetu. Záznam DNS bude vždy zjistitelný. Proto musíte mít ovládací prvky, abyste rozhraní API clusteru chránilo před veřejným přístupem. Pokud se vyžaduje použití veřejného clusteru, doporučeným přístupem je mít úzké kontroly prostřednictvím řízení přístupu na základě role Kubernetes (RBAC) spárované s funkcí Rozsahy autorizovaných IP adres AKS a omezit tak přístup k serveru rozhraní API AKS. Toto řešení se ale nedoporučuje pro clustery obsahující regulované úlohy.

Při zpracování dat držitelů karet (CHD) musí cluster komunikovat se sítěmi, které jsou považovány za důvěryhodné a nedůvěryhodné. V této architektuře se obě hvězdicové sítě v hraniční síti PCI-DSS 3.2.1 považují za důvěryhodné sítě.

Nedůvěryhodné sítě jsou sítě mimo hraniční síť. Tato kategorie zahrnuje další rozbočovače a paprsky, které můžou být ve stejné infrastruktuře, ale jsou mimo hraniční síť úloh, veřejný internet, podnikovou síť nebo virtuální sítě v Azure nebo jiné cloudové platformě. V této architektuře není virtuální síť hostovaná tvůrcem imagí nedůvěryhodná, protože při zpracování CHD nemá žádnou roli. Interakce CDE s těmito sítěmi by měla být zabezpečená podle požadavků. S tímto privátním clusterem můžete k zabezpečení celého prostředí použít službu Azure Virtual Network, skupinu zabezpečení sítě a další integrované funkce.

Informace o privátních clusterech najdete v tématu Vytvoření privátního clusteru Azure Kubernetes Service.

Požadavek 1.2.1

Omezte příchozí a odchozí provoz na to, co je nezbytné pro datové prostředí držitelů karet, a konkrétně odepřít veškerý ostatní provoz.

Vaše odpovědnosti

Služba Azure Virtual Network nemůže být záměrně přístupná přímo veřejným internetem. Veškerý příchozí (nebo příchozí) provoz musí projít přes zprostředkující směrovač provozu. Všechny komponenty v síti ale můžou přistupovat k veřejným koncovým bodům. Odchozí (nebo výchozí) provoz musí být explicitně zabezpečený, což umožňuje pouze zabezpečené šifry a protokol TLS 1.2 nebo novější.

• Aplikace Azure Brána integrovanou bránou WAF zachytí veškerý příchozí provoz HTTP(S) a trasy kontrolované přenosy do clusteru.

  Tento provoz může pocházet z důvěryhodných nebo nedůvěryhodných sítí. Služba Application Gateway je zřízená v podsíti paprskové sítě a zabezpečená skupinou zabezpečení sítě. Při příchozích přenosech pravidla WAF povolují nebo zamítnou a směrují provoz do nakonfigurovaného back-endu. Služba Application Gateway například chrání CDE tím, že zakáže tento typ provozu:

  • Veškerý provoz, který není šifrovaný protokolem TLS.
  • Provoz mimo rozsah portů pro komunikaci řídicí roviny z infrastruktury Azure.
  • Sondy stavu odesílají jiné entity než interní nástroj pro vyrovnávání zatížení v clusteru.

• Azure Firewall slouží k zabezpečení veškerého odchozího (výchozího) provozu z důvěryhodných a nedůvěryhodných sítí.

  Azure Firewall je zřízený v podsíti centrální sítě. K vynucování služby Azure Firewall jako jednoho výstupního bodu se trasy definované uživatelem používají v podsítích, které dokážou generovat odchozí provoz. To zahrnuje podsítě v nedůvěryhodných sítích, jako je virtuální síť tvůrce imagí. Jakmile provoz dosáhne služby Azure Firewall, použijí se několik pravidel s vymezeným oborem, která umožňují provoz z konkrétních zdrojů přejít na konkrétní cíle.

  Další informace najdete v tématu Použití služby Azure Firewall k ochraně nasazení služby Azure Kubernetes Service (AKS).

• Volitelně je možné použít proxy server HTTP pro monitorování a zabezpečení odchozího (výchozího) provozu z clusteru do externích prostředků.

  Kromě brány firewall můžou některé organizace chtít použít proxy server HTTP, aby měly další ovládací prvky pro výchozí přenos dat. Doporučujeme, abyste stále měli trasy definované uživatelem, které jsou směrované na bránu firewall, a omezit odchozí provoz tak, aby jenom přešli na proxy server HTTP. Při tomto nastavení se pod pokusí přepsat proxy server, brána firewall může stále blokovat odchozí provoz.

  Další informace najdete v tématu Podpora proxy serveru HTTP ve službě Azure Kubernetes Service.

Cluster může vyžadovat přístup k jiným službám přes veřejný internet. Pokud používáte antimalwarový software třetí strany, bude nutné získat definice virů ze serveru přes veřejný internet.

Interakce s koncovými body jiných služeb Azure jsou přes páteřní síť Azure. Například v rámci pravidelných operací bude cluster muset získat certifikáty ze spravovaného úložiště klíčů, vyžádat image z registru kontejneru atd. Zajistěte, aby tyto interakce byly privátní a zabezpečené pomocí služby Azure Private Link.

Kromě pravidel brány firewall a privátních sítí jsou toky NSG také zabezpečené prostřednictvím pravidel. Tady je několik příkladů z této architektury, kde je CDE chráněná odepřením provozu:

• Skupiny zabezpečení sítě v podsítích s fondy uzlů zamítnou veškerý přístup SSH k jeho uzlům. Máte zaveden proces pro nouzový přístup za běhu a současně zachovat zásadu odepření všech.
• Skupina zabezpečení sítě v podsíti, která obsahuje jump box pro spouštění nástrojů pro správu, odmítne veškerý provoz kromě služby Azure Bastion v centrální síti.
• Skupiny zabezpečení sítě v podsítích, které mají privátní koncové body pro Azure Key Vault a Azure Container Registry, zamítnou veškerý provoz kromě interního nástroje pro vyrovnávání zatížení a provozu přes Azure Private Link.

Požadavek 1.2.2

Zabezpečte a synchronizujte konfigurační soubory směrovače.

Vaše odpovědnosti

Máte mechanismus pro detekci rozdílu mezi skutečným stavem nasazení a požadovaným stavem. Infrastruktura jako kód (IaC) je pro tento účel skvělou volbou. Například šablony Azure Resource Manageru mají záznam požadovaného stavu.

Prostředky nasazení, jako jsou šablony ARM, musí být řízeny zdrojem, abyste měli historii všech změn. Shromážděte informace z protokolů aktivit Azure, protokolů kanálu nasazení a protokolů nasazení Azure. Tyto zdroje vám pomůžou udržet stopu nasazených prostředků.

V clusteru by se měly řídit sítě, jako jsou zásady sítě Kubernetes, také řídit tok řízený zdrojem. V této implementaci se Flux používá jako operátor GitOps. Při synchronizaci konfigurace clusteru, jako jsou zásady sítě, může být historie Gitu v kombinaci s protokoly Flux a API zdrojem historie konfigurace.

Požadavek 1.2.3

Nainstalujte hraniční brány firewall mezi všemi bezdrátovými sítěmi a datovým prostředím držitelů karet a nakonfigurujte tyto brány firewall tak, aby odepřely nebo pokud je provoz nutný pro obchodní účely, povolte pouze autorizovaný provoz mezi bezdrátovým prostředím a datovým prostředím držitelů karet.

Vaše odpovědnosti

Uzly AKS a fondy uzlů nesmí být dostupné z bezdrátových sítí. Požadavky na server rozhraní API Kubernetes musí být také odepřeny. Přístup k těmto komponentám je omezený na autorizované a zabezpečené podsítě.

Obecně platí, že omezte přístup z místního provozu do paprskové sítě.

Požadavek 1.3

Zakázat přímý veřejný přístup mezi internetem a libovolnou systémovou komponentou v datovém prostředí karet.

Vaše odpovědnosti

Fondy uzlů clusteru AKS fungují ve virtuální síti a jsou izolované od veřejných sítí, jako je internet. Udržujte izolaci tím, že zabráníte přidružení veřejných IP adres k uzlům clusteru a použijete pravidla NSG v podsítích clusteru, aby se zajistilo zablokování internetového provozu. Informace o řízeném přístupu najdete v části DMZ.

Cluster AKS má fondy systémových uzlů, které hostují důležité systémové pody. I ve fondech uzlů uživatelů existují pody, které spouštějí další služby, které se účastní operací clusteru. Pody můžou například spouštět Flux pro synchronizaci konfigurace clusteru s úložištěm GitHub nebo kontroleru příchozího přenosu dat pro směrování provozu do podů úloh. Bez ohledu na typ fondu uzlů musí být všechny uzly chráněné.

Další důležitou systémovou komponentou je server rozhraní API, který slouží k nativním úlohám Kubernetes, jako je udržování stavu clusteru a konfigurace. Výhodou použití privátního clusteru je, že koncový bod serveru ROZHRANÍ API není ve výchozím nastavení vystavený. Informace o privátních clusterech najdete v tématu Vytvoření privátního clusteru Azure Kubernetes Service.

Musí být zabezpečeny také interakce s jinými koncovými body. Jedním ze způsobů je omezení komunikace přes privátní síť. Například cluster načítá image ze služby Azure Container Registry přes privátní propojení.

Požadavek 1.3.1

Implementujte DMZ pro omezení příchozího provozu jenom na systémové komponenty, které poskytují autorizované veřejně přístupné služby, protokoly a porty.

Vaše odpovědnosti

Tady jsou některé osvědčené postupy:

• Nenakonfigurujte veřejné IP adresy na uzlech fondu uzlů.
• Pomocí Azure Policy se ujistěte, že Kubernetes nezpřístupňuje veřejný nástroj pro vyrovnávání zatížení. Provoz v rámci clusteru musí být směrován prostřednictvím interních nástrojů pro vyrovnávání zatížení.
• Zpřístupnit interní nástroje pro vyrovnávání zatížení pouze pro Aplikace Azure Gateway integrované s WAF.
• Všechny síťové ovládací prvky by měly určit omezení zdroje, cíle, portu a protokolu, pokud je to možné.
• Nezpřístupňujte server rozhraní API na internetu. Při spuštění clusteru v privátním režimu se koncový bod nezpřístupní a komunikace mezi fondy uzlů a serverem rozhraní API je přes privátní síť.

Uživatelé můžou implementovat hraniční síť pro ochranu clusterů AKS. Informace naleznete v tématu Cloud DMZ.

Požadavek 1.3.2

Omezte příchozí internetový provoz na IP adresy v rámci DMZ.

Vaše odpovědnosti

V síti clusteru má skupina zabezpečení sítě v podsíti s interním nástrojem pro vyrovnávání zatížení. Nakonfigurujte pravidla tak, aby přijímala pouze provoz z podsítě, která má bránu Aplikace Azure integrovanou s WAF. V rámci clusteru AKS použijte Kubernetes NetworkPolicies k omezení příchozího přenosu dat do podů.

Požadavek 1.3.3

Implementujte antipoofingové míry, které detekují a blokují zablokované zdrojové IP adresy vniknutí do sítě.

Odpovědnosti Za Azure

Azure implementuje filtrování sítě, aby se zabránilo falšování identity provozu a omezilo příchozí a odchozí provoz na důvěryhodné komponenty platformy.

Požadavek 1.3.4

Nepovolujte neoprávněný odchozí provoz z datového prostředí držitelů karet do internetu.

Vaše odpovědnosti

Tady jsou způsoby, kterými můžete blokovat neautorizovaný odchozí provoz:

• Vynucujte veškerý odchozí (výchozí) provoz z clusteru AKS, aby procházel bránou Azure Firewall pomocí tras definovaných uživatelem ve všech podsítích clusteru. To zahrnuje podsítě s fondy systémových a uživatelských uzlů.
• Omezte odchozí provoz přidáním skupin zabezpečení sítě do podsítí s fondy uzlů.
• Pomocí Kubernetes NetworkPolicies omezte odchozí provoz z podů.
• K zpracování dalších zásad použijte síť služeb. Pokud například povolíte pouze přenosy šifrované protokolem TLS mezi pody, proxy síť služby může zpracovat ověření protokolu TLS. Tento příklad je ukázaný v této implementaci. Jako proxy se nasadí envoy.
• Pokud podsítě explicitně neautorizují podsítě, jako jsou podsítě brány firewall, zabráníte přidání veřejných IP adres do sítí v rámci služby CDE.
• K omezení odchozího (výchozího) provozu z clusteru AKS na internet použijte kromě služby Azure Firewall proxy server HTTP.
• Pomocí služby Azure Monitor Private Link Service (AMPLS) můžete protokoly ze služby Container Insights odesílat prostřednictvím zabezpečeného privátního připojení ke službě Azure Monitor. Seznamte se s dopadem povolení služby AMPLS.

Podrobnosti najdete v tématu Řízení výchozího přenosu dat pro uzly clusteru ve službě Azure Kubernetes Service (AKS).

Požadavek 1.3.5

Povolte pouze "navázáná" připojení k síti.

Odpovědnosti Za Azure

Azure implementuje filtrování sítě, aby se zabránilo falšování identity provozu a omezilo příchozí a odchozí provoz na důvěryhodné komponenty platformy. Síť Azure je oddělená tak, aby oddělila provoz zákazníků od provozu správy.

Požadavek 1.3.6

Umístěte systémové komponenty, které ukládají data držitelů karet (například databázi) do interní zóny sítě, oddělují se od DMZ a dalších nedůvěryhodných sítí.

Vaše odpovědnosti

Zpřístupněte systémy úložiště pouze přes privátní síť, například pomocí služby Private Link. Omezte také přístup z podsítí fondu uzlů, které ho vyžadují. Udržujte stav mimo cluster a ve vlastní vyhrazené zóně zabezpečení.

Požadavek 1.3.7

Nezveřejňujte privátní IP adresy a informace o směrování neoprávněným stranám.

Vaše odpovědnosti

Pro splnění tohoto požadavku není možné použít veřejný cluster AKS. Privátní cluster uchovává záznamy DNS z veřejného internetu pomocí privátní zóny DNS. Přesto je ale možné vytvořit privátní cluster AKS s veřejnou adresou DNS. Proto doporučujeme tuto funkci explicitně zakázat nastavením enablePrivateClusterPublicFQDN , aby false se zabránilo zpřístupnění privátní IP adresy řídicí roviny. Zvažte použití služby Azure Policy k vynucení použití privátních clusterů bez veřejných záznamů DNS.

Pro směrování mezi podsítí, která má bránu Aplikace Azure integrovanou s WAF, a podsítí, která má interní nástroj pro vyrovnávání zatížení, použijte také privátní zónu DNS. Ujistěte se, že žádné odpovědi HTTP neobsahují žádné informace o privátní IP adrese v hlavicích nebo textu. Ujistěte se, že protokoly, které můžou obsahovat IP adresu a záznamy DNS, nejsou vystavené mimo provozní potřeby.

Služba Azure, která je připojená přes Private Link, nemá veřejný záznam DNS, který vystavuje vaše IP adresy. Vaše infrastruktura by měla optimálně využívat službu Private Link.

Požadavek 1.4

Nainstalujte software osobní brány firewall nebo ekvivalentní funkce na všechna přenosná výpočetní zařízení, která se připojují k internetu mimo síť, a která se také používají pro přístup k CDE.

Vaše odpovědnosti

Privátní cluster spravuje řídicí rovina AKS. Nemáte přímý přístup k uzlům. K provádění úloh správy budete muset použít nástroje pro správu, jako je kubectl z samostatného výpočetního prostředku. Možnost je použít jump box se mezerou vzduchu, kde můžete spouštět příkazy. Příchozí a odchozí provoz z jump boxu musí být také omezený a zabezpečený. Pokud se pro přístup používá síť VPN, ujistěte se, že je klientský počítač spravovaný podnikovými zásadami a jsou zavedeny všechny zásady podmíněného přístupu.

V této architektuře je tento jump box v samostatné podsíti v paprskové síti. Příchozí přístup k jump boxu je omezený pomocí skupiny zabezpečení sítě, která povoluje přístup jenom přes Azure Bastion přes SSH.

Pokud chcete na jump boxu spouštět určité příkazy, budete se muset spojit s veřejnými koncovými body. Například koncové body spravované rovinou správy Azure. Odchozí provoz musí být zabezpečený. Podobně jako u jiných komponent v paprskové síti je odchozí provoz z jump boxu omezený pomocí trasy definované uživatelem, která vynutí provoz HTTPs, aby procházel přes Azure Firewall.

Požadavek 1.5

Ujistěte se, že zásady zabezpečení a provozní postupy pro správu bran firewall jsou zdokumentované, používané a známé všem ovlivněným stranám.

Vaše odpovědnosti

Je důležité udržovat důkladnou dokumentaci k procesu a zásadám. To platí hlavně v případě, že spravujete pravidla služby Azure Firewall, která segmentují cluster AKS. Lidé provoz regulovaných prostředí musí být poučeny, informovány a incentivizovány, aby podporovaly záruky zabezpečení. To je zvlášť důležité pro uživatele s účty, kterým jsou udělena široká oprávnění správce.

Požadavek 2 – Nepoužívejte výchozí hodnoty dodané dodavatelem pro hesla systému a další parametry zabezpečení.

Vaše odpovědnosti

Požadavek	Odpovědnost
Požadavek 2.1	Před instalací systému v síti vždy změňte výchozí hodnoty dodané dodavatelem a před instalací systému v síti odeberte nebo zakažte nepotřebné výchozí účty.
Požadavek 2.2	Vyvíjejte standardy konfigurace pro všechny systémové komponenty. Ujistěte se, že tyto standardy řeší všechna známá ohrožení zabezpečení a jsou konzistentní s oborovými standardy posílení zabezpečení systému.
Požadavek 2.3	Zašifrujte veškerý přístup pro správu mimo konzolu pomocí silné kryptografie.
Požadavek 2.4	Udržujte inventář systémových komponent, které jsou v rozsahu pro PCI DSS.
Požadavek 2.5	Ujistěte se, že zásady zabezpečení a provozní postupy pro správu výchozích hodnot dodavatelů a dalších parametrů zabezpečení jsou zdokumentované, používané a známé všem ovlivněným stranám.
Požadavek 2.6	Poskytovatelé sdíleného hostingu musí chránit hostované prostředí každé entity a data držitelů karet.

Nepoužívejte výchozí hodnoty dodané dodavatelem pro systémová hesla a další parametry zabezpečení.

Požadavek 2.1

Před instalací systému v síti vždy změňte výchozí hodnoty dodané dodavatelem a před instalací systému v síti odeberte nebo zakažte nepotřebné výchozí účty.

Vaše odpovědnosti

Výchozí nastavení poskytovaná dodavateli je nutné změnit. Výchozí nastavení jsou běžné vektory útoku a systém je náchylný k útokům. Tady je několik aspektů:

• Zakažte přístup správce v registru kontejneru.
• Ujistěte se, že jump boxy a agenti sestavení dodržují postupy správy uživatelů a odebírají potřebné systémové uživatele.
• Negenerujte ani nezadáte přístup ke klíčům SSH k uzlům pro uživatele správce. V případě potřeby tísňového přístupu použijte proces obnovení Azure k získání přístupu za běhu.

Odpovědnosti Za Azure

Microsoft Entra ID má zásady hesel, které se vynucují pro nová hesla poskytnutá uživateli. Pokud změníte heslo, vyžaduje se ověření staršího hesla. Správa istrator resetování hesel je potřeba změnit při následném přihlášení.

Požadavek 2.1.1

V případě bezdrátových prostředí připojených k datovému prostředí držitelů karet nebo přenosu dat držitelů karet změňte výchozí nastavení všech bezdrátových dodavatelů při instalaci, včetně výchozích bezdrátových šifrovacích klíčů, hesel a řetězců komunity SNMP.

Vaše odpovědnosti

Tato architektura a implementace nejsou navrženy tak, aby přes bezdrátová připojení dělaly místní ani firemní síť pro cloudové transakce. Důležité informace najdete v pokynech v oficiální normě PCI-DSS 3.2.1.

Požadavek 2.2

Vyvíjejte standardy konfigurace pro všechny systémové komponenty.

Vaše odpovědnosti

Implementujte doporučení v srovnávacím testu zabezpečení Azure. Poskytuje jediný konsolidovaný pohled na doporučení zabezpečení Azure, která pokrývají oborové architektury, jako jsou CIS, NIST, PCI-DSS 3.2.1 a další. Využijte Microsoft Defender pro cloudové funkce a Azure Policy, které vám pomůžou sledovat standardy. Srovnávací test zabezpečení Azure je výchozí iniciativa pro Microsoft Defender for Cloud. Zvažte vytvoření dalších automatizovaných kontrol ve službě Azure Policy a azure Tenant Security Solution (AzTS).

Zdokumentujte požadovaný stav konfigurace všech komponent v CDE, zejména pro uzly AKS, jump box, agenty sestavení a další komponenty, které komunikují s clusterem.

Další informace najdete v tématu Srovnávací test zabezpečení Azure.

Odpovědnost za Azure

Azure poskytuje standardy konfigurace zabezpečení, které jsou konzistentní s oborovými standardy posílení zabezpečení. Standardy se prověřují alespoň jednou ročně.

Požadavek 2.2.1

Implementujte pouze jednu primární funkci na server, aby se zabránilo funkcím, které vyžadují různé úrovně zabezpečení, aby byly na stejném serveru společně existující. (Například webové servery, databázové servery a DNS by se měly implementovat na samostatných serverech.)

Vaše odpovědnosti

Klíčovou strategií je poskytnout požadovanou úroveň segmentace. Jedním ze způsobů je nasazení komponent v oboru a mimo rozsah v samostatných clusterech. Mějte na vědomí, že výsledkem jsou zvýšené náklady na přidanou infrastrukturu a režijní náklady na údržbu. Dalším přístupem je společné vyhledání všech komponent ve sdíleném clusteru. K udržení oddělení použijte strategie segmentace. Máte například samostatné fondy uzlů v rámci clusteru.

V referenční implementaci se druhý přístup demonstruje s aplikací mikroslužeb nasazenou do jednoho clusteru. Aplikace má dvě sady služeb: jedna sada má pody v oboru a druhá je mimo rozsah. Obě sady jsou rozdělené mezi dva fondy uzlů uživatele. Při použití taintů Kubernetes se pody v oboru a mimo rozsah nasazují do samostatných fondů uzlů a nikdy nesdílejí virtuální počítač uzlu.

U technologií kontejnerů je tato segmentace ve výchozím nastavení poskytována, protože za jednu funkci v systému zodpovídá pouze jedna instance kontejneru.

Úloha by měla používat identitu spravovanou podem. Nesmí dědit žádnou identitu na úrovni clusteru ani na úrovni uzlu.

Pokud je to možné, použijte externí úložiště místo úložiště v uzlu (v clusteru). Ponechte pody clusteru vyhrazené výhradně pro práci, která se musí provádět v rámci zpracování dat držitelů karet. Přesuňte mimo rozsah operace mimo cluster. Tyto pokyny platí pro agenty sestavení, nesouvisející úlohy nebo aktivity, jako je například jump box uvnitř clusteru.

Požadavek 2.2.2

Povolte pouze nezbytné služby, protokoly, démony atd., podle potřeby pro funkci systému.

Vaše odpovědnosti

Než je povolíte, projděte si funkce a důsledky. Výchozí nastavení může zahrnovat funkce, které nepotřebujete, a tyto funkce můžou potřebovat přehled o úloze. Příkladem je šifry ve výchozích zásadách SSL pro Aplikace Azure Gateway. Zkontrolujte, jestli je zásada příliš přesvědčivá. Doporučením je vytvořit vlastní zásadu tak, že vyberete jenom šifry, které potřebujete.

U komponent, u kterých máte úplnou kontrolu, odeberte ze imagí všechny nepotřebné systémové služby (například jump boxy a agenty sestavení).

U komponent, ve kterých máte jenom viditelnost, jako jsou uzly AKS, zdokumentujte, co Azure na uzly nainstaluje. Zvažte použití DaemonSets k poskytnutí dalších auditování nezbytných pro tyto cloudové řízené komponenty.

Požadavek 2.2.3

Implementujte další funkce zabezpečení pro všechny požadované služby, protokoly nebo démony, které jsou považovány za nezabezpečené.

Vaše odpovědnosti

Application Gateway má integrovaný WAF a vyjedná metodu handshake protokolu TLS pro požadavek odeslaný do svého veřejného koncového bodu, což umožňuje pouze zabezpečené šifry. Referenční implementace podporuje pouze protokol TLS 1.2 a schválené šifry.

Předpokládejme, že máte starší zařízení, které potřebuje komunikovat se službou CDE prostřednictvím brány Aplikace Azure. V takovém případě musí služba Application Gateway povolit nezabezpečený protokol. Zdokumentujte tuto výjimku a monitorujte, pokud se tento protokol používá nad rámec tohoto staršího zařízení. Zakažte tento protokol okamžitě po ukončení této starší interakce.

Application Gateway také nesmí reagovat na požadavky na portu 80. Neprovádějte přesměrování na úrovni aplikace. Tato referenční implementace obsahuje pravidlo NSG, které blokuje provoz portu 80. Pravidlo je v podsíti se službou Application Gateway.

Pokud úloha v clusteru nemůže dodržovat zásady organizace týkající se profilů dodržování předpisů zabezpečení nebo jiných ovládacích prvků (například omezení a kvót), ujistěte se, že je výjimka zdokumentovaná. Pokud chcete zajistit, aby se prováděly pouze očekávané funkce, musíte monitorovat.

Požadavek 2.2.4

Nakonfigurujte parametry zabezpečení systému, aby se zabránilo zneužití.

Vaše odpovědnosti

Všechny služby Azure používané v architektuře musí dodržovat doporučení poskytnutá srovnávacím testem zabezpečení Azure. Tato doporučení poskytují výchozí bod pro výběr konkrétních nastavení konfigurace zabezpečení. Porovnejte také konfiguraci s implementací standardních hodnot pro danou službu. Další informace o standardních hodnotách zabezpečení najdete v tématu Standardní hodnoty zabezpečení pro Azure.

Kontroler přístupu agenta Open Policy funguje ve spojení se službou Azure Policy ke zjišťování a prevenci chybných konfigurací v clusteru. Předpokládejme, že existují zásady organizace, které nepovolují přidělování veřejných IP adres na uzlech. Když se takové přidělení zjistí, označí se pro audit nebo odepření na základě akce zadané v definici zásady.

Na úrovni infrastruktury můžete použít omezení typu a konfigurace prostředků Azure. K zabránění těmto případům použijte Azure Policy. V této referenční implementaci existuje zásada, která zakazuje vytváření clusterů AKS, které nejsou soukromé.

Pravidelně se ujistěte, že jsou všechny výjimky zdokumentovány a zkontrolovány.

Odpovědnosti Za Azure

Azure zajišťuje, aby pomocí vícefaktorového řízení přístupu a zdokumentovaných obchodních potřeb mohli konfigurovat pouze autorizovaní pracovníci řízení zabezpečení platformy Azure.

Požadavek 2.2.5

Odeberte všechny nepotřebné funkce, jako jsou skripty, ovladače, funkce, subsystémy, systémy souborů a nepotřebné webové servery.

Vaše odpovědnosti

Nenainstalujte software na jump boxy ani agenty sestavení, kteří se nezúčastní zpracování transakce nebo poskytují pozorovatelnost požadavků na dodržování předpisů, jako jsou agenti zabezpečení. Toto doporučení platí také pro entity clusteru, například DaemonSet pody. Ujistěte se, že jsou zjištěny a protokolovány všechny instalace.

Požadavek 2.3

Zašifrujte veškerý přístup pro správu mimo konzolu pomocí silné kryptografie.

Vaše odpovědnosti

Veškerý přístup správce ke clusteru by měl být proveden pomocí konzoly. Nezpřístupňujte řídicí rovinu clusteru.

Odpovědnosti Za Azure

Azure zajišťuje, že se při přístupu k infrastruktuře hypervisoru vynucuje použití silné kryptografie. Zajišťuje, aby zákazníci, kteří používají portál pro správu Microsoft Azure, měli přístup ke svým konzolám i konzolám IaaS se silnou kryptografií.

Požadavek 2.4

Udržujte inventář systémových komponent, které jsou v rozsahu pro PCI DSS.

Vaše odpovědnosti

Všechny prostředky Azure používané v architektuře musí být správně označené. Značky pomáhají s klasifikací dat a označují, jestli je služba v oboru nebo mimo rozsah. Podrobné označování vám umožní dotazovat se na prostředky, udržovat inventář, pomáhat sledovat náklady a nastavovat upozornění. Pravidelně také udržujte snímek této dokumentace.

Vyhněte se označování prostředků v oboru nebo mimo rozsah na podrobné úrovni. S vývojem řešení se prostředky mimo rozsah můžou stát v rozsahu, i když nepřímo interagují nebo sousedí s daty držitelů karet. Tyto prostředky se můžou auditovat a mohou být součástí reprezentativní ukázky během auditu. Zvažte označování na vyšší úrovni na úrovni předplatného a clusteru.

Informace o aspektech označování najdete v průvodci rozhodováním o pojmenování a označování prostředků.

Označte objekty v clusteru použitím popisků Kubernetes. Tímto způsobem můžete uspořádat objekty, vybrat kolekci objektů a vytvořit sestavu inventáře.

Požadavek 2.5

Ujistěte se, že zásady zabezpečení a provozní postupy pro správu výchozích hodnot dodavatelů a dalších parametrů zabezpečení jsou zdokumentované, používané a známé všem ovlivněným stranám.

Vaše odpovědnosti

Je důležité udržovat důkladnou dokumentaci k procesům a zásadám. Pracovníci by se měli vytrénovat v nastavení zabezpečení a konfigurace jednotlivých prostředků Azure. Lidé provoz regulovaných prostředí musí být poučeny, informovány a incentivizovány, aby podporovaly záruky zabezpečení. To je zvlášť důležité pro účty správců, kterým jsou udělena široká oprávnění správce.

Požadavek 2.6

Poskytovatelé sdíleného hostingu musí chránit hostované prostředí každé entity a data držitelů karet.

Vaše odpovědnosti

Azure poskytuje záruky zabezpečení pro všechny hostované součásti prostředí, které jsou sdílené. Důrazně doporučujeme, abyste s uzly AKS zacházeli jako s vyhrazeným hostitelem pro tuto úlohu. To znamená, že všechny výpočetní prostředky by měly být v jednom modelu tenanta a neměly by být sdíleny s jinými úlohami, které můžete provozovat.

Pokud je na úrovni infrastruktury Azure požadovaná úplná izolace výpočetních prostředků, můžete do clusteru Azure Kubernetes Service (AKS) přidat vyhrazeného hostitele Azure. Tato nabídka poskytuje fyzické servery vyhrazené pro vaši úlohu a umožňuje umístit uzly AKS přímo do těchto zřízených hostitelů. Tato volba architektury má významný dopad na plánování nákladů a kapacity a není typická pro většinu scénářů.

Další kroky

Chraňte uložená data držitelů karet. Zašifrujte přenos dat držitelů karet napříč otevřenými veřejnými sítěmi.

Související prostředky

• Návrh architektury Služby Azure Kubernetes Service (AKS)
• Zavedení regulovaného clusteru AKS pro PCI-DSS 3.2.1 (část 1 z 9)
• Architektura regulovaného clusteru AKS pro PCI-DSS 3.2.1 (část 2 z 9)
• Základní architektura pro cluster Azure Kubernetes Service (AKS)
• Standardní hodnoty AKS pro clustery s více oblastmi