0

私は、SQL Server のセキュリティ関連の問題に頭を悩ませようと懸命に探してきました。SQL Server 2008 を対象とする .NET アプリケーションを開発しており、FileStream を使用したいと考えています。

統合セキュリティを使用している場合、SQL Server は Win32 API を介した FileStream のみを許可することがわかりました。問題は、アプリケーションの約 80% が完成していることですが、それは完全に SQL 認証に基づいています。そのため、アプリケーションで INSERT のストレート フォームを実行しており、すべての CRUD 操作にストアド プロシージャを使用していません。

これは、SQL のユーザー名とパスワードを暗号化された形式で保存できるため、比較的安全です。パスワードが平文で転送されることは知っていますが、それを受け入れるつもりです。

エンド ユーザーが Crystal Reports などのツールを介してデータベースに接続できるようにしたいと考えています。そのために、SELECT 権限のみが付与された追加の SQL ログインを用意しています。

ここで、統合セキュリティに変更する場合、(AD グループなどを介して) 個々のユーザーに、アプリケーションが実行できることを実行する権限を付与する必要があります。そうしないと、アプリケーションはその作業を行うことができなくなります。ただし、エンドユーザーは、DB に直接接続するときにもこれらの権利を持ちます。

すべての CRUD 操作にストアド プロシージャを使用し、AD グループにのみ EXEC 権限を付与する必要があると言っている人を見かけますが、どうすればよいでしょうか? ユーザーが直接接続するとき、またはアプリケーションを介して接続するときに、ユーザーがどのように異なる権限を持つのかわかりません...これについて誰か教えてもらえますか。

ボーナス ポイントに関する追加の質問: 私が理解している限り、統合セキュリティはワークグループでは機能しません。では、ワークグループで FileStream を動作させるにはどうすればよいでしょうか。それとも、これは不可能と見なされますか?

4

1 に答える 1

4

  1. 統合セキュリティは、2 台のマシンでユーザー名とパスワードが一致する従来のメカニズムを使用して、ワークグループで機能します。また、サーバーに一致するユーザー アカウントがある場合、ドメイン ユーザーはレガシー メカニズムを使用して非ドメイン サーバーにログインできます。

  2. 統合されたセキュリティは、ユーザー名とパスワードが一致しない場合でも機能します。これは、シナリオで役立つ場合があります。

これを試して：

NET USE \\DBSERVER /USER:DOMAIN\USERNAME

パスワードの入力を求められます。これにより、データベース サーバーとの NetBIOS セッションが確立されます。完了すると、データベース サーバー上の共有フォルダーと共有プリンターが表示されるはずです。

クライアント コンピューターとデータベース サーバーの間で NetBIOS セッションが確立されると、パスワードの入力を求められることなく、統合セキュリティを使用できるようになります。

TCPで動作しない場合は、使用するネットワークプロトコルとして「名前付きパイプ」を指定する必要がある場合があります（ただし、動作すると思います）。名前付きパイプは既存の NetBIOS セッションを継承するため、共有を一覧表示できれば、おそらく問題なく使用できます。

パスワードを組み込んだ (レベル 2) 情報を使用して、Windows API 関数NetUseAddを使用してログオン セッションを確立することもできます。USE_INFO_2

簡単に言えば、アプリケーション用に特別な Windows ログオンを作成し、それを使用してユーザーにログインさせることができるということです。ただし、独自のユーザー名とパスワードを使用して同じサーバーに接続することはできないことに注意してください。

于 2012-05-25T10:27:22.183 に答える