Konfigurace sítě se AKS regulovaným clusterem pro PCI-DSS 3.2.1 (část 3 z 9)

Tento článek popisuje požadavky pro cluster Azure Kubernetes Service (AKS), který je nakonfigurovaný v souladu se standardem PCI-DSS v oboru 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.

Hlavním motivem PCI-DSS 3.2.1 Standard je zabezpečení. Topologie centra s paprsky je přirozenou volbou pro nastavení regulovaného prostředí. Vytváření infrastruktury, která umožňuje zabezpečenou komunikaci, je snazší. Ovládací prvky sítě se umísťují do obou sítí hvězdicové sítě a řídí se modelem nulové důvěryhodnosti od Microsoftu. Ovládací prvky lze vyladit s nejnižšími oprávněními pro zabezpečení provozu a poskytují přístup podle potřeby. Kromě toho můžete použít několik přístupů do důkladné obrany přidáním ovládacích prvků při každém směrování v síti.

Při hostování úlohy v Kubernetes není dostačující spoléhat na tradiční konstrukce sítě, jako jsou pravidla brány firewall. Existují také Kubernetes konstrukce, které řídí tok provozu v clusteru, jako je například NetworkPolicy prostředek. Důrazně doporučujeme, abyste se seznámili se základními koncepty pro izolované lusky a zásady příchozího a odchozího přenosu informací v dokumentaci k Kubernetes.

Sestavování a údržba zabezpečených sítí a systémů

Požadavek 1 — Nainstalujte a udržujte konfiguraci brány firewall pro ochranu dat držitele.

Podpora funkcí AKS

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

Azure Firewall lze integrovat s AKS a může omezit odchozí provoz z clusteru, což je klíčová komponenta CDE. Konfigurace je snadná díky značce AKS plně kvalifikovaného názvu domény. Doporučený postup je k dispozici v části použití Azure firewall k ochraně nasazení služby Azure Kubernetes Service (AKS).

Clustery AKS vyžadují, aby byl přístup k rovině spravovaného řízení nějaký veřejným internetovým přístupem. Omezte odchozí provoz na Internet pomocí Azure Firewall a skupin zabezpečení sítě v podsíti clusteru. Informace najdete v tématu řízení odchozího provozu pro uzly clusteru ve službě Azure Kubernetes Service (AKS).

Vaše odpovědnosti

Požadavek	Zodpovědní
Požadavek 1,1	Vytvoření a implementace standardů konfigurace brány firewall a směrovače.
Požadavek 1,2	Sestavování konfigurací brány firewall a směrovačů, které omezují připojení mezi nedůvěryhodnými sítěmi a všemi systémovými součástmi v datovém prostředí držitele.
Požadavek 1,3	Zabrání přímému veřejnému přístupu mezi Internetem a všemi součástmi systému v datovém prostředí držitele.
Požadavek 1,4	Nainstalujte osobní software brány firewall nebo ekvivalentní funkce na všechna přenosná výpočetní zařízení (včetně společnosti nebo zaměstnanců), která se připojují k Internetu, pokud se nachází mimo síť (například přenosné počítače používané zaměstnanci) a které se také používají 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 popsány, jsou používány a jsou známy všem postiženým stranám.

Požadavek 2 — Pro systémová hesla a další parametry zabezpečení nepoužívejte výchozí nastavení dodavatele.

Vaše odpovědnosti

Požadavek	Zodpovědní
Požadavek 2,1	Před instalací systému do sítě vždy změňte výchozí hodnoty zadané dodavatelem a odeberte nebo zakažte nepotřebné výchozí účty.
Požadavek 2,2	Vývoj standardů konfigurace pro všechny součásti systému. Zajistěte, aby tyto standardy vyznamenaly všechny známé chyby zabezpečení a byly konzistentní s tím, jak byly přijaty 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 oboru 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ší parametry zabezpečení jsou popsány v používání a jsou známy všem postiženým stranám.
Požadavek 2,6	Poskytovatelé sdíleného hostování musí chránit hostované prostředí a data držitele každé entity.

Požadavek 1,1

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

Požadavek 1.1.1

Formální proces pro schválení 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 pomocí Azure Portal nebo přímo prostřednictvím rozhraní příkazového řádku Azure. Doporučujeme použít infrastrukturu jako kód (IaC). V IaC se infrastruktura spravuje pomocí popisného modelu, který používá systém správy verzí. Model IaC vygeneruje stejné prostředí při každém použití. Běžné příklady IaC jsou Azure Resource Manager nebo Terraformu. Pokud IaC není možností, máte dobře zdokumentované procesy pro sledování, implementaci a bezpečné nasazení změn pravidel brány firewall. Další podrobnosti jsou k dispozici jako součást požadavku 11,2.

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

Minimalizujte počet uživatelů, kteří mají přístup k síťovým ovládacím prvkům a upravují je. Definujte role a odstraňte zodpovědnosti na týmy. Například síťový tým organizace bude ověřovat změny podle zásad správného řízení nastavených týmy IT. Mít proces ověřovaného schválení, který zahrnuje lidi a procesy ke schválení změn v jakékoli konfiguraci sítě. Proces by měl zahrnovat krok pro testování všech síťových ovládacích prvků. Podrobná dokumentace, která popisuje proces.

Požadavek 1.1.2

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

Vaše odpovědnosti

V rámci vaší dokumentace Udržujte diagram toku sítě, který zobrazuje příchozí a odchozí provoz s ovládacími prvky zabezpečení. To zahrnuje přenosový tok z jiných sítí, včetně jakékoli bezdrátové sítě do CDE. Diagram by taky měl zobrazovat toky v rámci clusteru. Existují určité požadavky na diagramy, které by měly zobrazit senzory vniknutí. Ovládací prvky pro

Tento obrázek ukazuje síťový diagram implementace reference.

Obrázek 1.1.2 – tok sítě

Popis tohoto toku je v následujících oddílech.

Pokud máte Azure Network Watcher, můžete Zobrazit topologii Azure Virtual Network . 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, který zobrazuje všechny toky dat na držiteli napříč systémy a sítěmi.

Vaše odpovědnosti

Jako součást vaší dokumentace zahrňte diagram toku dat, který ukazuje, jak jsou data chráněná v klidovém umístění a při přenosu.

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

Vzhledem k tomu, že se tato architektura zaměřuje na infrastrukturu a ne na zatížení, jsme tady vynechali 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á (DMZ) a zónou interní sítě.

Vaše odpovědnosti

Musí mít jasnou definici toho, co definuje hranici DMZ. Například v rámci DMZ zabezpečeného bránou firewall, zásadami sítě a dalšími ovládacími prvky se může jednat o datové prostředí (CDE). Další informace najdete 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é zablokují neoprávněný přístup do sítě a ze sítě pomocí CDE. Síťové ovládací prvky musí být správně nakonfigurované pro silné stav zabezpečení a musí se použít na:

• Komunikace mezi společně umístěnými součástmi v rámci clusteru.
• Komunikace mezi úlohami a dalšími součástmi v důvěryhodných sítích.
• Komunikace mezi úlohami a veřejným internetem.

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

• WAF (Integrated Web Application firewall) pro Azure Application Gateway slouží jako směrovač provozu a pro zabezpečení příchozího (příchozího) provozu do clusteru.

• Azure Firewall slouží k zabezpečení odchozího (odchozího) provozu z libovolné sítě a jejích podsítí.

  V rámci zpracování transakcí nebo operací správy bude cluster potřebovat komunikovat s externími entitami. cluster může například vyžadovat komunikaci s rovinou ovládacího prvku AKS, Windows získávat aktualizace balíčků a aktualizace balíčku a interakce úlohy 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ílem útoku prostředníkem, který může mít za následek exfiltrace dat. Přidání brány firewall do odchozího provozu snižuje riziko této hrozby.

  Doporučujeme, aby byla i komunikace pod protokolem TLS zašifrovaná. Tento postup se zobrazuje v referenční implementaci s použitím mTLSové sítě.

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

  Když přidáváte součásti do architektury, zvažte přidání dalších skupin zabezpečení sítě, které povolují nebo odmítnou typy provozu na hranicích podsítí. Vzhledem k tomu, že každý fond uzlů je ve vyhrazené podsíti, aplikujte konkrétnější pravidla na základě očekávaných vzorců provozu vašich úloh.

• Kubernetes NetworkPolicy

  Ve výchozím nastavení neexistují žádná omezení komunikace s příponou pod. Je nutné použít při NetworkPolicy komunikaci v rámci clusteru, počínaje sítí s nulovou důvěryhodností a otevřít cesty podle potřeby. Referenční implementace ukazuje sítě s nulovým vztahem důvěryhodnosti a0005-i v a0005-o oborech názvů a. Pro všechny obory názvů (s výjimkou kube-system , gatekeeper-system a jiné AKS poskytované obory názvů) se uplatní omezující podmínky NetworkPolicy . Definice zásad závisí na luskech spuštěných v těchto oborech názvů. Ujistěte se, že jste otevřeli cesty pro testy Readiness, liveliness a Startup. Otevřete také cestu k oms-agent tomu, aby bylo možné odesílat metriky na úrovni uzlu. Zvažte standardizaci portů napříč úlohami, abyste mohli zajistit konzistentní NetworkPolicy a Azure Policy pro povolené porty kontejnerů.

1.1.5 požadavku

Popis skupin, rolí a odpovědnost za správu síťových součástí.

Vaše odpovědnosti

Budete muset poskytnout ovládací prvky pro síťové toky a příslušné součásti. Výsledná infrastruktura bude mít několik segmentů sítě, z nichž každý má mnoho ovládacích prvků, a každý ovládací prvek s účelem. Zajistěte, aby vaše dokumentace nejen dosáhla rozsahu pokrytí v rámci plánování sítě až po všechny konfigurace, ale obsahuje také podrobnosti o vlastnictví. Mít jasné řádky zodpovědnosti a role, které jsou za ně zodpovědné.

Zjistěte například, kdo zodpovídá za řízení zabezpečování sítě mezi Azure a internetem. V podniku je IT tým zodpovědný za konfiguraci a údržbu pravidel Azure Firewall, firewallu webových aplikací (WAF), skupin zabezpečení sítě a dalších přenosů mezi sítěmi. Můžou být taky zodpovědné za podnikovou virtuální síť a přidělení podsítě a pro plánování IP adres.

Na úrovni zatížení zodpovídá operátor clusteru za údržbu Zero-Trust prostřednictvím zásad sítě. Zodpovědnosti mohou zahrnovat i komunikaci s řídicími rovinami Azure, Kubernetes rozhraními API a monitorovacími technologiemi.

Vždy zahajte pomocí strategie Deny-ALL. Poskytněte oprávnění pouze v případě, že je to obchodní potřeby nebo odůvodnění role.

1.1.6 požadavku

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

Vaše odpovědnosti

Máte podrobnou dokumentaci, která popisuje služby, protokoly a porty používané v ovládacích prvcích sítě. Odepřít vše s výjimkou výslovně povolených portů. Zdokumentujte obchodní odůvodnění a dokumentované funkce zabezpečení, pokud nemůžete zabránit použití nezabezpečených protokolů. Zde je několik příkladů z referenční implementace pro Azure Firewall. Pravidla brány firewall musí být vymezena výhradně na jejich související prostředky. To znamená, že každý provoz z konkrétních zdrojů může přejít na konkrétní plně kvalifikovaný název domény. Tady je několik případů pro povolení provozu.

Pravidlo	Protokol:port	Zdroj	Cíl	Zdůvodnění
Povolí zabezpečenou komunikaci mezi uzly a řídicí rovinou.	HTTPS: 443	Schválené rozsahy IP adres přiřazené ke fondům uzlů clusteru	Seznam cílů plně kvalifikovaného názvu domény v rovině ovládacího prvku AKS Tento parametr je zadaný s AzureKubernetesService označením plně kvalifikovaného názvu domény.	Uzly potřebují přístup k rovině ovládacího prvku pro nástroje pro správu, informace o stavu a konfiguraci a informace o tom, které uzly lze škálovat.
Povolí zabezpečenou komunikaci mezi tokem a GitHub.	HTTPS: 443	Fondy uzlů AKS	GitHub. com, API. GitHub. com	Tok je integrace třetí strany, která běží na uzlech. synchronizuje konfiguraci clusteru s privátním úložištěm GitHub.

Informace o požadovaných portech najdete v oficiální dokumentaci ke službě Azure.

1.1.7 požadavku

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

Vaše odpovědnosti

Kontrola konfigurace sítě a pravidel s vymezeným rozsahem vám umožní zpracovat alespoň každých šest měsíců. Tím se zajistí, že jsou bezpečnostní ujištění aktuální a platné. Nezapomeňte si projít tyto konfigurace:

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

Požadavek 1,2

Sestavování konfigurací brány firewall a směrovačů, které omezují připojení mezi nedůvěryhodnými sítěmi a všemi systémovými součástmi v datovém prostředí držitele.

Vaše odpovědnosti

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

Můžete také zvolit veřejný cluster, ale uvědomte si možné problémy s touto možností. Server rozhraní API bude přístupný pro Internet. Záznam DNS bude vždycky zjistitelný. Takže je nutné mít ovládací prvky, aby bylo udržování rozhraní API clusteru chráněno před veřejným přístupem. Přístup má těsné kontroly prostřednictvím Kubernetes řízení přístupu na základě role (RBAC), které se spárují s funkcí autorizovaných IP rozsahů AKS. Toto řešení se ale nedoporučuje u clusterů obsahujících regulované úlohy.

Při zpracování dat držitele karty (CHD) bude cluster potřebovat pracovat se sítěmi, které jsou považovány za důvěryhodné a nedůvěryhodné. V této architektuře se sítě hvězdicové v rámci hraničních úloh PCI-DSS 3.2.1 považují za důvěryhodné sítě.

Nedůvěryhodné sítě jsou sítě mimo tuto hraniční síť. Tato kategorie zahrnuje další centra a paprsky, které se mohou nacházet ve stejné infrastruktuře, ale jsou mimo hraniční zatížení, veřejný Internet, podnikovou síť nebo virtuální sítě v Azure nebo jiné cloudové platformy. V této architektuře není virtuální síť, která je hostitelem tvůrce imagí, nedůvěryhodná, protože nemá žádnou součást k přehrání při zpracování CHD. Interakce CDE s takovými sítěmi by měla být zabezpečená podle požadavků. Pomocí tohoto privátního clusteru můžete pomocí Azure Virtual Network, NSG a dalších integrovaných funkcí zabezpečit celé prostředí.

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

Požadavek 1.2.1

Omezte příchozí a odchozí provoz na to, který je nezbytný pro datové prostředí, a výslovně zakažte všechny ostatní přenosy.

Vaše odpovědnosti

V rámci návrhu služba Azure Virtual Network nemůže být přímo dosažitelná veřejným internetem. Veškerý příchozí (nebo příchozí) provoz musí projít směrovačem zprostředkujícího provozu. Všechny součásti v síti však mohou dosáhnout veřejných koncových bodů. Tento odchozí (nebo výstupní) provoz musí být explicitně zabezpečený, aby bylo možné pouze zabezpečit šifrovací šifry a TLS 1,2 nebo novější.

• Služba Azure Application Gateway Integrated WAF zachycuje všechny příchozí přenosy HTTP (S) a směruje provoz kontrolovaný do clusteru.

  Tento provoz může pocházet z důvěryhodných nebo nedůvěryhodných sítí. Application Gateway se zřídí v podsíti sítě paprsků a zabezpečená pomocí NSG. V případě přenosů dat v WAF pravidla povolují nebo zakazují a směrují provoz do nakonfigurovaného back-endu. Například Application Gateway chrání CDE zakázáním tohoto typu přenosu:

  • Veškerý provoz, který není šifrovaný protokolem TLS.
  • Provoz mimo rozsah portů pro komunikaci řídicích rovin z infrastruktury Azure.
  • Požadavky na testy stavu, které jsou odesílány jinými entitami než interní nástroj pro vyrovnávání zatížení v clusteru.

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

  Azure Firewall se zřídí v podsíti sítě rozbočovače. Aby bylo možné vyhovět Azure Firewall jako jeden výstupní bod, budou trasy definované uživatelem (udr) použity v podsítích, které jsou schopny generovat odchozí přenosy. To zahrnuje podsítě v nedůvěryhodných sítích, jako je třeba virtuální síť tvůrce imagí. Jakmile provoz dosáhne Azure Firewall, uplatní se několik pravidel s vymezeným oborem, které umožní provozu z konkrétních zdrojů přejít na konkrétní cíle.

  Další informace najdete v tématu použití Azure firewall k ochraně nasazení AKS (Azure Kubernetes Service).

Cluster bude potřebovat přístup k dalším službám přes veřejný Internet. Pokud používáte antimalwarový software jiného výrobce, bude nutné získat definice virů ze serveru prostřednictvím veřejného Internetu.

Interakce s koncovými body jiných služeb Azure je přes Internet. Ujistěte se, že jsou tyto interakce zabezpečené. Například v rámci pravidelných operací bude cluster potřebovat získat certifikáty ze spravovaného úložiště klíčů, vyžádat si obrázky z registru kontejneru atd. K provedení předchozích úkolů můžete použít soukromé odkazy pro jiné služby, například Azure Key Vault a Azure Container Registry.

Kromě pravidel brány firewall a privátních sítí jsou NSG toky také zabezpečeny prostřednictvím pravidel. Zde jsou některé příklady z této architektury, kde je CDE chráněna zakázáním provozu:

• Skupin zabezpečení sítě v podsítích, které mají fondy uzlů, odepře přístup SSH ke svým uzlům. Mít k dispozici proces pro nouzový přístup za běhu a zároveň přitom zachovává zásadu Odepřít – vše.
• NSG v podsíti, která má pole pro spuštění nástrojů pro správu, zamítne veškerý provoz kromě Azure bastionu v síti rozbočovače.
• Skupin zabezpečení sítě v podsítích, které mají privátní koncové body Azure Key Vault a Azure Container Registry, odmítne veškerý provoz kromě interního nástroje pro vyrovnávání zatížení a přenos dat prostřednictvím privátního propojení Azure.

Požadavek 1.2.2

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

Vaše odpovědnosti

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

Prostředky nasazení, jako jsou například šablony ARM, musí být řízeny zdrojem, takže máte historii všech změn. Shromažďovat informace z protokolů aktivit Azure, protokolů kanálů nasazení a protokolů nasazení Azure. Tyto zdroje vám pomůžou zachovat záznam nasazených assetů.

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

Požadavek 1.2.3

Umožňuje instalovat hraniční firewally mezi všemi bezdrátovými sítěmi a datovým prostředím držitele a nakonfigurovat tyto brány firewall tak, aby odepřely, nebo pokud je provoz potřebný pro obchodní účely, povolit jenom autorizovaný provoz mezi bezdrátovým prostředím a datovým prostředím držitele.

Vaše odpovědnosti

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

Obecně omezte přístup z místního provozu do sítě paprsků.

Požadavek 1,3

Zabrání přímému veřejnému přístupu mezi Internetem a všemi součástmi systému v datovém prostředí držitele.

Vaše odpovědnosti

Fondy uzlů clusteru AKS pracují v rámci virtuální sítě a 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žitím pravidel NSG v podsítích clusteru zajistíte blokování internetového provozu. Informace o řízeném přístupu najdete v části DMZ.

Cluster AKS má fondy systémových uzlů, které hostují kritické systémové lusky. I v fondech uzlů uživatelů existují lusky, které spouštějí další služby, které se účastní operací clusteru. například lusky můžou spustit tok, který synchronizuje konfiguraci clusteru s GitHubm úložištěm, nebo kontroler příchozího přenosu dat do lusků úloh. Bez ohledu na typ fondu uzlů musí být všechny uzly chráněny.

Další důležitou součástí systému je server rozhraní API, který se používá k provádění nativních úloh Kubernetes, jako je například údržba stavu clusteru a konfigurace. Výhodou použití privátního clusteru je, že koncový bod serveru API není ve výchozím nastavení zveřejněný. Informace o privátních clusterech najdete v tématu Vytvoření privátního clusteru služby Azure Kubernetes.

Interakce s ostatními koncovými body musí být také zabezpečeny. Jedním ze způsobů je omezení komunikace přes soukromou síť. Pokud třeba chcete, aby cluster vyčetl obrázky z Azure Container Registry přes privátní odkaz.

Požadavek 1.3.1

Implementujte DMZ, aby se omezil příchozí provoz jenom na součásti systému, které poskytují autorizované veřejně přístupné služby, protokoly a porty.

Vaše odpovědnosti

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

• Nekonfigurujte veřejné IP adresy na uzlech fondu uzlů.
• Před uzly nemusíte mít 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í.
• Vystavovat interní nástroje pro vyrovnávání zatížení pro Azure Application Gateway integrovaných s WAF.
• Všechny ovládací prvky sítě by měly podle potřeby určovat zdroj, cíl, port a omezení protokolu.
• Nezveřejňujte Server rozhraní API na Internet. Když cluster spustíte v privátním režimu, koncový bod se nezveřejňuje a komunikace mezi fondy uzlů a serverem rozhraní API je přes soukromou síť.

Uživatelé můžou implementovat hraniční síť pro ochranu clusterů AKS. Informace najdete 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 s clustery musí mít NSG v podsíti s interním nástrojem pro vyrovnávání zatížení. Nakonfigurujte pravidla tak, aby přijímala jenom provoz z podsítě, která má Azure Application Gateway integrována s WAF. V rámci clusteru AKS použijte Kubernetes NetworkPolicies k omezení příchozího provozu do lusků.

Požadavek 1.3.3

Implementujte opatření proti falšování identity, abyste zjistili a blokovali zablokované zdrojové IP adresy do vstupu do sítě.

Odpovědnosti Azure

Azure implementuje filtrování sítě, aby se zabránilo podvodnému provozu a omezil příchozí a odchozí provoz na komponenty důvěryhodných platforem.

1.3.4 požadavku

Nepovolujte neautorizovaný odchozí provoz z datového prostředí držitele na Internet.

Vaše odpovědnosti

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

• Vyjistěte, aby se veškerý odchozí (výstupní) provoz z clusteru AKS procházel prostřednictvím Azure Firewall. Musí mít uživatelsky definované trasy (udr) v 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 můžete omezit výstupní přenos dat z lusků.
• Použijte síť pro zpracování dalších zásad. Pokud například povolíte jenom přenosy šifrované protokolem TLS mezi lusky, může proxy server sítě služby zpracovat ověřování TLS. Tento příklad je znázorněn v této implementaci. Zástupné je nasazený jako proxy server.
• Zabraňte přidávání veřejných IP adres do sítí v rámci CDE, pokud není explicitně autorizovány podsítěmi, jako jsou například podsítě brány firewall.

AKS vyžaduje k přístupu k rovině řízení spravované v Azure nějaký veřejný internetový přístup. Cluster chce například odeslat metriky a protokoly do Azure Monitor. Můžete nastavit vymezená pravidla zadáním cíle zdrojového a cílového plně kvalifikovaného názvu domény nebo značek plně kvalifikovaného názvu domény. I když použití značek usnadňuje nastavování pravidel, některé značky mohou zahrnovat více cílů, než kolik potřebujete, a pravidlo tak bude mít v zásadě opravňující. Zkontrolujte značky a ujistěte se, že mají pouze správné cíle, které potřebujete. Zvažte použití explicitních pravidel pro přidaný ovládací prvek. Seznamte se s tím, že zahrnuje kompromisy při správě a složitosti, včetně odebrání pravidel, která už nejsou potřeba.

Podrobnosti najdete v tématu řízení odchozího provozu pro uzly clusteru ve službě Azure Kubernetes Service (AKS).

1.3.5 požadavku

Povoluje pouze "navázaná" připojení do sítě.

Odpovědnosti Azure

Azure implementuje filtrování sítě, aby se zabránilo podvodnému provozu a omezil příchozí a odchozí provoz na komponenty důvěryhodných platforem. Síť Azure je oddělená, aby se mohla oddělit provoz zákazníků od provozu správy.

1.3.6 požadavku

Umístěte součásti systému, které ukládají data držitele (například databáze) do zóny interní sítě, oddělené od DMZ a jiných nedůvěryhodných sítí.

Vaše odpovědnosti

Vystavte své systémy úložiště pouze přes privátní síť, například pomocí privátního propojení. Také omezte přístup z podsítí fondu uzlů, které to vyžadují. Udržujte si stav z clusteru a ve vlastní vyhrazené zóně zabezpečení.

1.3.7 požadavku

Nezveřejňujte soukromé IP adresy a informace o směrování na neoprávněných stranách.

Vaše odpovědnosti

Pro splnění tohoto požadavku není veřejný cluster AKS možností. Privátní cluster udržuje záznamy DNS z veřejného Internetu pomocí privátní zóny DNS. Je však stále možné vytvořit privátní cluster AKS s veřejnou adresou DNS. Proto se doporučuje explicitně zakázat tuto funkci nastavením enablePrivateClusterPublicFQDN na false , aby se zabránilo vyzrazení privátní IP adresy vaší plochy ovládacího prvku. Zvažte přidání Azure Policy pro vymáhání používání privátních clusterů bez veřejných záznamů DNS.

K směrování mezi podsítí, která má Azure Application Gateway integrována se službou WAF a podsítí s interním nástrojem pro vyrovnávání zatížení, použijte také privátní zónu DNS. Zajistěte, aby žádné odpovědi HTTP neobsahovaly v záhlaví nebo těle žádné soukromé informace IP. Zajistěte, aby protokoly, které by mohly obsahovat záznamy IP a DNS, nebyly vystaveny mimo provozní potřeby.

Služba Azure, která je propojená pomocí privátního propojení, nemá veřejný záznam DNS, který zveřejňuje vaše IP adresy. Vaše infrastruktura by měla optimální využití privátního propojení.

Požadavek 1,4

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

Vaše odpovědnosti

Privátní cluster je spravován rovinou ovládacího prvku AKS. Nemáte přístup k uzlům přímo. Pro úlohy správy budete muset použít nástroje pro správu, jako je kubectl, ze samostatného výpočetního prostředku. Možnost je použít k použití gapped pole pro přechod do vzduchu, kde můžete příkazy spustit. Příchozí a odchozí přenosy z pole pro skok musí být také omezené a zabezpečené. Pokud se k přístupu používá VPN, ujistěte se, že je klientský počítač spravovaný podnikovou zásadou a že jsou nastavené všechny zásady podmíněného přístupu.

V této architektuře se toto pole pro přechod nachází v samostatné podsíti v síti paprsků. Příchozí přístup k poli pro skok se omezuje pomocí NSG, který umožňuje přístup jenom prostřednictvím služby Azure bastionu přes SSH.

Pokud chcete spustit určité příkazy v poli pro skok, budete muset dosáhnout veřejných koncových bodů. Například koncové body, které spravuje rovina správy Azure. Odchozí provoz musí být zabezpečený. Podobně jako u jiných komponent v síti paprsků je odchozí provoz z pole skoku omezený pomocí UDR, který vynucuje přenos HTTPs prostřednictvím Azure Firewall.

Požadavek 1,5

Ujistěte se, že zásady zabezpečení a provozní postupy pro správu bran firewall jsou popsány, jsou používány a jsou známy všem postiženým stranám.

Vaše odpovědnosti

Je důležité, abyste zachovali důkladnou dokumentaci k procesu a zásadám. To platí zejména při správě Azure Firewall pravidel, která segmentují cluster AKS. Provozní prostředí, která jsou na něm podporovaná, se musí informovat, informovat a motivovaní, aby podporovaly bezpečnostní záruky. To je důležité hlavně pro uživatele s účty, kterým jsou udělena rozsáhlá oprávnění správce.

Požadavek 2

Pro systémová hesla a další parametry zabezpečení nepoužívejte výchozí nastavení dodavatele.

Požadavek 2,1

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

Vaše odpovědnosti

Je potřeba změnit výchozí nastavení poskytovaná dodavateli. Výchozím nastavením jsou běžné vektory útoku a zajištění náchylného systému k útokům. Tady je několik důležitých informací:

• Zakažte přístup správce k registru kontejneru.
• Zajistěte, aby pole pro přesun a agenti sestavení sledovaly postupy správy uživatelů a odebrali potřebné systémové uživatele.
• Nevytvářejte ani neposkytují přístup ke klíčům SSH k uzlům pro uživatele s oprávněními správce. Pokud je nouzový přístup nutný, použijte proces Azure Recovery k získání přístupu za běhu.

Odpovědnosti Azure

Azure Active Directory má zásady hesel, které jsou vynuceny na nových heslech dodaných uživateli. Pokud změníte heslo, bude vyžadováno ověření staršího hesla. Hesla pro resetování správců se musí po následném přihlášení změnit.

Požadavek 2.1.1

Pro bezdrátová prostředí připojená k datovému prostředí držitele nebo odesílající data držitele změňte výchozí nastavení pro bezdrátového dodavatele při instalaci, mimo jiné jako výchozí bezdrátové šifrovací klíče, hesla a řetězce komunity SNMP.

Vaše odpovědnosti

Tato architektura a implementace není navržená tak, aby v cloudových transakcích přes bezdrátové připojení probíhají místní nebo podniková síť. Informace najdete v pokynech v oficiálním standardu PCI-DSS 3.2.1.

Požadavek 2,2

Vývoj standardů konfigurace pro všechny součásti systému.

Vaše odpovědnosti

Implementujte doporučení v srovnávacím testu zabezpečení Azure. Poskytuje jediné konsolidované zobrazení doporučení zabezpečení Azure, které pokrývá oborové architektury, jako jsou CIS, NIST, PCI-DSS 3.2.1 a další. Pomocí funkcí Azure Security Center a Azure Policy můžete sledovat standardy. Výchozí iniciativou pro Azure Security Center je Azure Security test. Zvažte vytvoření dalších automatizovaných kontrol v Azure Policy a řešení zabezpečení klienta Azure (AzTS).

Zdokumentujte požadovaný stav konfigurace pro všechny součásti v CDE, zejména pro uzly AKS, pole pro přesun, agenty sestavení a další komponenty, které pracují s clusterem.

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

Zodpovědnost Azure

Azure poskytuje standardy konfigurace zabezpečení, které jsou konzistentní s normami, které přijaly v souladu s oborem posílení. Normy jsou přezkoumány nejméně jednou ročně.

Požadavek 2.2.1

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

Vaše odpovědnosti

Klíčovou strategií je poskytnutí požadované úrovně segmentace. Jedním ze způsobů je nasadit komponenty v rámci oboru a mimo rozsah do samostatných clusterů. Tím se rozumí, ž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é umístění všech součástí ve sdíleném clusteru. Použijte strategie segmentace k údržbě oddělení. Například mají samostatné fondy uzlů v rámci clusteru.

V referenční implementaci je druhý přístup znázorněn u aplikace mikroslužeb nasazené do jednoho clusteru. Aplikace má dvě sady služeb: jedna sada má v oboru lusky a druhá je mimo rozsah. Obě sady jsou rozdělené mezi dva fondy uživatelských uzlů. Při použití Kubernetesých chuti jsou v oboru a mimo rozsah lusky nasazeny do samostatných fondů uzlů a nikdy nesdílejí virtuální počítač uzlu.

Pro technologie kontejneru je toto segmentace k dispozici ve výchozím nastavení, protože pouze jedna instance kontejneru je zodpovědná za jednu funkci v systému.

Zatížení by mělo používat pod spravovanou identitou. Nesmí dědit žádné identity na úrovni clusteru ani uzlů.

Místo toho, aby bylo možné v případě potřeby využít úložiště v uzlu (v clusteru), použijte externí úložiště. Udržujte clustery, které jsou rezervované výhradně pro práci, kterou je třeba provést v rámci operace zpracování dat držitele karty. Přesuňte operace mimo rozsah mimo cluster. Tento návod se vztahuje na agenty sestavení, nesouvisející úlohy nebo aktivity, jako je například pole s odkazem v rámci clusteru.

Požadavek 2.2.2

Povolte pouze nezbytné služby, protokoly, démony atd., jak je vyžadováno pro funkci systému.

Vaše odpovědnosti

Než je povolíte, přečtěte si funkce a důsledky. Výchozí nastavení můžou zahrnovat funkce, které nepotřebujete, a tyto funkce můžou potřebovat zobrazitelné úlohy. Příkladem jsou šifry ve výchozích zásadách SSL pro Azure Application Gateway. Ověřte, jestli je zásada přesnou povolující. Doporučujeme vytvořit vlastní zásadu tím, že vyberete pouze šifry, které potřebujete.

Pro součásti, kde máte úplnou kontrolu, odeberte z imagí všechny nepotřebné systémové služby (například pole odkazů a agenty sestavení).

U komponent, kde máte jenom viditelnost, jako jsou například uzly AKS, zdokumentujte, co Azure na uzlech nainstalují. Zvažte použití DaemonSets k poskytnutí dalšího auditování potřebného pro tyto součásti ovládané cloudem.

Požadavek 2.2.3

Implementujte další funkce zabezpečení pro všechny požadované služby, protokoly nebo procesy, které se považují za nezabezpečené.

Vaše odpovědnosti

Application Gateway má integrovaný WAF a vyjednává metodu handshake TLS pro požadavek odeslanou do veřejného koncového bodu a povoluje pouze zabezpečené šifry. Referenční implementace podporuje jenom TLS 1,2 a schválená šifry.

Předpokládejme, že máte starší zařízení, které potřebuje pracovat s CDE prostřednictvím Azure Application Gateway. V takovém případě Application Gateway nutné povolit nezabezpečený protokol. Zdokumentujte tuto výjimku a sledujte, pokud se tento protokol používá za starším zařízením. Zakažte tento protokol ihned po ukončení starší verze této interakce.

Application Gateway také nesmí odpovídat 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 s Application Gateway.

Pokud zatížení v clusteru nemůže vyhovovat zásadám organizace v rámci profilů dodržování předpisů zabezpečení nebo jiných ovládacích prvků (například omezení a kvóty), ujistěte se, že je tato výjimka dokumentována. Aby bylo zajištěno, že je provedena pouze očekávaná funkčnost, je nutné monitorovat.

Požadavek 2.2.4

Nakonfigurujte parametry zabezpečení systému, abyste zabránili zneužití.

Vaše odpovědnosti

Všechny služby Azure používané v architektuře musí splňovat doporučení, která poskytuje srovnávací testy zabezpečení Azure. Tato doporučení poskytují výchozí bod pro výběr konkrétního nastavení konfigurace zabezpečení. Také Porovnejte konfiguraci s implementací standardních hodnot této služby. Další informace o standardních hodnotách zabezpečení najdete v tématu základní hodnoty zabezpečení pro Azure.

Otevřený řadič pro přístup agenta zásad funguje ve spojení s Azure Policy k detekci a zabránění v neúspěšných konfiguracích v clusteru. Předpokládejme, že existuje zásada organizace, která na uzlech nepovoluje přidělování veřejných IP adres. Pokud je takové přidělení zjištěno, je označeno pro audit nebo odepřeno na základě akce zadané v definici zásady.

Na úrovni infrastruktury můžete použít omezení pro typ a konfiguraci prostředků Azure. Tyto případy můžete zabránit pomocí Azure Policy. V této referenční implementaci je k dispozici zásada, která odepře vytváření clusterů AKS, které nejsou privátní.

Ujistěte se, že jsou zdokumentovány všechny výjimky.

Odpovědnosti Azure

Azure zajišťuje, že jenom autorizovaní zaměstnanci můžou nakonfigurovat řízení zabezpečení platformy Azure pomocí Multi-Factor Access Controls a dokumentovaného podnikového potřeb.

2.2.5 požadavku

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

Vaše odpovědnosti

Neinstalujte software do polí s odkazy ani do agentů sestavení, kteří se nepodílejí na zpracování transakce, nebo poskytněte požadavky na dodržování předpisů, jako jsou například agenti zabezpečení. Toto doporučení platí také pro entity clusteru, například DaemonSet a lusky. Zajistěte, aby byly 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 pro správu ke clusteru by se měl provádět pomocí konzoly nástroje. Nezveřejňujte řídicí plochu clusteru.

Odpovědnosti Azure

Azure zajišťuje, aby při přístupu k infrastruktuře hypervisoru bylo vynutilo použití silné kryptografie. zajišťuje, aby zákazníci, kteří používají Microsoft Azure Portál pro správu, mohli přistupovat ke svým službám nebo IaaS konzolám pomocí silné kryptografie.

Požadavek 2,4

Udržujte inventář systémových komponent, které jsou v oboru 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ůžou v klasifikaci dat a označují, jestli je služba v oboru nebo mimo rozsah. Označování nejpreciznější vám umožní zadávat dotazy na prostředky, uchovávat inventář, sledovat náklady a nastavovat upozornění. Také pravidelně Udržujte snímek této dokumentace.

Vyhněte se označování prostředků v oboru nebo mimo rozsah na podrobné úrovni. Vzhledem k tomu, že se řešení vyvíjí, můžou být prostředky mimo rozsah v oboru, i když nepřímo komunikují nebo sousedí s daty držitele karty. Tyto prostředky podléhají auditu a můžou být součástí reprezentativního vzorku během auditu. Zvažte označení na vyšší úrovni, na úrovni předplatného a clusteru.

Informace o aspektech označování najdete v průvodci rozhodováním ohledně 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 inventář sestav.

Požadavek 2.5

Zajistěte, aby zásady zabezpečení a provozní postupy pro správu výchozích hodnot dodavatelů a dalších parametrů zabezpečení byly zdokumentovány, používejte 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. Pracovníci by měli být vytrénování v bezpečnostních funkcích a nastaveních konfigurace jednotlivých prostředků Azure. Lidé, kteří provozují regulovaná prostředí, musí být pouční, informovaní a podnícení, aby podpořili záruky zabezpečení. To je zvlášť důležité pro účty správců, které mají udělená široká oprávnění správce.

Požadavek 2.6

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

Vaše odpovědnosti

Azure poskytuje záruky zabezpečení pro hostované prostředí, které se sdílí. Důrazně doporučujeme používat vyhrazené hostitele pro uzly AKS. To znamená, že výpočetní prostředky by měly být v modelu jednoho tenanta.

Další kroky

Ochrana uložených dat držitelů karet. Šifrování přenosu dat držitelů karet mezi otevřenými veřejnými sítěmi