2

混合モード認証を使用して、Microsoft SQL Server 2008 Express インスタンスに MyDB というデータベースがあります。データベース MyDB を使用するアプリケーションは、現在、現在のユーザーの Windows 資格情報を使用して、Windows 認証を使用して接続します。このログインは「パブリック」サーバー ロールのメンバーであり、MyDB データベースでユーザーがマップされています。このデータベース ユーザーは、db_datareader および db_datawriter データベース ロールのメンバーです。

私が望むのは、アプリケーションが接続すると、MyDB で読み書きする権限があることです。ただし、別のアプリケーションが同じログインを使用して接続する場合は、読み取りのみを許可する必要があります。

私が考えたのは、接続文字列のアプリケーション名の部分をチェックするログオン トリガーを作成し、それに基づいて実行コンテキストを切り替えるかどうかを決定することでした。(記録として、接続文字列のアプリケーション名に依存することは決して安全ではなく、回避するのは非常に簡単であることを知っています。ここでの目的は、データベースを保護することではなく、ユーザーが変更を回避できるようにすることです。 Microsoft Excel などの別のアプリケーションを使用して接続した場合のデータ)

db_datareader のメンバーである MyDB データベースのユーザーにマップされた「myapp_reader」という新しいログインを作成しました。

次に、次の TSQL を使用してログオン トリガーを作成してみました。

CREATE TRIGGER CheckUser
ON ALL SERVER
AFTER LOGON AS
BEGIN
IF APP_NAME() <> 'My Application Name'
    BEGIN
        EXECUTE AS LOGIN = 'myapp_reader' WITH NO REVERT
    END
END

しかし残念ながら、それはうまくいきません。接続しようとすると、次のエラーが表示されます。

トリガーの実行により、ログイン 'MyComputer\MyWindowsUsername' のログオンに失敗しました。
データベース コンテキストを「master」に変更しました。
言語設定を us_english に変更しました。(Microsoft SQL Server、エラー: 17892)

そして、エラーログを見ると、次のように書かれています：

エラー: 15590、重大度: 16、状態: 1。
アドホック レベルの 'Execute As' ステートメントでは、'No Revert' または 'Cookie' オプションのみを使用できます。
エラー: 17892、重大度: 20、状態: 1。
トリガーの実行により、ログイン 'MyComputer\MyWindowsUsername' のログオンに失敗しました。[クライアント: xxx.xxx.xxx.xxx]

このエラーは、ログオン トリガーの実行コンテキストを永続的に変更できないということですか?

4

4 に答える 4

1

セッション全体の実行コンテキストを変更することはできないと思います。データベース内のすべてのテーブル/ビューに対して、特定の app_name() のロールバックを行う INSERT、UPDATE、および DELETE の DML トリガーを作成できます。これらすべてのトリガーの作成を自動化する手順を作成できます。

または、Excel などのアプリケーションをリンク サーバー経由で接続するオプションがある場合は、この時点で実行コンテキストを変更できます。また、ユーザーが Excel または他のアプリを介してサーバーに直接接続しようとした場合に、接続をロールバックするログオン トリガーを作成します。

于 2010-07-20T09:51:06.507 に答える
1

アプリケーションを制御し、それを変更できると仮定すると、アプリケーションの役割はまさにあなたが望むことを行います。開始するには、Books Online の sp_setapprole を参照してください。

于 2010-07-30T09:21:36.463 に答える
0

最初に資格情報を整理して管理する方法について、本当に決心する必要があります。

Windows 認証を回避し、そのアプリを介したアクセスをすべてのユーザーに許可する sp_setapprole を使用する場合。それが本当にやりたいことである場合、アプリがサーバーの場合は、そのアプリのユーザー アカウントを作成し、そのユーザーの資格情報で実行します。

クライアント アプリの場合は、アプリが必要とする特定のデータのみを読み取って送信する Web サービスを作成し、その Web サービスを新しいアカウントで実行します。次に、IIS7 では Web サービス自体に ACL を配置して、Web サービスを引き続き保護することができます。

また、そのアプリがクリーンであると信頼されておらず、そのアプリが何を行っているかを把握している場合は、SQL サーバーへのアクセスを許可する前に、コードをレビューするように要求してください。それがあなた自身のアプリである場合は、自分自身を信頼し始めてください:-)

于 2010-08-04T01:58:26.627 に答える
0

あなたが望む方法でこれを行うことはできません。

  • ユーザー接続は、EXECUTE AS を使用するいくつかの特定のスコープを除いて、全体を通して同じ資格情報を持ちます。
  • APP_NAME() または HOST_NAME() に依存して誰かが異なる接続を検出することはできないことに気付きました。つまり、テーブルごとのロールバック トリガーはそこに依存できません。
  • アプリはテーブルへの直接書き込みアクセスに依存しています

私が考えることができるいくつかのオプション...

  • アプリはストアド プロシージャを使用しており、ユーザーはテーブルへの読み取りアクセスのみを持っています
  • アプリで SET CONTEXT_INFO を使用して、ロールバック トリガーの「秘密」キーを設定します。
  • サービスアカウントを使用するようにアプリを変更します/Windowsサービスです/などで、ユーザー名をプロキシします（Webページと同じように）
  • ...またはそれらのいくつかの順列
于 2010-07-31T05:17:05.473 に答える