SQL Server 2008 : Managing Security - Auditing

Available in SQL Server 2008 Enterprise, automatic auditing can be set up by using SQL Server Audit. The Audit object can capture activity in the database server and save it to a log. Audit information can be stored in a File, Windows Application Log, or Windows Security Log.

In order to create an Audit object you need to first use the CREATE SERVER AUDIT statement. The following is an example of creating a server audit that is saved to a file:

CREATE SERVER AUDIT HIPAA_File_Audit
      TO FILE (FILEPATH='\\SQLPROD_1\Audit\');

The resulting filename generated takes the form of: “AuditName_AuditGUID_nn_TS.sqlaudit.”

After you have created the Audit object, events can be added to the server audit that you created by creating a server audit specification. The syntax for that looks like the following:

CREATE SERVER AUDIT SPECIFICATION Failed_Login_Spec
FOR SERVER AUDIT HIPAA_File_Audit
      ADD (FAILED_LOGIN_GROUP);

Database Audits can also be created to track and CREATE, ALTER, or DROP actions in the database or any INSERT, UPDATE, or DELETE activities performed on database objects.

An example of creating a database audit specification looks like the following:

CREATE DATABASE AUDIT SPECIFICATION Sales_Audit_Spec
FOR SERVER AUDIT HIPAA_AppLog_Audit

    ADD (DATABASE_OBJECT_CHANGE_GROUP),
    ADD(INSERT, UPDATE, DELETE
      ON Schema:: Sales
      BY SalesUser, SalesAdmin);

Exam Warning

Be sure to understand the difference between server-level and database-level audits and your options for storing the audit activity.

Set Up a Database Audit Specification

You need to set up a database audit specification on the HumanResources. Employee table to monitor any SELECT or DELETE statements. Start setting up your server audit, enabling the server audit, and then creating the database audit specification. Your code should resemble the following: USE MASTER GO -- You are creating the server audit with this statement CREATE SERVER AUDIT Employee_Security_Audit TO FILE (FILEPATH = 'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\ MSSQL\DATA'); GO -- You need to then enable the server audit ALTER SERVER AUDIT Employee_Security_Audit WITH (STATE = ON) ; GO -- Now you need to set up the database audit by switching to the target database. USE AdventureWorks GO -- Now create the database audit specification for the Employee table. CREATE DATABASE AUDIT SPECIFICATION Employee_Table FOR SERVER AUDIT Employee_Security_Audit ADD (SELECT, DELETE ON HumanResources.Employee BY dbo ) WITH (STATE = ON) GO You have now completed setting up database auditing for the HumanResources.Employee table in the AdventureWorks2008 database.

Change Data Capture (CDC)

New in SQL Server 2008 and only available in the Developer, Enterprise, and Evaluation additions, Change data capture (CDC) can be implemented to capture INSERT, UPDATE, and DELETE activity applied to SQL Server tables from the SQL Server transaction log. CDC captures column information along with the metadata, such as the action being taken, that is required to apply the changes to a target environment for rows affected. The data capture information is stored in change tables that resemble the column structure of the tracked source tables.

New & Noteworthy...: Change Data Capture (CDC) CDC functionality is new in SQL Server 2008, providing the capability to capture INSERT, UPDATE, and DELETE activity from the SQL Server transaction logs.

Before CDC can be used it must be enabled; the following SQL code shows how to do this.

use testDatabase
--Activate CDC
EXEC sys.sp_cdc_enable_db_change_data_capture
--IsDatabaseEnabled?
SELECT is_cdc_enabled FROM sys.databases WHERE name = 'testDatabase'
--Enable CDC on table
EXEC sys.sp_cdc_enable_table_change_data_capture
@source_schema = 'dbo', @source_name = 'Table_1', @role_name = 'cdc_test'
--IsTableEnabled?
SELECT is_tracked_by_cdc FROM sys.tables WHERE name = 'table_1'

Using DDL Triggers

DDL triggers are a great way to keep track of any structural changes to the database schema. DDL triggers fire after DDL language events and are fully transactional.

Changes can roll back and, besides running Transact-SQL code, Common Language Runtime (CLR) code can be executed as well.

Providing an audit of schema changes can be very helpful when you want to make sure that column data types tied to data loads are not inadvertently changed or production tables are not dropped, resulting in data load or application failures.

DDL triggers can be set up at the database-level and at the server-level. An example of a database-level trigger would be a trigger that tracks or prevents DDL changes to tables. A server-level DDL trigger could track such changes as Logins being added to SQL Server.

Once created, you can see DDL and DML triggers using the database-level catalog view, sys.triggers, or the server-level view, sys.server_triggers.

The syntax for creating a DDL trigger is:

Code View: Scroll / Show All

CREATE TRIGGER trigger_name
ON { ALL SERVER | DATABASE }
[ WITH <ddl trigger_option> [,... n ] ]
{ FOR | AFTER } { event_type | event_group } [,...n ]
AS { sql_statement [ ; ] [,...n ] | EXTERNAL NAME < method specifier > [ ; ] }
<ddl_trigger_option> ::=
    [ ENCRYPTION ]
    [ EXECUTE AS Clause ]

					    

Here is an example of a database-level DDL that prevents a table from being altered or dropped:

CREATE TRIGGER DONOTCHANGEIT
ON DATABASE
FOR DROP_TABLE, ALTER_TABLE
AS
    PRINT 'You must contact a DBA before dropping or altering tables!'
ROLLBACK
;