権限制御の仕組み[ロールベースアクセスコントロール(RBAC)]
私が関わっている業務システムで、「この機能は、検査員しか使ってはいけない」など権限について考える必要があり、非常にわかりやすく解説されたサイトに出会いました。
ここでは、自分なりに考えをまとめたいと思います。詳しくは、次のサイトを参照していただくと良いと思います。 ネタ元:「業務システムにおけるロールベースアクセス制御」
ロールベースアクセスコントロール(RBAC)
アクセス制御というものを調べてみると、いくつかの種類があるようです。
- 任意アクセス制御(DAC)
- 強制アクセス制御(MAC)
- ロールベースアクセス制御(RBAC)
- 属性ベースアクセス制御(ABAC)
- アイデンティティベースアクセス制御(IBAC)
この中から、業務システムで使えるものとしてロールベースアクセス制御(RBAC)があります。 ロールベースアクセス制御(RBAC)は、大きく分けて「役割(ロール)」とある操作に対する「権限(パーミッション)」、役割が与えられる「人など(サブジェクト)」から構成されます。 上記関係をモデルにすると、次のようなイメージとなります。(Flat RBAC?)
ここで示したモデルは、基本的なモデルのようでNIST RBAC standardにはもう少し複雑なモデルについて解説されています。(the NIST model used in the standard.)
モデルで示される、「Subject」,「Role」,「Permission」は、次の関係となっています。
- Subject:人や自律エージェントで、複数のRole(役割)を持っている。
- Role:Permission(権限)のセットからなる。
- Permission:許可される操作のセットからなる。
具体的なRedmineでの使用例
「業務システムにおけるロールベースアクセス制御」で非常にわかりやすかったのが、具体的にRedmineでの使用例が示されていた事です。 業務上、Redmineを使用しているので理解しやすかったです。Redmineでは、1人のユーザを複数のプロジェクトへ異なるロールでアサインすることができるので、次のようなモデルになっています。
Redmineの場合、userテーブルがSubjectを表しており、プロジェクトとロール,ユーザー(Subject)をmembersテーブルとmember_rolesテーブルで関連付けています。
- membersテーブル:hogeプロジェクトにfugaユーザーをアサイン。
- member_rolesテーブル:アサインしたユーザに複数のロールを持たせることができる。
- rolesテーブル:権限は、permissions項目にカンマ区切りにて指定されている。
このような構造となっているため、ログインしたユーザーから役割(ロール)を検索し、その役割に許可された操作(パーミッション)を検索することが可能となります。