SQL Server Audit has been gradually brought to different editions of SQL Server as the years pass. When this true, native auditing feature was introduced in SQL Server 2008, it was only available in Enterprise and Datacenter editions. SQL Server 2012 made server-level auditing partially available to all editions, leaving only the more granular database-level auditing still exclusive to the Enterprise edition. Staring SQL Server 2016 SP1, all auditing features, that is both server-level and database-level auditing are available to all editions.

SQL Server Audit is based on actions and action groups. The audit can contain server-level audit specification and database-level audit specifications:

• Server-level auditing consists of server-level audit action groups, which include server operations, such as security operations involving logins, roles and permissions, logon and logoff operations, database backup and restore,manipulation of certain database-, server-, and schema objects.
• Database-level auditing is auditing at the database scope, and it is set on each database individually. Microsoft calls it "fine grained auditing". Database-level auditing utilizes database-level audit action groups, and database-level audit actions.
  • The database-level audit action groups cover some similar areas as the server-level audit groups, if applicable, but at the database level.
  • Additionally to auditing action groups,database-level auditing also enables auditing certain individual actions, such as SELECT, INSERT, UPDATE, DELETE, EXECUTE, RECEIVE, and REFERENCES. These database-level audit actions can be restricted to a specific database, an object (such as table, view, stored procedure), or a schema.

Here is a summary of the SQL Server Audit support in the different editions:

So where does LOGbinder for SQL Server fit into the SQL audit equation? LOGbinder for SQL Server can be installed on any Windows server that has access to a SQL Server 2008 or later regardless of the edition, including Express edition. It does not need to be installed on the production server. The requirement is that the SQL Server that is being audited is:

1. Set to produce audit events.
2. Set to output these audit events to a location accessible to LOGbinder for SQL Server and the SQL Server that is set to process the audit logs.

The audit file can then be accessed and processed by LOGbinder for SQL Server and made available for your SIEM / log management solution.

To summarize, audit logs could move the following way: