Clever Geek Handbook

ECMシステムのアクセスリストに基づくアクセス制御の問題

この記事では、ITで最も退屈な興味深いこと、つまりソフトウェアアーキテクチャ、つまり最も重要な部分の1つであるセキュリティについて説明します。



用語を定義しましょう



ソフトウェアによって、私は主にECMシステムを理解し、対象領域のオブジェクトへのアクセスを制限するという観点からのみセキュリティを検討します。



ECMについて少し



ウィキペディアから




エンタープライズコンテンツ管理（ECM）-デジタルドキュメントおよびその他の種類のコンテンツ、ならびに組織内での保存、処理、配信の管理[1]



MS SharePoint、Alfresco-これらはすべてECMシステムです。 一方、真空中の一部の球状ECMを考慮せず、同時に記事を既存のソリューションに限定しないために、独自の単純なECMシステムを考え出します。



サブジェクト領域について少し



したがって、ECMシステムが、ある組織のドキュメント管理の分野で機能するようにします。 彼は少女秘書にクーリエに税からの手紙を届け、彼女がそれをシステムに送ったので、会計士は答えを見て、そしてもちろん（システムを通しても）答えを生成しました。



上司は新しい最適化のアイデアを思いつきました-また、システムに、近いものと議論するために。 休日はもうすぐ来るのですか 少女秘書は、休業日のために命令を出します。 また、システムを通じて、誰もが見ることができます。



もう少しフォーマル



上記からわかるように、私たちのシステムはドキュメントを処理します。その一部は組織の外部から来ており、システムに登録して適切な人がレビューする必要があります。一部は組織で作成され、内部使用を目的としています。別の部分も組織自体で作成されますが、彼の人生のある段階で「外へ」送ること 。



インスタンスへのアクセスの差別化



上記の例をより詳しく見ると、5月の休日に関する少女秘書の手紙と、誰かを最適化することに関する上司の考えがわかります。これらはすべて、組織の従業員専用の「内部」ドキュメントです。 しかし、これら2つのドキュメントには、それらを表示および変更することを許可されているユーザーのサークルが少し異なることが示唆されます。 したがって、すぐに、サブジェクト領域内の同じタイプのオブジェクトのように見えるために、 異なる方法で異なるインスタンスへのアクセスを区別する必要があるという結論に達しました。



アクセス制御リスト



したがって、このデータ構造にスムーズに到達します。







すべてがすぐに良くなったようです-現在、サブジェクト領域の各オブジェクトに対して、システムの個々のユーザーに異なる権限を割り当てることが可能です。 しかし、問題はすぐに発生します。少女秘書は次のように叫びます。





デフォルトのアクセスリスト



小脳に負担をかけ、この解決策を考え出します。







オブジェクトの分類属性を見つけ、それを別のエンティティとして選択し、「デフォルトアクセスリスト」を開始し、この分類属性自体のデフォルトアクセスリストに基づいて作成されたオブジェクトのアクセスリストの編成を編成します。



女の子の秘書は後ろにいますが、叫び、感染、管理者、そして彼はこれについて不平を言います：





ユーザーグループ



次のように問題を解決します。







オブジェクトアクセスリストとデフォルトアクセスリストの両方で指定できるグループにシステムユーザーを結合する機会を提供します。 グループは、ユーザーと他のグループの両方を結合できます。



少女秘書の背後にいる私たちの背後にある管理者、なぜなら ユーザーグループがシステムに作成され、ユーザーグループがデフォルトでアクセスに追加され始めました。 管理者はグループからユーザーを削除/追加しただけで、システム内のすべてのドキュメントにアクセスできなくなりました。



しかし、他のすべての人は激しく叫びました。 システムの速度が低下し始めました。



事実、システムには非常に合理的な要件があり、ユーザーが権利に関する文書を読むことができない場合、 その存在をまったく知らない必要があります。つまり、システム内のオブジェクトの検索結果は権利に基づいてフィルター処理する必要があります。ユーザー。



もちろん、私たちのシステムのプログラマーは有能であり、データベースレベルでフィルタリングを行っていますが、それでも彼らはこのために複雑な再帰クエリを使用する必要がありました（ユーザーはグループの一部であり、グループは他のグループの一部である可能性があることを覚えています）。



ツリーのサポート



どうする 研究所で教えられたことを漠然と思い出し、階層構造をフラットな構造に展開するメカニズムを実装します。 このメカニズムには名前がありますが、残念ながら覚えていません。 TreeSupportと呼びましょう：







TreeSupportテーブルを作成するためのルールは次のとおりです。





例：



階層構造：





ツリーのサポート

親 子
ユーザー1 ユーザー1
グループ1 グループ1
グループ2 グループ2
ユーザー3 ユーザー3
グループ1 ユーザー2
グループ1 グループ2
グループ1 ユーザー3
グループ2 ユーザー3


実装しましたか？ やった！ これで、検索中のオブジェクトのフィルタリングがすぐに行われます。1つの結合で、次のようになります。 



select Id from Object o join ACL a on o.Id = a.ObjectId join TreeSupport t on t.ParentId = a.SecuritySubjectId where t.ChildId = < > and a.CanRead = 1


確かに、ユーザーとグループの階層構造を変更することをより困難にする代わりに、TreeSupportを更新する必要があります。 まあ、少なくともそれはめったに変わりません。



私たちのシステムはシンプルで控えめですが、アクセスリストに基づいたこのようなセキュリティ構造で生きることができます。 しかし、人生、それはより複雑であり、すぐに多くの問題に遭遇するでしょう、その解決はそれほど簡単ではありません。 以下では、これらの同じ問題と、次の記事での解決策について説明します 。 私もあなたの意見を聞いてうれしいです。



問題1-依存アクセスリスト



実際には、それぞれが独自のアクセスリストを持つドメインオブジェクトは、多くの場合、ビジネスプロセスの一部として一緒に使用されます。



例：契約とこの契約の行為、着信ドキュメント、および応答（発信）で作成されたドキュメントを示します。 このようなオブジェクトを使用する場合、ユーザーがオブジェクトAにアクセスできる場合、それに関連付けられているオブジェクトBにもアクセスする必要があるという要件を満たす必要がある場合があります。権利により、施設A へのアクセスとは異なります。



問題2-権限の委任



または別のシナリオ-ユーザーはボスであり、彼は代理人を持っています。 したがって、彼がアクセスできるすべてのオブジェクトは、同じ権限または制限された権限を持つ代理人が自動的に利用できるようにする必要があります。



問題3-多数のオブジェクトへのアクセスを提供する



非常に一般的な状況は、ユーザーが数年間システムを操作および操作しており、アクセスリストで、たとえば100kオブジェクトで強調表示されてから...終了する場合です。



別の人が彼の代わりに任命され、今では彼は辞任したのと同じ施設にアクセスできるはずです。 彼が同じオブジェクトに確実にアクセスできるようにするには、すべてのオブジェクトを列挙し、それらのアクセスリストを変更する（依存オブジェクト、代替オブジェクトなどを考慮に入れる）という長いプロセスを開始する必要があります。



多くの場合、このプロセスには非常に長い時間がかかります。 そしていくつかのシナリオでは-許容できないほど長い。



手動アクセスリストの編集



そして最後に、直接頼むアイデアに関するコメント-そして、ユーザーに自分でアクセスリストを編集させてみましょう。 だから-それは動作しません。



アクセスリスト-これは、システムでの作業時間の99％でユーザーから隠されるべきものです。 したがって、システムを操作する典型的なシナリオの実装中のアクセスリストの変更はすべて自動的に行われる必要があります。 また、上記の問題の解決策の背後にあるアーキテクチャソリューションは、検索中のオブジェクトのフィルター処理の速度に絶対に影響を与えず 、オブジェクトおよびオブジェクトのリスト（大規模なものを含む）の操作速度に最小限の影響しか与えません。



上で書いたように、これらの問題を解決することについてあなたの考えを聞いてうれしいです。



UPD ： 次の記事


More articles:


All Articles