0

興味深いデザインの質問があります。私はプロジェクトのセキュリティ面を設計しています。これにより、さまざまなコストでさまざまなバージョンのプログラムを使用できるようになり、管理者タイプのユーザーがプログラムの一部へのアクセスを他のユーザーに許可または拒否できるようになります。それはウェブベースになり、私たちのサーバーでホストされます。

「リソース」または画面ごとに単純な許可または拒否オプションを使用しています。

多数のリソースが用意され、ユーザーはさまざまなグループを設定して、アクセスを制御するためにユーザーを配置できます。各ユーザーは、1 つのグループにのみ所属できます。

私はこれに対して 2 つのアプローチを念頭に置いており、パフォーマンスの点で SQL サーバーにとってどちらが優れているかを知りたいと思っていました。

オプション A アクセス テーブルにエントリが存在するということは、アクセスが許可されていることを意味します。これにより、情報を格納するためにデータベースに列が必要なくなります。結果が返されない場合、アクセスは拒否されます。

これはより小さなテーブルを意味すると思いますが、クエリはテーブル全体を検索して一致するものがないと判断しますか?

オプション B 許可/拒否を制御するデータベースにビット列が含まれています。これは、常に結果が見つかることを意味し、テーブルが大きくなります。

考え？

4

4 に答える 4

4

許可/拒否のみの場合は、ユーザーとリソースの間の単純なリンク テーブルで問題なく機能します。リンク テーブルに User-Resource をキーとするエントリがある場合は、アクセスを許可します。

UserResources
-------------
UserId FK->Users
ResourceId FK->Resources

SQLは次のようになります

if exists (select 1 from UserResources 
where UserId = @uid and ResourceId=@rid)
set @allow=1;

クラスター化されたインデックス (UserId と ResourceId) を使用すると、何百万ものレコードがあっても、クエリは驚くほど高速になります。

于 2008-08-22T20:41:25.190 に答える
1

私はオプション B に投票します。オプション A を使用し、ユーザーが存在する場合に侵入できると仮定すると、最終的には、削除せずにユーザーへのアクセスを拒否する必要があるという問題に遭遇します。ユーザーレコード。

ユーザーをロックアウトしたいが、アカウントを完全に破壊したくない場合はたくさんあります。そのような例の 1 つ (必ずしもユース ケースに関連しているわけではありません) は、支払いに失敗した場合で、支払いを再開するまでアカウントが停止されます。アカウントを最初から再作成してすべてのユーザー履歴を失うのではなく、再度支払うときに有効にしたいため、レコードを削除したくありません。

于 2008-08-22T20:33:56.567 に答える
0

B. データが完全かどうかをより適切にチェックできます (たとえば、許可/拒否可能な機能を追加する場合)。

また、テーブル サイズは、多数のレコード (100,000 以上など) が含まれることがわかっているテーブルに対してのみ考慮する必要があります。この質問にテーブルサイズの考慮事項を入力するのに時間をかけても、必要な追加のハードドライブスペースよりも多くの費用がかかります.

于 2008-08-22T20:35:30.510 に答える
0

アプローチAですが、暗黙の拒否に加えて明示的な拒否も含めます。最終ロジックが機能することを確認するためにいくつかのユースケースを作成しますが、ここにいくつかの例を示します。

User1 is in group1 and group2.  
User2 is in group1  
User3 is in group2 

Folder1 allows group1 and deny group2.  
User1 is denied.  
User2 is allowed.  
User3 is denied.

あなたのアプローチusers1は許可されると思います。

于 2008-08-22T21:02:17.870 に答える