RBAC

Page content

RBAC（Role-Based Access Control：ロールベースアクセス制御）とは、
「ユーザー個人に権限を与えるのではなく、“役割（ロール）”に権限をまとめて管理する仕組み」 です。

✅ 一言でいうと

「どのユーザーが何をできるか」を “役割” を介して管理するアクセス制御モデル

🔍 RBAC の基本構造

RBAC は 3つの要素で成り立ちます：

  1. User（ユーザー）
    → 実際にシステムを使う人

  2. Role（ロール）
    → 権限のグループ（例：管理者、一般ユーザー、閲覧者）

  3. Permission（権限）
    → 実行できる操作（例：閲覧、編集、削除）

そして

User → Role → Permission

という 紐づけの“中間にロール”が入るのがポイントです。

🧱 RBAC がない場合（権限を直接付けると…）

例：

  • ユーザーA → 編集権限

  • ユーザーB → 閲覧権限

  • ユーザーC → 編集＋削除
    → ユーザーごとに権限管理が複雑になる
    → 大人数の組織では破綻しやすい

🧱 RBAC の場合（ロールを使う）

例：

■ ロール

  • admin（閲覧・編集・削除）

  • editor（閲覧・編集）

  • viewer（閲覧のみ）

■ ユーザー

  • ユーザーA → editor

  • ユーザーB → viewer

  • ユーザーC → admin

→ 権限はロールにまとめておくので 管理が圧倒的に楽

🎯 RBAC を使うメリット

✔ 管理が簡単（スケールする）

ユーザーが増えても、ロールを付け替えるだけ。

✔ セキュリティが明確

誰が何をできるかが一目で分かる。

✔ 役割に応じた権限変更が容易

部署異動や役割変更のとき、ロールを変更するだけ。

✔ 組織の構造と一致させやすい

現実の組織（管理者・チームリーダー・メンバー）と対応。

🛠 RBAC がよく使われる場面

  • Webアプリ・SaaS のユーザー管理

  • AWS IAM

  • Auth0 や Keycloak などの IAM サービス

  • 業務システムのアクセス権管理

  • ファイルサーバー、DB などのアクセス権限

  • 管理画面の閲覧制御

🔐 Auth0 での RBAC（補足）

Auth0 では：

  • Role に Permission を付ける

  • User に Role を付ける

  • API 用の Access Token に permissions クレームが入る

例：

{
  "permissions": [
    "read:users",
    "edit:articles"
  ]
}

API 側は JWT の permissions を見てアクセス制御できる。

🧩 まとめ

  • RBAC は「ユーザー → ロール → 権限」で管理する方式

  • 権限を直接ユーザーにつけないので管理が楽

  • 組織にスケールしやすく、セキュア

  • Auth0、AWS、各種サービスで標準的に使われている

  • RBAC と ABAC（属性ベース）比較

  • RBAC の図解

  • Auth0 で RBAC を有効にする手順

  • RBAC 設計のベストプラクティス