Share via

Důležité informace o nezávislém dodavateli softwaru (ISV) pro cílové zóny Azure

  • Článek

Koncepční architektura cílových zón Azure pro mnoho organizací představuje cíl cesty přechodu na cloud. Cílové zóny popisují, jak vytvořit prostředí Azure s několika předplatnými. Každá cílová zóna využívá škálování, zabezpečení, zásady správného řízení, sítě a identitu a vychází z zpětné vazby a poznatků získaných od mnoha zákazníků.

Tip

Cílové zóny Azure můžou být užitečné považovat za plány měst. Architektury úloh nasazených do cílové zóny se podobají plánům budov ve městě.

Aby bylo možné vytvořit budovy, musí být zavedeny všechny systémy vody, plynu, elektřiny a dopravy města. Podobně musí být všechny komponenty cílové zóny Azure, včetně skupin pro správu, zásad, předplatných a řízení přístupu na základě role (RBAC), zavedeny před nasazením všech produkčních úloh.

Jako nezávislý dodavatel softwaru (ISV) vytváří a provozuje vaše řešení v Azure, měli byste při vytváření prostředí Azure odkazovat na následující prostředky:

Cílové zóny Azure vám pomůžou zvolit směr pro vaše celkové prostředí Azure. Jako poskytovatel softwaru, poskytovatel SaaS nebo spuštění se ale vaše konkrétní požadavky na implementaci můžou lišit od standardních zákaznických scénářů. Tady je několik příkladů různých scénářů implementace:

  • Sestavíte software, který zákazníci nasadí do vlastních předplatných.
  • Máte vlastní řídicí rovinu a pomocí automatizačních skriptů nebo softwaru nasaďte a nakonfigurujte prostředky Azure pro vaše řešení SaaS.
  • Jste malý výrobce softwaru nebo spuštění a chcete začít s nejnižšími možnými náklady a nechcete zpočátku používat služby, jako je Azure Firewall a Azure DDoS Protection.
  • Jste rozsáhlý výrobce softwaru SaaS a plánujete rozdělit aplikaci SaaS mezi několik předplatných pro škálování. Také chcete seskupit předplatná tak, aby odpovídala vašemu vývojovému, testovacímu, přípravnému a produkčnímu prostředí.
  • Provozní model vaší organizace odděluje role firemního IT týmu a produktové týmy SaaS. Firemní IT tým vaší organizace může spravovat prostředky, jako jsou systém Microsoft Office 365 a Microsoft Teams, a váš produktový tým SaaS může odpovídat za sestavování a provoz vašeho produktu SaaS (včetně jeho centrální platformy a komponent identit).

Poznámka:

Nezávislí výrobci softwaru někdy chtějí začít jenom s jedním předplatným Azure, které zahrnuje aspekty "sdílených služeb" platformy i skutečné prostředky úloh. I když je to technicky možné, budete později čelit výzvám, když potřebujete přesunout prostředky mezi předplatnými a zjistit, že ne všechny typy prostředků je možné přesunout. Projděte si dopad odchylek návrhu a zjistěte, jaké odchylky jsou možné, a jejich různé úrovně rizika.

Modely nasazení isV

Řešení isV se často hodí do jednoho ze tří modelů nasazení: čisté SaaS, nasazené zákazníkem nebo SaaS s duálním nasazením. Tato část popisuje různé aspekty jednotlivých modelů pro cílové zóny Azure.

Čisté SaaS

V čistě modelu SaaS se váš software nasadí plně jenom ve vašich předplatných Azure. Koncoví zákazníci využívají váš software bez nutnosti ho nasazovat ve svých vlastních předplatných Azure. V následujícím diagramu uživatelé používají čistou aplikaci SaaS poskytovanou isV:

Diagram that shows a pure SaaS deployment model. A user directly uses the application deployed into the I S V's Azure subscription.

Mezi příklady čistého softwaru SaaS patří e-mail jako služba, Kafka jako služba, cloudový datový sklad jako služba a mnoho výpisů SaaS na Azure Marketplace.

Pokud jste malý výrobce softwaru SaaS, možná nebudete muset k nasazení prostředků hned použít více předplatných Azure. Při škálování ale limity předplatného Azure můžou ovlivnit vaši schopnost škálovat v rámci jednoho předplatného. Projděte si principy návrhu cílové zóny na podnikové úrovni, zejména demokratizaci předplatného, a seznamte se s přístupy architektury pro víceklientské architektury, které vám umožní naplánovat budoucí růst.

Nezávislí výrobci softwaru vytvářející čistě řešení SaaS by měli zvážit následující otázky:

  • Měly by být všechny prostředky Azure, které tvoří naše řešení SaaS, v jednom předplatném Azure, nebo rozdělené mezi několik předplatných Azure?
  • Máme každého zákazníka hostovat ve vlastním vyhrazeném předplatném Azure, nebo můžeme vytvářet prostředky v rámci jednoho nebo několika sdílených předplatných?
  • Jak můžeme model razítka nasazení (jednotky škálování) použít na všechny úrovně našeho řešení?
  • Jak můžeme použít organizaci prostředků Azure ve víceklientských řešeních , abychom zabránili problémům se škálováním a omezením předplatného Azure?

Nasazené zákazníkem

V modelu nasazeného zákazníkem si koncoví zákazníci kupují software od vás a pak ho nasazují do vlastních předplatných Azure. Můžou zahájit nasazení z Azure Marketplace nebo ho provést ručně podle pokynů a pomocí skriptů, které zadáte.

V následujícím diagramu poskytovatel softwaru poskytuje softwarový balíček nebo produkt katalogu Azure Marketplace a uživatelé tento prostředek nasadí do vlastních předplatných Azure spolu s dalšími úlohami:

Diagram that shows a customer-deployed deployment model. A customer deploys resources provided by the ISV into their own Azure subscription, and users use those resources.

Jiný prvek úlohy zákazníka v diagramu může představovat buď vlastní úlohu zákazníka, nebo jiný produkt ISV, který zákazník nasadil v rámci svého předplatného Azure. Zákazníci často nasazují do svých předplatných Azure více produktů z různých výrobců softwaru. Tyto jednotlivé produkty kombinují a vytvářejí řešení. Zákazník může například nasadit databázový produkt z jednoho výrobce softwaru, síťového virtuálního zařízení od jiného výrobce softwaru a webové aplikace třetího výrobce softwaru.

Mezi příklady produktů nezávislých výrobců softwaru nasazených zákazníkem patří řada imagí virtuálních počítačů (jako jsou síťová a úložné virtuální zařízení) a aplikace Azure na Azure Marketplace.

U některých řešení nasazených zákazníkem může organizace poskytovat správu a aktualizace řešení nasazeného v rámci jejich předplatných Azure pro koncové zákazníky pomocí služby Azure Lighthouse nebo spravovaných aplikací Azure. Nezávislí výrobci softwaru, integrátoři řešení (SI) a poskytovatelé spravovaných služeb můžou tuto strategii používat, když splňují jejich konkrétní potřeby.

Řešení isV nasazená zákazníkem se považují za standardní aplikační úlohu z pohledu cílových zón Azure. Při návrhu produktu zvažte pokyny k cílovým zónám Azure, abyste mohli pracovat s principy návrhu cílových zón Azure, které vaši zákazníci Azure přijmou.

Je důležité mít při migraci úloh stávajících zákazníků do Azure dobrý přehled o konceptech cílové zóny Azure.

Nezávislí výrobci softwaru vytvářející řešení nasazená zákazníkem by měli zvážit následující otázky:

  • Má zákazník nasadit naše řešení do vlastního vyhrazeného předplatného nebo do stávajícího předplatného, které obsahuje související úlohy?
  • Jak by zákazníci měli navázat síťové připojení mezi stávajícími úlohami (uvnitř a mimo Azure) a naším řešením?
  • Podporuje naše řešení mechanismy ověřování z Microsoft Entra ID nebo vyžaduje jiné protokoly, jako je LDAP nebo Kerberos?
  • Jak omezíme nebo odstraníme porušení zásad Azure Policy, jako jsou konflikty mezi šablonami řešení a zásadami Azure zákazníka?

Zásady Azure zákazníků, které můžou způsobit porušení zásad Azure, zahrnují příklady typu Všechny podsítě musí mít skupinu zabezpečení sítě a k síťovým rozhraním v cílové zóně Corp se nedají připojit žádné veřejné IP adresy. Při plánování nasazení mějte na paměti potenciál těchto zásad způsobujících konflikty.

Duální nasazení SaaS

Některá řešení SaaS komunikují nebo používají prostředky nasazené v předplatných Azure zákazníků. Tento model nasazení se někdy označuje jako hybridní SaaS nebo SaaS s duálním nasazením. V následujícím diagramu isV poskytuje hostované řešení SaaS, které komunikuje s prostředky nasazenými do předplatného Azure koncového zákazníka:

Diagram that shows a dual deployment SaaS deployment model.

Skutečný příklad duálního nasazení SaaS je služba Microsoft Power BI, která může volitelně používat místní bránu dat Power BI nasazenou na virtuálním počítači v předplatném Azure zákazníka.

Mezi další příklady scénářů SaaS s duálním nasazením patří:

  • Vaše organizace sestaví Virtual Desktop Manager, produkt, který poskytuje rozhraní konzoly SaaS pro řízení prostředků Azure Virtual Desktopu v předplatném Azure každého zákazníka.
  • Vaše organizace poskytuje konzolu SaaS pro analýzu dat a dynamicky vytváří a odstraňuje virtuální počítače výpočetních uzlů v předplatném Azure každého zákazníka.

Jako nezávislé výrobce softwaru pro duální nasazení byste se měli podívat na cílovou zónu Azure, kde najdete pokyny ve dvou oblastech: strukturování vlastního prostředí Azure pro hostování služby SaaS a zajištění správné interakce mezi vašimi nasazeními v předplatných Azure zákazníků a cílovými zónami vašich zákazníků.

Nezávislí výrobci softwaru vytvářející řešení SaaS s duálním nasazením by měli zvážit následující otázky:

  • Prozkoumali jsme všechny aspekty vytváření čistých řešení SaaS i řešení nasazených zákazníkem?
  • Které komponenty našeho řešení by se měly hostovat v našich předplatných Azure a které komponenty by měly být nasazené zákazníkem?
  • Jak můžeme zajistit zabezpečené zřizování a interakce s prostředky nasazenými v předplatných Azure našich zákazníků?

Principy a implementace návrhu cílových zón Azure

Principy návrhu cílových zón Azure doporučují sladění s funkcemi nativní platformy Azure, jako jsou Log Analytics, Azure Monitor a Azure Firewall. Pokyny k cílové zóně také poskytují konkrétní možnosti implementace cílové zóny Azure.

Jako výrobce softwaru se můžete rozhodnout implementovat vlastní prostředí cílové zóny. K nasazení prostředků Azure napříč předplatnými může být potřeba použít vlastní automatizaci. Nebo můžete chtít pokračovat v používání nástrojů, které už používáte pro protokolování, monitorování a další služby vrstvy platformy.

Pokud implementujete vlastní prostředí cílových zón, doporučujeme použít pokyny cílové zóny Azure a ukázkové implementace pro referenci a sladit přístup s osvědčenými návrhy cílových zón Azure.

Tenanti Microsoft Entra

Každá cílová zóna Azure a její hierarchie skupin pro správu je kořenem v jednom tenantovi Microsoft Entra. To znamená, že první rozhodnutí, které musíte udělat, je to, který tenant Microsoft Entra použije jako zdroj identit pro správu prostředků Azure. Identity v ID Microsoft Entra zahrnují uživatele, skupiny a instanční objekty.

Tip

Tenant Microsoft Entra, který vyberete pro cílovou zónu, nemá vliv na ověřování na úrovni aplikace. I nadále můžete používat jiné zprostředkovatele identity, jako je Azure AD B2C bez ohledu na to, kterého tenanta zvolíte.

Pokyny pro cílové zóny Azure a tenanty Microsoft Entra důrazně doporučují použití jednoho tenanta Microsoft Entra a ve většině situací se jedná o správný přístup. Jako výrobce softwaru SaaS ale možná budete mít důvod používat dva tenanty.

U některých výrobců softwaru SaaS spravuje jeden tým podnikové prostředky a samostatný tým provozuje řešení SaaS. Toto oddělení může být z provozních důvodů nebo v souladu s zákonnými požadavky. Váš firemní IT tým možná nemůže spravovat žádná předplatná a prostředky související s SaaS, takže nemůžou být správci tenanta Microsoft Entra. Pokud se tento scénář týká vás, zvažte použití dvou samostatných tenantů Microsoft Entra: jednoho tenanta pro podnikové IT prostředky, jako je Office 365, a jednoho tenanta pro prostředky Azure, které tvoří vaše řešení SaaS.

Každý tenant Microsoft Entra musí mít vlastní název domény. Pokud vaše organizace používá dva tenanty, můžete zvolit název, například contoso.com pro vašeho podnikového tenanta Microsoft Entra a contoso-saas-ops.com pro vašeho tenanta SaaS Microsoft Entra, jak je znázorněno v následujícím diagramu.

Diagram that shows Microsoft Entra tenant options for ISVs with a single corporate tenant or separation between corporate and SaaS Ops tenants.

Upozorňující

Pokud používáte více tenantů Microsoft Entra, zvýší se režie správy. Pokud používáte funkce Microsoft Entra ID P1 nebo P2, jako je Privileged Identity Management, musíte zakoupit jednotlivé licence pro každého tenanta Microsoft Entra. Nejlepší je použít pouze několik tenantů Microsoft Entra, pokud to vaše situace skutečně vyžaduje.

Nepoužívejte samostatné tenanty Microsoft Entra pro předprodukční a produkční prostředí. Místo vytváření dvou tenantů, jako contoso-saas-ops-preprod.com je a contoso-saas-ops-prod.com s samostatnými předplatnými Azure, byste měli vytvořit jednoho tenanta Microsoft Entra. Pomocí skupin pro správu a Azure RBAC můžete řídit přístup k předplatným a prostředkům v rámci tohoto jednoho tenanta.

Další informace o používání více tenantů Microsoft Entra najdete v cílových zónách Azure a několika tenantech Microsoft Entra a zabezpečení prostředí Azure pomocí dokumentu white paper microsoft Entra.

Skupiny pro správu

Koncepční architektura cílové zóny Azure doporučuje používat konkrétní hierarchii skupin pro správu. Nezávislí výrobci softwaru ale můžou mít jiné požadavky než jiné organizace. Tato část popisuje některé způsoby, jak se vaše organizace nezávislých výrobců softwaru může rozhodnout o různých postupech, než jakou doporučuje koncepční architektura cílové zóny.

Skupina pro správu nejvyšší úrovně

Hierarchie skupin pro správu je vnořená do kořenové skupiny tenanta vytvořeného v Azure. Kořenovou skupinu tenanta nepoužíváte přímo.

Standardní organizace, která má centralizovaný podnikový IT tým, který spravuje svoji platformu a sdílené služby (jako je protokolování, sítě, identita a zabezpečení), obvykle vytvoří jednu skupinu pro správu nejvyšší úrovně v kořenové skupině tenanta vytvořenou v Azure a nasadí zbývající skupiny pro správu pod ní. Tato skupina pro správu nejvyšší úrovně se obvykle jmenuje po samotné organizaci (například Contoso).

Jako nezávislý výrobce softwaru SaaS můžete mít jeden produkt SaaS nebo můžete mít několik samostatných produktů SaaS nebo obchodních řad. I když byste obecně měli použít stejného tenanta Microsoft Entra ke správě prostředků Azure napříč všemi vašimi produkty (jak je popsáno v části Tenants Microsoft Entra), v některých scénářích se můžete rozhodnout nasadit více hierarchií skupin pro správu.

Zvažte, jak nezávislé jsou vaše produkty od sebe navzájem, a zeptejte se sami sebe:

  • Používají naše produkty stejné platformy pro DevOps, identitu, zabezpečení, připojení a protokolování?
  • Jsou tyto sdílené služby provozované jedním centrálním týmem?

Pokud jste odpověděli na obě otázky ano, vytvořte v kořenové skupině tenanta jednu skupinu pro správu produktů SaaS nejvyšší úrovně.

Pokud jste místo toho odpověděli ne a každý z vašich produktů SaaS spravuje a provozuje samostatné týmy platforem, zvažte vytvoření samostatné skupiny pro správu nejvyšší úrovně pro každý produkt, jako jsou dvě skupiny pro správu SaaS Product-01 a SaaS Product-02.

Tip

Je neobvyklé, že jeden výrobce softwaru má víc než jen několik skupin pro správu nejvyšší úrovně. Často je možné kombinovat několik produktů z důvodu podobností v tom, jak se spravují a provozují.

Tento přístup správy je podobný testovacímu přístupu pro cílové zóny na podnikové úrovni. Místo toho, aby společnost Contoso a Contoso-Canaryv kořenové skupině tenanta vytvářela v tomto přístupu skupinu pro správu konkrétního produktu Contoso-SaaS-Product-01, Contoso-SaaS-Product-02 a Contoso-SaaS-Product-03. Tento scénář je znázorněný v následujícím diagramu:

Diagram that shows top-level management group options with a single management group and separate management groups for each of the SaaS products

Skupina pro správu platformy

V hierarchii prostředků cílové zóny Azure skupina pro správu platformy obsahuje všechna předplatná Azure, která hostují komponenty a sdílené služby používané úlohami v předplatných cílové zóny. Mezi příklady komponent nasazených do předplatných platforem a sdílených služeb patří centralizovaná infrastruktura protokolování (například pracovní prostory služby Log Analytics), DevOps, zabezpečení, nástroje pro automatizaci, centrální síťové prostředky (například plány hub-VNet a DDos Protection) a služby řídicí roviny isV.

Skupina pro správu platformy je často rozdělená do skupin Identita, Správa a Připojení ivnost, aby poskytovala pohodlné oddělení rolí a zásad pro podnikové zákazníky.

Ve vaší organizaci můžete mít jeden tým, který spravuje všechny sdílené komponenty platformy, jako je identita, sítě a správa. Pokud ano, a pokud nemáte žádné plány oddělit správu napříč více týmy, zvažte použití jedné skupiny pro správu platformy .

Pokud místo toho budete mít samostatné týmy, které spravují různé části centralizované platformy, měli byste nasadit další úrovně v hierarchii skupin pro správu v rámci skupiny pro správu platformy . To vám umožní přiřadit samostatné zásady pro každou část centralizované platformy.

Následující diagram znázorňuje dvě potenciální implementace skupiny pro správu platformy . Možnost A ukazuje komplexnější scénář, kdy skupina pro správu platformy obsahuje tři podřízené skupiny pro správu: Správa a DevOps, Identita a zabezpečení a Připojení ivity. Každá podřízená skupina pro správu obsahuje předplatné s příslušnými prostředky. Možnost B ukazuje jednodušší scénář, kdy skupina pro správu platformy obsahuje jedno předplatné platformy.

Diagram that shows two management group hierarchies. Option A shows separate platform management groups for management, connectivity, and identity. Option B includes a platform management group option with a single management group.

Skupina pro správu cílových zón

Skupina pro správu cílových zón obsahuje předplatná Azure, která hostují skutečné subsystémy a úlohy vašeho řešení SaaS.

Tato skupina pro správu obsahuje jednu nebo více podřízených skupin pro správu. Každá podřízená skupina pro správu v rámci cílových zón představuje archetyp úlohy nebo subsystému s konzistentními požadavky na zásady a přístup, které by se měly vztahovat na všechna předplatná. Mezi důvody použití více archetypů patří:

  • Dodržování předpisů: Pokud musí být subsystém vašeho produktu SaaS kompatibilní se standardem PCI-DSS, zvažte vytvoření skupiny pro správu archetypu PCI DSS v rámci cílových zón. Všechna předplatná Azure, která obsahují prostředky v rámci rozsahu dodržování předpisů PCI-DSS, by se měla umístit do této skupiny pro správu.
  • Úrovně: Zvažte vytvoření samostatných archetypů cílových zón pro vyhrazené zákazníky a zákazníky úrovně Free vašeho řešení SaaS. Každá z podřízených skupin pro správu obsahuje různá nastavení služby Azure Policy. Například zásady na úrovni Free můžou omezit nasazení tak, aby povolovala jenom konkrétní skladové položky virtuálních počítačů a zásady ve vyhrazené vrstvě můžou vyžadovat nasazení prostředků do konkrétních oblastí.

Skupiny pro správu specifické pro prostředí

Nezávislí výrobci softwaru SaaS často organizují svá cloudová prostředí modelováním životního cyklu vývoje softwaru v posloupnosti. To obvykle vyžaduje nasazení nejprve do vývojového prostředí, pak do testovacíhoprostředí, pak do přípravného prostředí a nakonec do produkčního prostředí.

Jedním z běžných rozdílů mezi prostředími jsou jejich pravidla Azure RBAC, například kdo má přístup ke každé skupině předplatných. Například týmy DevOps, SaaSOps, vývoj a testování můžou mít různé úrovně přístupu k různým prostředím.

Důležité

Většina zákazníků Azure má stovky aplikací a pro každý tým aplikací používá samostatná předplatná Azure. Pokud by každá aplikace měla svůj vlastní vývoj, testování, přípravu a produkční skupiny pro správu, existuje velký počet skupin pro správu s téměř identickými zásadami. Pro většinu zákazníků se nejčastější dotazy k cílovým zónám na podnikové úrovni doporučují, abyste pro každé prostředí používali samostatné skupiny pro správu. Místo toho doporučuje používat samostatná předplatná v rámci jedné skupiny pro správu.

Nezávislí výrobci softwaru SaaS ale můžou mít jiné požadavky než většina ostatních zákazníků Azure a v některých situacích můžou mít dobrý důvod používat skupiny pro správu specifické pro prostředí.

Nezávislí výrobci softwaru SaaS někdy potřebují seskupit více předplatných, která představují horizontální oddíly nebo oddíly stejného subsystému, aplikace nebo úlohy. Možná budete muset použít zásady nebo přiřazení rolí u skupin předplatných výrazně jinak než v archetypové skupině pro správu. V tomto případě zvažte vytvoření podřízených skupin pro správu, které odpovídají jednotlivým prostředím v rámci skupiny pro správu archetypu.

Následující diagramy znázorňují dvě potenciální možnosti. Možnost A ukazuje scénář s samostatnými předplatnými pro každé prostředí, ale žádné skupiny pro správu specifické pro prostředí. Možnost B ukazuje scénář isV SaaS se skupinami pro správu specifickou pro prostředí v rámci skupiny pro správu pravidelných kolek . Každá skupina pro správu specifická pro prostředí obsahuje více předplatných. V průběhu času isV škáluje své prostředky Azure v každém prostředí v rámci rostoucího počtu předplatných se společnou sadou zásad a přiřazení rolí.

Výběrem každé karty zobrazíte dva diagramy.

Vyřazené skupiny pro správu a sandboxy

Pokyny pro organizaci prostředků cílové zóny Azure doporučují zahrnutí skupin pro správu vyřazených z provozu a sandboxů přímo pod skupinu pro správu nejvyšší úrovně.

Vyřazená skupina pro správu je místem uchovávání pro předplatná Azure, která jsou zakázaná a nakonec se odstraní. Předplatné, které se už nepoužívá, můžete přesunout do této skupiny pro správu, abyste ho mohli sledovat, dokud nebudou trvale odstraněny všechny prostředky v předplatném.

Skupina pro správu sandboxů obvykle obsahuje předplatná Azure, která se používají pro účely zkoumání a mají pro ně volné nebo žádné zásady. Můžete například poskytnout jednotlivým vývojářům vlastní předplatná pro vývoj a testování. Můžete se vyhnout použití běžných zásad a zásad správného řízení u těchto předplatných tak, že je umístíte do skupiny pro správu sandboxů . Tím se zvyšuje flexibilita vývojářů a umožňuje jim snadno experimentovat s Azure.

Důležité

Předplatná ve skupině pro správu sandboxů by neměla mít přímé připojení k předplatným cílové zóny. Vyhněte se připojování předplatných sandboxu k produkčním úlohám nebo k neprodukčním prostředím, která zrcadlí produkční prostředí.

Následující diagram znázorňuje dvě potenciální možnosti. Možnost A nezahrnuje vyřazené skupiny pro správu a skupiny pro správu sandboxu, zatímco možnost B.

Diagram that shows the Decommissioned and Sandboxes management groups on the same level as the Platform and Landing Zones management groups.

Ukázkové cílové zóny nezávislých výrobců softwaru

Tato část obsahuje dva příklady struktur cílových zón Azure pro nezávislé výrobce softwaru SaaS. Vyberte každou kartu a porovnejte dvě ukázkové cílové zóny.

Následující diagram znázorňuje ukázkovou hierarchii cílových zón Azure isV SaaS s následujícími vlastnostmi:

Diagram that shows an example Azure landing zone hierarchy for an ISV. Most of the components from this article are omitted.

Další kroky