Having an SQL auditing system in place seems like a straightforward way to harden the security of your SQL data. This way you can at least track the activities and changes done to your SQL Server instance and databases, and depending on the specific auditing system you are using, you might even prevent or roll back malicious or inadvertent changes. However, it’s important to keep in mind that just having a SQL auditing system up and running is not enough. Poorly planned or supervised auditing solutions may lull you into a false sense of security, and actually result in you discovering an information leak or data loss much later than if you had no auditing set up in the first place

ApexSQL Audit has been designed by recognizing the principle that it is impossible to prevent tampering by trusted parties with software-only solutions. Even the worst-case scenario of an attacker obtaining trusted privileges is thus simply reduced to treating all tampering the same, no matter where it comes from. So we’ve applied this principle in all areas that affect auditing, from capturing of audited data all the way to its storage. This has been critical in ensuring not only easy compliance, but actually making tampering obvious

As we have seen in the 1st part of this article, in order to solve the overarching problem of easy compliance, we had to solve many different problems main of which were:

1. Capturing of what-was-executed and of other auditing events of interest
2. Fault tolerant auditing
3. Centralized storage of audited data and integrity checks
4. Centralized reporting
5. Prevention from tampering of audited data, or exposure when prevention is not possible (e.g. data tampered by trusted user accounts, hacked or otherwise)

In this 2nd part of this article, we will go deeper into solutions that we applied to each of these problems