Skip to content

Role Based Access Control RBAC

以下の翻訳です。
https://csrc.nist.gov/projects/role-based-access-control/faqs

What Is Role Based Access Control?

役割ごとに異なる権限や責任があるという考え方は、古くから企業組織で認識されており、少なくとも1970年代までさかのぼる商用コンピュータアプリケーションでは、組織内における利用者の役割に基づく限定的なアクセス制約が実装されていました。こうした role-based system は比較的単純で、アプリケーションごとに個別に作られていました。つまり、アクセス制御をどのように役割に基づいて行うかを定義する汎用モデルは存在せず、これらの system の安全性についての形式的な分析もほとんどありませんでした。これらの system はさまざまな組織によって開発されましたが、共通に合意された定義も、正式な標準における認知もありませんでした。

汎用的な role based access control model は、1992年に Ferraiolo と Kuhn によって提案され、既存のアプリケーション固有の手法の特徴を統合して、一般化された role based access control model としたものです。この論文では、RBAC を従来の Mandatory Access Control (MAC) および Discretionary Access Control (DAC) の代替として提示し、集合、関係、写像という観点からの形式的記述により、roles と role hierarchy、subject による role activation、subject-object mediation、さらに user/role membership と role set activation に対する制約を定義しました。そこでは、次の3つの基本ルールが必要とされました。

  1. Role assignment: subject は、自身が role を選択したか、または role を割り当てられている場合にのみ transaction を実行できます。識別および認証の過程（たとえば login）は transaction とは見なされません。それ以外の system 上のすべての user 活動は transaction を通じて行われます。したがって、すべての active user には何らかの active role が必要です。
  2. Role authorization: subject の active role は、その subject に対して認可されていなければなりません。上記の (1) と合わせることで、このルールは、user が自分に認可された roles のみを担えることを保証します。
  3. Transaction authorization: subject は、その transaction が subject の role membership を通じて認可されており、かつ users、roles、permissions 全体に適用されうる制約に従う場合にのみ transaction を実行できます。(1) および (2) と合わせることで、このルールは、user が自分に認可された transaction のみを実行できることを保証します。

この model の重要な特徴は、すべての access が roles を通じて行われることです。role とは本質的には permissions の集合であり、すべての users は、自分に割り当てられた roles、または role hierarchy を通じて継承した roles からのみ permissions を受け取ります。組織内では、roles は比較的安定していますが、users と permissions はいずれも数が多く、しかも急速に変化する可能性があります。したがって、すべての access を roles を通じて制御することで、アクセス制御の管理と見直しが簡素化されます。1992年の Ferraiolo と Kuhn の model は、1995年に Ferraiolo、Cugini、Kuhn によって拡張されました。

1996年には、Sandhu、Coyne、Feinstein、Youman が、上記の RBAC の特徴をモジュール構成で取り込んだ RBAC model framework を導入しました。RBAC0 は、users、roles、permissions によって定義される基本 model とされました。RBAC1 は RBAC0 を含みつつ、roles 間の部分順序関係として hierarchy を取り入れます。RBAC2 も RBAC0 を含みますが、さらに制約を追加します。RBAC1 と RBAC2 は互いに独立しており、system は一方のみを実装することもできます。RBAC3 は、RBAC0、RBAC1、RBAC2 を取り込んだ完全機能の RBAC model です。RBAC3 は本質的には 1992 年の Ferraiolo と Kuhn の model と等価ですが、RBAC3 が部分順序による hierarchy を許すのに対し、Ferraiolo-Kuhn model では hierarchy を rooted tree として定義している点が異なります。object-oriented の用語で言えば、1996年の SCFY model は multiple inheritance を取り込んでいると考えられるのに対し、Ferraiolo-Kuhn は single inheritance を用いています。

How Are Roles Different From Groups?

RBAC の roles と従来の groups には表面的な類似があります。通常の実装では、group は permissions の集合ではなく users の集合であり、permissions は users にも、その user が属する groups にも関連付けることができます。group-based mechanism では、permissions を直接 user に結び付けられるため、それは user-permission relationship の制御を難しくする「抜け道」と見なすことができます。RBAC では、すべての access は roles を通じて行われ、permissions は roles にのみ結び付けられ、users に直接結び付けられることはありません。RBAC を従来の group mechanism と区別するもう一つの点は、session という概念です。これにより、user に割り当てられた roles の一部のみを有効化できます。Core RBAC には、users と permissions の間に多対多の関係を構築できる堅牢な group/ACL mechanism を備えた system が含まれます。

What Is The Relationship Between RBAC, MAC, And DAC?

RBAC は MAC や DAC とは別個で独立した model ですが、いくつかの関係が明らかになっています。特に、RBAC が MAC と DAC を模倣できること、および role hierarchy が部分順序ではなく tree である場合には、MAC を使って RBAC を実装できることが示されています。

What About Complex Relationships And Constraints?

RBAC は「separation of duty」の要件を扱うのに適しており、実際、その点を念頭に置いて設計されました。このサイトには SoD を扱う論文がいくつか含まれており、RBAC standard でもこの話題が広く扱われています（下の「What Is The RBAC Standard?」を参照）。

また、RBAC が他の関係性にどの程度適しているのかについても疑問が提起されてきました。たとえば、2008年の RBAC standard に関する議論には、次のような懸念が含まれています。

しかし、doctor である Dr. X が特定の患者 Patient Y の medical chart を電子的に閲覧するためには、単に "Doctor" role を持っているだけでは足りず、Patient Y に対する関係において "Attending Doctor" role も必要です。言い換えると、medical chart に対する Access Control は、Dr. X と Patient Y の間に確立された特定の relationship に基づいており、それは relationship-based role として表現できるでしょう。

この種の状況は、1992年の RBAC model において明示的に扱われていました。この model では、role 要件が満たされた場合に access を与える条件を 'if' や 'if and only if' ではなく、'only if' としています（これは極めて重要な違いです）。これは、access 時に追加の制約を加えられるようにするためでした。追加の制約をどのように処理するかについての実装詳細は指定されていませんでした。なぜなら、それらはアプリケーションや制約の種類によって大きく異なるからです。RBAC standard も 1992 年の model と同様に、設計者がこうした relationship を扱うための制約を追加できるように設計されています。言い換えれば、RBAC model には、そうした制約の追加を妨げるものは何もありません。community に十分な関心があり、かつ多様な industry に対応できる十分に一般的な mechanism が存在するならば、上記のような relationship を扱う手段を追加する形で standard を改訂することも可能です。

What Is The RBAC Standard?

2000年に NIST は、Ferraiolo-Kuhn の 1992 年 model と、1996年に Sandhu らが導入した RBAC framework を統合した、統一的な RBAC standard を提唱しました。この提案は Sandhu、Ferraiolo、Kuhn によって公表され、ACM 5th Workshop on Role Based Access Control で発表されました。RBAC および security community の中で議論とコメントを経た後、NIST は改訂を行い、米国における情報通信技術標準化の主要機関である International Committee for Information Technology Standards (INCITS) を通じて、RBAC の米国国家標準を提案しました。INCITS は、国際レベルで IT の標準化を担う ISO/IEC Joint Technical Committee 1 に対する American National Standards Institute (ANSI) の Technical Advisory Group でもあります。2004年、この standard は投票による承認を得て、INCITS 359-2004 として採択されました。

Standard Structure

standard は2つの部分から成ります。

  • Reference Model。これは4つの model component、すなわち Core RBAC、Hierarchical RBAC、Static Separation of Duty Relations、Dynamic Separation of Duty Relations の集合として定義されます。これらの Model component は、RBAC の機能を定義するための標準的な用語体系を提供します。
  • これらの model component の functional specification。

Component summary

  • Core RBAC は、Role-Based Access Control system を完全に実現するために必要な最小限の RBAC elements、element sets、relations を定義します。これには、どの RBAC system においても基本と見なされる user-role assignment と permission-role assignment の関係が含まれます。さらに Core RBAC は、コンピュータ system 内における user の session の一部としての role activation の概念を導入します。Core RBAC はすべての RBAC system に必須ですが、他の component は互いに独立しており、別々に実装することができます。
  • Hierarchical RBAC は、role hierarchy を支えるための関係を追加します。Hierarchical RBAC は、単純な user と permission の role assignment を超えて、ある role に認可された users の集合、および認可された permissions の集合という概念を導入します。
  • Static Separation of Duty Relations は、user assignment に関する roles 間の関係を追加します。static separation of duty relation と role hierarchy の継承関係との間に不整合が生じうるため、SSD relations の model component は、role hierarchy がある場合とない場合の両方について関係を定義します。
  • 第4の model component である Dynamic Separation of Duty Relations は、user の session の一部として有効化された roles に関する関係を定義します。

What Theoretical Results Have Been Established?

1990年代以降、RBAC のあらゆる側面に関して広範な学術研究が公表されてきました。2006年時点で、Google Scholar には RBAC のさまざまな側面に関する 6,000 本を超える論文が掲載されています。初期の成果の一部を以下に示します。

RBAC MODEL

  • Ferraiolo と Kuhn (1992) は、permissions の集合としての roles、role hierarchy、subject-role activation、subject-object mediation、さらに user/role membership と role activation に対する制約について、形式的定義を与えました。
  • Nyanchama と Osborn (1994) は、RBAC のための role graph model を開発し、role 関係を分析する効率的な algorithm を提供しました。
  • Ferraiolo、Kuhn、およびその同僚たちは RBAC の prototype implementation を開発し、1995年の論文で static と dynamic の separation of duty を形式的に定義することで RBAC model をさらに発展させました。
  • Sandhu、Coyne、Feinstein、Youman (1996) は、複数の概念 model に RBAC を分解し、それらを組み合わせることで多様な RBAC system を提供できる RBAC models の framework を導入しました。

RELATIONSHIP BETWEEN RBAC, MAC, AND DAC

  • Sandhu (1996) は、RBAC を使って従来の multilevel security policy を実装できることを示しました。
  • Osborn (1997) は、multilevel security と RBAC の両方を支える system において成立しなければならない role lemma を提示しました。
  • Kuhn (1998) は、role hierarchy が部分順序ではなく tree である場合、multilevel-secure system が RBAC を実装できることを示しました。
  • Sandhu と Munawer (1998) は、RBAC を用いて discretionary access control を実装する方法を示しました。

SEPARATION OF DUTY

  • Kuhn (1997) は、RBAC の separation of duty における safety を確保するための必要十分条件に関する定理を示しました。
  • Li、Bizri、Tripunitara (2004) は、Kuhn, 1997 の成果を拡張しました。

What is the history of the RBAC systems used today?

今日使われている role based access control の原始的な形態は、1970年代から多くの system 上でさまざまな ad hoc な形で実装されてきました。今日使われている RBAC は、Ferraiolo と Kuhn (1992) によって提案された model と、Sandhu、Coyne、Feinstein、Youman (1996) の model framework に由来します。以下の timeline は、今日の RBAC の進化をたどったものです。

  • 1992 – roles のみを通じた access、hierarchy、制約を備えた RBAC を定義した Ferraiolo と Kuhn の論文。形式 model を提示。
  • 1994 – Ferraiolo、Kuhn、Gavrila によって DTOS ベースの RBAC prototype が開発される。
  • 1994 – Nyanchama と Osborn の論文が role graph model を定義。
  • 1994 – IBM が（ヨーロッパで）RBAC 分野における最初の patent application を提出し、Ferraiolo と Kuhn の研究を “closest prior art” として引用。
  • 1995 – Ferraiolo、Cugini、Kuhn が形式 model を拡張し、separation of duty の形態を定義。
  • 1996 – Sandhu、Coyne、Feinstein、Youman による RBAC models の family に関する論文。
  • 1996 – Sandhu が RBAC system 上で MAC を実装する方法を提示。
  • 1997-1998 – Sybase、Secure Computing、Siemens が、Ferraiolo-Kuhn RBAC model に直接基づくと説明される RBAC 製品を発表。
  • 1997 – Secure Computing が Ferraiolo-Kuhn RBAC model を US DoD Global Command and Control System に組み込む。
  • 1997 – Kuhn が separation of duty に関する論文を発表し、separation safety の必要十分条件を提示。
  • 1997 – Osborn が RBAC と multilevel security mandatory access (MLS/MAC) security policy model の関係に関する論文を発表し、RBAC と multilevel security を結びつける role lemma を提示。
  • 1997 – Ferraiolo と Barkley が RBAC の経済的利点に関する論文を発表。
  • 1998 – Kuhn が MAC system 上で RBAC を実装する方法を提示。
  • 1999 – Barkley、Ferraiolo、Kuhn、Cincotta により、web server 向けの open source RBAC prototype が開発される。
  • 2000 – Sandhu、Ferraiolo、Kuhn が統一 RBAC model を定義し、RBAC standard を提案する論文を発表。
  • 2004 – American National Standards Institute, International Committee for Information Technology Standards (ANSI/INCITS) が、Sandhu、Ferraiolo、Kuhn による RBAC proposal を industry consensus standard として採択。