4

これは、何よりもベスト プラクティスと設計に関する問題だと思います。これに関する同様のクエリを検索しようとしましたが、見つかりませんでした。実際にEntity Framework を使用した Row Level Security を見つけましたが、ここでのコンテキストは少し異なると思います。

最初に私のシナリオを説明しようとします：

共通のビジネス ライブラリを使用して NHibernate 経由で SQL 2008 データベースにアクセスする .net 3.5 Web サイトがあります。コードはすべて C# で、NHibernate 2.1 を使用しています。私の Web サイトには、ビジネス ライブラリからのさまざまな IList が表示されます。ビジネス レイヤーは、NHibernate を介して SQL からすべてのデータを取得します。したがって、つまり、IList を返すメソッド、IList を返す別のメソッド、別の IList などを作成できます。ポイントは、アクティブなユーザーがすべての戻り値の一部にしかアクセスできないことです (ほとんどすべてのタイプの結果セットをセキュリティから除外する必要があります)。 )、そのため、許可されたデータ行のみを Web サイトに返す「データ フィルター」をライブラリに実装する必要がありました。これを実現するために、私の Web サイトの IPrincipal がラ​​イブラリで使用されているため、ユーザーの詳細を取得してデータをフィルター処理できます。しかし、私たちのセキュリティ モデルは非常に複雑であるため、それをすべてのメソッドに広げると、メンテナンスに大きな問題が生じます。これを解決するために、現在のユーザーに許可されたアイテムを返すいくつかの SQL SP を作成しました。ビジネス ロジックでは、要求されたデータをセキュリティ データと結合するだけで、最終的な結果セットをユーザーに送信できます。現在、データを結合するこのプロセスは、Linq to Objects を使用しており、リスト (セキュリティ) で iList を結合して、許可された結果セットのみを返します。IList はさまざまな方法で NHibernate から取得され、GetAll() メソッド、ICriteria.List() または IQuery.List()、または NamedQuery.List() によって取得される可能性があり、セキュリティ データは常に次のいずれかから取得されます。 2 つの NamedQuery.List()。また、スレッド化を実装して、SQL 呼び出しを同時およびスレッド後に実行できるようにすることも計画しています。join() は、両方の IList で LINQ 結合を実行します。メソッドを実行する必要がある方法を示すために、次のサンプル コードを追加しました。

2 番目のオプションは、SQL 側に結合を実装することです。すべての呼び出しは、セキュリティ結果で結合を実行し、ビジネス コードが取得できないようにする SQL SP から来る必要があります。 NHibernate 機能の完全な使用。

public IList<Product> GetAllByName(string FirstLetter) {
    ICriteria GetAllCriteria = this.session.GetISession().CreateCriteria(typeof(Product));
    GetAllCriteria.Add(NHibernate.Criterion.Restrictions.Like("ProductName", FirstLetter));
    GetAllCriteria.AddOrder(NHibernate.Criterion.Order.Asc("ProductName"));

    // Here would go the Threading for the both calls
    IList<Guid> AllowedItems = SecurityBase.GetAllowedItemsForCurrentUser();
    IList<Product> AllProducts = GetAllCriteria.List<Product>();

    var ResultSet = from Prod in AllProducts
                    join Sec in AllowedItems on Prod.Id equals Sec
                    select Prod;

    return ResultSet.ToList<Product>();
}

さて、私の質問ですが、これは行レベルのセキュリティに対するひどいアプローチ/プラクティスですか (私たちのセキュリティ モデルは非常に複雑でカスタマイズ可能であり、それはビジネス設計によるものであることを覚えておいてください)、それとも正しい方向に進んでいますか? 他に選択肢はありますか？

前もってありがとう、クレイトン

4

3 に答える 3

2

これが少し遅れていることは承知していますが、次のことを確認しましたか。

http://securedata.codeplex.com

これは、私が主任開発者を務めているオープン ソース プロジェクトであり、行レベル セキュリティをシームレスに実装しています。

于 2010-02-22T23:46:46.577 に答える
2

私は現在、同様の要件を持つプロジェクトに取り組んでいます。これはグリーン フィールド プロジェクトであり、コードはまだ作成されていません。行ベースのセキュリティに対するソリューションを探しているだけです。

次の 2 つの記事をお勧めします。

http://www.codeproject.com/KB/database/Modeling_DAGs_on_SQL_DBs.aspx http://www.codeproject.com/KB/database/AFCAS.aspx

スレッド化のアイデアに関しては、System.Threading を使用すると悲しくなります。Ritcher の AsyncEnumerator または Microsoft Concurrency runtime (CCR) を見てください。

于 2009-10-17T13:08:58.417 に答える
0

オプションとして、SQL SP を使用して許容可能なアイテムのリストを返す代わりに、ビュー内で同じロジック/結合を使用し、ビューのみをクエリする/基になるテーブルではなくビューにのみアクセス許可を提供することを検討しましたか?

于 2009-10-15T11:23:35.543 に答える