Azure Well-Architected Framework je sada principů, které lze použít k vyhodnocení řešení prostřednictvím kvalitních pilířů kvalitní architektury:
Tento článek tuto sérii končí. Přečtěte si úvod.
Tyto pokyny v této sérii zahrnují Well-Architected ve všech volbách návrhu. Tento článek shrnuje tyto volby. Implementace GitHub: Azure Kubernetes Service (AKS) Baseline Cluster for Regulated Workloads (Základní cluster AKS) pro regulovaný úlohy tyto principy demonstruje, jak je to v případě použití.
PCI DSS 3.2.1 vyžadují, aby byly dobře na míru architektonické řešení. Přestože je sladění infrastruktury s požadavky PCI klíčové, dodržování předpisů v hostitelské infrastruktuře se nezastaví. Pokud se nezadáte na pilíře kvality, konkrétně zabezpečení, může to ohrozit dodržování předpisů. Dobře architektonická řešení kombinují perspektivy infrastruktury a úloh, aby se dosáhlo velmi náročného výsledku, který je nezbytný pro dosažení vyhovujících výsledků.
Zabezpečení
Postupujte podle základních pokynů uvedených v principech návrhu zabezpečení. Osvědčené postupy pro regulovaný prostředí jsou shrnuty v těchto částech.
Zásady správného řízení
Implementace zásad správného řízení se řídí požadavky na dodržování předpisů v PCI-DSS 3.2.1. To má vliv na technické kontroly pro zachování segmentace, přístup k prostředkům, zjišťování ohrožení zabezpečení a nejdůležitější ochranu zákaznických dat.
Enterprise segmentace
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á rovnoměrně aplikuje příslušné zásady Azure napříč předplatným v příslušném oboru. V rámci předplatného použijte související zásady Azure na úrovni předplatného, abyste zachytili široké zásady, které by se měly vztahovat na všechny clustery v prostředí dat držitelů karet (CDE). Pokud chcete zachytávání zásad, které platí pro konkrétní instanci clusteru, použít související zásady Azure na úrovni skupiny prostředků. Tyto zásady sestaví základní ochranné pásma cílové zóny.
Izolovat úlohy PCI (v rozsahu) od jiných úloh (mimo rozsah) z hlediska provozu a připojení. Izolaci můžete vytvořit nasazením samostatných clusterů. Nebo použijte strategie segmentace k udržení oddělení. Clustery například používají samostatné fondy uzlů, aby úlohy nikdy nesdílely virtuální počítač uzlu.
Vynucování zásad
Povolením zásad Azure vynucovat bezpečnostní prvky. V této regulovaný architektuře můžete například zabránit chybné konfiguraci prostředí dat držitelů karet. Můžete použít zásady Azure, které neumožňují přidělování veřejných IP adres na uzlech virtuálních počítače. Taková přidělení se detekují a hlásí nebo blokují.
Informace o zásadách, které můžete povolit pro AKS, najdete v Azure Policy integrovanýchdefinic pro Azure Kubernetes Service .
Azure poskytuje několik předdefinových zásad pro většinu služeb. Zkontrolujte tyto Azure Policy integrovaných definic zásad a podle potřeby je použijte.
Monitorování dodržování předpisů
Dodržování předpisů musí být systematicky monitorováno a udržováno. Provádí se pravidelné ověřování dodržování předpisů. Když budete vědět, jestli vaše cloudové prostředky jsou v souladu s předpisy, pomůže vám to připravit se na ověření a audit.
Využijte řídicí panel dodržování právních předpisů v Azure Security Center. Díky nepřetržitému monitorování řídicího panelu můžete sledovat stav dodržování předpisů pro vaši úlohu.
Zabezpečení sítě
V topologii centra s paprsky poskytuje samostatná virtuální síť pro každou entitu základní segmentaci v síťových stopách. Každá síť je dále segmentována do podsítí.
Cluster AKS tvoří jádro CDE. Neměla by být přístupná z veřejných IP adres a připojení musí být zabezpečené. Typické toky do a z CDE je možné zařadit do těchto kategorií:
- Příchozí provoz do clusteru.
- Odchozí provoz z clusteru.
- Provoz v clusteru mezi pody.
Aby bylo možné splnit požadavky regulovaných prostředí, cluster se nasadí jako privátní cluster. V tomto režimu je provoz do a z veřejného internetu omezený. Dokonce i komunikace se serverem rozhraní Kubernetes API spravovaným službou AKS je privátní. Zabezpečení se dále vylepšuje pomocí přísných síťových ovládacích prvků a pravidel firewallu protokolu IP.
- Skupiny zabezpečení sítě (NSG), které pomáhají zabezpečit komunikaci mezi prostředky v síti.
- Azure Firewall můžete filtrovat odchozí provoz mezi cloudovými prostředky, internetem a místním prostředím.
- Azure Application Gateway integrovaná s rozhraním Azure Web Application Framework pro filtrování veškerého příchozího provozu z internetu, který Azure Application Gateway zachycuje.
- Kubernetes NetworkPolicy umožňuje povolit pouze určité cesty mezi pody v clusteru.
- Azure Private Link připojit k jiným službám Azure PaaS (platforma jako služba), jako jsou Azure Key Vault a Azure Container Registry pro provozní úlohy.
Jsou nastaveny monitorovací procesy, které mají zajistit, že provoz probíhá podle očekávání 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 nebyla nikdy jasná, ať už během přenosu nebo v úložišti.
Vzhledem k tomu, že tato architektura a implementace se zaměřují na infrastrukturu, a ne na úlohu, správa dat není předvedena. Tady je několik dobře nanášených doporučení.
Neaktivní uložená data
Data musí být šifrovaná pomocí standardních šifrovacích algoritmů.
- Neukládejte data v prostředí držitelů karet.
- Šifrování mimo vrstvu úložiště
- Na úložné médium zapisují jenom šifrovaná data.
- Neukládejte klíče do vrstvy úložiště.
Všechna data v Azure Storage se šifrují a dešifrují pomocí silné kryptografie. Upřednostňovali jste šifrovací klíče spravované své vlastní.
Pokud potřebujete data dočasně ukládat, platí pro tato data stejné aspekty. Důrazně doporučujeme povolit funkci šifrování hostitele služby AKS. Pomocí integrovaných zásad Azure můžete vynutit šifrování dočasných dat.
Při výběru technologie úložiště prozkoumejte funkce uchovávání. Ujistěte se, že po vypršení nakonfigurovaného času jsou všechna data bezpečně odebrána.
Tento standard také vyžaduje, aby se citlivá ověřovací data (SAD) neu ukládali. Ujistěte se, že data nejsou zveřejněná 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ý jenom provoz HTTPS. V této architektuře Azure Application Gateway veškerý provoz přes port 80.
- Pokud možno, nechcete šifrovat a dešifrovat data mimo CDE. Pokud to tak je, zvažte, že tato entita je součástí CDE.
- V rámci CDE zajistěte 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 dodržujte tyto principy zabezpečení:
- Začněte Zero-Trust zásadami. Podle potřeby proveďte výjimky.
- Udělte co nejmenší oprávnění – stačí k dokončení úlohy.
- 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. Služba AKS je plně integrovaná s Azure Active Directory (Azure AD). K rolím můžete přiřadit identity Azure AD a také využívat další možnosti.
Zero-Trust přístupu
Služby RBAC, Azure RBAC a Azure v Kubernetes implementují ve výchozím nastavení odepření všech služeb. Toto nastavení přepište obezřetně a povolte přístup pouze těm entitám, které ho potřebují. Další oblastí pro implementaci Zero-Trust je zakázání přístupu SSH k uzlům clusteru.
Nejmenší oprávnění
Spravované identity můžete použít pro prostředky a pody Azure a nastavit jejich rozsah na očekávané úlohy. Například pokud Azure Application Gateway mít oprávnění k získání tajných kódů (certifikátů TLS) z Azure Key Vault. Nesmí mít oprávnění upravovat tajné kódy.
Minimalizace stálého přístupu
Minimalizujte stálý přístup pomocí členství ve skupině Azure AD za běhu. Zovládám řízení pomocí zásad podmíněného přístupu v Azure AD. Tato možnost podporuje mnoho případů použití, jako je vícefaktorové ověřování, omezení ověřování na zařízení spravovaná vaším tenantem Azure AD 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 CDE. Můžete použít nativní tajné kódy Kubernetes nebo spravované úložiště klíčů, například Azure Key Vault. Použití spravovaného úložiště vám pomůže při úlohách správy tajných klíčů, jako je obměná klíčů a prodloužení platnosti certifikátů.
Ujistěte se, že přístup k úložiště klíčů má rovnováhu mezi řízením přístupu a sítí. Když povolíte spravované identity, musí se cluster ověřit proti Key Vault získat přístup. Připojení k úložiště klíčů navíc nesmí být přes veřejný internet. Použijte privátní síť, například Private Link.
Efektivita provozu
Postupujte podle základních pokynů uvedených v principech efektivity provozu. Osvědčené postupy pro regulovaný prostředí jsou shrnuty v těchto částech.
Oddělení rolí
Klíčem je vynucování jasného oddělení povinností pro regulovaná prostředí. Definice rolí a zodpovědností na základě potřeb úlohy a interakce s CDE Například pro provoz související s clusterem a závislými službami můžete potřebovat roli operátora infrastruktury nebo techniky SRE (Site Reliability Engineer). Role zodpovídá za udržování zabezpečení, izolace, nasazení a pozorovatelnosti. Formalizujte tyto definice a rozhodněte o oprávněních, která tyto role potřebují. S SRE jsou například 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 úloh PCI od ostatních úloh z hlediska provozu. V této implementaci jsou úlohy v oboru a mimo rozsah segmentovány do dvou samostatných fondů uzlů uživatele. Vývojáři aplikací pro úlohy mimo rozsah a vývojáři můžou mít různé sady oprávnění. Budou také k dispozici samostatná hradla kvality. Například kód v rozsahu podléhá dodržování předpisů a ověření, zatímco kód mimo rozsah není. Také je potřeba mít samostatné kanály buildu a procesy správy verzí.
Provozní metadata
Požadavek 12 ze standardu PCI DSS 3.2.1 vyžaduje, abyste měli informace o inventáři úloh a dokumentaci k přístupu pracovníků. Důrazně doporučujeme používat značky Azure, protože můžete sbalit informace o prostředí s prostředky, skupinami prostředků a předplatným Azure.
Udržujte informace o schválených řešeních, která jsou součástí infrastruktury a úloh. To zahrnuje seznam imagí virtuálních počítače, databází a řešení třetích stran podle vašeho výběru, které přinášíte do CDE. Tento proces můžete dokonce automatizovat vytvořením katalogu služeb. Poskytuje samoobslužné nasazení pomocí těchto schválených řešení v konkrétní konfiguraci, která dodržuje průběžný provoz platformy.
Pozorovatelnost
Aby bylo možné splnit požadavek 10, je pozorovatelnost v CDE pro dodržování předpisů zásadní. Protokoly aktivit poskytují informace o operacích souvisejících se s právy k účtům a tajnými klíči, správě nastavení diagnostiky, správě serverů a dalším operacím přístupu k prostředkům. Všechny protokoly se zaznamenávají s datem, časem, identitou a dalšími podrobnými informacemi. V účtech úložiště můžete uchovávat protokoly po dobu až jednoho roku pro účely dlouhodobé archivace a auditování.
Ujistěte se, že k protokolům přistupují jenom role, které je potřebují. Log Analytics a Azure Sentinel podporují různé řízení přístupu na základě role pro správu přístupu k záznamu auditu.
Reakce a náprava
Monitorovací služby Azure, Azure Monitor a Azure Security Center, mohou generovat oznámení nebo upozornění, když zjistí neobvyklé aktivity. Tyto výstrahy obsahují kontextové informace, jako je závažnost, stav a čas aktivity. Při generování výstrah je k dispozici strategie nápravy a kontrola průběhu. Doporučujeme centralizovat data v řešení správy akcí a informací o zabezpečení (SIEM), protože integrace dat může poskytovat bohatý kontext výstrah.
V zobrazení Výstrahy zabezpečení v Azure Security Center máte přístup ke všem výstrahám, které Azure Security Center ve vašich zdrojích detekují. K řešení tohoto problému je zachytáte proces hodnocení. Spolupracujte se svým bezpečnostním týmem, abyste pochopili, jak budou vlastníkům úloh k dispozici relevantní výstrahy.
Efektivita výkonu
Postupujte podle základních pokynů uvedených v principech efektivity výkonu. Osvědčené postupy pro regulovaný prostředí jsou shrnuty v těchto částech.
Škálování
Když se prostředí přizpůsobí měnícím se požadavkům, bude to indikovat očekávané chování prostředí při vysokém zatížení. Automatické škálování prostředků v úlohě minimalizuje lidskou interakci v CDE. Další výhodou zabezpečení je za všech okolností omezení oblasti útoku. Výhodu můžete maximalizovat tím, že využijete prostředky, které podporují přístup škálování na nulu. AKS například podporuje horizontální navýšení kapacity fondů uzlů uživatele na 0. Další informace najdete v tématu Škálování fondů uzlů uživatele na 0.
Dělení
Dělení je klíčovým faktorem pro efektivitu výkonu u regulovaných úloh. Samostatné komponenty umožňují snadnou definici zodpovědnosti a pomáhají s přesnými kontrolami, jako jsou zásady sítě. Podobně jako u jakékoli strategie segmentace dělení izoluje komponenty a řídí dopad poloměru sítě na neočekávaná selhání nebo ohrožení systému.
Architektura SN (Shared-Nothing)
Architektura SN (Shared-Nothing) je navržená tak, aby odebírat kolektivy mezi kolokovaným zatížením. Toto je také strategie pro odstranění jednotlivých bodů selhání. V regulovaných prostředích musí být komponenty izolovány logickými nebo fyzickými hranicemi. To je v souladu s architekturou SN (Shared-Nothing), což má za následek výhody škálovatelnosti. Umožňuje také zacílení relevantních bezpečnostních prvků a přísnější možnosti auditování různých komponent.
Zjednodušená rozhraní
Složitost úloh je obtížné dokumentovat a auditovat. Usilujte o jednoduchost kvůli výhodám výkonu a snadnému auditování zákonných požadavků. Vyhodnoťte volby, které mají větší úroveň soukromí, než je potřeba, protože tím se zvyšuje prostor pro útok a potenciální zneužití nebo chybná konfigurace.
Spolehlivost
Spolehlivost regulovaných prostředí musí být předvídatelná, aby je bylo možné konzistentně vysvětlit pro účely auditování. Postupujte podle základních pokynů uvedených v principech spolehlivosti. Osvědčené postupy pro regulovaný prostředí jsou shrnuty v těchto částech.
Cíle obnovení a zotavení po havárii
Vzhledem k citlivé povaze dat zpracovaných v regulovaných úlohách je důležité definovat cíle obnovení a cíle bodů obnovení (RPO). Co je přijatelná ztráta CHD? Snahy o obnovení v rámci CDE stále podléhají standardním požadavkům. Očekávejte selhání a máte jasný plán obnovení pro selhání, která jsou v souladu s rolemi, odpovědnostmi a oprávněným přístupem k datům. Problémy na živém webu nejsou odůvodněním pro odchylování se od žádných předpisů. To je obzvláště důležité v případě úplného zotavení po havárii. Mít jasnou dokumentaci k zotavení po havárii, která splňuje požadavky a minimalizuje neočekávaný přístup CDE nebo CHD. Po obnovení vždy zkontrolujte kroky procesu obnovení a ujistěte se, že nedošlo k neočekávanému přístupu. Zdokumentujte obchodní odůvodnění těchto instancí.
Obnovovací
Přidáním strategií odolnosti a obnovení do vaší architektury můžete zabránit tomu, aby přístup k CDE byl potřebný pro ad hoc. Systém by měl být schopný obnovit počítač do určeného cíle RPO bez nutnosti přímého zásahu člověka. Tímto způsobem můžete eliminovat nepotřebnou expozici CHD, a to ani osobám, které mají oprávnění mít nouzový přístup. Proces obnovení musí být auditován.
Řešení rizik souvisejících se zabezpečením
Zkontrolujte rizika zabezpečení, protože mohou být zdrojem výpadku úloh a ztrátou dat. Investice do zabezpečení mají také dopad na spolehlivost úloh.
Provozní procesy
Spolehlivost se rozšiřuje na všechny provozní procesy v a sousedících s CDE. Dobře definované, automatizované a testované procesy pro otázky, jako je sestavení obrázků a faktor správy box, do dobře navrženého řešení.
Optimalizace nákladů
Řiďte se základními pokyny uvedenými v tématu Principy optimalizace nákladů.
Vzhledem k požadavkům na dodržování předpisů a přísným bezpečnostním kontrolám je jasné kompromisy náklady. Doporučujeme, abyste navázali počáteční odhady pomocí cenové kalkulačky.
Tady je základní reprezentace vlivu na hlavní prostředky, které tato architektura používá.
Hlavní ovladače jsou sady škálování virtuálních počítačů, které tvoří fondy uzlů a Azure Firewall. Další Přispěvatel je Log Analytics. V závislosti na zvolených plánech jsou také k dispozici přírůstkové náklady související s Azure Defenderem.
Jasné porozumění, co představuje cenu za službu. Azure sleduje měření využití. Tady je podrobná Azure Firewall této architektury.
Náklady spojené s některými prostředky, jako je například Azure Firewall, mohou být rozloženy mezi více organizačními jednotkami nebo aplikacemi. Další možností, jak optimalizovat náklady, může být hostování víceklientské clusteru v rámci organizace, což maximalizuje hustotu s různou zátěží. Tento postup nedoporučujeme pro regulované úlohy. Vždy nastavte prioritu dodržování předpisů a segmentace nad výhodami nákladů.
Pro zachování v rámci omezení rozpočtu jsou některé způsoby, jak řídit náklady, nastavením infrastruktury Azure Application Gateway, nastavením počtu instancí pro automatické škálování a zmenšením výstupu protokolu, pokud stále splňují záznam pro audit vyžadovaný rozhraním PCI-DSS 3.2.1. Tato volba se vždycky vyhodnotí proti kompromisům na dalších aspektech návrhu, které vám umožní splnit smlouvu SLA. Můžete se třeba pořád škálovat tak, aby splňoval špičky v provozu.
Při vytváření skupin prostředků Azure použijte značky, aby je bylo možné sledovat pro náklady. Pomocí nástrojů pro správu nákladů, jako jsou Azure Advisor a Azure cost management , můžete sledovat a analyzovat náklady.