Dobře navržená architektura Azure je sada hlavních principů, které je možné použít k vyhodnocení řešení prostřednictvím pilířů kvality efektivity architektury:
Tento článek končí touto řadou. Přečtěte si úvod.
Tyto pokyny uvedené v této sérii zahrnují dobře navržené principy ve všech možnostech návrhu. Tento článek shrnuje tyto volby. Základní cluster Azure Kubernetes Service (AKS) pro implementaci regulovaných úloh gitHubu znázorňuje tyto principy podle potřeby.
Úlohy PCI DSS 3.2.1 vyžadují rigorii, že jsou dobře navržená řešení. I když je sladění infrastruktury s požadavky na PCI zásadní, dodržování předpisů se u hostitelské infrastruktury nezastaví. Řešení pilířů kvality, konkrétně zabezpečení, může ohrozit dodržování předpisů. Dobře navržená řešení kombinují perspektivy infrastruktury i úloh, aby se dosáhlo rigorií potřebného k dosažení vyhovujících výsledků.
Zabezpečení
Postupujte podle základních pokynů uvedených v zásadách návrhu zabezpečení. Osvědčené postupy pro regulované prostředí jsou shrnuté v těchto částech.
Řízení
Implementace zásad správného řízení vychází z požadavků na dodržování předpisů v PCI-DSS 3.2.1. To ovlivňuje technické kontroly pro udržování segmentace, přístupu k prostředkům, zjišťování ohrožení zabezpečení a nejdůležitější ochranu zákaznických dat.
Strategie segmentace podniku
Pokud chcete zachovat úplnou izolaci, doporučujeme nasadit regulovanou infrastrukturu v samostatném předplatném. Pokud máte více předplatných, která jsou nezbytná pro dodržování předpisů, zvažte jejich seskupení v hierarchii skupin pro správu, která platí pro příslušné zásady Azure jednotně napříč předplatnými v daném oboru. V rámci předplatného použijte související zásady Azure na úrovni předplatného, abyste zachytili obecné zásady, které by se měly vztahovat na všechny clustery v datovém prostředí držitelů karet (CDE). Pomocí souvisejících zásad Azure na úrovni skupiny prostředků zachytejte zásady, které se vztahují na konkrétní instanci clusteru. Tyto zásady vytvářejí základní mantinely cílové zóny.
Izolujte úlohu PCI (v rozsahu) od jiných (mimo rozsah) úloh z hlediska provozu a připojení. Izolaci můžete vytvořit nasazením samostatných clusterů. Nebo pomocí strategií segmentace udržujte oddělení. Clustery například používají samostatné fondy uzlů, aby úlohy nikdy nesdílely virtuální počítač uzlu.
Vynucení zásad
Vynucujte kontrolní mechanismy zabezpečení povolením zásad Azure. Například v této regulované architektuře můžete zabránit chybné konfiguraci datového prostředí držitelů karet. Můžete použít zásady Azure, které nepovolují přidělování veřejných IP adres na uzlech virtuálních počítačů. Taková přidělení jsou zjištěna a hlášena nebo blokována.
Azure poskytuje několik předdefinovaných zásad pro většinu služeb. Projděte si tyto předdefinované definice zásad Azure Policy a podle potřeby je použijte.
Monitorování dodržování předpisů
Dodržování předpisů musí být systematicky sledováno a udržováno. Provádí se pravidelná ověření dodržování předpisů. Znalost toho, jestli jsou vaše cloudové prostředky v souladu s předpisy, vám pomůžou připravit se na ověření identity a audit.
Využijte řídicí panel dodržování právních předpisů v Programu Microsoft Defender pro cloud. Nepřetržitým monitorováním řídicího panelu můžete sledovat stav dodržování předpisů vaší úlohy.
Zabezpečení sítě
V hvězdicové topologii mají samostatné virtuální sítě pro každou entitu základní segmentaci v síťové stopě. Každá síť je dále segmentována do podsítí.
Cluster AKS tvoří jádro CDE. Nemělo by být přístupné z veřejných IP adres a musí být zabezpečené připojení. Typické toky in a out of CDE lze kategorizovat jako:
- Příchozí provoz do clusteru
- Odchozí provoz z clusteru
- Provoz v clusteru mezi pody.
Aby se splnily požadavky regulovaného prostředí, cluster se nasadí jako privátní cluster. V tomto režimu je provoz do veřejného internetu a z veřejného internetu omezený. Dokonce i komunikace se serverem rozhraní Kubernetes API spravovaným AKS je soukromá. Zabezpečení je dále rozšířeno o přísné řízení sítě a pravidla brány firewall protokolu IP.
- Skupiny zabezpečení sítě (NSG), které pomáhají zabezpečit komunikaci mezi prostředky v síti.
- Azure Firewall umožňuje filtrovat veškerý odchozí provoz mezi cloudovými prostředky, internetem a místním prostředím.
- Aplikace Azure lication Gateway integrovaná s architekturou webových aplikací Azure k filtrování veškerého příchozího provozu z internetu, který Aplikace Azure lication Gateway zachytává.
- Kubernetes NetworkPolicy umožňuje pouze určité cesty mezi pody v clusteru.
- Azure Private Link pro připojení k jiným službám Azure Platform as a Service (PaaS), jako je Azure Key Vault a Azure Container Registry pro provozní úlohy.
Jsou zavedeny procesy monitorování, aby se zajistilo, že provoz prochází očekávaným způsobem a že se detekuje a hlásí jakákoli anomálie.
Podrobnosti o zabezpečení sítě najdete v tématu Segmentace sítě.
Zabezpečení dat
PCI-DSS 3.2.1 vyžaduje, aby všechna data držitelů karet (CHD) nebyla nikdy jasná, ať už při přenosu nebo v úložišti.
Vzhledem k tomu, že tato architektura a implementace se zaměřují na infrastrukturu a ne na úlohu, není správa dat demonstrována. Tady jsou některá dobře navržená doporučení.
Neaktivní uložená data
Data musí být šifrovaná prostřednictvím standardních šifrovacích algoritmů.
- Neukládejte data v prostředí držitelů karet.
- Šifrování mimo vrstvu úložiště
- Do úložného média zapisujte jenom šifrovaná data.
- Neukládejte klíče do vrstvy úložiště.
Všechna data ve službě Azure Storage se šifrují a dešifrují pomocí silné kryptografie. Preferují se šifrovací klíče spravované vlastním systémem.
Pokud potřebujete data dočasně uložit, použijte na tato data stejné aspekty. Důrazně doporučujeme povolit funkci šifrování hostitele AKS. Šifrování dočasných dat můžete vynutit pomocí předdefinovaných zásad Azure.
Při výběru technologie úložiště prozkoumejte funkce uchovávání informací. Ujistěte se, že se všechna data po vypršení nakonfigurovaného času bezpečně odeberou.
Standard také vyžaduje, aby citlivá ověřovací data (SAD) nebyla uložena. Ujistěte se, že se data nezpřístupní v protokolech, názvech souborů, mezipaměti a dalších datech.
Přenášená data
Veškerá komunikace s entitami, které komunikují s CDE, musí být přes šifrované kanály.
- Do CDE musí být povolený pouze provoz HTTPS. V této architektuře Aplikace Azure lication Gateway odepře veškerý provoz přes port 80.
- Pokud možno nešifrujte a dešifrujte data mimo službu CDE. Pokud to uděláte, zvažte, že tato entita je součástí cde.
- V rámci CDE zajišťuje zabezpečenou komunikaci mezi pody pomocí mTLS. Pro tento účel můžete implementovat síť služeb.
- Povolte pouze zabezpečené šifry a protokol TLS 1.2 nebo novější.
Identita
Při navrhování zásad přístupu postupujte podle těchto principů zabezpečení:
- Začněte zásadami nulové důvěryhodnosti. Podle potřeby proveďte výjimky.
- Udělte nejnižší oprávnění – stačí k dokončení úkolu.
- Minimalizujte stálý přístup.
Řízení přístupu na základě role (RBAC) Kubernetes spravuje oprávnění k rozhraní Kubernetes API. AKS podporuje tyto role Kubernetes. AKS je plně integrovaná s Microsoft Entra ID. Identitám Microsoft Entra můžete přiřadit role a využívat také další funkce.
Přístup s nulovou důvěryhodností
Služby Kubernetes RBAC, Azure RBAC a Azure ve výchozím nastavení implementují odepření. Toto nastavení přepište s opatrností a povolte přístup jenom k těm entitám, které ho potřebují. Další oblastí pro implementaci nulové důvěryhodnosti je zakázání přístupu SSH k uzlům clusteru.
Nejnižší oprávnění
Spravované identity můžete použít pro prostředky a pody Azure a určit jejich rozsah na očekávané úlohy. Například Aplikace Azure lication Gateway musí mít oprávnění k získání tajných kódů (certifikátů TLS) ze služby Azure Key Vault. Nesmí mít oprávnění k úpravě tajných kódů.
Minimalizace stálého přístupu
Minimalizujte stálý přístup pomocí členství ve skupině Microsoft Entra za běhu. Posílení ovládacího prvku pomocí zásad podmíněného přístupu v Microsoft Entra ID. Tato možnost podporuje řadu případů použití, jako je vícefaktorové ověřování, omezení ověřování na zařízení spravovaná vaším tenantem Microsoft Entra nebo blokování netypických pokusů o přihlášení.
Správa tajných kódů
Ukládejte tajné kódy, certifikáty, klíče a hesla mimo službu CDE. Můžete použít nativní objekty tajných kódů Kubernetes nebo spravované úložiště klíčů, jako je Azure Key Vault. Použití spravovaného úložiště vám pomůže při úlohách správy tajných kódů, jako je obměně klíčů a obnovení certifikátů.
Ujistěte se, že přístup k úložišti klíčů má kombinaci síťových a přístupových ovládacích prvků. Když povolíte spravované identity, cluster se musí ověřit ve službě Key Vault, aby získal přístup. Připojení k úložišti klíčů nesmí být také přes veřejný internet. Použijte privátní síť, například Private Link.
Efektivita provozu
Dodržujte základní pokyny uvedené v zásadách efektivity provozu. Osvědčené postupy pro regulované prostředí jsou shrnuté v těchto částech.
Oddělení rolí
Vynucení jasného oddělení povinností pro regulovaná prostředí je klíčem. Definice rolí a zodpovědností na základě potřeb úlohy a interakce s CDE. Pro operace související s clusterem a závislými službami můžete například potřebovat roli operátora infrastruktury nebo inženýra SRE (Site Reliability Engineer). Role zodpovídá za udržování zabezpečení, izolace, nasazení a pozorovatelnosti. Formalizovat tyto definice a rozhodnout o oprávněních, která tyto role potřebují. Například srEs jsou vysoce privilegované pro přístup ke clusteru, ale potřebují přístup pro čtení k oborům názvů úloh.
Izolace úloh
PCI-DSS 3.2.1 vyžaduje izolaci úlohy PCI od jiných úloh z hlediska provozu. V této implementaci jsou úlohy v oboru a mimo rozsah rozdělené do dvou samostatných fondů uzlů uživatele. Vývojáři aplikací pro obor a vývojáři pro úlohy mimo rozsah můžou mít různé sady oprávnění. Budou tam také samostatné brány kvality. Kód v oboru je například podmíněn dodržováním předpisů a ověřením identity, zatímco kód mimo rozsah není. Je také potřeba mít samostatné kanály sestavení a procesy správy verzí.
Provozní metadata
Požadavek 12 standardu PCI DSS 3.2.1 vyžaduje, abyste zachovali informace o inventáři úloh a dokumentaci pro přístup k pracovníkům. Důrazně doporučujeme používat značky Azure, protože informace o prostředí můžete sloučit s prostředky, skupinami prostředků a předplatnými Azure.
Udržujte informace o schválených řešeních, která jsou součástí infrastruktury a úlohy. To zahrnuje seznam imagí virtuálních počítačů, databází a řešení třetích stran podle vašeho výběru, které do cde přinášíte. Tento proces můžete dokonce automatizovat vytvořením katalogu služeb. Poskytuje samoobslužné nasazení pomocí schválených řešení v konkrétní konfiguraci, která dodržuje probíhající operace platformy.
Pozorovatelnost
Pro splnění požadavku 10 je pozorovatelnost v CDE důležitá pro dodržování předpisů. Protokoly aktivit poskytují informace o operacích souvisejících se správou účtů a tajných kódů, správou nastavení diagnostiky, správou serveru a dalšími operacemi přístupu k prostředkům. Všechny protokoly se zaznamenávají s datem, časem, identitou a dalšími podrobnými informacemi. Zachovejte protokoly po dobu až rok tím, že v protokolech služby Azure Monitor nakonfigurujete zásady uchovávání a archivace dat.
Ujistěte se, že k protokolům mají přístup jenom role, které je potřebují. Log Analytics a Microsoft Sentinel podporují různé řízení přístupu na základě role za účelem správy přístupu ke záznamu auditu.
Reakce a náprava
Monitorovací služby Azure, Azure Monitor a Microsoft Defender for Cloud můžou generovat oznámení nebo výstrahy, když detekují neobvyklou aktivitu. Mezi tyto výstrahy patří kontextové informace, jako je závažnost, stav a čas aktivity. Jak se generují výstrahy, mají strategii nápravy a kontrolují průběh. Doporučujeme centralizovat data v řešení zabezpečení informací a správy událostí (SIEM), protože integrace dat může poskytovat bohatý kontext upozornění.
V zobrazení Výstrahy zabezpečení v programu Microsoft Defender for Cloud máte přístup ke všem výstrahám, které Microsoft Defender for Cloud rozpozná ve vašich prostředcích. Pokud chcete tento problém vyřešit, požádejte o proces třídění. Spolupracujte se svým týmem zabezpečení a seznamte se s tím, jak budou vlastníkům úloh zpřístupněny relevantní výstrahy.
Efektivita výkonu
Postupujte podle základních pokynů uvedených v zásadách efektivity výkonu. Osvědčené postupy pro regulované prostředí jsou shrnuté v těchto částech.
Škálování
Pozorování toho, jak se prostředí přizpůsobí měnícím se požadavkům, značí očekávané chování prostředí za běhu pod vysokým zatížením. Automatické škálování prostředků v úloze minimalizuje lidskou interakci v CDE. Přidaná výhoda zabezpečení snižuje prostor pro útoky za všech okolností. Výhodu můžete maximalizovat tím, že využijete prostředky, které podporují přístup se škálováním na nulu. AKS například podporuje vertikální snížení kapacity fondů uzlů uživatelů na 0. Další informace najdete v tématu Škálování fondů uzlů uživatelů na 0.
dělení na části
Dělení je klíčovým faktorem efektivity výkonu v regulovaných úlohách. Díky diskrétním komponentám lze zodpovědět jasné definice odpovědnosti a pomáhá při přesných kontrolách, jako jsou síťové zásady. Podobně jako jakákoli strategie segmentace oddělení izoluje komponenty a řídí dopad poloměru výbuchu na neočekávané chyby nebo ohrožení systému.
Architektura shared-nothing
Architektura typu shared-nothing je navržená tak, aby odebrala kolize mezi spolulokovanými úlohami. Toto je také strategie pro odebrání kritických bodů selhání. V regulovaných prostředích se komponenty musí izolovat logickými nebo fyzickými hranicemi. To je v souladu s architekturou typu shared-nothing, což vede k výhodám škálovatelnosti. Umožňuje také zacílení relevantních kontrolních mechanismů zabezpečení a přísnějších možností auditování různých komponent.
Zjednodušené úlohy
Složitost úloh je obtížné zdokumentovat a auditovat. Snažte se o jednoduchost z důvodu výhod výkonu a snadného auditování zákonných požadavků. Znovu zvažte možnosti, které mají větší šířku, než je potřeba, protože tím se zvyšuje prostor pro útok a potenciál zneužití nebo chybné konfigurace.
Spolehlivost
Spolehlivost regulovaných prostředí musí být předvídatelná, aby bylo možné je konzistentně vysvětlit pro účely auditování. Postupujte podle základních pokynů uvedených v zásadách spolehlivosti. Osvědčené postupy pro regulované prostředí jsou shrnuté v těchto částech.
Cíle obnovení a zotavení po havárii
Vzhledem k citlivé povaze dat zpracovávaných v regulovaných úlohách jsou cíle obnovení a cíle bodu obnovení (RPO) nezbytné k definování. Jaká je přijatelná ztráta CHD? Úsilí o obnovení v rámci CDE stále podléhá standardním požadavkům. Očekává selhání a má jasný plán obnovení pro tato selhání, která jsou v souladu s rolemi, odpovědnostmi a oprávněným přístupem k datům. Problémy s živými weby nejsou odůvodněním pro odchylku od žádných předpisů. To je zvlášť důležité v úplné situaci zotavení po havárii. Získejte jasnou dokumentaci pro zotavení po havárii, která splňuje požadavky a minimalizuje neočekávaný přístup k CDE nebo CHD. Po obnovení vždy zkontrolujte kroky procesu obnovení a ujistěte se, že nedošlo k žádnému neočekávanému přístupu. Zdokumentování obchodních odůvodnění těchto instancí
Obnovovací
Přidání strategií odolnosti a obnovení do architektury může zabránit nutnosti ad hoc přístupu k CDE. Systém by měl být schopný se sám zotavit na definovaném bodu obnovení bez nutnosti přímého zásahu člověka. Tímto způsobem můžete eliminovat nepotřebnou expozici CHD, a to i těm osobám, které mají oprávnění k nouzovému přístupu. Proces obnovení musí být auditovatelný.
Řešení rizik souvisejících se zabezpečením
Zkontrolujte rizika zabezpečení, protože můžou být zdrojem výpadků úloh a ztráty dat. Investice do zabezpečení mají také dopad na spolehlivost úloh.
Provozní procesy
Spolehlivost se rozšiřuje na všechny provozní procesy v rámci CDE a jejich sousedství. Dobře definované, automatizované a otestované procesy pro obavy, jako je vytváření obrázků a faktor správy jump boxů, do dobře navrženého řešení.
Optimalizace nákladů
Postupujte podle základních pokynů uvedených v zásadách optimalizace nákladů.
Vzhledem k požadavkům na dodržování předpisů a přísným kontrolním mechanismům zabezpečení je jasný kompromis. Doporučujeme vytvořit počáteční odhady pomocí cenové kalkulačky.
Tady je znázornění vysokého dopadu nákladů na hlavní prostředky, které tato architektura používá.
Hlavními faktory jsou škálovací sady virtuálních počítačů, které tvoří fondy uzlů a službu Azure Firewall. Dalším přispěvatelem je Log Analytics. V závislosti na vašem výběru plánů jsou k Microsoft Defenderu pro cloud přidružené také přírůstkové náklady.
Jasně pochopit, co představuje cenu služby. Azure sleduje měřené využití. Tady je podrobný přehled služby Azure Firewall pro tuto architekturu.
Náklady spojené s některými prostředky, jako je Azure Firewall, se dají rozložit do několika obchodních jednotek nebo aplikací. Dalším způsobem, jak optimalizovat náklady, může být hostování víceklientských clusterů v rámci organizace a maximalizace hustoty s rozmanitostí úloh. Tento přístup však nedoporučujeme pro regulované úlohy. Vždy stanovte prioritu dodržování předpisů a segmentace oproti výhodám nákladů.
Pokud chcete zachovat omezení rozpočtu, jsou některé způsoby řízení nákladů úpravou infrastruktury brány Aplikace Azure lication, nastavením počtu instancí pro automatické škálování a snížením výstupu protokolu, pokud stále splňují záznam auditu vyžadovaný PCI-DSS 3.2.1. Vždy tyto volby vyhodnoťte proti kompromisům v jiných aspektech návrhu, které vám umožní splnit smlouvu SLA. Jste například stále schopni odpovídajícím způsobem škálovat tak, aby splňovaly špičky v provozu?
Při vytváření skupin prostředků Azure použijte značky, aby je bylo možné sledovat podle nákladů. Ke sledování a analýze nákladů použijte nástroje pro správu nákladů, jako je Azure Advisor a Microsoft Cost Management .
Zvažte povolení analýzy nákladů AKS pro podrobné přidělování nákladů na infrastrukturu clusteru podle konkrétních konstruktorů Kubernetes.