ロールベースのアクセス制御
このドキュメントはどこからリンクされているか分からないが、ググったら出てきたmiyamonz.icon
以下で登場する「アプリケーション」という単語に注意
Azure のリソースにアクセスできるユーザー、そのユーザーがそれらのリソースに対して実行できること、そのユーザーがアクセスできる領域を管理するのに役立ちます。
RBAC でできることの例
各種リソースごとに異なるユーザへ管理の許可
あるユーザーにサブスクリプション内の仮想マシンの管理を許可し、
別のユーザーに仮想ネットワークの管理を許可します
DBA(database administrators) グループにサブスクリプション内の SQL データベースの管理を許可します
あるユーザーに、仮想マシン、Web サイト、サブネットなど、リソース グループ内のすべてのリソースの管理を許可します
あるアプリケーションに、リソース グループ内のすべてのリソースへのアクセスを許可します
アクセス制御戦略を計画する場合のベスト プラクティスは、ユーザーの作業を実行できる最低限の特権をユーザーに付与することです。
次の図は、RBAC を使用するための推奨パターンを示しています。
https://gyazo.com/bf5af0497d38524051e1bcc0d72f7bc9
RBAC を使用してリソースへのアクセスを制御するには、ロールの割り当てを作成します。
これは、アクセス許可が適用される方法であり、理解する必要のある重要な概念です。
ロールの割り当ては、セキュリティ プリンシパル、ロールの定義、スコープの 3 つの要素で構成されています。
セキュリティ プリンシパル
"セキュリティ プリンシパル" は、
Azure リソースへのアクセスを要求するユーザー、
グループ、
サービス プリンシパル、
またはマネージド ID
を表すオブジェクトです。
https://gyazo.com/d92d5994e6249e9b73f6a57857e547c0
ユーザー
Azure Active Directory 内にプロファイルを持つ個人です。
他のテナント内のユーザーにロールを割り当てることもできます。
他の組織のユーザーについては、「Azure Active Directory B2B」をご覧ください。
グループ
Azure Active Directory 内に作成されたユーザーのセットです。
グループにロールを割り当てると、そのグループ内のすべてのユーザーがそのロールを持つようになります。
サービス プリンシパル
特定の Azure リソースにアクセスするためにアプリケーションまたはサービスによって使用されるセキュリティ ID です。
アプリケーションに対する "ユーザー ID" (ユーザー名とパスワード、または証明書) と考えることができます。
マネージド ID
Azure によって自動的に管理される Azure Active Directory 内の ID。
通常、マネージド ID は、Azure サービスに対する認証を受けるための資格情報を管理するクラウド アプリケーションを開発するときに使用します。
サービスプリンシパルとマネージドIDの違い、使い分けが気になるmiyamonz.icon
どちらもプログラムによるアクセスで使われる
ドキュメントにはどちらの場合のやり方も書いてある
ロール定義
ロール定義はアクセス許可のコレクションです。 通常は単に "ロール" と呼ばれます。
ロール定義には、実行できる操作 (読み取り、書き込み、削除など) が登録されています。
ロールは、所有者のように高レベルにすることも、仮想マシン リーダーのように限定することもできます。
https://gyazo.com/963c77a71c269f39f8387db430b7c9e7
Azure には複数の組み込みロールがあり、使用することができます。
4 つの基本的な組み込みロールを次に示します。 最初の 3 つは、すべてのリソースの種類に適用されます。
所有者 - 他のユーザーへアクセス権を委任する権限を含め、すべてのリソースへのフル アクセス権を持ちます。
共同作成者 - Azure リソースのすべての種類を作成および管理できますが、他のユーザーへアクセス権を付与することはできません。
閲覧者 - 既存の Azure リソースを表示できます。
ユーザー アクセス管理者 - Azure リソースへのユーザー アクセスを管理できます。
残りの組み込みロールは、特定の Azure リソースの管理を許可します。
たとえば、仮想マシン共同作成者ロールが割り当てられたユーザーには、仮想マシンの作成と管理が許可されます。
組み込みロールが組織の特定のニーズを満たさない場合は、独自に Azure リソースに対するカスタム ロールを作成することができます。
Azure には、オブジェクト内のデータへのアクセスを許可できるようにするデータ操作が用意されています。
たとえば、ユーザーがあるストレージ アカウントへのデータの読み取りアクセス許可を持っている場合、
そのユーザーはそのストレージ アカウント内の BLOB またはメッセージを読み取ることができます。
詳しくは、Azure リソースのロール定義に関する記事をご覧ください。
スコープ
"スコープ" は、アクセスが適用されるリソースのセットです。 ロールを割り当てるときに、スコープを定義することによって、許可される操作をさらに制限できます。 これは、1 つのリソース グループについてのみ、あるユーザーを Web サイトの共同作業者として指定する場合に便利です。
Azure では、複数のレベル (管理グループ、サブスクリプション、リソース グループ、リソース) でスコープを指定できます。 スコープは親子関係で構造化されています。
https://gyazo.com/1fa4d1bc8f06a4d6ecc7315c221527bc
管理グループ自体を階層化することができるが、これは大企業向けの機能
親スコープでアクセス権を付与すると、それらのアクセス許可が子スコープに継承されます。 次に例を示します。
管理グループ スコープでユーザーに所有者ロールを割り当てた場合、そのユーザーは、その管理グループに存在する全サブスクリプションの内容をすべて管理することができます。
閲覧者ロールをサブスクリプション スコープでグループに割り当てた場合、そのグループのメンバーは、サブスクリプション内のすべてのリソース グループとリソースを見ることができます。
共同作成者ロールをリソース グループ スコープでアプリケーションに割り当てた場合、そのアプリケーションは、そのリソース グループ内のすべての種類のリソースを管理できますが、サブスクリプション内の他のリソース グループは管理できません。
拒否割当というのもある