Architektura clusteru s AKS regulovaným pro PCI-DSS 3.2.1 (část 2 z 9)

Tento článek popisuje referenční architekturu pro cluster Azure Kubernetes Service (AKS), který spouští úlohu v souladu se standardem PCI-DSS 3.2.1 (Payment Card Industry Data Security Standard). Tato architektura se zaměřuje na infrastrukturu, a ne na úlohu PCI-DSS 3.2.1.

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

Doporučení a příklady se extrahují z této doprovodné referenční implementace:

GitHub: cluster Azure Kubernetes Service standardních hodnot (AKS) pro regulovaný úlohy ukazuje regulovanou infrastrukturu. Tato implementace poskytuje aplikaci mikroslužeb. Součástí je , která vám pomůže prožít infrastrukturu a znázorní síťové a bezpečnostní prvky. Aplikace nepředstavuje ani neimplementuje skutečnou PCI DSS úlohy.

Tato síťová architektura je založená na topologii centra s paprsky. Centrální virtuální síť obsahuje bránu firewall pro řízení výchozího provozu, provoz brány z místních sítí a třetí síť pro přístup ke clusteru SRE. Existují dvě paprskové virtuální sítě. Jeden paprsek obsahuje cluster AKS, který je součástí prostředí pro držitele karet (CDE), a hostuje PCI DSS úlohy. Druhý paprsek vytváří image virtuálních počítačů používané pro řízený přístup SRE k prostředí.

Komponenty

Tady jsou hlavní komponenty použité v této architektuře. Pokud tyto služby ještě nevíte, najdete odkazy na dokumentaci k produktu v části Související služby Azure.

Azure Firewall

Instance brány firewall zabezpečuje odchozí síťový provoz. Bez této vrstvy zabezpečení může tok komunikovat se škodlivou službou třetí strany, která by mohla exfiltrovat citlivá firemní data.

Azure Bastion

Základní architektura poskytovala podsíť pro Azure Bastion, ale nezřídí prostředek. Tato architektura přidá Azure Bastion v podsíti. Poskytuje zabezpečený přístup k jump boxu.

Azure Image Builder

Zřízená v samostatné virtuální síti. Vytvoří image virtuálních počítače se základním zabezpečením a konfigurací. V této architektuře je přizpůsobená k vytváření zabezpečených imagí uzlů pomocí předinstalovaných nástrojů pro správu, jako jsou Azure CLI, a kubectl Flux CLI.

Azure Virtual Machine Scale Sets pro instance jump boxu

Paprsková síť má další výpočetní prostředky pro jump box. Tato škálovací sada je určena jako řízený přístupový bod pro spouštění nástrojů v clusteru AKS, například kubectl podle potřeby.

Azure Application Gateway s integrovaným Web Application Firewall (WAF)

Azure Application Gateway zatížení ve vrstvě 7. WAF zabezpečuje příchozí provoz před běžnými útoky na webový provoz. Instance má konfiguraci veřejné front-endové IP adresy, která přijímá požadavky uživatelů.

Azure Kubernetes Service (AKS)

Hostitelská infrastruktura, která je klíčovou součástí prostředí CDE (CardHolder Data Environment). Cluster AKS je nasazený jako privátní cluster. Proto server rozhraní Kubernetes API není vystavený veřejnému internetu a provoz na server rozhraní API je omezený na vaši privátní síť.

Úlohy ACR

Poskytuje automatizovaný způsob vytváření a údržby imagí kontejnerů.

Azure Key Vault

Ukládá a spravuje tajné kódy potřebné pro operace clusteru, jako jsou certifikáty a šifrovací klíče.

Konfigurace clusteru

Tady je několik významných změn oproti základní architektuře:

Segmentace fondu uzlů

V této architektuře má cluster dva fondy uzlů uživatele a jeden fond systémových uzlů. Volba výpočetních prostředků pro fondy uzlů zůstává stejná. Každý fond uzlů se nachází ve vyhrazené podsíti a poskytuje další hranici izolace sítě mezi úrovněmi výpočetních prostředků.

PCI-DSS 3.2.1 vyžaduje izolaci úloh PCI od ostatních úloh z hlediska provozu a připojení.

• V oboru: Úloha PCI, prostředí, ve kterém se nachází, a operace.

• Mimo rozsah: Jiné úlohy, které mohou sdílet služby, ale jsou izolované od součástí v oboru.

Klíčovou strategií je zajistit požadovanou úroveň oddělení. Preferovaným způsobem je nasadit součásti v rámci oboru a mimo rozsah v samostatných clusterech. Na straně dolů se zvyšují náklady na přidanou infrastrukturu a režijní náklady na údržbu. Tato implementace kvůli zjednodušení vyhledá všechny komponenty ve sdíleném clusteru. Pokud se rozhodnete postupovat podle tohoto modelu, použijte přísnou strategii segmentace v clusteru. Bez ohledu na to, jak se rozhodnete zachovat oddělení, si uvědomte, že s tím, jak se vaše řešení vyvíjí, se některé mimo oborové komponenty můžou stát v rozsahu.

V referenční implementaci je druhý přístup předveden pomocí aplikace mikroslužeb nasazené do jednoho clusteru. Úlohy v oboru a mimo rozsah jsou segmentovány do dvou samostatných fondů uzlů uživatele. Aplikace má dvě sady služeb: Jedna sada má pody v oboru a druhá je mimo rozsah. Obě sady jsou rozložené mezi dva fondy uzlů uživatele. S použitím taintů Kubernetes se pody v oboru a mimo rozsah nasadí do samostatných uzlů a nikdy nesdílí virtuální počítač uzlu ani prostor síťových IP adres.

Kontroler příchozího přenosu dat

Kontroler příchozího přenosu dat Kubernetes uvnitř clusteru se změnil na NGINX. Ve základní architektuře se používal Traefik. Tato změna ukazuje, že tuto komponentu je možné změnit na základě požadavků vašich úloh.

Privátní server rozhraní Kubernetes API

Základní architektura nasadila cluster AKS ve veřejném režimu. To znamená, že veškerá komunikace se serverem rozhraní Kubernetes API spravovaným službou AKS je přes veřejný internet. V této architektuře to není přijatelné, protože PCI-DSS 3.2.1 zakazuje veřejné vystavení žádným systémovým komponentám. V této regulovaný architektuře se cluster nasazovat jako privátní cluster. Síťový provoz na server rozhraní Kubernetes API je omezený na vaši privátní síť. Server rozhraní API je zveřejněný prostřednictvím privátního koncového bodu v síti clusteru. Zabezpečení se dále vylepšuje použitím skupin zabezpečení sítě a dalších integrovaných funkcí. Ty jsou popsány v části Konfigurace sítě.

Zabezpečení podů

Při popisu potřeb zabezpečení úloh používejte pro securityContext kontejnery relevantní nastavení. To zahrnuje základní nastavení, jako fsGroup je , a nastavení na hodnotu false runAsUser / runAsGroup allowPrivilegeEscalation (pokud není potřeba). Pište jasně o definování a odebírání možností Linuxu a o definování možností SELinuxu v seLinuxOptions systému .

V manifestech nasazení se vyhněte odkazování na image podle jejich značek. Místo toho použijte skutečné ID image. Tímto způsobem můžete spolehlivě mapovat výsledky prohledávání kontejnerů se skutečným obsahem spuštěný ve vašem clusteru. Můžete ho vynutit prostřednictvím Azure Policy, aby název image zahrnoval vzor ID obrázku do povoleného regulárního výrazu. Pokud používáte instrukci Dockerfile, postupujte také podle těchto FROM pokynů.

Konfigurace sítě

Paprsky centra jsou všechny nasazené v samostatných virtuálních sítích, z nichž každá je ve svém adresní prostoru privátních adres. Ve výchozím nastavení není mezi dvěma virtuálními sítěmi povolen žádný provoz. V rámci sítě se segmentace používá vytvořením podsítí.

Požadovanou úroveň řízení poskytuje kombinace různých služeb a funkcí Azure a nativních konstruktorů Kubernetes. Tady je několik možností, které se v této architektuře používají.

Zabezpečení podsítě prostřednictvím skupin zabezpečení sítě (skupin zabezpečení sítě)

Je k dispozici několik skupin zabezpečení sítě řízení toku v clusteru a z něj. Tady je několik příkladů:

• Fondy uzlů clusteru se nacházejí ve vyhrazených podsítích. Pro každou podsíť jsou k dispozici skupin zabezpečení sítě, které blokují přístup SSH k virtuálním počítačům uzlů a umožňují provoz z virtuální sítě. Provoz z fondů uzlů je omezen na virtuální síť.
• Veškerý příchozí provoz z Internetu je zachycen službou Azure Application Gateway. Například pravidla NSG zajišťují, že:
  • V nástroji je povolený jenom provoz HTTPS.
  • Provoz z řídicí plochy Azure je povolený.
    Podrobnosti najdete v tématu Povolení přístupu k několika zdrojovým IP adresám.
• V podsítích, které mají agenty Azure Container Registry, skupin zabezpečení sítě povoluje pouze nezbytný odchozí provoz. provoz je například povolený pro Azure Key Vault, Azure Active Directory, Azure Monitor a další služby, se kterými musí registry kontejneru komunikovat.
• Podsíť s polem pro skok je určena pro operace správy. Pravidlo NSG povoluje jenom přístup SSH z Azure bastionu v centru a omezená odchozí připojení. Pole s odkazy nemají univerzální přístup k Internetu a jsou řízena v podsíti NSG i Azure Firewall.

Jak jsou nasazené vaše úlohy, agenti zabezpečení systému a další komponenty, přidejte další pravidla NSG, která vám pomůžou definovat typ provozu, který se má povolit. Provoz by neměl procházet tyto hranice podsítí. Vzhledem k tomu, že každý fond uzlů žije ve vlastní podsíti, Sledujte vzory přenosů a pak použijte konkrétnější pravidla.

Zabezpečení pod a pod pomocí zásad sítě

Tato architektura se pokusí implementovat co nejvíc principů "nulového vztahu důvěryhodnosti společnosti Microsoft".

Příklady nulových důvěryhodných sítí jako koncept jsou znázorněné v části implementace v a0005-i a0005-o oborech názvů a uživatelem poskytovaných oborů. U všech oborů názvů úloh by měl být použit omezující NetworkPolicy. Definice zásad budou záviset na luskech spuštěných v těchto oborech názvů. Ujistěte se, že jste provedli účetní testy připravenosti, liveliness a Startup a zároveň jste vyplaceni metriky shromážděné agentem Log Analytics. Zvažte standardizaci na portech napříč vašimi úlohami, abyste mohli zajistit konzistentní NetworkPolicy a Azure Policy pro povolené porty kontejnerů.

V některých případech to není pro komunikaci v rámci clusteru praktické. Ne všechny obory názvů zadané uživatelem můžou používat síť s nulovou důvěryhodností (například cluster-baseline-settings nemůže použít).

Šifrování TLS

Základní architektura poskytuje přenos zašifrovaný přes protokol TLS do řadiče příchozího přenosu dat v clusteru, ale komunikace pod ní je nejasná. V této architektuře se TLS rozšiřuje na provoz s více procesory s ověřením certifikační autority (CA). Tento protokol TLS zajišťuje síť, která vynutila připojení a ověřování mTLS před povolením komunikace.

Implementace používá mTLS. podporu mTLS lze implementovat s sítí služby nebo bez ní. Pokud používáte síť, ujistěte se, že je kompatibilní s vystavitelem certifikátu dle vašeho výběru. Tato implementace používá síť s otevřenými službami.

Kontroler příchozího přenosu v této implementaci používá certifikát se zástupným znakem pro zpracování výchozího provozu, když prostředek příchozího přenosu dat neobsahuje konkrétní certifikát. To může být přijatelné, ale pokud zásady vaší organizace nepovolují používání certifikátů se zástupnými znaky, může být potřeba upravit kontroler příchozího přenosu dat, aby nepoužíval certifikát se zástupnými znaky.

Azure Key Vault omezení sítě

Všechny tajné kódy, klíče a certifikáty jsou uložené v Azure Key Vault. Key Vault zpracovává úlohy správy certifikátů, jako je například rotace. Komunikace s Key Vault je prostřednictvím privátního propojení Azure. Záznam DNS přidružený k Key Vault je v privátní zóně DNS, aby se nedal přeložit z Internetu. I když to zvyšuje zabezpečení, existují určitá omezení.

Azure Application Gateway nepodporuje zdrojové certifikáty TLS pro naslouchací proces HTTP z instancí Key Vault, které jsou vystaveny pomocí privátního odkazu. Implementace proto nasadí Key Vault v hybridním modelu. Pořád používá privátní propojení pro připojení, která ho podporují, ale také umožňuje veřejný přístup k Application Gateway integraci. Pokud tento hybridní přístup není pro vaše nasazení vhodný, přesuňte proces správy certifikátů na Application Gateway. Tím se přidají režijní náklady na správu, ale instance Key Vault bude zcela izolovaná. Informace najdete tady:

• Integrace s Azure Application Gateway a Key Vault
• Vytvoření aplikační brány s ukončením TLS pomocí Azure CLI.

Ochrana před útoky DDoS

Povolte Azure DDoS Protection Standard pro virtuální sítě s podsítí, která obsahuje Application Gateway s veřejnou IP adresou. Tím se zabezpečí infrastruktura a zatížení před hromadnými podvodnými požadavky. Tyto požadavky můžou způsobit přerušení služby nebo maskovat jiný souběžný útok. Azure DDoS se věnuje značným nákladům a obvykle se účtuje napříč mnoha úlohami, které zahrnují mnoho IP adres. Pracujte s týmem vaší sítě, abyste mohli koordinovat pokrytí vašich úloh.

Správa přístupu k identitám

Definujte role a nastavte zásady přístupu podle požadavků této role. Role mapování na Kubernetes akce jsou vymezené co nejpřesněji. Vyhněte se rolím, které přesahují více funkcí. Pokud je více rolí vyplněno jednou osobou, přiřaďte tuto osobu všem rolím, které jsou relevantní pro ekvivalentní funkce úlohy. Takže i když je jedna osoba přímo odpovědná za cluster i pro zatížení, vytvořte své Kubernetes, ClusterRoles jako kdyby existovali různí jednotlivci. Pak přiřaďte tuto jednotlivou roli všem relevantním rolím.

Minimalizujte stálý přístup, zejména u účtů s vysokým dopadem, jako jsou interakce SRE/OPS s vaším clusterem. Rovina ovládacího prvku AKS podporuje JIT (just-in-time) služby Azure AD Privileged Access Management (JIT). Zásady podmíněného přístupu můžou poskytnout další vrstvy požadovaného ověřování ověřování pro privilegovaný přístup na základě pravidel, která vytvoříte.

Další informace o použití PowerShellu ke konfiguraci podmíněného přístupu najdete v tématu podmíněný přístup Azure AD.

Šifrování disků

Pokud navrhujete šifrování pro neaktivní neaktivní data, zvažte disky úložiště, virtuální počítače uzlu agenta AKS, další virtuální počítače a dočasné disky a operační systémy.

Storage disky

ve výchozím nastavení jsou Azure Storage disky zašifrované v klidovém stavu pomocí klíčů spravovaných microsoftem. Pokud používáte nedočasný disk s operačním systémem nebo pokud chcete přidat datové disky, doporučujeme, abyste pro kontrolu šifrovacích klíčů používali klíče spravované zákazníkem. Zašifrujte mimo vrstvu úložiště a zapište jenom zašifrovaná data do úložného média. Ujistěte se také, že klíče nikdy nesousedí s vrstvou úložiště.

další informace najdete v tématu Bing vlastních klíčů (BYOK) s disky Azure.

Zvažte použití BYOK pro všechny další disky, které by mohly komunikovat s clusterem, jako jsou například pole s odkazy v Azure bastionu. Zvolíte-li možnost BYOK, bude položka SKU vybraná pro virtuální počítače a regionální dostupnost omezená, protože tato funkce není podporována ve všech SKU nebo oblastech.

Hostitelé virtuálních počítačů

Doporučujeme povolit funkci šifrování na hostiteli. Tím se zašifruje hostitel virtuálního počítače a všechny dočasné operační systémy nebo datové disky, které jsou uložené v mezipaměti hostitele virtuálních počítačů. Přečtěte si další informace o podpoře virtuálních počítačů pro šifrování založené na hostiteli.

Tato funkce se rozšiřuje na data uložená na hostiteli virtuálního počítače v uzlech agenta AKS prostřednictvím funkce šifrování založené na hostiteli . Podobně jako BYOK může tato funkce omezit možnosti vaší SKU a oblasti virtuálního počítače.

Tyto funkce můžete vyhovět prostřednictvím Azure Policy.

Zálohy clusteru (stav a prostředky)

Pokud vaše úloha vyžaduje úložiště v clusteru, máte robustní a zabezpečený proces zálohování a obnovení. Zvažte služby, jako je například Azure Backup (pro disky Azure a soubory Azure) pro zálohování a obnovení PersistantVolumeClaim . V případě, že systém zálohování podporuje nativní prostředky Kubernetes, existují výhody. Můžete doplnit primární metodu, která cluster sloučí do známého stavu, se systémem zálohování pro důležité techniky obnovení systému. Může například pomáhat při odhlašování a změnách stavu systému v průběhu času na úrovni prostředků Kubernetes.

Procesy zálohování musí klasifikovat data v rámci zálohování do clusteru nebo z nich mimo tento cluster. Pokud jsou data v oboru pro PCI DSS 3.2.1, rozšíříte hranice dodržování předpisů tak, aby zahrnovaly životní cyklus a cíl zálohování, který bude mimo cluster. Zálohy můžou být vektorem útoku. Při návrhu zálohování zvažte Zeměpisná omezení, neaktivní šifrování, řízení přístupu, role a zodpovědnosti, auditování, časovou dostupnost a ochranu proti falšování.

U systémů zálohování v clusteru se očekává, že se během svých operací spustí s vysokými oprávněními. Vyhodnoťte riziko a výhodu zavedení agenta zálohování do clusteru. Překrývá schopnost agenta jiné řešení pro správu v clusteru? Jaká je minimální sada nástrojů, kterou potřebujete k provedení této úlohy bez rozšíření prostoru pro útoky.

Azure Policy hlediska

U aplikovaných zásad Azure se obvykle nepoužívají nastavení úlohy. V implementaci používáme cluster Kubernetes pod standardy s omezeným zabezpečením pro iniciativu pro úlohy se systémem Linux, což neumožňuje ladění nastavení. Zvažte možnost exportovat tuto iniciativu a přizpůsobit její hodnoty pro konkrétní úlohu. Můžete zahrnout všechny zásady Azure na serveru gatekeeper deny v rámci jedné vlastní iniciativy a všechny audit zásady Azure v rámci jiné iniciativy. V takovém případě zařadí zablokované akce do kategorií jenom ze zásad pouze informací.

Zvažte zahrnutí kube-system gatekeeper-system oborů názvů a do zásad v zásadách auditu pro přidanou viditelnost. Zahrnutí těchto oborů názvů v zásadách odepření může způsobit selhání clusteru z důvodu nepodporované konfigurace.

Šifrování dat můžete vynutilit nastavením některých upozornění Azure Policy. Můžete například vyhovět BYOK s výstrahou, která detekuje clustery, které nejsou diskEncryptionSetID v prostředku clusteru. Další zásada může zjistit, jestli je povolené šifrování Host-Based zapnuté agentPoolProfiles . Implementace reference nepoužívá žádné disky v clusteru a disk operačního systému je dočasný. Obě tyto ukázkové zásady jsou zavedeny jako připomenutí funkce zabezpečení. Zásady jsou nastaveny na audit , nikoli block .

Správa imagí

Pro vaše úlohy používejte základní image bez distribuce. U těchto imagí je oblast zabezpečení minimalizována, protože se odeberou doplňkové image, například prostředí a správci balíčků. Výhodou je snížená míra přístupů na CVE.

Azure Container Registry podporuje bitové kopie, které splňují specifikaci formátu rozhraní OCI (Open container Initiative). V kombinaci s řadičem pro přijímání, který podporuje ověřování podpisů, můžete zajistit, že budete spouštět jenom image, které jste si zaregistrovali pomocí svých privátních klíčů. Existují open source řešení, jako jsou SSE Connaisseur nebo IBM Portieris, které tyto procesy integrují.

Chraňte image kontejnerů a jiné artefakty rozhraní OCI, protože obsahují duševní vlastnictví organizace. Používejte klíče spravované zákazníkem a Zašifrujte obsah registrů. Ve výchozím nastavení jsou data v klidovém stavu zašifrovaná pomocí klíčů spravovaných službou, ale klíče spravované zákazníkem se někdy vyžadují ke splnění standardů dodržování předpisů regulativními předpisy. Uložte klíč do spravovaného úložiště klíčů, jako je Azure Key Vault. Vzhledem k tomu, že klíč vytvoříte a vlastníte, zodpovídáte za operace související s životním cyklem klíčů, včetně rotace a správy. Další informace najdete v tématu šifrování registru pomocí klíče spravovaného zákazníkem.

Provozní přístup k serveru rozhraní Kubernetes API

Můžete omezit příkazy spouštěné proti clusteru, aniž byste museli vytvářet provozní procesy na základě seznamů odkazů. Pokud máte platformu pro automatizaci IT, která je na platformě IAM, využijte předdefinované akce k řízení a auditování typu akcí.

Agenti sestavení

Agenti kanálu by měli být pro regulovaný cluster mimo rozsah, protože procesy sestavení můžou být vektory hrozeb. I když je běžné používat Kubernetes jako infrastrukturu elastického agenta sestavení, nespouštějte tento proces v rámci hranice modulu runtime řízených úloh. Vaše agenti sestavení by neměli mít přímý přístup ke clusteru. Například udělte jenom agentům sestavení přístup k síti Azure Container Registry, aby mohli nabízet image kontejnerů, grafy Helm a tak dále. Pak nasazení proveďte pomocí GitOps. V rámci běžné praxe by pracovní postupy sestavení a vydání neměly mít přímý přístup k rozhraní API clusteru Kubernetes (nebo jeho uzlům).

Monitorování operací

Aktivity v clusteru

V rámci clusteru v omsagent systému kube-system je agent kolekce Log Analytics. Shromažďují telemetrii, stdout stderr vybírají kontejnery a protokoly a shromažďují metriky Prometheus. Nastavení kolekce můžete ladit aktualizací container-azm-ms-agentconfig.yaml souboru ConfigMap. V této referenční implementaci je protokolování povolené napříč kube-system všemi vašimi úlohami. Ve výchozím nastavení kube-system je vyloučena z protokolování. Ujistěte se, že upravujete proces shromažďování protokolů, abyste dosáhli cíle nákladů na rovnováhu, a SRE efektivitu při kontrole protokolů a požadavků na dodržování předpisů.

Monitorování zabezpečení

Pomocí Azure Security Center můžete zobrazit a opravit doporučení zabezpečení. Zobrazit také výstrahy zabezpečení pro vaše prostředky. Povolte plány Azure Defenderu, které se vztahují na různé komponenty datového prostředí držitele.

Integrujte protokoly, abyste si mohli efektivně kontrolovat, analyzovat a dotazovat data. Azure nabízí několik technologických možností. K zápisu protokolů do pracovního prostoru Log Analytics můžete použít Azure Monitor. Další možností je integrovat data do řešení SIEM (Information Security and Event Management), jako je například Azure Sentinel.

Podle požadavků standardu jsou všechny pracovní prostory Log Analytics nastavené na dobu uchování 90 dní. Zvažte nastavení průběžného exportu pro dlouhodobé ukládání. V datech protokolu neukládejte citlivé informace. Ujistěte se, že přístup k archivovaným datům protokolu podléhá stejným úrovním řízení přístupu jako k nedávným datům protokolu.

kompletní perspektivu najdete v tématu Azure Security Center průvodce připojováním Enterprise. Tato příručka řeší registraci, exporty dat do řešení SIEM, reakci na výstrahy a sestavování automatizace pracovních postupů.

Související služby Azure

Tady jsou odkazy na dokumentaci k funkcím některých klíčových součástí této architektury.

• Azure Kubernetes Service (AKS)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• Škálovací sady virtuálních počítačů Azure
• Azure Application Gateway s integrovanými firewally webových aplikací (WAF)
• Azure Container Registry úlohy
• Azure Key Vault

Další

Nainstalujte a udržujte konfiguraci brány firewall pro ochranu dat držitele. Pro systémová hesla a další parametry zabezpečení nepoužívejte výchozí nastavení dodavatele.