最近では、プロジェクトの権利管理モジュールを設計し実装する必要があるため、RBACの知識をまとめました。
現在、最も一般的に使用されている権利管理モデルはRBAC（ロールベースのアクセス制御）モデルです。この記事では、RBACベースの権利管理システムを紹介します。RBACとは何か、RBACを設計する方法から説明します。
RBACとは？
1、RBACモデル概要
RBACモデル（Role-Based Access Control：ロールベースアクセス制御）モデルは1990年代に研究された新しいモデルですが、実際には1970年代のマルチユーザーコンピューティングの時代にこのアイデアが提案されており、1990年代半ばから後半にかけてRBACが研究コミュニティで注目され、多くの種類のRBACモデルが提案されています。その中で、米国George Mason 大学情報セキュリティ技術実験室（LIST）が提出したRBAC96モデルが最も代表的であり、普遍的な公認を得た。
RBACは、権限認可のプロセスを抽象的に要約することができると考えている：WhoがWhatに対してどのようにアクセス操作を行うことができ、この論理式がTrueかどうかを判断するプロセス、すなわち、権限の問題をWhat，Howの問題に変換することであり、Who，What，Howはアクセス権のトリプルを構成し、具体的な理論はRBAC96の論文を参照することができ、ここでは詳細な紹介をしないで、皆さんは印象を持っています。
（2）RBACの構成
RBACモデルには、ユーザー、ロール、権限の3つの基本的なコンポーネントがあります。
RBACは、役割の権限を定義し、ユーザーに役割を付与することによってユーザーの権限を制御し、ユーザーと権限の論理的分離（ACLモデルとは異なる）を実現し、権限の管理を大幅に容易にします。
説明する前に、いくつかの用語を紹介します：
- Userユーザー：各ユーザーは一意のUID識別子を持ち、異なるロールを割り当てられます。
- Roleロールロールによって権限が異なります。
- 権限Permissionアクセス権
- ユーザー-ロールマッピングユーザーとロール間のマッピング関係
- ロール-権限マッピングロールと権限間のマッピング
これらの関係は次の図に示されています（ユーザー、ロール、権限関係）。
例えば、下の図では、管理者と一般ユーザーには異なる権限が与えられており、一般ユーザーは個人情報の変更と表示のみができ、作成ユーザーと凍結ユーザーの作成はできませんが、管理者はすべての権限が与えられているため、すべての操作を実行できます。
例えば、下の図（ロール操作例）では、管理者と一般ユーザーには異なる権限が付与されており、一般ユーザーは個人情報の変更と表示しかできず、ユーザーの作成と凍結はできませんが、管理者はすべての権限が付与されているため、すべての操作を行うことができます。
RBACでサポートされるセキュリティ原則
RBACは、最小権限、責任分離、データ抽象化の3つのセキュリティ原則をサポートしている。
- 最小権限の原則：RBACは、タスクを実行するために必要な最小権限のセットとして役割を構成できます。
- 責任分離の原則：会計担当者と財務管理者が統合投稿操作に参加するなど、機密タスクは相互に排他的で排他的な役割を呼び出すことで共同で実行できます。
- データ抽象化の原則：典型的な読み取り、書き込み、実行権限を使用する代わりに、金融操作のための借入、預金などの抽象的な権限のような権限の抽象化によって具現化することができます。
RBACの弱点
（1）の利点：
- ユーザーと権限の関係を簡素化
- 簡単な拡張とメンテナンス
（2）の欠点：
RBACモデルは動作順序を制御するメカニズムを提供しておらず、動作順序に厳しい要件を持つシステムに適応することが困難である。
RBACの3種類のモデル
（1）RBAC0
RBAC0は最も単純で原始的な実装であり、他のRBACモデルの基礎となっている。
このモデルでは、ユーザとロールの間に多対多の関係があります。つまり、ユーザは異なるシナリオで異なる役割を持つことができます。例えば、プロジェクトマネージャーはチームリーダー、アーキテクトなどです。各ロールには少なくとも1つの権限があります。このモデルでは、ユーザとパーミッションが分離され、パーミッションの認証がより柔軟になります。
（2）RBAC1
RBAC0モデルに基づいて、役割間の継承、すなわち下位と下位の区別が導入されました。
ロール間の継承関係は、一般継承関係と制限継承関係に分けられる。一般的な継承関係は、ロール継承関係が絶対半順序関係であり、ロール間の多重継承を可能にすることを要求する。制限付き継承関係では、ロール継承関係がツリー構造であり、ロール間の単一継承を実現する必要があります。
このモデルは、キャラクター間のレイヤー化に適しており、キャラクターのグループ化にレイヤー化できます。
（3）RBAC2
RBAC2は、RBAC0モデルに基づいて、役割のアクセス制御を行っています。
RBAC2の基本的な制限の1つは、相互排他的役割の制限であり、相互排他的役割は、それぞれの権限が互いに制限できる2つの役割である。このようなロールでは、ユーザーはアクティビティ内に1つのロールのみを割り当てることができ、両方のロールを同時に使用することはできません。
このモデルには次のような制約があります。
- 相互排他的ロール：同じユーザーは、相互排他的ロールのセット内で最大1つのロールにしか割り当てることができず、責任分離の原則を支持します。相互排他的ロールは、それぞれの権限が互いに制約する2つのロールを指す。このようなロールでは、ユーザーはアクティビティ内に1つのロールのみを割り当てることができ、両方のロールを同時に使用することはできません。よくある例：監査活動では、1つの役割を会計と監査人の役割の両方に割り当てることはできません。
- 基準制約：ロールに割り当てられるユーザーの数に制限があります。ユーザーが持つことができるロールの数に制限があります。システム内の高度な権限の割り当てを制御するために、同じロールに対応するアクセス権限の数に制限があります。例えば、会社のリーダーが限られている。
- 前提条件ロール：ユーザーがすでに別のロールのメンバーである場合にのみ、ロールをユーザーに割り当てることができます。ロールには別のアクセス権がある場合にのみ、ロールにアクセス権を割り当てることができます。高い権限を得るには、まず低い権限を持たなければならない。私たちの人生のように、大統領は副大統領の中から選ばれます。
- 実行時相互排他的：たとえば、1人のユーザーが2つのロールのメンバーシップを持つことを許可しますが、実行中に両方のロールを同時にアクティブにすることはできません。
RBCの設計方法
このセクションでは、RBACモデルに基づくパーミッションシステムを設計するための機能モジュールの構成、プロセス、およびデータベースの設計について説明します。
RBACの機能モジュール
2、RBAC実行プロセス
3、RBACデータベース設計
