Log in SQL Server Express for audit?

The results of an audit are sent to a target, which can be a file, the Windows Security event log, or the Windows Application event log. Logs must be reviewed and archived periodically to make sure that the target has sufficient space to write additional records. Writing to the Windows Security log requires the SQL Server service account to be added to the Generate security audits policy.

By default, the Local System, Local Service, and Network Service are part of this policy.  This setting can be configured by using the security policy snap-in (secpol. Additionally, the Audit object access security policy must be enabled for both Success and Failure.

This setting can be configured by using the security policy snap-in (secpol. In Windows Vista or Windows Server 2008, you can set the more granular application generated policy from the command line by using the audit policy program (AuditPol. For more information about the steps to enable writing to the Windows Security log, see Write SQL Server Audit Events to the Security Log.

For more information about the Auditpol. Exe program, see Knowledge Base article 921469, How to use Group Policy to configure detailed security auditing.  The Windows event logs are global to the Windows operating system.

For more information about the Windows event logs, see Event Viewer Overview. Â If you need more precise permissions on the audit, use the binary file target. The SQL Server Service Account must have both Read and Write permission.

Audit Administrators typically require Read and Write permission. This assumes that the Audit Administrators are Windows accounts for administration of audit files, such as: copying them to different shares, backing them up, and so on. Audit Readers that are authorized to read audit files must have Read permission.

Even when the Database Engine is writing to a file, other Windows users can read the audit file if they have permission. The Database Engine does not take an exclusive lock that prevents read operations. Because the Database Engine can access the file, SQL Server logins that have CONTROL SERVER permission can use the Database Engine to access the audit files.

To record any user that is reading the audit file, define an audit on master.sys. This records the logins with CONTROL SERVER permission that have accessed the audit file through SQL Server. We recommend that you generate audit reports from a separate instance of SQL Server, such as an instance of SQL Server Express, to which only Audit Administrators or Audit Readers have access.

By using a separate instance of the Database Engine for reporting, you can help prevent unauthorized users from obtaining access to the audit record. You can offer additional protection against unauthorized access by encrypting the folder in which the audit file is stored by using Windows BitLocker Drive Encryption or Windows Encrypting File System. For more information about the audit records that are written to the target, see SQL Server Audit Records.