Základní architektura virtuálních počítačů Azure v cílové zóně Azure

Architektura v tomto článku rozšiřuje základní architekturu virtuálního počítače, která řeší změny a očekávání při jejím nasazení v cílové zóně Azure.

V příkladu v tomto článku chce organizace, aby úloha založená na virtuálních počítačích používala federované prostředky, které centrálně spravuje tým platformy. Mezi tyto prostředky patří síťové prostředky pro připojení mezi místy, správu přístupu k identitám a zásady. Tento příklad předpokládá, že organizace přijme cílové zóny Azure, aby vynucuje konzistentní zásady správného řízení a nákladovou efektivitu napříč několika úlohami.

Jako vlastník úlohy můžete správu sdílených prostředků přesměrovat do centrálních týmů, abyste se mohli soustředit na vývoj úloh. Tento článek představuje perspektivu týmu úloh. Zadají se doporučení pro tým platformy.

Rozložení článku

Architektura	Rozhodnutí o návrhu	Přístup k architektuře Azure
▪ Diagram architektury ▪ Prostředky úloh ▪ Federované prostředky	▪ Nastavení předplatného ▪ Požadavky na sítě ▪ Změny návrhu sítě ze směrného plánu ▪ Sledování ▪ Dodržování předpisů oprav ▪ Zásady správného řízení organizace ▪ Správa změn	▪ Spolehlivost ▪ Zabezpečení ▪ Optimalizace nákladů

Architektura

Stáhněte si soubor aplikace Visio s touto architekturou.

Komponenty

Všechny architektury cílových zón Azure mají oddělení vlastnictví mezi týmem platformy a týmem úloh. Architekti aplikací a týmy DevOps musí mít silné znalosti o této odpovědnosti, aby pochopili, co je pod jejich přímým vlivem nebo kontrolou a co ne.

Prostředky vlastněné týmem úloh

Následující prostředky zůstávají většinou beze změny oproti základní architektuře.

• Azure Virtual Machines je aplikační platforma. Výpočetní prostředky se distribuují napříč zónami dostupnosti.

• Azure Load Balancer se používá k privátnímu vyrovnávání zatížení provozu z front-endových virtuálních počítačů do back-endových virtuálních počítačů. Nástroj pro vyrovnávání zatížení distribuuje provoz do virtuálních počítačů napříč zónami.

• Aplikace Azure Gateway se používá jako reverzní proxy pro směrování uživatelských požadavků na front-endové virtuální počítače. Vybraná skladová položka se také používá k hostování služby Azure Web Application Firewall k ochraně front-endových virtuálních počítačů před potenciálně škodlivým provozem.

• Azure Key Vault se používá k ukládání tajných kódů aplikací a certifikátů.

• Azure Monitor, Log Analytics a Přehledy aplikací se používají ke shromažďování, ukládání a vizualizaci dat pozorovatelnosti.

• Azure Policy se používá k použití zásad specifických pro danou úlohu.

Tým úloh udržuje a plní následující zdroje a povinnosti.

• Paprskové podsítě virtuální sítě a skupiny zabezpečení sítě (NSG), které jsou umístěné v těchto podsítích, aby se zachoval segmentace a řízení toku provozu.

• Privátní koncové body pro zabezpečení připojení k řešením PaaS (Platforma jako služba) a privátní zóny DNS vyžadované pro tyto koncové body.

• Azure Spravované disky ukládá soubory protokolů na back-endových serverech a data se uchovávají i při restartování virtuálních počítačů. Front-endové servery mají připojené disky, které můžete použít k nasazení bezstavové aplikace.

Prostředky vlastněné týmem platformy

Tým platformy vlastní a udržuje tyto centralizované prostředky. Tato architektura předpokládá, že tyto prostředky jsou předem zřízenýy a považují je za závislosti.

• Azure Firewall v centrální síti slouží ke kontrole a omezení odchozího provozu. Tato komponenta nahrazuje standardní nástroj pro vyrovnávání zatížení v základní architektuře, která neposkytuje omezení odchozího provozu do internetu.

• Azure Bastion v centrální síti poskytuje zabezpečený provozní přístup k virtuálním počítačům úloh. V základní architektuře vlastní tým úloh tuto komponentu.

• Paprsková virtuální síť je místem nasazení úlohy.

• Trasy definované uživatelem se používají k vynucení tunelování do centrální sítě.

• Omezení zásad správného řízení založená na Azure Policy a DeployIfNotExists zásady (DINE) jsou součástí předplatného úloh.

Nastavení předplatného

V kontextu cílové zóny musí tým úloh informovat tým platformy o konkrétních požadavcích.

Váš tým úloh musí obsahovat podrobné informace o síťovém prostoru, který vaše úlohy potřebuje, aby tým platformy mohl přidělit potřebné prostředky. Váš tým určuje požadavky a tým platformy určí IP adresy, které se mají přiřadit ve virtuální síti, a skupinu pro správu, ke které je předplatné přiřazeno.

Tým platformy přiřadí příslušnou skupinu pro správu na základě obchodní důležitosti a technických požadavků úlohy, například pokud je úloha vystavená internetu. Organizace určí konfiguraci těchto skupin pro správu a tým platformy je implementuje.

Například skupiny pro správu ve scénářích aplikace pro základní architekturu se považují za:

• Soukromé aplikace, jako jsou interní obchodní aplikace nebo komerční řešení COTS (COTS), která se často nacházejí ve skupině pro správu Corp cílových zón Azure.

• Veřejné aplikace jako v internetových aplikacích, které jsou často pod skupinou pro správu Corp nebo Online.

Tým platformy také zodpovídá za nastavení předplatného nebo skupiny předplatných pro nasazení úloh.

Následující části obsahují pokyny k počátečnímu nastavení předplatného. Tým platformy ale obvykle provádí změny centralizovaných služeb, které řeší zmeškané nebo změněné požadavky. Změny platformy mají širší vliv na všechny týmy úloh.

Proto tým platformy musí zajistit, aby všechny úlohy virtuálních počítačů byly připravené na jakékoli změny a musí si uvědomit životní cyklus řešení založeného na virtuálních počítačích a testovací cyklus. Další informace najdete v tématu Správa změn v průběhu času.

Požadavky na úlohy a plnění

Tým úloh a týmy platforem sdílejí dvě hlavní odpovědnosti: přiřazení skupin pro správu a nastavení sítě. Pro tuto architekturu zvažte následující síťové požadavky, které byste měli sdělit týmu platformy. Tyto body použijte jako příklady, abyste porozuměli diskuzi a vyjednávání mezi dvěma týmy při implementaci podobné architektury.

• Počet paprskových virtuálních sítí: V této architektuře se vyžaduje pouze jeden vyhrazený paprsk. Nasazené prostředky nemusí být rozložené do více sítí a jsou společně umístěné v rámci jedné virtuální sítě.

• Velikost paprskové sítě: Vezměte v úvahu provozní požadavky a očekávaný růst zatížení. Pokud například plánujete implementovat modré nebo zelené aktualizace nebo kanárky, maximální velikost by měla odpovídat prostoru, který vyžadují vaše souběžná nasazení.

  Budoucí změny můžou vyžadovat větší prostor IP adres, což může chybně zarovnát s aktuálním přidělením. Integrace těchto prostorů může představovat větší složitost. Buďte proaktivní a vyžádejte si předem dostatek síťových prostředků, aby se zajistilo, že přidělený prostor může pojmout budoucí rozšíření.

• Oblast nasazení: Je důležité určit oblasti, ve kterých se úloha nasadí. Tým platformy může tyto informace použít k zajištění zřizování virtuálních sítí paprsků a rozbočovačů ve stejné oblasti. Sítě napříč různými oblastmi můžou vést k problémům s latencí kvůli překročení regionálních hranic a můžou také vzniknout další náklady na šířku pásma.

• Charakteristiky úloh a možnosti návrhu: Komunikujte s týmem platformy volby návrhu, komponenty a charakteristiky. Pokud například očekáváte, že vaše úloha vygeneruje velký počet souběžných připojení k internetu (chatty), tým platformy by měl zajistit, aby byly k dispozici dostatek portů, aby se zabránilo vyčerpání. Můžou přidat IP adresy do centralizované brány firewall, aby podporovaly provoz, nebo nastavit bránu překladu adres (NAT) pro směrování provozu přes alternativní cestu.

  Pokud naopak očekáváte, že vaše úloha vygeneruje minimální síťový provoz (šum na pozadí), měl by tým platformy efektivně využívat prostředky v celé organizaci.

  Tým platformy musí jasně pochopit všechny závislosti. Vaše úloha může například potřebovat přístup k databázi, kterou vlastní jiný tým, nebo vaše úloha může mít provoz mezi místy. Má vaše úloha závislosti mimo Azure? Tyto informace jsou důležité pro tým platformy, který má vědět.

• Konfigurace brány firewall: Tým platformy musí vědět o provozu, který opouští paprskovou síť a je tunelovaný do centrální sítě. Brána firewall v centru nemůže blokovat tento provoz.

  Pokud například vaše úloha potřebuje přístup k aktualizacím Windows, aby zůstaly opravené, brána firewall by tyto aktualizace neměla blokovat. Podobně platí, že pokud existují agenti monitorování, kteří přistupují ke konkrétním koncovým bodům, brána firewall by neměla blokovat tento provoz, protože může narušit monitorování dat pro vaši úlohu. Aplikace může vyžadovat přístup ke koncovým bodům třetích stran. Bez ohledu na to použijte centralizovanou bránu firewall k rozlišení očekávaného a neoprávněného provozu.

• Přístup operátora: Pokud existují skupiny zabezpečení Microsoft Entra ID, které operátoři používají pro přístup k virtuálním počítačům přes Azure Bastion, informujte tým platformy. Azure Bastion je obvykle centrálním prostředkem. Je důležité zajistit, aby skupiny zabezpečení a virtuální počítače podporovaly zabezpečený protokol.

  Dále informujte tým platformy o rozsahech IP adres, které obsahují virtuální počítače. Tyto informace jsou nezbytné pro konfiguraci skupin zabezpečení sítě kolem služby Azure Bastion v centrální síti.

• Veřejné IP adresy: Informujte tým platformy o profilu příchozího přenosu dat, včetně všech očekávaných veřejných IP adres. V této architektuře cílí pouze internetový provoz na veřejnou IP adresu ve službě Application Gateway. Tým platformy by měl informovat tým úloh, pokud jsou tyto IP adresy pod plánem služby Azure DDoS Protection nebo pokud je to zodpovědností týmu úloh.

  V této architektuře existuje další veřejná IP adresa pro provozní přístup přes Azure Bastion. Tým platformy vlastní tuto veřejnou IP adresu a je zaregistrovaný ve službě, jako je DDoS Protection, kterou spravuje také tým platformy.

Možnosti návrhu virtuálních počítačů

Výběr skladové položky virtuálního počítače a disku zůstává stejný jako základní architektura.

Organizace může vyžadovat požadavky na dodržování předpisů pro tým úloh, který vyžaduje použití konkrétních imagí virtuálních počítačů. Vzhledem k těmto požadavkům může tým platformy spravovat sadu standardizovaných imagí, často označovaných jako zlaté obrázky, které se vytvářejí pro použití v celé organizaci.

Tým platformy může k ukládání schválených imagí operačního systému nebo artefaktů úloh použít spravovanou nabídku, jako je Galerie výpočetních prostředků Azure nebo privátní úložiště. Když pro virtuální počítače zvolíte image operačního systému, obraťte se na tým platformy o zdrojích imagí, frekvenci aktualizací a očekávání využití. Také se ujistěte, že image můžou splňovat nezbytné obchodní požadavky, které úloha splňuje.

Sítě

V základní architektuře se úloha zřizuje v jedné virtuální síti. Tým úloh spravuje virtuální síť.

V této architektuře tým platformy určuje topologii sítě. V této architektuře se předpokládá hvězdicová topologie.

Stáhněte si soubor aplikace Visio s touto architekturou.

• Virtuální síť centra: Regionální centrum obsahuje centralizované služby, které komunikují s prostředky úloh ve stejné oblasti. Další informace najdete v tématu Prostředky vlastněné týmem platformy. Doporučujeme umístit centrum do předplatného připojení.

• Paprsková virtuální síť: V této architektuře je paprskovou sítí jedna virtuální síť ze základní architektury. Je v partnerském vztahu k centrální síti, která obsahuje centralizované služby. Tým platformy vlastní a spravuje tuto paprskovou síť. Tato síť obsahuje prostředky úloh. Tým úloh vlastní prostředky v této síti, včetně jejích podsítí.

Ujistěte se, že s týmem platformy komunikujete s požadavky na úlohy a pravidelně je kontrolujete.

Podsítě virtuální sítě

V paprskové virtuální síti tým úloh vytvoří a přidělí podsítě. Umístěním ovládacích prvků, které omezují provoz do podsítí a z podsítí, pomáhá poskytovat segmentaci. Tato architektura používá stejnou topologii podsítě jako základní architektura, která má vyhrazené podsítě pro službu Application Gateway, front-endové virtuální počítače, nástroj pro vyrovnávání zatížení, back-endové virtuální počítače a privátní koncové body.

Když nasadíte úlohu v cílové zóně Azure, musíte stále implementovat síťové ovládací prvky. Organizace můžou uplatňovat omezení pro ochranu před exfiltrací dat a zajistit viditelnost centrálního centra pro provoz zabezpečení (SOC) a týmu IT sítě.

Díky tomuto přístupu může tým platformy optimalizovat celkovou útratu organizace pomocí centralizovaných služeb místo nasazení redundantních kontrolních mechanismů zabezpečení pro každou úlohu v celé organizaci. V této architektuře je příkladem centrální služby Azure Firewall. Pro každý tým úloh není nákladově efektivní ani praktické spravovat vlastní instanci brány firewall. Doporučujeme centralizovaný přístup ke správě brány firewall.

Příchozí přenos dat

Tok příchozího přenosu dat zůstává stejný jako základní architektura.

Vlastník úlohy zodpovídá za všechny prostředky, které souvisejí s příchozím přenosem dat z veřejného internetu do vaší úlohy. Například v této architektuře se služba Application Gateway a její veřejná IP adresa umístí do paprskové sítě, nikoli do centrální sítě. Některé organizace můžou prostředky s příchozím přenosem dat umístit do předplatného připojení pomocí centralizované implementace DMZ (Demilitarized). Integrace s touto konkrétní topologií je mimo rozsah pro tento článek.

Výchozí přenos

V základní architektuře škálovací sady úloh přistupují k veřejnému internetu přes Azure Load Balancer, ale tento provoz není omezený.

Tento návrh se v této architektuře liší. Veškerý provoz, který opouští paprskovou virtuální síť, se směruje přes síť partnerského centra přes výstupní bránu firewall. Trasa je připojená ke všem možným podsítím v paprskové síti, která směruje veškerý provoz pro IP adresy, které nejsou nalezeny v místní virtuální síti (0.0.0.0/0) do brány Azure Firewall centra.

Stáhněte si soubor aplikace Visio s touto architekturou.

Komunikace úloh s privátním koncovým bodem pro přístup ke službě Key Vault zůstává stejná jako základní architektura. Tato cesta je vynechána z předchozího diagramu pro stručnost.

Tým úloh musí identifikovat, zdokumentovat a komunikovat všechny nezbytné odchozí toky provozu pro provoz infrastruktury a úloh. Tým platformy umožňuje požadovaný provoz a veškerý nesdělený odchozí provoz je pravděpodobně odepřen.

Řízení výchozího provozu je více než jen zajištění toho, aby byl povolený očekávaný provoz. Jde také o zajištění toho, aby byl povolený jenom očekávaný provoz. Nesdělený odchozí provoz je ve výchozím nastavení pravděpodobně odepřen, ale je v nejlepším zájmu o zabezpečení úlohy, aby se zajistilo správné směrování provozu.

Sdělte týmu platformy všechny požadavky na jedinečný výchozí přenos dat. Pokud například vaše úloha vytváří řadu souběžných připojení k externím koncovým bodům sítě, informujte tým platformy. Tým platformy pak může zřídit odpovídající implementaci služby Azure NAT Gateway nebo přidat do regionální brány firewall další veřejné IP adresy pro zmírnění rizik.

Vaše organizace může mít požadavky, které nedoporučuje používat vzory architektury, které používají veřejné IP adresy vlastněné úlohami pro výchozí přenos dat. V takovém případě můžete pomocí služby Azure Policy odepřít veřejné IP adresy na kartách síťového rozhraní virtuálních počítačů a všech dalších veřejných IP adres, které jsou jiné než známé body příchozího přenosu dat.

Privátní zóny DNS

Architektury, které používají privátní koncové body, potřebují privátní zóny DNS pro práci s poskytovatelem DNS. Tým úloh musí jasně porozumět požadavkům a správě privátních zón DNS v předplatném, které tým platformy poskytuje. Privátní DNS zóny se obvykle spravují ve velkém měřítku pomocí zásad DINE, které umožňují službě Azure Firewall fungovat jako spolehlivý proxy server DNS a podporovat plně kvalifikovaná síťová pravidla názvu domény (FQDN).

V této architektuře tým platformy zajišťuje spolehlivý privátní překlad DNS pro koncové body privátního propojení. Spolupracujte s týmem platformy, abyste pochopili jejich očekávání.

testování Připojení ivity

Pro architektury založené na virtuálních počítačích existuje několik testovacích nástrojů, které vám můžou pomoct určit problémy se sítí v dohledu, směrováním a DNS. Můžete použít tradiční nástroje pro řešení potíží, například netstat, nslookupnebo tcping. Kromě toho můžete prozkoumat nastavení DHCP (Dynamic Host Configuration Protocol) a DNS síťového adaptéru. Pokud existují síťové karty, máte více možností řešení potíží, které umožňují provádět kontroly připojení pomocí služby Azure Network Watcher.

Přístup operátora

Stejně jako základní architektura se v této architektuře podporuje provozní přístup prostřednictvím služby Azure Bastion.

Základní architektura ale nasadí Azure Bastion jako součást úlohy. Pro typickou organizaci, která přijímá cílové zóny Azure, nasadí Azure Bastion jako centrální prostředky pro každou oblast. Tým platformy vlastní a udržuje Azure Bastion a všechny úlohy v organizaci ho sdílejí. Abychom si ukázali, že případ použití v této architektuře je Azure Bastion v centrální síti v předplatném připojení.

Identita operátora

Tato architektura používá stejné rozšíření ověřování jako základní architektura.

Vždy začněte principem nejnižších oprávnění a odstupňovaného přístupu k úkolu místo dlouhodobého přístupu. V kontextu cílové zóny využijte podporu JIT (just-in-time), kterou spravuje tým platformy.

Opravy dodržování předpisů a upgradů operačního systému

Základní architektura popisuje autonomní přístup k opravám a upgradům. Pokud je úloha integrovaná s cílovými zónami, může se tento přístup změnit. Tým platformy může diktovat operace oprav, aby všechny úlohy splňovaly požadavky organizace.

Ujistěte se, že proces oprav zahrnuje všechny komponenty, které do architektury přidáte. Pokud se například rozhodnete přidat virtuální počítače agenta sestavení pro automatizaci nasazení, škálování a správy aplikací, musí tyto virtuální počítače splňovat požadavky na platformu.

Sledování

Platforma cílové zóny Azure poskytuje sdílené pozorovatelné prostředky jako součást předplatného pro správu. Doporučujeme ale zřídit vlastní monitorovací prostředky, abyste usnadnili odpovědnost za vlastnictví úlohy. Tento přístup je konzistentní se základní architekturou.

Tým úloh zřizuje monitorovací prostředky, mezi které patří:

• Aplikace Přehledy jako služba APM (Application Performance Monitoring) pro tým úloh.

• Pracovní prostor služby Log Analytics jako sjednocená jímka pro všechny protokoly a metriky shromážděné z prostředků Azure vlastněných úlohami a kódu aplikace.

Stáhněte si soubor aplikace Visio s touto architekturou.

Podobně jako u směrného plánu jsou všechny prostředky nakonfigurované tak, aby odesílaly protokoly Azure Diagnostics do pracovního prostoru služby Log Analytics, který tým úloh zřizuje jako součást nasazení infrastruktury jako kódu (IaC) prostředků. Možná budete také muset odesílat protokoly do centrálního pracovního prostoru služby Log Analytics. V cílových zónách Azure se tento pracovní prostor nachází v předplatném pro správu.

Tým platformy může mít také zásady DINE, které můžou použít ke konfiguraci diagnostiky tak, aby odesílaly protokoly do centralizovaných předplatných pro správu. Je důležité zajistit, aby implementace neomezila další toky protokolů.

Korelace dat z více jímek

Protokoly a metriky úlohy a její komponenty infrastruktury se ukládají do pracovního prostoru služby Log Analytics úlohy. Protokoly a metriky, které centralizované služby, jako jsou Azure Firewall, Microsoft Entra ID a Azure Bastion, se ale ukládají do centrálního pracovního prostoru služby Log Analytics. Korelace dat z více jímek může být složitá úloha.

Korelovaná data se často používají během reakce na incidenty. Pokud dojde k potížím s korelací dat z několika jímek, ujistěte se, že runbook pro třídění pro tuto architekturu řeší a zahrnuje body kontaktu organizace, pokud problém přesahuje prostředky úloh. Správci úloh můžou od správců platforem vyžadovat pomoc při korelaci položek protokolu z podnikových sítí, zabezpečení nebo jiných služeb platformy.

Azure Policy

Tým platformy pravděpodobně použije zásady, které ovlivňují nasazení úloh. Často používají zásady DINE pro zpracování automatizovaných nasazení do předplatného cílové zóny aplikace. Zásady DINE můžou upravovat prostředky úloh nebo přidávat prostředky do vašeho nasazení, což může vést k nesrovnalostem mezi prostředky, které jsou deklarativní nasazené prostřednictvím šablony úlohy, a prostředky, které skutečně používají žádosti o zpracování. Typickým řešením je opravit tyto změny imperativními přístupy, které nejsou ideální.

Abyste se této nesrovnalosti vyhnuli, předem začleňte a otestujte změny iniciované platformou do šablon IaC. Pokud tým platformy používá zásady Azure, které jsou v konfliktu s požadavky aplikace, můžete s týmem platformy vyjednat řešení.

Správa změn v průběhu času

Služby a operace poskytované platformou jsou v této architektuře považovány za externí závislosti. Tým platformy nadále používá změny, onboarding uživatelů a používá řízení nákladů. Tým platformy, který slouží organizaci, nemusí určovat prioritu jednotlivých úloh. Změnytěchtoch funkcím můžou mít vliv na několik úloh, ať už se jedná o změny zlatých imagí, úpravy brány firewall, automatizované opravy nebo změny pravidel.

Proto týmy úloh a platforem musí efektivně a včas komunikovat, aby se spravily všechny externí závislosti. Je důležité testovat změny, takže nemají negativní vliv na úlohy.

Změny platformy, které ovlivňují úlohu

V této architektuře spravuje tým platformy následující zdroje informací. Změny těchto prostředků můžou potenciálně ovlivnit spolehlivost, zabezpečení, provoz a výkonnostní cíle úloh. Tyto změny je důležité vyhodnotit předtím, než je tým platformy uplatní, aby určil, jak ovlivňují úlohu.

• Zásady Azure: Změny zásad Azure můžou ovlivnit prostředky úloh a jejich závislosti. Může se například jednat o přímé změny zásad nebo přesun cílové zóny do nové hierarchie skupin pro správu. Tyto změny můžou být nepovšimnuté, dokud nedojde k novému nasazení, takže je důležité je důkladně otestovat.

• Pravidla brány firewall: Změny pravidel brány firewall můžou ovlivnit virtuální síť nebo pravidla úlohy, která se vztahují široce napříč všemi přenosy. Tyto úpravy můžou vést k zablokovaným přenosům a dokonce i selháním tichého procesu, jako je neúspěšná aplikace oprav operačního systému. Tyto potenciální problémy se vztahují jak na výchozí bránu Azure Firewall, tak na pravidla skupiny zabezpečení sítě použitou službou Azure Virtual Network Manager.

• Sdílené prostředky: Změny skladové položky nebo funkcí sdílených prostředků můžou ovlivnit zatížení.

• Směrování v centrální síti: Změny přechodné povahy směrování v centru můžou potenciálně ovlivnit funkčnost úloh, pokud úloha závisí na směrování do jiných virtuálních sítí.

• Hostitel Služby Azure Bastion: Změny dostupnosti nebo konfigurace hostitele Služby Azure Bastion můžou mít vliv na operace úloh. Ujistěte se, že změny vzoru přístupu jump boxu mají efektivní rutinní, ad hoc a nouzový přístup.

• Změny vlastnictví: Informujte všechny změny ve vlastnictví a kontaktních bodech týmu úloh, protože můžou ovlivnit žádosti o správu a podporu úlohy.

Změny úloh, které ovlivňují platformu

Následující příklady jsou změny úloh v této architektuře, které byste měli sdělit týmu platformy. Je důležité, aby tým platformy ověřil spolehlivost, zabezpečení, provoz a výkonnostní cíle služby platformy vůči novým změnám týmu úloh, než se projeví.

• Výchozí přenos dat sítě: Monitorujte jakékoli významné zvýšení výchozího přenosu dat sítě, abyste zabránili tomu, aby se úloha stala hlučným sousedem na síťových zařízeních. Tento problém může potenciálně ovlivnit cíle výkonu nebo spolehlivosti jiných úloh.

• Veřejný přístup: Změny veřejného přístupu k komponentám úloh můžou vyžadovat další testování. Tým platformy může úlohu přemístit do jiné skupiny pro správu.

• Hodnocení obchodní důležitosti: Pokud dojde ke změnám smluv o úrovni služeb (SLA) úlohy, možná budete potřebovat nový přístup pro spolupráci mezi platformou a týmy úloh.

• Změny vlastnictví: Komunikujte změny ve vlastnictví a kontaktních bodech týmu platformy.

Změny obchodních požadavků úloh

Aby bylo možné zachovat cíle na úrovni služeb (SLO) úlohy, může být potřeba, aby se tým platformy zapojil do změn architektury úloh. Tyto změny můžou vyžadovat správu změn od týmu platformy nebo ověření, že stávající zásady správného řízení podporují změněné požadavky.

Můžete například sdělit změny jakéhokoli dříve nepovoleného toku výchozího přenosu dat, aby tým platformy mohl přidat tento tok do brány firewall, virtual network manageru nebo jiných komponent pro podporu požadovaného provozu. Pokud už dříve povolený tok výchozího přenosu dat nepotřebujete, měl by tým platformy tento tok blokovat, aby zachoval zabezpečení úlohy. Komunikujte také změny směrování do jiných virtuálních sítí nebo mezi místními koncovými body nebo změnami komponent architektury. Každý prostředek podléhá zásadám a potenciálně výchozímu řízení brány firewall.

Spolehlivost

Tato architektura odpovídá zárukám spolehlivosti v základní architektuře.

Cíle spolehlivosti

Maximální možné složeného cíle úrovně služeb (SLO) je nižší než základní složené SLO kvůli komponentám, jako je řízení sítě výchozího přenosu dat. Tyto komponenty, které jsou běžné v prostředích cílových zón, nejsou pro tuto architekturu jedinečné. Cíl úrovně služby se podobně sníží, pokud tým úloh přímo řídí tyto služby Azure.

Navzdory nižšímu maximálnímu možnému cíli úrovně služeb je klíčovým aspektem spolehlivosti rozdělení komponent úloh napříč funkčními týmy. Díky této metodě má tým úloh výhody specializovaného týmu, který se zaměřuje na provoz kritické infrastruktury, kterou tato úloha a další úlohy používají.

Další informace najdete v tématu Doporučení pro definování cílů spolehlivosti.

Kritické závislosti

Zobrazte všechny funkce, které úloha provádí v cílové zóně platformy a aplikace jako závislosti. Plány reakce na incidenty vyžadují, aby tým úloh věděl o bodu a metodě kontaktních informací pro tyto závislosti. Zahrnout také tyto závislosti do analýzy režimu selhání úlohy (FMA).

Pro tuto architekturu zvažte následující závislosti:

• Výchozí brána firewall: Centralizovaná výchozí brána firewall sdílená více úlohami prochází změnami nesouvisející s úlohou.

• Vyčerpání síťových portů: Špičky využití ze všech úloh sdílejících síťové zařízení může vést k nasycení sítě nebo vyčerpání portů v bráně firewall pro výchozí přenos dat.

• Zásady DINE: Zásady DINE pro privátní zóny DNS Azure (nebo jakoukoli jinou závislost poskytovanou platformou) jsou nejlepší úsilí bez smlouvy SLA při spuštění. Zpoždění konfigurace DNS může způsobit zpoždění v připravenosti aplikace na zpracování provozu.

• Zásady skupiny pro správu: Konzistentní zásady mezi prostředími jsou klíčové pro spolehlivost. Zajistěte, aby předprodukční prostředí byla podobná produkčním prostředím, aby bylo možné zajistit přesné testování a zabránit odchylkám specifických pro prostředí, které můžou blokovat nasazení nebo škálování. Další informace najdete v tématu Správa vývojových prostředí aplikací v cílových zónách Azure.

Mnoho z těchto aspektů může existovat bez cílových zón Azure, ale týmy úloh a platforem musí tyto problémy společně řešit, aby se zajistilo splnění potřeb.

Další informace najdete v tématu Doporučení k provádění analýzy režimu selhání.

Zabezpečení

Aspekty zabezpečení pro tuto architekturu se přenášejí ze základní architektury. Doporučení v následujících částech jsou založená na kontrolním seznamu kontroly návrhu zabezpečení v architektuře Well-Architected Framework.

Síťové ovládací prvky

Správně nakonfigurujte síťové ovládací prvky, abyste měli jistotu, že je vaše úloha zabezpečená.

Příchozí přenos dat

Úlohy můžete izolovat od jiných paprsků úloh v rámci vaší organizace prostřednictvím skupin zabezpečení sítě ve vašich podsítích nebo netransitivní povahy nebo ovládacích prvků v regionálním centru. Vytvořte komplexní skupiny zabezpečení sítě, které umožňují pouze příchozí síťové požadavky vaší aplikace a její infrastruktury. Doporučujeme, abyste se nespoléhali výhradně na nepřenosnou povahu sítě rozbočovače pro zabezpečení.

Tým platformy pravděpodobně implementuje zásady Azure, aby se zajistilo, že služba Application Gateway má nastavený režim odepření webových aplikací, aby omezil počet veřejných IP adres dostupných pro vaše předplatné a další kontroly. Kromě těchto zásad by měl tým úloh vlastnit odpovědnost za nasazování zásad orientovaných na úlohy, které posiluje stav zabezpečení příchozího přenosu dat.

Následující tabulka ukazuje příklady ovládacích prvků příchozího přenosu dat v této architektuře.

Zdroj	Účel	Řízení úloh	Řízení platformy
Internet	Toky uživatelského provozu	Trychtýřuje všechny požadavky prostřednictvím skupiny zabezpečení sítě, firewallu webových aplikací a pravidel směrování před povolením přechodu veřejného provozu na privátní provoz, který vstupuje do front-endových virtuálních počítačů.	Nic
Azure Bastion	Přístup operátora k virtuálním počítačům	Skupina zabezpečení sítě v podsítích virtuálních počítačů, která blokuje veškerý provoz na porty vzdáleného přístupu, pokud není zdrojem z určené podsítě služby Azure Bastion dané platformy	Nic
Další paprsky	Nic	Blokováno prostřednictvím pravidel NSG	Netransitivní směrování nebo pravidla služby Azure Firewall v případě zabezpečeného centra Azure Virtual WAN

Výchozí přenos

Použijte pravidla NSG, která vyjadřují požadované požadavky na odchozí připojení vašeho řešení a zamítnou všechno ostatní. Nespoléhejte jenom na síťové ovládací prvky rozbočovače. Jako operátor úlohy máte odpovědnost za zastavení nežádoucího výchozího přenosu dat, který je co možná nejblíže zdroji.

Mějte na paměti, že zatímco vlastníte podsíť v rámci virtuální sítě, tým platformy pravděpodobně vytvořil pravidla brány firewall, která v rámci procesu správa předplatného konkrétně reprezentují vaše zachycené požadavky. Ujistěte se, že změny v podsítích a umístění prostředků po celou dobu životnosti vaší architektury jsou stále kompatibilní s původním požadavkem. Nebo můžete spolupracovat se síťovým týmem, abyste zajistili kontinuitu řízení výchozího přenosu dat s nejnižším přístupem.

Následující tabulka ukazuje příklady výchozího přenosu dat v této architektuře.

Koncový bod	Účel	Řízení úloh (NSG)	Řízení platformy (centra)
ntp.ubuntu.com	Protokol NTP (Network Time Protocol) pro virtuální počítače s Linuxem	UDP/123 na internet v podsíti front-endového virtuálního počítače (výchozí brána firewall tuto širokou otevření zúží)	Povolení síťového pravidla brány firewall pro stejné jako řízení úloh
koncové body služba Windows Update	funkce služba Windows Update ze serverů Microsoftu	TCP/443 a TCP/80 k internetu v podsíti back-endového virtuálního počítače (výchozí brána firewall tuto širokou otevření zúží)	Pravidlo povolení brány firewall se značkou plně kvalifikovaného názvu domény WindowsUpdate
Monitorování koncových bodů agenta	Požadovaný provoz pro rozšíření Monitorování na virtuálních počítačích	TCP/443 na internet v obou podsítích virtuálních počítačů (výchozí brána firewall tuto širokou otevření zúží)	Nezbytné povolenky pravidel aplikace brány firewall pro všechny konkrétní plně kvalifikované názvy domén na tcp/443
nginx.org	Instalace serveru Nginx (ukázková komponenta aplikace) přímo od dodavatele	TCP/443 na internet v podsíti front-endového virtuálního počítače (výchozí brána firewall zúží toto široké otevření)	Nezbytné povolení pravidel aplikace brány firewall pro nginx.org v protokolu TCP/443
Key Vault	Import certifikátů TLS (Transport Layer Security) ve službě Application Gateway a virtuálních počítačích	- TCP/443 k podsíti privátního koncového bodu z obou podsítí virtuálních počítačů do podsítě privátního koncového bodu - TCP/443 k podsíti privátního koncového bodu z podsítě služby Application Gateway - TCP/443 z virtuálních počítačů označených požadovaným označením skupiny zabezpečení aplikace (ASG) a podsítí služby Application Gateway	Nic

DDoS Protection

Určete, kdo zodpovídá za použití plánu ochrany před útoky DDoS, který pokrývá všechny veřejné IP adresy vašeho řešení. Tým platformy může použít plány ochrany IP adres nebo dokonce použít Azure Policy k vynucování plánů ochrany virtuální sítě. Tato architektura by měla mít pokrytí, protože zahrnuje veřejnou IP adresu pro příchozí přenos dat z internetu.

Další informace najdete v tématu Doporučení pro sítě a připojení.

Správa tajných kódů

Pro správu tajných kódů se tato architektura řídí základní architekturou.

Jako tým úloh pokračujte v uchovávání tajných kódů v instanci služby Key Vault. Podle potřeby nasaďte další instance pro podporu provozu vaší aplikace a infrastruktury.

Další informace najdete v tématu Doporučení pro ochranu tajných kódů aplikací.

Optimalizace nákladů

U prostředků úloh platí pro tuto architekturu také strategie optimalizace nákladů v základní architektuře .

Tato architektura výrazně přináší výhody prostředků platformy cílové zóny Azure. I když tyto prostředky používáte prostřednictvím modelu vrácení peněz, přidané zabezpečení a připojení mezi místy jsou nákladově efektivnější než samoobslužná správa těchto prostředků.

Tým platformy spravuje následující zdroje informací v této architektuře. Tyto prostředky jsou často založené na spotřebě (vratky) nebo potenciálně bezplatné pro tým úloh.

• Azure Firewall
• Řešení SIEM (Security Information and Event Management)
• Hostitelé služby Azure Bastion
• Připojení mezi místními sítěmi, jako je ExpressRoute

Využijte další centralizované nabídky od vašeho týmu platformy, abyste tyto výhody rozšířili na vaši úlohu, aniž by to ovlivnilo cíle cíle bodu obnovení( SLO), plánovanou dobu obnovení (RTO) nebo cíl bodu obnovení (RPO).

Další informace najdete v tématu Doporučení pro shromažďování a kontrolu dat o nákladech.

Nasazení tohoto scénáře

Nasazení pro tuto referenční architekturu je k dispozici na GitHubu.

Další krok

Projděte si informace o spolupráci a technických podrobnostech sdílených mezi týmem úloh a týmy platforem.

Prodejní předplatné