1.権限管理の意味
安全性の確保：誤操作、人為的な妨害、データ漏洩などを避けてください。
データの分離：さまざまな権限が、相互に干渉することなくさまざまなデータを表示および操作できます。
明確な責任：さまざまな役割がさまざまな業務を処理し、責任を洗練し、プロセスを標準化および簡素化します。
第二に、権限管理システムの一般的な設計アイデア
オブジェクト（オブジェクト、つまりリソース）のサブジェクト（サブジェクト、つまりユーザー）は、ある種の操作（操作）を実装する必要があります。そのような操作のシステム管理制御はアクセス制御です。
1.許可の分類
- 操作許可
API許可
メニュー許可
ボタン許可 - データ許可
いわゆる操作権限とは、出席を承認できるかどうかなど、ユーザーが特定の操作を実行する権限を持っているかどうかです。具体的な兆候は、ユーザーが特定のメニューまたはボタンを表示できるかどうか、およびユーザーが特定のAPI（たとえば、関係する一部のAPI）ユーザー情報のAPIは、ユーザーのログイン検証に使用されます。
いわゆるデータ権限とは、ユーザーがログメニューなどの特定のデータへのアクセス権限を持っているかどうか、通常のユーザーは自分の操作レコードのみを表示でき、管理者はすべてのユーザー操作の動作を表示できるかどうかです。ユーザーには操作権限がありますが、すべてのデータを表示または変更する権限があるわけではありません。
2.アクセス制御権限モデル
アクセス制御権限モデルは、ACL、DAC、MAC、RBAC、ABACです。
2.1ACLアクセス制御リスト
どのエンティティがどのリソースを実行できるかを指定します
ACL、アクセス制御リスト、アクセス制御リストを介して、ユーザーとリソース間のマッピング関係を維持します。ACLには、ユーザー、リソース、操作の3つの要素が含まれています。リソースごとに、このリソースに対してどのユーザーがどの操作を実行できるかを記録するリストが構成されます。システムがこのリソースにアクセスしようとすると、このリストに現在のユーザーの操作権限があるかどうかがチェックされます。その場合、操作を実行できます。そうでない場合、操作は拒否されます。
ACLアクセスコントロールリストは、ルーターやレイヤー3スイッチで広く使用されており、設定された条件に従ってインターフェイス上のデータパケットをフィルタリングし、通過または破棄することができます。アクセス制御リストの助けを借りて、ユーザーはネットワークへのアクセスを効果的に制御できるため、ネットワークのセキュリティを最大限に確保できます。
アプリケーションシナリオ：ルーター、ファイアウォール、ファイルシステム
2.2DAC自律アクセス制御
DACは、どのサブジェクトがリソースに対してどの操作を実行できるかを指定します。同時に、サブジェクトは他のサブジェクトにリソースと操作のアクセス許可を付与できます。
DACはACLの実装であり、柔軟性を強調しています。純粋なACL、権限はセンター管理者によって一律に割り当てられ、柔軟性に欠けています。柔軟性を強化するために、ACLに基づいて、DACモデルは承認を分散化し、権限を持つユーザーが他のユーザーに自律的に権限を付与できるようにします。
従来のLinuxアクセス制御方法は、DAC自律アクセス制御です。
DACのアイデア：プロセスとその実行ユーザーは同じ権限を持っています。
例：rootユーザーとして実行されるプロセスA、プロセスAにはrootユーザーの権限があります。
もう1つの例は、Windowsファイルのアクセス許可です。
随意アクセス制御は比較的緩いアクセス制御です。サブジェクトのアクセスアクセス許可は推移的です。自律性を強調し、アクセス戦略を独自に決定しますが、セキュリティリスクも自律性に起因します。
2.3.MAC強制アクセス制御
強制アクセス制御モデル（MAC、強制アクセス制御）は、DAC典拠制御の過剰分散の問題を補うために生まれました。
a。リソースがどのタイプのサブジェクトによって実行できるかを指定しますb。サブジェクトがどのレベルのリソースで実行できる操作を
指定します
ユーザーが操作を実行する場合、操作が許可される前に、aとbが同時に満たされる必要があります。
MACアクセス制御では、サブジェクトとリソースに特定のセキュリティレベルが与えられます。ユーザーは自分自身とリソースのセキュリティレベルを変更できません。管理者のみがユーザーのアクセス権限を決定できます。DACモデルとは異なり、MACはマルチレベルのアクセス制御戦略です。その主な機能は、システムがユーザーとアクセスされたリソースに強制アクセス制御を適用することです。システムは、ユーザーとリソースオブジェクトに異なるセキュリティレベルの属性を事前に割り当てます。アクセス制御中、システムは最初にユーザーとリソースオブジェクトのセキュリティレベル属性を比較し、次にユーザーがリソースにアクセスできるかどうかを判断します。
MACの強制アクセスポリシーは、各ユーザー、プロセス、およびファイルにセキュリティアクセスレベルを割り当てます。
- トップシークレットレベル（トップシークレット、通常はTとマークされています）
- シークレットレベル（シークレット、通常はSとマークされています）
- 機密レベル（機密、通常はCとマークされています）
- 未分類（未分類、通常はUとマークされています）
MACは、機密性の高い組織や、強力な階層概念を持つその他の業界に非常に適しています。しかし、同様の商用サービスシステムの場合、機密性が過度に強調されているため、管理は適切なほど柔軟ではありません。
2.4RBACの役割ベースのアクセス制御
現在、最も一般的なアクセス許可設計モデルのほとんどは、RBACモデルであるロールベースのアクセス制御です。RBACモデルの基本的な考え方は、特定の役割にアクセス許可を割り当てることであり、ユーザーはさまざまな役割を演じることで、役割が所有する対応する許可を取得できます。
2.4.1.RBAC0
RBAC0は、役割ベースのアクセス制御の基本モデルであり、コアの3つの要素、ユーザー、役割、およびアクセス許可のみが含まれています。他のバージョンはRBAC0に基づいて拡張されています。
各役割は一連のリソース権限（多対多）に関連付けられ、各ユーザーはいくつかの一連の役割（多対多）に関連付けられるため、ユーザーがアクセスできるリソースを簡単に制御できます。
2.4.2.RBAC1
階層的役割、役割の継承。
親子ロールの概念を導入すると、いわゆるロール継承とは、子ロールがRBAC1のモデルである親ロールの権限を継承できることを意味します。
2.4.3.RBAC2
職務の静的分離は、職務の静的分離であり、ユーザーの権限を通常の範囲内に制限するために使用され、SSD制約は役割の割り当て中に適用されます。
役割と役割のために、レジ係と会計士、運動選手と審判など、許可と許可の間に矛盾がある場合があります。従業員はレジ係と会計士の両方になることはできず、オペレーターはオペレーターと審判の両方になることはできません。
職務の静的な分離は、ユーザーが現在の職務に対して妥当なレベルの権限を超えないようにするために、ユーザーに同時に競合する役割を割り当てることができないことを意味します。簡単に言えば、2つの役割間の競合を回避することです。従業員がすでにキャッシャーの役割を持っている場合、従業員に経理の役割が割り当てられると、役割が競合し、操作を実行できないというプロンプトが表示されます。つまり、役割が割り当てられると、それがチェックされます。ロール間に継承関係があるかどうかに関係なく、検証が必要です。
2.4.4.RBAC3
職務の動的分離は、職務の動的分離でもあります。必須の制約は、任意の時点で一緒に使用できる機能です。DSD制約を使用して、マルチステップ承認プロセスで厳密な制御を実装できます。通常、DSD制約は、役割がアクティブ化されたときに適用されます。
職務の動的な分離は、競合する役割を同時にユーザーに与えることができることを意味しますが、ユーザーはセッションで同時に競合する役割をアクティブ化することはできず、そのうちの1つしか選択できません。
ユーザーがログインするとき、またはログインが成功した後、ユーザーは役割を選択するように求められます。たとえば、ユーザーはレジ係の役割を選択します。実行中のセッション中、ユーザーは操作する会計士の役割を選択できず、ログアウトして再度ログインすることしかできません。
2.5ABAC属性ベースのアクセス制御
ユーザーを特定の方法で権限に関連付ける一般的な方法とは異なり、ABACは、属性の1つまたはグループが特定の条件を満たすかどうかを動的に計算することによって承認の判断を行います。
属性は一般に4つのカテゴリに分類されます。
- ユーザー属性（ユーザー名など）
- 環境属性（現在の時刻など）
- 運用属性（読み取りや書き込みなど）
- オブジェクト属性（記事などのリソース属性とも呼ばれます）
ABACの制御粒度はRBACの制御粒度よりも細かく、理論的には非常に柔軟な許可制御を実現でき、ほぼすべてのタイプのニーズを満たすことができます。
ユーザーは、サブジェクト属性、リソース属性、環境属性などの独自の属性値を保持し、リソースにリクエストを送信します。承認エンジンは、サブジェクトが保持する属性に基づいて判断し、ユーザーに拒否を与えます。または同意の結果、ユーザーはリソースへのアクセスまたはアクセス拒否を行うことができます。
たとえば、「クラスの教師全員が授業中に学校の門に自由に出入りできるようにする」というルール。「クラスの教師」はユーザーの役割属性、「クラスの時間」は環境属性、「出入り」は操作属性であり、「スクールゲート」もオブジェクトのプロパティです。便利なルール設定とルール判断の実行を実現するために、ABACには通常、ルール解析エンジンと連携する構成ファイル（XML、YAMLなど）またはDSLがあります。
3.データパーミッションの実現
データ権限は、ユーザーが表示できるデータを制御することであり、特定の条件を満たすユーザーは、その条件の下で対応するデータリソースのみを表示できます。
アクセス制御権限は、ユーザーが特定のリソースにアクセスできるかどうかを制御することです。
データ権限は、ユーザーがアクセス制御権限を取得した後、特定のルールに従ってユーザーが表示できるデータをさらに除外することです。
これは、特定の部門のユーザーのデータの可視性を制御するためによく使用されます。たとえば、ユーザーは自分の部門のデータしか表示できません。
データオーソリティには2つの主な機能があります。
（1）データセキュリティの問題を解決するため
に、企業内のユーザーレベルが高いほど、より多くのデータコンテンツが表示され、大量の機密データが表示または漏洩されるのを防ぎます。普通の従業員。
（2）熾烈な競争を避ける。
企業の営業部門では一般的であり、営業マネージャーが蓄積した顧客リソースは他の営業マネージャーと簡単に共有されません。
一般的な解決策は次のとおりです。
- 最も簡単な方法：対応するWhere条件をSQLコードに直接追加して、データをフィルタリングします。これは、小規模なプロジェクトのシナリオに適しています。
- ビジネスによって実行されたSQLをインターセプトし、データフィルター条件を自動的にスプライスしますが、これは単一のアプリケーションにのみ適しています。分散シナリオでは、クロスサービス呼び出しのデータをフィルター処理することは困難です。
- コントローラーレイヤーでは、AOPを介して、ユーザーの表示データが指定されたデータルールに従ってフィルターで除外されます。つまり、すべてのデータが最初にクエリされ、次に表示データが特定のルールに従ってフィルター処理されます。
これらの2つの記事データ一般設計権管理権とデータ権利設計-データ許可に基づくEntityFramework設計：1つの設計概念は、設計アイデアが興味を持って行くことができる、より一般的なデータ権限も提供します。一般的な考え方は、ユーザーをより柔軟に制御することです。役割データフィルタリングルールを構成することによるデータ権限。
3.アクセス制御権限の一般的なソリューション
私たちの作業で使用するアクセス許可モデルは、主にRBACに基づいているか、RBACに基づく拡張機能です。一般的な方法は、ユーザー側またはリソース側に制限を追加することです。
1.標準シーン（API、メニュー、ボタン）
これは最も基本的なシナリオであり、RBAC0モデルです。
一般に、ユーザーテーブル、ロールテーブル、権限（リソース）テーブル、ユーザーロールテーブル、ロール権限テーブルの5つのテーブルに設計されています。
APIパーミッション：ユーザーへのすべてのリクエストは、APIパーミッションによって検証する必要があります（アスペクトまたはフィルターを介して実現できます）
1）最初にユーザーのロールセットAを取得し、次にリクエストされたAPIに従ってAPIパーミッションを持つセットBを取得します交差点がある場合は、権限があることを意味します
。2）ユーザーのロールセットを取得してから、承認されたすべてのAPIセットAを取得し、要求されたAPIがセットAにあるかどうかを判断します。
メニュー権限：最初にユーザーに応じて役割のセットをクエリし、次に対応するメニューリストを取得してメニューツリーを形成し、フロントエンドレンダリングに戻ります
ボタンの権限：ユーザーの役割に応じて、承認されたすべてのボタンセットBを取得できます。ページがレンダリングされると、ボタンがセットBにあるかどうかに応じて、ボタンを表示するか非表示にするかが決定されます。
2.グループの紹介
ユーザーをより適切に管理し、ユーザーをカテゴリにグループ化するために、グループの概念を導入できます。
実際の状況では、グループが独自の役割情報と許可情報を持つこともできます。たとえば、QQユーザーグループ、グループには複数のユーザーを含めることができ、ユーザーは複数のグループに参加することもできます。各グループには、独自の権限情報があります。たとえば、グループ共有を表示します。QQグループは、通常のグループ、上級グループなど、独自の役割情報を持つこともできます。
グループの概念を導入した後、ユーザーが持つ役割は、ユーザーが所有する役割のセットと、ユーザーが属するグループが所有する役割のセットの和集合です。このように、すべてを与える必要があります。特定のユーザーグループのユーザーは、特定の役割の権限を持っています。、対応する役割をグループに割り当てる必要があります。
3.役割の継承
承認の利便性を向上させるために、ロールの複製とロールの継承の機能を提供することもできます。つまり、前述のRBAC1のモデルであるロールをコピーして継承することができます。
コピーされたロールは、コピーされたロールと同じ権限を持つことができます。ロールの継承の場合、子ロールは親ロールの権限を継承できます（Javaの継承と同様）。
4.機能モジュールを紹介します
以前のリソースは、API、メニュー、ボタンの3つのカテゴリに分類されますが、以前は多くのリソースが関連しており、関連するリソースを機能モジュールに集約できるため、リソースの割り当てに便利です。
メニューも考慮できます。親切な汎用モジュールとして、メニューを個別に承認することもできます
5.マルチアプリケーション認証センター
複数のサービスがパーミッションシステムを設計する必要がある場合、パーミッションサービスは独立していて、複数のアプリケーションのパーミッション管理を提供できます。
管理が必要な各サービスはアプリケーションと見なすことができ、各アプリケーションは独自のユーザー、役割、およびリソースを持つことができます。同時に、ユーザーは複数のアプリケーションに属することもできます。
パーミッションサービスは、他のアプリケーションのパーミッションを維持できるだけでなく、パーミッションサービス自体のパーミッションも維持できます。