Enterprise Auditing with SQL Server Audit Colleen Morrow, SQL Server Consultant, UpSearch
About me Colleen Morrow Principal consultant at UpSearch MCSE: Data Platform 10+ years of SQL Server experience http://colleenmorrow.com @ClevelandDBA
Agenda Why audit? Introduction to SQL Server Audit Defining audit requirements Implementing SQL Server Audit Handling audit data
Why audit? Once upon a time… a cautionary tale
Why audit? Your company employs an outside firm to perform security audits Required by law to perform auditing Supplement a change management system Answer the question, “what changed?” Determine who’s accessing that sensitive data Determine what a particular login is being used for
SQL Audit: Introduction 2008+ Enterprise Edition* Built on Extended Events framework Very lightweight Events recorded at permission-check time Executes asynchronously or synchronously Enjoys long walks on the beach Built on the Extended Events framework minimal overhead, less than SQL Trace Events are recorded at the permission-check level Record when an event was even attempted Capture indirect activities, i.e. a stored procedure or view referencing a table being audited Executes asynchronously or synchronously
SQL Audit: Terminology Server Audit Server audit specification Database audit specification Server Audit object - defines where the audit information goes. Audit Specification object - describes what gets audited. Database Audit Specification - audits events at the database level. For example, selecting from a certain table (or all tables), altering a stored procedure, etc. Server Audit Specification - captures events at the instance level, such as logging in, adding principals to server roles, etc. An audit specification can be associated with only one audit object. A server audit object can have one or more audit specifications assigned to it.
What actions can you audit? Objects object is created, altered or dropped object is accessed (e.g. DML, EXECUTE) ownership changes permission changes server objects, database objects, schema objects
What actions can you audit? (cont.) Security principals are created, altered, or dropped database/server role is added or removed principal is added to or removed from a role. successful/failed logins password changes a password is changed for an application role
What actions can you audit? (cont.) Databases a database is created, altered, or dropped. ownership changes permission changes Backups backup/restore operations
What actions can you audit? (cont.) Audits/Traces any audit is created, modified or deleted. any audit specification is created, modified, or deleted. any change to an audit is audited in that audit. statements that check for the ALTER TRACE permission.
What actions can you audit? (cont.) Server state the SQL Server service state is modified DBCC a principal issues any DBCC command User Defined Events
What can’t you audit? Temp tables #temp and ##temp tables not audited Internal events E.g. locking, transaction log growth from large transactions
Defining audit requirements Where? How many servers? What version/editions? What? What events? What data for the event? How critical is it? Can you afford to miss any events? How will the data be viewed? Ad hoc? Formal report? How long should it be retained?
Example #1: Security in Azure To: Dan Wilson From: Stephanie Conroy Dan, Now that we’ve deployed the ordering system infrastructure to Azure virtual machines, I’m concerned about security. I want to make sure we’ve locked things down as much as possible. Is there any way to know who is or is trying to log into the database? Thanks much, Stephanie Conroy Network Manager AdventureWorks, Inc.
Audit requirements Where? Single instance on Azure VM What? Security Where? Single instance on Azure VM What? Logins, Logouts, Failed Logins; Login name, Event time, session duration, client hostname/IP How critical? Some event loss Viewed? Ad hoc report Retention? 1 week
Create Server Audit Read audit file Demo Create Server Audit Read audit file
Reading audit data fn_get_audit_file ( file_pattern, { default | initial_file_name | NULL }, { default | audit_record_offset | NULL } ) file_pattern – the path and file name of the audit file(s) to be read; file name can be or include a wildcard. initial_file_name – first file to process; all subsequent files will also be processed. audit_record_offset – Used in conjunction with the initial file name to tell SQL Server where in that initial file to start. file_pattern – the path and file name of the audit file(s) to be read; file name can be or include a wildcard. initial_file_name – first file to process; all subsequent files will also be processed. audit_record_offset – Used in conjunction with the initial file name to tell SQL Server where in that initial file to start.
Using fn_get_audit_file() Select * from fn_get_audit_file (‘c:\MyAudits\Security*’ , NULL , NULL ) Select * from fn_get_audit_file (‘c:\MyAudits\Security*’ , ‘File 2’ , 7200 ) Select * from fn_get_audit_file (‘c:\MyAudits\Security*’ , ‘File 1’ , 9650 ) File 1 File 2 File 3 7200 9650
Example #2: Troubleshooting To: Dan Wilson From: Karen Berg Hey Dan, You know that audit you configured for to help us troubleshoot erroneous updates to ProductInventory? It’s a lot of data to sift through and really we’re only interested in updates to the Bin column. Any way you can refine the audit? Thanks, Karen Berg Application Specialist AdventureWorks, Inc.
Audit requirements Where? Single database What? Troubleshooting Where? Single database What? Updates to specific column Login/username, event time, statement or procedure How critical? No event loss Viewed? Ad hoc viewing Retention? No requirement
User-defined events Synchronous auditing Demo User-defined events Synchronous auditing
Synchronous-icity Permissions check / Audit check Expand Event details Send to Audit Xevent session Record event QUEUE_DELAY = 1000 Synchronous Async
Performance Impact NOTE: Graphs and chart colours provided are examples. You may add your own graphs and select your own colours, if you see this necessary.
Example #3: Change Management To: All IT Employees From: Jean Trenary As a result of AdventureWorks, Inc. becoming a publicly traded company, IT systems will be undergoing a yearly audit, to be conducted by an external firm. Part of this auditing process is a reconciliation between Production-level changes and change management tickets. To help facilitate the yearly audit, we are now requesting monthly reports from each Production environment listing all object changes during the previous month and the corresponding ticket number. Thank you, Jean Trenary Information Services Manager AdventureWorks, Inc.
Audit requirements Where? All production databases What? Change Management Where? All production databases What? Database object changes (DDL) Server, database, schema, object, login, event time, statement How critical? No event loss Viewed? Monthly/Annual report Retention? 18 months
Using PowerShell Managing audit data Demo Using PowerShell Managing audit data
Permissions Creating audits or server audit specifications ALTER ANY SERVER AUDIT or the CONTROL SERVER permission Creating database audit specification ALTER ANY DATABASE AUDIT permission or the ALTER or CONTROL permission on the database Viewing audit logs CONTROL SERVER permission
Recap Why audit? Introduction to SQL Server Audit Defining audit requirements Implementing SQL Server Audit Handling audit data
Questions?
Thank You