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 本の対応を管理しなければなりません。ロールを挟むと、管理するのは「ユーザー→ロール」と「ロール→権限」の2種類の対応になります。各ユーザーがロールを1つだけ持ち、各権限が1つのロールにだけ属するという単純な場合なら、本数は m+n 本にまで圧縮されます。実際にはユーザーが複数のロールを持ち、権限も複数のロールで共有されるので、本数は m+n と m×n の間に落ち着きます。それでも人数が増えるほど差は開きます。数の圧縮以上に重要なのは意味の圧縮で、「このユーザーの権限一覧」という説明不能な集合が、「開発者ロール」という監査可能な名前に置き換わることです。

ロール設計の実際

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

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

落とし穴 — ロール爆発

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

下の部品で確かめてください。まず未割り当てのユーザーをロールへ運び、直接割り当てと RBAC の線の本数を比べます。続いて例外要求のカードを投げ込むと、ロールが掛け算で増えていく様子が見えます。

⚡ 体験: ロールで束ねる、例外でロールが増えるリセット

＋30人 入社する

割り当て

6人のうち2人（伊藤さん・渡辺さん）がまだ権限を持っていません。金の輪のチップをドラッグして、ロールに割り当ててください。上の数字で、直接割り当てと RBAC の線の本数を比べられます。

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

実例 — Kubernetes RBAC

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

試問

RBAC（ロールベース）は「経理担当」「開発者」のような役割に権限をまとめて人に割り当てる方式で、ABAC（属性ベース）は「利用者の部署」「データの持ち主」「いまの時刻」のような属性を比べるルールで判定する方式です。業務システムに届いた8つのアクセスの決まりを、どちらで書くのが素直かで分けます。

✦ 命題挑戦中

8つのアクセスの決まりを、ロールで書けるものと、属性を比べるルールが要るものに仕分けよ

東京支社のデータは、東京支社の人だけが見られる開発者は、検証環境にデプロイできる本番のデータベースには、勤務時間内だけ入れる担当に割り当てられた顧客のカルテだけを開ける閲覧者は、売上のダッシュボードを見られる管理者は、新しいユーザーを追加できる自分が作った経費申請だけを編集できる経理担当は、請求書を承認できる

ロールで書ける役割が決まれば、できることが決まる

属性ルールが要る人・データ・状況の属性を比べる

判定する

項目を選んでから、入れる箱を選びます