ロールベースアクセス制御の概要説明
この記事で述べること
- 参考資料に基づき、ロールベースアクセス制御の概念を説明する。
- 参考資料: Microsoft Word - BSR+INCITS+359.doc
モチベーション
- 開発の仕事で実装することになったロールベースアクセス制御を理解するため。
対象読者
- ロールベースアクセス制御の概要を図解でさっと知りたい人
- システム開発者で、アクセス制御を判定フラグで実装しているが、他により良い方法を探している人。
ロールベースアクセス制御とは
基本的な概念
ロールベースアクセス制御（以降 RBAC）とはリソースへのアクセス制御方法の一つである。
ユーザとアクセス対象（システムリソース）へのアクセスパーミッション（権限）をロール（役割）を介して関連付ける。
ユーザがシステムリソースにアクセス可能であるかは、ユーザが関連付けされているロールがそのシステムリソースへのアクセスパーミッションを保持しているかで判定する。
ロールとは、会社組織で例えると役職のことである。
会社のリソースを閲覧する権限は、人そのものではなく、役職に関連付けられる。
例えば、Aさんは部長のため担当部署の機密書類の閲覧権限がある。しかしAさんが係長に降格となった場合、彼はその書類の閲覧権限がなくなる。その書類の閲覧権限は部長というロールに関連づいており、係長のロールには関連付けられていないためである。
RBACの要素
参考資料: Microsoft Word - BSR+INCITS+359.doc Figure 1: Core RBAC
RBACの構成要素
| 要素 | |
|---|---|
| Users | アクセスユーザ。 |
| Objects (OBS) | アクセス対象のオブジェクト。 「特定のシステムデータ」「機能A」など、その粒度は様々である。 また、粒度によってRBACの関連付けの管理の複雑さが変わる（後述）。 |
| Operations (OPS) | アクセス対象への操作。 作成、閲覧、編集、削除など。 |
| Permissions | アクセス対象への操作権限。 OBSとOPSの組み合わせで表現される。 機能Aの作成、機能Aの削除、など。 |
| Roles | ある意味を持つグルーピングされた1つ以上のPermissionと、そのPermissionを持つことが許可されたUserとの多対多の関係性に付ける名前。 平たく言うと役職のこと。 |
| User Assignment (UA) | Roleに割り当てられたUserの静的なマッピング情報。 |
| Permission Assignment (PA) | Roleに割り当てられたPermissionの静的なマッピング情報。 |
| SESSION | User Assignmentのうち、関連付けが活性化された状態、またはそのつながり（後述）。 |
| user_sessions | User-Sessionの関連付けのマッピング情報。 |
| sessions_roles | Session-Roleの関連付けのマッピング情報。 |
各要素は図で示したように以下の関係を持つ。
| 要素 | |
|---|---|
| Users:Roles | 多対多 |
| Roles:Permissons | 多対多 |
| Operations:Objects | 多対多 |
| Operations-Objects | Permission |
| Users:Sessions | 1対多 |
| Sessions:Roles | 多対多 |
- 一人で複数の部の部長を兼任する。
- 一般社員というロールには一人以上の人が関連付けられる。
- 部署Aの書類は部長Aも一般社員Aも閲覧する権限がある。
- 書類Aの閲覧権限、書類Aの編集権限、オフィスAへの入室権限など。
Sessionの概念
参考資料: アクセス制御機構を有するセキュア WebDAV の開発 電子政府等の大規模組織に適したドキュメント共有・協調編集システム
Sessionとはなにか
Sessionとは、RBACの採用されたシステムにおけるUserの行動単位である。RBACが採用されたシステムを利用するには、Userはまずシステムに対するSessionを確立させる必要がある。これはシステムへのログインを通して実施される。
User1はSession1でログインしている。User1はSession2でログインしていない。User2はSession3でログインしていない。
sessions_rolesマッピング
ログイン後、システムはUserの行動単位であるSessionに対してUAマッピング情報から動的にロールをアサインする必要がある。
UA- UA1:
User1 = { Role1, Role2, Role3 } - UA2:
User2 = { Role2, Role3 }
- UA1:
sessions_roles
Sessionの活性・非活性
アサインしたsessions_rolesの関連付けには、システムの仕様に基づき適切な活性状態のステータスを設定する。
- sessions_roles1:
Session1 - Role1を活性化。 - sessions_roles1:
Session1 - Role2を非活性化。 - sessions_roles2:
Session2 - Role3を非活性化。 - sessions_roles3:
Session3 - Role2を非活性化。 - sessions_roles3:
Session3 - Role3を非活性化。
アクセス判定
アサインされたsessions_rolesのアクティブな関連付けであるSession-Role-Permissionを用いることにより、Sessionがその機能へアクセスできるかを判定する。
User1はSession1でログインし、Permission1、Permission2が設定されている機能にアクセスができる。User1はSession2でログインしていないため、Permission3、Permission4が設定されている機能にはアクセスができない。
sessions_rolesのロールはどのようにアサインされるのか
確立されたSessionにはUAマッピング情報から任意のロールをアサインするが、そのルールはシステムのコンセプトにより様々である。なぜそのようにSessionへの動的アサインをするように定義されているか。そのメリットをイメージできるように、（おそらくは近いことをしていると思われる）AWSのスイッチロールを例として挙げてみる。
リンク先で説明されているが、簡単に説明する。
AWSでは、任意の作成ロールへ任意の組み合わせの権限のセットを付与できる。
また、IAM機能で作成されたIAMユーザでログイン時にはデフォルトで一連のアクセス許可が付与されているが、このログインIAMユーザのロールを、作成ロールに切り替えることができる。
図5の状態では、ログインIAMユーザはIAM機能のみ使うことができる。
切り替えタイミングは任意である。切り替えた後はデフォルトのアクセス件が一時的に無効となり、切り替え後のロールに割り当てられたアクセス権限が有効になる。
図6の状態では、ログインIAMユーザはS3、EC2のみ使うことができる。IAM機能は一時的に使えなくなっている。
AWSのように膨大な機能が存在するシステムにおいては、意図的に使える機能やリソースを切り替えることは、実行してはならない操作ミスを防ぐ意味で有効である。
SSD: 静的な義務関係の分離
参考資料: Microsoft Word - BSR+INCITS+359.doc Figure 3: SSD within Hierarchical RBAC
システムにとって利益相反となる権限を持つロールの組み合わせを、一人のUserに関連付けられないようにする仕組みのこと。制限チェックはユーザ新規登録時のUAマッピング時に行う。
一例として、「R市の補助金申請・支払いシステム」を考えてみる。
前提として、法律の事実関係は考えないものとする。また、ロールはあくまでもシステム内のみで使われるものであるとする。
| User | 支払いシステムにおけるRole | Permission | |
|---|---|---|---|
| A | R市民 | Citizen | 補助金の申請 |
| B | R市民、かつR市役所の補助金担当職員 | Citizen, Grants-staff | 補助金の申請、申請チェックと補助金の支払い |
AさんとBさんは二人ともR市民のため、R市役所に補助金申請を出すことができる。
また、BさんはR市役所の補助金担当職員でもあるため、補助金の支払いができる。
Aさんは申請しかできないが、Bさんは自分で申請しつつ自分で支払うことができるということだ。システムにとっては申請チェックが一部機能していないことになる。
このように、一人のUserへ割り当てるロールの種類によってはシステムが機能しなくなる。これを防ぐためには、システムでユーザ登録してロールを割り当てる時にRole: CitizenとRole:Grants-staffを同時に選べないように制限すればよい。（R市の補助金申請・支払いという限られたシステムの中では）UserはCitizenかGrants-staffのどちらかのロールしか持てないことによって、システム内の利益相反を防ぐことができる。
制御処理には以下2つの情報が必要となる。
- 防ぎたい組み合わせのロールの集合（2つ以上）
- 防ぎたい組み合わせのロールの集合から、一人の
Userにアサインして良いロールの最大数
上記を組み合わせ、以下のようなUAのマッピング制限ポリシーを定義できる。
ロール集合 { Citizen, Grants-staff }から、2つ以上のロールを一人のUserにアサインしてはならない。
アクセス制御対象（Object）の粒度の選定
RBACは、Object（アクセス対象）をなにに設定するかによってシステムの複雑さが大幅に変わる。
機能単位とシステムデータ単位の2つの例で、RBACの関連付け管理がどれくらい変わるのかを比較してみる。
Object=機能単位のアクセス制御
Objectの粒度を「機能」単位とする場合の要素と要素間関連付けをシミュレーションしてみる。
| 要素 | 粒度 | 例 | |
|---|---|---|---|
| Role | 役割 | 管理者、マネージャー、一般社員 | 静的 |
| Object | 機能 | システム管理、投稿データ管理 | 静的 |
| Operation | 操作 | 取得、新規登録、更新、削除 | 静的 |
Userの新規登録
Role: 一般社員のUserを1名新規登録する場合。
必要な登録処理は以下となる。
Userを1レコード登録。UAマッピングの関連付けを1つ登録。
Object=システムデータ単位のアクセス制御
Objectの粒度を、DBの「登録レコード」単位とする場合の要素と要素間関連付けをシミュレーションしてみる。
| 要素 | 粒度 | 例 | |
|---|---|---|---|
| Role | 役割 | 管理者、マネージャー1、一般社員1、一般社員2、... | 動的 |
| Object | 機能 | システム管理レコード1、システム管理レコード2、...、投稿データ管理レコード1, 投稿データ管理レコード2, ... | 動的 |
| Operation | 操作 | 取得、新規登録、更新、削除 | 静的 |
登録レコード単位のため、Permissionは「登録されたレコード1への取得権限」「登録されたレコード1への更新権限」...というように、登録レコード一つ一つに対する権限となる。
また、Roleの粒度も変わり、「登録されたレコード1への取得権限」「登録されたレコード1への更新権限」を持つロール1、「登録されたレコード2への取得権限」「登録されたレコード2への更新権限」を持つロール2、...というように、登録されたユーザごとに増えていく。
Userの新規登録
Role: 一般社員のUserを1名新規登録する場合。
必要な登録処理は以下となる。
Userを1レコード登録。Roleを1レコード登録。UAマッピングの関連付けを複数登録。関連付けは、他のRole: General{n}がどのロールと関連付けを持っているのかによって変わる。Permission Assignment (PA)マッピングの関連付けを複数登録。関連付けは、他のRole: General{n}がどの権限と関連付けを持っているのかによって変わる。
投稿データの登録
Role: 一般社員のUserが投稿データを1つ登録する場合。
必要な登録処理は以下となる。
Permissionを3レコード登録。（Post.id=789への取得・更新・削除権限）Permission Assignment (PA)マッピングの関連付けを複数登録。関連付けは、他のRole: General{n}がどの権限と関連付けを持っているのかによって変わる。
比較まとめ
機能単位のアクセス制御に比べ、システムデータ単位のアクセス制御のほうが大幅にUser-Role-Permissionの要素と関連付け管理が複雑になる。また、複雑になった分だけ、細かいアクセス制御が可能となる。
RBAC以外のアクセス制御方法
RBACをシステムのアクセス制御に採用するための比較検討材料として、任意アクセス制御をピックアップ。
任意アクセス制御（DAC：Discretionary Access Control）
Objectの登録ユーザが、そのシステムデータにアクセスしてくるユーザの属性（オーナー、グループ、その他など）それぞれに対して何ができるか（Read, Write, Execute）を決める方式。Unix が採用している。
| 関係性 | |
|---|---|
OWNER |
システム登録ユーザ = アクセスユーザ |
GROUP |
システム登録ユーザ = アクセスユーザと同じグループの一員 |
OTHER |
それ以外 |
図14の場合、関連性がGROUPのユーザは{ read: on, write: off, execute: off }読み書きはOKで実行は不可となる。
システムデータそれぞれにPermission: rwxrwxrwxを設定する必要がある。
また、GROUPという概念をアクセス制御の外で用意しなくてはならない。
RBACとの比較
DACはアクセス対象のシステムデータ側に権限情報を保持して管理するため、関連付けという概念はない。そのため、複雑な要素間の関連付け管理がキーとなるRBACと比べてシンプルな管理となる。その分、アクセス機構の外にグループという概念が必要となる。また、実際のシステム構築時は、システムデータの権限管理を効率化するためのなんらかの工夫がいるだろう。
まとめ
後日記載予定。
