はじめに

Webアプリの権限設計でよく登場する RBAC（Role-Based Access Control）と DAC（Discretionary Access Control）。名前は聞いたことがあっても、違いをスッキリ説明できる方は意外と少ないのではないでしょうか。

この記事では、Google DriveやGitHubなど身近なWebサービスを例に、両者の本質的な違いと使い分けの考え方を整理します。

対象読者

Webアプリの権限設計をこれから設計する／見直したい方
RBAC・DACという言葉は聞いたことがあるが、違いを説明できない方

参考リンク

両者を分ける本質：「誰が権限を決めるか」

最初に結論を書いてしまいます。RBACとDACを分ける最も重要な軸は、「誰が権限を決めるか」 です。

モデル	一言で	権限を決めるのは
RBAC	役割で配る	管理者（システム全体のポリシー）
DAC	持ち主が配る	リソースの所有者

この一行さえ押さえてしまえば、あとはその応用です。順番に見ていきましょう。

DAC：所有者が裁量で配る

DACは「Discretionary（任意の）」という名前の通り、リソースの所有者が自分の裁量で権限を配れるモデルです。

最も分かりやすいのが Google Drive の共有ボタンですね。あなたが作ったドキュメントは、あなたの判断で同僚を閲覧者にしたり、上司を編集者に格上げしたり、いつでも共有を取り消したりできます。システム管理者が「このドキュメントを誰が見られるか」を決めているわけではない、というのがポイントです。Unixのファイルパーミッション（chmod）も古典的なDACの代表例で、ファイルの所有者が他のユーザーに読み書き権限を渡せます。

DACが活きるのは、ユーザー自身に共有の判断を委ねたいサービスです。ファイル共有、写真共有、個人用メモアプリなど、「自分の作ったものは自分で配りたい」という体験が中心にあるサービスと相性が良いですね。

ただし、DACには有名な落とし穴があります。

所有者が自由に共有を広げられるため、組織全体としての情報統制が効きにくい。各ドキュメントの所有者が「外部リンクで共有可」にしてしまえば、機密情報の流出を防ぐルールはザルになります。

RBAC：管理者が役割で配る

RBACは、管理者が「ロール（役割）」を定義し、ユーザーをそこに紐付けることで権限を配るモデルです。1992年に Ferraiolo と Kuhn によって提唱され、現在ではエンタープライズで最も普及しているモデルですね¹。

身近な例は、SaaSのメンバー管理画面です。Slack、Notion、GitHubなどで「Owner / Admin / Member / Guest」といったロールを見たことがあるはずです。新入社員が入ってきたら「Member」を割り当てる。退職したらロールを剥がす。それだけで、その人の権限が一括で決まったり、取り上げられたりします。

ここで重要なのは、個別のリソースに対して権限を設定しているわけではないこと。

RBACが活きるのは、組織として一貫した権限ルールを敷きたいシーンです。業務用SaaS、社内管理ツール、CMSのバックエンドなど、「役職」や「職務」で権限が決まる世界ですね。

こちらにも落とし穴があります。

ロール爆発（Role Explosion）問題

「営業部の東京オフィスのマネージャーで、かつ案件Aの担当」のように細かい条件で権限を切り分けたくなると、ロールの数が組み合わせ爆発で増えていきます。大規模組織で頻発する古典的な弱点です。

この問題への対処として、属性で動的に判定する ABAC（Attribute-Based Access Control）や、関係性で判定する ReBAC（Relationship-Based Access Control）といった発展形が登場しています。

現実のWebサービスはハイブリッド

ここまで対立軸で書いてきましたが、実際のWebサービスはほとんどの場合ハイブリッドです。

たとえばGitHubでは、Organization全体の役割（Owner / Member など）はRBACで設計されていますが、個別リポジトリへのコラボレーター招待は所有者の裁量によるDAC的な仕組みです。Notion、Slack、Google Workspaceなども同様に、ワークスペース全体のロールはRBAC、個別ページやチャンネルの共有はDAC、という多層構成になっています。

NISTの研究でも、RBACはDACやMACを実装する基盤として使えることが示されています。RBACで全体の骨格を作り、その上でDAC的な細かい共有を許す多層構成は、理論的にも自然な設計です。

設計時の判断フロー

自分でWebアプリの権限設計をするときは、次の順番で考えるとうまく行くことが多いです。

経験則として、まずRBACで骨格を作り、必要に応じてDACで穴を開けるという順番が安全です。逆にDACから始めると、組織が大きくなったときに統制が効かなくなりがちなので、骨格としてのロール設計を最初にしておく価値は大きいですね。

まとめ

DAC：所有者が裁量で権限を配る。Google Driveの共有ボタンが代表例。
RBAC：管理者がロールを定義し、ユーザーを紐付ける。SaaSのメンバー管理画面が代表例。
両者の本質的な違いは「誰が権限を決めるか」。
現実のWebサービスはほぼハイブリッド。RBACで骨格、DACで個別共有が定石。
より動的な制御が必要になったら、ABACやReBACへの発展も視野に。

NIST/ANSI/INCITS 359-2004（2012年に INCITS 359-2012 として改訂）として標準化されています。 ↩