Kurumsal Bulutu benimseme: Birden çok takım idare tasarımıEnterprise Cloud Adoption: Governance design for multiple teams

Bu kılavuz, azure'da birden çok takımda ve birden çok iş birden çok ortamı desteklemek için kaynak İdaresi model tasarlama işlemi öğrenmenize yardımcı olmaktır.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. Biz kuramsal idare gereksinimleri bir dizi Ara sonra bu gereksinimleri karşılayan birkaç örnek uygulamalar gidin.We'll look at a set of hypothetical governance requirements, then go through several example implementations that satisfy those requirements.

Gereksinimler şunlardır:The requirements are:

  • Kurumsal geçiş yeni bulut rolleri ve sorumlulukları kullanıcı planları ve bu nedenle azure'daki farklı kaynak erişim gereksinimlerine sahip birden çok takımı için Kimlik Yönetimi gerektirir.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. Bu kimlik yönetimi sistemi aşağıdaki kullanıcıların kimliklerini depolamak için gereklidir:This identity management system is required to store the identity of the following users:
    1. Kuruluşunuz için sahipliğini sorumlu ayrı ayrı abonelikleri.The individual in your organization responsible for ownership of subscriptions.
    2. Kuruluşunuz sorumlu için ayrı ayrı paylaşılan altyapı kaynaklarını şirket içi ağınızı bir Azure sanal ağına bağlanmak için kullanılır.The individual in your organization responsible for the shared infrastructure resources used to connect your on-premises network to an Azure virtual network.
    3. İki kişiler yönetmekten sorumlu, kuruluşunuzdaki bir iş yükü.Two individuals in your organization responsible for managing a workload.
  • Desteklemek için birden çok ortamları.Support for multiple environments. Bir ortamda sanal makineler, sanal ağ ve ağ trafiğini yönlendirme hizmetleri gibi kaynakları mantıksal bir gruplandırmasıdır.An environment is a logical grouping of resources, such as virtual machines, virtual networking, and network traffic routing services. Bu kaynak gruplarını benzer yönetim ve güvenlik gereksinimlerine sahiptir ve genellikle test veya üretim gibi belirli bir amaç için kullanılır.These groups of resources have similar management and security requirements and are typically used for a specific purpose such as testing or production. Bu örnekte, üç ortamları için bir gereksinimdir:In this example, the requirement is for three environments:
    1. A paylaşılan altyapı ortamı diğer ortamlarda iş yükleri tarafından paylaşılan kaynakları içerir.A shared infrastructure environment that includes resources shared by workloads in other environments. Örneğin, bir sanal ağ ile şirket içi bağlantı sağlayan ağ geçidi alt ağı.For example, a virtual network with a gateway subnet that provides connectivity to on-premises.
    2. A üretim ortamına en kısıtlayıcı güvenlik ilkeleri ile.A production environment with the most restrictive security policies. İç veya dış yönelik iş yüklerini içerebilir.May include internal or external facing workloads.
    3. A geliştirme ortamı kavram kanıtı ve test çalışması için.A development environment for proof-of-concept and testing work. Bu ortam, güvenlik, uyumluluk ve üretim ortamında farklı maliyet ilkeleri vardır.This environment has security, compliance, and cost policies that differ from those in the production environment.
  • A en düşük izinler modeli hangi kullanıcılar varsayılan olarak izin yok sahiptir.A permissions model of least privilege in which users have no permissions by default. Model aşağıdaki desteklemesi gerekir:The model must support the following:
    • Kaynak erişim hakları atamak için izne sahip abonelik kapsamında tek bir güvenilen kullanıcı.A single trusted user at the subscription scope with permission to assign resource access rights.
    • Her iş yükü sahibi, varsayılan olarak kaynaklarına erişimi reddedilir.Each workload owner is denied access to resources by default. Kaynak erişim haklarını açıkça abonelik kapsamında tek güvenilen kullanıcı tarafından verilir.Resource access rights are granted explicitly by the single trusted user at the subscription scope.
    • Paylaşılan altyapı sahibine sınırlı paylaşılan altyapı kaynakları için erişim yönetimi.Management access for the shared infrastructure resources limited to the shared infrastructure owner.
    • Yönetim erişimi iş yükü sahibine kısıtlı her iş yükü için.Management access for each workload restricted to the workload owner.
    • Kuruluş rollerini bağımsız olarak üç ortamların her birinde yönetmek zorunda istemiyor. Bu nedenle gerektirir [yerleşik RBAC rolleri] rbac-built-in-roles yalnızca.The enterprise does not want to have to manage roles independently in each of the three environments, therefore requires the use of built-in RBAC roles only. Kuruluş özel RBAC rollerini kullanmanız gerekirse, başka bir işlem özel roller üç ortamlar genelinde eşitlemek için gereklidir.If the enterprise were to use custom RBAC roles, an additional process is required to synchronize custom roles across the three environments.
  • İzleme iş yükü sahibi adı, ortam veya her ikisi de maliyeti.Cost tracking by workload owner name, environment, or both.

Kimlik yönetimiIdentity management

Biz idare modeliniz için Kimlik Yönetimi tasarlamadan önce kapsadığını dört ana alanlarını anlamak önemlidir:Before we can design identity management for your governance model, it's important to understand the four major areas it encompasses:

  • Yönetim: işlemleri ve araçları oluşturmak, düzenlemek ve kullanıcı kimliği siliniyor.Administration: the processes and tools for creating, editing, and deleting user identity.
  • Kimlik doğrulaması: kullanıcı kimliği, bir kullanıcı adı ve parola gibi kimlik bilgilerini doğrulayarak doğrulanıyor.Authentication: verifying user identity by validating credentials, such as a user name and password.
  • Yetkilendirme: hangi kaynakların belirleme kimliği doğrulanmış bir kullanıcı için erişim veya bunların hangi işlemleri gerçekleştirmek için izne sahip izin verilir.Authorization: determining which resources an authenticated user is allowed to access or what operations they have permission to perform.
  • Denetleme: günlükleri ve diğer bilgileri güvenlik sorunlarını keşfetmek için düzenli aralıklarla gözden kullanıcı kimliğiyle ilgili.Auditing: periodically reviewing logs and other information to discover security issues related to user identity. Bu, şüpheli kullanım düzenlerini, düzenli aralıklarla doğru olduklarını doğrulamak için kullanıcı izinlerini gözden geçirme ve diğer işlevleri içerir.This includes reviewing suspicious usage patterns, periodically reviewing user permissions to verify they are accurate, and other functions.

Azure tarafından güvenilen kimlik için yalnızca bir hizmet yoktur ve Azure Active Directory (Azure AD).There is only one service trusted by Azure for identity, and that is Azure Active Directory (Azure AD). Biz kullanıcıları Azure AD'ye ekleme ve yukarıda listelenen işlevlerin tümü için kullanma.We'll be adding users to Azure AD and using it for all of the functions listed above. Ancak, nasıl Azure AD'ye yapılandıracağız konumunda göz atmadan önce bu hizmetlere erişimi yönetmek için kullanılan ayrıcalıklı hesapların anlamak önemlidir.But before we look at how we'll configure Azure AD, it's important to understand the privileged accounts that are used to manage access to these services.

Ne zaman kuruluşunuz kaydolduğu bir Azure hesabı için en az bir Azure hesap sahibi atandı.When your organization signed up for an Azure account, at least one Azure account owner was assigned. Ayrıca, Azure AD Kiracı oluşturulduğu sürece, var olan bir kiracı, kuruluşunuzun Office 365 gibi diğer Microsoft hizmetlerinin kullanımı ile zaten ilişkilendirilmişti.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 Office 365. A genel yönetici oluşturulduğunda Azure AD'ye tam izinleri olan Kiracı ilişkilendirildi.A global administrator with full permissions on the Azure AD tenant was associated when it was created.

Kullanıcı kimliklerini Azure hesap sahibi hem de Azure AD genel Yöneticisi için Microsoft tarafından yönetilen bir yüksek oranda güvenli kimlik sistemi depolanır.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. Azure hesap sahibi, oluşturma, güncelleştirme ve abonelikleri silme yetkisine sahiptir.The Azure Account Owner is authorized to create, update, and delete subscriptions. Azure AD genel Yöneticisi, Azure AD'de birçok eylemi gerçekleştirmek için yetkili olup, ancak bu tasarım kılavuzu için oluşturma ve kullanıcı kimliği silinmesini odaklanacağız.The Azure AD global administrator is authorized to perform many actions in Azure AD, but for this design guide we'll focus on the creation and deletion of user identity.

Not

Bir mevcut Office 365 veya Intune lisansı hesabınızla ilişkili ise, kuruluşunuzun mevcut bir Azure AD kiracısı zaten olabilir.Your organization may already have an existing Azure AD tenant if there's an existing Office 365 or Intune license associated with your account.

Azure hesap sahibi, oluşturma, güncelleştirme ve abonelikleri silme izni vardır:The Azure Account Owner has permission to create, update, and delete subscriptions:

Azure Hesap Yöneticisi ve Azure AD genel yönetici Azure hesabıyla Şekil 1. Bir Hesap Yöneticisi ve Azure AD genel yöneticisi olan bir Azure hesabı.Azure account with Azure Account Manager and Azure AD global admin Figure 1. An Azure account with an Account Manager and Azure AD Global Administrator.

Azure AD genel yönetici kullanıcı hesapları oluşturma izni vardır:The Azure AD global administrator has permission to create user accounts:

Azure Hesap Yöneticisi ve Azure AD genel yönetici Azure hesabıyla Şekil 2. Azure AD genel Yöneticisi, kiracıda gereken kullanıcı hesaplarını oluşturur.Azure account with Azure Account Manager and Azure AD global admin Figure 2. The Azure AD Global Administrator creates the required user accounts in the tenant.

İlk iki hesap App1 iş yükü sahibi ve App2 iş yükü sahibi bir iş yükü yönetmekten sorumlu, kuruluşunuzdaki bir kişi ile ilişkili olan her.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. Ağ işlemleri hesap sahibi tarafından paylaşılan altyapı kaynakları için sorumlu birey.The network operations account is owned by the individual that is responsible for the shared infrastructure resources. Son olarak, abonelik sahibi hesabıdır abonelikleri sahipliği için sorumlu kişi ile ilişkili.Finally, the subscription owner account is associated with the individual responsible for ownership of subscriptions.

En düşük kaynak erişim izinleri modeliResource access permissions model of least privilege

Kimlik yönetimi sistemi ve kullanıcı hesapları oluşturulur, biz size en az ayrıcalık bir izinler modelini desteklemek için her hesap için rol tabanlı erişim denetimi (RBAC) rollerini nasıl uygulayacağınız karar vermeniz gerekir.Now that your identity management system and user accounts have been created, we have to decide how we'll apply role-based access control (RBAC) roles to each account to support a permissions model of least privilege.

Başka bir gereksinim yoktur. her iş yükü ile ilişkili kaynakları belirten birbirinden yalıtılmış sağlayacak şekilde bir iş yükü sahibi kendilerine ait yükünü yönetim erişimi yok.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. Ayrıca yalnızca kullanarak bu modeli uygulamak için bir gereksinim yoktur Azure RBAC için yerleşik roller.There's also a requirement to implement this model using only built-in roles for Azure RBAC.

Azure'da üç kapsamları birinde her RBAC rolü uygulanır: abonelik, kaynak grubu, sonra bireysel kaynak.Each RBAC role is applied at one of three scopes in Azure: subscription, resource group, then an individual resource. Rolleri alt kapsamlar devralınır.Roles are inherited at lower scopes. Örneğin, bir kullanıcıya atanmış ise [yerleşik bir sahip rolü] rbac-built-in-owner , geçersiz kılınmadığı sürece abonelik düzeyinde bu rol de bu kullanıcı bir kaynak grubu ve ayrı kaynak düzeyinde atanır.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 it's overridden.

Bu nedenle, en az ayrıcalık erişim eylemleri karar sahibiz bir model oluşturmak için belirli bir kullanıcı türü her biri bu üç kapsamların ele izin verilmez.Therefore, to create a model of least privilege access we have to decide the actions a particular type of user is allowed to take at each of these three scopes. Örneğin, yalnızca iş yükünü ve hiçbir diğer kullanıcılarla ilişkili kaynaklara erişimi yönetme izni sağlamak bir iş yükü sahibi gereksinimi içindir.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. Atamak olsaydık [yerleşik bir sahip rolü] rbac-built-in-owner abonelik kapsamında, her iş yükü sahibi tüm iş yükleri için yönetim erişimi gerekir.If we were to assign the built-in owner role at the subscription scope, each workload owner would have management access to all workloads.

Bu kavramı biraz daha iyi anlamak için iki örnek izin modeli bir göz atalım.Let's take a look at two example permission models to understand this concept a little better. İlk örnekte, model yalnızca kaynak grupları oluşturmak için Hizmet Yöneticisi güvenir.In the first example, the model trusts only the service administrator to create resource groups. İkinci örnekte, her iş yükü sahibi abonelik kapsamda model yerleşik bir sahip rolü atar.In the second example, the model assigns the built-in owner role to each workload owner at the subscription scope.

Örneklerin her ikisi de sahibiz atanan abonelik Hizmet Yöneticisi [yerleşik bir sahip rolü] rbac-built-in-owner abonelik kapsamında.In both examples, we have a subscription service administrator that is assigned the built-in owner role at the subscription scope. Bu geri çağırma [yerleşik bir sahip rolü] rbac-built-in-owner Yönetimi kaynaklarına erişim, tüm izinleri verir.Recall that the built-in owner role grants all permissions including the management of access to resources. sahip rolü ile aboneliği Hizmet Yöneticisi Şekil 3. Hizmet Yöneticisi aboneliğe yerleşik bir sahip rolü atanmış.subscription service administrator with owner role Figure 3. A subscription with a service administrator assigned the built-in owner role.

  1. İlk örnekte, sahip olduğumuz iş yükü sahibi A varsayılan olarak kaynak erişim yönetim hakları sahiptirler ile abonelik kapsamda - izni yok.In the first example, we have workload owner A with no permissions at the subscription scope - they have no resource access management rights by default. Bu kullanıcı, dağıtmak ve kaynaklar için iş yükünü yönetmek istiyor.This user wants to deploy and manage the resources for their workload. Başvurmanız gerekir Hizmet Yöneticisi bir kaynak grubu oluşturulmasını istemek için.They must contact the service administrator to request creation of a resource group. iş yükü sahibi istekleri oluşturma ve kaynak grubu Aworkload owner requests creation of resource group A

  2. Hizmet Yöneticisi isteğini inceler ve oluşturur kaynak grubu A. Bu noktada, iş yükü sahibi A yine de herhangi bir şey için izne sahip değil.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. kaynak grubu bir Hizmet Yöneticisi oluştururservice administrator creates resource group A

  3. Hizmet Yöneticisi ekler iş yükü sahibi A için kaynak grubu A ve atar yerleşik katkıda bulunan rolü.The service administrator adds workload owner A to resource group A and assigns the built-in contributor role. Katkıda bulunan rolü, üzerindeki tüm izinleri sağlar. kaynak grubu A erişim izni yönetme dışında.The contributor role grants all permissions on resource group A except managing access permission. Hizmet Yöneticisi, iş yükü sahibi ekler bir kaynak grubu için birservice administrator adds workload owner a to resource group a

  4. Varsayalım, iş yükü sahibi A CPU ve ağ trafiğini kapasite planlaması için iş yükünün parçası olarak izleme verilerini görüntülemek için takım üyelerinin bir çifti için bir gereksinim vardır.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. Çünkü iş yükü sahibi A olan katkıda bulunan rolü atandı, bunlar için bir kullanıcı eklemek için izniniz yok kaynak grubu A. Bu isteği göndermesi gerekir Hizmet Yöneticisi.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. iş yükü sahibi istekleri iş yükü Katkıda Bulunanlar, kaynak grubuna eklenebilirworkload owner requests workload contributors be added to resource group

  5. Hizmet Yöneticisi isteği inceler ve iki ekler iş yükü katkıda bulunan kullanıcılara kaynak grubu A. Bu iki kullanıcı hiçbiri atanmaları için kaynakları yönetme izni gerektiren yerleşik okuyucu rolüne.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 are assigned the built-in reader role. Hizmet Yöneticisi iş yükü katkıda bulunanlar için kaynak grup A ekler.service administrator adds workload contributors to resource group A

  6. Ardından, iş yükü sahibi B kaynaklar için iş yükünü içerecek bir kaynak grubu da gerektirir.Next, workload owner B also requires a resource group to contain the resources for their workload. Olduğu gibi iş yükü sahibi A, iş yükü sahibi B başlangıçta bir istek göndermeniz gerekir böylece abonelik kapsamında herhangi bir işlem yapması için izni yok HizmetYöneticisi.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. kaynak grubu B, iş yükü sahibi B istekleri oluşturmaworkload owner B requests creation of resource group B

  7. Hizmet Yöneticisi taleplerini inceler ve oluşturan kaynak grubu B. Hizmet Yöneticisi B kaynak grubu oluşturur.The service administrator reviews the request and creates resource group B. Service Administrator creates resource group B

  8. Hizmet Yöneticisi ardından ekler iş yükü sahibi B için kaynak grubu B ve atar yerleşik katkıda bulunan rolü.The service administrator then adds workload owner B to resource group B and assigns the built-in contributor role. Hizmet Yöneticisi, iş yükü sahibi B B kaynak grubuna ekler.Service Administrator adds Workload Owner B to resource group B

Bu noktada, her iş yükü sahipleri, kendi kaynak grubunda yalıtılır.At this point, each of the workload owners is isolated in their own resource group. İş yükü sahipleriyle veya takım üyelerinin hiçbiri başka bir kaynak grubunda kaynaklarına yönetim erişimi vardır.None of the workload owners or their team members have management access to the resources in any other resource group.

Kaynak grupları A ve B abonelikle Şekil 4 '. Kendi kaynak grubuyla yalıtılmış iki iş yükü sahibi olan bir abonelik.subscription with resource groups A and B Figure 4. A subscription with two workload owners isolated with their own resource group.

Bu modelde en az ayrıcalık model - her kullanıcı doğru kaynak yönetim kapsamının doğru izinleri atanır.This model is a least privilege model - each user is assigned the correct permission at the correct resource management scope.

Ancak, bu örnekte her görev tarafından gerçekleştirilen göz önünde bulundurun Hizmet Yöneticisi.However, consider that every task in this example was performed by the service administrator. Bu basit bir örnektir ve bir sorun olmadığı için yalnızca iki iş yükü sahibi olacak şekilde görünmeyebilir, ancak büyük bir kuruluş için ortaya çıkabilecek sorunları türlerini Imagine kolaydır.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. Örneğin, Hizmet Yöneticisi gecikmelerine neden isteklerinin büyük bir biriktirme listesi ile bir performans sorunu haline gelebilir.For example, the service administrator can become a bottleneck with a large backlog of requests that result in delays.

Tarafından gerçekleştirilen görevlerin sayısını azaltan ikinci örnek bir göz atalım Hizmet Yöneticisi.Let's take a look at second example that reduces the number of tasks performed by the service administrator.

  1. Bu modelde, iş yükü sahibi A atanan [yerleşik bir sahip rolü] rbac-built-in-owner bunları kendi kaynak grubu oluşturmak abonelik kapsamında etkinleştiriliyor: Kaynak Grubu A. Hizmet Yöneticisi, iş yükü sahibi bir aboneliğe ekler.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. Zaman kaynak grubu A oluşturulan iş yükü sahibi A varsayılan olarak eklenir ve devralır [yerleşik sahibi] rbac-built-in-owner rolünden Abonelik kapsamı.When resource group A is created, workload owner A is added by default and inherits the built-in owner role from the subscription scope. İş yükü sahibi bir kaynak grubu oluşturulurWorkload Owner A creates resource group A

  3. [Yerleşik bir sahip rolü] rbac-built-in-owner verir iş yükü sahibi A kaynak grubuna erişimi yönetme izni.The built-in owner role grants workload owner A permission to manage access to the resource group. Bir iş yükü sahibi iki ekler iş yükü katkıda bulunanlar ve atar [yerleşik okuyucu rolüne] rbac-built-in-owner bunların her biri için.Workload owner A adds two workload contributors and assigns the built-in reader role to each of them. İş yükü sahibi bir iş yükü katkıda bulunanlar ekler.Workload Owner A adds Workload Contributors

  4. Hizmet Yöneticisi artık ekler iş yükü sahibi B yerleşik sahip rolüne abonelik.Service administrator now adds workload owner B to the subscription with the built-in owner role. Hizmet Yöneticisi aboneliğe iş yükü sahipleri B ekler.Service Administrator adds Workload Owners B to subscription

  5. İş yükü sahibi B oluşturur kaynak grubu B ve varsayılan olarak eklenir.Workload owner B creates resource group B and is added by default. Yeniden iş yükü sahibi B abonelik kapsamından yerleşik bir sahip rolü devralır.Again, workload owner B inherits the built-in owner role from the subscription scope. İş yükü sahibi B B kaynak grubu oluşturur.Workload Owner B creates resource group B

Bu modelde, dikkat Hizmet Yöneticisi yönetim erişimi temsilcisi nedeniyle ilk örnekte her birini tek tek iş yükü sahipleriyle menülerin daha az eylemleri.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.

Kaynak grupları A ve B abonelikle Şekil 5 '. Bir abonelikte Hizmet Yöneticisi ve iki iş yükü sahipleriyle tüm yerleşik bir sahip rolü atanmış.subscription with resource groups A and B Figure 5. A subscription with a service administrator and two workload owners, all assigned the built-in owner role.

Ancak, çünkü her ikisi de iş yükü sahibi A ve iş yükü sahibi B yerleşik sahip rolüne atanan abonelik kapsamında, bunlar her birbirlerinin kaynak için yerleşik bir sahip rolü devralınan Grup.However, 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. Bu yalnızca tam başka birinin kaynaklarına erişimleri, ayrıca yönetim erişimi birbirlerinin kaynak gruplarına temsil edebileceği gösterir.This means that not only do they have full access to one another's resources, they are also able to delegate management access to each other's resource groups. Örneğin, iş yükü sahibi B başka bir kullanıcı eklemek için haklara sahip kaynak grubu A ve bunları yerleşik bir sahip rolü dahil olmak üzere herhangi bir rol atayabilirsiniz.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.

Biz gereksinimler için her örnek karşılaştırırsanız, örneklerin her ikisi de tek bir güvenilen kullanıcı iki iş yükü sahipleri için kaynak erişim hakları vermek için izne sahip abonelik kapsamında destek bakın.If we compare each example to the requirements, we 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. Her iki iş yükü sahipleriyle kaynak yönetimi için erişim varsayılan olarak sahip değil ve gerekli Hizmet Yöneticisi açıkça kendisine izinler atamak için.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. Ancak, yalnızca ilk örnek, hiçbir iş yükü sahibi başka bir iş yükünün kaynaklara erişimine sahip olacak şekilde, her iş yükü ile ilişkili kaynakları birbirinden yalıtılmış gereksinim destekler.However, 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.

Kaynak yönetim modeliResource management model

Bir izin modeli en az ayrıcalık tasarladık, bazı pratik uygulamalar, bu idare modellerinin bakmak geçelim.Now that we've designed a permissions model of least privilege, let's move on to take a look at some practical applications of these governance models. Aşağıdaki üç ortamları desteklemelidir gereksinimlerinden Hatırla:Recall from the requirements that we must support the following three environments:

  1. Paylaşılan altyapı: tüm iş yükleri tarafından paylaşılıp kaynakların tek bir grup.Shared infrastructure: a single group of resources shared by all workloads. Bu, ağ geçitleri, güvenlik duvarları ve güvenlik hizmetleri gibi kaynaklardır.These are resources such as network gateways, firewalls, and security services.
  2. Geliştirme: birden fazla grubu kaynakları temsil eden birden çok üretim dışı iş yüklerini hazır.Development: multiple groups of resources representing multiple non-production ready workloads. Bu kaynaklar, kavram kanıtı, test ve diğer Geliştirici etkinlikler için kullanılır.These resources are used for proof-of-concept, testing, and other developer activities. Bu kaynaklar daha yüksek Geliştirici çevikliği etkinleştirmek için daha esnek bir idare modeli sahip olabilir.These resources may have a more relaxed governance model to enable increased developer agility.
  3. Üretim: kaynakların birden çok üretim iş yükleri temsil eden birden çok grubu.Production: multiple groups of resources representing multiple production workloads. Bu kaynaklar, özel ve genel kullanıma yönelik uygulama yapıtlar barındırmak için kullanılır.These resources are used to host the private and public facing application artifacts. Bu kaynaklar genellikle kaynaklar, uygulama kodu ve verileri yetkisiz erişimden korumak için güvenlik modelleri ve tightest idare sahiptir.These resources typically have the tightest governance and security models to protect the resources, application code, and data from unauthorized access.

Her üç bu ortamlar için maliyet verilerine göre izlemek için bir gereksinim sahibiz iş yükü sahibi, ortam, veya her ikisini de.For each of these three environments, we have a requirement to track cost data by workload owner, environment, or both. Diğer bir deyişle, devam eden maliyetini bilmek istiyoruz paylaşılan altyapı, hem de kişiler tarafından maliyetleri geliştirme ve üretim ortamları ve Son olarak, genel maliyetini geliştirme ve üretim.That is, we want to know the ongoing cost of the shared infrastructure, the costs incurred by individuals in both the development and production environments, and finally the overall cost of development and production.

Kaynaklar için iki düzey kapsamındaki zaten öğrendiniz: abonelik ve kaynak grubu.You have already learned that resources are scoped to two levels: subscription and resource group. Bu nedenle, ilk ortamlarının düzenlemek nasıl bir karardır abonelik.Therefore, the first decision is how to organize environments by subscription. Yalnızca iki olasılık vardır: tek bir aboneliğe veya birden çok abonelik.There are only two possibilities: a single subscription, or, multiple subscriptions.

Biz bu modellerin her örneklere göz atacağız önce Azure abonelikleri için yönetim yapısı gözden geçirelim.Before we look at examples of each of these models, let's review the management structure for subscriptions in Azure.

Geri çağırma bireysel abonelikler için sorumlu kuruluştaki sunuyoruz ve bu kullanıcının sahip olduğu gereksinimlerinden abonelik sahibi hesabı Azure AD kiracısında.Recall from the requirements that we have an individual in the organization who is responsible for subscriptions, and this user owns the subscription owner account in the Azure AD tenant. Ancak, bu hesap, abonelik oluşturma izni yok.However, this account does not have permission to create subscriptions. Yalnızca Azure hesap sahibi Bunu yapmak için izne sahip: Şekil 6. Azure hesap sahibi, bir abonelik oluşturur.Only the Azure Account Owner has permission to do this: Figure 6. An Azure Account Owner creates a subscription.

Abonelik oluşturulduktan sonra Azure hesap sahibi ekleyebilirsiniz abonelik sahibi abonelikle hesap sahibi rolü:Once the subscription has been created, the Azure Account Owner can add the subscription owner account to the subscription with the owner role:

Şekil 7. Azure hesap sahibi ekler abonelik sahibi abonelikle kullanıcı hesabına sahibi rol. Figure 7. The Azure Account Owner adds the subscription owner user account to the subscription with the owner role.

Abonelik sahibi artık oluşturabilirsiniz kaynak grupları ve temsilci kaynağa erişim yönetimi.The subscription owner can now create resource groups and delegate resource access management.

İlk tek bir abonelik kullanarak bir örnek kaynak yönetim modeli bakalım.First let's look at an example resource management model using a single subscription. İlk üç ortamlar için kaynak gruplarını hizalama kararıdır.The first decision is how to align resource groups to the three environments. İki seçenek sunuyoruz:We have two options:

  1. Her ortam için tek bir kaynak grubu hizalayın.Align each environment to a single resource group. Tüm paylaşılan altyapı kaynaklarını tek bir dağıtılan paylaşılan altyapı kaynak grubu.All shared infrastructure resources are deployed to a single shared infrastructure resource group. Geliştirme iş yükleri ile ilişkili tüm kaynakları tek bir dağıtılan geliştirme kaynak grubu.All resources associated with development workloads are deployed to a single development resource group. Üretim iş yükleri ile ilişkili tüm kaynakları tek bir dağıtılan üretim için kaynak grubu üretim ortam.All resources associated with production workloads are deployed into a single production resource group for the production environment.
  2. Her iş yükü için üç ortamların her birinde kaynak gruplarıyla hizalamak için bir adlandırma kuralı ve etiketleri kullanarak ayrı kaynak grubu oluşturun.Create separate resource groups for each workload, using a naming convention and tags to align resource groups with each of the three environments.

İlk seçenek değerlendirerek başlayalım.Let's begin by evaluating the first option. Ele almıştık izinler modeli önceki bölümde, kaynak grubu oluşturur ve kullanıcıları ile ya da yerleşik ekler tek abonelik Hizmet Yöneticisi ile kullanacağız katkıda bulunan veya okuyucu rol.We'll be using the permissions model that we 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. İlk kaynak grubuna dağıtıldığını temsil paylaşılan altyapı ortam.The first resource group deployed represents the shared infrastructure environment. Abonelik sahibi adlı paylaşılan altyapı kaynakları için bir kaynak grubu oluşturur netops paylaşılan rg.The subscription owner creates a resource group for the shared infrastructure resources named netops-shared-rg.
  2. Abonelik sahibi ekler ağ işlemleri kullanıcı atar ve kaynak grubu için hesap katkıda bulunan rol.The subscription owner adds the network operations user account to the resource group and assigns the contributor role.
  3. Ağ işlemleri kullanıcı oluşturur bir VPN ağ geçidi ve şirket içi VPN gerecine bağlanmak için yapılandırır.The network operations user creates a VPN gateway and configures it to connect to the on-premises VPN appliance. Ağ işlemleri kullanıcı da geçerli bir çift etiketleri kaynakların her biri için: ortam: paylaşılan ve managedBy:netOps .The network operations user also applies a pair of tags to each of the resources: environment:shared and managedBy:netOps. Zaman aboneliği Hizmet Yöneticisi Maliyet raporu, maliyetleri hizalanmayacak her bu etiketleri dışa aktarır.When the subscription service administrator exports a cost report, costs will be aligned with each of these tags. Böylece aboneliği Hizmet Yöneticisi Özet maliyetleri kullanarak ortam etiketi ve managedBy etiketi.This allows the subscription service administrator to pivot costs using the environment tag and the managedBy tag. Bildirim kaynak sınırları şekil sağ üst tarafındaki sayaç.Notice the resource limits counter at the top right-hand side of the figure. Her Azure aboneliği hizmet sınırları, ve bu sınırları etkisini anlamanıza yardımcı olması için her abonelik için sanal ağ sınırı izleyeceğiz.Each Azure subscription has service limits, and to help you understand the effect of these limits we'll follow the virtual network limit for each subscription. Abonelik başına 50 sanal ağ'ın varsayılan bir sınırı yoktur ve ilk sanal ağ dağıtıldıktan sonra artık 49 kullanılabilen vardır.There is a default limit of 50 virtual networks per subscription, and after the first virtual network is deployed there are now 49 available.
  4. Daha fazla iki kaynak grubu dağıtılır, ilk adlı prod-rg.Two more resource groups are deployed, the first is named prod-rg. Bu kaynak grubu ile hizalanır üretim ortam.This resource group is aligned with the production environment. İkinci adlı geliştirme-rg birlikte hizalanır ve geliştirme ortam.The second is named dev-rg and is aligned with the development environment. Üretim iş yükleri ile ilişkili tüm kaynakları dağıtılan üretim ortamı ve geliştirme iş yükleri ile ilişkili tüm kaynakları için dağıtıldığı geliştirme ortamı .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. Biz herhangi bir Azure aboneliği hizmet sınırları karşılaştığınız olmaz için bu örnekte biz yalnızca iki iş yükünden her iki Bu ortamların dağıtacaksınız.In this example we'll only deploy two workloads to each of these two environments so we won't encounter any Azure subscription service limits. Ancak, her kaynak grubu 800 kaynakları kaynak grubu başına sınırı olduğunu göz önünde bulundurmanız önemlidir.However, it's important to consider that each resource group has a limit of 800 resources per resource group. İş yükleri her bir kaynak grubuna ekleyeceğiz tutmak, bu nedenle, bu sınıra ulaşılmasını mümkündür.Therefore, if we keep adding workloads to each resource group it is possible that this limit will be reached.
  5. İlk iş yükü sahibi bir istek gönderir aboneliği Hizmet Yöneticisi ve her biri için eklenen geliştirme ve üretim ortamı kaynak grupları ile katkıda bulunan rol.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. Daha önce öğrenilen katkıda bulunan rolü başka bir kullanıcıya rol atama dışındaki herhangi bir işlem gerçekleştirmesine izin verir.As you learned earlier, the contributor role allows the user to perform any operation other than assigning a role to another user. İlk iş yükü sahibi artık kendi iş yükü ile ilişkili kaynakları oluşturabilirsiniz.The first workload owner can now create the resources associated with their workload.
  6. İlk iş yükü sahibi her bir çift Sanal makine her iki kaynak gruplarıyla bir sanal ağ oluşturur.The first workload owner creates a virtual network in each of the two resource groups with a pair of virtual machines in each. İlk iş yükü sahibi geçerlidir ortam ve managedBy tüm kaynaklar için etiketler.The first workload owner applies the environment and managedBy tags to all resources. Azure hizmet sınırı sayacı artık kalan 47 sanal ağlara olduğuna dikkat edin.Note that the Azure service limit counter is now at 47 virtual networks remaining.
  7. Oluşturulduğunda sanal ağların her birinde şirket içi bağlantı yok.Each of the virtual networks does not have connectivity to on-premises when they are created. Bu tür mimari, her bir sanal ağ için eşlenmesi gerekir hub-vnet içinde paylaşılan altyapı ortam.In this type of architecture, each virtual network must be peered to the hub-vnet in the shared infrastructure environment. Sanal Ağ eşlemesi iki ayrı sanal ağlar arasında bir bağlantı oluşturur ve aralarındaki seyahat ağ trafiğine izin verir.Virtual network peering creates a connection between two separate virtual networks and allows network traffic to travel between them. Sanal Ağ eşlemesi kendiliğinden geçişli değildir.Note that virtual network peering is not inherently transitive. Bir eşleme her bağlı olan iki sanal ağ içinde belirtilmelidir ve sanal ağlardan birine bir eşleme belirtir. yalnızca bağlantı tamamlanmadı.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 the connection is incomplete. Bu, etkisini göstermek için ilk iş yükü sahibi arasında bir eşleme belirtir prod-vnet ve hub-vnet.To illustrate the effect of this, the first workload owner specifies a peering between prod-vnet and hub-vnet. İlk eşleme oluşturulur, ancak hiçbir trafik için akış gelen tamamlayıcı eşlemesi hub-vnet için prod-vnet henüz belirtilmedi.The first peering is created, but no traffic flows because the complementary peering from hub-vnet to prod-vnet has not yet been specified. İlk iş yükü sahibi kişiler ağ işlemleri kullanıcı ve istekleri bu bağlantı eşlemesi tamamlayıcı.The first workload owner contacts the network operations user and requests this complementary peering connection.
  8. Ağ işlemleri kullanıcı taleplerini inceler, kişi ve ardından ayarlarında eşleme belirtir hub-vnet.The network operations user reviews the request, approves it, then specifies the peering in the settings for the hub-vnet. Eşleme bağlantısını tamamlanır ve ağ trafiğini iki sanal ağ arasında akar.The peering connection is now complete and network traffic flows between the two virtual networks.
  9. Şimdi, ikinci iş yükü sahibi bir istek gönderir aboneliği Hizmet Yöneticisi ve varolan eklenir üretim ve geliştirme ortamı kaynak grupları ile katkıda bulunan rol.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. İkinci iş yükü sahibi aynı izinleri, ilk tüm kaynaklara sahip iş yükü sahibi her kaynak grubunda.The second workload owner has the same permissions on all resources as the first workload owner in each resource group.
  10. İkinci iş yükü sahibi içindeki alt ağ oluşturur prod-vnet sanal ağ, sonra iki sanal makineye ekler.The second workload owner creates a subnet in the prod-vnet virtual network, then adds two virtual machines. İkinci iş yükü sahibi geçerlidir ortam ve managedBy her kaynak için etiketler.The second workload owner applies the environment and managedBy tags to each resource.

Bu örnekte kaynak yönetimi modeline bize üç gerekli ortamlarda kaynakları yönetmek etkinleştirir.This example resource management model enables us to manage resources in the three required environments. Bu kaynakları erişmek için izne sahip bir abonelik yalnızca tek bir kullanıcı olduğundan paylaşılan altyapı kaynaklarını korunur.The shared infrastructure resources are protected because there's only a single user in the subscription with permission to access those resources. Her iş yükü sahipleriyle paylaşımı altyapı kaynaklarını gerçek paylaşılan kaynaklardaki üzerinde tüm izinlere sahip olmadan kullanmaya başlayabilirsiniz.Each of the workload owners is able to utilize the share infrastructure resources without having any permissions on the actual shared resources themselves. Ancak, bu yönetim modeli iş yükü yalıtımı - her iki gereksinimi başarısız iş yükü sahipleriyle diğer kişinin iş yükü kaynaklarına erişebilir.However, This management model fails the requirement for workload isolation - each of the two workload owners are able to access the resources of the other's workload.

Hemen belirgin olmayabilir, bu model ile başka bir önemli konu vardır.There's another important consideration with this model that may not be immediately obvious. Bu örnekte olduğu app1 iş yükü sahibi ağ eşleme bağlantısı ile istenen hub-vnet şirket içi bağlantı sağlamak için.In the example, it was app1 workload owner that requested the network peering connection with the hub-vnet to provide connectivity to on-premises. Ağ işlemleri kullanıcı bu isteği, iş yüküyle birlikte dağıtılan kaynakların göre değerlendirilir.The network operations user evaluated that request based on the resources deployed with that workload. Zaman abonelik sahibi eklenen app2 iş yükü sahibi ile katkıda bulunan rolü, bu kullanıcı olduğu tüm kaynaklara erişim hakları yönetimi Ürün-rg kaynak grubu.When the subscription owner added app2 workload owner with the contributor role, that user had management access rights to all resources in the prod-rg resource group.

Başka bir deyişle app2 iş yükü sahibi kendi alt ağ ile sanal makineleri dağıtmak için izninde prod-vnet sanal ağ.This means app2 workload owner had permission to deploy their own subnet with virtual machines in the prod-vnet virtual network. Varsayılan olarak, bu sanal makineleri şirket içi ağ yararlanabiliyor.By default, those virtual machines now have access to the on-premises network. Ağ işlemleri kullanıcı bu makinelerin farkında değildir ve kendi şirket içi bağlantı onaylamadı.The network operations user is not aware of those machines and did not approve their connectivity to on-premises.

Ardından, birden çok kaynak gruplarına farklı ortamları ve iş yükleri için tek bir abonelikle göz atalım.Next, let's look at a single subscription with multiple resources groups for different environments and workloads. Bunlar aynı kaynak grubunda olduğundan kaynaklar her ortam için önceki örnekte, kolayca tanımlanabilen unutmayın.Note that in the previous example, the resources for each environment were easily identifiable because they were in the same resource group. Artık bu gruplandırma sahibiz, biz bu işlevi sağlamak için kaynak grubu üzerinde bir adlandırma kuralı güvenmek zorunda kalacak.Now that we no longer have that grouping, we will have to rely on a resource group naming convention to provide that functionality.

  1. Paylaşılan altyapı kaynakları hala olacaktır ayrı bir kaynak grubu bu modelde, böylece aynı kalır.The shared infrastructure resources will still have a separate resource group in this model, so that remains the same. Her iş yükü iki kaynak grupları - için birer tane gerektirir geliştirme ve üretim ortamları.Each workload requires two resource groups - one for each of the development and production environments. İlk iş yükü için abonelik sahibi iki kaynak grubu oluşturur.For the first workload, the subscription owner creates two resource groups. İlk adlı app1-prod-rg ve ikincisi adlı app1-dev-rg.The first is named app1-prod-rg and the second one is named app1-dev-rg. Daha önce bahsedildiği gibi bu adlandırma kuralı ilk iş yükü ile ilişkilendiriliyor olarak kaynakları belirleyen app1ve her iki geliştirme veya prod ortam.As discussed earlier, this naming convention identifies the resources as being associated with the first workload, app1, and either the dev or prod environment. Yeniden abonelik sahibi ekler app1 iş yükü sahibi sahip kaynak grubunda katkıda bulunan rol.Again, the subscription owner adds app1 workload owner to the resource group with the contributor role.
  2. İlk örnek, benzer app1 iş yükü sahibi adlı bir sanal ağ'ı dağıtır app1-prod-vnet için üretim ortamı ve başka bir adlandırılmış app1-dev-vnet için geliştirme ortam.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. Yeniden app1 iş yükü sahibi bir istek gönderir ağ işlemleri eşleme bağlantısı oluşturmak için kullanıcı.Again, app1 workload owner sends a request to the network operations user to create a peering connection. Unutmayın app1 iş yükü sahibi ilk örnek ve sınırı sayacı ayrıldıkça abonelikte kalan 47 sanal ağlara aynı etiketleri ekler.Note that app1 workload owner adds the same tags as in the first example, and the limit counter has been decremented to 47 virtual networks remaining in the subscription.
  3. Abonelik sahibi şimdi için iki kaynak grubu oluşturur app2 iş yükü sahibi.The subscription owner now creates two resource groups for app2 workload owner. Olarak için aynı kurallarına app1 iş yükü sahibi, kaynak gruplarını adlı app2-prod-rg ve app2-dev-rg.Following the same conventions as for app1 workload owner, the resource groups are named app2-prod-rg and app2-dev-rg. Abonelik sahibi ekler app2 iş yükü sahibi her kaynak gruplarıyla katkıda bulunan rol.The subscription owner adds app2 workload owner to each of the resource groups with the contributor role.
  4. App2 iş yükü sahibi sanal ağlar ve sanal makineler aynı adlandırma kuralları ile kaynak gruplarına dağıtır.App2 workload owner deploys virtual networks and virtual machines to the resource groups with the same naming conventions. Etiketler eklenir ve sınırı sayaç içinde kalan 45 sanal ağlara indirildiği abonelik.Tags are added and the limit counter has been decremented to 45 virtual networks remaining in the subscription.
  5. App2 iş yükü sahibi bir istek gönderir ağ işlemleri eşlenecek kullanıcı app2-prod-vnet ile hub-vnet.App2 workload owner sends a request to the network operations user to peer the app2-prod-vnet with the hub-vnet. Ağ işlemleri kullanıcı eşleme bağlantısını oluşturur.The network operations user creates the peering connection.

Sonuçta elde edilen bir yönetim modeli, ilk örnek, bazı önemli farklılıklar ile benzerdir:The resulting management model is similar to the first example, with several key differences:

  • Her iki iş yüklerinin iş yüküne göre ve ortama göre yalıtılır.Each of the two workloads is isolated by workload and by environment.
  • Bu model, ilk örnek modeli değerinden daha fazla iki sanal ağ gereklidir.This model required two more virtual networks than the first example model. Bu önemli bir ayrımdır yalnızca iki iş yüklerine sahip olmamasına karşın, teorik olarak bir sınırı iş yükleri için bu modeli sayısı 24'tür.While this is not an important distinction with only two workloads, the theoretical limit on the number of workloads for this model is 24.
  • Kaynakları, artık her ortam için bir tek bir kaynak grubu içinde gruplandırılır.Resources are no longer grouped in a single resource group for each environment. Kaynakları gruplandırma, her ortam için kullanılan adlandırma kuralları'nın bilinmesini gerektirir.Grouping resources requires an understanding of the naming conventions used for each environment.
  • Eşlenmiş sanal ağa bağlantıların her biri gözden geçirdi ve onaylayan ağ işlemleri kullanıcı.Each of the peered virtual network connections was reviewed and approved by the network operations user.

Artık birden çok abonelik kullanarak bir kaynak yönetim modeli bakalım.Now let's look at a resource management model using multiple subscriptions. Bu modelde, biz ayrı bir abonelik için üç ortamların her birinde hizalama: bir Paylaşılan Hizmetler aboneliği üretim aboneliği ve son olarak bir Geliştirme abonelik.In this model, we'll align each of the three environments to a separate subscription: a shared services subscription, production subscription, and finally a development subscription. Bu model dikkat edilecek noktalara iş yükleri için kaynak gruplarını hizalama nasıl karar vermek sunuyoruz, tek bir abonelik kullanarak bir model benzerdir.The considerations for this model are similar to a model using a single subscription in that we have to decide how to align resource groups to workloads. Biz bu örnekte bu modeli kullanacağız şekilde her iş yükü için bir kaynak grubu oluşturmayı iş yükü yalıtımı gereksinim gerçekleştirip gerçekleştirmediğini zaten saptadıktan.We've already determined that creating a resource group for each workload satisfies the workload isolation requirement, so we'll stick with that model in this example.

  1. Bu modelde, var olan üç abonelikleri: paylaşılan altyapı, üretim, ve geliştirme.In this model, there are three subscriptions: shared infrastructure, production, and development. Her üç bu abonelikler gerektirir bir abonelik sahibive kullanacağız aynı kullanıcı hesabı için üç basit örnekte.Each of these three subscriptions requires a subscription owner, and in the simple example we'll use the same user account for all three. Paylaşılan altyapı kaynakları Yukarıdaki ilk iki örnek benzer şekilde yönetilir ve ilk iş yükü ile ilişkili app1-rg içinde üretim ortamı ve aynı adlı bir kaynak grubuna geliştirme ortam.The shared infrastructure resources are managed similarly to the first two examples above, and the first workload is associated with the app1-rg in the production environment and the same-named resource group in the development environment. App1 iş yükü sahibi kaynak grubuyla eklenir katkıda bulunan rol.The app1 workload owner is added to each of the resource group with the contributor role.
  2. Önceki örnek olarak ile app1 iş yükü sahibi kaynakları oluşturduğunu ve eşleme bağlantısı istekleri paylaşılan altyapı sanal ağ.As with the earlier examples, app1 workload owner creates the resources and requests the peering connection with the shared infrastructure virtual network. App1'i iş yükü sahibi yalnızca ekler managedBy artık ihtiyaç duyulduğu için etiket ortam etiketi.App1 workload owner adds only the managedBy tag because there is no longer a need for the environment tag. Her ortam artık gruplandırılmış için aynı diğer bir deyişle, kaynaklardır abonelik ve ortam etiketi gereksizdir.That is, resources are for each environment are now grouped in the same subscription and the environment tag is redundant. Kalan 49 sanal ağları sınırı sayaç azaltılır.The limit counter is decremented to 49 virtual networks remaining.
  3. Son olarak, abonelik sahibi kaynak gruplarıyla ekleme ikinci iş yükü için işlem yinelenir app2 iş yükü sahibi içinde * katkıda bulunan rolü.Finally, the subscription owner repeats the process for the second workload, adding the resource groups with the app2 workload owner in the *contributor role. Her ortam abonelikler için sınır sayaç kalan 48 sanal ağlara azaltılır.The limit counter for each of the environment subscriptions is decremented to 48 virtual networks remaining.

Bu yönetim modeli, yukarıdaki ikinci örnekte avantajları vardır.This management model has the benefits of the second example above. Ancak, en önemli fark üzerinde iki yayılır Bunun nedeni, sınırları sorun olmasıdır abonelikleri.However, the key difference is that limits are less of an issue due to the fact that they are spread over two subscriptions. Etiketlere göre izlenen maliyet verileri üç arasında toplanması gereken, dezavantajı olan abonelikleri.The drawback is that the cost data tracked by tags must be aggregated across all three subscriptions.

Bu nedenle, bu iki örnek kaynak yönetimi modeller gereksinimlerinizi önceliğini bağlı olarak birini seçebilirsiniz.Therefore, you can select any of these two examples resource management models depending on the priority of your requirements. Kuruluşunuz için tek bir abonelik hizmet sınırları ulaşmaz öngörüyorsanız, tek bir abonelik birden çok kaynak gruplarıyla kullanabilirsiniz.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. Buna karşılık, kuruluşunuzda çok sayıda iş yükü düşünmektedir, her ortam için birden çok abonelik daha iyi olabilir.Conversely, if your organization anticipates many workloads, multiple subscriptions for each environment may be better.

Kaynak Yönetimi modeline uygulamaImplementing the resource management model

Azure kaynaklarına erişimi yöneten birçok farklı model hakkında öğrendiniz.You've learned about several different models for governing access to Azure resources. Artık her biri için bir abonelik kaynak yönetim modeliyle uygulamak gerekli adımları gösterilecektir paylaşılan altyapı, üretim, ve Geliştirme Tasarım Kılavuzu ortamları.Now we'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. Biz bir gerekir abonelik sahibi üç tüm ortamlar için.We'll have one subscription owner for all three environments. Her iş yükü olarak yalıtılmış bir kaynak grubu ile bir iş yükü sahibi ile eklenen katkıda bulunan rol.Each workload will be isolated in a resource group with a workload owner added with the contributor role.

Not

Okuma [azure'da kaynak erişimini anlama] understand-resource-access-in-azure Azure hesaplar ve abonelikler arasındaki ilişki hakkında daha fazla bilgi edinmek için.Read understanding resource access in Azure to learn more about the relationship between Azure Accounts and subscriptions.

Şu adımları uygulayın:Follow these steps:

  1. Oluşturma bir Azure hesabı kuruluşunuzun zaten yoksa.Create an Azure account if your organization doesn't already have one. Azure hesabı için kaydolan kişi Azure Hesap Yöneticisi olur ve kuruluşunuzun liderlik bu rolü üstlenme olanağı bireysel seçmeniz gerekir.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. Bu kişi sorumlu olacaktır:This individual will be responsible for:
    • Abonelik, oluşturma veCreating subscriptions, and
    • Oluşturma ve yönetme Azure Active Directory (AD) kullanıcı kimliği için bu Aboneliklerdeki depolama kiracılar.Creating and administering Azure Active Directory (AD) tenants that store user identity for those subscriptions.
  2. Kuruluşunuzun liderlik ekibindeki hangi kişilerin sorumlu olan karar verir:Your organization's leadership team decides which people are responsible for:
    • Kullanıcı Kimliği yönetimini; bir Azure AD kiracısı varsayılan olarak, kuruluşunuzun Azure hesabı oluşturulduğunda ve hesap yöneticisi olarak eklenir oluşturulur Azure AD genel Yöneticisi varsayılan olarak.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. Kuruluşunuz tarafından kullanıcı kimliği yönetmek için başka bir kullanıcı seçebileceğiniz o kullanıcıya Azure AD genel yönetici rolü atama.Your organization can choose another user to manage user identity by assigning the Azure AD global administrator role to that user.
    • Abonelikler, bu kullanıcılar anlamına gelir:Subscriptions, which means these users:
      • Bu Abonelikteki kaynak kullanımı ile ilişkili maliyetleri yönetmek,Manage costs associated with resource usage in that subscription,
      • Uygulama ve kaynak erişimi için en az bir izin modeli Bakım veImplement and maintain least permission model for resource access, and
      • Hizmet sınırları takip edin.Keep track of service limits.
    • Yani bu kullanıcı sorumlu olduğu (kuruluşunuzun bu modeli kullanan karar verirse) paylaşılan altyapı hizmetleri:Shared infrastructure services (if your organization decides to use this model), which means this user is responsible for:
      • Şirket içi Azure ağı bağlantısını veOn-premises to Azure network connectivity, and
      • Sanal Ağ eşlemesi üzerinden ağ bağlantısı azure'daki sahipliğini.Ownership of network connectivity within Azure through virtual network peering.
    • İş yükü sahipleriyle.Workload owners.
  3. Azure AD genel Yöneticisi yeni kullanıcı hesaplarını oluşturur için:The Azure AD global administrator creates the new user accounts for:
    • Olacaktır kişiye abonelik sahibi her ortamla ilişkili her abonelik için.The person who will be the subscription owner for each subscription associated with each environment. Bu gerekli olduğunu unutmayın yalnızca abonelik Hizmet Yöneticisi her abonelik/ortam için kaynak erişim yönetimiyle görevli değil.Note that this is necessary only if the subscription service administrator will not be tasked with managing resource access for each subscription/environment.
    • Olacaktır kişiye ağ işlemleri kullanıcı, veThe person who will be the network operations user, and
    • Kişiler iş yüküne sahip.The people who are workload owner(s).
  4. Azure Hesap Yöneticisi kullanarak aşağıdaki üç abonelikler oluşturur Azure hesap portalı:The Azure account administrator creates the following three subscriptions using the Azure account portal:
    • Bir abonelik için paylaşılan altyapı ortamıA subscription for the shared infrastructure environment,
    • Bir abonelik için üretim ortamı veA subscription for the production environment, and
    • Bir abonelik için geliştirme ortam.A subscription for the development environment.
  5. Azure Hesap Yöneticisi her bir aboneliğe abonelik hizmet sahibi ekler.The Azure account administrator adds the subscription service owner to each subscription.
  6. Bir onay işlemi oluşturmak iş yükü sahipleriyle kaynak grupları oluşturulmasını istemek için.Create an approval process for workload owners to request the creation of resource groups. Onay süreci birçok yolla gibi e-posta uygulanabilir veya bir işlem yönetim aracı gibi kullanarak yapabilecekleriniz Sharepoint iş akışlarını.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. Onay işlemi aşağıdaki adımları izleyin:The approval process can follow these steps:
    • İş yükü sahibi ikisinde gerekli Azure kaynakları için ürün reçetesi hazırlar geliştirme ortamı üretim ortam ya da her ikisini ve gönderir kendisine abonelik sahibi.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.
    • Abonelik sahibi reçetesi inceler ve doğrular ve istenen kaynaklara denetleme ve istenen kaynaklara gibi planlanan kullanımları için - uygun olduğundan emin olmak için istenen sanal makine boyutları doğrudur.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 - for example, checking that the requested virtual machine sizes are correct.
    • İstek onaylanmamışsa iş yükü sahibi bildirilir.If the request is not approved, the workload owner is notified. İstek onaylanırsa abonelik sahibi istenen kaynak grubu oluşturulur kuruluşunuzun aşağıdaki adlandırma kuralları, ekler iş yükü sahibi ile katkıda bulunan rol ve bildirim gönderen işyüküsahibi , kaynak grubu oluşturuldu.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. İş yükü sahipleriyle bir sanal ağ eşlemesi paylaşılan altyapı sahibinden bağlantı isteği için bir onay işlemi oluşturun.Create an approval process for workload owners to request a virtual network peering connection from the shared infrastructure owner. Önceki adımla gibi bu onay işlemi e-posta veya bir işlem yönetim aracını kullanarak uygulanabilir.As with the previous step, this approval process can be implemented using email or a process management tool.

İdare modelinizi uyguladık, paylaşılan altyapı hizmetlerinizin dağıtabilirsiniz.Now that you've implemented your governance model, you can deploy your shared infrastructure services.

Sonraki adımlarNext steps