여러 팀을 위한 거버넌스 디자인Governance design for multiple teams

이 지침의 목적은 여러 팀, 여러 워크로드 및 여러 환경을 지원하기 위해 Azure에서 리소스 거버넌스 모델을 디자인하는 프로세스를 알아보는 데 있습니다.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. 먼저 가상의 거버넌스 요구 사항 세트를 살펴본 다음 해당 요구 사항을 충족하는 몇 가지 예제 구현을 수행합니다.First you'll look at a set of hypothetical governance requirements, then go through several example implementations that satisfy those requirements.

요구 사항은 다음과 같습니다.The requirements are:

  • 엔터프라이즈는 새로운 클라우드 역할과 책임을 사용자 집합으로 전환할 계획입니다. 따라서 Azure에서 다양한 리소스 액세스 요구 사항을 가진 여러 팀에 대해 ID를 관리해야 합니다.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. ID 관리 시스템은 다음 사용자의 ID를 저장해야 합니다.This identity management system is required to store the identity of the following users:
    • 구독 소유권을 담당하는 조직의 개인The individual in your organization responsible for ownership of subscriptions.
    • 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.
    • 워크로드 관리를 담당하는 조직의 개인 2명Two individuals in your organization responsible for managing a workload.
  • 여러 환경 에 대해 지원합니다.Support for multiple environments. 환경은 가상 머신, 가상 네트워킹 및 네트워크 트래픽 라우팅 서비스와 같은 리소스의 논리적 그룹화입니다.An environment is a logical grouping of resources, such as virtual machines, virtual networking, and network traffic routing services. 이러한 리소스 그룹은 비슷한 관리 및 보안 요구 사항을 포함하고, 일반적으로 테스트 또는 프로덕션과 같은 특정 목적을 위해 사용됩니다.These groups of resources have similar management and security requirements and are typically used for a specific purpose such as testing or production. 이 예에서 요구 사항은 다음 네 가지 환경을 위한 것입니다.In this example, the requirement is for four environments:
    • 다른 환경의 워크로드에서 공유하는 리소스를 포함하는 공유 인프라 환경 입니다.A shared infrastructure environment that includes resources shared by workloads in other environments. 예를 들어 온-프레미스에 연결을 제공하는 게이트웨이 서브넷이 있는 가상 네트워크입니다.For example, a virtual network with a gateway subnet that provides connectivity to on-premises.
    • 가장 제한적인 보안 정책이 있는 프로덕션 환경 입니다.A production environment with the most restrictive security policies. 내부 또는 외부 연결 작업을 포함할 수 있습니다.Could include internal or external facing workloads.
    • 개발 및 테스트 작업을 위한 비프로덕션 환경 입니다.A nonproduction environment for development and testing work. 이 환경에는 프로덕션 환경과 다른 보안, 준수 및 비용 정책이 있습니다.This environment has security, compliance, and cost policies that differ from those in the production environment. Azure에서이는 Enterprise 개발/테스트 구독의 형태를 사용 합니다.In Azure, this takes the form of an Enterprise Dev/Test subscription.
    • 개념 증명 및 교육 목적을 위한 샌드박스 환경 입니다.A sandbox environment for proof of concept and education purposes. 이 환경은 일반적으로 개발 활동에 참여 하는 직원에 게 할당 되며, 회사 데이터가 여기에 방문 하지 못하도록 하는 엄격한 절차 및 운영 보안 제어를 포함 합니다.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. Azure에서 Visual Studio 구독의 형태를 사용 합니다.In Azure, these take the form of Visual Studio subscriptions. 이러한 구독은 엔터프라이즈 Azure Active Directory 연결 되어 있지 않아야 합니다.These subscriptions should also not be tied to the enterprise Azure Active Directory.
  • 기본적으로 사용자가 사용 권한이 없는 최소 권한의 사용 권한 모델 입니다.A permissions model of least privilege in which users have no permissions by default. 모델은 다음을 지원해야 합니다.The model must support the following:
    • 구독 범위에서 신뢰할 수 있는 단일 사용자로, 서비스 계정 처럼 취급 되며 리소스 액세스 권한을 할당할 수 있는 권한이 부여 됩니다.A single trusted user at the subscription scope, treated like a service account and granted permission to assign resource access rights.
    • 각 워크로드 소유자는 기본적으로 리소스에 대한 액세스가 거부됩니다.Each workload owner is denied access to resources by default. 리소스 그룹 범위에서 신뢰할 수 있는 단일 사용자가 리소스 액세스 권한을 명시적으로 부여 합니다.Resource access rights are granted explicitly by the single trusted user at the resource group scope.
    • 공유 인프라 리소스에 대 한 관리 액세스 (공유 인프라 소유자로 제한 됨)Management access for the shared infrastructure resources, limited to the shared infrastructure owners.
    • 각 워크 로드에 대 한 관리 액세스는 프로덕션의 워크 로드 소유자로 제한 되며, 개발 시 제어 수준이 늘어나는 것은 다양 한 배포 환경 (개발, 테스트, 스테이징 및 프로덕션)을 통해 진행 됩니다.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).
    • 엔터프라이즈는 세 가지 주요 환경 각각에서 개별적으로 역할을 관리할 필요가 없으므로 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). 엔터프라이즈에 사용자 지정 역할이 절대적으로 필요한 경우 세 가지 환경에서 사용자 지정 역할을 동기화 하려면 추가 프로세스가 필요 합니다.If the enterprise absolutely requires custom roles, additional processes would be needed to synchronize custom roles across the three environments.
  • 워크로드 소유자 이름, 환경 또는 둘 다의 추적 비용입니다.Cost tracking by workload owner name, environment, or both.

ID 관리Identity management

거버넌스 모델에 대한 ID 관리를 디자인하기 전에 이 모델이 포함하는 네 개의 주요 영역을 이해하는 것이 중요합니다.Before you can design identity management for your governance model, it's important to understand the four major areas it encompasses:

  • 관리: 사용자 id를 만들고, 편집 하 고, 삭제 하는 프로세스와 도구입니다.Administration: The processes and tools for creating, editing, and deleting user identity.
  • 인증: 사용자 이름 및 암호와 같은 자격 증명의 유효성을 검사 하 여 사용자 id를 확인 합니다.Authentication: Verifying user identity by validating credentials, such as a user name and password.
  • 권한 부여: 인증 된 사용자가 액세스할 수 있는 리소스 또는 수행할 권한이 있는 작업을 결정 합니다.Authorization: Determining which resources an authenticated user is allowed to access or what operations they have permission to perform.
  • 감사: 로그 및 기타 정보를 정기적으로 검토 하 여 사용자 id와 관련 된 보안 문제를 검색 합니다.Auditing: Periodically reviewing logs and other information to discover security issues related to user identity. 여기에는 의심 스러운 사용 패턴을 검토 하 고, 정확 하 게 확인 하기 위해 주기적으로 사용자 권한을 검토 하 고, 다른 기능을 포함 합니다This includes reviewing suspicious usage patterns, periodically reviewing user permissions to verify they're accurate, and other functions.

ID에 대해 Azure에서 신뢰하는 유일한 서비스는 Azure AD(Azure Active Directory)입니다.There is only one service trusted by Azure for identity, and that is Azure Active Directory (Azure AD). Azure AD에 사용자를 추가하고 위에 나열된 모든 기능에 대해 Azure AD를 사용하겠습니다.You'll be adding users to Azure AD and using it for all of the functions listed above. Azure AD를 구성 하는 방법을 확인 하기 전에 이러한 서비스에 대 한 액세스를 관리 하는 데 사용 되는 권한 있는 계정을 이해 하는 것이 중요 합니다.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.

조직이 Azure 계정에 등록한 경우 하나 이상의 Azure 계정 소유자 가 할당되었습니다.When your organization signed up for an Azure account, at least one Azure account owner was assigned. 또한 기존 테 넌 트가 조직의 다른 Microsoft 서비스 사용과 이미 연결 되어 있지 않은 경우 (예: Microsoft 365) Azure AD 테 넌 트가 생성 되었습니다.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. Azure AD 테넌트에 대한 모든 권한이 있는 전역 관리자 가 만들어졌을 때 연결됐습니다.A global administrator with full permissions on the Azure AD tenant was associated when it was created.

Azure 계정 소유자와 Azure AD 전역 관리자에 대 한 사용자 id는 Microsoft에서 관리 하는 매우 안전한 id 시스템에 저장 됩니다.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 계정 소유자에 게는 구독을 만들고, 업데이트 하 고, 삭제할 수 있는 권한이 부여 됩니다.The Azure account owner is authorized to create, update, and delete subscriptions. Azure ad 전역 관리자는 Azure AD에서 많은 작업을 수행할 수 있는 권한이 있지만이 디자인 가이드에서는 사용자 id의 생성 및 삭제에 초점을 둡니다.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.

참고

계정과 연결 된 기존 Microsoft 365, Intune 또는 Dynamics 365 라이선스가 있는 경우 조직에 기존 Azure AD 테 넌 트가 이미 있을 수 있습니다.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.

Azure 계정 소유자에 게는 구독을 만들고, 업데이트 하 고, 삭제할 수 있는 권한이 있습니다.The Azure account owner has permission to create, update, and delete subscriptions:

Azure 계정 소유자 및 Azure AD 전역 관리자 를 사용 하는 azure 계정을 보여 주는 다이어그램 그림 1: azure 계정 소유자 및 AZURE AD 전역 관리자를 사용 하는 azure 계정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.

Azure AD 전역 관리자 는 사용자 계정을 만들 권한이 있습니다.The Azure AD global administrator has permission to create user accounts:

Azure AD 전역 관리자가 테 넌 트 에 필요한 사용자 계정을 만들고 있음을 보여 주는 다이어그램 그림 2: AZURE AD 전역 관리자는 테 넌 트에 필요한 사용자 계정을 만듭니다.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.

처음 두 계정인 app1 워크 로드 소유자app2 워크 로드 소유자 는 조직에서 작업을 관리 하는 개인에 연결 됩니다.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. 네트워크 작업 계정은 공유 인프라 리소스를 담당하는 개인이 소유합니다.The network operations account is owned by the individual that is responsible for the shared infrastructure resources. 마지막으로 구독 소유자 계정은 구독 소유권을 담당하는 개인과 연결되어 있습니다.Finally, the subscription owner account is associated with the individual responsible for ownership of subscriptions.

최소 권한의 리소스 액세스 권한 모델Resource access permissions model of least privilege

이제 id 관리 시스템 및 사용자 계정을 만들었기 때문에 최소 권한 모델을 지원 하기 위해 각 계정에 Azure 역할을 적용 하는 방법을 결정 해야 합니다.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.

한 명의 워크로드 소유자가 소유하지 않은 다른 모든 워크로드에 대한 관리 액세스 권한을 갖지 않도록 각 워크로드와 연결된 리소스가 서로 격리되어야 하는 또 다른 요구 사항이 있습니다.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. Azure 역할 기반 액세스 제어의 기본 제공 역할만 사용 하 여이 모델을 구현 해야 하는 요구 사항도 있습니다.There's also a requirement to implement this model using only built-in roles for Azure role-based access control.

각 Azure 역할은 Azure의 세 가지 범위 ( 구독, 리소스 그룹, 개별 리소스) 중 하나에서 적용 됩니다.Each Azure role is applied at one of three scopes in Azure: subscription, resource group, then an individual resource. 역할은 더 낮은 범위에서 상속됩니다.Roles are inherited at lower scopes. 예를 들어 사용자에 게 구독 수준에서 기본 제공 소유자 역할이 할당 된 경우 해당 역할은 재정의 되지 않는 한 리소스 그룹 및 개별 리소스 수준에서 해당 사용자에 게 할당 됩니다.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.

따라서 최소 권한 액세스 모델을 만들려면 특정 유형의 사용자가 이러한 세 범위에서 수행할 수 있는 작업을 결정 해야 합니다.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. 예를 들어 요구 사항은 워크로드 소유자가 다른 리소스를 제외한 해당 워크로드와 연결된 리소스에 대해서만 액세스를 관리할 권한을 갖는 것입니다.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. 구독 범위에서 기본 제공 소유자 역할을 할당 하는 경우 각 워크 로드 소유자는 모든 워크 로드에 대 한 관리 액세스 권한을 보유 합니다.If you were to assign the built-in Owner role at the subscription scope, each workload owner would have management access to all workloads.

이 개념을 좀 더 잘 이해하려면 두 사용 권한 모델 예제에 대해 살펴보겠습니다.Let's take a look at two example permission models to understand this concept a little better. 첫 번째 예제에서 모델은 서비스 관리자만을 신뢰 하 여 리소스 그룹을 만듭니다.In the first example, the model trusts only the Service Administrator to create resource groups. 두 번째 예제에서 모델은 구독 범위에서 각 워크 로드 소유자에 게 기본 제공 소유자 역할을 할당 합니다.In the second example, the model assigns the built-in Owner role to each workload owner at the subscription scope.

두 예제 모두 구독 범위에서 기본 제공 소유자 역할이 할당 된 구독 서비스 관리자가 있습니다.In both examples, there is a subscription Service Administrator that is assigned the built-in Owner role at the subscription scope. 기본 제공 소유자 역할은 리소스에 대 한 액세스 관리를 비롯 한 모든 권한을 부여 합니다.Recall that the built-in Owner role grants all permissions including the management of access to resources.

소유자 역할을 사용 하는 구독 서비스 관리자 그림 3: 서비스 관리자를 사용 하는 구독이 기본 제공 소유자 역할을 할당 했습니다.Subscription service administrator with owner role Figure 3: A subscription with a Service Administrator assigned the built-in Owner role.

  1. 첫 번째 예제에서 작업 소유자 A 에는 구독 범위에서 사용 권한이 없으며 기본적으로 리소스 액세스 관리 권한이 없습니다.In the first example, workload owner A has no permissions at the subscription scope and no resource access management rights by default. 이 사용자는 해당 워크로드에 대한 리소스를 배포하고 관리하려 합니다.This user wants to deploy and manage the resources for their workload. 리소스 그룹 만들기를 요청하려면 서비스 관리자 에게 문의해야 합니다.They must contact the service administrator to request creation of a resource group. 작업 소유자가 리소스 그룹 A 만들기를 요청 합니다.Workload owner requests creation of resource group A
  2. 서비스 관리자 는 해당 요청을 검토 하 고 리소스 그룹 A를 만듭니다. 이 시점에서 작업 소유자 A는 여전히 작업 을 수행할 수 있는 권한이 없습니다.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. 서비스 관리자가 리소스 그룹 A를 만듭니다.Service administrator creates resource group A
  3. 서비스 관리자리소스 그룹 a작업 소유자 a 를 추가 하 고 기본 제공 참가자 역할을 할당 합니다.The service administrator adds workload owner A to resource group A and assigns the built-in Contributor role. 참가자 역할은 액세스 권한을 관리 하는 것을 제외 하 고 리소스 그룹 A 에 대 한 모든 권한을 부여 합니다.The Contributor role grants all permissions on resource group A except managing access permission. 서비스 관리자가 리소스 그룹 A에 작업 소유자 A를 추가 합니다.Service administrator adds workload owner A to resource group A
  4. 워크 로드 소유자 a 에 게 작업에 대 한 용량 계획의 일부로 CPU 및 네트워크 트래픽 모니터링 데이터를 확인 하는 데 필요한 요구 사항이 있다고 가정 하겠습니다.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. 작업 소유자 A에 는 참가자 역할이 할당 되기 때문에 리소스 그룹 a 에 사용자를 추가할 수 있는 권한이 없습니다. 서비스 관리자 에 게이 요청을 보내야 합니다.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. 작업 소유자 요청 작업 참가자가 리소스 그룹에 추가 됨Workload owner requests workload contributors be added to resource group
  5. 서비스 관리자 가 요청을 검토 하 고 두 개의 작업 참가자 사용자를 리소스 그룹 A 에 추가 합니다. 이러한 두 사용자 모두 리소스를 관리할 수 있는 권한이 필요 하지 않으므로 기본 제공 읽기 권한자 역할이할당 됩니다.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. 서비스 관리자가 리소스 그룹 A에 작업 참가자를 추가 합니다.Service administrator adds workload contributors to resource group A
  6. 다음으로 워크로드 소유자 B 는 리소스 그룹이 해당 워크로드에 대한 리소스를 포함할 것을 요구합니다.Next, workload owner B also requires a resource group to contain the resources for their workload. 워크로드 소유자 A 와 마찬가지로 워크로드 소유자 B 는 처음에 구독 범위에서 작업을 수행할 권한이 없으므로 요청을 서비스 관리자 에게 보내야 합니다.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. 작업 소유자 B가 리소스 그룹 B의 생성을 요청 합니다.Workload owner B requests creation of resource group B
  7. 서비스 관리자가 요청을 검토 하 고 리소스 그룹 B 를 만듭니다. 서비스 관리자가 리소스 그룹 B를 만듭니다.The service administrator reviews the request and creates resource group B. Service administrator creates resource group B
  8. 그러면 서비스 관리자리소스 그룹 b작업 소유자 b 를 추가 하 고 기본 제공 참가자 역할을 할당 합니다.The service administrator then adds workload owner B to resource group B and assigns the built-in Contributor role. 서비스 관리자가 리소스 그룹 B에 작업 소유자 B를 추가 합니다.Service administrator adds workload owner B to resource group B

이 시점에서 각 워크로드 소유자는 해당 고유 리소스 그룹에서 격리됩니다.At this point, each of the workload owners is isolated in their own resource group. 워크로드 소유자 또는 팀 멤버 중 누구도 다른 모든 리소스에서 관리 액세스 권한이 없습니다.None of the workload owners or their team members have management access to the resources in any other resource group.

리소스 그룹이 A 및 B 인 구독을 보여 주는 다이어그램 그림 4: 자체 리소스 그룹과 격리 된 두 개의 작업 소유자가 있는 구독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.

이 모델은 최소 권한 모델입니다.This model is a least-privilege model. 각 사용자에 게 올바른 리소스 관리 범위에서 올바른 권한이 할당 됩니다.Each user is assigned the correct permission at the correct resource management scope.

이 예제의 모든 작업은 서비스 관리자 가 수행 해야 합니다.Consider that every task in this example was performed by the service administrator. 이 예제는 간단하며, 워크로드 소유자가 두 명밖에 없었기 때문에 문제처럼 보이지 않을 수 있는 반면 대규모 조직의 경우에 이런 문제 유형이 발생한다는 것은 쉽게 상상할 수 있습니다.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. 예를 들어 서비스 관리자 는 요청의 큰 백로그가 있는 병목 상태가 되어 결국 지연될 수 있습니다.For example, the service administrator can become a bottleneck with a large backlog of requests that result in delays.

서비스 관리자 가 수행하는 작업의 수를 줄여주는 두 번째 예제를 살펴보겠습니다.Let's take a look at second example that reduces the number of tasks performed by the service administrator.

  1. 이 모델에서 작업 소유자 a 는 구독 범위에서 기본 제공 소유자 역할을 할당 하 여 리소스 그룹 a 리소스 그룹을 만들 수 있도록 합니다. 서비스 관리자가 구독에 작업 소유자 A를 추가 합니다.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. 리소스 그룹 a 를 만들면 작업 소유자 A 가 기본적으로 추가 되 고 구독 범위에서 기본 제공 소유자 역할을 상속 합니다.When resource group A is created, workload owner A is added by default and inherits the built-in Owner role from the subscription scope. 작업 소유자 A가 리소스 그룹 A를 만듭니다.Workload owner A creates resource group A
  3. 기본 제공 소유자 역할은 작업 소유자 에 게 리소스 그룹에 대 한 액세스를 관리할 수 있는 권한을 부여 합니다.The built-in Owner role grants workload owner A permission to manage access to the resource group. 워크 로드 소유자 A는 두 개의 워크 로드 참가자 를 추가 하 고 각각에 기본 제공 읽기 권한자 역할을 할당 합니다.Workload owner A adds two workload contributors and assigns the built-in Reader role to each of them. 워크 로드 소유자 A가 작업 참가자를 추가 합니다.Workload owner A adds workload contributors
  4. 서비스 관리자 는 이제 기본 제공 소유자 역할을 사용 하 여 작업 소유자 B 를 구독에 추가 합니다.The Service Administrator now adds workload owner B to the subscription with the built-in Owner role. 서비스 관리자가 구독에 작업 소유자 B를 추가 합니다.Service Administrator adds workload owner B to subscription
  5. 워크로드 소유자 B리소스 그룹 B 를 만들고 기본적으로 추가됩니다.Workload owner B creates resource group B and is added by default. 다시, 워크 로드 소유자 B 는 구독 범위에서 기본 제공 소유자 역할을 상속 합니다.Again, workload owner B inherits the built-in Owner role from the subscription scope. 작업 소유자 B가 리소스 그룹 B를 만듭니다.Workload owner B creates resource group B

이 모델에서 서비스 관리자 는 개별 워크로드 소유자 각각에 대한 관리 액세스의 위임으로 인해 첫 번째 예제에서 보다 더 적은 작업을 수행했습니다.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.

리소스 그룹 A와 B에 대 한 서비스 관리자와 두 개의 작업 소유자를 보여 주는 다이어그램입니다. 그림 5: 서비스 관리자와 두 개의 워크 로드 소유자가 있는 구독에는 모두 기본 제공 소유자 역할이 할당 됩니다.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.

작업 소유자 A워크 로드 소유자 B 는 모두 구독 범위에서 기본 제공 소유자 역할을 할당 하기 때문에 각각 서로의 리소스 그룹에 대해 기본 제공 소유자 역할을 상속 받습니다.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. 즉, 서로 다른 리소스에 대 한 전체 액세스를 가질 뿐만 아니라 서로 다른 리소스 그룹에 대 한 관리 액세스를 위임할 수도 있습니다.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. 예를 들어 워크 로드 소유자 B리소스 그룹 A 에 다른 사용자를 추가 하 고 기본 제공 소유자 역할을 비롯 하 여 역할을 할당할 수 있습니다.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.

요구 사항과 각 예제를 비교하면 두 예제는 모두 두 워크로드 소유자에 대한 리소스 액세스 권한을 부여할 사용 권한이 있는 구독 범위에서 신뢰할 수 있는 단일 사용자를 지원한다는 것을 확인합니다.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. 두 워크로드 소유자 각자는 기본적으로 리소스 관리에 대한 액세스 권한이 없었으며 명시적으로 서비스 관리자 에게 해당 권한을 할당하도록 요구했습니다.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. 첫 번째 예제만 각 워크 로드와 연결 된 리소스를 서로 격리 하 여 작업 소유자가 다른 작업의 리소스에 액세스할 수 없도록 하는 요구 사항을 지원 합니다.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.

리소스 관리 모델Resource management model

최소 권한의 사용 권한 모델을 디자인했으므로 이러한 거버넌스 모델로 이동해 몇 가지 실제적인 애플리케이션을 살펴보겠습니다.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. 다음 세 환경을 지원해야 하는 요구 사항을 다시 확인해 봅니다.Recall from the requirements that you must support the following three environments:

  1. 공유 인프라 환경: 모든 작업에서 공유 하는 리소스 그룹입니다.Shared infrastructure environment: A group of resources shared by all workloads. 이들은 네트워크 게이트웨이, 방화벽 및 보안 서비스 같은 리소스입니다.These are resources such as network gateways, firewalls, and security services.
  2. 프로덕션 환경: 여러 프로덕션 작업을 나타내는 여러 리소스 그룹입니다.Production environment: Multiple groups of resources representing multiple production workloads. 이러한 리소스는 개인 및 공용 응용 프로그램 아티팩트를 호스트 하는 데 사용 됩니다.These resources are used to host the private and public-facing application artifacts. 이러한 리소스에는 일반적으로 리소스, 애플리케이션 코드 및 데이터를 무단 액세스로부터 보호하려면 가장 강력한 거버넌스 및 보안 모델이 있습니다.These resources typically have the tightest governance and security models to protect the resources, application code, and data from unauthorized access.
  3. 사전 프로덕션 환경: 여러 개의 프로덕션이 준비 되지 않은 작업을 나타내는 여러 리소스 그룹입니다.Preproduction environment: Multiple groups of resources representing multiple non-production-ready workloads. 이러한 리소스는 개발 및 테스트에 사용 되며 개발자 민첩성을 높일 수 있는 보다 완화 된 거 버 넌 스 모델을 포함할 수 있습니다.These resources are used for development and testing, and may have a more relaxed governance model to enable increased developer agility. 응용 프로그램 개발 프로세스가 프로덕션에 더 가깝게 이동 하면 이러한 그룹 내의 보안이 증가 합니다.Security within these groups should increase as the application development process moves closer to production.

이러한 세 가지 환경 각각의 경우 워크로드 소유자, 환경 또는 둘 다에 의한 비용 데이터 추적 요구 사항이 있습니다.For each of these three environments, there is a requirement to track cost data by workload owner, environment, or both. 즉, 공유 인프라 의 지속적인 비용, 비프로덕션프로덕션 환경에서 개인이 발생 한 비용, 그리고 비프로덕션프로덕션 환경의 전반적인 비용을 파악 하는 것이 좋습니다.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.

리소스가 구독리소스 그룹, 두 수준으로 구분된다는 것을 이미 알게 됐습니다.You have already learned that resources are scoped to two levels: subscription and resource group. 따라서 첫 번째로 구독 으로 환경을 구성하는 방법을 결정합니다.Therefore, the first decision is how to organize environments by subscription. 단일 구독 또는 여러 구독 이라는 두 가지 가능성이 있습니다.There are only two possibilities: a single subscription or multiple subscriptions.

이러한 모델 각각의 예를 살펴보기 전에 Azure에서 구독에 대한 관리 구조를 검토해 보겠습니다.Before you look at examples of each of these models, let's review the management structure for subscriptions in Azure.

구독을 담당하는 조직의 개인이 있으며 이 사용자가 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. 이 계정에는 구독을 만들 수 있는 권한이 없습니다.This account does not have permission to create subscriptions. Azure 계정 소유자 만이 작업을 수행할 수 있는 권한이 있습니다.Only the Azure account owner has permission to do this:

Azure 계정 소유자는 구독 그림 6을 만듭니다. azure 계정 소유자는 구독을 만듭니다.An Azure account owner creates a subscription Figure 6: An Azure account owner creates a subscription.

구독이 생성 되 면 Azure 계정 소유자소유자 역할을 사용 하 여 구독에 구독 소유자 계정을 추가할 수 있습니다.Once the subscription has been created, the Azure account owner can add the subscription owner account to the subscription with the owner role:

Azure 계정 소유자는 구독 소유자 사용자 계정을 소유자 역할을 사용 하 여 구독에 추가 합니다. 그림 7: Azure 계정 소유자는 구독 소유자 사용자 계정을 소유자 역할을 사용 하 여 구독에 추가 합니다.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.

이제 구독 소유자 계정에서 리소스 그룹 을 만들고 리소스 액세스 관리를 위임할 수 있습니다.The subscription owner account can now create resource groups and delegate resource access management.

먼저, 단일 구독을 사용하여 예제 리소스 관리 모델을 살펴봅시다.First let's look at an example resource management model using a single subscription. 첫 번째로 세 가지 환경에 리소스 그룹을 정렬하는 방법을 결정합니다.The first decision is how to align resource groups to the three environments. 다음 두 가지 옵션을 사용할 수 있습니다.You have two options:

  1. 단일 리소스 그룹에 각 환경을 정렬합니다.Align each environment to a single resource group. 모든 공유 인프라 리소스를 단일 공유 인프라 리소스 그룹에 배포합니다.All shared infrastructure resources are deployed to a single shared infrastructure resource group. 개발 워크로드와 연결된 모든 리소스를 단일 개발 리소스 그룹에 배포합니다.All resources associated with development workloads are deployed to a single development resource group. 프로덕션 워크로드와 연결된 모든 리소스를 프로덕션 환경에 대한 단일 프로덕션 리소스 그룹에 배포합니다.All resources associated with production workloads are deployed into a single production resource group for the production environment.
  2. 각 워크로드에 대해 별도 리소스 그룹을 만들고, 명명 규칙 및 태그를 사용하여 세 가지 환경 각각에 리소스 그룹을 정렬합니다.Create separate resource groups for each workload, using a naming convention and tags to align resource groups with each of the three environments.

첫 번째 옵션 평가로 시작합시다.Let's begin by evaluating the first option. 이전 섹션에서 설명한 사용 권한 모델을 사용 하 여 리소스 그룹을 만들고 기본 제공 참여자 또는 읽기 권한자 역할로 사용자를 추가 하는 단일 구독 서비스 관리자를 사용 합니다.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. 배포된 첫 번째 리소스 그룹은 공유 인프라 환경을 나타냅니다.The first resource group deployed represents the shared infrastructure environment. 구독 소유자 계정은 이라는 공유 인프라 리소스에 대 한 리소스 그룹을 만듭니다 netops-shared-rg .The subscription owner account creates a resource group for the shared infrastructure resources named netops-shared-rg. 리소스 그룹 만들기Creating a resource group
  2. 구독 소유자 계정은 네트워크 운영 사용자 계정을 리소스 그룹에 추가 하 고 참가자 역할을 할당 합니다.The subscription owner account adds the network operations user account to the resource group and assigns the contributor role. 네트워크 작업 사용자 추가Adding a network operations user
  3. 네트워크 작업 사용자VPN 게이트웨이를 만들고 온-프레미스 VPN 어플라이언스에 연결하도록 구성합니다.The network operations user creates a VPN gateway and configures it to connect to the on-premises VPN appliance. 또한 네트워크 작업 사용자 는 각 리소스 (및)에 쌍의 태그 를 적용 environment:shared 합니다 managedBy:netops .The network operations user also applies a pair of tags to each of the resources: environment:shared and managedBy:netops. 구독 서비스 관리자 가 비용 보고서를 내보내는 경우 비용은 이러한 태그 각각에 맞춰 정렬됩니다.When the subscription service administrator exports a cost report, costs will be aligned with each of these tags. 이를 통해 구독 서비스 관리자environment 태그 및 태그를 사용 하 여 비용을 피벗할 수 있습니다 managedBy .This allows the subscription service administrator to pivot costs using the environment tag and the managedBy tag. 리소스 제한 은 그림의 맨 위 오른쪽에 카운터됩니다.Notice the resource limits counter at the top right-hand side of the figure. 각 Azure 구독에는 제한 서비스가 있으며, 이러한 제한의 효과를 이해하도록 도우려면 각 구독에 대해 가상 네트워크 제한을 따릅니다.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. 구독 당 가상 네트워크는 1000 개로 제한 되며, 첫 번째 가상 네트워크를 배포한 후에는 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. VPN 게이트웨이 만들기Creating a VPN gateway
  4. 리소스 그룹이 두 개 더 배포됩니다.Two more resource groups are deployed. 첫 번째의 이름은 prod-rg입니다.The first is named prod-rg. 이 리소스 그룹은 프로덕션 환경에 맞춰집니다.This resource group is aligned with the production environment. 두 번째의 이름은 dev-rg며 개발 환경에 맞춰집니다.The second is named dev-rg and is aligned with the development environment. 프로덕션 작업과 연결된 모든 리소스는 프로덕션 환경에 배포되고 개발 워크로드와 연결된 모든 리소스는 개발 환경에 배포됩니다.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. 이 예에서 두 개의 워크로드를 이러한 두 환경 각각에 배포하므로 모든 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. 각 리소스 그룹에는 리소스 그룹당 800 리소스 제한이 있습니다.Consider that each resource group has a limit of 800 resources per resource group. 각 리소스 그룹에 워크 로드를 계속 추가 하는 경우 최종적으로이 제한에 도달 하 게 됩니다.If you continue to add workloads to each resource group, you'll eventually reach this limit. 리소스 그룹 만들기Creating resource groups
  5. 첫 번째 워크로드 소유자 는 요청을 구독 서비스 관리자 에게 보내고 기여자 역할이 있는 개발 및 프로덕션 환경 리소스 그룹 각각에 추가됩니다.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. 앞에서 살펴본 것처럼 기여자 역할은 다른 사용자에게 역할을 할당하지 않고 사용자가 모든 작업을 수행하게 합니다.As you learned earlier, the contributor role allows the user to perform any operation other than assigning a role to another user. 첫 번째 워크로드 소유자 는 이제 해당 워크로드와 연결된 리소스를 만들 수 있습니다.The first workload owner can now create the resources associated with their workload. 가상 네트워크를 만들고, 환경을 적용 하 고, 태그를 통해 모든 리소스에 관리 하는 첫 번째 워크 로드 소유자를 보여 주는 다이어그램입니다.Diagram showing the first workload owner creating virtual networks and applying the environment and managed By tags to all resources.
  6. 첫 번째 워크로드 소유자 는 각각에 가상 머신 쌍이 포함된 두 리소스 그룹의 각각에서 가상 네트워크를 만듭니다.The first workload owner creates a virtual network in each of the two resource groups with a pair of virtual machines in each. 첫 번째 작업 소유자environmentmanagedBy 태그를 모든 리소스에 적용 합니다.The first workload owner applies the environment and managedBy tags to all resources. Azure 서비스 제한 카운터는 이제 남은 가상 네트워크 997대를 나타내고 있습니다.Note that the Azure service limit counter is now at 997 virtual networks remaining. 가상 네트워크 만들기Creating virtual networks
  7. 만들 때 온-프레미스에 연결 된 가상 네트워크가 없습니다.None of the virtual networks has connectivity to on-premises when created. 이러한 유형의 아키텍처에서 각 가상 네트워크는 hub-vnet 공유 인프라 환경에서로 피어 링 되어야 합니다.In this type of architecture, each virtual network must be peered to the hub-vnet in the shared infrastructure environment. 가상 네트워크 피어링은 두 개의 별도 가상 네트워크 간에 연결을 만들고 두 네트워크 간에 이동하는 네트워크 트래픽을 허용합니다.Virtual network peering creates a connection between two separate virtual networks and allows network traffic to travel between them. 가상 네트워크 피어링은 기본적으로 전이적이지 않습니다.Note that virtual network peering is not inherently transitive. 연결 된 두 개의 가상 네트워크에서 피어 링을 지정 해야 하며, 가상 네트워크 중 하나만 피어 링을 지정 하는 경우 연결이 불완전 합니다.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. 이로 인 한 영향을 설명 하기 위해 첫 번째 작업 소유자 는와 간의 피어 링을 지정 합니다 prod-vnet hub-vnet .To illustrate the effect of this, the first workload owner specifies a peering between prod-vnet and hub-vnet. 첫 번째 피어 링이 만들어지지만에서로의 보완 피어 링 hub-vnet 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. 첫 번째 워크로드 소유자네트워크 작업 사용자에게 문의하여 이 보완 피어링 연결을 요청합니다.The first workload owner contacts the network operations user and requests this complementary peering connection. Og 링 연결을 만드는 방법을 보여 주는 다이어그램입니다.Diagram that shows the creation og a peering connection.
  8. 네트워크 작업 사용자는 요청을 검토 하 고 승인한 후의 설정에서 피어 링을 지정 합니다 hub-vnet .The network operations user reviews the request, approves it, then specifies the peering in the settings for the hub-vnet. 이제 피어 링 연결이 완료 되 고 두 가상 네트워크 간에 네트워크 트래픽이 흐릅니다.The peering connection is now complete, and network traffic flows between the two virtual networks. 요청 승인 및 피어 링 설정 지정을 보여 주는 다이어그램Diagram showing the approval of the request and the specifying of the peering settings.
  9. 첫 번째 워크로드 소유자 는 요청을 구독 서비스 관리자 에게 보내고 기여자 역할이 있는 기존의 개발프로덕션 환경 리소스 그룹에 추가됩니다.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. 두 번째 워크로드 소유자 는 각 리소스 그룹의 첫 번째 워크로드 소유자 와 동일한 권한을 모든 리소스에 대해 갖습니다.The second workload owner has the same permissions on all resources as the first workload owner in each resource group. 리소스 그룹에 추가 되는 두 번째 작업 소유자를 보여 주는 다이어그램Diagram showing the second workload owner being added to teh resource groups.
  10. 두 번째 워크 로드 소유자 는 가상 네트워크에 서브넷을 만든 prod-vnet 다음 두 개의 가상 머신을 추가 합니다.The second workload owner creates a subnet in the prod-vnet virtual network, then adds two virtual machines. 두 번째 워크 로드 소유자environmentmanagedBy 태그를 각 리소스에 적용 합니다.The second workload owner applies the environment and managedBy tags to each resource. 서브넷 만들기Creating subnets

이 예제 리소스 관리 모델을 사용하면 세 가지 필수 환경에서 리소스를 관리할 수 있습니다.This example resource management model enables us to manage resources in the three required environments. 구독에 있는 한 명의 사용자만 이러한 리소스에 액세스할 수 있는 권한을 가지 므로 공유 인프라 리소스는 보호 됩니다.The shared infrastructure resources are protected because only a single user in the subscription has permission to access those resources. 각 워크 로드 소유자는 공유 리소스 자체에 대 한 사용 권한이 없어도 공유 인프라 리소스를 사용할 수 있습니다.Each of the workload owners can use the shared infrastructure resources without having any permissions on the shared resources themselves. 워크 로드 소유자 는 모두 서로의 작업의 리소스에 액세스할 수 있으므로이 관리 모델은 워크 로드 격리에 대 한 요구 사항을 충족 하지 않습니다.This management model fails the requirement for workload isolation, because both workload owners can access the resources of each other's workload.

즉시 알 수 없는 이 모델에 대해 다른 중요한 고려 사항이 있습니다.There's another important consideration with this model that may not be immediately obvious. 이 예제에서는 온-프레미스 네트워크에 대 한 연결을 제공 하기 위해와의 네트워크 피어 링 연결을 요청한 작업 소유자가 app1 되었습니다 hub-vnet .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. 네트워크 작업 사용자는 해당 워크로드에 배포된 리소스에 기반한 해당 요청을 평가했습니다.The network operations user evaluated that request based on the resources deployed with that workload. 구독 소유자 계정에 app2 작업 소유자 가 추가 되 면 해당 사용자에 게 리소스 그룹의 모든 리소스에 대 한 관리 액세스 권한이 부여 prod-rg 됩니다.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.

관리 액세스 권한을 보여 주는 다이어그램

즉, app2 워크 로드 소유자 는 가상 네트워크의 가상 컴퓨터를 사용 하 여 자체 서브넷을 배포할 권한이 prod-vnet 있습니다.This means app2 workload owner had permission to deploy their own subnet with virtual machines in the prod-vnet virtual network. 기본적으로 해당 가상 머신은 온-프레미스 네트워크에 액세스할 수 있습니다.By default, those virtual machines have access to the on-premises network. 네트워크 작업 사용자는 해당 머신을 인식하지 못하고 있으며 온-프레미스에 연결을 승인하지 않았습니다.The network operations user is not aware of those machines and did not approve their connectivity to on-premises.

다음으로, 다른 환경 및 워크 로드에 대 한 여러 리소스 그룹을 포함 하는 단일 구독을 살펴보겠습니다.Next, let's look at a single subscription with multiple resource groups for different environments and workloads. 이전 예제에서 각 환경에 대한 리소스는 동일한 리소스 그룹에 있었기 때문에 쉽게 식별할 수 있었습니다.Note that in the previous example, the resources for each environment were easily identifiable because they were in the same resource group. 더 이상 해당 그룹화가 없으므로 해당 기능을 제공하려면 리소스 그룹 명명 규칙에 따라야 합니다.Now that you no longer have that grouping, you will have to rely on a resource group naming convention to provide that functionality.

  1. 공유 인프라 리소스는 이 모델에서 별도 리소스 그룹이 아직 없으므로 동일하게 유지됩니다.The shared infrastructure resources will still have a separate resource group in this model, so that remains the same. 각 워크 로드에는 개발프로덕션 환경 마다 하나씩 두 개의 리소스 그룹이 필요 합니다.Each workload requires two resource groups, one for each of the development and production environments. 첫 번째 워크 로드의 경우 구독 소유자 계정은 두 개의 리소스 그룹을 만듭니다.For the first workload, the subscription owner account creates two resource groups. 첫 번째에는 이름이로 지정 되 app1-prod-rg 고 두 번째에는 이름이 지정 됩니다 app1-dev-rg .The first is named app1-prod-rg and the second is named app1-dev-rg. 앞에서 설명한 대로이 명명 규칙은 첫 번째 작업, app1개발 또는 프로덕션 환경에 연결 되는 리소스를 식별 합니다.As discussed earlier, this naming convention identifies the resources as being associated with the first workload, app1, and either the development or production environment. 다시, 구독 소유자 계정은 참가자 역할을 사용 하 여 리소스 그룹에 app1 워크 로드 소유자 를 추가 합니다.Again, the subscription owner account adds app1 workload owner to the resource group with the contributor role. 앱 1 prod r g 및 앱 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. 첫 번째 예제와 마찬가지로 app1 워크 로드 소유자 는 이라는 가상 네트워크를 app1-prod-vnet 프로덕션 환경에 배포 하 고 다른 이름은 app1-dev-vnet 개발 환경에 배포 합니다.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. 다시, app1 워크로드 소유자 는 피어링 연결을 만들려면 네트워크 작업 에 요청을 전송합니다.Again, app1 workload owner sends a request to the network operations user to create a peering connection. app1 워크로드 소유자 가 첫 번째 예제에서와 동일한 태그를 추가하고 제한 카운터는 구독에 남아 있는 997대 가상 네트워크로 감소됐습니다.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. 앱 1의 배포를 보여 주는 다이어그램 1 prod v net 및 app 1 dev v 가상 네트워크입니다.A diagram showing the deployment of the app 1 prod v net and app 1 dev v net virtual networks.
  3. 이제 구독 소유자 계정이 app2 워크 로드 소유자 에 대해 두 개의 리소스 그룹을 만듭니다.The subscription owner account now creates two resource groups for app2 workload owner. App1 워크 로드 소유자 와 동일한 규칙에 따라 리소스 그룹의 이름은 app2-prod-rgapp2-dev-rg 입니다.Following the same conventions as for app1 workload owner, the resource groups are named app2-prod-rg and app2-dev-rg. 구독 소유자 계정은 참가자 역할을 사용 하 여 각 리소스 그룹에 app2 워크 로드 소유자 를 추가 합니다.The subscription owner account adds app2 workload owner to each of the resource groups with the contributor role. 앱 2 prod r g 및 앱 2 dev r g 리소스 그룹 추가를 보여 주는 다이어그램입니다.A diagram showing the addition of the app 2 prod r g and app 2 dev r g resource groups.
  4. App2 워크 로드 소유자 계정은 동일한 명명 규칙을 사용 하 여 리소스 그룹에 가상 네트워크 및 가상 컴퓨터를 배포 합니다.The app2 workload owner account deploys virtual networks and virtual machines to the resource groups with the same naming conventions. 태그가 추가되고 제한 카운터는 구독에 남아 있는 995대 가상 네트워크로 감소됐습니다.Tags are added and the limit counter has been decremented to 995 virtual networks remaining in the subscription. 가상 네트워크 및 Vm 배포Deploying virtual networks and VMs
  5. App2 워크 로드 소유자 계정은 네트워크 작업 사용자 에 게를 피어 링 하는 요청을 보냅니다 app2-prod-vnet 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. 네트워크 작업 사용자는 피어링 연결을 만듭니다.The network operations user creates the peering connection. 허브 v 넷를 사용 하는 앱 2 prod v 넷의 피어 링을 보여 주는 다이어그램입니다.A diagram showing the peering of app 2 prod v net with the hub v net.

결과 관리 모델은 첫 번째 예제와 유사하며 다음과 같은 몇 가지 주요 차이점이 있습니다.The resulting management model is similar to the first example, with several key differences:

  • 두 워크로드 각각은 워크로드 및 환경에 의해 격리됩니다.Each of the two workloads is isolated by workload and by environment.
  • 이 모델에는 첫 번째 예제 모델보다 두 개 더 많은 가상 네트워크가 필요합니다.This model required two more virtual networks than the first example model. 두 워크로드만으로 중요한 차이가 아닐 수 있지만 이 모델에 대한 워크로드 수의 제한은 이론적으로 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.
  • 리소스는 각 환경에 대한 단일 리소스 그룹에서 더 이상 그룹화되지 않습니다.Resources are no longer grouped in a single resource group for each environment. 리소스 그룹화에는 각 환경에 사용된 명명 규칙에 대한 이해가 필요합니다.Grouping resources requires an understanding of the naming conventions used for each environment.
  • 네트워크 작업 사용자 는 각 피어 링 가상 네트워크 연결을 검토 하 고 승인 했습니다.Each of the peered virtual network connections was reviewed and approved by the network operations user.

여러 구독을 사용하여 리소스 관리 모델을 살펴봅시다.Now let's look at a resource management model using multiple subscriptions. 이 모델에서는 공유 서비스 구독, 프로덕션 구독 및 마지막으로 개발 구독의 세 가지 환경 각각을 별도 구독에 맞춰 정렬하겠습니다.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. 이 모델에 대한 고려 사항은 워크로드에 맞춰 리소스 그룹을 정렬하는 방법을 결정해야 하는 단일 구독을 사용한 모델과 유사합니다.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. 각 워크로드에 대한 리소스 그룹의 생성은 워크로드 격리 요구 사항을 충족하는 것으로 이미 결정했으므로 이 예제에서는 해당 모델을 계속 사용하겠습니다.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. 이 모델에는 공유 인프라, 프로덕션개발과 같은 세 가지 구독이 있습니다.In this model, there are three subscriptions: shared infrastructure, production, and development. 이러한 세 가지 구독 각각에는 구독 소유자가 필요하고, 간단한 예제에서는 세 가지 모두에 대해 동일한 사용자 계정을 사용합니다.Each of these three subscriptions requires a subscription owner, and in the simple example you'll use the same user account for all three. 공유 인프라 리소스는 위의 처음 두 예제와 유사 하 게 관리 되며, 첫 번째 작업은 app1-rg 프로덕션 환경의 리소스 그룹과 개발 환경에서 동일한 이름의 리소스 그룹에 연결 됩니다.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. App1 작업 소유자 계정이 참가자 역할을 사용 하 여 각 리소스 그룹에 추가 됩니다.The app1 workload owner account is added to each of the resource group with the contributor role.

    공유 인프라 리소스를 관리 하는 방법을 보여 주는 다이어그램

  2. 이전 예제에서와 마찬가지로 app1 워크로드 소유자 는 요청을 만들고 공유 인프라 가상 네트워크와 피어링 연결을 요청합니다.As with the earlier examples, app1 workload owner creates the resources and requests the peering connection with the shared infrastructure virtual network. App1 작업 소유자 계정은 태그가 managedBy 더 이상 필요 하지 않으므로 태그만 추가 합니다 environment .The app1 workload owner account adds only the managedBy tag because there is no longer a need for the environment tag. 즉, 각 환경에 대 한 리소스는 이제 동일한 구독 에서 그룹화 되 고 environment 태그는 중복 됩니다.That is, resources are for each environment are now grouped in the same subscription and the environment tag is redundant. 제한 카운터는 남은 가상 네트워크 999대로 감소됩니다.The limit counter is decremented to 999 virtual networks remaining.

    이제 각 환경에 대 한 리소스가 동일한 구독에서 그룹화 되었음을 보여 주는 다이어그램

  3. 마지막으로, 구독 소유자 계정은 두 번째 워크 로드에 대 한 프로세스를 반복 하 여 참가자 역할에 app2 워크 로드 소유자 가 있는 리소스 그룹을 추가 합니다.Finally, the subscription owner account repeats the process for the second workload, adding the resource groups with app2 workload owner in the contributor role. 각 환경 구독에 대한 제한 카운터는 남은 가상 네트워크 998대로 감소됩니다.The limit counter for each of the environment subscriptions is decremented to 998 virtual networks remaining.

이 관리 모델에는 위의 두 번째 예제의 이점이 있습니다.This management model has the benefits of the second example above. 주요 차이점은 두 구독에 분산 되어 있기 때문에 한도는 문제가 되지 않는다는 점입니다.The key difference is that limits are less of an issue due to the fact that they're spread over two subscriptions. 단점은 태그에서 추적한 비용 데이터가 세 가지 구독 모두에서 집계되어야 한다는 것입니다.The drawback is that the cost data tracked by tags must be aggregated across all three subscriptions.

따라서 요구 사항 우선 순위에 따라 이러한 두 가지 예제 리소스 관리 모델 중에서 하나를 선택할 수 있습니다.Therefore, you can select any of these two examples resource management models depending on the priority of your requirements. 조직이 단일 구독에 대한 서비스 제한에 도달하지 않을 것으로 예상하는 경우 여러 리소스 그룹이 포함된 단일 구독을 사용할 수 있습니다.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. 반대로, 조직이 많은 워크로드를 예상하는 경우 각 환경에 대해 여러 구독이 더 좋을 수 있습니다.Conversely, if your organization anticipates many workloads, multiple subscriptions for each environment may be better.

리소스 관리 모델 구현Implement the resource management model

Azure 리소스에 대한 액세스를 관리하기 위해 여러 다른 모델에 대해 알아보았습니다.You've learned about several different models for governing access to Azure resources. 설계 가이드에서 공유 인프라, 프로덕션개발 환경 각각에 대해 구독 하나씩 사용하여 리소스 관리 모델을 구현하는 데 필요한 단계를 살펴볼 것입니다.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. 세 가지 환경 모두에 대해 하나의 구독 소유자 계정이 있습니다.You'll have one subscription owner account for all three environments. 각 워크로드는 기여자 역할과 함께 추가된 워크로드 소유자 를 통해 리소스 그룹 에서 격리됩니다.Each workload will be isolated in a resource group with a workload owner added with the contributor role.

참고

Azure 계정과 구독 간의 관계에 대 한 자세한 내용은 azure에서 리소스 액세스 이해를 참조 하세요.To learn more about the relationship between Azure accounts and subscriptions, see Understanding resource access in Azure.

다음 단계를 수행합니다.Follow these steps:

  1. 조직에 아직 Azure 계정이 없는 경우 새로 하나 만듭니다.Create an Azure account if your organization doesn't already have one. Azure 계정에 등록하는 사람이 Azure 계정 관리자가 되고 조직의 경영진은 이 역할을 맡을 개인을 선정해야 합니다.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. 이 개인은 다음을 담당하게 됩니다.This individual will be responsible for:
  2. 조직의 리더십 팀은 다음을 담당 하는 사람을 결정 합니다.Your organization's leadership team decides who is responsible for:
    • 사용자 id 관리 AZURE ad 테 넌 트는 조직의 azure 계정을 만들 때 기본적으로 만들어지며, 계정 관리자는 기본적으로 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. 조직에서는 해당 사용자에 게 AZURE AD 전역 관리자 역할을 할당하 여 사용자 id를 관리 하는 다른 사용자를 선택할 수 있습니다.Your organization can choose another user to manage user identity by assigning the Azure AD Global Administrator role to that user.
    • 구독. 이러한 사용자는 다음을 수행합니다.Subscriptions, which means these users:
      • 해당 구독의 리소스 사용량과 관련 된 비용을 관리 합니다.Manage costs associated with resource usage in that subscription.
      • 리소스 액세스에 대 한 최소 권한 모델을 구현 하 고 유지 관리 합니다.Implement and maintain least permission model for resource access.
      • 서비스 제한을 추적합니다.Keep track of service limits.
    • 공유 인프라 서비스(조직이 이 모델을 사용하기로 결정하는 경우). 이 사용자는 다음을 담당합니다.Shared infrastructure services (if your organization decides to use this model), which means this user is responsible for:
      • 온-프레미스에서 Azure로의 네트워크 연결.On-premises to Azure network connectivity.
      • 가상 네트워크 피어링을 통해 Azure 내에서 네트워크 연결의 소유권입니다.Ownership of network connectivity within Azure through virtual network peering.
    • 워크로드 소유자.Workload owners.
  3. Azure AD 전역 관리자는 다음에 대 한 새 사용자 계정을 만듭니다 .The Azure AD Global Administrator creates the new user accounts for:
    • 각 환경에 연결 된 각 구독에 대 한 구독 소유자가 될 사용자입니다.The person who will be the subscription owner for each subscription associated with each environment. 구독 서비스 관리자 가 각 구독/환경에 대한 리소스 액세스를 관리하는 작업을 담당하지 않을 경우에만 필요합니다.Note that this is necessary only if the subscription service administrator will not be tasked with managing resource access for each subscription/environment.
    • 네트워크 작업 사용자 가 될 사용자입니다.The person who will be the network operations user.
    • 작업 소유자 인 사용자입니다.The people who are workload owners.
  4. Azure 계정 관리자는 세 개의 azure 구독을 만듭니다.The Azure account administrator creates three Azure subscriptions:
    • 공유 인프라 환경에 대 한 구독입니다.A subscription for the shared infrastructure environment.
    • 프로덕션 환경에 대 한 구독입니다.A subscription for the production environment.
    • 개발 환경에 대한 구독입니다.A subscription for the development environment.
  5. Azure 계정 관리자는 각 구독에 구독 서비스 소유자를 추가합니다.The Azure account administrator adds the subscription service owner to each subscription.
  6. 리소스 그룹의 생성을 요청하려면 워크로드 소유자 에 대한 승인 프로세스를 만듭니다.Create an approval process for workload owners to request the creation of resource groups. 승인 프로세스는 전자 메일을 사용 하는 등의 여러 가지 방법으로 구현 하거나 SharePoint 워크플로와같은 프로세스 관리 도구를 사용할 수 있습니다.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. 승인 프로세스는 다음 단계를 따를 수 있습니다.The approval process can follow these steps:
    • 워크로드 소유자개발 환경이나 프로덕션 환경 또는 둘 다에서 필요한 Azure 리소스에 대한 제품 구성 정보를 준비하여 구독 소유자 에게 전송합니다.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.
    • 구독 소유자 는 자료의 청구서를 검토 하 고 요청 된 리소스의 유효성을 검사 하 여 요청 된 가상 머신 크기가 올바른지 확인 하는 등의 계획 된 사용에 적합 한지 확인 합니다.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.
    • 요청이 승인되지 않은 경우 워크로드 소유자 에게 알립니다.If the request is not approved, the workload owner is notified. 요청이 승인 되 면 구독 소유자 는 조직의 명명 규칙에 따라 요청 된 리소스 그룹을 만들고 , 작업 소유자 참가자 역할 에 추가 하 고, 리소스 그룹이 만들어진 작업 소유자 에 게 알림을 보냅니다.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. 워크로드 소유자가 공유 인프라 소유자에게서 가상 네트워크 피어링 연결을 요청하려면 승인 프로세스를 만듭니다.Create an approval process for workload owners to request a virtual network peering connection from the shared infrastructure owner. 이전 단계에서와 마찬가지로 이 승인 프로세스는 이메일 또는 프로세스 관리 도구를 사용하여 구현할 수 있습니다.As with the previous step, this approval process can be implemented using email or a process management tool.

거버넌스 모델을 구현했으므로 공유 인프라 서비스를 배포할 수 있습니다.Now that you've implemented your governance model, you can deploy your shared infrastructure services.

Azure 기본 제공 역할Azure built-in roles