はじめに: 権限設計は、アプリケーションシステムの権限、データベースのアクセス権限、公文書回覧における承認権限、オペレーティングシステムのファイルアクセス権限、企業内部文書の承認権限、政府機関の承認権限など、プログラマーの 80% が遭遇する問題です。人生、権威はいつでもどこにでもあります。ここで紹介したいのは、アイデアを呼び込む役割を期待して、みんなで議論するための文書のアクセス権に関する設計スキームです。
企業内では、特定の顧客向けの契約文書や設計草案などの一連の物理文書が論理文書を形成し、通常は一連のデータベース設計、ER図、クラス図、アプリケーション・システム設計のオブジェクト図などの文書を作成できます。論理的にはアプリケーションシステムの設計文書と呼ばれます。似たような文書が数百件以上ある場合、社内の文書管理は紙の文書カードを作成して文書を検索することに依存しており、この段階でオンライン文書管理システムが企業のニーズとなります。。
オンライン文書管理システムの主な目的は、ユーザーが文書を管理し、相互に通信できるようにすることですが、誰もが文書を表示したり変更したりできるわけではありません。ここでは権利管理が極めて重要な問題になります。これらは私のドキュメントです、同じ部門の同僚は私のドキュメントに対してどのような権限を持っていますか、他の人は私のドキュメントに対してどのような権限を持っていますか、他の部門の人々は私のドキュメントに対してどのような権限を持っていますか、特定の人または特定の部門に、私のドキュメントに対する特定のアクセス許可を与えることができます。この記事では、これらの問題に対する解決策を提供します。ユーザー設計や部門設計などの必要な要素の一部については、この記事では説明しません。すでに比較的適切に設計されているものと想定しています。著者は、UNIX 権限設計のいくつかのアイデアを参照して、これらの問題を議論し、解決します。2 つの部分に分かれています:
最初の部分では、アクセス許可の種類について説明します。ドキュメントごとに、ドキュメントの名前、作成者などの次のドキュメント情報を入力し、添付ファイルを追加する必要があります。ドキュメントに対する操作には、ダウンロード、削除、変更、表示の 4 種類があります。たとえば、ファイルをダウンロードする場合は、ダウンロード権限が必要ですが、その前に閲覧権限が必要であり、閲覧権限がないとダウンロードできません。ファイルの再アップロードなど、一部の情報には変更権限が必要です。これら 4 つの許可は 4 ビットで置き換えることができます。1 は許可を意味し、0 は許可なしを意味します。たとえば、最初のビットはダウンロード、2 番目は削除、3 番目のビットは変更、4 番目のビットは view である場合、1111 にはすべてが含まれます。 0000 はアクセス許可を意味し、0000 はアクセス許可がないことを意味します。このようなバイナリビットは 16 進数でデータベースに格納できます。たとえば、0..A..F を使用すると、データベース内のストレージは 1 バイトのみになります。アクセス許可を追加する必要がある場合は、このアクセス許可を上位の位置に追加します。JavaのIntegerクラスではシフト演算が便利に行えます与えられたパーミッションの2進数に対して、対応するビットに対して&演算を行い、判定結果が0より大きい場合にパーミッションがあるかどうかが分かりますたとえば、1010 と 0010 が & 演算を実行した場合、結果が 0 より大きい場合は、変更する権限があることを意味します。権限を増やす必要がある場合は、元の権限を取り出し、対応する権限ビットに対して OR | 演算を実行してから格納します。これは Unix 権限の設計と一致しています。
後半では、ユーザーが一意の ××× ID 番号を持ち、各部門が ××× ID 番号を持っていると仮定して、どのように認証するかを説明します。従業員 1,000 人の企業の場合、数百の部門があり、その平均 ID 番号はの長さは 3 ビットであると仮定できます。文書の記録には、文書が誰のものであるかを示すために、文書の所有者 (所有者) の番号を記入するフィールドを追加する必要があります。同時に所有者の部門番号（部門）も追加され、同じ人が 2 つの部門に勤務していた場合、異なる期間の文書は異なる部門に属することになります。これらの後に、文書所有者の権限フィールド (ownerAuth) が必要です。これには 1 バイトの権限情報が格納されます (権限が 4 つしかないと仮定します)。同じ部署の人が操作を閲覧したり、変更したりする必要がある場合が多いため、検索を容易にするために、同じ部署の権限(deptAuth)を同じく1バイトで追加し、さらに他人の権限も持たせる必要があります。ドキュメント (otherAuth) は、通知またはドキュメントテンプレートであると仮定すると、全員に読み取り権限が必要なため、この方法の方が適切です。個人に権限を与える必要がある場合はどうなるでしょうか?部門が個別に権限を与えられた場合はどうなりますか? ここには 2 つのオプションがあります。 1. ドキュメントテーブルと多対 1 の関係を持つテーブルを追加し、ドキュメントを複数の部門または複数の人に承認できるようにします。2. 2 つのフィールド、usersAuth、deptsAuth を追加します。auth の前に s があることに注意してください。これは、複数の人または部門の権限を保存することを意味します。保存されるコンテンツは、100:f、101:A、などの ID 番号と権限です。ID 番号 100 のユーザーが F などのすべての権限を持っていることを示します。単一の個人または部門の承認には 6 バイトが必要であり、1k フィールドの長さですでに 170 を超える権限を承認できることがわかります。これは基本的に操作です。人員の制限により、オペレーターは 1 つのオブジェクトを 170 人または部門に 1 つずつ許可するために暇で退屈することはありませんが、これは確率が低く、実際には無視できます。これら 2 つの方式のうち、筆者は後者を好みますが、長所はクエリの数が少ないこと、短所は許可されるオブジェクトの数が限られていることです。ユーザーが特定のドキュメントに対する特定の権限を持っているかどうかを判断する方法。ここでは、独自の使用法に応じて優先検索順序を設定できます。たとえば、ユーザーがドキュメント A に対する読み取り権限を持っているかどうかを判断するには、ownerAuth-> からアクセスできます。 groupAuth->otherAuth->usersAuth->deptsAuth の優先順位の検索と判定も独自のスキームに従って判定できますが、otherAuth のより一般的に使用されるファイルシステムの場合は、otherAuth の許可判定を最初に置く方が適切な場合があります。これには統一された基準はありません。
以上、文書のパーミッションの設計についての筆者の考えですが、急いでいたので、文章がスムーズかどうかをよく考えずに書きましたが、不明な点や間違っている点がありましたら、アドバイスをお願いします。
-----------------------------------
https://blog.51cto.com/tianli/227217

システム権限 = 機能権限 + データ権限

1. 権限管理が必要なのはなぜですか?

プログラマが入社すると、ネットワークへの接続権限、コードのダウンロードと送信の権限、監視プラットフォームのログイン権限、操作プラットフォームの権限など、さまざまな権限を設定できる人を見つける必要があります。クエリデータ、権限など。

複雑な申請が多くて業務に不便を感じている場合が多く、急にデータを確認したいときに許可申請を行っていないことが判明した場合、再度承認手続きを行う必要があり、時間がかかります。長い時間。では、なぜそこまで厳密な権限管理が必要なのでしょうか？

たとえば、決済会社には業務背景があり、その業務背景からすべての加盟店情報、法定代理人情報、取引情報、料金設定情報を見つけることができます。この情報を審査なしで会社のすべての小規模パートナーに提供すると、誰でも市場を運営する業者は業者のレート情報を操作することができるため、誤ってレートを変更すると多大な損失が発生します。

別の例としては、販売者の情報は機密性が高く、悪意を持った一部のパートナーがこの情報を持ち出して販売者の競合他社に販売することにより、販売者に重大な悪影響が生じる可能性があります。人為的なミスではありますが、情報自体がシステム上に公開されなければ、法令違反や規律違反の発生はかなり回避できます。

一般に、** 権利管理は企業のデータセキュリティを保証する重要な要素であり、立場やレベルが異なれば、見られるデータも異なり、運用データに対する制限も異なります。**たとえば、資金に関連する情報は財務の関連職にのみ公開され、構成に関連する情報は運用の関連職にのみ公開されるため、各部門とその機能は多くの不必要なセキュリティ問題を回避できます。

2.1 権限の設計

業務分類としては、データ閲覧権限、データ変更権限などに分けられ、システム設計におけるページ権限、メニュー権限、ボタン権限に相当します。メニューも第 1 階層メニュー、第 2 階層メニュー、さらに第 3 階層メニューに分かれており、csdn 記事編集ページの左側のメニューバーを例にすると 2 階層のメニューがあります。ページにはメニューに対応するボタンが多数ありますが、デザインする際には、権限をツリー構造に設計するのがベストで、権限を申請する際にメニューの構造が一目で分かり、非常に分かりやすくなります。どの権限が必要かを明確にします。

2.2 ロールが必要な理由

権限の構造を明確にした後、ユーザーに権限を割り当てる方法を考える必要があります。ユーザーが少ない場合は、直接割り当てることができます。1 人のユーザーが複数の権限を持つことができ、1 つの権限を複数のユーザーが所有することができます。権限モデルの構造は次のとおりです。

このモデルは、アクセス許可を割り当てる基本的な機能を満たしていますが、ユーザー数が増加するにつれて、このモデルの欠点が強調されます。すべてのユーザーにアクセス許可を割り当てる必要があり、管理者とユーザーにとって時間と労力の無駄です。許可を与えると、後の段階で莫大なメンテナンスコストが発生します。ユーザー権限対応図：

ユーザー数が多い場合、この対応を維持することは基本的に不可能です。実際、多くのユーザーが同じビジネスモジュールに対して同じ権限を必要としています。この場合、3 番目のメディアを使用してこのメディアに同じ権限を割り当て、ユーザーをそのメディアに関連付けることができます。そうすれば、ユーザーはメディア権限を持つことになります。。これは古典的な RBAC モデルであり、メディアは通常ロールと呼ばれるものです。

2.3 許可モデルの進化

1 基本的な RBAC モデル

ロールを取得したら、そのロールにアクセス許可を割り当てることができます。同じアクセス許可が必要なユーザーをそのロールに関連付けることができます。1 つのアクセス許可を複数のロールに割り当てたり、1 つのロールに複数のアクセス許可を割り当てたり、同じユーザーを割り当てることができます複数のロール。ロールは複数のユーザーに対応することもでき、対応するモデルは次のとおりです。

これは古典的なRBAC モデル (ロールベースのアクセス制御)であり、ロールがユーザーとアクセス許可を接続するブリッジとして機能します。各ロールには複数のアクセス許可を設定でき、各ユーザーに複数のロールを割り当てることができます。複数の役割に対する複数の権限を持っています。

同時に、ロールが媒体として使用されるため、複雑な相互作用関係が大幅に軽減されます。たとえば、数万人の従業員がいる企業では、多くのユーザーが同じ権限を必要とするため、必要なロールは数百だけになる場合があります。はい。このモデルの対応関係図は次のとおりです。

ユーザーとロール、ロールとアクセス許可はすべて多対多の関係にあります。このモデルは最も一般的なアクセス許可管理モデルであり、アクセス許可の維持コストを大幅に節約します。ただし、実際のビジネスは常に変化しており、アクセス許可は管理モデルも、ビジネスモデルに対する適切な調整に基づく必要があります。たとえば、企業の内部組織構造は階層構造になっています。レベルが高いほど、権限は大きくなります。これは、より高いレベルの人々が部下の権限を持っているだけではないためです。、ただし、第 2 フェーズでは追加の権限も持ちます。

RBAC モデルでは、異なるレベルのユーザーに異なるロールを割り当てることができ、より高いレベルの対応するロールには、より多くのアクセス許可が与えられます。この処理方法で問題は解決できますが、より良い解決策はありますか? 答えは間違いなく「はい」であり、RBAC モデルが導かれます。役割の継承。

2.4ユーザーグループの RBAC モデルとロール制限の RBAC モデルの紹介

2.4.1 ユーザーグループ

ユーザー数が多い場合の、ユーザー割り当て権限の煩雑さやユーザーと権限関係の維持コストの高さの問題を解決するために、ロールを作成しました。ロールを抽象化し、一緒に操作する必要がある権限をこのロールに割り当て、そのロールをユーザーに割り当てると、ユーザーはそのロールに対する権限を持つことになるため、ユーザーに 1 つずつ権限を割り当てる必要がなくなり、多くのリソースが節約されます。。

同様に、ユーザーのグループが同じロールを必要とする場合、ユーザーに 1 つずつロールを割り当てる必要があります。たとえば、ある企業にはカスタマーサービス部門に 500 人以上の従業員がいます。ある日、研究開発部門は、バックグラウンドデータをクエリするための製品です。パートナーはそれを使用する必要がありますが、カスタマーサービスはこれまですべてのカスタマーサービスパートナーに統一されたロールを与えていませんでした。現時点では、新しいロールを追加し、このロールに権限を割り当ててから、割り当てる必要があります。 500 人のユーザーに 1 つずつロールを追加するのは非常に面倒だと感じる場合があります。ただし、カスタマーサービス担当者には共通の属性があるため、ユーザーグループを作成し、すべてのカスタマーサービス担当者がカスタマーサービスユーザーグループに属し、カスタマーサービスユーザーグループにロールを割り当て、このユーザーグループのすべてのユーザーに必要な権限を与えることができます。

ユーザーグループを RBAC モデルに追加した後のモデル図は次のとおりです。

ユーザーグループとロールの違いは何ですか? と多くの友人が尋ねるでしょう。簡単に言うと、ユーザーグループはユーザーのグループの組み合わせであり、ロールはユーザーと権限の間の橋渡しをします。 ユーザーグループは、同じ属性を持つユーザーを組み合わせたものです。たとえば、同じプロジェクトの開発、製品、テストをユーザーグループにすることができます。同じ部門の同じポジションの従業員をユーザーグループにすることができます。ユーザーグループは、部門には、さまざまな立場の人々が一緒に働くことができます。

ユーザーをグループ化することができ、権限もグループ化できます。権限が多すぎる場合は、モジュールの権限を結合して権限グループを形成できます。権限グループは、権限とロール間の複雑な対応の問題も解決します。

たとえば、権限を定義する場合、第 1 レベルのメニュー、第 2 レベルのメニュー、およびボタンをすべて権限にすることができます。第 1 レベルのメニューの下には数十の第 2 レベルのメニューがあり、各第 2 レベルのメニューの下には数十のボタンがあります。このとき、ロールに権限を一つずつ割り当てるのも大変なので、グループ化という方法で権限をグループ化し、分割したグループをロールに割り当てることができます。

権限のグループ化も技術的な作業であり、権限間の関係を明確にする必要があります。例えば、決済業務のバックグラウンドでは、アカウントデータ、注文データ、加盟店データなどのさまざまな情報を確認する必要があります。これらのクエリデータは、は A ページにはなく、各ページにも多くのボタンがあります。これらのページとボタンに対応する権限を組み合わせて権限グループを作成し、役割を割り当てることができます。権限グループに参加した後の RBAC モデルは次のとおりです。

3. モデル設計: RBAC (ロールベースのアクセス制御)

ユニバーサル「ユーザーロール権限」プラットフォーム設計 - Zhihu

RBAC (ロールベースのアクセス制御) とは、ユーザーがロールと権限に関連付けられていることを意味します。つまり、ユーザーには複数のロールがあり、各ロールには複数の権限があります。このようにして、「ユーザー-ロール-権限」の認可モデルが構築されます。このモデルでは、通常、ユーザーとロールの間、およびロールと権限の間に多対多の関係が存在します。

2.1 アカウントテーブル（アカウント）

弊社システムでは、携帯電話番号、メールアドレス、ID番号、WeChatログインなど、様々なログイン方法がございます。したがって、このテーブルは主に各ログイン方法の情報を記録するために使用されますが、さまざまなログイン方法で同じパスワードが使用されるため、パスワード情報は含まれません。各レコードは一意のユーザーレコードに関連付けられます。

アカウントテーブル (アカウント) : アカウント関連情報 (パスワード、登録元、登録 IP など、ログインアカウントは含まれません) のみを保存します。

CREATE TABLE `account`  (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '账号ID',
  `user_id` bigint(20) NULL DEFAULT NULL COMMENT '用户ID',
  `open_code` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '登录账号,如手机号等',
  `category` tinyint(1) NULL DEFAULT NULL COMMENT '账号类别',
  `created` datetime(0) NULL DEFAULT NULL COMMENT '创建时间',
  `creator` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '创建人',
  `edited` datetime(0) NULL DEFAULT NULL COMMENT '修改时间',
  `editor` varchar(36) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL COMMENT '修改人',
  `deleted` double(1, 0) UNSIGNED ZEROFILL NULL DEFAULT 0 COMMENT '逻辑删除:0=未删除,1=已删除',
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `idx_member_id`(`user_id`) USING BTREE COMMENT '普通索引',
  CONSTRAINT `account_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE RESTRICT ON UPDATE RESTRICT
)

2.2 ユーザーテーブル（ユーザー）

主にユーザーの基本情報とパスワード情報を記録するために使用されます。このうち、無効状態 (state) は主に、不正なユーザーによるシステムの使用を制御するバックグラウンド管理で使用され、パスワードソルト (ソルト) は、企業が暗号化された公開パスワードであっても、各ユーザーのログインパスワードに固有のロックを追加するために使用されます。キーが漏洩してもロックできず、すべてのユーザーのパスワードが漏洩することはありません。

ユーザー情報テーブル(user) : 基本的なユーザー情報のみを格納します(パスワードを除く)

CREATE TABLE `user`  (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '用户ID',
  `state` tinyint(1) NULL DEFAULT NULL COMMENT '用户状态:0=正常,1=禁用',
  `name` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '姓名',
  `head_img_url` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '头像图片地址',
  `mobile` varchar(11) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '手机号码',
  `salt` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '密码加盐',
  `password` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '登录密码',
  `created` datetime(0) NULL DEFAULT NULL COMMENT '创建时间',
  `creator` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '创建人',
  `edited` datetime(0) NULL DEFAULT NULL COMMENT '修改时间',
  `editor` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '修改人',
  `deleted` tinyint(1) UNSIGNED ZEROFILL NULL DEFAULT 0 COMMENT '逻辑删除:0=未删除,1=已删除',
  PRIMARY KEY (`id`) USING BTREE
)

2.3 権限テーブル（権限）

ユーザーを設定した後、さまざまなユーザーがさまざまな機能 (ページ、メニュー、ボタンなど) を操作および表示できるようにしたいと考えています。したがって、権限関連の情報を格納するテーブルを定義する必要があります。アクセス許可を含める前に親子関係があり、親が割り当てられた後は、すべての子のアクセス許可が付与される必要があります。同時に、フロントエンドページにも権限情報を付与して制御するため、一意の識別子（コード）を付与する必要があります。もちろん可能ですが、IDは自動生成されており、環境ごとに異なり、再生成後も異なるため、識別には別のフィールドが使用されます。

CREATE TABLE `permission`  (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '权限ID',
  `parent_id` bigint(20) NULL DEFAULT NULL COMMENT '所属父级权限ID',
  `code` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '权限唯一CODE代码',
  `name` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '权限名称',
  `intro` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '权限介绍',
  `category` tinyint(1) NULL DEFAULT NULL COMMENT '权限类别',
  `uri` bigint(20) NULL DEFAULT NULL COMMENT 'URL规则',
  `created` datetime(0) NULL DEFAULT NULL COMMENT '创建时间',
  `creator` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '创建人',
  `edited` datetime(0) NULL DEFAULT NULL COMMENT '修改时间',
  `editor` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '修改人',
  `deleted` tinyint(1) UNSIGNED ZEROFILL NULL DEFAULT 0 COMMENT '逻辑删除:0=未删除,1=已删除',
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `parent_id`(`parent_id`) USING BTREE COMMENT '父级权限ID',
  INDEX `code`(`code`) USING BTREE COMMENT '权限CODE代码'
)

2.4 ロールテーブル(role)

メンテナンスを容易にするために、権限テーブル内のレコードをグループ化し、いくつかの関連する権限を同じグループに割り当てます。これをロールと呼びます。ロールテーブルの役割は、分散した権限を集約し、関連するグループの統一処理（小規模バッチ処理）を容易にすることです。このテーブルの追加により、前述のメンテナンスの困難な問題が大幅に軽減されると言える。

CREATE TABLE `role`  (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '角色ID',
  `parent_id` bigint(20) NULL DEFAULT NULL COMMENT '所属父级角色ID',
  `code` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '角色唯一CODE代码',
  `name` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '角色名称',
  `intro` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '角色介绍',
  `created` datetime(0) NULL DEFAULT NULL COMMENT '创建时间',
  `creator` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '创建人',
  `edited` datetime(0) NULL DEFAULT NULL COMMENT '修改时间',
  `editor` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '修改人',
  `deleted` tinyint(1) UNSIGNED ZEROFILL NULL DEFAULT 0 COMMENT '逻辑删除:0=未删除,1=已删除',
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `parent_id`(`parent_id`) USING BTREE COMMENT '父级权限ID',
  INDEX `code`(`code`) USING BTREE COMMENT '权限CODE代码'
)

2.5 ユーザーロールテーブル (user_role)

このテーブルは主に、各ユーザーがどの役割を持っているかを保存するために使用されます。通常、各ユーザーはいくつかのロールしか持たないため、データ量は 100 億から 10 億以下になります。

CREATE TABLE `user_role`  (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `user_id` bigint(20) NULL DEFAULT NULL COMMENT '用户ID',
  `role_id` bigint(20) NULL DEFAULT NULL COMMENT '角色ID',
  `created` datetime(0) NULL DEFAULT NULL COMMENT '创建时间',
  `creator` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '创建人',
  `edited` datetime(0) NULL DEFAULT NULL COMMENT '修改时间',
  `editor` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '修改人',
  `deleted` tinyint(1) UNSIGNED ZEROFILL NULL DEFAULT 0 COMMENT '逻辑删除:0=未删除,1=已删除',
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `member_id`(`user_id`) USING BTREE COMMENT '用户ID',
  INDEX `role_id`(`role_id`) USING BTREE COMMENT '角色ID',
  CONSTRAINT `user_role_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE RESTRICT ON UPDATE RESTRICT,
  CONSTRAINT `user_role_ibfk_2` FOREIGN KEY (`role_id`) REFERENCES `role` (`id`) ON DELETE RESTRICT ON UPDATE RESTRICT
)

2.6 ロール - 権限テーブル (role_permission)

このテーブルは、各役割グループで使用できるアクセス許可を定義するために使用されます。テーブルの数はそれよりも少なくなります（基本的には10,000以内）。

CREATE TABLE `role_permission`  (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `role_id` bigint(20) NULL DEFAULT NULL COMMENT '角色ID',
  `permission_id` bigint(20) NULL DEFAULT NULL COMMENT '权限ID',
  `created` datetime(0) NULL DEFAULT NULL COMMENT '创建时间',
  `creator` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '创建人',
  `edited` datetime(0) NULL DEFAULT NULL COMMENT '修改时间',
  `editor` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '修改人',
  `deleted` tinyint(1) UNSIGNED ZEROFILL NULL DEFAULT 0 COMMENT '逻辑删除:0=未删除,1=已删除',
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `role_id`(`role_id`) USING BTREE COMMENT '角色ID',
  INDEX `permission_id`(`permission_id`) USING BTREE COMMENT '权限ID',
  CONSTRAINT `role_permission_ibfk_1` FOREIGN KEY (`role_id`) REFERENCES `role` (`id`) ON DELETE RESTRICT ON UPDATE RESTRICT,
  CONSTRAINT `role_permission_ibfk_2` FOREIGN KEY (`permission_id`) REFERENCES `permission` (`id`) ON DELETE RESTRICT ON UPDATE RESTRICT
)

3.1 ユーザーグループテーブル(user_group)

前述のロールテーブル（役割）を追加したことでデータ量は100億から10億に減りましたが、それでも10倍というデータ量は多いです。そして、ほとんどのユーザー (主題ユーザー。学生システムなど、学生が主題) には、同じ役割グループが割り当てられます。ユーザーグループと役割グループの違い:

役割グループ (役割) : 権限のグループ化を解決し、権限の繰り返しの割り当てを削減します。
ユーザーグループ (user_group) : ユーザーのグループ化を解決し、ユーザーの繰り返しの認証を削減します。

CREATE TABLE `user_group`  (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `parent_id` bigint(20) NULL DEFAULT NULL COMMENT '所属父级用户组ID',
  `name` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '用户组名称',
  `code` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '用户组CODE唯一代码',
  `intro` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '用户组介绍',
  `created` datetime(0) NULL DEFAULT NULL COMMENT '创建时间',
  `creator` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '创建人',
  `edited` datetime(0) NULL DEFAULT NULL COMMENT '修改时间',
  `editor` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '修改人',
  `deleted` tinyint(1) UNSIGNED ZEROFILL NULL DEFAULT 0 COMMENT '逻辑删除:0=未删除,1=已删除',
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `parent_id`(`parent_id`) USING BTREE COMMENT '父级用户组ID',
  INDEX `code`(`code`) USING BTREE COMMENT '用户组CODE代码'
)

3.2 ユーザーグループ - ユーザーテーブル (user_group_user)

このテーブルは、各ユーザーグループにどのユーザーが属しているかを記録するために使用されます。

CREATE TABLE `user_group_user`  (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'ID说',
  `user_group_id` bigint(20) NULL DEFAULT NULL COMMENT '用户组ID',
  `user_id` bigint(20) NULL DEFAULT NULL COMMENT '用户ID',
  `created` datetime(0) NULL DEFAULT NULL COMMENT '创建时间',
  `creator` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '创建人',
  `edited` datetime(0) NULL DEFAULT NULL COMMENT '修改时间',
  `editor` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '修改人',
  `deleted` tinyint(1) UNSIGNED ZEROFILL NULL DEFAULT 0 COMMENT '逻辑删除:0=未删除,1=已删除',
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `member_group_id`(`user_group_id`) USING BTREE COMMENT '用户组ID',
  INDEX `member_id`(`user_id`) USING BTREE COMMENT '用户ID',
  CONSTRAINT `user_group_user_ibfk_1` FOREIGN KEY (`user_group_id`) REFERENCES `user_group` (`id`) ON DELETE RESTRICT ON UPDATE RESTRICT,
  CONSTRAINT `user_group_user_ibfk_2` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE RESTRICT ON UPDATE RESTRICT
)

3.3 ユーザーグループ-ロールテーブル (user_group_role)

このテーブルは、各ユーザーグループがどのユーザーロールを持っているかを記録するために使用されます。

CREATE TABLE `user_group_role`  (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `user_group_id` bigint(20) NULL DEFAULT NULL COMMENT '用户组ID',
  `role_id` bigint(20) NULL DEFAULT NULL COMMENT '角色ID',
  `created` datetime(0) NULL DEFAULT NULL COMMENT '创建时间',
  `creator` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '创建人',
  `edited` datetime(0) NULL DEFAULT NULL COMMENT '修改时间',
  `editor` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '修改人',
  `deleted` tinyint(1) UNSIGNED ZEROFILL NULL DEFAULT 0 COMMENT '逻辑删除:0=未删除,1=已删除',
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `member_group_id`(`user_group_id`) USING BTREE COMMENT '用户组ID',
  INDEX `role_id`(`role_id`) USING BTREE COMMENT '角色ID',
  CONSTRAINT `user_group_role_ibfk_1` FOREIGN KEY (`user_group_id`) REFERENCES `user_group` (`id`) ON DELETE RESTRICT ON UPDATE RESTRICT,
  CONSTRAINT `user_group_role_ibfk_2` FOREIGN KEY (`role_id`) REFERENCES `role` (`id`) ON DELETE RESTRICT ON UPDATE RESTRICT
)

各システムの主な利用者は、基本的に全利用者の9割以上を占めます（利用者と加盟店の両方が含まれるシステムは、利用者と加盟店も対象利用者となります）。したがって、各ユーザーは登録時に、基本的に自分が所属するユーザーグループを割り当てるだけでロール権限の設定が完了します。この処理の後、データの量は 10 億から 1 億以上に減少します。同時に、ユーザー登録に必要な一括書き込み回数も削減されます。

ユーザーテーブル (t_user)
ユーザーグループテーブル (t_group)
ロールテーブル (t_role)
権限テーブル (t_permission)
ユーザーテーブル - ユーザーグループ (user_group)
ユーザー - ロールテーブル (user_role)
ユーザーグループ - ロールテーブル (group_role)
ロール - 権限テーブル (role_permission) ）

3. Django: ユーザー認証、権限管理

権限は、ユーザーの行動を制限し、ページに表示されるコンテンツを制御できるメカニズムです。完全な権限には、ユーザー、オブジェクト、権限という 3 つの要素が含まれている必要があります。つまり、どのユーザーがどのオブジェクトに対してどの権限を持っているかということです。

Django の組み込み権限メカニズムはモデルのみを対象としています。つまり、ユーザーが Article モデルに対する変更権限を持っている場合、そのユーザーはすべての記事に対する変更権限を持ちます。単一のオブジェクトにアクセス許可管理を実装する場合は、サードパーティのライブラリガーディアンを使用できます。この記事では、組み込みの「認証モジュール」の許可メカニズムとガーディアンをそれぞれ紹介します。

1. 自己完結型の許可メカニズム

auth モジュールは、Django によって提供される標準の権限管理システムであり、ユーザー認証、ユーザーグループ、および権限管理を提供できます。

1.1 テーブル構造

認証モジュールに関連するデータベーステーブルが 6 つあります。

計画	効果	述べる
認証ユーザー。	ユーザー情報
認証グループ	グループ情報	各グループには ID と名前の 2 つのフィールドがあります
auth_user_groups	ユーザーとグループの関係
auth_user_user_permissions	ユーザーと権限の関係
認証許可	権限	各権限には ID、名前、 content_type_id、コード名 4 つのフィールド
auth_group_permissions	ユーザーグループと権限の対応	ユーザーグループを使用して権限を管理すると、より便利な方法です。グループには多対多のフィールド権限が含まれます

1.1 認証ユーザー

auth_user テーブルはユーザー情報を保持します。構造は次のとおりです。

CREATE TABLE `auth_user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `password` varchar(128) COLLATE utf8mb4_unicode_ci NOT NULL,
  `last_login` datetime(6) DEFAULT NULL,
  `is_superuser` tinyint(1) NOT NULL,
  `username` varchar(150) COLLATE utf8mb4_unicode_ci NOT NULL,
  `first_name` varchar(30) COLLATE utf8mb4_unicode_ci NOT NULL,
  `last_name` varchar(150) COLLATE utf8mb4_unicode_ci NOT NULL,
  `email` varchar(254) COLLATE utf8mb4_unicode_ci NOT NULL,
  `is_staff` tinyint(1) NOT NULL,
  `is_active` tinyint(1) NOT NULL,
  `date_joined` datetime(6) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

1.2 認証グループ

auth_group テーブルには id と name の 2 つのフィールドのみがあり、その構造は次のとおりです。

CREATE TABLE `auth_group` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(150) COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

auth_user_groups テーブルを通じて、auth_group と auth_user の間に多対多の関係が確立されます。構造は次のとおりです。

auth_user_groups

CREATE TABLE `auth_user_groups` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `group_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `auth_user_groups_user_id_group_id_94350c0c_uniq` (`user_id`,`group_id`),
  KEY `auth_user_groups_group_id_97559544_fk_auth_group_id` (`group_id`),
  CONSTRAINT `auth_user_groups_group_id_97559544_fk_auth_group_id` FOREIGN KEY (`group_id`) REFERENCES `auth_group` (`id`),
  CONSTRAINT `auth_user_groups_user_id_6a12ed8b_fk_auth_user_id` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

1.3 auth_permission: テーブルにはモデルの権限情報が格納されます。

CREATE TABLE `auth_permission` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
  `content_type_id` int(11) NOT NULL,
  `codename` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `auth_permission_content_type_id_codename_01ab375a_uniq` (`content_type_id`,`codename`),
  CONSTRAINT `auth_permission_content_type_id_2f476e4b_fk_django_co` FOREIGN KEY (`content_type_id`) REFERENCES `django_content_type` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=25 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

auth_group_permissions

auth_permission と auth_group の間の多対多の関係を維持する

CREATE TABLE `auth_group_permissions` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `group_id` int(11) NOT NULL,
  `permission_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `auth_group_permissions_group_id_permission_id_0cd325b0_uniq` (`group_id`,`permission_id`),
  KEY `auth_group_permissio_permission_id_84c5c92e_fk_auth_perm` (`permission_id`),
  CONSTRAINT `auth_group_permissio_permission_id_84c5c92e_fk_auth_perm` FOREIGN KEY (`permission_id`) REFERENCES `auth_permission` (`id`),
  CONSTRAINT `auth_group_permissions_group_id_b120cbf9_fk_auth_group_id` FOREIGN KEY (`group_id`) REFERENCES `auth_group` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

auth_user_user_permissions

auth_permission と auth_user の間の多対多の関係を維持する

CREATE TABLE `auth_user_user_permissions` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `permission_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `auth_user_user_permissions_user_id_permission_id_14a6b632_uniq` (`user_id`,`permission_id`),
  KEY `auth_user_user_permi_permission_id_1fbb5f2c_fk_auth_perm` (`permission_id`),
  CONSTRAINT `auth_user_user_permi_permission_id_1fbb5f2c_fk_auth_perm` FOREIGN KEY (`permission_id`) REFERENCES `auth_permission` (`id`),
  CONSTRAINT `auth_user_user_permissions_user_id_a95ead1b_fk_auth_user_id` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

上記 3 つのテーブルにより、認証モジュールからモデルレベルまでの権限管理、つまり、ユーザーが特定のデータテーブルを追加 (add)、変更 (change)、削除 (delete) する権限を持っているかどうかが保証されます。

オブジェクトレベルの権限管理が必要な場合は、サードパーティのライブラリを使用する必要があります django-guardian 。

注: auth_permission テーブルの content_type_id エントリは、django.contrib.contenttypes モジュールのアプリケーションです。

2. 関連するメソッドと関数

authenticate()、ユーザ認証。認証情報が有効な場合は、User オブジェクトが返されます。void は None を返します
user.set_password(new_password)、ユーザーのパスワードを変更します
login(HttpRequest, user)、 django.contrib.sessions モジュールと組み合わせて、認証されたユーザーにセッション ID およびその他の情報を添付します。
logout(request)、ユーザーをログアウトします
@login_required デコレータはまずセッションキーを介してログインしているかどうかを確認し、ログインしているユーザーは通常どおり操作を実行でき、ログインしていないユーザーは login_url で指定された場所にリダイレクトされます。login_url パラメータが指定されていない場合は、にリダイレクトされますsettings.LOGIN_URL。
user.has_perm、ユーザーが特定のモデルを操作する権限を持っているかどうかを確認するには、次のようにします。

user.has_perm('blog.add_article')
user.has_perm('blog.change_article')
user.has_perm('blog.delete_article')

django.contrib.auth.middleware.AuthenticationMiddleware、現在ログインしているユーザーを HttpRequestオブジェクトのuserプロパティに追加します。
django.contrib.auth.context_processors.authテンプレートのコンテキスト（コンテキスト）に認証を追加します。
django.contrib.auth.password_validation一連のパスワード強度チェックはで提供されています。

注: このテストはコマンドライン操作などのみを対象とし createsuperuser、などchangepasswordのモデル操作には無効です (これらは開発者の操作であり、ユーザーの操作ではないため)。User.objects.create_user()create_superuser()

認可管理システムの設計スキーム

システム権限 = 機能権限 + データ権限

1. 権限管理が必要なのはなぜですか?

2.1 権限の設計

2.2 ロールが必要な理由

2.3 許可モデルの進化

1 基本的な RBAC モデル

2.4ユーザーグループの RBAC モデルとロール制限の RBAC モデルの紹介

2.4.1 ユーザーグループ

3. モデル設計: RBAC (ロールベースのアクセス制御)

2.1 アカウントテーブル（アカウント）

2.2 ユーザーテーブル（ユーザー）

2.3 権限テーブル（権限）

2.4 ロールテーブル(role)

2.5 ユーザーロールテーブル (user_role)

2.6 ロール - 権限テーブル (role_permission)

3.1 ユーザーグループテーブル(user_group)

3.2 ユーザーグループ - ユーザーテーブル (user_group_user)

3.3 ユーザーグループ-ロールテーブル (user_group_role)

3. Django: ユーザー認証、権限管理

1. 自己完結型の許可メカニズム

1.1 テーブル構造

1.1 認証ユーザー

1.2 認証グループ

auth_user_groups

1.3 auth_permission: テーブルにはモデルの権限情報が格納されます。

auth_group_permissions

auth_user_user_permissions

2. 関連するメソッドと関数

おすすめ

認可管理システムの設計スキーム

システム権限 = 機能権限 + データ権限

1. 権限管理が必要なのはなぜですか?

2.1 権限の設計

2.2 ロールが必要な理由

2.3 許可モデルの進化

1 基本的な RBAC モデル

2.4ユーザー グループの RBAC モデルとロール制限の RBAC モデルの紹介

2.4.1 ユーザーグループ

3. モデル設計: RBAC (ロールベースのアクセス制御)

2.1 アカウントテーブル（アカウント）

2.2 ユーザーテーブル（ユーザー）

2.3 権限テーブル（権限）

2.4 ロールテーブル(role)

2.5 ユーザーロールテーブル (user_role)

2.6 ロール - 権限テーブル (role_permission)

3.1 ユーザーグループテーブル(user_group)

3.2 ユーザーグループ - ユーザーテーブル (user_group_user)

3.3 ユーザーグループ-ロールテーブル (user_group_role)

3. Django: ユーザー認証、権限管理

1. 自己完結型の許可メカニズム

1.1 テーブル構造

1.1 認証ユーザー

1.2 認証グループ

auth_user_groups

1.3 auth_permission: テーブルにはモデルの権限情報が格納されます。

auth_group_permissions

auth_user_user_permissions

2. 関連するメソッドと関数

おすすめ

2.4ユーザーグループの RBAC モデルとロール制限の RBAC モデルの紹介