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

ApexSQL has a long history in SQL Server auditing space with two tools that either prepare databases for auditing, or actually perform auditing. ApexSQL Trigger automates creation of triggers (among other things) that track data modifications on selected tables, while ApexSQL Log reads the database transaction log, extracting data modifications from it. Both of these tools show who-did-what, achieving it in different ways, with their own relative strengths and weaknesses. But these tools also lack the means to satisfy stringent regulations on data access (including who-saw-what), and out-of-the-box prevention from tampering, and that is why we built ApexSQL Audit: to make compliance with auditing regulations easy