2011-02-04 7 views
2

セキュリティの要件が少し異常です。ベストプラクティスまたは少なくとも脆弱ではないアプローチについてのアドバイスを探しています。ASp.NET MVC EF4 SQLテーブルまたはフィールドレベルのセキュリティ

シナリオ:イントラネットシステム。多くの関連エンティティに関するデータはプライベートと見なされます。これは、システムの未公開部分として知られています。特定のユーザーだけがこのデータにアクセスできます。いくつかの段階で、ユーザーはこのデータから選択し、いくつかのレコードをマークし、それらを「公開」側に公開します。公開側に公開されたデータは、未公開側から削除されます。システムユーザーの大半は、公開された側のレコードで作業することができます。

これは親レコードのboolフィールドのように聞こえますが、公開されているか未公開であるとフラグされていますが、置き換えようとしているシステムがどのように問題に取り組んでいるかを説明します。パブリッシュされていないパブリッシュされたデータを別々のテーブルに保存し、別々のサーバードライブに保存し、別々のテープにバックアップします。ネットワーク権限は、公開されたユーザーが未公開データを取得できないようにします。ソフトウェアは権利も管理しますが、それが間違ったり、プログラマーが間違いを犯したりすると、間違ったデータにアクセスすることはできません。潜在的にこのデータをブローさせる可能性のあるシステム管理者は、肯定的な審査済みのセキュリティ許可を持っています。

私が探しているのは、これを実現するMVC、EF4、SQLでアーキテクチャを達成する方法に関するアドバイスです。ある極端な場合、私は2つのSQLデータベース、異なる権限を持つ2つのシステムを構築します。潜在的にweb.configに含まれる相違点と同じで、実際は同じコードベースです。スケールの反対側では、コントローラメソッドを持つテーブルのフラグがマークアップされ、アクセスを拒否しました。 (プログラマーが検索クエリを駄目にして間違ったカテゴリのデータを返すと、それが建物の外に出てしまい、人間の犠牲になってしまう可能性があるからです。ヒステリー)

大変申し訳ございません。ベストプラクティスまたはこれにアクセスする方法に関するその他のアドバイス

+0

? :) – RPM1984

+0

それは王室に関連しています。 – Andiih

答えて

2

ないMVC/EF-固有の答えが、多くの問題に答え、有用である可能性がある(SQL Server 2005の)古いTechnetの紙があります:

「の実装行優先とセルレベルのセキュリティでは、 SQL Server 2005を使用して分類されたデータベース "

Available on Technet同じ論文はdownloaded as a Word documentでもよい。

+0

それは興味深い考えです。システムには少数のユーザーしかいないため、接続プーリングを回避すると拡張性の問題はありません。ユーザーごとに1つの接続を使用したことはありませんが、これは信頼できる接続を使用している場合にすぎず、と考えられます。私はそのペーパーを詳細に読むでしょう! – Andiih

+0

私は偽装を介してテーブルレベルのセキュリティを使用しています。接続プールに慣れているので、忘れてしまいました。 – Andiih

1

正直、私はEntityFrameworkがあなたが探しているORMだとは思わない。あなたが提供するものよりも制御が必要になるでしょう。私が考えていることは、接続の監査情報を設定して、誰が誰であるかを知って、おそらくログオン・トリガーを実行してから、関係を傍受するコードコードセキュリティを実行します。あなたはORMを使用して上の注目している場合、この読みprehaps:情報は、あなたが言うほど重要か秘密である場合は、データベースのセキュリティを実装する必要がしようとしている

Nhibernate vs EntityFramework in the real world

を、それがすることはできませんアプリレベルのセキュリティを確保するのに十分です(徹底的な防御を考えてください)。

Webサーバーとアプリケーションサーバーを展開してwcfと接続していると思われるので、質問はMVCが行うものではなく、MVC、WCF、ORM(もしあれば)相互作用するだろう。

もう1つの方法は、SQL Serverで未発行データをマスクする更新可能なビューを使用することです。

+0

興味深い読書。私はNhibernateに少し詳しく行きます。監査の要件、ログオン・トリガーなどがあります。更新可能なビューが役立つかもしれませんが、それでもユーザーに関連付けられたテーブル・レベルのセキュリティは提供されません。それはおそらくそれがあったはずですが、階層化されたデプロイメントではなく、WCFはありません!私は「私たちがどこにいるのか」に入るつもりはありませんが、すでに多くのシステムが導入されています。 – Andiih

1

すべてのエンティティがコアIDフィールドの共通基本クラスを共有する場合、それほど難しくありません。あなたのエンティティが共通の基本クラスを共有している限り、エンティティのキ​​ーとその操作を試みるユーザーのIDを使用するそのベースの拡張メソッドを作成することができます。あなたのデータアクセス層。

public static bool ActionIsAuthorized<T>(this T entity, ActionType actionType, string  actionBy) where T : BaseEntity 
{ 
    bool authorized = false; 
    //do your auth lookup here based on which kind of action they are performing. ActionTypes  is an enum 
    return authorized; 
} 

そして、ちょうどこのようにそれを呼び出します、どのような業界であなたが作業している好奇心から

if(!YourEntity.ActionIsAuthorized(ActionType.Update, username)) 
{ 
    throw new ActionUnauthorizedException(); 
} 
else 
{ 
    //do data access stuff here 
} 
関連する問題