最近、プロジェクトで権限管理モジュールの設計・実装が必要になったため、RBACに関する知識を整理・まとめました。
現在、最も広く使われている権限管理モデルはRBAC(Role-Based Access Control)モデルです。この記事では主にRBACベースの権限管理システムについて紹介し、RBACとは何か、RBACをどのように設計するかの2つの部分に分けて説明します。
一、RBACとは
1、RBACモデルの概要
RBACモデル(Role-Based Access Control:ロールベースアクセス制御)は1990年代に研究された新しいモデルですが、実際には1970年代のマルチユーザーコンピューティングの時代にすでにこの考え方は提案されていました。1990年代後半になって、RBACは研究コミュニティで注目を集めるようになり、さまざまなタイプのRBACモデルが提案されました。中でも、アメリカのジョージ・メイソン大学情報セキュリティ技術研究所(LIST)が提案したRBAC96モデルが最も代表的で、広く認められています。
RBACでは、権限付与のプロセスは「Who は What に対して How のアクセス操作が可能か」という論理式の真偽を判定するプロセスとして抽象化できます。つまり、権限の問題をWho、What、Howの3つ組に変換するものです。具体的な理論はRBAC96の論文を参照してください。ここでは詳細には触れず、概要を把握していただければ十分です。
2、RBACの構成要素
RBACモデルには、ユーザー、ロール、権限の3つの基本構成要素があります。
RBACはロールに権限を定義し、ユーザーにロールを割り当てることでユーザーの権限を制御し、ユーザーと権限の論理的な分離を実現します(ACLモデルとは異なります)。これにより権限管理が大幅に容易になります。
以下、説明の前にいくつかの用語を紹介します。
- User(ユーザー):各ユーザーは一意のUIDを持ち、異なるロールが割り当てられます。
- Role(ロール):異なるロールは異なる権限を持ちます。
- Permission(権限):アクセス権限。
- ユーザー-ロールマッピング:ユーザーとロールのマッピング関係。
- ロール-権限マッピング:ロールと権限のマッピング。
これらの関係を下図に示します(ユーザー、ロール、権限の関係):

例えば下図のように、管理者と一般ユーザーには異なる権限が割り当てられます。一般ユーザーは自分の情報の変更と表示のみ可能で、ユーザーの作成や凍結はできません。一方、管理者はすべての権限が付与されているため、すべての操作が可能です。
例えば下図(ロール操作の例)のように、管理者と一般ユーザーには異なる権限が付与され、一般ユーザーは自分の情報の変更と表示のみ可能で、ユーザーの作成や凍結はできません。管理者はすべての権限が付与されているため、すべての操作が可能です。

3、RBACがサポートするセキュリティ原則
RBACは3つの有名なセキュリティ原則をサポートします:最小権限の原則、職務分離の原則、データ抽象の原則。
- 最小権限の原則:RBACはロールにタスク完了に必要な最小限の権限セットを設定できます。
- 職務分離の原則:互いに独立し排他的なロールを組み合わせて、機密性の高いタスクを共同で完了させることができます。例えば、会計係と財務管理者が共同で一括転記操作を行うなど。
- データ抽象の原則:権限の抽象化によって実現されます。例えば、財務操作では「借入」「預金」などの抽象的な権限を使用し、典型的な読み取り、書き込み、実行権限を使用しません。
4、RBACの長所と短所
(1)長所:
- ユーザーと権限の関係を簡素化
- 拡張性、保守性が高い
(2)短所:
RBACモデルには操作順序の制御メカニズムがなく、この欠点により、操作順序に厳格な要件があるシステムへの適用が難しい場合があります。
5、RBACの3つのモデル
(1)RBAC0
RBAC0は最もシンプルで原始的な実装方法であり、他のRBACモデルの基礎です。

このモデルでは、ユーザーとロールは多対多の関係を持つことができます。つまり、あるユーザーは異なるシナリオで異なるロールを持つことができます(例:プロジェクトマネージャーが同時にグループリーダーやアーキテクトを兼ねるなど)。また、各ロールは少なくとも1つの権限を持ちます。このモデルでは、ユーザーと権限が分離され、権限の認証がより柔軟になります。
(2)RBAC1
RBAC0モデルに基づき、ロール間の継承関係を導入します。つまり、ロールに上下関係が生まれます。

ロール間の継承関係は、一般的な継承関係と制限付き継承関係に分けられます。一般的な継承関係は、ロールの継承関係が絶対的な半順序関係であることのみを要求し、多段継承を許容します。制限付き継承関係はさらに、ロールの継承関係がツリー構造であることを要求し、単一継承を実現します。
このモデルは、ロール間の階層が明確で、ロールをグループ化・階層化できる場合に適しています。
(3)RBAC2
RBAC2は、RBAC0モデルに基づいてロールのアクセス制御を追加したものです。

RBAC2の基本的な制約の1つは、排他ロールの制約です。排他ロールとは、互いに権限を制約し合う2つのロールのことです。このようなロールに対して、あるユーザーは1つのアクティビティにおいてそのうちの1つのロールのみ割り当てられ、両方のロールの使用権を同時に取得することはできません。
このモデルには以下の制約があります:
- 排他ロール:同一ユーザーは、排他ロール集合の中から最大1つのロールのみ割り当てられます。職務分離の原則をサポートします。排他ロールとは、互いに権限を制約し合う2つのロールです。このようなロールに対して、あるユーザーは1つのアクティビティにおいてそのうちの1つのロールのみ割り当てられ、両方のロールの使用権を同時に取得することはできません。よく挙げられる例:監査活動において、あるロールが会計ロールと監査員ロールの両方を同時に割り当てられることはできません。
- 基数制約:ロールに割り当てられるユーザー数に制限がある。ユーザーが持つことのできるロール数に制限がある。同様に、ロールに対応するアクセス権限の数にも制限を設け、システム内での高権限の分配を制御します。例えば、会社のリーダーは限られています。
- 前提条件ロール:ユーザーがあらかじめ別のロールのメンバーである場合にのみ、ロールを割り当てることができる。同様に、ロールがすでに別のアクセス権限を持っている場合にのみ、新たなアクセス権限を割り当てることができる。より高い権限を得るには、まず下位の権限を持っている必要があることを意味します。現実生活で例えるなら、国家主席は副主席から選出されるようなものです。
- 実行時排他:例えば、あるユーザーが2つのロールのメンバーシップを持っていても、実行中にその2つのロールを同時にアクティブにすることはできない。
二、RBACの設計方法
このセクションでは、RBACモデルに基づく権限管理システムの機能モジュール構成、フロー、およびデータベース設計について説明します。
1、RBACの機能モジュール

2、RBACの実行フロー

3、RBACのデータベース設計
