Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SQL Server: Modifying the "Application Name" property for auditing purposes

As we do not implement the users of our applications as users in SQL server, when the application server connects to a database each application always uses the same credentials to attach to each database.

This presents an auditing problem. Using triggers, we want to store every update, insert and delete and attribute each to a particular user. One possible solution is to add an "updated by user" column to every table and update this every time. This means a new column on every table and a new parameter on every stored procedure. It also means you can only do soft deletes.

Instead of this I propose using the Application Name property of the connection string and reading this with the App_Name() property inside the trigger. I tested this with a simple app and it seems to work (the format could be as so: App=MyApp|User=100).

The question for you guys is, is this a bad idea and do you have a better one?

like image 778
Chris Simpson Avatar asked Nov 27 '08 11:11

Chris Simpson


People also ask

What are the components of SQL Server auditing?

The SQL Server auditing feature encompasses three main components: The Server Audit. The Server Audit Specification. The Database Audit Specification.

What is a audit specification in SQL Server?

A Server Audit Specification defines which Audit Action Groups will be audited for the entire server (or "instance"). Some audit action groups comprise server level actions like the creation of a database or modification of a server role and hence are only applicable to the server itself.

What is audit trigger in SQL?

Database administrators can employ various techniques to audit the use of SQL Server databases for security and regulatory compliance purposes. One of the most common methods is creating SQL Server audit triggers to automatically capture information about transactions and changes to database tables.


2 Answers

I use SET CONTEXT_INFO for this. It's just what you need.

like image 88
Dave Markle Avatar answered Sep 18 '22 16:09

Dave Markle


It certainly seems like a feasible solution, although you'll need to inject the username into the connection string each time your application loads. Note that this solution probably wouldn't work with a web application, as your connection string will be different each time, which could lead to huge connection pooling issues.

Another option is to retrieve the hostname/IP address (SELECT host_name() ) and store that instead.

You wouldn't necessarily need a new parameter on each stored procedure, as you can modify each stored procedure (or the trigger) to automatically insert the App_Name/Hostname.

A potential drawback is that any modifications performed via Management Studio won't have the custom App_Name, and you'll be left with "Microsoft Management Studio" as the user.

like image 20
Jim McLeod Avatar answered Sep 18 '22 16:09

Jim McLeod