自己紹介

中山 賢斗

• 所属：日本マイクロソフト
• クラウドを勉強し隊 (https://www.kentsu.website/ja/)
• すきやねん Azure!!
• Japan Azure Travelers
• AzPoC 部
• YonaYona Azure Club

最近の 1 日

こどもの誕生から半年経過し、最近はこんな感じの生活

• ～18時半：仕事、離乳食
• ～19時半：こどものお風呂
• ～20時半：寝かしつけ
• ～22時：晩御飯
• ～24時：残った仕事、プライベートのあれこれ、勉強 etc,...

平日の勉強会が だいたい 19:00 - 21:00 が多くオンラインでも参加できない。。。

本題に入ります

Azure の権限管理（RBAC）やってますか？

RBAC には3つの要素があります

1. ロール: 権限（アクション）の集合
2. プリンシパル: ユーザー、グループやアプリケーション
3. スコープ: 権限を適用する範囲（サブスクリプション、リソース グループ、リソース）

RBAC あるある？

%%{init: {'themeCSS': '.actor text, .actorLabel, .messageText, .label, .actorName, .noteText { fill: #000 !important; font-weight: 700 !important; }'}}%%
sequenceDiagram
    actor 管理者
    actor リーダー
    actor メンバー
    管理者->>リーダー: "所有者" 渡すから君の組織の権限管理よろしく
    リーダー->>管理者: OK まかせて
    リーダー ->> メンバー: "所有者" ある方が便利やから渡しとくわ
    Note right of メンバー: よっしゃなんでもできるでー
    Note right of 管理者: なんでこんなに "所有者" おるねん。。おかしいやろ

従来の RBAC の課題

権限委任は「全か無か」の世界

• 「ユーザー アクセス管理者」ロールや 「所有者」ロールを付与すると...
• そのスコープ内で すべての ロール割り当てを管理可能

細かい制御ができない = セキュリティリスク

その結果。。。

• 結局、管理者が全ユーザーの権限を管理することに
• 管理者の負担 爆上げ
• ユーザーは権限が欲しい場合に申請をあげる必要があり、効率ダウン

誰も幸せにならない

条件付き委任の登場

Azure ABAC を活用した新しいアプローチ

• 特定の条件を満たす場合のみ ロール割り当てを許可
• より細かい粒度での権限制御が可能

セキュリティリスクの軽減

実装のポイント

「ロール ベースのアクセス制御の管理者」を推奨

• 所有者やユーザー アクセス管理者は高権限すぎる
• ロール ベースのアクセス制御の管理者は必要最小限の権限
  • Microsoft.Authorization/roleAssignments/write
  • Microsoft.Authorization/roleAssignments/delete
  • */read
  • Microsoft.Support/*

余計な操作ができないため安全

条件として指定できること

RBAC の 3つの要素のうち、ロールとプリンシパルに制限をかけられる

1. ロール:
   • ロールの種類の制限：特定のロールのみ許可/拒否
2. プリンシパル:
   • プリンシパルのタイプの制限：ユーザー、グループ、サービス プリンシパル
   • 特定のプリンシパルのみ許可
3. スコープ:
   • スコープに対する制限は不可

設定画面

Azure Portal での設定例

• ロール: 「閲覧者」のみ
• プリンシパル: 「ユーザー」のみ

動作確認

制限が効いている

• 閲覧者ロールしか選択できない
• 条件に合わないロールは表示されない

まとめ

RBAC 条件付き委任の主なメリット

• 細かい粒度での権限制御
• セキュリティリスクの軽減
• 管理者の負荷軽減
• ガバナンスの向上