複数チーム向けのガバナンス設計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. この例では、要件は次の 4 つの環境に対応しています。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 Dev/Test サブスクリプションの形式になります。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:
    • サービス アカウントのように扱われ、リソースのアクセス権を割り当てるためのアクセス許可が付与されている、サブスクリプション スコープの 1 人の信頼されたユーザー。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. リソース アクセス権が、リソース グループ スコープの 1 人の信頼されたユーザーによって明示的に付与されている。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).
    • この企業は 3 つの主要環境それぞれで個別にロールを管理しなければならない状況を望んでいないため、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's role-based access control (RBAC). エンタープライズにカスタム RBAC ロールが必要な場合は、3 つの環境間でカスタム ロールを同期するために追加のプロセスが必要になります。If the enterprise absolutely requires custom RBAC 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 管理を設計する前に、次の 4 つの主な領域について理解しておくことが重要です。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: 認証されたユーザーにどのリソースへのアクセスを許可するか、またはどのような操作を実行するためのアクセス許可を与えるかを決定すること。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 Active Directory (Azure AD) の 1 つだけです。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 アカウントにサインアップしたときに、少なくとも 1 つの 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 アカウント。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 アカウント所有者と Azure AD グローバル管理者が含まれる Azure アカウント 図 2:Azure AD グローバル管理者は必要なユーザー アカウントをテナント内に作成する。Azure account with an Azure account owner and Azure AD global admin Figure 2: The Azure AD global administrator creates the required user accounts in the tenant.

最初の 2 つのアカウント 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 管理システムとユーザー アカウントが作成されたので、次は、最小限の特権のアクセス許可モデルをサポートするために、ロールベースのアクセス制御 (RBAC) ロールを各アカウントに適用する方法を決める必要があります。Now that your identity management system and user accounts have been created, you have to decide how to apply role-based access control (RBAC) roles to each account to support a permissions model of least privilege.

また、ワークロード所有者が自身の所有していない他のワークロードに管理アクセスできないように、各ワークロードに関連付けられているリソースがそれぞれ互いに分離されていなければならないというもう 1 つの要件があります。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.

それぞれの RBAC ロールが、サブスクリプションリソース グループ、個別のリソースの 3 つのスコープのいずれかで適用されます。Each RBAC 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.

そのため、最小特権アクセスのモデルを作成するには、特定の種類のユーザーがこれらの 3 つの各スコープで実行を許可されるアクションを決定する必要があります。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.

この概念がもう少しわかるように、2 つのアクセス許可モデルの例を見てみましょう。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. 2 番目の例のモデルでは、組み込み所有者ロールを、サブスクリプション スコープの各ワークロード所有者に割り当てます。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 は、ワークロードの容量計画の一環として、2 人のチーム メンバーが 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. サービス管理者は要求を確認し、2 人のワークロードの共同作成者ユーザーをリソース グループ A に追加します。この 2 人のユーザーには、リソース管理のためのアクセス許可は必要ありません。したがって、組み込み閲覧者ロールが割り当てられます。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 にも、サブスクリプション スコープでアクションを実行するためのアクセス許可が最初は付与されていません。そこで、ワークロード所有者 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: それぞれのリソース グループで孤立している 2 人のワークロード所有者が含まれるサブスクリプション。gfigure 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. この例ではワークロード所有者が 2 人しかいなかったため、シンプルで、問題がないように見えますが、大規模な組織では問題が発生するのは想像に難くありません。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.

次の 2 番目の例では、サービス管理者によって実行されるタスク数が減っています。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. 組み込み所有者ロールにより、ワークロード所有者 A に、リソース グループへのアクセスを管理するアクセス許可が付与されます。The built-in owner role grants workload owner A permission to manage access to the resource group. ワークロード所有者 A が 2 人のワークロード共同作成者を追加し、それぞれに組み込み閲覧者ロールを割り当てます。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 を、組み込み所有者ロールが含まれるサブスクリプションに追加します。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 を作成します。ワークロード所有者 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:組み込み所有者ロールが割り当てられた、サービス管理者と 2 人のワークロード所有者が含まれるサブスクリプション。Subscription with resource groups A and B Figure 5: A subscription with a service administrator and two workload owners, all assigned the built-in owner role.

ワークロード所有者 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.

それぞれの例を要件と比較すると、この 2 つの例では、2 人のワークロード所有者にリソース アクセス権を付与するアクセス許可を持つ 1 人の信頼されたユーザーがサブスクリプション スコープでサポートされていることがわかります。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. 2 人のワークロード所有者は、既定では、リソース管理にアクセスできなかったため、サービス管理者に、アクセス許可を明示的に割り当ててもらう必要がありました。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. 次の 3 つの環境をサポートする必要がある、という要件を思い出してください。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.

この 3 つの環境ごとに、ワークロード所有者環境、またはその両方について、コスト データを追跡する必要があります。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.

リソースのスコープには、サブスクリプションリソース グループの 2 つのレベルがあることは既に説明しました。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. 可能性は 2 つしかありません。1 つのサブスクリプション、そして複数のサブスクリプションです。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.

まず、1 つのサブスクリプションを使用したリソース管理モデルの例を見てみましょう。First let's look at an example resource management model using a single subscription. 最初に、リソース グループを 3 つの環境と連携させる方法を決めます。The first decision is how to align resource groups to the three environments. 2 つのオプションがあります。You have two options:

  1. 各環境を 1 つのリソース グループと連携させる。Align each environment to a single resource group. 共有インフラストラクチャ リソースはすべて、1 つの共有インフラストラクチャ リソース グループにデプロイされます。All shared infrastructure resources are deployed to a single shared infrastructure resource group. 開発ワークロードに関連付けられているリソースはすべて、1 つの開発リソース グループにデプロイされます。All resources associated with development workloads are deployed to a single development resource group. 運用ワークロードに関連付けられているリソースについては、運用環境の 1 つの運用リソース グループにすべてデプロイされます。All resources associated with production workloads are deployed into a single production resource group for the production environment.
  2. ワークロードごとに個別のリソース グループを作成し、名前付け規則とタグを使用して、そのリソース グループを 3 つの環境それぞれと連携させる。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. ここでは、前のセクションで説明したアクセス許可モデルと、1 人のサブスクリプション サービス管理者を使用します。この管理者は、リソース グループを作成し、そのグループに、ユーザーを、組み込み共同作成者ロールまたは閲覧者ロールと共に追加します。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:sharedmanagedBy: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 です。1 つ目の仮想ネットワークがデプロイされたため、現在 999 の仮想ネットワークが使用可能です。There is a limit of 1000 virtual networks per subscription, and after the first virtual network is deployed there are now 999 available. VPN ゲートウェイの作成Creating a VPN gateway
  4. さらに 2 つのリソース グループがデプロイされます。Two more resource groups are deployed. 1 つ目の名前は prod-rg です。The first is named prod-rg. このリソース グループは運用環境と連携します。This resource group is aligned with the production environment. 2 つ目の名前は 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. この例では、この 2 つの環境それぞれにデプロイするワークロードは 2 つだけなので、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. 共同作成者の追加Adding contributors
  6. 最初のワークロード所有者は、2 つのリソース グループそれぞれに仮想ネットワークを作成します。各仮想ネットワークには 2 つの仮想マシンがあります。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. 仮想ネットワークのピアリングにより、2 つの個別の仮想ネットワーク間に接続が作成され、その間をネットワーク トラフィックが行き来できるようになります。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. ピアリングは、接続されている 2 つの各仮想ネットワークで指定する必要があります。いずれか 1 つの仮想ネットワークでしかピアリングが指定されていない場合、接続は不完全です。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-vnethub-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. ピアリング接続の作成Creating 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. これでピアリングの接続は完了です。2 つの仮想ネットワーク間を、ネットワーク トラフィックが行き来するようになります。The peering connection is now complete, and network traffic flows between the two virtual networks. ピアリング接続の作成Creating a peering connection
  9. ここで、もう 1 人のワークロード所有者が要求をサブスクリプション サービス管理者に送信します。その所有者は、共同作成者ロールと共に、既存の運用環境と開発環境それぞれのリソース グループに追加されます。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. その 2 番目のワークロード所有者には、各リソース グループで、最初のワークロード所有者と同じアクセス許可がすべてのリソースについて付与されます。The second workload owner has the same permissions on all resources as the first workload owner in each resource group. 共同作成者の追加Adding contributors
  10. 2 番目のワークロード所有者は、prod-vnet 仮想ネットワークにサブネットを作成し、2 つの仮想マシンを追加します。The second workload owner creates a subnet in the prod-vnet virtual network, then adds two virtual machines. 2 番目のワークロード所有者は、environment タグと managedBy タグを各リソースに適用します。The second workload owner applies the environment and managedBy tags to each resource. サブネットの作成Creating subnets

このリソース管理モデルの例では、3 つの必要な環境でリソースを管理できます。This example resource management model enables us to manage resources in the three required environments. 共有インフラストラクチャ リソースへのアクセス許可を持つユーザーはサブスクリプション内に 1 人しかいないため、これらのリソースは保護されています。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.

また、一見するとわかりにくいかもしれませんが、このモデルには重要な考慮事項がもう 1 つあります。There's another important consideration with this model that may not be immediately obvious. この例では、オンプレミス ネットワークへの接続を提供するために hub-vnet とのネットワーク ピアリング接続を要求したのは、app1 ワークロード所有者でした。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.

次に、さまざまな環境やワークロードに対するリソース グループが複数含まれる 1 つのサブスクリプションを見てみましょう。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. ワークロードごとに 2 つのリソース グループが必要です。1 つは開発環境、もう 1 つは運用環境に対して使用されます。Each workload requires two resource groups, one for each of the development and production environments. 最初のワークロードに対して、サブスクリプション所有者アカウントで 2 つのリソース グループを作成します。For the first workload, the subscription owner account creates two resource groups. 1 つ目の名前は app1-prod-rg、2 つ目の名前は 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. 共同作成者の追加Adding contributors
  2. 最初の例と同様、app1 ワークロード所有者が、app1-prod-vnet という名前の仮想ネットワークを運用環境に、もう 1 つの 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. ピアリング接続の作成Creating a peering connection
  3. 次に、サブスクリプション所有者アカウントで、app2 ワークロード所有者に対して 2 つのリソース グループを作成します。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. 共同作成者の追加Adding contributors
  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-vnethub-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. ピアリング接続の作成Creating a peering connection

結果の管理モデルは最初の例と似ていますが、主に次のような違いがあります。The resulting management model is similar to the first example, with several key differences:

  • 2 つのワークロードはそれぞれ、ワークロードおよび環境によって分離されています。Each of the two workloads is isolated by workload and by environment.
  • このモデルには、最初の例のモデルよりも仮想ネットワークが 2 つ多く必要です。This model required two more virtual networks than the first example model. ワークロードが 2 つだけなので、この違いは重要ではありませんが、このモデルのワークロード数の制限は理論的には 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.
  • それぞれの環境に対応する 1 つのリソース グループに、リソースがグループ化されなくなりました。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. このモデルでは、3 つの各環境を、共有サービス サブスクリプション、運用サブスクリプション、開発サブスクリプションの 3 つの個別のサブスクリプションと連携させます。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. このモデルに関する考慮事項は、リソース グループとワークロードを連携させる方法を決める必要がある点では、1 つのサブスクリプションを使用するモデルと似ています。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. このモデルには、共有インフラストラクチャ運用、および開発 の 3 つのサブスクリプションがあります。In this model, there are three subscriptions: shared infrastructure, production, and development. この 3 つのサブスクリプションそれぞれに、"サブスクリプション所有者" が必要で、このシンプルな例では、3 つすべてに同じユーザー アカウントを使用します。Each of these three subscriptions requires a subscription owner, and in the simple example you'll use the same user account for all three. 共有インフラストラクチャリソースは、上記の最初の 2 つの例と同じように管理されており、最初のワークロードは、運用環境の 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. 最後に、サブスクリプション所有者アカウントで 2 つ目のワークロードに対して処理を繰り返し、共同作成者ロールで 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.

この管理モデルには、上記の 2 番目の例で示した利点があります。This management model has the benefits of the second example above. 主な違いは、制限が 2 つのサブスクリプションに分散されるため、あまり問題にはならないという点です。The key difference is that limits are less of an issue due to the fact that they're spread over two subscriptions. 欠点は、タグによって追跡されるコスト データを、3 つのすべての "サブスクリプション" にわたって集計する必要があることです。The drawback is that the cost data tracked by tags must be aggregated across all three subscriptions.

したがって、ご自身の要件の優先度に応じて、2 つのサンプル リソース管理モデルのいずれかを選択できます。Therefore, you can select any of these two examples resource management models depending on the priority of your requirements. 皆様の組織で 1 つのサブスクリプションのサービス制限に到達しないと思われる場合は、複数のリソース グループを含む 1 つのサブスクリプションを使用できます。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. ここでは、設計ガイドの共有インフラストラクチャ環境、運用環境、開発環境それぞれに、1 つのサブスクリプションが含まれるリソース管理モデルを実装する手順を説明します。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. この 3 つの環境すべてで 1 つのサブスクリプション所有者アカウントを持っています。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:
    • サブスクリプションの作成。Creating subscriptions.
    • これらのサブスクリプションのユーザー ID を格納する 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:
    • ユーザー ID の管理。ご自身の組織の Azure アカウントの作成時に Azure AD テナントが既定で作成されます。アカウント管理者は、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. ご自身の組織がユーザー ID 管理の担当者として別のユーザーを選択するには、そのユーザーに 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 アカウント管理者は、次の 3 つの 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 リソースの組み込みロールBuilt-in roles for Azure resources