ログオントリガー内の[実行]コンテキストの切り替え

StackOverflow https://stackoverflow.com/questions/3148616

質問

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'のログオンが失敗しました。
データベースコンテキストを「マスター」に変更しました。
言語設定をUS_Englishに変更しました。 （Microsoft SQL Server、エラー：17892）

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

エラー：15590、重大度：16、状態：1。
Adhocレベルで「as as」ステートメントを使用して、「revert no」または「cookie」オプションのみを使用できます。
エラー：17892、重大度：20、状態：1。
トリガーの実行により、ログイン 'mycomputer mywindowsusername'のログオンが失敗しました。 [クライアント：xxx.xxx.xxx.xxx

このエラーは、ログオントリガーの実行コンテキストを永久に変更できないことを意味しますか？

役に立ちましたか？

解決

セッション全体の実行コンテキストを変更することは可能ではないと思います。特定のapp_name（）のロールバックを実行するデータベース内のすべてのテーブル/ビューの挿入、更新、および削除用のDMLトリガーを作成できます。これらすべてのトリガーの作成を自動化する手順を作成できます。

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

他のヒント

アプリケーションを制御し、それを変更できると仮定すると、アプリケーションの役割は必要なことを正確に行います。開始するには、オンラインの本のsp_setapproleを参照してください。

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

  • ユーザー接続は、ASを使用した特定のスコープを除き、全体に同じ資格情報を持っています。
  • app_name（）またはhost_name（）に頼ることができないことがわかりました。
  • アプリは、直接テーブル書き込みアクセスに依存しています

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

  • あなたのアプリは保存されたProcsを使用し、ユーザーはテーブルにのみ読み取りアクセスを持っています
  • アプリでset context_infoを使用して、ロールバックトリガーの「秘密」キーを設定します
  • アプリを変更してサービスアカウントを使用します/Windowsサービス/などです。
  • ...またはいくつかの順列

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

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

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

また、そのアプリがクリーンであると信頼されておらず、それが何をしているのかを知っていると信頼されていない場合は、SQL Serverにタッチする前にコードレビューを受ける必要があることを要求します。それがあなた自身のアプリの場合、自分自身を信頼し始めてください:-)

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top