権限制御の仕組み[ロールベースアクセスコントロール(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項目にカンマ区切りにて指定されている。

このような構造となっているため、ログインしたユーザーから役割(ロール)を検索し、その役割に許可された操作(パーミッション)を検索することが可能となります。