Azure リソースのロールベースのアクセス制御 (RBAC) の概要What is role-based access control (RBAC) for Azure resources?

クラウド リソースに対するアクセスの管理は、クラウドが使用している組織にとって重要な機能です。Access management for cloud resources is a critical function for any organization that is using the cloud. ロールベースのアクセス制御 (RBAC) は、Azure のリソースにアクセスできるユーザー、そのユーザーがそれらのリソースに対して実行できること、そのユーザーがアクセスできる領域を管理するのに役立ちます。Role-based access control (RBAC) helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.

Azure RBAC は Azure Resource Manager 上に構築された承認システムであり、Azure リソースに対するアクセスをきめ細かく管理できます。RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources.

RBAC でできることWhat can I do with RBAC?

RBAC でできることの例を次に示します。Here are some examples of what you can do with RBAC:

  • あるユーザーにサブスクリプション内の仮想マシンの管理を許可し、別のユーザーに仮想ネットワークの管理を許可しますAllow one user to manage virtual machines in a subscription and another user to manage virtual networks
  • DBA グループにサブスクリプション内の SQL データベースの管理を許可しますAllow a DBA group to manage SQL databases in a subscription
  • あるユーザーに、仮想マシン、Web サイト、サブネットなど、リソース グループ内のすべてのリソースの管理を許可しますAllow a user to manage all resources in a resource group, such as virtual machines, websites, and subnets
  • あるアプリケーションに、リソース グループ内のすべてのリソースへのアクセスを許可しますAllow an application to access all resources in a resource group

RBAC を使用するためのベスト プラクティスBest practice for using RBAC

RBAC を使用して、チーム内で職務を分離し、職務に必要なアクセス許可のみをユーザーに付与します。Using RBAC, you can segregate duties within your team and grant only the amount of access to users that they need to perform their jobs. すべてのユーザーに Azure サブスクリプションまたはリソースで無制限のアクセス許可を付与するのではなく、特定のスコープで特定の操作のみを許可することができます。Instead of giving everybody unrestricted permissions in your Azure subscription or resources, you can allow only certain actions at a particular scope.

アクセス制御戦略を計画する場合のベスト プラクティスは、ユーザーの作業を実行できる最低限の特権をユーザーに付与することです。When planning your access control strategy, it's a best practice to grant users the least privilege to get their work done. 次の図は、RBAC を使用するための推奨パターンを示しています。The following diagram shows a suggested pattern for using RBAC.

RBAC と最小限の特権

RBAC のしくみHow RBAC works

RBAC を使用してリソースへのアクセスを制御するには、ロールの割り当てを作成します。The way you control access to resources using RBAC is to create role assignments. これは、アクセス許可が適用される方法であり、理解する必要のある重要な概念です。This is a key concept to understand – it’s how permissions are enforced. ロールの割り当ては、セキュリティ プリンシパル、ロールの定義、スコープの 3 つの要素で構成されています。A role assignment consists of three elements: security principal, role definition, and scope.

セキュリティ プリンシパルSecurity principal

"セキュリティ プリンシパル" は、Azure リソースへのアクセスを要求するユーザー、グループ、サービス プリンシパル、またはマネージド ID を表すオブジェクトです。A security principal is an object that represents a user, group, service principal, or managed identity that is requesting access to Azure resources.

ロール割り当てのセキュリティ プリンシパル

  • ユーザー - Azure Active Directory 内にプロファイルを持つ個人です。User - An individual who has a profile in Azure Active Directory. 他のテナント内のユーザーにロールを割り当てることもできます。You can also assign roles to users in other tenants. 他の組織のユーザーについては、「Azure Active Directory B2B」をご覧ください。For information about users in other organizations, see Azure Active Directory B2B.
  • グループ - Azure Active Directory 内に作成されたユーザーのセットです。Group - A set of users created in Azure Active Directory. グループにロールを割り当てると、そのグループ内のすべてのユーザーがそのロールを持つようになります。When you assign a role to a group, all users within that group have that role.
  • サービス プリンシパル - 特定の Azure リソースにアクセスするためにアプリケーションまたはサービスによって使用されるセキュリティ ID です。Service principal - A security identity used by applications or services to access specific Azure resources. アプリケーションに対する "ユーザー ID" (ユーザー名とパスワード、または証明書) と考えることができます。You can think of it as a user identity (username and password or certificate) for an application.
  • マネージド ID - Azure によって自動的に管理される Azure Active Directory 内の ID。Managed identity - An identity in Azure Active Directory that is automatically managed by Azure. 通常、マネージド ID は、Azure サービスに対する認証を受けるための資格情報を管理するクラウド アプリケーションを開発するときに使用します。You typically use managed identities when developing cloud applications to manage the credentials for authenticating to Azure services.

ロール定義Role definition

ロール定義はアクセス許可のコレクションです。A role definition is a collection of permissions. 単にロールと呼ばれることもあります。It's sometimes just called a role. ロール定義には、実行できる操作 (読み取り、書き込み、削除など) が登録されています。A role definition lists the operations that can be performed, such as read, write, and delete. ロールは、所有者のように高レベルにすることも、仮想マシン リーダーのように限定することもできます。Roles can be high-level, like owner, or specific, like virtual machine reader.

ロール割り当てのためのロールの定義

Azure には複数の組み込みロールがあり、使用することができます。Azure includes several built-in roles that you can use. 4 つの基本的な組み込みロールを次に示します。The following lists four fundamental built-in roles. 最初の 3 つは、すべてのリソースの種類に適用されます。The first three apply to all resource types.

  • 所有者 - 他のユーザーへアクセス権を委任する権限を含め、すべてのリソースへのフル アクセス権を持ちます。Owner - Has full access to all resources including the right to delegate access to others.
  • 共同作成者 - Azure リソースのすべての種類を作成および管理できますが、他のユーザーへアクセス権を付与することはできません。Contributor - Can create and manage all types of Azure resources but can’t grant access to others.
  • 閲覧者 - 既存の Azure リソースを表示できます。Reader - Can view existing Azure resources.
  • ユーザー アクセス管理者 - Azure リソースへのユーザー アクセスを管理できます。User Access Administrator - Lets you manage user access to Azure resources.

残りの組み込みロールは、特定の Azure リソースの管理を許可します。The rest of the built-in roles allow management of specific Azure resources. たとえば、仮想マシン共同作成者ロールが割り当てられたユーザーには、仮想マシンの作成と管理が許可されます。For example, the Virtual Machine Contributor role allows a user to create and manage virtual machines. 組み込みロールが組織の特定のニーズを満たさない場合は、独自に Azure リソースに対するカスタム ロールを作成することができます。If the built-in roles don't meet the specific needs of your organization, you can create your own custom roles for Azure resources.

Azure には、オブジェクト内のデータへのアクセスを許可できるようにするデータ操作が用意されています。Azure has data operations that enable you to grant access to data within an object. たとえば、ユーザーがあるストレージ アカウントへのデータの読み取りアクセス許可を持っている場合、そのユーザーはそのストレージ アカウント内の BLOB またはメッセージを読み取ることができます。For example, if a user has read data access to a storage account, then they can read the blobs or messages within that storage account. 詳しくは、Azure リソースのロール定義に関する記事をご覧ください。For more information, see Understand role definitions for Azure resources.

Scope (スコープ)Scope

"スコープ" は、アクセスが適用されるリソースのセットです。Scope is the set of resources that the access applies to. ロールを割り当てるときに、スコープを定義することによって、許可される操作をさらに制限できます。When you assign a role, you can further limit the actions allowed by defining a scope. これは、1 つのリソース グループについてのみ、あるユーザーを Web サイトの共同作業者として指定する場合に便利です。This is helpful if you want to make someone a Website Contributor, but only for one resource group.

Azure では、複数のレベル (管理グループ、サブスクリプション、リソース グループ、リソース) でスコープを指定できます。In Azure, you can specify a scope at multiple levels: management group, subscription, resource group, or resource. スコープは親子関係で構造化されています。Scopes are structured in a parent-child relationship.

ロール割り当てのスコープ

親スコープでアクセス権を付与すると、それらのアクセス許可が子スコープに継承されます。When you grant access at a parent scope, those permissions are inherited to the child scopes. 例:For example:

  • 管理グループ スコープでユーザーに所有者ロールを割り当てた場合、そのユーザーは、その管理グループに存在する全サブスクリプションの内容をすべて管理することができます。If you assign the Owner role to a user at the management group scope, that user can manage everything in all subscriptions in the management group.
  • 閲覧者ロールをサブスクリプション スコープでグループに割り当てた場合、そのグループのメンバーは、サブスクリプション内のすべてのリソース グループとリソースを見ることができます。If you assign the Reader role to a group at the subscription scope, the members of that group can view every resource group and resource in the subscription.
  • 共同作成者ロールをリソース グループ スコープでアプリケーションに割り当てた場合、そのアプリケーションは、そのリソース グループ内のすべての種類のリソースを管理できますが、サブスクリプション内の他のリソース グループは管理できません。If you assign the Contributor role to an application at the resource group scope, it can manage resources of all types in that resource group, but not other resource groups in the subscription.

ロールの割り当てRole assignments

"ロールの割り当て" は、アクセスの許可を目的として、特定のスコープで、ユーザー、グループ、サービス プリンシパル、またはマネージド ID にロールの定義をアタッチするプロセスです。A role assignment is the process of attaching a role definition to a user, group, service principal, or managed identity at a particular scope for the purpose of granting access. アクセスは、ロールの割り当てを作成することによって許可され、ロールの割り当てを削除することによって取り消されます。Access is granted by creating a role assignment, and access is revoked by removing a role assignment.

次の図では、ロールの割り当ての例を示します。The following diagram shows an example of a role assignment. この例では、Marketing グループには、pharma-sales リソース グループに対する共同作成者ロールが割り当てられています。In this example, the Marketing group has been assigned the Contributor role for the pharma-sales resource group. つまり、Marketing グループのユーザーは、pharma-sales リソース グループ内の任意の Azure リソースを作成または管理できます。This means that users in the Marketing group can create or manage any Azure resource in the pharma-sales resource group. Marketing ユーザーは、別のロール割り当ての一部になっていない限り、pharma-sales リソース グループに含まれないリソースにはアクセスできません。Marketing users do not have access to resources outside the pharma-sales resource group, unless they are part of another role assignment.

アクセスを制御するためのロールの割り当て

ロールの割り当ては、Azure portal、Azure CLI、Azure PowerShell、Azure SDK、または REST API を使用して作成できます。You can create role assignments using the Azure portal, Azure CLI, Azure PowerShell, Azure SDKs, or REST APIs. 各サブスクリプションには、最大 2,000 個のロールの割り当てを保持できます。You can have up to 2000 role assignments in each subscription. ロールの割り当てを作成および削除するには、Microsoft.Authorization/roleAssignments/* アクセス許可が必要です。To create and remove role assignments, you must have Microsoft.Authorization/roleAssignments/* permission. このアクセス許可は、所有者ロールまたはユーザー アクセス管理者ロールを通じて許可されます。This permission is granted through the Owner or User Access Administrator roles.

複数のロールの割り当てMultiple role assignments

複数のロールの割り当てが重複しているとどうなるでしょうか。So what happens if you have multiple overlapping role assignments? RBAC は加算方式のモデルであるため、ロール割り当てを足し算した結果が有効なアクセス許可になります。RBAC is an additive model, so your effective permissions are the addition of your role assignments. ここで、ユーザーにサブスクリプション スコープの共同作成者ロールとリソース グループの閲覧者ロールが付与されている例を考えてみましょう。Consider the following example where a user is granted the Contributor role at the subscription scope and the Reader role on a resource group. 共同作成者アクセス許可と閲覧者アクセス許可を足すと、事実上、リソース グループに対する共同作成者ロールになります。The addition of the Contributor permissions and the Reader permissions is effectively the Contributor role for the resource group. そのため、この場合、閲覧者ロールの割り当ては効果がありません。Therefore, in this case, the Reader role assignment has no impact.

複数のロールの割り当て

拒否割り当てDeny assignments

これまでの RBAC は拒否のない許可のみのモデルでしたが、限定的にですが RBAC で拒否の割り当てがサポートされるようになりました。Previously, RBAC was an allow-only model with no deny, but now RBAC supports deny assignments in a limited way. ロールの割り当てと同様に、"拒否割り当て" ではアクセスの拒否を目的として、特定のスコープでユーザー、グループ、サービス プリンシパル、またはマネージド ID に一連の拒否アクションがアタッチされます。Similar to a role assignment, a deny assignment attaches a set of deny actions to a user, group, service principal, or managed identity at a particular scope for the purpose of denying access. ロールの割り当てでは "許可される" アクションのセットを定義しますが、拒否割り当てでは "許可されない" アクションのセットを定義します。A role assignment defines a set of actions that are allowed, while a deny assignment defines a set of actions that are not allowed. つまり、拒否割り当てでは、ロールの割り当てでアクセスを許可されている場合であっても、指定したアクションがユーザーによって実行されるのをブロックします。In other words, deny assignments block users from performing specified actions even if a role assignment grants them access. ロールの割り当てより拒否割り当ての方が優先されます。Deny assignments take precedence over role assignments. 詳しくは、「Azure リソースの拒否割り当ての概要」をご覧ください。For more information, see Understand deny assignments for Azure resources.

ユーザーがリソースへのアクセス権を持っているどうかを RBAC が特定する方法How RBAC determines if a user has access to a resource

管理プレーン上のリソースへのアクセス権をユーザーが持っているかどうかを判断するために RBAC が使用する手順の概要を次に示します。The following are the high-level steps that RBAC uses to determine if you have access to a resource on the management plane. これは、アクセスの問題のトラブルシューティングを行う場合に理解していると役に立ちます。This is helpful to understand if you are trying to troubleshoot an access issue.

  1. ユーザー (またはサービス プリンシパル) は、Azure Resource Manager に対するトークンを取得します。A user (or service principal) acquires a token for Azure Resource Manager.

    トークンには、ユーザーのグループ メンバーシップが含まれています (推移的なグループ メンバーシップを含みます)。The token includes the user's group memberships (including transitive group memberships).

  2. ユーザーは、トークンを添付して Azure Resource Manager への REST API の呼び出しを行います。The user makes a REST API call to Azure Resource Manager with the token attached.

  3. Azure Resource Manager では、アクション実行対象リソースに適用されるすべてのロール割り当てと拒否割り当てが取得されます。Azure Resource Manager retrieves all the role assignments and deny assignments that apply to the resource upon which the action is being taken.

  4. Azure Resource Manager は、このユーザーまたはユーザーのグループに適用されるロールの割り当てを絞り込み、このリソースに対してユーザーが持っているロールを特定します。Azure Resource Manager narrows the role assignments that apply to this user or their group and determines what roles the user has for this resource.

  5. Azure Resource Manager は、API 呼び出しでのアクションが、このリソースに対してユーザーが持っているロールに含まれるかどうかを判別します。Azure Resource Manager determines if the action in the API call is included in the roles the user has for this resource.

  6. 要求されたスコープでのアクションを含むロールをユーザーが持っていない場合、アクセスは許可されません。If the user doesn’t have a role with the action at the requested scope, access is not granted. それ以外の場合、Azure Resource Manager は拒否割り当てが適用されるかどうかを確認します。Otherwise, Azure Resource Manager checks if a deny assignment applies.

  7. 拒否割り当てが適用される場合、アクセスはブロックされます。If a deny assignment applies, access is blocked. それ以外の場合、アクセスは許可されます。Otherwise access is granted.

ライセンスの要件License requirements

この機能の使用は無料で、Azure サブスクリプションに含まれています。Using this feature is free and included in your Azure subscription.

次の手順Next steps