Návrh zásad správného řízení pro několik týmůGovernance design for multiple teams

Cílem těchto pokynů je pomoci naučit se postup navrhování modelu zásad správného řízení prostředků v Azure za účelem podpory více týmů, více úloh a více prostředí.The goal of this guidance is to help you learn the process for designing a resource governance model in Azure to support multiple teams, multiple workloads, and multiple environments. Nejdřív se podíváte na sadu hypotetických požadavků zásad správného řízení a potom si Projděte několik ukázkových implementací, které tyto požadavky splňují.First you'll look at a set of hypothetical governance requirements, then go through several example implementations that satisfy those requirements.

Požadavky:The requirements are:

  • Enterprise plánuje přecházet nové cloudové role a zodpovědnosti na skupinu uživatelů, takže vyžaduje správu identit pro více týmů s různými požadavky na přístup k prostředkům v Azure.The enterprise plans to transition new cloud roles and responsibilities to a set of users and therefore requires identity management for multiple teams with different resource access needs in Azure. Tento systém správy identit je nutný k uložení identity následujících uživatelů:This identity management system is required to store the identity of the following users:
    • Jednotlivec ve vaší organizaci zodpovědný za vlastnictví předplatných.The individual in your organization responsible for ownership of subscriptions.
    • Osoba ve vaší organizaci zodpovědná za sdílené prostředky infrastruktury používané pro připojení místní sítě k virtuální síti v Azure.The individual in your organization responsible for the shared infrastructure resources used to connect your on-premises network to a virtual network in Azure.
    • Dva uživatelé ve vaší organizaci odpovědní za správu úloh.Two individuals in your organization responsible for managing a workload.
  • Podpora více prostředí.Support for multiple environments. Prostředí je logické seskupení prostředků, jako jsou virtuální počítače, virtuální sítě a služby směrování provozu sítě.An environment is a logical grouping of resources, such as virtual machines, virtual networking, and network traffic routing services. Tyto skupiny prostředků mají podobné požadavky na správu a zabezpečení a jsou obvykle používány pro konkrétní účel, jako je testování nebo produkce.These groups of resources have similar management and security requirements and are typically used for a specific purpose such as testing or production. V tomto příkladu je požadavek pro čtyři prostředí:In this example, the requirement is for four environments:
    • Prostředí sdílené infrastruktury , které zahrnuje prostředky sdílené úlohami v jiných prostředích.A shared infrastructure environment that includes resources shared by workloads in other environments. Například virtuální síť s podsítí brány, která poskytuje připojení místně.For example, a virtual network with a gateway subnet that provides connectivity to on-premises.
    • Produkční prostředí s nejpřísnějšími zásadami zabezpečení.A production environment with the most restrictive security policies. Může zahrnovat interní nebo externí úlohy.Could include internal or external facing workloads.
    • Nevýrobní prostředí pro vývoj a testování práce.A nonproduction environment for development and testing work. Toto prostředí má zásady zabezpečení, dodržování předpisů a nákladů, které se liší od těch, které jsou v produkčním prostředí.This environment has security, compliance, and cost policies that differ from those in the production environment. V Azure to má podobu Enterprise pro vývoj/testování předplatného.In Azure, this takes the form of an Enterprise Dev/Test subscription.
    • Prostředí izolovaného prostoru (sandbox) pro testování konceptu a vzdělávání.A sandbox environment for proof of concept and education purposes. Toto prostředí se obvykle přiřazuje jednomu zaměstnanci, který se účastní vývoje aktivit a má přísné procesní a provozní kontrolní mechanismy, aby se zabránilo vybudování firemních dat.This environment is typically assigned per employee participating in development activities and has strict procedural and operational security controls in place to prevent corporate data from landing here. V Azure mají tyto předplatné formu předplatných sady Visual Studio.In Azure, these take the form of Visual Studio subscriptions. Tato předplatná by se taky neměla přivázat k podnikovým Azure Active Directory.These subscriptions should also not be tied to the enterprise Azure Active Directory.
  • Model oprávnění s minimálním oprávněním, ke kterému nemají uživatelé ve výchozím nastavení žádná oprávnění.A permissions model of least privilege in which users have no permissions by default. Model musí podporovat následující:The model must support the following:
    • Jeden důvěryhodný uživatel v oboru předplatného, považovaný za účet služby a udělil oprávnění k přiřazení přístupových práv k prostředkům.A single trusted user at the subscription scope, treated like a service account and granted permission to assign resource access rights.
    • Každému vlastníkovi úlohy je ve výchozím nastavení odepřen přístup k prostředkům.Each workload owner is denied access to resources by default. Přístupová práva k prostředkům jsou výslovně udělena jedním důvěryhodným uživatelem v oboru skupiny prostředků.Resource access rights are granted explicitly by the single trusted user at the resource group scope.
    • Přístup pro správu prostředků sdílené infrastruktury omezený na sdílené vlastníky infrastrukturyManagement access for the shared infrastructure resources, limited to the shared infrastructure owners.
    • Přístup pro správu pro každé zatížení omezený na vlastníka úlohy v produkčním prostředí a zvýšení úrovně řízení jako vývoj pokračuje v různých prostředích nasazení (vývoj, testování, fázování a produkce).Management access for each workload restricted to the workload owner in production, and increasing levels of control as development proceeds through the various deployment environments (development, test, staging, and production).
    • Společnost nechce spravovat role nezávisle na těchto třech hlavních prostředích, proto vyžaduje použití jenom integrovaných rolí , které jsou dostupné v řízení přístupu na základě role Azure (Azure RBAC).The enterprise does not want to have to manage roles independently in each of the three main environments, and therefore requires the use of only built-in roles available in Azure role-based access control (Azure RBAC). Pokud podnik naprosto vyžaduje vlastní role, bude potřeba další procesy pro synchronizaci vlastních rolí v rámci tří prostředí.If the enterprise absolutely requires custom roles, additional processes would be needed to synchronize custom roles across the three environments.
  • Sledování nákladů podle názvu vlastníka úlohy, prostředí nebo obojího.Cost tracking by workload owner name, environment, or both.

Správa identitIdentity management

Než budete moct navrhovat správu identit pro model zásad správného řízení, je důležité pochopit čtyři hlavní oblasti, které zahrnuje:Before you can design identity management for your governance model, it's important to understand the four major areas it encompasses:

  • Správa: Procesy a nástroje pro vytváření, úpravy a odstraňování identity uživatele.Administration: The processes and tools for creating, editing, and deleting user identity.
  • Ověřování: Ověřování identity uživatele pomocí ověřování přihlašovacích údajů, jako je uživatelské jméno a heslo.Authentication: Verifying user identity by validating credentials, such as a user name and password.
  • Autorizace: Určení prostředků, ke kterým má ověřený uživatel přístup, nebo operací, ke kterým mají oprávnění provádět.Authorization: Determining which resources an authenticated user is allowed to access or what operations they have permission to perform.
  • Auditování: Pravidelně kontrolujte protokoly a další informace a zjistěte problémy zabezpečení související s identitou uživatele.Auditing: Periodically reviewing logs and other information to discover security issues related to user identity. To zahrnuje kontrolu na podezřelé vzorce používání, pravidelnou kontrolu uživatelských oprávnění, abyste ověřili, že jsou správné a další funkce.This includes reviewing suspicious usage patterns, periodically reviewing user permissions to verify they're accurate, and other functions.

Služba Azure pro identitu důvěřuje jenom jedné službě, která je Azure Active Directory (Azure AD).There is only one service trusted by Azure for identity, and that is Azure Active Directory (Azure AD). Do Azure AD přidáte uživatele a použijete je pro všechny výše uvedené funkce.You'll be adding users to Azure AD and using it for all of the functions listed above. Než začnete s postupem konfigurace Azure AD, je důležité pochopit privilegované účty, které se používají ke správě přístupu k těmto službám.Before looking at how to configure Azure AD, it's important to understand the privileged accounts that are used to manage access to these services.

Pokud se vaše organizace zaregistrovala k účtu Azure, byl přiřazen alespoň jeden vlastník účtu Azure.When your organization signed up for an Azure account, at least one Azure account owner was assigned. Také byl vytvořen tenant služby Azure AD, pokud již nebyl stávající tenant přidružen k používání jiných služeb společnosti Microsoft, jako je například Microsoft 365.Also, an Azure AD tenant was created, unless an existing tenant was already associated with your organization's use of other Microsoft services such as Microsoft 365. Globální správce s úplnými oprávněními k TENANTOVI Azure AD byl přidružen při vytvoření.A global administrator with full permissions on the Azure AD tenant was associated when it was created.

Identity uživatelů pro vlastníka účtu Azure i globálního správce služby Azure AD jsou uložené ve vysoce zabezpečeném systému identit, který je spravovaný Microsoftem.The user identities for both the Azure account owner and the Azure AD Global Administrator are stored in a highly secure identity system that is managed by Microsoft. Vlastník účtu Azure má oprávnění k vytváření, aktualizaci a odstraňování předplatných.The Azure account owner is authorized to create, update, and delete subscriptions. Globální správce Azure AD má oprávnění provádět mnoho akcí v Azure AD, ale v tomto průvodci se zaměříte na vytváření a odstraňování identity uživatelů.The Azure AD Global Administrator is authorized to perform many actions in Azure AD, but for this design guide you'll focus on the creation and deletion of user identity.

Poznámka

Vaše organizace už může mít existujícího tenanta Azure AD, pokud existuje stávající licence Microsoft 365, Intune nebo Dynamics 365, která je přidružená k vašemu účtu.Your organization may already have an existing Azure AD tenant if there's an existing Microsoft 365, Intune, or Dynamics 365 license associated with your account.

Vlastník účtu Azure má oprávnění k vytváření, aktualizaci a odstraňování předplatných:The Azure account owner has permission to create, update, and delete subscriptions:

Diagram znázorňující účet Azure s vlastníkem účtu Azure a globálním správcem služby Azure AD. Obrázek 1: účet Azure s vlastníkem účtu Azure a globálním správcem služby Azure AD.Diagram showing an Azure account with an Azure account owner and Azure AD global admin. Figure 1: An Azure account with an Azure account owner and Azure AD global administrator.

Globální správce Azure AD má oprávnění k vytváření uživatelských účtů:The Azure AD global administrator has permission to create user accounts:

Diagram znázorňující, že globální správce Azure AD vytvoří v tenantovi požadované uživatelské účty. Obrázek 2: globální správce Azure AD vytvoří v tenantovi požadované uživatelské účty.Diagram showing that the Azure AD global administrator creates the required user accounts in the tenant. Figure 2: The Azure AD global administrator creates the required user accounts in the tenant.

První dva účty, vlastník úlohy app1 a vlastník úlohy app2, jsou přidruženy k jednotlivcům ve vaší organizaci, která je odpovědná za správu úlohy.The first two accounts, app1 workload owner and app2 workload owner, are each associated with an individual in your organization responsible for managing a workload. Účet síťových operací vlastní osoba, která je zodpovědná za sdílené prostředky infrastruktury.The network operations account is owned by the individual that is responsible for the shared infrastructure resources. Nakonec je účet vlastníka předplatného přidružený k osobě zodpovědné za vlastnictví předplatných.Finally, the subscription owner account is associated with the individual responsible for ownership of subscriptions.

Model oprávnění přístupu k prostředkům s nejnižším oprávněnímResource access permissions model of least privilege

Teď, když jste vytvořili váš systém správy identit a uživatelské účty, se musíte rozhodnout, jak použít role Azure u každého účtu za účelem podpory modelu oprávnění s nejnižšími oprávněními.Now that your identity management system and user accounts have been created, you have to decide how to apply Azure roles to each account to support a permissions model of least privilege.

Existuje další požadavek, který uvádí, že prostředky přidružené ke každé úloze jsou izolované od sebe, takže nikdo jiný vlastník úlohy nemá přístup pro správu k žádným jiným úlohám, které nevlastní.There's another requirement stating the resources associated with each workload be isolated from one another such that no one workload owner has management access to any other workload they do not own. Je taky potřeba implementovat tento model jenom pomocí integrovaných rolí řízení přístupu na základě role Azure.There's also a requirement to implement this model using only built-in roles for Azure role-based access control.

Každá role Azure se používá v jednom ze tří oborů v Azure: předplatné, Skupina prostředků a pak jeden prostředek.Each Azure role is applied at one of three scopes in Azure: subscription, resource group, then an individual resource. Role jsou zděděné v nižších oborech.Roles are inherited at lower scopes. Pokud má uživatel například přiřazenou předdefinovanou roli vlastníka na úrovni předplatného, tato role je přiřazená i pro daného uživatele ve skupině prostředků a na úrovni jednotlivých prostředků, pokud není přepsána.For example, if a user is assigned the built-in Owner role at the subscription level, that role is also assigned to that user at the resource group and individual resource level unless overridden.

Proto pokud chcete vytvořit model s nejnižším oprávněním, je nutné určit akce, které může určitý typ uživatele provést v každém z těchto tří oborů.Therefore, to create a model of least-privilege access you have to decide the actions a particular type of user is allowed to take at each of these three scopes. Požadavek je například na to, aby vlastník úlohy měl oprávnění ke správě přístupu pouze k prostředkům přidruženým ke svým úlohám a žádnému z dalších.For example, the requirement is for a workload owner to have permission to manage access to only the resources associated with their workload and no others. Pokud jste přidělili integrovanou roli vlastníka v oboru předplatného, bude mít každý vlastník úlohy přístup pro správu ke všem úlohám.If you were to assign the built-in Owner role at the subscription scope, each workload owner would have management access to all workloads.

Pojďme se podívat na dva příklady modelů oprávnění, abyste tento koncept pochopili trochu lépe.Let's take a look at two example permission models to understand this concept a little better. V prvním příkladu model důvěřuje jenom správci služby a vytvoří skupiny prostředků.In the first example, the model trusts only the Service Administrator to create resource groups. V druhém příkladu model přiřadí předdefinované role vlastníka pro každého vlastníka úlohy v oboru předplatného.In the second example, the model assigns the built-in Owner role to each workload owner at the subscription scope.

V obou příkladech je k dispozici Správce služby předplatného, kterému je přiřazena předdefinovaná role vlastníka v oboru předplatného.In both examples, there is a subscription Service Administrator that is assigned the built-in Owner role at the subscription scope. Odvolat, že předdefinovaná role vlastníka uděluje všechna oprávnění, včetně správy přístupu k prostředkům.Recall that the built-in Owner role grants all permissions including the management of access to resources.

Správce služby předplatného s hodnotou role vlastníka Obrázek 3: předplatné se správcem služby, kterému je přiřazená předdefinovaná role vlastníka.Subscription service administrator with owner role Figure 3: A subscription with a Service Administrator assigned the built-in Owner role.

  1. V prvním příkladu vlastník úlohy a nemá žádná oprávnění v oboru předplatného a ve výchozím nastavení nejsou k dispozici žádná práva pro správu přístupu k prostředkům.In the first example, workload owner A has no permissions at the subscription scope and no resource access management rights by default. Tento uživatel chce nasadit a spravovat prostředky pro své úlohy.This user wants to deploy and manage the resources for their workload. Musí požádat Správce služby o vytvoření skupiny prostředků.They must contact the service administrator to request creation of a resource group. Vlastník úlohy vyžádá vytvoření skupiny prostředků A.Workload owner requests creation of resource group A
  2. Správce služby zkontroluje svůj požadavek a vytvoří skupinu prostředků a. V tuto chvíli vlastník úlohy stále nemá oprávnění dělat cokoli.The service administrator reviews their request and creates resource group A. At this point, workload owner A still doesn't have permission to do anything. Správce služby vytvoří skupinu prostředků A.Service administrator creates resource group A
  3. Správce služby přidá vlastníka úlohy a do skupiny prostředků a a přiřadí integrovanou roli přispěvatele.The service administrator adds workload owner A to resource group A and assigns the built-in Contributor role. Role přispěvatele uděluje všechna oprávnění pro skupinu prostředků A s výjimkou oprávnění ke správě přístupu.The Contributor role grants all permissions on resource group A except managing access permission. Správce služby přidá vlastníka úlohy A do skupiny prostředků A.Service administrator adds workload owner A to resource group A
  4. Řekněme, že vlastník úlohy A má požadavek na pár členů týmu, aby zobrazili data monitorování procesoru a sítě v rámci plánování kapacity pro zatížení.Let's assume that workload owner A has a requirement for a pair of team members to view the CPU and network traffic monitoring data as part of capacity planning for the workload. Vzhledem k tomu, že vlastník úlohy a má přiřazenou roli přispěvatel, nemají oprávnění přidat uživatele do skupiny prostředků a. Tyto požadavky musí odeslat Správci služby.Because workload owner A is assigned the Contributor role, they do not have permission to add a user to resource group A. They must send this request to the service administrator. Vlastník úlohy požaduje, aby se přispěvatelé úloh přidaly do skupiny prostředků.Workload owner requests workload contributors be added to resource group
  5. Správce služby tuto žádost zkontroluje a přidá dva uživatele Přispěvatel úloh do skupiny prostředků a. Ani jeden z těchto dvou uživatelů nevyžaduje oprávnění ke správě prostředků, takže se jim přiřadí integrovaná role čtenáře.The service administrator reviews the request, and adds the two workload contributor users to resource group A. Neither of these two users require permission to manage resources, so they're assigned the built-in Reader role. Správce služeb přidá přispěvatele úloh do skupiny prostředků A.Service administrator adds workload contributors to resource group A
  6. V dalším kroku vlastník úlohy B také vyžaduje, aby skupina prostředků obsahovala prostředky pro jejich úlohy.Next, workload owner B also requires a resource group to contain the resources for their workload. Stejně jako vlastník úlohy a, vlastník úlohy B zpočátku nemá oprávnění k provedení jakékoli akce v oboru předplatného, takže musí odeslat žádost Správci služby.As with workload owner A, workload owner B initially does not have permission to take any action at the subscription scope so they must send a request to the service administrator. Vlastník úlohy B vyžádá vytvoření skupiny prostředků B.Workload owner B requests creation of resource group B
  7. Správce služby zkontroluje požadavek a vytvoří skupinu prostředků B. Správce služby vytvoří skupinu prostředků B.The service administrator reviews the request and creates resource group B. Service administrator creates resource group B
  8. Správce služby pak přidá vlastníka úlohy b do skupiny prostředků b a přiřadí integrovanou roli přispěvatele.The service administrator then adds workload owner B to resource group B and assigns the built-in Contributor role. Správce služby přidá vlastníka úlohy B do skupiny prostředků B.Service administrator adds workload owner B to resource group B

V tomto okamžiku jsou jednotlivé vlastníky úloh izolované ve vlastní skupině prostředků.At this point, each of the workload owners is isolated in their own resource group. Žádný z vlastníků úloh nebo jejich členové týmu nemají přístup ke správě prostředků v žádné jiné skupině prostředků.None of the workload owners or their team members have management access to the resources in any other resource group.

Diagram znázorňující předplatné se skupinami prostředků a a B. Obrázek 4: předplatné se dvěma vlastníky úloh, které jsou izolované s vlastní skupinou prostředků.A diagram showing a subscription with resource groups A and B. Figure 4: a subscription with two workload owners isolated with their own resource group.

Tento model je model s nejnižšími oprávněními.This model is a least-privilege model. Každému uživateli je přiřazeno správné oprávnění v oboru správného řízení prostředků.Each user is assigned the correct permission at the correct resource management scope.

Vezměte v úvahu, že každý úkol v tomto příkladu byl proveden správcem služby.Consider that every task in this example was performed by the service administrator. I když se jedná o jednoduchý příklad a nemusí se jednat o problém, protože existovaly jenom dva vlastníci úloh, můžete si snadno představit typy problémů, které by měly být výsledkem velké organizace.While this is a simple example and may not appear to be an issue because there were only two workload owners, it's easy to imagine the types of issues that would result for a large organization. Správce služby se například může stát kritickým bodem s velkým počtem nevyřízených položek žádostí, jejichž výsledkem budou zpoždění.For example, the service administrator can become a bottleneck with a large backlog of requests that result in delays.

Pojďme se podívat na druhý příklad, který snižuje počet úloh provedených správcem služby.Let's take a look at second example that reduces the number of tasks performed by the service administrator.

  1. V tomto modelu má vlastník úlohy A přiřazenou předdefinovanou roli vlastníka v oboru předplatného, který jim umožní vytvořit vlastní skupinu prostředků: Skupina prostředků A. Správce služeb přidá vlastníka úlohy a k předplatnému.In this model, workload owner A is assigned the built-in Owner role at the subscription scope, enabling them to create their own resource group: resource group A. Service administrator adds workload owner A to subscription
  2. Když se vytvoří Skupina prostředků a, vlastník úlohy a se přidá ve výchozím nastavení a zdědí integrovanou roli vlastníka z oboru předplatného.When resource group A is created, workload owner A is added by default and inherits the built-in Owner role from the subscription scope. Vlastník úlohy vytvoří skupinu prostředků A.Workload owner A creates resource group A
  3. Předdefinovaná role vlastníka uděluje vlastníkovi úlohy oprávnění ke správě přístupu ke skupině prostředků.The built-in Owner role grants workload owner A permission to manage access to the resource group. Vlastník úlohy a přidává dva přispěvatele úloh a přiřadí jim integrovanou roli čtenářů.Workload owner A adds two workload contributors and assigns the built-in Reader role to each of them. Vlastník úlohy A přidává přispěvatele úlohWorkload owner A adds workload contributors
  4. Správce služby teď přidá vlastníka úlohy B k předplatnému s integrovanou rolí vlastníka.The Service Administrator now adds workload owner B to the subscription with the built-in Owner role. Správce služeb přidá vlastníka úlohy B k předplatnému.Service Administrator adds workload owner B to subscription
  5. Vlastník úlohy b vytvoří skupinu prostředků b a přidá se ve výchozím nastavení.Workload owner B creates resource group B and is added by default. Vlastník úlohy B pak zdědí integrovanou roli vlastníka z oboru předplatného.Again, workload owner B inherits the built-in Owner role from the subscription scope. Vlastník úlohy B vytvoří skupinu prostředků B.Workload owner B creates resource group B

Všimněte si, že v tomto modelu provedl Správce služby méně akcí než v prvním příkladu z důvodu delegování přístupu ke správě každé z individuálních vlastníků úloh.Note that in this model, the service administrator performed fewer actions than they did in the first example due to the delegation of management access to each of the individual workload owners.

Diagram znázorňující Správce služby a dva vlastníci úloh pro skupiny prostředků a a B. Obrázek 5: předplatné se správcem služeb a dvěma vlastníky úloh, které má přiřazenou předdefinovanou roli vlastníka.A diagram showing a Service Administrator and two workload owners for resource groups A and B. Figure 5: A subscription with a Service Administrator and two workload owners, all assigned the built-in Owner role.

Vzhledem k tomu, že vlastník úlohy a a vlastník úlohy B mají přiřazenou předdefinovanou roli vlastníka v oboru předplatného, mají každý z nich děděnou předdefinovanou roli vlastníka pro skupinu prostředků.Because both workload owner A and workload owner B are assigned the built-in Owner role at the subscription scope, they have each inherited the built-in Owner role for each other's resource group. To znamená, že nejen mají úplný přístup k prostředkům ostatních zdrojů, můžou taky delegovat přístup pro správu do skupin prostředků ostatních.This means that not only do they have full access to each other's resources, they can also delegate management access to each other's resource groups. Například vlastník úlohy B má práva k přidání dalšího uživatele do skupiny prostředků a a může jim přiřadit libovolnou roli, včetně předdefinované role vlastníka.For example, workload owner B has rights to add any other user to resource group A and can assign any role to them, including the built-in Owner role.

Pokud každý příklad porovnáte s požadavky, uvidíte, že oba příklady podporují jednoho důvěryhodného uživatele v oboru předplatného s oprávněním pro udělení přístupových práv k prostředkům pro tyto dva vlastníky úloh.If you compare each example to the requirements, you'll see that both examples support a single trusted user at the subscription scope with permission to grant resource access rights to the two workload owners. Každý ze dvou vlastníků úloh neměl ve výchozím nastavení přístup ke správě prostředků a vyžaduje, aby Správce služby explicitně přidělil oprávnění.Each of the two workload owners did not have access to resource management by default and required the service administrator to explicitly assign permissions to them. Pouze první příklad podporuje požadavek, aby prostředky přidružené k jednotlivým úlohám byly od sebe izolované, takže žádný vlastník úlohy nemá přístup k prostředkům žádné jiné úlohy.Only the first example supports the requirement that the resources associated with each workload are isolated from one another such that no workload owner has access to the resources of any other workload.

Model správy prostředkůResource management model

Teď, když jste navrhli model oprávnění s minimálním oprávněním, pojďme přejít na, abyste se mohli podívat na některé praktické aplikace těchto modelů zásad správného řízení.Now that you've designed a permissions model of least privilege, let's move on to take a look at some practical applications of these governance models. Navrácení z požadavků, které musíte podporovat v následujících třech prostředích:Recall from the requirements that you must support the following three environments:

  1. Prostředí sdílené infrastruktury: Skupina prostředků sdílených všemi úlohami.Shared infrastructure environment: A group of resources shared by all workloads. Jedná se o prostředky, jako jsou síťové brány, brány firewall a služby zabezpečení.These are resources such as network gateways, firewalls, and security services.
  2. Provozní prostředí: Několik skupin prostředků, které představují několik produkčních úloh.Production environment: Multiple groups of resources representing multiple production workloads. Tyto prostředky se používají pro hostování privátních a veřejných artefaktů aplikace.These resources are used to host the private and public-facing application artifacts. Tyto prostředky mají typicky nejpřísnější modely zásad správného řízení a zabezpečení, aby chránily prostředky, kód aplikace a data před neoprávněným přístupem.These resources typically have the tightest governance and security models to protect the resources, application code, and data from unauthorized access.
  3. Předprodukční prostředí: Několik skupin prostředků, které představují více úloh, které nejsou připravené k výrobě.Preproduction environment: Multiple groups of resources representing multiple non-production-ready workloads. Tyto prostředky se používají pro vývoj a testování a můžou mít ještě uvolněný model zásad správného řízení, který umožňuje zvýšenou flexibilitu vývojářů.These resources are used for development and testing, and may have a more relaxed governance model to enable increased developer agility. Zabezpečení těchto skupin by se mělo zvýšit, protože proces vývoje aplikace se přesune blíž k produkčnímu prostředí.Security within these groups should increase as the application development process moves closer to production.

Pro každé z těchto tří prostředí je potřeba sledovat nákladová data podle vlastníka úlohy, prostředí nebo obojího.For each of these three environments, there is a requirement to track cost data by workload owner, environment, or both. To znamená, že budete chtít znát průběžné náklady na sdílenou infrastrukturu, náklady vzniklé jednotlivcům v neprodukčním i produkčním prostředí a nakonec celkové náklady na nevýrobní a produkční prostředí.That is, you'll want to know the ongoing cost of the shared infrastructure, the costs incurred by individuals in both the nonproduction and production environments, and finally the overall cost of nonproduction and production environments.

Již jste se dozvěděli o tom, že prostředky jsou vymezeny na dvě úrovně: předplatné a Skupina prostředků.You have already learned that resources are scoped to two levels: subscription and resource group. Proto první rozhodnutí slouží k uspořádání prostředí podle předplatného.Therefore, the first decision is how to organize environments by subscription. K dispozici jsou pouze dvě možnosti: jedno nebo více předplatných.There are only two possibilities: a single subscription or multiple subscriptions.

Než se podíváte na příklady jednotlivých modelů, Podívejme se na strukturu správy předplatných v Azure.Before you look at examples of each of these models, let's review the management structure for subscriptions in Azure.

Nahlaste se od požadavků, které máte jednotlivce v organizaci, který je zodpovědný za předplatná, a tento uživatel je vlastníkem účtu vlastníka předplatného v TENANTOVI Azure AD.Recall from the requirements that you have an individual in the organization who is responsible for subscriptions, and this user owns the subscription owner account in the Azure AD tenant. Tento účet nemá oprávnění k vytváření předplatných.This account does not have permission to create subscriptions. Jenom vlastník účtu Azure má oprávnění k tomu:Only the Azure account owner has permission to do this:

Vlastník účtu Azure vytvoří předplatné na obrázku 6: vlastník účtu Azure vytvoří předplatné.An Azure account owner creates a subscription Figure 6: An Azure account owner creates a subscription.

Po vytvoření předplatného může vlastník účtu Azure přidat účet vlastníka předplatného k předplatnému s rolí vlastníka :Once the subscription has been created, the Azure account owner can add the subscription owner account to the subscription with the owner role:

Vlastník účtu Azure přidá uživatelský účet vlastníka předplatného k předplatnému s rolí vlastníka. Obrázek 7: vlastník účtu Azure přidá k předplatnému s rolí vlastníka uživatelský účet vlastníka předplatného.The Azure account owner adds the subscription owner user account to the subscription with the owner role. Figure 7: The Azure account owner adds the subscription owner user account to the subscription with the owner role.

Účet vlastníka předplatného teď může vytvářet skupiny prostředků a delegovat správu přístupu k prostředkům.The subscription owner account can now create resource groups and delegate resource access management.

Nejdřív se podíváme na ukázkový model správy prostředků s použitím jediného předplatného.First let's look at an example resource management model using a single subscription. Prvním rozhodnutím je postup, jak zarovnat skupiny prostředků do tří prostředí.The first decision is how to align resource groups to the three environments. Máte dvě možnosti:You have two options:

  1. Jednotlivá prostředí zarovnejte do jedné skupiny prostředků.Align each environment to a single resource group. Všechny prostředky sdílené infrastruktury se nasazují do jedné sdílené skupiny prostředků infrastruktury.All shared infrastructure resources are deployed to a single shared infrastructure resource group. Všechny prostředky přidružené k úlohám vývoje se nasazují do jedné vývojářské skupiny prostředků.All resources associated with development workloads are deployed to a single development resource group. Všechny prostředky přidružené k produkčním úlohám se nasazují do jedné produkční skupiny prostředků pro produkční prostředí.All resources associated with production workloads are deployed into a single production resource group for the production environment.
  2. Vytvořte samostatné skupiny prostředků pro každou úlohu a pomocí konvence pojmenování a značek zarovnejte skupiny prostředků se všemi třemi prostředími.Create separate resource groups for each workload, using a naming convention and tags to align resource groups with each of the three environments.

Pojďme začít vyhodnocením první možnosti.Let's begin by evaluating the first option. Budete používat model oprávnění, který byl popsán v předchozí části, s jedním správcem služby předplatného, který vytvoří skupiny prostředků a přidá k nim uživatele buď pomocí předdefinované role Přispěvatel nebo Čtenář .You'll be using the permissions model that was discussed in the previous section, with a single subscription Service Administrator who creates resource groups and adds users to them with either the built-in contributor or reader role.

  1. První nasazená skupina prostředků představuje prostředí sdílené infrastruktury .The first resource group deployed represents the shared infrastructure environment. Účet vlastníka předplatného vytvoří skupinu prostředků pro sdílené prostředky infrastruktury s názvem netops-shared-rg .The subscription owner account creates a resource group for the shared infrastructure resources named netops-shared-rg. Vytvoření skupiny prostředkůCreating a resource group
  2. Účet vlastníka předplatného přidá uživatelský účet síťové operace do skupiny prostředků a přiřadí roli přispěvatele .The subscription owner account adds the network operations user account to the resource group and assigns the contributor role. Přidání uživatele síťových operacíAdding a network operations user
  3. Uživatel síťové operace vytvoří bránu VPN a nakonfiguruje ji pro připojení k místnímu zařízení VPN.The network operations user creates a VPN gateway and configures it to connect to the on-premises VPN appliance. Uživatel síťových operací také pro každý z prostředků používá dvojici značek : environment:shared a managedBy:netops .The network operations user also applies a pair of tags to each of the resources: environment:shared and managedBy:netops. Když Správce služby předplatného exportuje sestavu nákladů, budou náklady zarovnány s každou z těchto značek.When the subscription service administrator exports a cost report, costs will be aligned with each of these tags. To umožňuje Správci služby předplatného pivotovat náklady pomocí environment značky a managedBy značky.This allows the subscription service administrator to pivot costs using the environment tag and the managedBy tag. Všimněte si počítadla omezení prostředků v pravém horním rohu obrázku.Notice the resource limits counter at the top right-hand side of the figure. Každé předplatné Azure má omezení službya pomůže vám pochopit dopad těchto omezení, které se řídí limitem virtuální sítě pro každé předplatné.Each Azure subscription has service limits, and to help you understand the effect of these limits you'll follow the virtual network limit for each subscription. U každého předplatného je povolený limit 1 000 virtuálních sítí a po nasazení první virtuální sítě je teď k dispozici 999.There is a limit of 1,000 virtual networks per subscription, and after the first virtual network is deployed there are now 999 available. Vytváření služby VPN GatewayCreating a VPN gateway
  4. Nasadí se další dvě skupiny prostředků.Two more resource groups are deployed. První má název prod-rg .The first is named prod-rg. Tato skupina prostředků je zarovnána s provozním prostředím.This resource group is aligned with the production environment. Druhý má název dev-rg a je zarovnán s vývojovým prostředím.The second is named dev-rg and is aligned with the development environment. Všechny prostředky přidružené k produkčním úlohám se nasazují do provozního prostředí a všechny prostředky přidružené k úlohám vývoje se nasazují do vývojového prostředí.All resources associated with production workloads are deployed to the production environment and all resources associated with development workloads are deployed to the development environment. V tomto příkladu nasadíte do každého z těchto dvou prostředí jenom dvě úlohy, takže nebudete mít žádná omezení služby předplatného Azure.In this example, you'll only deploy two workloads to each of these two environments, so you won't encounter any Azure subscription service limits. Vezměte v úvahu, že každá skupina prostředků má omezení 800 prostředků na skupinu prostředků.Consider that each resource group has a limit of 800 resources per resource group. Pokud budete do každé skupiny prostředků dál přidávat úlohy, můžete toto omezení nakonec dosáhnout.If you continue to add workloads to each resource group, you'll eventually reach this limit. Vytváření skupin prostředkůCreating resource groups
  5. První vlastník úlohy pošle požadavek Správci služby předplatného a přidá se do každé skupiny prostředků vývojového a produkčního prostředí s rolí Přispěvatel .The first workload owner sends a request to the subscription service administrator and is added to each of the development and production environment resource groups with the contributor role. Jak už jste se naučili, role přispěvatele umožňuje uživateli provádět jakoukoli jinou operaci než přiřazení role jinému uživateli.As you learned earlier, the contributor role allows the user to perform any operation other than assigning a role to another user. První vlastník úlohy teď může vytvořit prostředky přidružené ke svým úlohám.The first workload owner can now create the resources associated with their workload. Diagram znázorňující, že první vlastník úlohy vytváří virtuální sítě a používá prostředí a spravuje je pomocí značek pro všechny prostředky.Diagram showing the first workload owner creating virtual networks and applying the environment and managed By tags to all resources.
  6. První vlastník úlohy vytvoří virtuální síť v každé ze dvou skupin prostředků s dvojicí virtuálních počítačů v každém z nich.The first workload owner creates a virtual network in each of the two resource groups with a pair of virtual machines in each. První vlastník úlohy používá environment managedBy značky a pro všechny prostředky.The first workload owner applies the environment and managedBy tags to all resources. Všimněte si, že čítač limit služby Azure je teď ve zbývajících 997 virtuálních sítích.Note that the Azure service limit counter is now at 997 virtual networks remaining. Vytváření virtuálních sítíCreating virtual networks
  7. Žádná z virtuálních sítí nemá při vytváření připojení k místní síti.None of the virtual networks has connectivity to on-premises when created. V tomto typu architektury musí být každá virtuální síť navázána na partnerský vztah hub-vnet v prostředí sdílené infrastruktury .In this type of architecture, each virtual network must be peered to the hub-vnet in the shared infrastructure environment. Partnerský vztah virtuálních sítí vytvoří připojení mezi dvěma oddělenými virtuálními sítěmi a umožňuje mezi nimi procházet síťový provoz.Virtual network peering creates a connection between two separate virtual networks and allows network traffic to travel between them. Všimněte si, že partnerský vztah virtuálních sítí není ve své podstatě přenosný.Note that virtual network peering is not inherently transitive. Partnerský vztah musí být zadán v každé ze dvou připojených virtuálních sítí, a pokud pouze jedna z těchto virtuálních sítí Určuje partnerský vztah, připojení je neúplné.A peering must be specified in each of the two virtual networks that are connected, and if only one of the virtual networks specifies a peering, then the connection is incomplete. Pro ilustraci tohoto efektu určuje první vlastník úlohy partnerský vztah mezi prod-vnet a hub-vnet .To illustrate the effect of this, the first workload owner specifies a peering between prod-vnet and hub-vnet. Vytvoří se první partnerský vztah, ale žádné toky provozu, protože se hub-vnet ještě nezadal doplňkový partnerský vztah od do prod-vnet .The first peering is created, but no traffic flows because the complementary peering from hub-vnet to prod-vnet has not yet been specified. První vlastník úlohy kontaktuje uživatele síťové operace a požádá o toto komplementární propojení partnerských vztahů.The first workload owner contacts the network operations user and requests this complementary peering connection. Diagram, který znázorňuje vytvoření připojení typu og.Diagram that shows the creation og a peering connection.
  8. Síťové operace kontrolují požadavek, schválí ho a pak určí partnerské vztahy v nastavení pro hub-vnet .The network operations user reviews the request, approves it, then specifies the peering in the settings for the hub-vnet. Připojení partnerského vztahu je nyní dokončeno a síťové přenosy mezi těmito dvěma virtuálními sítěmi.The peering connection is now complete, and network traffic flows between the two virtual networks. Diagram znázorňující schválení žádosti a určení nastavení partnerského vztahu.Diagram showing the approval of the request and the specifying of the peering settings.
  9. Teď druhý vlastník úlohy pošle požadavek Správci služby předplatného a přidá se do existující skupiny prostředků produkčního a vývojového prostředí s rolí Přispěvatel .Now, a second workload owner sends a request to the subscription service administrator and is added to the existing production and development environment resource groups with the contributor role. Druhý vlastník úlohy má stejná oprávnění pro všechny prostředky jako první vlastník úlohy v každé skupině prostředků.The second workload owner has the same permissions on all resources as the first workload owner in each resource group. Diagram znázorňující, že se druhý vlastník úlohy přidávají do skupin prostředků.Diagram showing the second workload owner being added to teh resource groups.
  10. Druhý vlastník úlohy vytvoří podsíť ve prod-vnet virtuální síti a pak přidá dva virtuální počítače.The second workload owner creates a subnet in the prod-vnet virtual network, then adds two virtual machines. Druhý vlastník úlohy používá environment managedBy pro každý prostředek značky a.The second workload owner applies the environment and managedBy tags to each resource. Vytváření podsítíCreating subnets

Tento ukázkový model správy prostředků nám umožňuje spravovat prostředky ve třech požadovaných prostředích.This example resource management model enables us to manage resources in the three required environments. Sdílené prostředky infrastruktury jsou chráněné, protože oprávnění pro přístup k těmto prostředkům mají jenom jednotliví uživatelé v rámci předplatného.The shared infrastructure resources are protected because only a single user in the subscription has permission to access those resources. Každý vlastník úlohy může použít sdílené prostředky infrastruktury bez jakýchkoli oprávnění ke sdíleným prostředkům.Each of the workload owners can use the shared infrastructure resources without having any permissions on the shared resources themselves. Tento model správy nesplňuje požadavky na izolaci úloh, protože jak vlastníci úloh mají přístup k prostředkům jednotlivých úloh.This management model fails the requirement for workload isolation, because both workload owners can access the resources of each other's workload.

Tento model má další důležité hledisko, které nemusí být okamžitě zřejmé.There's another important consideration with this model that may not be immediately obvious. V tomto příkladu byl app1 vlastník úlohy , který požádal o připojení partnerského vztahu k síti s tím, hub-vnet aby poskytoval připojení k místní síti.In the example, it was app1 workload owner that requested the network peering connection with the hub-vnet to provide connectivity to the on-premises network. Síťové operace vyhodnotily požadavek na základě prostředků nasazených s touto úlohou.The network operations user evaluated that request based on the resources deployed with that workload. Když se účtu vlastníka předplatného přidalo vlastník úlohy app2 k roli Přispěvatel , měl by mít tento uživatel práva pro správu pro všechny prostředky ve prod-rg skupině prostředků.When the subscription owner account added app2 workload owner with the contributor role, that user had management access rights to all resources in the prod-rg resource group.

Diagram znázorňující přístupová práva pro správu

To znamená, že vlastník úlohy app2 měl oprávnění k nasazení vlastní podsítě s virtuálními počítači ve prod-vnet virtuální síti.This means app2 workload owner had permission to deploy their own subnet with virtual machines in the prod-vnet virtual network. Ve výchozím nastavení mají tyto virtuální počítače přístup k místní síti.By default, those virtual machines have access to the on-premises network. Uživatel síťových operací si tyto počítače neví a neschválil své připojení k místnímu prostředí.The network operations user is not aware of those machines and did not approve their connectivity to on-premises.

Teď se podívejme na jedno předplatné s několika skupinami prostředků pro různá prostředí a úlohy.Next, let's look at a single subscription with multiple resource groups for different environments and workloads. Všimněte si, že v předchozím příkladu byly prostředky pro každé prostředí snadno identifikovatelné, protože byly ve stejné skupině prostředků.Note that in the previous example, the resources for each environment were easily identifiable because they were in the same resource group. Teď, když už toto seskupení nemusíte, budete muset spoléhat na zásady vytváření názvů skupin prostředků, které tuto funkci poskytují.Now that you no longer have that grouping, you will have to rely on a resource group naming convention to provide that functionality.

  1. Prostředky sdílené infrastruktury budou mít v tomto modelu stále samostatnou skupinu prostředků, takže to zůstane stejné.The shared infrastructure resources will still have a separate resource group in this model, so that remains the same. Každé zatížení vyžaduje dvě skupiny prostředků, jednu pro každé vývojové a produkční prostředí.Each workload requires two resource groups, one for each of the development and production environments. Pro první úlohu vytvoří účet vlastníka předplatného dvě skupiny prostředků.For the first workload, the subscription owner account creates two resource groups. První má název app1-prod-rg a druhý má název app1-dev-rg .The first is named app1-prod-rg and the second is named app1-dev-rg. Jak už bylo popsáno výše, Tato konvence vytváření názvů identifikuje prostředky, které jsou přidruženy k prvnímu zatížení, app1 a buď vývojové , nebo produkční prostředí.As discussed earlier, this naming convention identifies the resources as being associated with the first workload, app1, and either the development or production environment. Účet vlastníka předplatného znovu přidá vlastníka úlohy app1 do skupiny prostředků s rolí Přispěvatel .Again, the subscription owner account adds app1 workload owner to the resource group with the contributor role. Diagram znázorňující přidání aplikace 1: Skupina prostředků r g a aplikace 1 dev r g.A diagram showing the addition of the app 1 prod r g and app 1 dev r g resource groups.
  2. Podobně jako v prvním příkladu vlastník úlohy app1 nasadí virtuální síť s názvem app1-prod-vnet do provozního prostředí a další s názvem app1-dev-vnet do vývojového prostředí.Similar to the first example, app1 workload owner deploys a virtual network named app1-prod-vnet to the production environment, and another named app1-dev-vnet to the development environment. Vlastník úlohy app1 znovu odešle požadavek na uživatele síťové operace , aby vytvořil připojení partnerského vztahu.Again, app1 workload owner sends a request to the network operations user to create a peering connection. Všimněte si, že vlastník úlohy app1 přidá stejné značky jako v prvním příkladu a čítač limit byl snížen na 997 virtuálních sítí zbývajících v rámci předplatného.Note that app1 workload owner adds the same tags as in the first example, and the limit counter has been decremented to 997 virtual networks remaining in the subscription. Diagram znázorňující nasazení aplikace 1 v produkčním prostředí a aplikace 1 dev v NET Virtual Networks.A diagram showing the deployment of the app 1 prod v net and app 1 dev v net virtual networks.
  3. Účet vlastníka předplatného teď vytvoří dvě skupiny prostředků pro vlastníka úloh app2.The subscription owner account now creates two resource groups for app2 workload owner. V rámci stejných konvencí jako u vlastníka úloh app1 se skupiny prostředků nazývají app2-prod-rg a app2-dev-rg .Following the same conventions as for app1 workload owner, the resource groups are named app2-prod-rg and app2-dev-rg. Účet vlastníka předplatného přidá do každé skupiny prostředků v roli přispěvatele vlastníka úlohy app2 .The subscription owner account adds app2 workload owner to each of the resource groups with the contributor role. Diagram znázorňující přidání skupiny prostředků ve skupině r g a App 2 pro vývoj v rámci aplikace 2.A diagram showing the addition of the app 2 prod r g and app 2 dev r g resource groups.
  4. Účet vlastníka úlohy app2 nasadí virtuální sítě a virtuální počítače do skupin prostředků se stejnými konvencemi vytváření názvů.The app2 workload owner account deploys virtual networks and virtual machines to the resource groups with the same naming conventions. Přidávají se značky a čítač limit byl snížen na 995 virtuálních sítí zbývajících v rámci předplatného.Tags are added and the limit counter has been decremented to 995 virtual networks remaining in the subscription. Nasazení virtuálních sítí a virtuálních počítačůDeploying virtual networks and VMs
  5. Účet vlastníka úlohy app2 odešle požadavek na uživatele síťové operace , aby se napředal app2-prod-vnet s hub-vnet .The app2 workload owner account sends a request to the network operations user to peer the app2-prod-vnet with the hub-vnet. Síťové operace vytvoří připojení partnerského vztahu.The network operations user creates the peering connection. Diagram znázorňující partnerský vztah aplikace 2 prod. verze s centrem sítě v netto.A diagram showing the peering of app 2 prod v net with the hub v net.

Výsledný model správy je podobný prvnímu příkladu s několika klíčovými rozdíly:The resulting management model is similar to the first example, with several key differences:

  • Každá ze dvou úloh je izolována úlohou a prostředím.Each of the two workloads is isolated by workload and by environment.
  • Tento model vyžadoval dvě virtuální sítě, než je první Vzorový model.This model required two more virtual networks than the first example model. I když se nejedná o důležitý rozdíl pouze se dvěma úlohami, teoretický limit počtu úloh pro tento model je 24.While this is not an important distinction with only two workloads, the theoretical limit on the number of workloads for this model is 24.
  • Prostředky se už neseskupují do jedné skupiny prostředků pro každé prostředí.Resources are no longer grouped in a single resource group for each environment. Seskupení prostředků vyžaduje porozumění konvencím pojmenování používaných pro každé prostředí.Grouping resources requires an understanding of the naming conventions used for each environment.
  • Každé připojení s partnerskými virtuálními sítěmi bylo zkontrolováno a schváleno uživatelem síťové operace.Each of the peered virtual network connections was reviewed and approved by the network operations user.

Teď se podívejme na model správy prostředků s použitím několika předplatných.Now let's look at a resource management model using multiple subscriptions. V tomto modelu zarovnáváte každé ze tří prostředí do samostatného předplatného: předplatné sdílených služeb , produkční předplatné a nakonec vývojové předplatné.In this model, you'll align each of the three environments to a separate subscription: a shared services subscription, production subscription, and finally a development subscription. Požadavky pro tento model se podobají modelu s použitím jediného předplatného, které je potřeba rozhodnout o tom, jak se skupiny prostředků zarovnají s úlohami.The considerations for this model are similar to a model using a single subscription in that you have to decide how to align resource groups to workloads. Již bylo zjištěno, že vytvoření skupiny prostředků pro každou úlohu splňuje požadavek na izolaci úloh, takže v tomto příkladu vytvoříte tento model.Already determined is that creating a resource group for each workload satisfies the workload isolation requirement, so you'll stick with that model in this example.

  1. V tomto modelu existují tři předplatná: sdílená infrastruktura, produkce a vývoj.In this model, there are three subscriptions: shared infrastructure, production, and development. Každé z těchto tří předplatných vyžaduje vlastníka předplatného a v jednoduchém příkladu použijete stejný uživatelský účet pro všechny tři.Each of these three subscriptions requires a subscription owner, and in the simple example you'll use the same user account for all three. Sdílené prostředky infrastruktury se spravují podobně jako první dva příklady a první úloha je přidružená ke app1-rg skupině prostředků v provozním prostředí a skupině prostředků se stejným názvem ve vývojovém prostředí.The shared infrastructure resources are managed similarly to the first two examples above, and the first workload is associated with the app1-rg resource group in the production environment and the same-named resource group in the development environment. Účet vlastníka úlohy app1 se přidá do každé skupiny prostředků s rolí Přispěvatel .The app1 workload owner account is added to each of the resource group with the contributor role.

    Diagram znázorňující, jak se spravují prostředky sdílené infrastruktury

  2. Stejně jako v předchozích příkladech vytvoří vlastník úlohy app1 prostředky a požádá o připojení partnerského vztahu ke sdílené infrastruktuře virtuální sítě.As with the earlier examples, app1 workload owner creates the resources and requests the peering connection with the shared infrastructure virtual network. Účet vlastníka úlohy app1 přidá pouze značku, managedBy protože již není nutné používat environment značku.The app1 workload owner account adds only the managedBy tag because there is no longer a need for the environment tag. To znamená, že prostředky jsou pro každé prostředí seskupené do stejného předplatného a environment značka je redundantní.That is, resources are for each environment are now grouped in the same subscription and the environment tag is redundant. Čítač limit je snížen na 999 virtuálních sítí zbývá.The limit counter is decremented to 999 virtual networks remaining.

    Diagram znázorňující, že prostředky pro každé prostředí jsou nyní seskupeny do stejného předplatného.

  3. Nakonec účet vlastníka předplatného opakuje proces pro druhou úlohu a přidá skupiny prostředků s vlastníkem úloh app2 v roli přispěvatele .Finally, the subscription owner account repeats the process for the second workload, adding the resource groups with app2 workload owner in the contributor role. Čítač omezení pro každé předplatné prostředí se sníží na 998 virtuálních sítí.The limit counter for each of the environment subscriptions is decremented to 998 virtual networks remaining.

Tento model správy má výhody druhého výše uvedeného příkladu.This management model has the benefits of the second example above. Klíčovým rozdílem je to, že omezení jsou menší než problém, protože jsou rozdělená do dvou předplatných.The key difference is that limits are less of an issue due to the fact that they're spread over two subscriptions. Nevýhodou je, že data nákladů sledovaná pomocí značek musí být agregována ve všech třech předplatných.The drawback is that the cost data tracked by tags must be aggregated across all three subscriptions.

Proto můžete vybrat kterýkoli z těchto dvou příkladů modelů správy prostředků v závislosti na prioritě vašich požadavků.Therefore, you can select any of these two examples resource management models depending on the priority of your requirements. Pokud předpokládáte, že vaše organizace nedosáhne omezení služby pro jedno předplatné, můžete použít jedno předplatné s více skupinami prostředků.If you anticipate that your organization will not reach the service limits for a single subscription, you can use a single subscription with multiple resource groups. Naopak, pokud vaše organizace očekává mnoho úloh, může být více předplatných pro každé prostředí lepší.Conversely, if your organization anticipates many workloads, multiple subscriptions for each environment may be better.

Implementace modelu správy prostředkůImplement the resource management model

Seznámili jste se s několika různými modely pro řízení přístupu k prostředkům Azure.You've learned about several different models for governing access to Azure resources. Nyní vás provedete kroky potřebnými k implementaci modelu správy prostředků s jedním předplatným pro každou sdílenou infrastrukturu, produkční prostředí a vývoj prostředí z Průvodce návrhem.Now you'll walk through the steps necessary to implement the resource management model with one subscription for each of the shared infrastructure, production, and development environments from the design guide. Pro všechna tři prostředí budete mít jeden účet vlastníka předplatného .You'll have one subscription owner account for all three environments. Jednotlivé úlohy se budou izolovat ve skupině prostředků s vlastníkem úlohy přidaným s rolí přispěvatele .Each workload will be isolated in a resource group with a workload owner added with the contributor role.

Poznámka

Další informace o vztahu mezi účty a předplatnými Azure najdete v tématu Principy přístupu k prostředkům v Azure.To learn more about the relationship between Azure accounts and subscriptions, see Understanding resource access in Azure.

Postupujte takto:Follow these steps:

  1. Vytvořte si účet Azure , pokud ho vaše organizace ještě nemá.Create an Azure account if your organization doesn't already have one. Osoba, která se zaregistruje k účtu Azure, se stala správcem účtu Azure a vedoucí pracovník vaší organizace musí vybrat jednotlivce, aby tuto roli předpokládal.The person who signs up for the Azure account becomes the Azure account administrator, and your organization's leadership must select an individual to assume this role. Tato osoba bude zodpovědná za:This individual will be responsible for:
  2. Tým vedoucí organizace rozhodl, kdo zodpovídá za:Your organization's leadership team decides who is responsible for:
    • Správa identity uživatele; tenant Azure AD se ve výchozím nastavení vytvoří, když se vytvoří účet Azure vaší organizace a správce účtu se ve výchozím nastavení přidá jako globální správce Azure AD .Management of user identity; an Azure AD tenant is created by default when your organization's Azure account is created, and the account administrator is added as the Azure AD Global Administrator by default. Vaše organizace může pro správu identity uživatelů zvolit jiného uživatele tak , že k tomuto uživateli přiřadí roli globálního správce Azure AD.Your organization can choose another user to manage user identity by assigning the Azure AD Global Administrator role to that user.
    • Předplatná, což znamená tyto uživatele:Subscriptions, which means these users:
      • Spravujte náklady spojené s využitím prostředků v tomto předplatném.Manage costs associated with resource usage in that subscription.
      • Implementujte a udržujte nejméně model oprávnění pro přístup k prostředkům.Implement and maintain least permission model for resource access.
      • Udržujte si přehled o omezeních služeb.Keep track of service limits.
    • Sdílené služby infrastruktury (Pokud se vaše organizace rozhodne použít tento model), což znamená, že tento uživatel zodpovídá za:Shared infrastructure services (if your organization decides to use this model), which means this user is responsible for:
      • Připojení k síti Azure v místním prostředí.On-premises to Azure network connectivity.
      • Vlastnictví síťového připojení v rámci Azure prostřednictvím partnerského vztahu virtuálních sítí.Ownership of network connectivity within Azure through virtual network peering.
    • Vlastníci úloh.Workload owners.
  3. Globální správce Azure AD vytvoří nové uživatelské účty pro:The Azure AD Global Administrator creates the new user accounts for:
    • Osoba, která bude vlastníkem předplatného pro každé předplatné přidružené k jednotlivým prostředím.The person who will be the subscription owner for each subscription associated with each environment. Všimněte si, že to je nezbytné jenom v případě, že se Správce služby předplatného nebude řídit správou přístupu k prostředkům pro každé předplatné nebo prostředí.Note that this is necessary only if the subscription service administrator will not be tasked with managing resource access for each subscription/environment.
    • Osoba, která bude uživatel síťového provozu.The person who will be the network operations user.
    • Lidé, kteří jsou vlastníci úloh.The people who are workload owners.
  4. Správce účtu Azure vytvoří tři předplatná Azure:The Azure account administrator creates three Azure subscriptions:
    • Předplatné pro prostředí sdílené infrastrukturyA subscription for the shared infrastructure environment.
    • Předplatné pro produkční prostředí.A subscription for the production environment.
    • Předplatné pro vývojové prostředí.A subscription for the development environment.
  5. Správce účtu Azure přidá vlastníka služby předplatného do každého předplatného.The Azure account administrator adds the subscription service owner to each subscription.
  6. Vytvořte schvalovací proces pro vlastníky úloh , které vyžádají vytvoření skupin prostředků.Create an approval process for workload owners to request the creation of resource groups. Proces schvalování se dá implementovat mnoha způsoby, například přes e-maily, nebo můžete použít nástroj pro správu procesů, například pracovní postupy SharePointu.The approval process can be implemented in many ways, such as over email, or you can using a process management tool such as SharePoint workflows. Proces schvalování může postupovat podle těchto kroků:The approval process can follow these steps:
    • Vlastník úlohy připraví množství materiálů pro požadované prostředky Azure ve vývojovém prostředí, v produkčním prostředí nebo v obou a odešle je vlastníkovi předplatného.The workload owner prepares a bill of materials for required Azure resources in either the development environment, production environment, or both, and submits it to the subscription owner.
    • Vlastník předplatného zkontroluje množství materiálů a ověří požadované prostředky, aby bylo zajištěno, že požadované prostředky jsou vhodné pro plánované použití, například kontrolu správnosti velikosti požadovaných virtuálních počítačů .The subscription owner reviews the bill of materials and validates the requested resources to ensure that the requested resources are appropriate for their planned use, such as checking that the requested virtual machine sizes are correct.
    • Pokud žádost není schválena, vlastník úlohy se oznámí.If the request is not approved, the workload owner is notified. Pokud je žádost schválená, vlastník předplatného vytvoří požadovanou skupinu prostředků podle zásad vytváření názvůvaší organizace, přidá vlastníka úlohy přispěvateli a pošle oznámení vlastníkovi pracovního postupu, že se vytvořila skupina prostředků.If the request is approved, the subscription owner creates the requested resource group following your organization's naming conventions, adds the workload owner with the contributor role and sends notification to the workload owner that the resource group has been created.
  7. Vytvořte schvalovací proces pro vlastníky úloh, které vyžádají připojení partnerského vztahu virtuální sítě od vlastníka sdílené infrastruktury.Create an approval process for workload owners to request a virtual network peering connection from the shared infrastructure owner. Stejně jako v předchozím kroku se tento proces schvalování dá implementovat pomocí e-mailu nebo nástroje pro správu procesů.As with the previous step, this approval process can be implemented using email or a process management tool.

Teď, když jste implementovali model zásad správného řízení, můžete nasadit své sdílené služby infrastruktury.Now that you've implemented your governance model, you can deploy your shared infrastructure services.

Předdefinované role v AzureAzure built-in roles