権利管理は B サイドの共通のトピックであり、ユーザーのそれぞれの役割と機能を規定し、データ セキュリティの保護も提供します。
B エンド製品にとって権限管理は避けては通れないテーマですが、この記事では権限管理に関する私の設計経験と設計手法をまとめ、以下の 4 部に分けて説明します。
- 権利管理の概念化
- RBAC 権限設計の一般的な手順
- 機能権限設計の3つの軸：基本版（権限、ロール、ユーザー管理）、拡張版（部門、役職、メニュー管理）、拡張版（バージョン管理）
- データ権限を設計する方法
すべての内容は私自身の考え、実践、経験に基づいていますので、間違いがある場合は修正してください。
第 1 章: 権利管理の概念化
1. 権限とは何ですか
権限には、機能権限とデータ権限が含まれます。
機能権限とは、ページ権限、メニュー権限、ボタン権限などを含む、システム実行権限制御の基本単位です。
データ権限には、基本データ、業務データ、リソースデータなどが含まれます。
機能モジュールに対するユーザー権限の分割は、大まかな分割です異なるユーザーが同じデータを表示できますが、実行できる操作は異なります。たとえば、オンライン データベース内のデータはスーパー管理者のみが削除でき、他のユーザーは表示のみ可能です。データに対するユーザーの権限を分割することは、細かい制限です。粒度分割方式で、運用管理者は部門全体のデータを見ることができ、運用担当者は自分が作成したデータしか見ることができないなど、異なるユーザーが同じページ/メニューに入ると、見えるデータが異なります。アクセス許可を設計するときは、まず機能アクセス許可とデータ アクセス許可の境界を区別する必要があり、便宜上この 2 つを組み合わせないでください。
2. 権限管理が必要な理由
- 仕事の責任
- データセキュリティのニーズ
3. パーミッション設計の核となる考え方
権利管理とは、ユーザーが特定のリソースにのみアクセスできるように制御するためのシステムであり、この定義によれば、次の図を描くことができます: ユーザーとリソースは複雑なマッピング関係を形成しており、管理が困難であることがわかります
。この問題を解決するには、2 つの方法があります。1 つはユーザー/リソースの数を減らすことですが、これは明らかに非現実的であるため、残された方法はマッピング関係を減らす 1 つだけです。
この方法を詳しく紹介する前に、データベースのクエリが遅いという問題を解決する方法を見てみましょう。[35、27、48、12、29、38、55] という順序で 55 という数字をすばやく見つけるにはどうすればよいかという質問について考えてみましょう。
ほとんどの人の最初の反応は 1 つずつたどることなので、合計 7 つのクエリが必要になります。データベース エンジニアの場合、まずこの配列セットの表現関係を構築するための媒体を見つけます (下の図を参照 - バランスの取れた二分木)。次に、単純な判断により、わずか 3 回で 55 を見つけます。この媒体はデータベース内のインデックスであり、データの量が膨大な場合、クエリにインデックスを使用する利点は非常に明白です。
この例がわかりにくい場合は、辞書の索引、書籍の目録、図書館の棚ラベルなどを思い浮かべてください。オブジェクトのパブリック属性を抽象化して分類管理を行うことが中心的な考え方です。 。
この考え方を使って、ユーザーとリソース間のマッピング関係を減らす方法を振り返ってみましょう。
- ユーザー間に共通の属性があるかどうかを判断しますか?
- 部門、役職など、権限に影響するパブリック属性を見つけます。
- 仲介者を継続的に排除する
リソースについても同様です。
上記の手順を実行すると、元は混沌としたマッピング関係が単純化され階層化され (下図を参照)、抽象化された仮想メディアにアクセス許可を割り当てるだけで済み、管理の複雑さが大幅に軽減されます。
4. 権限管理モデルの進化
権限設計の核となる考え方を理解した後、CMS システムの更新を例として、権限管理モデルの進化を説明します。
1. ACL: ユーザーベースの権限管理モデル
Xiao Wang は新興企業のプロダクト マネージャーで、CMS システムの設計を担当しています。当初、Web サイトのすべてのコンテンツは、同社の唯一の運営者である Xiaohong が担当していたため、Xiaowang は Xiaohong のアカウントに対するすべての権限を有効にしました。
権限をユーザー アカウントに直接バインドするこの方法は、ユーザーベースの権限管理 (ACL) と呼ばれます。
2. RBAC: 役割ベースの権限管理モデル
運用部門の継続的な発展と成長に伴い、新しい従業員が仕事に加わるたびに、Xiao Wang はその従業員の権限を個別に構成する必要があり、バッチで変更することはできず、非常に面倒です。同時に、Xiao Wang 氏は、運用部門には明確な分業があり、一部の担当者が内容のレビューを担当し、その担当者に監査管理権限を与える必要がある、つまり反復的な作業であることにも気づきました。そこで Xiao Wang は、既存のユーザー レイヤー上の別のレイヤーであるロール レイヤーを抽象化したいと考えました。ロールに権限が設定されている限り、そのロールに属する担当者は自動的にこれらの権限を持ちます。
アクセス許可をロールにバインドし、ロールをユーザー アカウントに割り当てるこの方法は、ロールベースの権限管理 (RBAC) と呼ばれます。このモデルは 1992 年に米国標準技術研究所によって開発され、現在最も一般的です。権限管理モデルにより、多額の権限維持費。
ジョージ メイソン大学の教授である Ravi Sandhu は、1996 年に RBAC モデルを改良し、RBAC0、RBAC1、RBAC2、RBAC3 の 4 つのモデルを含む RBAC96 モデル ファミリを提案しました。上の図は RBAC0 モデルを表しており、他の 3 つのモデルの基礎でもあります。
a. RBAC1: 役割継承の RBAC モデル
CMS システムを一定期間使用した後、Xiao Wang は新しい問題を発見しました - 異なる権限を持つユーザーがシステムに参加する限り、新しいロールを作成する必要があるため、システム内にロールが多すぎるということです。これは ACL よりもさらに複雑なので、Xiao Wang はこの問題を解決したいと考えています。
彼をクリックすると、COO > 運用マネージャー > 運用スーパーバイザー > 運用チーム リーダー > 運用担当者 > 運用インターンなど、組織構造と同様の役割間に上司と部下の関係があり、上司が部下のすべての権限を持っていることがわかります。 、さらに他の権限を持つことができるため、既存の役割に基づいて役割レベルの別の層を抽象化しました。
このような、ロールに従属-従属関係を導入する RBAC モデルは、ロール継承の RBAC モデル (RBAC1) と呼ばれ、ロールをグレーディングすることにより、上位のロールが下位のロールの権限を継承できるため、権限管理がある程度簡素化されます。
また、ロール間の継承関係は、一般継承関係と限定継承関係とに分けることができる。一般的な継承関係では、ロール継承関係が絶対半順序関係である必要があり、ロール間の多方向継承が可能です。つまり、下位レベルのロールが複数の上位レベルのロールを持つことができ、上位レベルのロールも複数の上位レベルのロールを持つことができます。複数の下位レベルの役割。制限された継承関係では、ロール継承関係がツリー構造であることが必要であり、ロールは一方向にのみ継承できます。つまり、下位ロールは上位ロールを 1 つだけ持つことができますが、上位ロールは複数の下位ロールを持つことができます。
b. RBAC2: 役割が制限された RBAC モデル
しばらくして、運用マネージャーのシャオホンさんは、シャオワンさんのアカウントで会社の財務請求書が実際に確認できると報告しましたが、検証の結果、シャオホンさんのアカウントに財務マネージャーの役割を追加したのはシャオワンさんの不注意だったことが判明しました。このリスクを完全に回避するために、Xiao Wang 氏は開発者に判断を追加するよう求めました。ロールが運用マネージャーである場合、同時に財務マネージャーであることはできません。
この役割ベースの制限モデルは役割制限 RBAC モデル (RBAC2) と呼ばれ、特に静的義務分離 (SSD) と動的義務分離 (DSD) に分類できます。
SSD：
- 相互に排他的なロール: 同じユーザーは、相互に排他的なロールのセット内の最大 1 つのロールにのみ割り当てることができます。たとえば、ユーザーは会計と監査の 2 つのロールを同時に持つことはできません。
- カーディナリティ制約: ユーザーが持つことができるロールの数は制限されており、ロールに割り当てることができるユーザーの数は制限されており、ロールに対応する権限の数は制限されています。
- 前提条件のロール: ユーザーが上位レベルのロールになりたい場合は、まずゲーム内でのジョブ変更などの下位レベルのロールになる必要があります。
DSD: ユーザーが複数のロールを持つことができますが、実行時にアクティブ化できるのは BOSS 直接採用などの一部のみです。ユーザーは採用担当者と応募者の両方になることができますが、同時に操作する ID は 1 つだけ選択できます。
c. RBAC3: 統合 RBAC モデル
RBAC3=RBAC1+RBAC2。これは、ロール間の継承関係を導入するだけでなく、ロール制限関係も導入します。
d. グループ: 完璧な RBAC モデル
既存の権限管理モデルは、「役割」レベルは最適化されていますが、「ユーザー」側は最適化されていません。つまり、新入社員が採用されるたびに、Xiao Wang はその人の権限を個別に設定する必要があり、これは依然として非常に困難です。面倒なので、抽象的な考え方を使って同じ属性のユーザーを分類します。会社では、最も単純な共通属性は「部門」です。役割と権限が部門に割り当てられている場合、この部門のすべてのユーザーが部門の権限を持つことになり、各ユーザーに個別に役割を指定する必要はありません。
ユーザーはグループ化でき、権限もグループ化できます。特に権限の数が多い場合、同じレベルの権限を 1 つの権限グループにまとめることができます (たとえば、第 2 レベルのメニューの下に十数個のボタンがあります)。ボタン操作にロール制限がない場合は、 , これらのボタンのアクセス許可は、第 2 レベルのメニューのアクセス許可と組み合わせることができます。アクセス許可グループに結合し、そのアクセス許可グループをロールに割り当てます。
「グループ」の概念の導入により、RBAC モデルが改善され、実際のビジネスに近くなり、理解しやすくなり、操作が簡素化されます。
3. ABAC: 属性ベースの権限管理モデル
コンテンツの安全性を確保するため、運用管理者の暁紅氏は暁王氏に対し、コンテンツ管理担当者はコンテンツを社外に公開しないという要件を提起した。Xiao Wang はこれに困惑しました。既存の RBAC 権限モデルでは、ページ/関数/データに対する権限しか付与できず、そのようなきめ細かい権限制御を実装できないからです。関連情報を調べた結果、Xiao Wang はこの問題の解決策である属性ベースの権限管理モデル (ABAC) を見つけました。
ABACは、ユーザー属性（性別や年齢など）、環境属性（時間や場所など）、操作属性（編集や削除など）、オブジェクトなど、1つまたは複数の属性が特定の条件を満たすかどうかを動的に計算することによって認可の判断を行います。属性 (記事など)。
ABAC は RBAC と比較して非常に柔軟な権限制御を実現でき、拡張性も高く、ほぼあらゆるニーズに対応できます。ただし、設計が複雑であり、単一の属性に対する簡単な判定ロジックを記述するだけで置き換えられるため、あまり普及していません。
5. 権限管理と権限体系
権利管理とは、特定の権利分配の問題を解決するために採用される方法を指します。たとえば、ACL モデルはファイルの権利分配の問題を解決するために使用でき、RBAC+ABAC はさまざまな年齢グループのユーザーが必要とする問題を解決するために使用できます。さまざまな種類の映画にアクセスできます。
権限システムとは、システム全体で使用される権限管理方法の集合を指します。
六、権限設計の誤解
1. RBAC 理論のみ
RBAC は広く使用されていますが、それでも最初から使用することは避ける必要があります。権限の設計では、データ量とビジネスの複雑さを評価する必要がありますが、推定されるデータ量が非常に少なく、ビジネスが非常に単純である場合は、他の方法を使用できます。
2. 自由割り当て理論のみ
柔軟でユーザーに割り当て可能な権限を設定するだけで満足するとは考えないでください。実際、ユーザーはそれほど賢明ではありません。ロール名に苦労したり、一連の権限構成を見たときに途方に暮れたりするでしょう。ビジネスで固定ロールと統一された権限を抽象化できる場合は、それらを組み込みます。
3. 権限は多ければ多いほど / 細かいほど良い
権限は機能のリストではないため、実際の業務を考慮せずにやみくもに権限を調整すると、開発の負荷が増大するだけであり、ユーザーの構成には役立ちません。権限設定としてよく使うファンクションポイントだけを選択したり、「追加・削除・変更」の3つの機能を1つの「管理」権限ポイントに抽象化するなど、複数のファンクションポイントを1つの権限ポイントに抽象化することもできます。
第 2 章: RBAC 権限設計の一般的な手順
1. 役割を整理する
1.すべての文字をリストする
ロールは抽象的なアイデンティティであり、RBAC はロールと切り離せないものであるため、最初のステップは、ビジネスに関与する可能性のあるすべてのロールを見つけることです。
企業の内部管理システム (ERP、OA など) に取り組んでいる場合は、組織構造を参照してすべての役割 (製品マネージャー、製品アシスタント、プロジェクト リーダーなど) を見つけることができます。他のシステムでは、ビジネスを通じて関連する役割を見つけることができます。筆記試験の受験プロセスに応じて、問題教師、問題検討教師、試験室管理者、補助者、試験監督、巡回教師、受験者、採点教師が必要となります。
2. キャラクター間の関係性を見つける
すべての文字を見つけたら、次のステップは文字間のつながりを見つけることです。一般的なものは継承、相互排除、共有関係であり、実際のビジネスに基づいてロール間のその他の関係も見つけることができます。
- レベル/後継者: プロダクト ディレクター、プロダクト マネージャー、プロダクト アシスタント、プロダクト インターン
- 相互排除: 財務と監査を同一人物にすることはできません
- 共有: 採点教師と監督者は同じ人でもかまいません
- シリアル: 最初にプロダクト マネージャーによって設計され、次に開発者によって開発されました。
- 並行: フロントエンドとバックエンドの共同開発
- ……
3. ロールを組み込む必要があるかどうか、およびロールを非表示にする必要があるかどうかを分析します。
どの役割を分析するか、どの役割をユーザーがカスタマイズできるかを事前に決定できます。組み込みロールは、ロールが共通、固定、頻繁に使用される状況に適用され、ユーザーの操作手順を簡素化することを目的としています。「管理者」ロールはビルトインされている場合や、実際の業務に合わせて選択できる場合が多く、例えばオンライン試験システムでは「受験者管理」メニューがビルトインロールとなっており、アカウントが追加されています。リストは「候補」のみです。
また、システムによっては「スーパー管理者」など、ユーザーにロールを表示する必要がない場合も考えられます。
2. 権限を組み合わせる
1. 機能権限を整理する
権限は機能権限とデータ権限に分けられ、機能権限はさらにメニュー権限とボタン権限に分けることができます。
機能の権限を整理する最も簡単で実用的な方法の 1 つは、「機能リスト」を使用することです (次の図では例として「Youzan」を使用しています)。
2. データ権限を整理する
データ権限とは、システム内に存在するデータとリソースを表示および管理できるユーザーを指します。データのアクセス許可に関して言えば、データベースについて言及する必要があります。
1) テーブル/オブジェクト
テーブルとは、データベース内のすべてのデータを格納するデータベース オブジェクトであり、下図に示すように、上から受験者テーブル、試験室テーブル、試験官テーブルの順に、異なる業務データが存在します。
2) データ
テーブルには行と列からなる二次元のデータが格納されており、下図に示す被験者テーブルでは、各行が被験者を表し、各列が被験者の属性を表しています。
テーブルとデータの関係により、データ権限は次の 4 つの状況に分類できます。
(1) システムベースのデータ権限
つまり、システム内のすべてのテーブルは誰でも閲覧および管理できますが、データ権限がないことも理解できます。たとえば、管理者 A と管理者 B は、すべての受験者、試験官、および試験室のデータを閲覧および管理できます。
(2) オブジェクトベースのデータ権限
つまり、管理者 A は受験者の管理のみを担当し、管理者 B は試験室の管理のみを担当するなど、テーブルに従ってデータの権限を分割します。
(3) 行ベースのデータ権限
つまり、データ権限はテーブル内のデータ行に従って分割されます。たとえば、管理者 A は学校 B の候補者のみを管理できますが、学校 C の候補者は管理できません。または、部門 A のマネージャーは週次レポートのみを参照できます。 A部門のスタッフです。
(4) 列ベースのデータ権限
つまり、テーブルのデータ列に従ってデータ権限が分割され、たとえば、管理者 A は候補者の名前のみを参照でき、管理者 B は候補者の名前、携帯電話番号、ID 番号を参照できます。
データ権限を整理する際、オブジェクト、行、列のデータ権限を実際の業務に合わせて自由に組み合わせることができ、例えばA校の管理者はA校の受験者と試験官の名前と電話番号のみ閲覧可能、ただし、ID 番号は表示できません。必要に応じて、行ベースと列ベースのデータ権限が使用されます。
3. 接続の役割と権限
1. 接続の役割と機能権限
機能リストを取得したら、ロールと関連付ける必要がありますが、テーブルの後に直接ロール列を追加し、ロールが業務に応じた機能権限を持っているかどうかを判断できます。
2. 接続の役割とデータ権限
データ権限は通常、一連のルールであり、テキストの説明を通じて上の表に付加できます。
3. 分析と整理
すべての権限を割り当てる必要がありますが、すべての権限をユーザーが構成する価値があるわけではありません。
前のステップが完了すると、すべての役割と権限の関係が確立されましたが、上記の表を直接使用することはできません。詳細設計の前に、どの権限をユーザーが手動で割り当てる必要があり、どれが手動で割り当てる必要があるかを分析する必要があります。いいえ？ユーザーアクションの数を減らすためにどの機能権限を組み合わせることができますか? どのようなシナリオでデータ権限を構成可能にする必要がありますか? など、具体的な業務に応じて判断する必要があります。
「Youzan」を例に挙げると、上の写真は実際に「リード管理」機能の権限を設定するページで、ユーザーに「表示、編集、転送、破棄、データ項目の追加、試聴」のみを提供していることがわかります。機能、およびその他の機能の権限は、「表示」(追加、登録など) に関連付けられるか、1 つの機能に統合されます (「一括転送」は「転送」に統合されます)。
理論的には、すべての機能権限をユーザーが構成できるようにすることができますが、ユーザー エクスペリエンスを考慮すると、権限を分析して整理することが非常に必要です。
第 3 章: 機能権限を設計するための 3 つのコツ
上記の分析を通じて、役割と権限の間の最終的な関係が得られ、インターフェイスの設計方法のリンクが入力されます。
機能権限の設計は、ユーザー管理、ロール管理、権限管理という最も基本的な 3 つの要素から切り離すことができませんが、ビジネスによっては、より複雑な部門管理、役職管理、メニュー管理の 3 つの要素が関係する場合もあります。顧客のさまざまなニーズに合わせてバージョン管理が必要となるため、その管理機能の設計方法について詳しく説明します。
1. トリプルアックス - 基本編
1. 権利管理
権限管理は、ロールに権限を付与することです。権限は、組み込みまたはユーザー定義にすることができます。権限の構成は、役割に結び付ける必要があります。権限が比較的単純で比較的固定されている場合、バックエンド担当者は、権限を次のように書き込むことができます。コードまたは code. 設定ファイル内。
2. 役割管理
「役割の整理」ではシステムに関わるすべての役割をリストアップし、これらの役割をオンライン上でミラーリングして管理するのが「役割管理」です。
ロールのソースに応じて、ユーザー定義ロールとシステム組み込みロールに分類できます。
カスタム ロール: ロールの名前と権限はユーザーが自由に構成でき、任意に変更できます。
組み込みロール: ロールの名前と権限はシステムによって組み込まれており、ユーザーは表示のみでき、変更できません。
「ロール管理」の設計には主に次の 3 つのページがあります。
- ロール リスト ページ: システム内のすべてのロールを表示します。少なくともロール名と、クエリ、削除 (カスタム ロール)、表示 (組み込みロール)、追加、編集などの操作を表示します。
- ロールの追加ページ: 繰り返し不可のロール名を入力する必要があり、ステータス、メモ、並べ替え、その他の情報を入力できます。インタラクション モードに関しては、ページ コンテンツの豊富さに応じて、ポップアップ ウィンドウまたはドロワーの形式を選択できます。
- [アクセス許可の構成] ページ: ロールの作成中にアクセス許可を構成することも (上の図を参照)、ロールの作成後にアクセス許可を構成することもできます (下の図を参照) 2 つの方法に本質的な違いはありません。
さらに、一部のシステムでは、バインドするアクセス許可のキャリアは「ロール」ではなく、DingTalk の「管理グループ」などの別の名前で呼ばれますが、ここでは実際には「ロール」であることを明確にする必要があります。
3. ユーザー管理
「ユーザー管理」は、ユーザー役割の変更、ユーザーの作成・削除、パスワードやユーザー情報の変更など、ユーザー情報を管理するために使用します。
「ユーザー管理」の設計には主に 2 つのページがあります。
- ユーザーリストページ: システム内のすべてのユーザーを表示します。追加、編集、削除、エクスポート、インポート、およびバッチ操作をサポートする必要があります。
- ユーザー追加ページ：業務に応じて作成に必要な項目を選択します。ユーザーを追加するときは、ユーザーにロールを設定する必要があります。オプションのロールには、カスタム ロールと「ロール リスト」に存在する組み込みロールが含まれます。
「権限の割り当て」と同様に、「ロールの割り当て」もユーザーリストの操作に個別に配置することができ、この種の対話はより具体的になりますが、実際には違いはありません。
4. 注意事項
1) ユーザーと役割
実際のビジネスに基づいて、ユーザーにいくつのロールをバインドできるかを決定する必要があります。複数のロールをバインドできる場合、ロール間に継承や排他などの関係があるかどうか、機能権限をどのように分割するかなどを事前に考慮する必要があります。
また、組み込みロールがある場合は、社内の「運用管理基盤」上で「組み込みロール」専用の管理機能を設計することも忘れないでください。
2) キャラクター同士の関係性
上記ではロール間の関係（階層・継承、排他、共有など）を列挙しましたが、既存の「ロール管理」では1人のユーザーに複数のロールをバインドすることでしか「ロールの共有」を実現できませんが、そのような方法はありません。ロール間の継承と相互排他を実装します。
ロール間に継承関係がある場合は、後述の「ロールグループ（ポジション）管理」により実現でき、相互に排他関係がある場合（会計と監査など）は、組み込みロールをハードコーディングできます。コード内で、カスタム ロールの場合、ユーザーがミューテックス ルールを追加設定できるようにすることができます。
3) 権限グループ
上記の分析と並べ替えは、実際には、不要な権限をマージするための権限グループの作成であり、ユーザーの操作を簡素化できます。
上記の手順を完了すると、シナリオの 80% に対応できる基本的な権限システムが設計されます。
2. 3 軸 - 上級バージョン
OA システムの権利管理を行っている場合、または柔軟性に対する高度な要件がある場合は、権利管理の 3 つのトリックの上級バージョンについて学ぶことができます。
1.部門管理
「部門管理」には3つの利用シーンがあります。
1 つ目は企業の組織構造を構築する場合であり、この場合、部門管理は機能権限とは関係がなく、ユーザーの分類とデータ権限の割り当てにのみ使用されます。
次の 2 つのシナリオは、機能権限に関連しています。
2 番目のシナリオは、「ユーザー グループ」の役割を引き受けることです。上記で紹介したRBACでは、ユーザー数が多い場合、各ユーザーにロール権限を対応付けるのが非常に面倒になるため、その際にユーザーの共通属性を抽象化する必要があります。ユーザーは部門ごとに表すことができます。
3 番目のシナリオは、「ロール」の役割を引き受ける場合で、部門に機能権限を直接割り当てることができ、部門内のユーザーは部門の機能権限を継承します。ユーザーが他のロールの権限も持っている場合 (下図のユーザー 2)、実際の機能権限は 2 つの権限を組み合わせたものになります。
さらに、部門の権限を割り当てるときは、サブ部門と親部門の間の権限関係も考慮する必要があります。親部門の権限を一貫して維持することを選択することも、サブ部門がその権限を継承するように選択することもできます。ビジネスの複雑さに応じて、親部門の権限とはまったく異なる権限を設定することもできます。
2. ジョブ管理
ジョブ管理には 2 つの使用シナリオがあります。1 つ目は、従業員情報を改善することです。これは属性であり、機能権限とは関係ありません。
2 番目のシナリオは機能権限に関連しており、「役割グループ」の役割を引き受けることです。「ロール グループ」は、上司と部下の関係を満たすために派生した概念です。たとえば、「プロダクト マネージャー」は、「プロダクト アシスタント」のすべての権限を持っている必要があります。すべての機能権限を設定します。単に「」の親にするだけです。 Product Manager」の役割を追加し、いくつかの特別な権限を追加します。
3. メニュー管理
「部門」であれ「役職」であれ、より柔軟に「ユーザー」や「ロール」をどう設定するかという課題を解決することです。RBAC には「アクセス許可」もあります。現在のアクセス許可の管理では、バックエンド担当者がコードまたは構成ファイルにアクセス許可を記述できることのみが導入されています。機能のアクセス許可が頻繁に変更され、自由な構成の要求が非常に高い場合は、 , アクセス許可をより柔軟に管理する方法はありますか? もつ！それは「メニュー管理」です。
「メニュー管理」はリソース管理とも呼ばれ、システムリソースの外部表現です。「メニュー管理」を使用すると、権限の管理が容易になる (バックエンドをハードコーディングする必要がない) だけでなく、システムの表示がより柔軟になります (メニュー情報を変更できます)。
メニューは 3 つのカテゴリに分かれています。
- ディレクトリ: システム内に実際のページはありません
- メニュー: 実際のページが存在します
- ボタン: メニュー内の実行可能な項目
「メニュー マネージャー」の設計には、次の 2 つのメイン ページがあります。
1) メニューリストページ:
ナビゲーションメニューは上位階層と下位階層に分かれており、ツリー図で表すことができます。共通のメニュー属性には、メニュー名、メニュータイプ（ディレクトリ、メニュー、ボタン）、アイコン、ソート、ルーティングアドレス（ブラウザアクセスメニューのアドレス）が含まれます)、コンポーネント パス (プロジェクトのコンポーネント ファイルのパス)、権限の識別 (表示、編集、追加など)、外部リンクかどうか、有効なステータス、および作成時刻。図に示したフィールド以外にも、業務に応じて「番号、新規ページを開くかどうか、非表示にするかどうか、キャッシュするかどうか（他のメニューに切り替えると現在のメニューがキャッシュされる）」などのフィールドを追加することができます。ニーズ。
2) メニューページを追加:
ディレクトリの追加: ディレクトリは外部リンクにすることができます。つまり、クリックして外部アドレスにジャンプします。https:// または http:// を含める必要があります。外部リンクでない場合は、開発者によって与えられるルーティング アドレス。
メニューの追加: メニューが外部リンクの場合、ルールはディレクトリと同じです。外部リンクでない場合は、コンポーネント名、権限識別子、およびコンポーネントのパスを入力することを選択できます (詳細については議論する必要があります)開発システムを使用して、それが関係しているかどうかを確認してください)。
ボタンの追加: ボタンを追加する場合は、権限 ID を入力するだけです。
4. 注意事項
1) 誰が誰を相続するか
「権限の継承」に関して、注意深い読者は、最初の章で RBAC を紹介したときに、「高レベルのロールは低レベルのロールの権限を継承できる」と書き、この章でも次のように述べたことに気づくでしょう。部門は親部門を継承できます。権限」に競合がありますか。
実はそうではなく、ABという2つの部署があり、その上にCという部署が設置されるとすると、Cという部署の権限はABの2つの部署を合わせたものになります。 C 部門は AB 部門の権限を継承し、C 部門は個別に権限を設定することもでき、C 部門を A 部門に割り当てる場合、C 部門は A 部門の権限を継承し、その範囲内で権限を絞り込むことができます。2 つの式の意味は同じで、両方の子レベルは親レベルの権限に属します。
2) 機能権限は複数のエンティティに関連付けないことが最善です
上記の紹介では、「部門」と「役職」は機能権限を直接バインドする「役割グループ」として機能しますが、実際にはこのように設計されているシステムはほとんどありません。根本的な理由は、それが不要であるためです。機能権限が最適です。 1 つのエンティティにのみ関連付けられるため、システムにすでに「役割管理」(役割に対する機能権限の設定) がある場合は、部門や役職に機能権限を設定する必要はありません。役職に権限を設定すると、 「役割」という概念を導入する必要はありません。実際の仕事では、部門、役職、役割ごとに個別の機能権限を持っている人はほとんどいませんが、たとえ持っていたとしても、新しい「役割」を作成することで複雑さを簡素化できるからです。現在のほとんどの OA システムでは、ユーザーの分類とデータ権限の管理に役職と部門がよく使用されています。
3) メニュー管理は権限グループをどのように実装するか
「メニュー管理」はシステム内の最小の操作であり、役割の権限を割り当てるために直接使用できますが、ユーザー エクスペリエンスを向上させるためには、機能権限を組み合わせてユーザーに表示する必要があることに注意してください (図を参照)以下）、「メニュー管理」に「表示と操作」のボタンを直接設定することはできませんが、「メニュー管理」の上にユーザーに表示する機能権限のレイヤーを構築する必要があります。 「操作」権限がバインドされている「新規+編集+削除」ボタン。
5. 拡張: バージョン管理
SAAS ソフトウェアの場合、さまざまなレベルの顧客のニーズを満たすために複数のバージョンに分割されることがよくあり、異なるバージョン間の機能権限は異なります。このような状況に対して、「バージョン管理」を行うことで柔軟な管理が可能になります（この「バージョン」は製品の反復バージョンではありません）。
設計「バージョン管理」には主に 2 つのページがあります。
- バージョン一覧ページ: バージョン情報が一覧表示されます。
バージョン機能の権限設定ページ: ロールへの権限の割り当てと同様ですが、ここではバージョンへの権限の割り当てとして理解できます。違いは、ここでの機能権限が「メニュー管理」のものよりも詳細であることです。「トピック管理」を例に挙げると、通常「メニュー管理」では第1階層のページに「トピックの追加、インポート、削除、編集」ボタンのみが設置されますが、バージョン管理では以下のように絞り込まれます。無料などトピックの種類 このバージョンでは「リスニング問題」の追加はできず、機能の利用回数にも制限があります。この要件を解決するには、2 つの設計ソリューションがあります。各バージョン間の権限が細かく分割されており、多くの場合 (このセクションの最初の図、テスト スターのバージョン機能比較を参照)、それを でカバーするのが最善です。メニュー管理 すべてのサブページのボタンが使用可能で、使用可能回数は別のルールで制限されますが、バージョン間の個別の軽微な機能の違いのみであれば、既存の「」に基づいて制限ルールを追加するだけで十分です。メニュー管理」機能。
さらに複雑な状況では、同じバージョンの異なるクライアントでも異なる機能権限が与えられるため、クライアントごとに機能制限を構成することも必要になります。
第 4 章: データ権限を設計する方法
前述したように、データ権限は 4 つの状況に分類されます (分類の基礎については第 2 章を参照)。
- システムベースのデータ権限
- オブジェクトベースのデータ権限
- 行ベースのデータ権限
- 列ベースのデータ権限
このうち、「システムベースのデータパーミッション」は、誰が見ても操作できるものは同じであるため、データパーミッションに関係なく理解できますが、「オブジェクトベースのデータパーミッション」は、ユーザーAに次のような権限を割り当てるなどの機能的なパーミッションによって実現できます。顧客テーブルの権限が付与されると、A はすべての顧客を参照して操作できるようになります。これは、ユーザー A に「顧客管理」の機能権限を割り当てるのと同じです。したがって、以下では後者の 2 つのケースを中心に説明します。
さらに、データ権限の割り当ても、組み込みとユーザー定義の 2 つのタイプに分類できます。組み込みのデータ権限は、システムのハードコーディングされたルールに属します。たとえば、この学校の教師は自分の学校のリソースのみを表示でき、公共図書館のリソースはすべての学校の教師が表示でき、営業担当者が作成した見込み客も表示できます。組み込みデータのアクセス許可は単純すぎるため、この記事の範囲を超えています。
1. 行ベースのデータ権限
行ベースのデータ権限には 2 種類あり、1 つはオブジェクト (部門/役割) にデータを割り当てるもので、上位部門は下位部門のすべてのデータを管理できます。また、データをオブジェクトに割り当てることもできます。共有ファイル。
1. オブジェクトにデータを割り当てる
1) 組織構造がない
組織構造を必要としないシステムの場合、データ権限の設計は比較的単純であり、ロールの権限を設定する場合は、割り当て可能なデータ権限を表示するだけで十分です。
データ権限を割り当てる前提は、対応する機能権限を割り当てることです。たとえば、コンピュータ教師が「ソフトウェア エンジニアリング」のすべてのトピックのみを管理できるようにするには、その教師に対して「試験バンク管理」の機能権限を有効にすることが前提となります。先生には「試験バンク管理」さえありません。それが表示されません。どうすればその中のトピックデータを管理できますか。もちろん、機能権限を手動で割り当てる必要はなく、組み込みも可能です。たとえば、Blue Lake では、追加されたメンバーはデフォルトで「チーム ファイル」メニューを開くため、データ権限リストのみを設定する必要があります。設定中に表示されます。
2) 組織構造
「管理範囲」を設定することで、上位と下位間のデータ権限制御を実現します。例えば、上司が部下の問題バンクを閲覧できるようにするという要件に対して、「部門リーダー」ロールを設定し、管理範囲を「部門とその下位部門」として設定し、会社リーダーと部下を追加することができます。各部門の責任者がこの役割に就けば、この要件を満たすことができます。
「管理範囲」を設定することで、部門を越えたデータアクセス制御も実現できます。例えば、研究開発部門の担当者がIT部門のトピックスを参照できる場合は、新規ロールを作成し、管理範囲として「特定の部門」を選択し、「研究開発部門とIT部門」にチェックを入れることができます。
「管理範囲」を設定することで、同一部門間のデータ権限制御も実現できます。たとえば、製品部門では、製品チームのリーダーは部下が作成したトピックを表示できますが、製品ディレクターが作成したトピックは表示できず、製品アシスタントは自分が作成したトピックのみを表示できます。位置関係を利用する必要がある。
2. オブジェクトをデータに割り当てる
これは、特定の役割/部門にデータを直接共有するものとして理解でき、ファイル/リソースの共有によく使用されます。
2. 列ベースのデータ権限
データ権限が機能権限の垂直方向の拡張である場合、フィールド権限は水平方向の拡張です。データ列の権限を設定すると、指定されたロールによる ID 番号や取引金額などの特定の機密フィールドへのアクセスが禁止される可能性があるためです。
「列の権限」を設計するには、次の 2 つのメイン ページがあります。
- 入り口：ロールの作成時にまとめて設定することも、ロール単体の操作として使用することもでき、「ロール管理」で全ロールに一括で設定することもでき、対応するメニューページで設定することもできます。
- 列権限設定ページ: 以下の図は、すべてのロールに対して列権限を一括で設定する設計を示しており、さまざまな機能権限を持つロールと、ユーザーが確認できるこのメニューのフィールドがリストされています。
