Sql-server – How to Audit any change in Permission

Don't bother tracking audit data on a per-field basis. It's much easier to have an audit table with the same structure as the main table and timestamp and user information tracked on the table.

This architecture has a few advantages:

• You can easily create a view across the main table and audit table to show a complete history includint current versions.
• It is relatively simple to implement the audit triggers - in fact if you hae a large number of tables you can write a utility to generate them from the system data dictionary.
• The audit tables can be put on a separate disk to reduce the I/O load on the disk with the main tables.
• It's very easy to reconstruct an as-at version of the record, rather than having to apply a list of field-level changes in reverse.

Audit information should include at least: user who created/changed the record, date/time of the creation/change, nature of change (insert, update, delete). You may want to use logical deletion (i.e. a 'Deleted' flag) if you have the option of doing so. Otherwise you need to capture the user and date/time from the session and put these on the deletion record, probably along with the last state of the record. If this is not available from the connection (often the case on N-tier apps where the user is not being impersonated at the database level) then you need to find some other way to get it.

Since you're using SQL 2012, you can leverage SQL Server Auditing, which was introduced with SQL 2008. SQL Server Auditing can be used to track a multitude of actions within SQL Server, include database object permission GRANT/REVOKE/DENY actions. You'll be able to see the security principal that executed the statement, when the statement was run, and what that exact statement was. To create your audit, you will need to perform the following:

Create an Audit

The Audit defines the over-arching logging for all the audits. To create an Audit, you can use the object explorer to browse under the instance to Security->Audits. Right click on Audits and select "New Audit". Fill out the next dialog (the important bit here is where you store the audit file, the rest you can use defaults on). After you create it, you will need to right click on the Audit in the object browser and enable it.

Create an Audit Specification

The Specification defines what action you want to track, using any combination of actions/groups to define the Specification. There are many different actions, both on the server and database level, that can be tracked. To create a Specification for database permission changes, browse under the database you wish to track in to Security->Database Audit Specifications. Right click and fill out the dialog. Select the Audit you created above to write to. Under Audit Action Type, select SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP from the drop down. This action allows you to track permissions changes on schema objects. Once you have this, click 'Ok' to create the specification. Then, in the object browser, enable it.

Viewing the audit

Once this is all complete, the audit is running and will capture and GRANT/REVOKE/DENY actions in that database. To view the audit logs, browse to the audit under the instance in Security->Audits. Right click on the audit and select 'View Audit Logs' and you will be able to see all the audit actions that have occurred in your database since you started the auditing.

As an alternative, your auditing can be enabled using T-SQL with the following commands:

--Create Audit
USE [master];

CREATE SERVER AUDIT [PermissionTracking]
TO FILE 
(   FILEPATH = N'C:\DBData'
    ,MAXSIZE = 0 MB
    ,MAX_ROLLOVER_FILES = 2147483647
    ,RESERVE_DISK_SPACE = OFF
)
WITH
(   QUEUE_DELAY = 1000
    ,ON_FAILURE = CONTINUE
);

--Enable Audit
ALTER SERVER AUDIT [PermissionTracking] WITH (STATE=ON);

--Create Database Audit Specification
USE [foo];

CREATE DATABASE AUDIT SPECIFICATION [FooDBPermissions]
FOR SERVER AUDIT [PermissionTracking]
ADD (SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP)
WITH (STATE=ON);