1

一部のアプリケーションがログインできるようにするSQLサーバーを実行する製品に取り組んでおり、そのログインにはストアドプロシージャを実行する権限が付与されています。ストアド プロシージャは管理者が所有しています。ストアド プロシージャはクエリを受け取って実行し、結果がアプリケーションに返されます。

残念ながら、アプリケーションがアクセスを許可されたストアド プロシージャを呼び出すことができる理由はわかりませんが、ストアド プロシージャは渡された SQL ステートメントを実行できません。

管理者としてログインしている場合、ストアド プロシージャは渡されたクエリを実行しますが、制限付きユーザーとしてログインすると、execute ステートメントで例外がスローされます。

例えば：

EXEC [Admin].[STORED_PROC] @SQL_STATEMENT = 'SELECT * FROM table_x'

STORED_PROC は次のようになります。

BEGIN TRY
   EXEC (@SQL_STATEMENT)
END TRY
BEGIN CATCH
   -- some logging when an exception is caught, and the exception is caught here!!!
END CATCH

EXEC を除いて、try catch ステートメント内には何もありません。SQL_STATEMENT は、管理者としてログインしている場合は機能しますが、ユーザーとしてログインしている場合は機能しません。

ユーザーがストアド プロシージャのみを介してクエリを実行できるようにするために設定する必要があるアクセス許可を特定するのを手伝ってくれる人はいますか?

そのため、ストアド プロシージャを介して生の SQL ステートメントを実行できるようにすることについて、いくつかのコメントがありました。ストアド プロシージャを使用する目的を無効にします...しかし、実際には、暗号化された SQL ステートメントをストアド プロシージャに渡しています。ストアド プロシージャはステートメントを復号化し、それを実行します。

そうです、実際には生の SQL ステートメントは安全ではなく、ストアド プロシージャの目的を無効にしますが、ODBC を介して渡され、2005 年より前の SQL Server に対して実行される SQL クエリを暗号化する方法がわかりません。

いずれにせよ、少なくとも基本的なセキュリティを確保するために、最低限の安全策を講じようとしました。

4

6 に答える 6

6

動的SQLを使用しているため、SQLサーバーは使用しているテーブルを認識できないため、すべてのテーブルにもSELECT権限を付与する必要があります

于 2009-02-05T18:19:55.910 に答える
4

ユーザーには、テーブルに対する SELECT 権限も必要です

于 2009-02-05T18:17:55.023 に答える
4

生の SQL をストアド プロシージャに渡して実行できるようにすることは、データのセキュリティの本質です。

SQL Server のセキュリティは、SQL の任意の部分が独自のセキュリティ コンテキストで実行されるように構成されています。クエリをアドホックに実行する権限がない場合は、ストアド プロシージャを介してクエリを実行する権限もありません。この点で、SQL Server はあなたを自分自身から救っています。

于 2009-02-05T18:22:40.303 に答える
0

これは、スキーマが異なるためである可能性が最も高いです。つまり、ログインするユーザーが管理者スキーマの一部ではないか、少なくともそうでないことを願っています。

達成しようとしているタイプのアクセスを許可する、つまり同じスキーマによって所有されているオブジェクトへのアクセスを許可するセキュリティ手法は、所有権の連鎖と呼ばれます。

この原則は、投稿で説明するのが最も適切ではありません。

これは、概念を説明する Microsoft からのリンクです。

http://msdn.microsoft.com/en-us/library/ms188676(SQL.90).aspx

これは、他の手法の中でも特に、所有権の連鎖の例とウォークスルーを提供するセキュリティに関する優れた記事です。

http://www.sommarskog.se/grantperm.html

これが明確で参考になることを願っていますが、お気軽にさらに質問をしてください.

乾杯、ジョン

于 2009-02-05T20:47:15.037 に答える
0

システムはストアド プロシージャへのアクセスのみを許可しているため (これはセキュリティ上の目的に適しており、変更しないでください)、どのような状況でも動的 SQL を使用することはできません。これは、権限がテーブル レベルではなく、DBA が変更される可能性が低いためです。それ。これは、SQL インジェクション攻撃を防ぐためだけでなく、内部不正の可能性を防ぐためでもあります。そのため、これを重要視している職場は、あなたの生活を楽にするために妥協することはありません。動的に何もしないように再設計するだけです。他に選択肢はありません。そもそもやりたいことをするようにprocsを書いておけば、暗号化されたsqlを送る必要はありません。

于 2009-02-05T19:03:05.793 に答える
0

EXECSP を介して、またはsp_executesqlSP 内で動的 SQL を使用する場合、SP のEXEC権限では、動的 SQL で任意のコードを実行することはできません。許可する必要がある(yuck) か、またはSELECTを使用して別のユーザーになりすますことができる場合があります。EXECUTE ASSETUSER

通常の SQL を使用すると、EXECパーミッションは正常に機能し、許可されていないパーミッションが上書きされSELECTます。ただし、持っている場合はDENY、それが勝ると思います。

そうは言ってもEXECUTE AS、SQLのソースがSPの外部（またはデータベースの外部）にある場合に使用する必要があるかどうかはまだわかりません。外部の影響から安全なコード生成または動的SQLEXECUTE ASの場合、便利なツールになる可能性があります

于 2009-02-05T19:06:28.187 に答える