組織のためのクラウド サービスの管理における重要な側面は、クラウド リソースへのアクセスを制御することです。 それは、サービスまたはそのコンポーネントの 1 つにアクセスする必要があるユーザーにはそれにアクセスできるようにし、それ以外のユーザーにはアクセスできないようにすることを意味します。 このプロセスは、 ID およびアクセス管理 (IAM) と呼ばれます。 Azure、AWS、GCP では、IAM は ロールベースのアクセス制御 (RBAC) と呼ばれる手法を使用して実現されます。
RBAC では、ユーザーまたはユーザーのグループに 1 つ以上の ロールが割り当てられます。 各ロールにはわかりやすい名前が付いており、ロールではアクセス許可を使用して、ロールを割り当てられたユーザーが関連するリソースに対して実行できるアクションが定義されます。 たとえば、あるリソース グループに対して定義されている "閲覧者" ロールを割り当てられたユーザーは、そのリソース グループ内のリソースを表示できますが、変更または削除することはできません。
ユーザーがリソースにアクセスできるかどうかは、次のものによって制御されます。
- ユーザーに割り当てられたロール
- ユーザーが属しているグループに割り当てられたロール
- ロールのリソース スコープ。
リソース スコープは、クラウド リソース階層内のレベルです。 たとえば、Azure では、ロールは、個々のリソース、リソース グループ、サブスクリプション全体 (この場合、ロールのアクセス許可は、特定のサブスクリプションで作成されたすべてのリソースに適用されます)、またはサブスクリプションのグループに適用できます。 リソース階層内の異なるスコープに異なるロールを適用することにより、ユーザーが持っているアクセス許可によって組織内で何を実行できるかを、きめ細かく制御できます。
図 3.6 の例では、一連のリソースがクラウド サブスクリプション内にプロビジョニングされ、2 つのリソース グループにまとめられています。 Engineering という名前のユーザー グループには、"Reader" (閲覧者) ロールが割り当てられています。これにより、グループのメンバーは、サブスクリプションで作成されたすべてのリソースを表示できるようになります。 同時に、Aurelia Dyer という名前のユーザーには、リソース グループ A の任意のリソースを変更できる "Contributor" (共同作成者) ロールと、同じリソース グループ内の Web アプリ リソースを削除できる "Owner" (所有者) ロールが割り当てられています。 Aurelia が Engineering グループのメンバーであると仮定してみましょう。 これらのアクセス許可により、次のことができます。
- サブスクリプションで作成されたすべてのリソースを表示する
- リソース グループ A の 2 つのリソースを変更する -- たとえば、Web アプリ 1 の構成設定の変更や、ストレージ アカウント 1 のレプリケーション設定の変更
- リソース グループ A の Web アプリ 1 リソースを削除する
リソース グループ B のリソースについては、Aurelia は表示することはできますが、変更または削除することはできません。
図 3.6: RBAC と有効なアクセス許可。
ユーザーに複数のロールを割り当てることができる場合は、アクセス許可の競合の処理方法に関して懸念されることがいくつか発生する場合があります。 現在、主要なクラウド サービス プロバイダーでは、RBAC の実装において "許可" アクセス許可はサポートされていますが、"拒否" アクセス許可はほとんど、またはまったくサポートされていません。 (Azure においてのみ、"拒否" アクセス許可が、限られたコンテキストだけでサポートされています。"拒否" アクセス許可が "許可" アクセス許可と競合する場合、"拒否" が優先されます) "許可" アクセス許可は加算的であるため、相互に競合することはありません。ユーザーのアクセス許可は、該当する各スコープのさまざまな "許可" アクセス許可の合計になります。