1はじめエディタ
最小特権のデータ抽象化と原則、職務の分離の原則：RBACは3既知のセキュリティの原則をサポートしています。
タスクを完了するために必要なアクセス許可のセットの役割を最小化するように構成することができるので、（1）最小権限の原則は、RBACによってサポートされている理由は、RBACです。
（2）職務の分離の原則は、財務会計のスタッフを必要とし、管理者が同じ投稿に関与していたとして、敏感なタスクを完了するために一緒に独立した相互排他的な役割を呼び出すことによって実施することができます。
（3）データの抽象化は、オペレーティング・システムは、典型的なリードを提供し、書き込み、および実行権限をするのではなく、等抽象権限ローンと金融業務、預金として抽象的権利、によって実施することができます。しかしながら、これらの原則は、各コンポーネントに詳細RBAC構成によって反映されなければなりません。
多面的なRBACの管理を行う多くのRBAC部材（BUCU）。役割と権限を割り当てる;継承の役割を定義することで役割と役割を割り当てる割り当てるユーザーとロールを：特に、我々は議論するために、これらの問題を分割したいです。これらの活動は、リンクされたユーザーと権限が必要です。しかし、彼らは最高の異なる管理者や、多くの場合、管理者の役割によって行われます。これは、役割の割り当ての権限典型的なアプリケーションマネージャの責任です。ローンの運用管理者の役割を承認する権限を割り当てるにはキャッシャーの役割を堆積させるために、操作権限を借入金を割り当てるには銀行業務アプリケーション、。そして、レジやマネージャ役割の適切な役割に割り当てられた特定の担当者が人事管理の範疇です。役割と役割の割り当ては、ユーザーとロールの割り当ての割り当て、役割と機能のいくつかの権限が含まれています。より一般的には、役割と役割の関係は、より広範な戦略を反映しています。
編集の基本概念2
RBACは、実際に誰が、何を、どのように問題認可と思います。RBACモデルでは、誰が、何を、アクセス権は、トライアド、すなわち構成する方法「（どの）はどのように動作するどのようなのを。」
誰：によって所有権個人または団体（など主、ユーザー、グループ、役割、俳優、など）
何：オブジェクトまたはリソースに対するアクセス権（リソース、クラス）。
方法：特定の権限（特権、正と負の認可承認）。
演算子：操作。どのような動作する方法を示しています。これは、特権+リソースで
役割：役割、一定数のアクセス権のコレクション。権利割当部とサポート、目的のユーザーと特権の分離ロジック。
キャリア群を持つユーザー単位、権限が割り当てられた：グループ。権限は、特定のユーザとグループに割り当てるとは見なされません。グループは、ユーザーのグループは、グループ内の権限を継承し、またユーザーが含まれていてもよい、（相続権を達成するために）基を含んでもよいです。ユーザーとグループは、多くの関係に多くのです。当社グループは、アクセス制御の異なるレベルの要件を満たすために、階層化することができます。
焦点は、RBACの役割、およびユーザーのアクセス権との関係にあります。ユーザーの割り当て（UA）とパーミッションの割り当て（PA）と呼ばれる。左右の関係多対多の関係です。つまり、ユーザが複数の役割を持つことができるされ、役割は、ユーザの複数を含んでもよいです。
我々は、RDBMSを使用するかを知る、N：Mの関係は、2つのテーブル間の関係を保持する中間テーブルを必要とします。このUAとPAは、中間テーブルに相当します。実際には、全体のRBACは、リレーショナルモデルに基づいています。
セッションは、RBACでは比較的あいまいな要素です。標準は言った：各セッションのマッピング、より多くの役割へのマッピングユーザーです。ユーザーは、彼のすべての文字のサブセット、セッションの確立を起動すると。セッションおよび各個々のユーザに関連付けられ、各ユーザは、1つまたは複数のセッションに関連付けることができます。
RBACシステムでは、ユーザーは、このアイデアは、ビジネス・モデリング、UMLで予約アクター - ロールモデルから来て、俳優のユーザーを置き換えるために使用することができる役割（ロール）を再生し、実際にあります。人々が同じ権限を持つことができます考慮すると、RBACは、グループの概念を導入しています。グループはまた、俳優として見られています。人へのコンクリート上のユーザの概念。
ここではグループGBAC異なる（グループベースのアクセス制御）・グループ（グループ）インチ GBACは、オペレーティングシステムのために使用しました。これでグループが直接および関連する権利は、実際にはRBACもGBAC概念の一部に描画します。
ユーザグループとすべての関連機関や団体ではなく、組織。どちらも概念的に異なります。組織構造は、部署、人、仕事、などなど、会社の物理的な存在の抽象モデルであり、およびアクセス許可モデルは、抽象化の記述です。構造は、一般的にモデル化や責任のパーティーモードマーティン・ファウラーします。
関係パーティーモード者とユーザー、および各人のユーザーに対応することが、すべてではなく、ユーザーのは、対応する人物であってもよいです。組織パーティーでの部署の部門や組織は、グループに対応してもよいです。逆に、グループは、必ずしも実際の機構に対応していません。例えば、同一の業務以上であるグループの副管理者が存在してもよいです。
この概念を紹介するグループ、マルチプレイヤーの役割に加えて、同じ問題を解決するために、だけでなく、問題に別の認可組織を解決するためには：例えば、部門のニュースは、私はすべての人がA部門を見ることができることを願っています。こうした部門に対応するグループが、直接、グループに付与することができます。[1]
3モデルエディタ
RBAC96モデル
1、基本モデルRBAC0モデル
定義：RBAC0モデルは、以下の記述から決定されます。
U、R、P、Sはユーザの集合、ロールのセット、および許可設定セッションコレクションを示します。
PA P×Rは、割り当てられた役割と権限、多くの関係を表しています。
UA U×Rは、ユーザと割り当てられたロールの間で多くの関係を示します。
ユーザー：S→UシングルユーザユーザーSI（SI）マッピング関数に各セッション（ライフサイクル定数がセッションを表します）。
役割：S→2文字サブセットSIロールに各セッション（SI）{R |ユーザー（SI、R「）∈UA}（経時的に変化することができる）マッピング関数の、セッション許可Ur∈rolesがSI（SI ）{P |（P、R「）∈PA}。
RBAC0モデルを使用するときは、それぞれ、すべてのユーザーのために許可を求める必要があり、少なくともロールに割り当てる必要があります。パーミッション二つの役割は正確に可能性として割り当てられているが、それでも2つの完全に独立した役割は、ユーザーが似たような状況があります。適切な役割は、正式なアクセス制御ポリシーの基本である、意味構造として見ることができます。
その正確な意味は、唯一の決定および関連システムによって達成することができるので、RBAC0許可処理は、シンボルの非解釈ではありません。RBAC0許可は、データとリソース・オブジェクトに適用することができるが、モデル自体の構成要素には適用できません。修飾されたU、権限R、Pのセット、及び後述する著作権管理と呼ばUAとPAとの間の関係、RBAC管理モデル。したがって、RBAC0で唯一のセキュリティ管理者は、これらのコンポーネントを変更することができると仮定しました。
セッションは、モデル内の単一のユーザーによって制御され、ユーザーがセッションを作成することができ、かつユーザーの選択の役割を活性化する特定のサブセットがあります。セッションを終了するには、ユーザーの意思決定によってセッションの活性化における役割は、ユーザによって開始されます。RBAC0は、セッションはユーザーのみで作成することができ、セッションの別のセッションを作成することはできません。
2、階層的なロールモデルRBAC1
定義：以下によって決定RBAC1
U、R、P、Sはユーザの集合、ロールのセット、および許可設定セッションコレクションを示します。
PA P×Rは、割り当てられた役割と権限、多くの関係を表しています。
UA U×Rは、ユーザと割り当てられたロールの間で多くの関係を示します。
RH R×R Rの文字レベルまたは支配的な役割関係と呼ばれる半順序関係、≥表記法を使用することも可能です。
ユーザー：S→UシングルユーザユーザーSI（SI）マッピング関数に各セッション（ライフサイクル定数がセッションを表します）。
役割：文字サブセットSIロール（SI）{R |（r'≥r）ユーザ（SI、R「）∈UA]}にS→2各セッションマッピング関数の（経時的に変化することができる）、セッションSIそこ許可Ur∈roles（SI）{P |（r''≤r）[（P、R ''）∈PA]}。
3
、
制限モデルRBAC2
RBAC2モデルは限界RBAC0モデルを増大させるために形成され、それはRBAC1と互換性がありません。次のように定義さRBAC2：
定義：
外部RBAC0における制約の数を増加させることに加えて、RBAC2はRBAC0から不変であり、これらの制限は、各成分のRBAC0の値が許容可能であるかどうかを決定するため、のみ許容される値が許容されています。
RBAC2は制限がすべてのコンポーネントとの関係RBAC0モデルに適用することができる導入しました。排他的限界RBAC2、排他的な役割は、それぞれ他の制約のそれぞれの能力の2グラムの役割である基本的な制限の役割。役割のこのタイプのユーザーは、単一のイベントでは、2つの役割を使用する権利を取得することはできませんロールが割り当てられています。
例えば、監査活動は、役割は、監査役と会計の役割の役割に割り当てることはできません。別の例として、同社では、マネージャとアシスタントマネジャーの役割は、また、管理者が署名した契約相互に排他的であるかだけチェックし、副社長によって署名することはできません。会社の設立のためのRBAC2モデルでは、ユーザーには2つの役割の管理者と副管理者の両方を持つことはできません。概要制限専属モデルは、権限と責任の分離の原則の実現をサポートすることができます。
より一般的には、排他的な制限は、ユーザーのメンバーシップに役割の異なる組み合わせで制御することができるが許容されます。たとえば、ユーザーがすることができ、両方のプログラマプロジェクトAは、インスペクタテスターとプロジェクトB Cプロジェクトかもしれないが、彼は3つの役割の同じプロジェクトになることができません。RBAC2モデルは、この場合に限定することができます。
別の例では、ユーザーに割り当てられた限界ベースの役割を制限することが知られているメンバーの最大数を制限する役割です。例えば、ユニットのトップのリーダーシップは一人ですることができ、中間レベルの幹部の数は限られており、これらの役割に割り当てられたユーザーの数は一度、限界にベースの役割を超えていないことは、もはや配給の新しいユーザーを受け入れています。
いくつかの困難を実装するために最低限のベースの役割を制限します。ユーザーの指定した最小数は役割を取る場合、例えば、問題は、システムが消滅し、システムとどのようにそれを行うにあれば、いつでも消えない人の乗員を知ることができる方法です。
ユーザAに役割を割り当てること、および場合によっては、ユーザーが前提役割役割役割になるためにB、Bの役割のメンバでなければならないことを必要とする場合。先例（PrerequisiteRoles）の役割の概念は、能力と適応性から来ています。絶対的な限界のための前提条件は、前提条件の限界となります。一般的な例は、数学の准教授で数学の講師に講師から推進すべき前提条件役割の准教授です。しかし、実際のシステムでは、先例の制限の役割間の非互換性も発生する可能性があります。
プロジェクトのメンバーのみが、通常のシステムでは、プログラマの役割を担う資格がある制限することができるap08-03図では、先例の役割は、新たに割り当てられた役割のいくつかのレベルよりも低くなっています。しかし、いくつかのケースでは、ユーザーはA.などの別の役割に特別な役割を必要とされていない場合にのみ、たとえば、たとえば、グループメンバーは、プロジェクト評価委員会の結果のメンバーであってはならないので、回避戦略を実行するために必要なときに実行する必要があります。このような制限は、ライセンス条項に拡張することができます。
ロールを持つユーザーがセッションにリンクされますので、そのセッションでは制限を課すことができます。例えば、ユーザは、二つの役割に割り当てることができるようにしてもよいが、同時にユーザは、二つの役割を活性化しません。さらに、ユーザは、数を制限することができるアクティブなセッションの制限でユーザに割り当てられたライセンスの対応する数を適用することができる、セッションの同時に活性化することができます。
継承の前述の概念は限定として考えることができます。アクセス権は、下位レベルの役割に割り当てられているが、また、そのロールのすべての上位レベルの役割に割り当てる必要があります。または同等の、利用者は、より高いレベルのロールに割り当てられている役割そのすべての下位ロールに割り当てる必要があります。RBAC1モデルは冗長であるので、その意味は、それがRBAC2に含まれています。しかしRBAC1モデルは比較的単純である、という概念明確相続の代わりに、制限を行うことができます。
ユーザーのために、またはこれらの関数を呼び出すための役割の割り当て許可が割り当てを決定するためにチェックするために指定された役割は、通常は効果的に確認することができた者としたものに、関数によって返される結果を制限する要件を満たしている場合は、制限を実装する機能として実装することができますこれらの制限は、長い時間を維持することができるので、達成与えることのいくつかの簡単な制約大会。
ユーザーが識別子よりも多くを持っている場合、実際のシステムのサポートに基づいて、各ユーザーのための唯一の一意の識別子に基づいてモデルのメカニズムの有効性を制限し、制限は無効になります。あなたは同じ正確より二つ以上の操作を可能にする権限を持っている場合は同様に、その後、RBACシステムは、基本的な制限や義務と規制の分離の強化を実装することはできません。したがって、ユーザ識別子それ、およびライセンスに対応する動作の対応を必要とします。
4、統一モデルRBAC3
RBAC3 RBAC1とRBAC2はグレーディングと役割を継承する機能を提供するために一緒に組み合わせます。しかし、これら二つの概念は、一緒にも、いくつかの新たな問題を引き起こしました。
制約が伴う半順序の役割間の階層関係に、文字レベル自体にも適用することができる、そのような制限は、モデルのために不可欠であり、これは、部分的な順序に影響を与える可能性があります。例えば、追加の制限が原因下位ロールに与えられた役割の数を制限することができます。
公共することによって、2つ以上の役割が無い優れたか下位の役割の役割に限定することができます。格付け機関の役割の概念の場合の制限のこれらのタイプは、便利なああ分権化、それでも法にセキュリティ制限を担当することにしたいされてきたこれらの変化のすべてのことができます。
また、規制や格付けの役割間の敏感な相互作用を持っています。環境にap08-03図、プロジェクトメンバーが同時にプログラマーやテスターの役割を想定していないかもしれないが、プロジェクトの場所は、管理者が明確な制限の違反です。高レベルの役割によって、このような制限に違反し、私いくつかのケースでは許容可能であるが、他の例では、それらは、そのような違反が発生しないようにしてください。
モデルの厳格なルールの観点から許容されているいくつかのケースでは、他の場合であることが許されるべきではありません。同様の状況は、ベース上の制限で起こります。ユーザーはこの制限を行うことはできませんその後、テスターの姿に割り当てられ、役割を割り当てることができ制限すると仮定？言い換えれば、基本制限があるだけでなく、直接のメンバーのために、それはまた、継承されたメンバーにも適用することができますか？
民間の役割の概念は、これらの制限が有用で説明することができます。また、図ap08-03環境の中で、それは相互に排他的なように説明テスター「プログラマやプロジェクトマネージャ3つの文字に可能であるが、彼らは同じレベルにある、共通の優れた役割がありません、管理者の役割がお互いに違反していません排除限界。彼らはこのレベルの最大の要素であるため、通常の上司民間の役割と他のロールの間には、公共的な役割、民間の役割の間のように相互に排他的な関係は、定義の競合になることはできません。
様々な民間の役割との間の同一部分は、最大の技術的な限界0メンバーを有するものとして説明することができます。この方法によれば、テスターはテスターにこの役割を割り当てる必要があります、とテスターの役割は、管理者の役割の権限と共有するためのツールとして機能します。
ARBAC97モデル
ARBAC97モデルは、役割ベースの管理モデルの役割である三つの部分から構成されています。
URA97：ユーザー - ロールの割り当て。UA割り当て関係管理、ロールに関連付けられたユーザとの関係 - アセンブリは、ユーザを含みます。右の管理役割のメンバーは、正式な役割にメンバーシップを管理するように、この関係を修正する権利は、管理役割によって制御されています。ユーザーは、管理役割がURA97外で行われるように指定され、セキュリティ担当者によって行われるものとします。
PRA97：パーミッション - ロールの割り当て。パーミッション割当てと取消し - このコンポーネントは、役割を必要とします。ユーザーと権限の役割の観点から同様の特性を持って、彼らは物理的な現実の役割によってリンクされています。したがって、PRA97はURA97のデュアル構成要素として見て。
RRA97：役割 - 役割の割り当て。役割と分類された上で、役割の管理を容易にするために。あるクラス3関連するコンポーネントの役割：
-
能力（アビリティ）役割 - 入力する権限、および役割の他のメンバーを作る能力。
-
グループ（グループ）役割 - 唯一のユーザーとロールのクラスのメンバーとして他のグループ。
-
UP-役割は - ユーザーの役割と権限を表し、これらの役割は、そのメンバーには制限はありません、メンバーはユーザー、ロール、権限、能力、グループ、またはその他のUP-の役割をすることができます。
主な理由は、これらの3つのモデルの違いは、役割の異なる種類の間の関係を確立するために、異なる管理モデルに適用することが可能です。最初は、容量のモチベーションを考慮の区別で、機能を使用してロールに割り当てられた単位として、コレクション内のすべての権限を置くことができ、アクセス権のセットです。同様に、グループを使用してロールに割り当てられた単位として、コレクション内のすべての権限を置くことができ、ユーザーのコレクションです。グループや役割に能力がクラスに分けているように見えます。
支配は、それ以外ではない、ある場合にケーパビリティは、その役割のメンバであるかどうかをUP-役割において、能力が支配するかどうかをUP-によって決定されます。文字はグループUP-の役割によって支配されている場合は逆に、このグループはUP-ロールのメンバーです。
グループに割り当てられている - - ARBAC97管理モデルに関する研究は、能力の中で続けて正式な割り当てが完了している、UP-役割概念の研究の結果は、まだ正式にされていません。[2]
DRBAC
DRBACは、動的な環境の提携でRBACモデルが配布されます。
前回の信頼管理およびRBACの方法とは異なるDRBACが、それは3つの機能をサポートしていることです。
1.サードパーティの割り当て：エンティティが割り当てを割り当てることが許可されている場合は、その名前空間以外の役割を割り当てることができます。
2.デジタルプロパティ：割当てプロセスの値を調整するための機構を介したアクセスと関連する役割。
3.監視割付：連続監視パブ/トラッキングで確立された信頼関係のサブ構造は、割り当てられた状態を解除することができます。
DRBAC環境は質問リードによって、リソースへの連合軍のアクセスを制御します下にあります。「アライアンス環境は、」いくつかの国で共通の目標を達成するために一緒に働いて、軍事、またはいくつかの商用のパートナーになることができます。アライアンス定義された環境はありません、共通の信頼された機関で複数の組織またはエンティティが存在することを特徴とします。この場合、それぞれのリソースを保護しながら、エンティティは、提携のために必要な保護されたリソースの一部を共有するために協力しなければなりません。この需要の伸びを作るために、インターネットのネットワークサービスが広まっています。
DRBACは、柔軟な管理システムだけでなく、分散、スケーラブルな実装の両方であるRBAC及び信頼管理システムの利点を組み合わせます。DRBACは、制御された行動の役割で表し一方のエンティティのドメイン信頼の役割の定義、およびこの役割を通過することができる他の役割異なる信頼ドメインに割り当てられます。DRBACは割り当て証明書をすべての重要な操作と信頼関係のエンティティを識別し、確認するためにPKIを使用しています。許可された名前空間へのロールのマッピングは、さらなる戦略のルーツを認識する必要がなくなります。
4ライセンス設定エディタ
ライセンスの設定手順
RBACでは、ユーザーがメインのデータ表現とデータがあるスタンドアロンコンピュータシステム、または他のリソースにアクセスすることができます。役割は、組織のタスクまたはジョブまたは位置である、それは右、タイトルと責任を表します。ライセンス（権限）は、1つまたは複数のオブジェクトの実行の操作を可能にすることです。ユーザは、複数の役割を持つように、複数のユーザによって構成される役割を許可することができ、各文字は、ライセンスの様々な構造を有することができ、各ライセンスは異なる役割の数に発行することができます。各操作は、オブジェクト（制御対象）の複数に適用することができる、各オブジェクトは、複数の操作を受け付けることができます。
ユーザーID、ユーザー名、ユーザーのログインパスワードを含むユーザーテーブル（USERS）、。ユーザテーブルは、動的な変更を追加および削除するユーザと、個々のユーザシステムの集合です。
アイデンティティーの役割、役割名、役割ベース、可能なロールを識別含むロールテーブル（ロール）。ロールシステムテーブルは、ロール、システム管理者によって定義されたロールのセットです。
オブジェクト識別、オブジェクト名を含むオブジェクトテーブル（オブジェクト）。オブジェクトテーブルには、すべての制御システムオブジェクトのコレクションです。
オペレータ手術台（OPERATIONS）が操作識別子、操作オペレータの名前を含みます。オペレータシステムオペレータは、オペレータの動作テーブルを構成するすべてのオブジェクトを制御します。
ライセンステーブル（PERMISSIONS）は、ライセンスID、ライセンス名、制御対象、動作識別子を含みます。制御対象のオペレータの操作に対応を与えるライセンステーブル。
アイデンティティ、ライセンスIDの役割を含む役割/ライセンステーブル。システム管理者は、役割を割り当てたり、ライセンス管理役割/ライセンステーブルをキャンセルします。
RBACの基本的な考え方は次のとおりです。通常、組織内のユーザーの役割によって決まるアクセスに許可されたユーザ、。RBACの権限がロールに付与され、役割がユーザーに付与され、ユーザーが直接ライセンスに関連付けられていません。RBACの承認は、管理者による一元管理にアクセスするには、組織内のユーザーの要件に基づいてアクセス許可および制御、認証は、ユーザーが自律的に他の人にアクセスすることができない、利用者に課されるにRBACの役割は、これは非自律集中アクセスコントロールの種類。例えば、病院で、医師がこの役割を処方することができますが、彼は権限を規定する看護師に合格する権利はありません。
RBACでは、ユーザーの識別と認証監査レコードがために非常に有用であるが、実際の決定は、対応するユーザロール識別へのアクセスです。ユーザは、ユーザが現時点でアクティブである一方が一定の役割を、許可されたアクセス動作を実行するために必要な条件に反対し、適切なアクセス権を持つオブジェクトの役割をすることができます。つまり、ユーザーが操作を実行できるかを判断リソースへのロールアクセスの種類の主要なアクセス制御などのRBACの役割、ユーザーにあります。
ACLは、直接体に連結されたオブジェクトを制御し、RBACロール、ロールを介してサブジェクトとオブジェクト通信の途中で接合されます。層状の利点は、身体が変化した場合、単純にロールに関連付けられたオブジェクトを変更することなく、本体とロールの間の関連付けを変更することです。
機能エディタ5RBACモデル
さまざまな組織のニーズに沿った安全管理。RBACモデルは、職務の分離の最小権限の原則の原則をサポートし、これらの原則は、いかなる組織の管理が必要とされています。これは、RBACモデルは、幅広いアプリケーションの見通しを持っています。
RBACモデルは、データ抽象化と継承の概念の原則をサポートしています。起因する現在主流のプログラミング言語サポートオブジェクト指向技術に、この機能は、実際のシステムで実現するためにRBACを使用して簡単です。
これは、モデルと実際のシステムの概念に密接に対応しています。ロールモデル、ユーザーと権限のRBACの概念をすべて実際のシステムでは、実際のエンティティは、既存のRBACモデルやシステムを構築するために確立するため、設計者を支援存在しています。
RBACモデルは、依然としてシステム本体に良好な溶液分布および制御の問題であることができる、アクセス制御クラスのモデルを本質的にアクセス行列モデルに拡張さリギングされるアクセス制御アクセス権の一種であるが、このモデルは、情報フロー制御メカニズムを提供していないだけでなく、我々は完全に情報システムのすべてのセキュリティ要件を満たすことができません。
一部の人々はあなたがシミュレーションベースのグリッドアクセス制御システム（LBAC）にRBACを使用することができますが、RBACは、システム内の情報の流れが直感的でない制御するためだと思いますが、機能はモデルからのサポートが必要です。第四章のフロー制御の原理の範囲については、読者はさらに、この欠陥のRBACモデルことが理解されるであろう。
RBACモデルは、動作シーケンス制御機構を提供していません。この欠陥は、RBACモデルは、システムのエンティティの動作の厳密な順序でそれらの要件を適用することは困難であり、例えば、顧客が支払っていない前に、ショッピング・制御システムに購入するために必要な手順の制御システムは、彼が品物を奪うせてはならない可能性があります。RBACモデルは、外部モデルへの制御機構が達成していることが必要です。
RBAC96モデルとRBAC97uanliモデルは、意図的に提供せずに対処する必要があり、そのようなユーザーはセッション管理モデルの再作成、新しいセッションを許可するかどうかの増加をサポートし、ユーザー管理や権限を削除しないようにいくつかの問題、などを避けてきましたサポートの問題は、これらの問題はまだ検討中ですが、これらの機能の有無は、モデルやアプリケーションにも影響を受けることになりますサポートしています。代わりに、行列モデルは、ユーザーのアクセスや機能を変更する権限を提供し、そのため、RBACモデルは完全にアクセス行列モデルを置き換えることができます言うことはできません。
オリジナル住所ます。https：//www.cnblogs.com/rongfengliang/p/3982011.html