Разработка системы управления для нескольких команд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.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. В этой системе управления удостоверениями должны храниться удостоверения следующих пользователей: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.
    • Два сотрудника организации, отвечающих за управление рабочей нагрузкой.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.

Управление удостоверениямиIdentity management

Прежде чем разрабатывать систему управления удостоверениями для модели системы управления, необходимо ознакомиться с четырьмя основными областями, которые она охватывает.Before you can design identity management for your governance model, it's important to understand the four major areas it encompasses:

  • Администрирование: Процессы и средства для создания, изменения и удаления удостоверений пользователей.Administration: The processes and tools for creating, editing, and deleting user identity.
  • Проверка подлинности: Проверка удостоверения пользователя путем проверки учетных данных, например имени пользователя и пароля.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.
  • Аудит: Периодически изучайте журналы и другие сведения для обнаружения проблем безопасности, связанных с удостоверением пользователя.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.

Существует только одна служба управления удостоверениями, являющаяся доверенной в Azure, — Azure Active Directory (Azure AD).There is only one service trusted by Azure for identity, and that is Azure Active Directory (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. Кроме того, был создан клиент Azure AD, если существующий клиент уже не связан с использованием других служб Майкрософт, таких как Microsoft 365.Also, an Azure AD tenant was created, unless an existing tenant was already associated with your organization's use of other Microsoft services such as Microsoft 365. Microsoft Azure Active Directory Глобальный администратор с полными правами при создании был связан с клиентом Microsoft Azure Active Directory.A global administrator with full permissions on the Azure AD tenant was associated when it was created.

Удостоверения пользователя как для владельца учетной записи Azure, так и для глобального администратора Azure AD хранятся в системе идентификации с высоким уровнем безопасности, управляемой корпорацией Майкрософт.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, но в этом руководство по проектированию вы можете сосредоточиться на создании и удалении удостоверений пользователей.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.

Примечание

Возможно, у вашей организации уже есть клиент Azure AD, если имеется существующая лицензия Microsoft 365, Intune или Dynamics 365, связанная с вашей учетной записью.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 и глобальным администратором Azure AD. Рис. 1. учетная запись Azure с владельцем учетной записи Azure и глобальным администратором Azure AD.Diagram showing an Azure account with an Azure account owner and Azure AD global admin. Figure 1: An Azure account with an Azure account owner and Azure AD global administrator.

Глобальный администратор Microsoft Azure Active Directory имеет разрешение на создание учетных записей пользователей.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 и пользователь с рабочими нагрузками в г., связаны с индивидуальными сотрудниками вашей организации, ответственными за управление рабочей нагрузкой.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

Теперь, когда система управления удостоверениями и учетные записи пользователей созданы, необходимо решить, как применять роли 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. В первом примере Владелец рабочей нагрузки а не имеет разрешений в области действия подписки и права на управление доступом к ресурсам по умолчанию.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. Владелец рабочей нагрузки запрашивает создание группы ресурсов AWorkload owner requests creation of resource group A
  2. Администратор службы просматривает свой запрос и создает группу ресурсов 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. Администратор службы создает группу ресурсов AService 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 в группу ресурсов AService administrator adds workload owner A to resource group A
  4. Предположим, что Владелец рабочей нагрузки A имеет требование для пары участников команды, чтобы просмотреть данные мониторинга ресурсов ЦП и сетевого трафика в рамках планирования ресурсов для рабочей нагрузки.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. Они должны отправить этот запрос администратору службы.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. Администратор службы добавляет участников рабочей нагрузки в группу ресурсов AService administrator adds workload contributors to resource group A
  6. Далее, владелец рабочей нагрузки Б также требует группу ресурсов для ресурсов своей рабочей нагрузки.Next, workload owner B also requires a resource group to contain the resources for their workload. Как и в случае с владельцем рабочей нагрузки A, владелец рабочей нагрузки Б изначально не имеет разрешения принимать какие-либо действия в области подписки, поэтому ему необходимо отправить запрос администратору служб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 запрашивает создание группы ресурсов BWorkload owner B requests creation of resource group B
  7. Администратор службы просматривает запрос и создает группу ресурсов B. Администратор службы создает группу ресурсов BThe 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 в группу ресурсов BService 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 в подписку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 Владелец рабочей нагрузки по умолчанию добавляется и наследует встроенную роль владельца из области действия подписки.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 создает группу ресурсов AWorkload owner A creates resource group A
  3. Встроенная роль владельца предоставляет владельцу рабочей нагрузки разрешение на управление доступом к группе ресурсов.The built-in Owner role grants workload owner A permission to manage access to the resource group. Владелец рабочей нагрузки а добавляет двух участников рабочей нагрузки и назначает каждому из них встроенную роль читателя.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. Владелец рабочей нагрузки Б создает группы ресурсов Б и добавляется по умолчанию.Workload owner B creates resource group B and is added by default. Опять же, Владелец рабочей нагрузки б наследует встроенную роль владельца из области действия подписки.Again, workload owner B inherits the built-in Owner role from the subscription scope. Владелец рабочей нагрузки B создает группу ресурсов BWorkload 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.

Так как владельцем рабочей нагрузки а и владельцем рабочей нагрузки 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 имеет права на добавление любого другого пользователя в группу ресурсов а и может назначать им любую роль, включая встроенную роль владельца.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. Существует ограничение в 1 000 виртуальных сетей на подписку. После развертывания первой виртуальной сети теперь доступно 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. Первый Владелец рабочей нагрузки применяет environment managedBy теги и ко всем ресурсам.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. Второй Владелец рабочей нагрузки применяет environment managedBy теги и к каждому ресурсу.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. Когда учетная запись владельца подписки добавила владельца рабочей нагрузки «опыт» с ролью « участник », этот пользователь имел права доступа управления ко всем ресурсам в 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.

Схема, демонстрирующая права на доступ к управлению

Это означает, что у владельца рабочей нагрузки от компании слышал есть разрешение на развертывание собственной подсети с виртуальными машинами в 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. Схема, показывающая добавление групп ресурсов r g и App 1 dev r для разработчиков приложений 1.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. Опять же, владелец рабочей нагрузки аpp1 отправляет запрос пользователю сетевых операций для создания пирингового соединения.Again, app1 workload owner sends a request to the network operations user to create a peering connection. Обратите внимание, что владелец рабочей нагрузки аpp1 добавляет те же теги, что и в первом примере, а счетчик границ был уменьшен до 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. Схема, на которой показано развертывание виртуальных сетей App 1, а также виртуальные сети 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. Учетная запись владельца подписки теперь создает две группы ресурсов для владельца рабочей нагрузки в.The subscription owner account now creates two resource groups for app2 workload owner. Следуя тем же соглашениям, что и для владельца рабочей нагрузки APP1, группы ресурсов имеют имена app2-prod-rg и app2-dev-rg .Following the same conventions as for app1 workload owner, the resource groups are named app2-prod-rg and app2-dev-rg. Учетная запись владельца подписки добавляет владельца рабочей нагрузки в каждую группу ресурсов с ролью участника .The subscription owner account adds app2 workload owner to each of the resource groups with the contributor role. Схема, на которой показано добавление групп ресурсов r g и App 2 для разработчиков в версии 2.A diagram showing the addition of the app 2 prod r g and app 2 dev r g resource groups.
  4. Учетная запись владельца рабочей нагрузки от а затем развертывает виртуальные сети и виртуальные машины в группах ресурсов с одинаковыми соглашениями об именовании.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. Развертывание виртуальных сетей и виртуальных машинDeploying virtual networks and VMs
  5. Учетная запись владельца рабочей нагрузки от а затем отправляет запрос пользователю сетевых операций на пиринг 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. Схема, показывающая пиринг в App 2 произв. NET с концентратором 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. Как и в предыдущих примерах, владелец рабочей нагрузки аpp1 создает ресурсы и запрашивает пиринговое подключение с виртуальной сетью общей инфраструктуры.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. Наконец, учетная запись владельца подписки повторяет процесс для второй рабочей нагрузки, добавляя группы ресурсов с владельцем рабочей нагрузки в роли участника .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, становится ее администратором, поэтому руководство организации должно выбрать человека, который возьмет на себя эту роль.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:
    • Создание подписок.Creating subscriptions.
    • Создание и администрирование клиентов Azure Active Directory (Azure AD) , в которых хранятся удостоверения пользователей для этих подписок.Creating and administering Azure Active Directory (Azure AD) tenants that store user identity for those subscriptions.
  2. Группа лидерства в Организации решает, кто отвечает за:Your organization's leadership team decides who is responsible for:
    • Управление удостоверениями пользователей; клиент 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.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.

Встроенные роли AzureAzure built-in roles