【入門編】 Azure RBACにおけるカスタムロールの定義と管理のベストプラクティス – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

皆さん、こんにちは。現場で泥にまみれながらインフラを守り続けているエンジニアです。

今日は「クラウドの要塞化」という、少し強そうなテーマについてお話しします。特にAzureを使っている皆さんが、誰でも一度は迷う「Azure RBAC（ロールベースのアクセス制御）」と、その中でも「カスタムロール」という仕組みについて紐解いていきましょう。

「とりあえず管理者権限を渡しておけば動くから大丈夫だよね」……実はその考え方が、一番の泥棒の入り口なんです。

—

1. なぜ「最小限の権限」が最強の防犯なのか？

想像してみてください。あなたは立派な一軒家（クラウド環境）に住んでいます。
ここには「家中のすべての部屋に入れるマスターキー（所有者権限）」と、「リビングとキッチンだけ入れる鍵（カスタムロール）」の2種類があるとします。

もし、あなたが友人に「ちょっとキッチンでコーヒー淹れてきて！」と頼むとき、どちらの鍵を渡しますか？

マスターキーを渡すと： 寝室の金庫も、書斎の秘密書類も、友人は自由に見放題です。もしその友人が悪意のある誰かに騙されたら？あるいは友人がうっかり失くしたら？家中の全てが危険に晒されます。
キッチンの鍵だけ渡すと： 友人はコーヒーを作るという目的だけを達成し、他の場所へは手出しができません。万が一鍵を盗まれても、被害はキッチンだけで食い止められます。

ITの世界でも全く同じです。「必要最小限の権限」とは、まさにこの「必要な部屋の鍵だけを渡す」という防犯テクニックのこと。これが、ハッカーから環境を守るための最も基本的で、かつ強力な盾になります。

—

2. 組み込みロールという「広すぎる鍵」

Azureには、最初から用意されている「組み込みロール（Contributorなど）」があります。これは非常に便利ですが、実は「家中の部屋に入れる」に近い権限を持っていることが多いのです。

「サーバーを再起動するだけ」「ログを確認するだけ」という作業のために、サーバーを削除する権限まで渡してしまうのは、セキュリティの観点から見ると「金庫の鍵を首から下げて街を歩いている」ようなものです。

そこで登場するのが、今回の主役「カスタムロール」です。

—

3. カスタムロールを作ってみよう（実践編）

カスタムロールは、必要な操作（アクション）だけを厳選して定義します。Azureでは、JSON形式でこれらを定義するのが一般的です。

例えば、「仮想マシンの状態を確認し、再起動だけはできるが、削除は絶対にさせない」という担当者向けのロールを作ってみましょう。

{
  "Name": "VM-Operator-CustomRole",
  "IsCustom": true,
  "Description": "仮想マシンの起動・再起動のみ許可するロール",
  "Actions": [
    "Microsoft.Compute/virtualMachines/read", // 状態の閲覧権限
    "Microsoft.Compute/virtualMachines/start/action", // 起動アクション
    "Microsoft.Compute/virtualMachines/restart/action" // 再起動アクション
  ],
  "NotActions": [
    "Microsoft.Compute/virtualMachines/delete" // 念のため削除を明示的に禁止
  ],
  "AssignableScopes": [
    "/subscriptions/{サブスクリプションID}" // この設定が有効な範囲を限定
  ]
}

ポイント解説

Actions: 「何をしてもいいか」を具体的に書きます。これ以外の操作は自動的に「拒否」されます。
NotActions: 「これだけは絶対にやらせない」という、いわば拒絶のバリケードです。多重防御の考え方ですね。
AssignableScopes: 「家全体」ではなく「特定の部屋（リソースグループなど）」だけに鍵を適用することで、被害範囲を最小限に抑えられます。

—

4. 運用で一番大事なこと：定期的な「棚卸し」

カスタムロールを作って終わり！ではありません。ここが泥臭いセキュリティ運用の真骨頂です。

「権限の肥大化」を疑う： 担当者が変わったり、業務内容が変わったりすると、いつの間にか「あれもこれもできるようにしてほしい」と権限が増えていきがちです。半年に一度は「本当にこの権限は必要か？」と見直しましょう。
不自然なログを監視する： 最小権限で運用していれば、もしそのIDが乗っ取られた場合、「許可されていない操作（拒否されたログ）」が大量に発生するはずです。これこそが「泥棒がドアノブをガチャガチャしている証拠」になります。

—

まとめ：一歩ずつ要塞を固めていこう

最初は難しく感じるかもしれません。「あれもこれも制限したら仕事が止まるのでは？」と不安になることもありますよね。でも大丈夫です。

まずは「一番リスクの高い場所」や「最も触る頻度の低い権限」から、少しずつカスタムロールに置き換えていきましょう。「全員にすべての鍵を渡さない」。この小さな一歩が、将来の大きなインシデントを防ぐ最強の壁になります。

セキュリティは一度やって終わりではありません。皆さんと一緒に、コツコツと安全な環境を育てていけたら嬉しいです。また次回の記事でお会いしましょう！