0

インターネット経由でアクセスできる、かなりシンプルなMVCフロントエンドを備えたかなり高度なDBになるプロジェクトの仕様を作成し始めたところです。ユーザーの処理方法がわかりません。2つのオプションがあります。

オプション 1 - SQL Server の組み込みのログイン/ユーザーを使用してユーザー認証を処理し、組み込みのユーザー アクセスを使用して、誰が何にアクセスできるかを制御します (ほとんどすべてが選択またはストアド プロシージャになります)。

オプション 2 - 独自のユーザー リスト (ハッシュ化されたソルト パスワードを使用) と独自のアクセス制御リスト (おそらく proc 名を使用OBJECT_NAME(@@PROCID)して別の proc に渡される) を使用し、すべてのプロシージャにアクセスできるアプリケーション プロファイルを介して DB のすべての書き込み/読み取りを行う/ビュー。

検索しましたが、どちらか一方を選択する必要がある理由が見つかりません。リンクを共有したり、一方が他方よりも優れている理由を提供したりできますか (または両方に明らかな問題がある場合)。

詳細が必要な場合は、お知らせください。

4

1 に答える 1

0

接続プールを介して SQL 認証 (ユーザーごとにオプション 1) を使用すると、パフォーマンスが比較的低下します。ユーザーごとにプーリングが行われますが、それでも数百または数千の接続が必要になる可能性があります。それを回避する方法はありますが、ソリューションはオプション 1 をオプション 2 のように機能させ始めるため、オプション 2 を使用することもできます。

各ユーザーの初期認証を行う SQL アカウントを作成するソリューションをいくつか見てきました (単一のアプリケーション ベースの SQL アカウントを介して)。残りはオプション 2 のように機能します (ここでも単一のアプリケーション ベースの SQL アカウントを介して)。これらのケースでは多くの SQL アカウントが使用されていたため、各ユーザーは一連のビューを所有し、スキーマを模倣することができました。スキーマとエイリアスは SQL Server 2005 以降で利用できるようになったため、その理由でオプション 2 を選択する価値はなくなりました。

最後に、SQL Server アプリケーション ロールも使用しないでください。これはセキュリティ対策として不適切です。Brian Kelly は、いくつかの問題 (長所と短所) についての記事 ( http://www.sqlservercentral.com/articles/Security/sqlserversecurityprosandconsofapplicationroles/1116/ ) で取り上げています。

于 2013-02-05T17:49:46.940 に答える