ロールベースアクセス制御
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2023/12/28 08:43 UTC 版)
ロールベースアクセス制御（英: Role-based access control, RBAC）[1][2]は、認められたユーザーのシステムアクセスを制限するコンピュータセキュリティの手法の一種。強制アクセス制御 (MAC) や任意アクセス制御 (DAC) よりも新しい手法である。
概要
RBAC は、ポリシーを柔軟に設定できるアクセス制御法であって、任意アクセス制御 (DAC)[3]も強制アクセス制御 (MAC)[4]もシミュレート可能である。
RBAC が開発されるまで、アクセス制御法としては MAC と DAC しかなかった。従って、MAC を使っていないなら DAC を、DAC を使っていないなら MAC を使っていると思ってほぼ間違いなかった。90年代後半の研究では、RBAC はそのどちらにも分類されていない[要出典]。
組織において、「ロール（役割）」とは仕事上の機能を表す。ある操作を実行する許可（パーミッション）は、特定のロールに対して割り当てられる。各従業員には特定の（場合によっては複数の）ロールが割り当てられ、それによって特定のシステム機能を実行するパーミッションが与えられる。コンテキストベースアクセス制御 (CBAC) とは異なり、RBAC はメッセージのコンテキスト（コネクションがどこから起動されているかなど）を考慮しない。
ユーザーに対して直接パーミッションが与えられるわけではなく、ロールを通して与えられるため、各人のアクセス権の管理はユーザーへのロールの適切な割り当てに単純化され、ユーザーアカウントの追加やユーザーの部門間の異動などにも容易に対応できる。
RBAC は従来からあるアクセス制御手法であるアクセス制御リスト (ACL) とも異なる。ACL はデータオブジェクトについてアクセス権を設定するが、RBAC は組織内での意味を考慮して操作そのものにアクセス権を設定する。例えば、ACL は特定のシステムファイルへの書き込みを許可/拒否するが、そのファイルをどう変更すべきかは規定しない。一方 RBAC では、銀行口座の開設操作のパーミッションとか、血糖値検査結果を記録するパーミッションといった規定が可能である。すなわち、利用者にとって意味のある形式で細かくパーミッションを設定可能である。
ロール階層と制限の概念をあわせて採用すると、RBAC によってラティスベースアクセス制御 (LBAC) も構築できる。従って、RBAC は LBAC も包含していると見なすことができる。
RBACモデルを定義する場合、以下のような略記法が便利である。
- S = Subject = 個人または自律エージェント
- R = Role = 仕事上の機能、または権限レベルを定義するタイトル
- P = Permission = リソースへのアクセスモードの承認
- SE = Session = S、R、P のマッピング
- SA = Subject Assignment（Subject割り当て）
- PA = Permission Assignment（Permission割り当て）
- RH = Partially ordered role Hierarchy（半順序ロール階層）。≥ とも表記する。
- Subject は複数の Role を持つことができる。
- Role は複数の Subject に対応させることができる。
- Role は複数の Permission を持つことができる。
- Permisson は複数の Role に対応させることができる。
制限を置くことで、相反するロールを1人の個人が持つことがないようにする。つまり、職務の適切な分離を達成する。例えば、1人の個人がログインアカウントの作成とアカウント作成のための手続きが可能になっているのは適切ではない。
集合論的記法を使うと、次のようになる。
- PA ⊆ P × R - 多対多のパーミッションとロールの割り当て関係
- SA ⊆ S × R - 多対多の個人とロールの割り当て関係
- RH ⊆ R × R
x ≥ y と書いた場合、x が y のパーミッションを継承することを意味する。
ユーザー権限の管理をRBACで行うことは、ベストプラクティスとして単一システムやアプリケーションでは広く使われている手法である。マイクロソフトの Active Directory、SELinux、FreeBSD、Solaris、Oracle DBMS、PostgreSQL 8.1、SAP R/3 などで RBAC が何らかの形で実装されている。
異機種混在型のIT基盤のある大きな組織では、ロールを階層化しないとRBACを全体で運用することは非常に複雑で困難となる。このような大規模な権限設定についての戦略は、Beyond Roles: A Practical Approach to Enterprise User Provisioning で論じられている。RBAC の企業全体への展開の問題に対処するため、NISTモデル[5]を拡張した新たなシステムもある。このテーマの研究論文はいくつかあり、商用システムでこれを実装した Beyond NIST がある。
関連項目
- アクセス制御 - ロールベースアクセス制御
- 認証
- grsecurity
脚注
- ^ Ferraiolo, D.F. and Kuhn, D.R. (1992年10月). "Role Based Access Control" (PDF). 15th National Computer Security Conference. pp. 554–563.
- ^ Sandhu, R., Coyne, E.J., Feinstein, H.L. and Youman, C.E. (1996年8月). "Role-Based Access Control Models" (PDF). IEEE Computer. IEEE Press. 29 (2): 38–47.
- ^ Ravi Sandhu, Qamar Munawer (1998年10月). "How to do discretionary access control using roles". 3rd ACM Workshop on Role-Based Access Control. pp. 47–54.
- ^ Sylvia Osborn, Ravi Sandhu, and Qamar Munawer (2000年). "Configuring role-based access control to enforce mandatory and discretionary access control policies". ACM Transactions on Information and System Security (TISSEC). pp. 85–106.
- ^ Sandhu, R., Ferraiolo, D.F. and Kuhn, D.R. (2000年7月). "The NIST Model for Role Based Access Control: Toward a Unified Standard". 5th ACM Workshop Role-Based Access Control. pp. 47–63.
外部リンク
ロールベースアクセス制御
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2011/01/24 19:29 UTC 版)
「grsecurity」の記事における「ロールベースアクセス制御」の解説
grsecurity には、完全なロールベースアクセス制御 (RBAC) システムを提供するコンポーネントも含まれる。RBAC は従来のUNIXのアクセス制御リストよりも厳密なアクセス制限が可能で、完全な最小権限システム（ユーザーやプロセスが動作に必要な最小限の権限のみを持ち、余分な権限を持たせないシステム）を構築する基礎となる。これにより、攻撃者がシステムの機密情報を入手または破壊する可能性は劇的に削減できる。RBAC は「役割(role)」の集合を通して動作する。各役割には何ができて何ができないかという制限を個々に設定でき、これによってポリシーが形成される（ポリシーは修正可能）。
※この「ロールベースアクセス制御」の解説は、「grsecurity」の解説の一部です。
「ロールベースアクセス制御」を含む「grsecurity」の記事については、「grsecurity」の概要を参照ください。
- ロールベースアクセス制御のページへのリンク
