Database teams trying to comply with regulations such as the Health Insurance Portability and Accountability Act of 1996 (HIPAA) or the Sarbanes-Oxley Act of 2002 (SOX) commonly use auditing as part of their compliance strategies to help track potential threats to stored data. For example, teams running SQL Server might turn to SQL Server Audit to log actions at both the server and database levels. SQL Server Audit is built into the database engine and, starting with SQL Server 2016, is available in all SQL Server editions.
If you’re a DBA tasked with implementing SQL Server Audit, you’ll find that setting up the auditing components is a relatively straightforward process. The more significant challenges often lie in trying to determine what user actions to audit, how to handle the potentially large amounts of audit data, and what tools to use to monitor and review that data.
Although these are all important considerations, this article is concerned primarily with the last one―monitoring and reviewing the audit data. SQL Server makes it easy to collect the data but provides no mechanisms for working with that data in a meaningful way, other than to review it manually.
One way to address this issue is to bring in a third-party solution such as EventTracker to consolidate, manage, and monitor the audit data, but this comes with additional licensing and implementation considerations.
Another approach is to use Power BI to create reports that provide quick visual insights into the data. Although Power BI is not designed for auditing and alerting to the same degree as more robust log management tools, it provides a relatively simple method for tracking user behavior. Best of all, the basic Power BI service is free, as is Power BI Desktop, a downloadable tool for transforming and visualizing different types of data.
In this article, I demonstrate how you can use Power BI to work with SQL Server Audit data, walking you through the steps necessary to set up a test environment, generate sample audit data, pull that data into Power BI Desktop, and create a report that contains tables and visualizations. Keep in mind, however, that SQL Server Audit and Power BI Desktop are both powerful solutions that support far more capabilities than can be covered in a single article. The information here should at least provide you with a conceptual overview of how the tools can be used together and what it takes to get started using Power BI Desktop to review audit data.
Setting Up a Test EnvironmentTo prepare your environment for the examples in this article, you should first create the ImportSales test database, which contains one schema, Sales , and one table, Sales.Customers . You can then populate the table with data from the Sales.Customers table in the WideWorldImporters database. For this article, all audited actions are limited to Customers table in the ImportSales database.
To create the ImportSales database, run the following T-SQL code:
USE master; GO DROP DATABASE IF EXISTS ImportSales; GO CREATE DATABASE ImportSales; GO USE ImportSales; GO CREATE SCHEMA Sales; GO CREATE TABLE Sales.Customers( CustID INT IDENTITY PRIMARY KEY, Customer NVARCHAR(100) NOT NULL, Contact NVARCHAR(50) NOT NULL, Email NVARCHAR(256) NULL, Phone NVARCHAR(20) NULL, Category NVARCHAR(50) NOT NULL); GO INSERT INTO Sales.Customers(Customer, Contact, Email, Phone, Category) SELECT c.CustomerName, p.FullName, p.EmailAddress, p.PhoneNumber, cc.CustomerCategoryName FROM WideWorldImporters.Sales.Customers c INNER JOIN WideWorldImporters.Application.People p ON c.PrimaryContactPersonID = p.PersonID INNER JOIN WideWorldImporters.Sales.CustomerCategories cc ON c.CustomerCategoryID = cc.CustomerCategoryID; GOIf you don’t have the WideWorldImporters database installed, you can populate the Customers table with your own data. If you want to use a different table and database for these examples, skip the T-SQL statements above and use a database and table that best suit your needs (and are not in a production environment, of course). Just be sure to replace any references to the ImportSales database or Customers table in the subsequent examples.
The next step is to create an audit object at the SQL Server instance level and a database audit specification at the ImportSales database level. The audit object serves as a container for organizing the server and database audit settings and for delivering the final audit logs. For this article, you’ll be saving the audit data to a local folder, but know that SQL Server Audit also lets you save the data to the windows Application log or Security log.
A database audit specification is created at the database level and is associated with an audit object, which means that the audit object needs to exist before you can create the database audit specification. The specification determines what actions should be audited at the database level. You can also create a server audit specification for auditing actions at the server level, but for this article, you need only the database audit specification.
To create both the audit object and database audit specification, run the following T-SQL code:
USE master; GO CREATE SERVER AUDIT ImportSalesAudit TO FILE (FILEPATH = 'C:\DataFiles\audit\'); GO ALTER SERVER AUDIT ImportSalesAudit WITH (STATE = ON); GO USE ImportSales; GO CREATE DATABASE AU