承認設計（暫定ドラフト）
1。はじめに：
承認管理は非常に複雑な問題であることがよくありますが、論理式として簡単に表現することもできます。「誰がどのように（どの）を実行するか」の論理式が正しいかどうかを判断します。アプリケーションごとに、プロジェクトの実際の状況や具体的な構造に応じて、保守性、柔軟性、完全性など、N個の複数のソリューションを比較し、適切なソリューションを選択する必要があります。
2.目標：
直感的。 システムは最終的にエンドユーザーによって維持されるため、概念の数の単純さ、感覚の単純さなど、直感的で理解しやすいアクセス許可の配布がより重要で単純です。と機能のシンプルさ。すべての許可問題を解決するために許可システムを使用することは非現実的です。設計では、「カスタマイズ」特性が強い頻繁に変化する部分をビジネスロジックと判断し、権限ロジックとして「一般」特性が強い同一部分が多いという考え方に基づいています。
3.現状維持：
企業環境には、一般に3種類のアクセス制御方法があり
ます。1。自律アクセス制御方法：現在、わが国の情報システムのアクセス制御モジュールのほとんどは、基本的に自律アクセス制御方法に依存しています。の制御リスト（ACL）
2.強制アクセス制御方式：マルチレベルのセキュリティレベルを備えた軍事アプリケーションに使用されます。
3.役割ベースのアクセス制御方法（RBAC）：現在、大企業の統合リソースアクセス制御を解決するための効果的な方法として認識されています。その2つの注目すべき機能は次のとおりです。1。承認管理の複雑さを軽減し、管理オーバーヘッドを削減します。2.企業のセキュリティ戦略を柔軟にサポートし、企業の変化に対して優れたスケーラビリティを備えています。
4.名詞：
粗粒度：カテゴリレベルを表します。つまり、オブジェクトのタイプのみが考慮され、オブジェクトの特定のインスタンスは考慮されません。たとえば、ユーザー管理では、作成と削除はすべてのユーザーに平等に扱われ、操作の特定のオブジェクトインスタンスは区別されません。
きめ細かい：インスタンスレベルを示します。つまり、オブジェクトのインスタンスを考慮する必要があります。もちろん、きめ細かいとは、粗いオブジェクトのカテゴリを考慮した後、特定のインスタンスを考慮することです。たとえば、契約管理、一覧表示、削除では、契約インスタンスが現在のユーザーによって作成されているかどうかを区別する必要があります。
5.原則：
許可ロジックはビジネスロジックと一致します。つまり、認証システムは、ビジネスロジックにサービスを提供することを目的としています。かなりの数のきめ細かい権限の問題は非常に独特であり、普遍的な意味はなく、「ビジネスロジック」の一部として理解することもできます。たとえば、「契約リソースは作成者のみが削除でき、作成者と同じグループのユーザーは変更でき、すべてのユーザーが閲覧できます」という要件があります。これは、きめ細かいアクセス許可の問題と見なすことができます。または、ビジネスロジックの問題と見なすことができます。これはビジネスロジックの問題であり、許可システム全体のアーキテクチャ設計ではあまり考慮されるべきではありません。もちろん、許可システムのアーキテクチャもそのような制御判断をサポートできなければなりません。言い換えれば、システムは十分ではあるが完全ではない制御機能を提供します。つまり、設計原則は次のように要約されます。「システムは大まかなアクセス許可のみを提供し、きめ細かいアクセス許可はビジネスロジックの責任と見なされます。」
パーミッションの式：Who + What（Which）+ How is the problem、where weimplement What and part of thePermissions Problem of which（coarse-grained and fine-grained、as more）、and otherpermissionsproblemsは解決するビジネスロジック
6.概念：
誰が：パーミッションの所有者またはサブジェクト（プリンシパル、ユーザー、グループ、ロール、アクターなど）内容
：パーミッションが向けられるオブジェクトまたはリソース（リソース、クラス）。
方法：特定の権限（特権、正の承認、および否定の承認）。
役割：特定の数の権限を持つ役割です。
オペレーター：操作。How操作をWhatに示します。
7.説明：
ユーザー：ロールに関連して、ユーザーは単なる純粋なユーザーであり、権限は分離されています。ユーザーを特権に直接関連付けることはできません。ユーザーが特定のリソースへのアクセス許可を持っている場合は、ロールを介して関連付ける必要があります。誰の問題を解決します。
リソース：アクセスのためにユーザーに提供できるのは、部門のニュース、ドキュメント、その他のオブジェクトなど、システムのリソースです。
特権：リソース関連の権限です。これは、この権限が特定のリソースインスタンスにバインドされていることを意味します。たとえば、部門ニュースの発行機関は「部門ニュース発行機関」と呼ばれます。これは、特権が発行機関であり、部門ニュースなどのリソースの発行機関であることを示しています。特権は、開発中に作成者によって決定されます。「削除」などの権限 これは抽象名詞であり、特定のオブジェクトまたはリソースにバインドされていない場合は意味がありません。ニュースリリースを例にとると、リリースは一種の権威ですが、リリースされたと言っても意味がありません。リリースが何を操作できるかわからないからです。出版とニュースを組み合わせた場合にのみ、真の特権が生み出されます。これは特権インスタンスです。
ロール：これは、粗粒度および細粒度（ビジネスロジック）インターフェイスであり、粗粒度制御に基づく権限フレームワークソフトウェアです。外部インターフェイスはロールである必要があります。特定のビジネス実装は、ロールのコンテンツを直接継承または拡張できます。役割はユーザーやグループの具体的なエンティティとは異なり、インターフェイスの概念であり、抽象的な一般的な用語です。
演算子の定義には、リソースタイプとメソッドの概念が含まれます。つまり、What andHowの概念です。個別にモデル化して関連付けを確立するのではなく、WhatとHowがOperatorの概念としてバインドされる理由は、多くのHowが特定のWhatにとって意味があるためです。たとえば、公開操作はニュースオブジェクトには意味がありますが、ユーザーオブジェクトには意味がありません。
8.アイデア：
権限システムのコアは、次の3つの部分で構成されます。1。権限の作成、2。権限の割り当て、3。権限の使用、次に、システムの各部分の主な参加者を次のように比較します。権限の作成-作成者の作成、2。権限の割り当て-管理者の割り当て、3。権限の使用-ユーザー：
1。作成者が権限を作成します。作成者は、システム、サブシステム、またはモジュールと呼ばれるものを設計および実装するときに分割します。 。ここで行われるのは、特権とリソースのオブジェクト宣言であり、実際には特権と特定のリソースインスタンスをリンクしてOperatorを形成するわけではありません。
2.管理者は、特権とリソースインスタンス間の関連付けを指定します。このステップでは、権限が実際にリソースインスタンスにリンクされ、結果としてオペレーター（特権インスタンス）になります。管理者は、Operatorの基本要素を使用して、理想的な権限モデルを作成します。たとえば、ロールの作成、ユーザーグループの作成、ユーザーグループへのユーザーの割り当て、ユーザーグループとロールの関連付けなどです。これらの操作はすべて管理者によって実行されます。
3.ユーザーは、管理者によって割り当てられた権限を使用して、各サブシステムを使用します。管理者はユーザーです。彼の頭の中には、管理と保守に適したアクセス許可モデルがあります。したがって、プログラマーは1つの質問に答えるだけで済みます。それは、どのパーミッションがどのリソースにアクセスできるかということです。これは、上記のオペレーターです。オペレーターを提供するプログラマーは、システムに鎧を置くことを意味します。管理者は、必要に応じて必要なアクセス許可フレームワークを構築でき、リソースと特権の関係を追加、削除、および管理できます。ユーザーとロールの対応する関係は自分で設定できます。（CreatorをBasicの発明者と見なす場合、AdministratorはBasicのユーザーであり、スクリプトスタイルのプログラミングを行うことができます）Operatorはこのシステムの最も重要な部分であり、リンクであり、Programmer、Administratorに関連付けられています。 、ユーザー間のリンク。
異なるアクセス許可を持つ複数のユーザーが関与するネットワークまたはスタンドアロンプログラムには、アクセス許可管理の問題があります。最も顕著なのはMISシステムです。
私が話したいのは、データベースの設計とMISシステム権限管理の実装です。もちろん、これらのアイデアは、たとえばBBSのさまざまなレベルのユーザー権限を管理するために、促進および適用することもできます。
承認設計には通常、データベース設計、アプリケーションプログラミングインターフェイス（API）設計、およびプログラム実装の3つの部分が含まれます。
これらの3つの部分は相互に依存し、分離できません。完全な権限管理システムを実現するには、各リンクの実現可能性と複雑さを考慮し、実行効率さえも考慮する必要があります。
最初にデータアクセス許可、通常は4種類の入力、参照、変更、削除、次に統計などのすべての間接データアクセス操作を含む機能に分類します。さらに、特定のフィールドへのアクセスも可能です。一部の主要なデータテーブルでは制限されています。また、他の許可カテゴリーは考えられません。
完全なパーミッション設計には十分なスケーラビリティが必要です。つまり、システムに新しい機能やその他の機能を追加しても、パーミッション管理システム全体に大きな変更が加えられることはありません。この目標を達成するには、まずデータベース設計が合理的であり、次に、アプリケーションプログラムのインターフェイス仕様。
最初にデータベース設計について説明しましょう。通常、リレーショナルデータベースを使用しますが、Lotus製品に基づく権限管理についてはここでは説明しません。
権限テーブルと関連コンテンツは、次の6つのテーブルで記述できます
。1ロール（つまりユーザーグループ）テーブル：3つのフィールド、ID、ロール名、およびロールの説明が
含まれます 。2ユーザーテーブル：3つ以上のフィールドが含まれます。 ID、ユーザー名、ユーザーの説明、その他（住所、電話番号など）
。3ロール-ユーザー対応テーブル：このテーブルは、ユーザーとロール間の対応を記録します。ユーザーは複数のロールに属することができます。ロールグループには複数のユーザーを含めることもできます。ID、ロールID、ユーザーIDの3つのフィールドが含まれます。
4制限付きコンテンツリスト：このテーブルには、権限とその説明（ID、名前、説明の3つのフィールドを含む）によって区別および制限する必要があるすべてのデータテーブル、関数、およびフィールドが記録されます
。5権限リスト：このテーブルには、すべてのデータが記録されます。制御可能入力、変更、削除、実行などのアクセス許可には、ID、名前、説明の3つのフィールドも含まれます
。6アクセス許可-役割-ユーザー対応表：通常の状況では、アクセス許可について次の規定を行います。役割/ユーザーの場合、役割には明示的に許可された権限があり、他のすべての権限は禁止されています。ユーザーは、所属する役割のすべての権限を継承します。この範囲内のすべての権限は、明示的に禁止されている場合を除き、許可されます。明示的に許可されている場合を除き、範囲外は禁止されています。このテーブルのデザインは権限管理の焦点であり、デザインのアイデアはたくさんありますが、それぞれにメリットがあると言え、ある方法が良いとは言えません。この点で、私の意見は、私の個人的な状況に基づいて問題を解決できる適切なものを見つけることです。
最初の最も簡単な理解方法について説明します。ID、制限付きコンテンツID、アクセス許可ID、ロール/ユーザータイプ（ブールフィールド、レコードレコードがロールアクセス許可かユーザーアクセス許可かを説明するために使用）、ロール/の5つのフィールドを設計します。ユーザーID、アクセス許可の種類（ブールフィールド、アクセス許可または禁止を示すレコードを記述するために使用）
表6によると、これらの6つのテーブルがあり、特定の役割/ユーザーが特定のアクセス許可を持っているか禁止しているかを知ることができます。
つまり、この設計で十分であり、必要な機能を十分に実現しています。役割とユーザーを個別にカスタマイズでき、非常に拡張性もあります。たとえば、新しい機能を追加する場合は、1つ以上のレコードを追加するだけで済みます。十分であり、アプリケーションプログラムのインターフェイスを変更する必要はありません。これは非常に実現可能です。ただし、プログラムの実装過程で、この方法を使用することはあまり科学的ではないことがわかりました。たとえば、ユーザーが所有するアクセス許可を参照する場合、データベースに複数回（再帰的にも）クエリを実行する必要があり、非常に不便です。したがって、他の方法を考える必要があります。Unixシステムを使用したことのある人なら誰でも、Unixファイルシステムがファイル操作のアクセス許可を読み取り、書き込み、実行の3つのタイプに分割し、3つのコード1、2、4で識別され、ユーザーが読み取りと書き込みの両方を行えることを知っています。ファイルのパーミッション。3、つまり1 +2として記録されます。同様のアプローチを使用して、この問題を解決することもできます。最初のアイデアは、権限リストを変更し、フィールドを追加することです：識別コード。たとえば、入力権限を1、閲覧権限を2、変更権限を4、削除権限を8、実行を識別できます。このように、パーミッション累積の方法を使用して、複数のレコードに記述されているパーミッションを簡単にまとめることができます。たとえば、ユーザーIDが1、インベントリテーブルの対応する制限付きコンテンツIDが2、役割も同時に指定されます。タイプが0でユーザータイプが1の場合、インベントリテーブルを入力、参照、変更、および削除するユーザーの権限を2,15,1,1と表すことができます。
本当に簡単ですね。さらに根本的な方法があります。制限付きコンテンツリストに列を追加し、識別コードを定義します。このようにして、単純なレコードを使用して、ユーザーがすべてのコンテンツに対して持つすべてのアクセス許可を記述することもできます。もちろん、これはコンテンツの量を比較的少量に制限することを前提としています。そうしないと、n乗の2の数が増えますが、その量は驚くべきものであり、分析するのは簡単ではありません。
表面的には、上記の方法は、機能を実装し、データベースの設計と実装の複雑さを単純化するという目的を達成するのに十分ですが、そうすることには欠点があります。私たちが関与する権限のリストは、互いに独立しているのではなく、依存しています。権限の変更など、相互にアクセスできます。実際には、閲覧権限が含まれます。たとえば、インベントリテーブルへのユーザーのアクセスを、入力+変更+削除（1 + 4 + 8 = 13）に設定するだけですが、実際にはユーザーは（1+ 2 + 4 + 8 = 15）を持っています。つまり、このスキームでは13 = 15です。そのため、APIを呼び出してユーザーが閲覧権限を持っているかどうかを確認するときは、ユーザーがデータテーブルを変更する権限を持っているかどうかを判断する必要があります。したがって、権限間の包含関係をプログラムで修正できない場合は、アプリケーションプログラムインターフェースは使用できません。判断してください。しかし、これは「十分なスケーラビリティ」という私たちの目標と矛盾します。
この問題を解決する方法は？識別コードを設定する別の方法、つまり素数を使用する方法を考えました。入力、閲覧、変更、削除、実行の基本的なロゴコードを2、3、5、7、11に設定することもできます。権限に相互が含まれている場合は、ロゴコードを2つ（または複数）に設定します。基本的なマークコードの積。たとえば、「変更」機能のマークコードを3 * 5 = 15に設定し、すべての権限を乗算して、必要な最終的な権限識別値を取得できます。このように、ユーザーに特定の権限があるかどうかを尋ねるときは、最終値を素因数に分解するだけで済みます。たとえば、在庫テーブルを入力+変更+削除する権限を持つユーザーを2 *として定義できます。 15 * 7 = 2 * 3 * 5 * 7は、ユーザーがインベントリテーブルを入力+参照+変更+削除する権利を持っていることを意味します。
もちろん、パーミッションリストに上記の方法を使用することの前提は、パーミッションリストのレコード数が多すぎず、関係がそれほど複雑ではないことです。そうでない場合、パーミッションコードを解析するだけでマシンが愚かになります:)