みなさん、こんにちは。
私は次のケースを勉強しています：
シナリオ：アプリケーションは、ドメインユーザーの代わりに汎用の「SA」ユーザーを使用して本番データベース（SQL Server 2008）に接続します。これにより、トレース\ログ\組織が難しくなります。これは、すべてがSAユーザーによって実行されたものとしてフラグが立てられるためです。
注：ドメインユーザー/パスワードが使用されるアプリケーションでは、汎用アカウントはデータベースのみに関係します。
質問：この場合の最良の方法は何でしょうか？すべてのユーザーは、データベースにログインするためのアカウントを持っている必要がありますか？（Windows認証を使用したSQL）+-500人のユーザーがいますが、データベースのパフォーマンスに関する問題ですか？または一般的なアカウントが示されていますか？
どうもありがとう！
他の人が述べたように、それがオプションであれば、Active DirectoryとWindows認証がより適切かもしれません. しかし、そうでなければ...
アプリケーションに、更新前に接続とトランザクションを作成する中心的な場所がある場合は、 SET CONTEXT_INFOを使用して、ログインに共有 SQL アカウントを使用しながら、「実際の」アプリケーション ユーザーを渡すことができる場合があります。
次に、監査トリガーで、 CONTEXT_INFO() 関数を使用して情報を再び引き出すことができます
これは、少なくとも 1 つの商用監査ツールで使用されているアプローチです。
context_info を参照する同様の SO の質問hereおよびhereと、NHibernate の例を示すブログ投稿Exploiting Context_Info for Fun and Auditも参照してください。
あなたの質問で何か別のことを考えてください：あなたはそれがsaユーザーを使用していると言いました。これは単なる例かもしれませんが、おそらくアプリケーションはサーバー上でそれほど多くの権限を持つべきではありません。アプリケーションが使用する特定のデータベースに必要な権限のみを持つユーザーを作成します。これにより、アプリケーションにおける将来のセキュリティの脆弱性 (SQL インジェクションなど) の影響が制限されます。さらに一歩進めると、読み取り専用ユーザー アカウントを持つ接続文字列が 1 つあり、データを更新するトランザクションを作成する時点で、読み取り/書き込みユーザー アカウントを持つ接続文字列に切り替えることができます。接続プーリングのほとんどの利点は引き続き得られますが、アプリケーション層のバグの影響をさらに制限できます。