Third-Party Audit-Logging Options
Third-party transaction-log analyzers and gateways can audit logs and process and filter SQL Server traffic. They can analyze backup logs and use listener agents to collect and process SQL Server traffic to filter out the good stuff.
April 28, 2008
![Third-Party Audit-Logging Options Third-Party Audit-Logging Options](https://eu-images.contentstack.com/v3/assets/blt07f68461ccd75245/blt6f5876fbd5ff4cec/6617fea8f253a7139dcb362a/active-directory-object-names595x335_0_2.jpg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
Third-party transaction-log analyzers and gateways can audit logs and process and filter SQL Server traffic. Here’s a quick glimpse at the functionality such products provide:
Third-party transaction-log analyzers. SQL Server 2005 keeps relational tables and other objects in .mdf- and .ndf-file data pages and tracks data-page changes in transaction logs (in .ldf files). These transaction-log files are in a proprietary binary format. By analyzing a backed-up transaction log, the third-party tools can provide auditing capabilities without slowing production-server performance.
Third-party gateways. A gateway uses a listener agent on the SQL Server network port to collect and process all SQL Server traffic and filter out the interesting stuff, such as failed logins, schema changes, and dml statements run from query tools rather than production applications. This can be an effective vendor-agnostic database solution. One problem with this approach is that it might not perform optimally with encrypted data. Any database connections passing privileged information should be encrypted on the wire, but encryption makes the gateway’s job very difficult since the encrypted traffic appears to be gibberish. The gateway would need to unencrypt the traffic to make sense of it. Another potential issue is multi-instance server port tracking. A gateway must work with the SQL Browser service, which manages connections and ports.
About the Author
You May Also Like