ApexSQL-UnderstandingTheSQLServerAudit
ApexSQL-UnderstandingTheSQLServerAudit
By Minette Steynberg
Contents
Introduction ............................................................................................................................................ 2
Auditing in SQL Server prior to 2008 ...................................................................................................... 2
Auditing in SQL Server 2008 onwards ..................................................................................................... 2
Extended Events.................................................................................................................................. 2
Auditing Components ............................................................................................................................. 3
The Server Audit.................................................................................................................................. 3
Audit Specifications............................................................................................................................. 5
The Server Audit Specification ........................................................................................................ 5
The Database Audit Specification ................................................................................................... 6
User defined audit events ............................................................................................................... 7
Reading audit file data ............................................................................................................................ 8
Securing the audit logs ............................................................................................................................ 8
Restarting SQL after a forced shutdown ............................................................................................... 10
Best Practices ........................................................................................................................................ 10
Conclusion ............................................................................................................................................. 10
If we cannot prevent people from accessing data, we need to keep track of how it is being used. This will then enable
us to investigate any suspicious activities to determine if a breach has occurred and the nature of the breach, which
will allow us to take appropriate action.
To this end, Microsoft have added the Auditing feature to SQL Server 2008 onwards
Utilising the above mentioned features for auditing purposes can be quite cumbersome as it involves a significant
amount of setup. The data accumulated by these methods are logged in different ways to a variety of locations
which made it hard to assimilate. Potential performance impact can also be associated with some of these actions
which makes it less than desirable
In SQL Server 2008, Auditing was an enterprise only feature. In SQL server 2012, server auditing has now been made
available to all editions, however database auditing remains for use by enterprise customers only
Extended Events
Extended events are a highly configurable architecture used to handle events occurring in SQL Server. Extended
events are built into the SQL Server code and as such it has a minimal impact on performance
Extended events makes use of packages to group objects together. One of these packages is the SecAudit package
which is used by SQL Audit. The events in this package are private and used internally by the SQL Audit feature. This
package is unfortunately not accessible so none of its objects are available externally
The Server Audit resides in the master database, and is used to define where the audit information will be stored,
file roll over policy, the queue delay and how SQL Server should react in case auditing is not possible
To be able to configure this option, the user who creates or modifies the Audit needs to have
SERVER SHUTDOWN permissions
In SQL Server 2012 auditing has become more robust by now allowing SQL Audit to recover should the target
become unavailable temporarily.
o File
The recommended approach is to store audit logs to a network location off of the server
The file name used is automatically generated by SQL Server. This is done to ensure that the file
names are always unique. The audit file name is made up of the following:
o Security log
One of the requirements of most compliancy regulations are that the audited data itself needs to be
secured. This can be achieved in a variety of ways, but typically access to the security log is more
restricted than access to the application log, and as such offers a good way to keep the logged
information secured
o Application log
Keep in mind that the default setting for the application log is to over-write events when it reaches
the maximum size. This could result in audit information being los
The file path to specify the path if the previous option selected to log to a file
The limit of the size and the number of audit files
The maximum number of audit files to be used without rollover
In SQL Server 2008 it was only possible to set the number of files to have in addition to the current file before
starting to rollover. An additional option has been added to SQL Server 2012 to allow DBAs to specify the
number of audit files without running the risk of auditing data being over-written when the roll over starts
Whether or not to reserve disk space specifically for the audit logs
A Server Audit is automatically assigned a uniquely identifying GUID. This GUID can be explicitly assigned. This GUID
is static and cannot be changed after the audit has been created
In SQL Server 2012, the audit now also allows for a filter to be specified. This is basically a WHERE clause for the
audit which is evaluated before an audit event is written to the target audit destination. This is applied to all audit
specifications linked to an audit. Any of the fields returned by the sys.fn_get_audit_file function except for
file_name and audit_file_offset may be used as a filter expression
An audit can be created either by using SQL Server Management Studio, by using transact SQL or SQL Server
Management Objects (SMO)
In SQL Server Management Studio an audit can be created under Audit node which resides under the Security node
in the Object Explorer
NB: All audits and audit specifications are created in a disabled state. Enabling an audit does not automatically enable
all audit specifications linked to it. Each audit specification needs to be enabled individually. An audit or audit
specification cannot be modified when it is enabled, it first needs to be disabled, then modified and re-enabled
Both the audit and the audit specification need to be enabled for an event to be logged
Permissions required:
To CREATE, ALTER or DROP an audit a user requires the ALTER ANY SERVER AUDIT permission. This is also included in
the CONTROL SERVER permission
In order to write to a file location the SQL Server service account will need to have write permissions on the network
share. In order to read the file all users which belong to the Audit Reader role and Audit Administrators role need to
have read permissions to that share as well
Additional security is required when writing to the Windows Security Log, this is addressed later in this paper
Audit Specifications
Audit specifications can have 3 categories of actions:
Some actions can be audited individually, such as auditing a select event on a table. This is referred to as an Audit
Actions
In most cases audit actions are grouped together resulting in Audit Action Groups. This facilitates audit specification
configuration since actions which form a logical unit are included in a single group saving you from having to specify
each one individually
The Server Audit Specification is found under the security node in SQL Server. There can be only one Server Audit
Specification per audit
The Name of the audit specification. This is optional, a default name will be assigned if you do not enter one
The Server Audit which defines the target the selected events should be logged to
The Audit Action Type. This is the events which should be audited
For the Server Specification all events are grouped into Audit Action Groups
SUCCESSFUL_LOGIN_GROUP
FAILED_LOGIN_GROUP
DBCC_GROUP
The full list of Server Level Audit Action Groups can be found here: Audit Actions and Audit Action Groups
When a Server Audit Specification is created via SSMS it is disabled by default. When creating it with T-SQL
there is an optional parameter to create it in an enabled state
Permissions required:
In order to create a Server Audit Specification a user needs to have permission to connect to the database and have
ALTER ANY SERVER AUDIT, the CONTROL SERVER permission allows the audit to be viewed by the user
The Database Audit Speciation is created under the Security node of the relevant database
The Database Audit Specification name. A default name will be assigned if none is provided
The Server Audit that the specification must be linked to
The Audit Action Type. There are both Audit Actions and Audit Action Groups which may be selected in this
field
INSERT and UPDATE is some of the Audit Actions which may be selected in this field
A complete list of Audit Actions and Audit Action Groups applicable to the Database Audit Specification can
be found here: Audit Actions and Audit Action Groups
The Object Name of the object to be audited when an Audit Action has been selected
The Schema of the selected object
The Principal name. In order to audit all users, use the keyword public in this field
Even though SQL Server will allow you to specify an audit action on server scope objects , such as system views, the
objects will not be audited but no error will be raised either
If you want to audit server scope objects, you need to create a database audit specification in the master database
Permissions required:
In order to create a database audit specification a user needs to have permission to connect to the database and
have ALTER ANY DATABASE AUDIT SPECIFICATION or the ALTER or CONTROL permission for the database to which
they would like to add the audit
A user defined audit event is created by using the sp_audit_write procedure. This procedure accepts 3 parameters:
In order for a user defined event to be audited, the USER_DEFINED_AUDIT_GROUP needs to be selected for audit in
either the database or server audit specification
If this has not been selected as an audit event, all events generated by the sp_audit_write procedure will be ignored
File pattern
This is a nvarchar(260).The path or the path and filename of the file to read should be provided. To read all
the files in a folder, specify the path to the folder using the asterisk (*) as wildcard. If an invalid file is
specified the MSG_INVALID_AUDIT_FILE error message will be displayed
Example:
SELECT * FROM fn_get_audit_file('D:\Audits\*',default,default)
The file can contain any of the 26 available elements. A complete list of the available elements can be found here:
SQL Server Audit Records
Audit information written to the Windows Security Log or the Application Log can we read using event viewer. This
information can also be read through the SQL Server Management studio by expanding the security node, then
expanding the Audit node, right click on an Audit and select the option View Audit Logs
There are two ways to increase the security of the audit logs:
1. Write the audit logs to a file server share on a different server to which the sysadmin does not even have
permission. Only allow permission to the auditor
2. Write to the Windows Security log is also a good alternative. If you want to write to the Windows Security
log you will need to do the following:
o Add the SQL Server Service account to the Generate Security Audits policy in your Edit Group Policy
Editor
o Change the Audit Object Access policy to include both Success and Failure
Keep in mind that when writing to the Windows logs, the Windows audit policy could potentially cause audit
data to be lost. The windows logs usually roll over and as such can start over-writing older events which could
cause some SQL Audit data to be lost
In Windows 8 the plugin is called gpedit.msc. In order to access it, you need to type gpedit.msc in the search
box. Remember to include the .msc extension or you might not find it
Unfortunately if you do only have the basic edition of Windows 8, you may not be able to access this
application
SQL Server will write the MSG_AUDIT_SHUTDOWN_BYPASSED message to the error log if auditing was bypassed in
this way
Best Practices
Write audit logs to a centralized location
To facilitate processing of the audited data, load the logs into a database
Use a file as a target for optimal performance
Use targeted auditing to minimize the collected data and better performance
When writing to the Windows logs, ensure that the roll-over policy of the Windows Logs, coincides with that
of your audit strategy
Conclusion
SQL Server Auditing is a powerful feature, but should not be used without careful planning and consideration. In
order to use Auditing successfully you need to have a very clear idea of what you hope to achieve. Which actions
need to be audited? Who needs access to this information? How will it be accessed? A large part of successful
auditing depends on how the audit data is stored, processed and monitored
In addition to planning, more work may be required to create reports which can be used for auditors to make sense
of this information