共有ログインを使用しているときに、監査テーブルで削除アクションを実行しているユーザーを知る方法は？

背景情報：

• アプリの一連のデータテーブルに対する更新と削除を追跡するために、監査テーブルのコレクションを作成しています。
• 監査レコードはトリガーを介して作成されます。
• アプリのデータベースのDMLは通常、サービスがデータベースにアクセスするために使用するログインから取得されます。このためSYSTEM_USER、トリガーで呼び出されたときの結果は常に同じになると思います。
• 私のアプリは現在ユーザーデータを保存していませんが、UserIdDMLが実行されるたびに文字列が与えられます（ストアドプロシージャでのみ行われます）。

私が遭遇した問題は、ユーザーがレコードを削除するときに、誰がそれをしたのか知りたいということです。同じログインによって行われるため、すべてのアクションがサービスによって行われたことを確認したくありません。どのユーザーがそれを実行したかを確認したいと思います。ModifiedBy更新の送信で更新される列があるため、これは更新の問題ではありませんUserId。

問題はSYSTEM_USER、削除が実行されたときに、ユーザー情報をトリガーに設定する方法、またはトリガーに取得する方法はありますか？

私が現在持っている「最高の」アイデアは、それが良いアイデアかどうかはまだわかりませんが、サービスで、現在のものUserIdがデータベースとしてユーザーに存在するかどうかを確認し、そうでない場合はユーザーを作成することです彼らのためのオブジェクト。次に、でストアドプロシージャを実行しEXECUTE AS User = @UserIdます。次に、ストアドプロシージャでDMLが実行され、トリガーが起動すると、SYSTEM_USERからユーザーを返す必要がありEXECUTE ASます。

EXECUTE AS User = @UserId（他の問題によっては）を使用するのが最善の方法かもしれませんが、代替のアプローチを次に示します。

ストアドプロシージャ内、またはSQLセッションでいつでもDELETE、次のコマンドを実行する前。

SET CONTEXT_INFO @UserId

次に、トリガーでこの値を取得できます

SELECT @var = CAST(CAST(CONTEXT_INFO() As Varbinary(4)) As Int)

これにはいくつかの欠点がありますが、最も重要なことは、一度に複数のものに対してCONTEXT_INFOを簡単に使用できないことです。

ユーザーコンテキストを個々のログインからサービスログインに変更する方法によっては、ORIGINAL_LOGIN（）が役立つ場合があります。

http://technet.microsoft.com/en-us/library/ms189492.aspx

「この関数は、元の接続コンテキストのIDの監査に役立ちます。SESSION_USERやCURRENT_USERなどの関数は現在実行中のコンテキストを返しますが、ORIGINAL_LOGINは、そのセッションでSQL Serverのインスタンスに最初に接続したログインのIDを返します。」

Host_Nameテーブルに追加することもできます。ログインを共有している状況では、人が自分のマシンで作業している時間の95％から、通常はマシン名で個人を追跡できます。常に機能するとは限りませんが、有用な副次的な情報となる場合があります。

SELECT host_name FROM sys.dm_exec_sessions WHERE session_id = @@SPID

残念ながら、ホストが常にWebアプリケーション自体になるWebアプリケーションで作業している場合、これは機能しませんが、試してみる価値はあります。