次の方法で共有

Azure ロールベースのアクセス制御 (Azure RBAC) とは

  • [アーティクル]

クラウド リソースに対するアクセスの管理は、クラウドが使用している組織にとって重要な機能です。 Azure ロールベースのアクセス制御 (Azure RBAC) は、Azure のリソースにアクセスできるユーザー、そのユーザーがそれらのリソースに対して実行できること、そのユーザーがアクセスできる領域を管理するのに役立ちます。

Azure RBAC は Azure Resource Manager 上に構築された承認システムであり、Azure リソースに対するアクセスをきめ細かく管理できます。

このビデオでは、Azure RBAC の概要を簡単に説明します。

Azure RBAC でできること

Azure RBAC でできることの例を次に示します。

  • あるユーザーにサブスクリプション内の仮想マシンの管理を許可し、別のユーザーに仮想ネットワークの管理を許可します
  • DBA グループにサブスクリプション内の SQL データベースの管理を許可します
  • あるユーザーに、仮想マシン、Web サイト、サブネットなど、リソース グループ内のすべてのリソースの管理を許可します
  • あるアプリケーションに、リソース グループ内のすべてのリソースへのアクセスを許可します

Azure RBAC のしくみ

Azure RBAC を使用してリソースへのアクセスを制御するには、Azure のロールを割り当てます。 これは理解する必要のある重要な概念です。これではアクセス許可を適用できます。 ロールの割り当ては、セキュリティ プリンシパル、ロールの定義、スコープの 3 つの要素で構成されています。

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

"セキュリティ プリンシパル" は、Azure リソースへのアクセスを要求するユーザー、グループ、サービス プリンシパル、またはマネージド ID を表すオブジェクトです。 これらのセキュリティ プリンシパルのいずれかに、ロールを割り当てることができます。

Diagram showing the security principal types for a role assignment.

ロール定義

ロール定義はアクセス許可のコレクションです。 通常は単に "ロール" と呼ばれます。 ロール定義には、実行できるアクション (読み取り、書き込み、削除など) が登録されています。 ロールは、所有者のように高レベルにすることも、仮想マシン リーダーのように限定することもできます。

Diagram showing role definition example for a role assignment

Azure には複数の組み込みロールがあり、使用することができます。 たとえば、仮想マシン共同作成者ロールが割り当てられたユーザーには、仮想マシンの作成と管理が許可されます。 組み込みロールが組織の特定のニーズを満たさない場合は、独自の Azure カスタム ロールを作成することができます。

このビデオでは、組み込みロールとカスタム ロールの概要を簡単に説明します。

Azure には、オブジェクト内のデータへのアクセスを許可できるようにするデータ アクションが用意されています。 たとえば、ユーザーがあるストレージ アカウントへのデータの読み取りアクセス許可を持っている場合、そのユーザーはそのストレージ アカウント内の BLOB またはメッセージを読み取ることができます。

詳細については、Azure ロールの定義の概要に関するページを参照してください。

Scope

"スコープ" は、アクセスが適用されるリソースのセットです。 ロールを割り当てるときに、スコープを定義することによって、許可される操作をさらに制限できます。 これは、1 つのリソース グループについてのみ、あるユーザーを Web サイトの共同作業者として指定する場合に便利です。

Azure では、4 つのレベル (管理グループ、サブスクリプション、リソース グループ、リソース) でスコープを指定できます。 スコープは親子関係で構造化されています。 これらのスコープレベルのいずれかで、ロールを割り当てることができます。

Diagram showing scope levels for a role assignment.

スコープの詳細については、スコープについての理解に関する記事を参照してください。

ロールの割り当て

"ロールの割り当て" は、アクセスの許可を目的として、特定のスコープで、ユーザー、グループ、サービス プリンシパル、またはマネージド ID にロールの定義をアタッチするプロセスです。 アクセスは、ロールの割り当てを作成することによって許可され、ロールの割り当てを削除することによって取り消されます。

次の図では、ロールの割り当ての例を示します。 この例では、Marketing グループには、pharma-sales リソース グループに対する共同作成者ロールが割り当てられています。 つまり、Marketing グループのユーザーは、pharma-sales リソース グループ内の任意の Azure リソースを作成または管理できます。 Marketing ユーザーは、別のロール割り当ての一部になっていない限り、pharma-sales リソース グループに含まれないリソースにはアクセスできません。

Diagram showing how security principal, role definition, and scope create a role assignment.

ロールは Azure portal、Azure CLI、Azure PowerShell、Azure SDK、REST API のいずれかを使用して割り当てることができます。

詳細については、Azure ロールを割り当てる手順を参照してください。

グループ

ロールの割り当ては、グループに対して推移的です。つまり、ユーザーがあるグループのメンバーであり、そのグループがロール割り当てのある別のグループのメンバーである場合、そのユーザーにそのロールの割り当てのアクセス許可が与えられます。

Diagram showing how role assignments are transitive for groups.

複数のロールの割り当て

複数のロールの割り当てが重複しているとどうなるでしょうか。 Azure RBAC は加算方式のモデルであるため、自分で行ったロール割り当ての合計が自分の実際のアクセス許可になります。 ここで、ユーザーにサブスクリプション スコープの共同作成者ロールとリソース グループの閲覧者ロールが付与されている例を考えてみましょう。 共同作成者アクセス許可と閲覧者アクセス許可を足すと、実質的にサブスクリプションの共同作成者ロールになります。 そのため、この場合、閲覧者ロールの割り当ては効果がありません。

Diagram showing how multiple role assignments overlap.

ユーザーがリソースへのアクセス権を持っているどうかを Azure RBAC が特定する方法

リソースへのアクセス権をユーザーが持っているかどうかを特定するために Azure RBAC が使用する手順の概要を次に示します。 これらの手順は、Azure Resource Manager または Azure RBAC と統合されたデータ プレーン サービスに適用されます。 これは、アクセスの問題のトラブルシューティングを行う場合に理解していると役に立ちます。

  1. ユーザー (またはサービス プリンシパル) は、Azure Resource Manager に対するトークンを取得します。

    トークンには、ユーザーのグループ メンバーシップが含まれています (推移的なグループ メンバーシップを含みます)。

  2. ユーザーは、トークンを添付して Azure Resource Manager への REST API の呼び出しを行います。

  3. Azure Resource Manager では、アクション実行対象リソースに適用されるすべてのロール割り当てと拒否割り当てが取得されます。

  4. 拒否割り当てが適用される場合、アクセスはブロックされます。 それ以外の場合は、評価が続行されます。

  5. Azure Resource Manager は、このユーザーまたはユーザーのグループに適用されるロールの割り当てを絞り込み、このリソースに対してユーザーが持っているロールを特定します。

  6. Azure Resource Manager は、API 呼び出しでのアクションが、このリソースに対してユーザーが持っているロールに含まれるかどうかを判別します。 ワイルドカード (*) が使用された Actions がロールに含まれている場合、有効なアクセス許可は、許可された Actions から NotActions を減算することによって計算されます。 同様に、同じ減算がすべてのデータ アクションに対して行われます。

    Actions - NotActions = Effective management permissions

    DataActions - NotDataActions = Effective data permissions

  7. 要求されたスコープのアクションを含むロールをユーザーが持っていない場合、アクセスは許可されません。 それ以外の場合は、すべての条件が評価されます。

  8. ロールの割り当てに条件が含まれる場合は、それらが評価されます。 それ以外の場合は、アクセスが許可されます。

  9. 条件が満たされた場合は、アクセスが許可されます。 それ以外の場合、アクセスは許可されません。

次の図は、評価ロジックの概要です。

Evaluation logic flowchart for determining access to a resource.

Azure RBAC データはどこに格納されますか。

リソースを作成したリージョンに関係なく、リソースにアクセスできるように、ロールの定義、ロールの割り当て、および拒否の割り当ては、グローバルに保存されます。

ロールの割り当てまたはその他の Azure RBAC データが削除されると、データはグローバルに削除されます。 Azure RBAC データを介してリソースにアクセスしたプリンシパルは、アクセス権を失います。

Azure RBAC データがグローバルである理由は何ですか。

Azure RBAC データはグローバルであり、ユーザーがどこからアクセスしているかに関係なく、タイムリーにリソースにアクセスできます。 Azure RBAC は、Azure Resource Manager によって適用されます。この場合、グローバル エンドポイントが指定され、要求は、迅速性と回復性のために、最寄りのリージョンにルーティングされます。 そのため、Azure RBAC をすべてのリージョンに適用し、データをすべてのリージョンにレプリケートする必要があります。 詳細については、「Azure Resource Manager の回復性」を参照してください。

例を次に示します。 Arina は、東アジアに仮想マシンを作成します。 Arina のチームのメンバーである Bob は、米国で作業をしています。 Bob は、東アジアで作成された仮想マシンにアクセスする必要があります。 Bob が仮想マシンにタイムリーにアクセスできるようにするには、Azure を使用して、ロールの割り当てをグローバルにレプリケートする必要があります。このロールの割り当てにより、Bob は、どこにいても仮想マシンへのアクセスが許可されます。

Diagram showing Azure RBAC data in multiple regions.

ライセンスの要件

この機能の使用は無料で、Azure サブスクリプションに含まれています。

次のステップ