Auditing Architectures - Implementing Database Security and Auditing - page 380

Figure 13.3

Auditing by
inspecting
supporting
database files.

13.4 Archive auditing information

Depending on which categories of auditing information you choose to col-
lect, you will probably be collecting huge amounts of data. This is true for
all three auditing mechanisms described in the previous section, because
underlying everything is the fact that your databases are usually supporting
massive numbers of SQL calls, all of which may need to be audited.
Your auditing solution is probably good at storing this information and
making it readily available for you to use for reports, alerts, and audits.
However, in order for auditing to be sustainable, you also have to verify that
your auditing solution addresses archive and restore capabilities.
Don't underestimate this issue. You must fully understand where audit
data is stored and what the volumes are in extreme cases. The consequence
of mistakes here can be as far-reaching as the shutdown of your database.
For example, if you use SQL Server's C2 auditing feature, audit files are
saved on disk. If you do not move these files off the server, they will fill up
the disk fairly quickly. When this happens, SQL Server will simply stop
providing any database services.
Generally, it is far better not to store auditing files on your database
server. The database server and the disk have plenty to do without asking
them to also write all of this auditing information. Regardless of where the
auditing information is stored, you should have a clear understanding of
auditing data volumes and what your archiving schedules should look like.