🛡️ 誰に何を許す？ RBAC、ACL、RLSの関係をサクッと解説！
システムやデータベースのセキュリティを考える上で、「誰に、どこまでアクセスを許すか」を決める仕組みは非常に重要です。その中でも代表的なものが、RBAC、ACL、そしてRLSです。
一見難しそうな横文字ですが、実はこれらは「アクセスを制御する粒度（細かさ）とアプローチ 」が違うだけ。身近な例でその関係を整理してみましょう！
🏢 1. RBAC (Role-Based Access Control)：「役割」で管理する 👑
【例えるなら】会社の「名札」と「部署」
RBACは、その名の通り「ロール（役割）」に基づいてアクセスを制御する手法です。
📌 RBACの仕組み
- まず、「管理者」「経理担当」「一般社員」といった役割（ロール） を定義します。
- それぞれの役割に対して、「経理システムへのアクセス」「全社員データの閲覧」といった権限を与えます。
- ユーザーには、該当する役割を与えます。
🔑 特徴
- 管理がシンプル: ユーザーが増えても、権限管理は「役割」を変えるだけで済みます。異動で役割が変わっても、ロールを付け替えるだけで必要な権限が自動で付与されます。
- 大規模向け: ユーザーやリソースが多い、複雑な組織の権限管理に最適です。
📝 2. ACL (Access Control List)：リソースごとにリストで管理する 📜
【例えるなら】個々の「鍵」と「許可証」
ACLは、「対象となるリソース（資源）」ごとに、「誰が」何をできるかをリスト（一覧）形式で定義する手法です。
📌 ACLの仕組み
- リソース（例:
売上データ.xlsxというファイル）を一つ用意します。 - そのファイルに対し、「ユーザーAは読み取りと書き込み、ユーザーBは読み取りのみ」というリスト（ACL）を設定します。
🔑 特徴
- 粒度が細かい: ファイルやフォルダ、データベースのテーブル全体や特定の列（カラム） など、リソースごと、ユーザーごとに非常に細かくアクセスを設定できます。
- 直接的: ユーザーと権限が直接結びつくため、設定内容はわかりやすいです。
- 課題: ユーザーやリソースが増えると、リストが膨大になり、管理が複雑化しやすいのが欠点です。
💡 RBACは役割をベースにした効率的な管理アプローチであり、ACLはリソースをベースにした個別設定のアプローチです。ACLは、RBACが適用される環境の中でも、特定のファイルだけ例外的に設定したい場合などにも利用されます。
🧱 3. RLS (Row-Level Security)：「行」単位で制御する 🎫
【例えるなら】データベースの「座席指定券」
RLSは、主にデータベース（PostgreSQLなど）で使用される、最も粒度の細かいアクセス制御です。テーブル内の「行（レコード）」単位でアクセスを制限します。
📌 RLSの仕組み
- 人事データのようなテーブル全体にアクセス権がある場合でも、RLSのポリシー（規則） を設定します。
- そのポリシーが、「ログインしているユーザーIDと一致する行（自分のデータ）」しか閲覧できない、というフィルターとして機能します。
🔑 特徴
- 最も安全: ユーザーがSELECTクエリを実行しても、ポリシーが自動的にWHERE句のような働きをするため、見せたくない行が最初から存在しないかのように見えます。
- マルチテナントに最適: 複数の企業データが一つのテーブルに混在するSaaSのようなシステムで、他社のデータを見せないようにする（テナント分離）ために必須の機能です。
💡 結論：アクセス制御の「三種の神器」の関係 ⚙️
これら三つの仕組みは、優劣ではなく、制御したい「対象」と「粒度」 によって使い分けられます。
| 制御の種類 | 主な対象 | 制御の粒度 | アプローチ |
|---|---|---|---|
| RBAC | システム、機能 | 役割(ロール) ごと | 役割でまとめて効率化 |
| ACL | ファイル、テーブル、列 | ユーザーごと、リソースごと | 個別リストで細かく設定 |
| RLS | データベース | 行(レコード) ごと | データの実体レベルでフィルタリング |
これら3つを適切に組み合わせることで、強固で柔軟なアクセス制御を実現することができます。ご自身のシステムで、どの粒度で制御が必要か、ぜひ検討してみてください。