既存のアプリケーションにきめ細かなセキュリティを適用する

Question

SQL ServerでEFコードファーストを使用して、相当に大きく複雑なASP.NET MVC3 Webアプリケーションを継承しました。データベース認証でASP.NETメンバーシップの役割を使用します。コントローラのアクションは、ロールをアクションにマップするAuthorizeAttributeから派生した属性で保護されます。特定のウィジェットを特定のロールに表示するなど、細かい点の拡張メソッドがあります。これは素晴らしい作品です。現在のセキュリティモデルをよく理解しています。

データレベルでより細かいセキュリティを提供するように求められました。たとえば、「顧客」ユーザーは、自分自身に関連付けられたデータ（データベース全体）を見ることができ、他の顧客は表示できません。問題は、「顧客」が独自の固有の制限を持つ5つの異なるタイプのうちの1つだけであることです（9つのロールのそれぞれが5つのタイプのうちの1つです）。

私が考えることができる最も良いことは、すべてのデータリポジトリを調べ、すべてのLINQステートメント/クエリをすべてのユーザータイプのフィルタで拡張することです。たとえそれに時間があったとしても、それは最もエレガントな方法のようには見えません。

提案がありますか？私は本当にどこから始めるべきかわからないので、何かが役に立つかもしれません。

多くのありがとうございます。

Answer 1

データ駆動型のセキュリティは、クエリで実行する必要があります。これをプロジェクトの後半に追加するには、本当に時間がかかります。プログラミングによるものではなく、テストによるものです。経営陣がこの要件を持っている場合は、単にそれを受け入れなければなりません。

いくつかの基本クエリをリファクタリングして開始することができます。すべてのクエリは、DbSetにアクセスする必要があります。DbSetにアクセスする代わりに、そのセットのセキュリティを適用するヘルパーメソッドにアクセスする必要があります。派生した文脈でDbSetを公開したり、独自のDbSetを派生させて、IQueryalbe.Expression（明示的に実装）を再実装して、フィルタリングロジックを直接セットに追加することもできます。

実際の合併症は、怠惰で熱心な負荷から始まりました。 EFは、遅れてまたは熱心に読み込まれたデータをフィルタリングする方法を提供しません。うまく設計された集約では、クロス顧客の遅延読み込みと熱心な読み込みは必要ありません。必要な場合は、適切に機能するようにコードの一部をリファクタリングする必要があります（クエリに条件を追加することだけではありません）。