ECMシステムのアクセスリストに基づくアクセス制御の問題（パート2）

私のデビュー記事では、サブジェクト領域へのアクセスを制限するためのモデルを段階的に設計しました。例として、単純なものから非常に単純ではなくなった架空のECMシステムを考えます。 結果として得られたモデルの枠組みの中で簡単かつ簡単に解決できない問題に直面しました。 この記事では、状況の修正を試みます。

簡単に遭遇した問題のリストを思い出させてください

• 問題1-依存アクセスリスト
• 問題2-権限の委任
• 問題3-多数のオブジェクトへのアクセスを提供する

基本スキーム

上記の問題を適切に解決するために、最初の図に少し戻ります



現在のスキーマには、サブジェクト領域の各オブジェクトのアクセスリストが含まれています。

理論的な部分から、どのアクセス制御パターンがセキュリティモデルをサポートする必要があるかをおおまかに理解しました。

したがって、抽象化の度合いを高めます。 ACLでは、権限を持つセキュリティエンティティのリストではなく、このオブジェクトに適用可能なアクセスモデルのリストを示します。 同時に、公理を観察することにより、ACLモデルが他のすべてよりも優れていることをサポートします。 常にACLのみに基づいてオブジェクトへのアクセスを計算できる必要があります 。



そのため、次のようにスキームを変更します



以下、データベーススキーマではなく、クラス図。 データベースでクラススキームをマッピングする問題については、後ほど取り上げます（ 次の記事で説明します ）。 白い閉じた矢印は継承です。 白抜きの矢印は関連付けです。



既に理解したように、ドキュメントへのアクセスのリストは、オブジェクトによってサポートされるsecurityAspectオブジェクトの階層リストに縮退しました—アクセスを提供するための抽象的なメカニズム。 Compositeパターンを使用してSecurityAspectを実装しました。



SecurityAspectCompositeとSecurityAspectの間の多対多の関係に対して、Compositeパターンの中間エンティティを指定しなかったことに注意してください。 他の場合（Compositeパターンとは無関係）、そのような中間エンティティを示します。



また、 SecurityAspectがObjectを参照していないという事実にも注目します。 それどころか、 ObjectにはルートSecurityAspectへのリンクが含まれており、このオブジェクトは（その階層とともに）このオブジェクトへのアクセスを決定します。



将来、オブジェクトのルートSecurityAspect（およびその階層）は、 ACLを昔ながらの方法で呼び出します 。

ユーザー

理論的な部分（および問題2で概説した要件）から、システムユーザーは複数の特権セットを持つことができ、一度にアクティブにする必要があるのは1つのセットだけであることがわかりました。



簡単な例は、システムのユーザーが自分のために、上司のために、そして非常に大きな上司のために働くことができる場合です（秘書の典型的なシナリオ）-システムのビジネスロジックは、ユーザーがこれまたはシステム内の別のアクション。



このすべてを図に反映します。



ご覧のとおり、各ユーザーは、関連付けられた一連のプリンシパルを持つことができます。これにより、階層を形成できます（ 複合パターンも使用）。 明確にするために、特定の実装（組織のプリンシパル）を実装しました。 組織の構造。

さらに、 セッションは図にも表示されます。これは、ユーザーの参照に加えて、ユーザーが現在作業しているプリンシパルも参照します。

将来的には、ユーザーではなく、 校長にアクセスを提供します 。 これにより、 交換シナリオの実装が容易になります（問題2） 。

オブジェクトへの直接アクセス

次に、これら2つのスキームをクロスして、 Principal’sを介したオブジェクトへの直接アクセスを実装しましょう。



DirectAccessという名前のSecurityAspectの子孫を作成しました。これには、オブジェクトへの権限のリストと、これらの権限が実際に利用可能なPrincipalへのリンクの両方があります。

このモデルでは、 前の記事のデータモデルとは異なり、権利は属性ではなく、DirectAccessRightsを介してDirectAccessに関連付けられているRightという別のエンティティに割り当てられていることに注意してください。 これにより、将来的にこの一連の権利を簡単に拡張できるようになります。

役割

前に約束したように、システムには役割もあります。 実現する



ご覧のとおり、新しいSecurityAspectがRoleという名前で作成されます。これは、他のSecurityAspectを階層的に結合できます（ SecurityAspectCompositeから継承されるため）。

ロールは権利の宣言的な割り当てに最もよく使用され、オブジェクトACLで示されないため（モデルではこれを禁止していませんが）、ロールとPrincipal'amiの間に接続を提供する必要があります。 これはPrincipalSecurityAspectsを使用して行います。



ロールの使用に関する詳細：

• これらは、 システム機能へのアクセスを提供するため、およびシステムオブジェクトへのアクセスを提供するために使用できます。
• 前者の場合 、モデルにはオブジェクトへのアクセスに使用される権利とは異なる権利のセットを持つ必要な役割があり、これらの役割はPrincipalSecurityAspectsでPricipalsに登録されます
• 2番目の場合 、ロールもモデルで作成され、プリンシパルはPrincipalSecurityAspectsに登録され、 さらにこれらのロールが適用されるオブジェクトのACLにも登録されます。 この場合、ロールで使用される権限のセットは、DirectAccessで使用される権限と同じである場合があります。

最も重要なこと：

• 従来のRBACでは、 RoleエンティティはRoleRightsを介してオブジェクトとオブジェクトの間に接続が必要です
• RBACはありませんが、 ACLが支配的であるため、この接続は存在せず、したがって、必要に応じて、ロールを介してオブジェクトへのアクセスを提供します-それらは、対応するオブジェクトのACL

デフォルトのアクセス

マルチレベルセキュリティモデルを実装しましょう。 オブジェクトの機能に基づいた権利の分配。 ObjectKindにします。



ご覧のとおり、オブジェクトには分類属性ObjectKindが含まれるようになり、SecurityAspectLeafの新しい相続人（つまり、他のSecurityAspectの階層を含めることができないことを示すヒント）がObjectKindAccessという名前で表示されます。 RoleとPrincipalSecurityAspectの場合のように、彼とプリンシパル間の通信が保証されます。



最も重要なこと：

• 従来のマルチレベルでは、権利を付与するためのオブジェクトエンティティに分類子とすべての
• ACLはprimaryであるため、マルチレベルモデルが機能するオブジェクトについては、対応するSecurityAspectをACLに登録する必要があります

依存アクセスリスト

そして最後に、 依存アクセスリストに関する問題1がまだあります 。

本質を思い出させてください。1つのビジネスプロセスに参加するオブジェクトは、それぞれ独自のアクセスリストを持ち、多くの場合、このプロセスのすべての参加者が利用できる必要があります。 つまり ユーザーがオブジェクトAへのアクセス権を持っている場合、ユーザーはオブジェクトBへのアクセス権も持っている必要があります（通常、限られた権限セットで）。



実現する



いつものように、SecurityAspectCompositeからLinkedAccessという名前の新しい後続を作成しました。



秘Theは、このSecurityAspectが関連付けられたオブジェクトのルートSecurityAspectを「ラップ」 することで 、これにアクセスしたすべてのユーザー、および現在のオブジェクトにアクセスできるようにすることです。 LinkedAccessRightsを介してLinkedAccessで定義された権限は、関連付けられたオブジェクトにアクセスできる人の権限を制限するか、権限のセットを拡張します（ビジネスロジックの要件に応じて）。

次は何ですか

次の記事では、 最初の記事の必須要件を前提として、 これらすべてをデータベースにマッピングします。

「上記の問題の解決策の背後にあるアーキテクチャソリューションは、検索中のオブジェクトのフィルタリング速度に絶対に影響を与えず、オブジェクトおよびオブジェクトのリスト（大きなオブジェクトを含む）の操作速度に最小限の影響しか与えません。

何を読む

役割ベースのアクセス制御の設計パターン

アクセス制御のパターンとパターン図

セッションベースのアクセス制御のパターン