RBAC許可システムの手動設定

記事のソース: 「RBAC 権限システムの分析、設計、実装」 | shuwoom.com

現在、最も一般的に使用されている権限管理モデルは RBAC (Role-Based Access Control) モデルです。この記事でも RBAC ベースの権限管理システムを主に紹介し、RBAC とは何か、RBAC の設計方法についても説明します。

1.RBACとは

1. RBACモデルの概要

RBACモデル(Role-Based Access Control:役割ベースのアクセス制御)モデルは1990年代に開発された新しいモデルですが、実はこの考え方は1970年代のマルチユーザーコンピューティング時代から中期、そして1970年代までは提案されていました。 1990 年代後半、RBAC は研究コミュニティであまり注目されず、多くの種類の RBAC モデルが次々に提案されました。中でも、米国ジョージ・メイソン大学の情報セキュリティ技術研究所（ＬＩＳＴ）が提案したＲＢＡＣ９６モデルが最も代表的であり、一般に認知されている。

RBACでは、権限認可のプロセスは、「誰が、何を、どのようにアクセス操作できるか」と、その論理式が真であるかどうかを判断する解決プロセス、つまり権限の問題を「何をどのように質問するか」に抽象的に要約できると考えています。 Who、What、How がアクセス権の 3 つの要素を構成しており、具体的な理論については RBAC96 の論文を参照してください。

2. RBACの構成

RBAC モデルには、ユーザー、ロール、権限という 3 つの基本コンポーネントがあります。

RBAC は、ロールの権限を定義し、ユーザーに特定のロールを付与することでユーザーの権限を制御し、(ACL モデルとは異なる) ユーザーと権限の論理的な分離を実現し、権限の管理を大幅に容易にします。

説明する前に、いくつかの名詞を紹介します。

ユーザー (ユーザー): 各ユーザーは一意の UID ID を持ち、異なる役割が付与されます。
役割: 役割が異なると権限も異なります。
許可: アクセス権
ユーザーとロールのマッピング: ユーザーとロール間のマッピング関係
役割と権限のマッピング: 役割と権限間のマッピング

それらの関係を次の図に示します。

たとえば、次の図では、管理者と一般ユーザーに異なる権限が付与されています。一般ユーザーは個人情報の変更と表示のみが可能ですが、ユーザーの作成と凍結はできません。管理者はすべての権限が付与されているため、すべての操作が可能です。

3. RBAC によってサポートされるセキュリティ原則

RBAC は、最小特権の原則、職務分離の原則、データ抽象化の原則という 3 つのよく知られたセキュリティ原則をサポートしています。

最小権限の原則: RBAC は、タスクを完了するために必要な最小限の権限セットとしてロールを構成できます。
責任の分離の原則: 簿記係と財務管理者が統合転記業務に共同で参加することを要求するなど、相互に独立し、相互に排他的な役割を呼び出すことで、機密性の高いタスクを一緒に達成できます。
データ抽象化の原則: 一般的な読み取り、書き込み、実行のアクセス許可を使用する代わりに、金融業務のための借入や預金などの抽象的なアクセス許可などのアクセス許可の抽象化によって反映できます。

4. RBAC の長所と短所

(1) メリット：

ユーザーと権限の関係を簡素化します
拡張と保守が簡単

(2) デメリット:

RBAC モデルには操作順序の制御メカニズムが提供されていないため、操作順序に厳しい要件があるシステムに RBAC モデルを適応させることが困難になります。

5. RBAC の 3 つのモデル

(1)RBAC0

RBAC0 は最も単純かつ原始的な実装であり、他の RBAC モデルの基礎となります。

このモデルでは、ユーザーとロールの間に多対多の関係が存在する可能性があります。つまり、ユーザーはさまざまなシナリオでさまざまなロールを持つことができます。たとえば、プロジェクトマネージャーがチームリーダーまたはアーキテクトである場合もあります。同時に、各役割には少なくとも 1 つの権限があります。このモデルでは、ユーザーと権限が分離されて独立しているため、権限の認可と認証がより柔軟になります。

（2）RBAC1

RBAC0 モデルに基づいて、ロール間の継承関係が導入されます。つまり、ロールには上位ロールと下位ロールの区別があります。

ロール間の継承関係は、一般継承関係と限定継承関係とに分けられる。一般的な継承関係では、ロール継承関係が絶対半順序関係であることのみが必要であり、ロール間の多重継承が可能です。制限された継承関係では、ロール間の単一継承を実現するために、ロール継承関係がツリー構造であることがさらに必要になります。

このモデルは、役割間の明確な階層に適しており、役割をグループ化して階層化できます。

（3）RBAC2

RBAC2 は、RBAC0 モデルに基づいて、ロールのアクセス制御を実行します。

RBAC2 の基本的な制限は、相互排他的なロールの制限です。相互排他的なロールとは、それぞれのアクセス許可が相互に制限できる 2 つのロールを指します。このタイプの役割の場合、ユーザーには特定のアクティビティのいずれかの役割のみを割り当てることができ、両方の役割を同時に使用する権利を取得することはできません。

モデルには次の制約があります。

相互に排他的なロール: 同じユーザーは、責任の分離の原則をサポートする、相互に排他的なロールのセット内の最大 1 つのロールにのみ割り当てることができます。相互に排他的なロールとは、それぞれの権限が相互に制限する 2 つのロールを指します。このタイプの役割の場合、ユーザーには特定のアクティビティのいずれかの役割のみを割り当てることができ、両方の役割を同時に使用する権利を取得することはできません。一般的な例: 監査活動では、会計士の役割と監査人の役割の両方に同時に役割を割り当てることはできません。
カーディナリティ制約: ロールに割り当てられるユーザーの数は制限され、ユーザーが持つことができるロールの数は制限されます。システム内の高度な権限の配布を制御するには、ロールに対応するアクセス権の数も制限する必要があります。たとえば、会社のリーダーは限られています。
前提条件のロール: ロールをユーザーに割り当てることができるのは、そのユーザーがすでに別のロールのメンバーである場合のみです。同様に、ロールにアクセス権を割り当てることができるのは、そのロールが別の種類のアクセス権をすでに持っている場合のみです。これは、より高い権限を得るには、まずより低いレベルの権限を持たなければならないことを意味します。私たちの生活と同じように、国の大統領も副大統領の中から選出されます。
実行時の相互排他: たとえば、ユーザーは 2 つのロールのメンバーシップを持つことができますが、実行時に両方のロールをアクティブにすることはできません。

2. RBACの設計方法

このセクションでは、RBAC モデルに基づく許可システムの機能モジュール構成、プロセス、データベース設計について紹介します。

1. RBACの機能モジュール

2.RBAC実行処理

3. RBAC データベースの設計

ここに画像の説明を挿入