私は、エンティティフレームワークを使用して行レベルのセキュリティを実装する方法を検討してきました。アイデアは、ObjectContextからの行を制限するメソッドを提供するデータベースにとらわれない手段を持つことです。
私の最初のアイデアのいくつかは、EDMGENツールによって作成された部分的なクラスを変更することを含み、それはいくつかの限定されたサポートを提供しました。ユーザーは、独自のeSQLステートメントとQueryObjectを使用して、このソリューションを回避できます。
私は、データベースプロバイダーの上に存在し、不可知論者であり続けるための包括的なソリューションを探していました。
確かにあなたはそれを行うことができます。重要なことは、オブジェクト コンテキストへの直接アクセスをブロックし (ユーザーが独自の ObjectQuery を作成できないようにする)、代わりにエンティティにアクセスして変更するためのより狭いゲートウェイをクライアントに提供することです。エンティティ リポジトリ パターンでそれを行います。あなたは見つけることができます
ただし、考慮すべき微妙な点があります。リポジトリ パターンを介して特定のエンティティ タイプに行レベルのビュー セキュリティを実装する場合は、クライアントが同じエンティティにアクセスできる他の手段を検討する必要があります。たとえば、ナビゲーション関係を介して。これらのリレーションシップの一部を非公開にする必要がある場合がありますが、これはモデルで行うことができます。エンティティをロード/保存するためのカスタム クエリまたはストアド プロシージャを指定するオプションもあります。ストアド プロシージャは DB サーバー固有のものになりがちですが、SQL は一般的な方法で記述できます。
これが Entity Framework で実行できないことに同意しませんが、多層防御を実装する必要がある限り、「DB サーバーで実行する」というコメントには同意します。
セキュリティを追加する場所は、誰に対してセキュリティを確保しようとしているかによって異なります。
たとえば、Web サイトを保護している場合、この場合の「ユーザー」は Web サイト上にいるため、コンテキスト レベルでフィルタリングを追加するだけで十分です。コンテキストに対して完全にアプリケーションを作成するため、コンテキストを調べる以外に選択肢はありません。
あなたの場合、保護しようとしている「ユーザー」は開発者のようです。それはかなり難しいです。開発者がデータベース自体に変更を加えるアクセス権を持っていない場合は、データベース レベルでセキュリティを設定する必要があります。「いいえ」と言ってデータベースを回避できるeSQLアクセスの量はありません。
この記事は役に立つかもしれません:
http://msdn.microsoft.com/en-us/magazine/ff898427.aspx
「反乱を起こさずにEntity Frameworkへのテーブルアクセスを拒否する」
あなたが達成しようとしていることは、定義上、不可能です。
基礎となるデータベース アプリケーション (SQL Server、Oracle など) によってセキュリティが明示的に処理されない場合、SQL Management Studio などの標準ツールはすぐにそれを吹き飛ばしてしまいます。
あなたができる最善の方法は、アプリケーションのユーザーが別のメカニズムを介してデータベースにアクセスできない場合にのみ、アプリケーションのユーザーによって行レベルのセキュリティを強制することです。
Postgres とVeilという拡張機能を使用してそれを行う方法を見つけました。実際にはViews、すべての操作 (選択、更新、削除、挿入) を使用し、WHERE句の権限を検証するために (設計されて) 動作します。しかし、Veil は、パーミッションの情報を毎回クエリするのではなく、メモリ内で効率的に管理するための計算を追加するだけです。したがって、Veil を使用すると、DBMS に直接接続しても、行レベルのアクセスしか許可されません。
いくつかの方法でベールを使用してスタイルを変更します。たとえば、アクセス許可の制限を適用するTriggers代わりに使用するようになりました。Views
このソリューションを検討し、ここでそのロジックを適用することをお勧めします。
つまり、select * from tableクエリを作成すると、意図したとおりの結果が得られます (行レベルで言えば)。