ManagingSecurity•Chapter4 147 EXERCISE 4.7 se t UP a Da t a b a s e aU D i t sP e C i f i C a t i o N 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. 148 Chapter4•ManagingSecurity 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. ManagingSecurity•Chapter4 149 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 cat- alog view, sys.triggers, or the server-level view, sys.server_triggers. The syntax for creating a DDL trigger is: 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 ; Te s T Da y Ti p Make sure that you are familiar with the difference between database-level and server-level DDL triggers. 150 Chapter4•ManagingSecurity EXERCISE 4.8 iM P l e M e N t i N g a Da t a b a s e -le v e l DDL tr i g g e r You have an application vendor that supports their application and the supporting SQL Server database remotely. When support issues or maintenance requests arise, this vendor can log in securely and make database schema changes. Unfortunately, the vendor is not aware of any of the in-house custom development so you want to make sure that you are aware of the changes that they are making so that you can head off any problems arising from table changes. Write a DDL trigger that will keep track of any table changes and the User who has made the change. You will want to save this table audit information to an audit table. The SQL Server Configuration Manager In SQL Server 2005, The Surface Area Configuration Tool was used to manage SQL Server features such as Database mail and xp_cmdshell. In SQL Server 2008, the Surface Area Configuration Tool no longer exists; it has been replaced with the SQL Server Configuration Manager. Available as a Facet at the server instance level, Database mail, CLR integration, and xp_cmdshell, as well as a few other features, can be enabled or disabled through this new interface. Configuring & Implementing… Secure by Default Many SQL Server 2008 features are installed in a disabled state requiring that they be manually enabled when needed. Following the “secure by default” philosophy of SQL Server, many features are installed in a disabled state so that potential attackers cannot exploit them. In order to use functions such as the Service Broker, database mail, xp_cmdshell, and CLR they have to be enabled by using the Surface Area Configuration Tool. This tool can ManagingSecurity•Chapter4 151 be accessed by Right Clicking on the Server and selecting Facets. Then by selecting Surface Area Configuration from the drop-down menu, you will see a screen that looks like Figure 4.11. Te s T Da y Ti p Be aware of what features are automatically set up to run when SQL Server 2008 is installed and which functions need to be enabled, as well as their purpose. Keep in mind that you only want to enable what you know you need. Enabling unused functions will leave your server vulnerable to potential attack. Using sp_configure will display configuration settings for the current server. Changes can also be made using sp_configure. Configuration settings can be viewed by executing the following: Figure 4.11 Surface Area Configuration Facet . Server MSSQL10.MSSQLSERVER MSSQLDATA' ); 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. 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. to manage SQL Server features such as Database mail and xp_cmdshell. In SQL Server 2008, the Surface Area Configuration Tool no longer exists; it has been replaced with the SQL Server Configuration