RBAC

概要

RBAC（Role-Based Access Control、ロールベースアクセス制御）は、「誰が何をしてよいか」を決める認可の設計モデルのひとつで、ユーザーに権限を直接与える代わりに、「経理担当」「開発者」「閲覧者」といったロール（役割）に権限をまとめ、ユーザーにはロールを割り当てる方式です。ユーザーと権限の間に「ロール」という間接層を1枚挟む — この一手間が、権限管理を人数と機能の掛け算から救い出します。

クラウドの IAM、業務システムの権限設定、Kubernetes のアクセス制御、SaaS の管理画面 — 現代のシステムで「権限」という言葉が出てくる場面の大半で、その裏側は RBAC か、RBAC をベースにした変種です。権限管理の実務標準と言ってよいモデルです。

なぜ生まれたか

RBAC 以前の素朴なモデルは、ユーザーと権限を直接結びつけるものでした。「Aさんは請求書の閲覧と承認ができる」「Bさんはサーバの再起動ができる」と個人単位で設定していく方式です。ユーザーが10人、権限が20種類なら管理できますが、1,000人×500種類になると設定は最大50万通りの組み合わせに膨らみ、「Aさんはなぜこの権限を持っているのか」を誰も説明できなくなります。異動しても古い権限が残り続け、監査のたびに棚卸しが破綻する — 権限の付与は簡単でも、剥奪と説明が不可能になるのがこのモデルの宿命でした。

1990年代にこの問題への解として定式化されたのが RBAC です（1992年の Ferraiolo と Kuhn の論文が起点とされ、後に NIST 標準になりました）。着眼点は「権限は個人ではなく、組織上の役割に紐づいている」という事実です。経理担当者が請求書を承認できるのは、その人が特別だからではなく「経理担当という役割」だからです。ならば権限は役割に定義し、人には役割を割り当てればよい。異動したらロールを付け替えるだけで権限が丸ごと入れ替わり、「なぜこの権限を持つか」は「このロールだから」と説明できるようになりました。

詳細

ロールという間接層

RBAC の構造は「ユーザー → ロール → 権限」の三層です。権限（パーミッション）は「請求書を承認する」「デプロイを実行する」のような操作の単位で、これをロールに束ね、ユーザーにはロールだけを割り当てます。ユーザーが m 人、権限が n 種類のとき、直接割り当てでは最大 m×n 本の対応を管理するのに対し、ロールを k 個挟めばおおよそ m+n 本のオーダーに圧縮されます。数の圧縮以上に重要なのは意味の圧縮で、「このユーザーの権限一覧」という説明不能な集合が、「開発者ロール」という監査可能な名前に置き換わることです。

ロール設計の実際

RBAC 運用の成否はロールの切り方で決まります。基本は職務（ジョブ機能）に沿って切ることです。「閲覧者・編集者・承認者・管理者」のように業務上の役割と対応させると、人事イベント（入社・異動・退職）と権限変更が自然に連動します。IdP と連携させて、ディレクトリ上のグループ（部署や職種）をロールに対応づければ、異動が権限の付け替えに自動反映される運用が実現します。

ロールには階層（承認者は編集者の権限を含む、など）や制約（同一人物に「申請者」と「承認者」を同時に与えない職務分掌ルール）を加えられます。後者は不正の抑止に直結するため、経理・購買系のシステムでは特に重要です。いずれの場合も、各ロールに与える権限は最小権限の原則に従い、その役割の遂行に必要な最小限に絞るのが大前提です。

落とし穴 — ロール爆発

RBAC の古典的な失敗パターンが「ロール爆発（role explosion）」です。「営業部の編集者だが東京支社のデータだけ」「開発者だが本番環境は閲覧のみ」といった例外要求のたびに専用ロールを作っていくと、「営業_東京_編集」「営業_大阪_編集」「開発_本番_閲覧」…とロールが部署×地域×環境の掛け算で増殖し、気づけばユーザー数よりロール数が多い本末転倒な状態に陥ります。間接層で圧縮したはずの複雑さが、ロールの名前空間に形を変えて戻ってくるわけです。

この限界への対案が ABAC（Attribute-Based Access Control、属性ベースアクセス制御）です。ABAC はロールを列挙する代わりに、「ユーザーの部署 = リソースの管轄部署、かつ勤務時間内なら編集可」のように、ユーザー・リソース・環境の属性を組み合わせたルール（ポリシー）で判定します。掛け算で増える条件をルール1本で表現できる反面、「今この人は何ができるのか」の全容把握が難しくなり、ポリシーのデバッグも複雑になります。実務では、骨格は RBAC で組み、細かい条件だけ属性ルールで補うハイブリッドが現実解になることが多く、AWS IAM の条件付きポリシーや Azure の条件付きアクセスはまさにこの形です。

実例 — Kubernetes RBAC

具体的な実装として分かりやすいのが Kubernetes の RBAC です。「どの操作を許すか」を Role（例: Pod の get/list/watch を許可）として定義し、RoleBinding で「誰に」（ユーザー、グループ、またはサービスアカウント）を結びつけます。ロール定義と割り当てが別リソースに分かれているため、「権限のセットを設計する人」と「それを配る人」の作業を分離できるのが特徴です。クラスタ全体に効かせる ClusterRole/ClusterRoleBinding との使い分け、そして CI パイプラインや運用ツールに与えるサービスアカウントの権限を絞ることが、実運用での主要な論点になります。人間だけでなく「プログラムに与える権限」も同じロールの仕組みに載せられることは、RBAC が実務標準であり続ける理由のひとつです。