この記事の目的
Azureではいくつかの方法でユーザーのアクセスを制御することができます。
この記事ではAzure1年生の筆者の備忘録を兼ねてAzureでのロールベースのアクセス制御の基本や、注意点を確認していきたいと思います。
ロールとは
Azureにおけるロールは、いくつかのアクセス許可をまとめたものです。
ユーザーにロールを付与することでリソースへのアクセスや、リソースに対する操作を制御することができます。
ロールには大きく分けて下記の２種類があります。
- 組み込みロール：Azureがあらかじめ用意しているロール
- カスタムロール：ユーザーがアクセス許可を任意に編集して作成するロール
組み込みロールの一覧は下記の公式ページに記載されています。
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/built-in-roles
ロールのスコープと自動継承
ロールの付与は、各リソースなどのメニューにある「アクセス設定（IAM）」で行います。
手順は下記の公式ページに記載されています。
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/role-assignments-portal
ロールの付与（IAMの設定）を行う時は下記に注意が必要です。
- IAMの設定はリソースでだけではなく、各スコープでも行うことができる
- IAMで設定したロールとユーザーは、下位のスコープのIAMの設定に自動継承される
上記を意識していないと、許可していないはずの操作をユーザーができてしまったり、許可したはずの操作をユーザーができなかったりしてしまいます。
スコープ
まず、ロールの付与（IAMの設定）は各リソースでだけでなく、サブスクリプションやリソースグループでも行うことができます。スコープは、上位から管理グループ＞サブスクリプション＞リソースグループ＞リソースとなっています。
詳細は下記の公式ページの通りです。
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/overview
自動継承
注意すべきなのは、上位のスコープでユーザーに付与されたロールは、下位のスコープに自動継承されるということです。例えば、あるリソースグループのIAMでユーザーAを「閲覧者」に設定すると、そのリソースグループ以下の全てのリソースにおいて、ユーザーAは「閲覧者」としてのアクセス許可を持つことになります。そしてこの自動継承を解除することは基本的にできません。
例
これから２つの組み込みロールを例にして、IAM設定の注意点を確認していきたいと思います。
閲覧者（Viewer）
組み込みロール「閲覧者」は下記のアクセス許可で構成されています。
*/read
アクセス許可にはワイルドカード（アスタリスクの部分）を使うことができます。上記のアクセス許可は、サービスを問わないread権限を示しているため、「閲覧者」を付与されたユーザーは、IAM設定を行ったスコープ以下全てのリソースなどにおけるread権限を持つことになります。
特に注意が必要なのは、ある一つのサービスに複数のリソースを作成した時です。例えば、既にVM以外のリソースが存在する環境下において、新たにVM1〜VM5を作成したとします。このときユーザーにVM1〜5のread権限を与えるため、リソースグループのIAM設定でユーザーに「閲覧者」を付与するのは適当でしょうか。
もしリソースグループのIAMに設定してしまうと、同じリソースグループ以下にある、VM以外の他のリソースに対してもユーザーは「閲覧者」のアクセス許可を持つことになってしまいます。これを防ぎVMのみのread権限を与えるには、VM1~5それぞれのIAMで「閲覧者」を設定するか、VMのみをスコープとしたread権限を持つカスタムロールを作成してリソースグループに設定するほうが適当でしょう。
SQL Server 共同作成者（SQL Server Contributor）
次に「SQL Server 共同作成者」というロールを見てみます。
持つ権限が多いため、説明の都合により一部のアクセス許可のみを抜粋しました。
Microsoft.Authorization/*/read #ロールとロール割り当ての読み取り
Microsoft.Resources/deployments/* #リソース グループ デプロイの作成と管理
Microsoft.Resources/subscriptions/resourceGroups/read #リソース グループを取得または一覧表示
Microsoft.Sql/servers/databases/* #SQL データベースの作成と管理
Microsoft.Sql/servers/read #サーバーの一覧とプロパティの読み取り
ここで、sqlsrv1という名前のSQL Serverリソースを作成したとします。
sqlsrv1のIAM設定で「SQL Server 共同作成者」をユーザーに付与しても、ユーザーは権限が足りずデータベースを作成することができません。Microsoft.Resources/subscriptions/resourceGroups/readというアクセス許可が含まれているロールにも関わらず、ユーザーはサーバー作成時にリソースグループを選択することができず、操作を続行できなくなります。
これは、sqlsrv1のIAMで設定してしまうと、Microsoft.Sql以外のアクセス許可が有効にならないためだと考えられます。
このロールはリソースグループ、またはそれより上位のスコープのIAMで設定することで、ユーザーがSQLServerを作成することができるようになります。複数のサービスにまたがるアクセス許可を持つロールを扱う場合に、同様のことが起こると思われるため、注意が必要です。
※ちなみにAzure SQL Server内のデーターベースユーザーをAzure Portal上で作成および管理することはできません。オンプレのSQL Serverと同じように、データベースに対してクエリを発行するなどして作成および管理する必要があります。
おわりに
ロールベースのアクセス制御は、設定に注意も必要ですが柔軟な設定が可能です。
上手に活用してAzureライフを楽しみたいですね。
最後までご覧いただきありがとうございました。
※古くなった内容や、内容の誤りがありましたらご連絡いただけますと幸いです。