権限制御の仕組み

私が関わっている業務システムで、「この機能は、検査員しか使ってはいけない」など 権限について考える必要があり、非常にわかりやすく解説されたサイトに出会いました。

ここでは、自分なりに考えをまとめたいと思います。

詳しくは、次のサイトを参照していただくと良いと思います。

ネタ元:「業務システムにおけるロールベースアクセス制御

ロールベースアクセスコントロール(RBAC)

アクセス制御というものを調べてみると、いくつかの種類があるようです。

  • 任意アクセス制御(DAC)
  • 強制アクセス制御(MAC)
  • ロールベースアクセス制御(RBAC)
  • 属性ベースアクセス制御(ABAC)
  • アイデンティティベースアクセス制御(IBAC)

この中から、業務システムで使えるものとしてロールベースアクセス制御(RBAC)があります。

ロールベースアクセス制御(RBAC)は、大きく分けて「役割(ロール)」とある操作に対する「権限(パーミッション)」、 役割が与えられる「人など(サブジェクト)」から構成されます。

上記関係をモデルにすると、次のようなイメージとなります。(Flat RBAC?)

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のデーターモデル

Redmineの場合、userテーブルがSubjectを表しており、プロジェクトとロール,ユーザー(Subject)をmembersテーブルとmember_roles テーブルで関連付けています。

  • membersテーブル:hogeプロジェクトにfugaユーザーをアサイン。
  • member_rolesテーブル:アサインしたユーザに複数のロールを持たせることができる。
  • rolesテーブル:権限は、permissions項目にカンマ区切りにて指定されている。

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