Auditing

SQL Server 2005 provides a highly sophisticated auditing mechanism that allows you to perform auditing on two levels depending on the security plan requirements. I refer to the two levels as auditing according to data center security requirements and according to C2 security requirements. Now, your data center may require less of the C2 specification, and you should define your needs according to change control and data center security needs.

C2, however, applies only to stand-alone computers, so NSA certification will really only mean something to certain parties when SQL Server 2005 and Windows Server 2003 rate for the networked computer specifications (Red Book and Blue Book). Microsoft has gone above and beyond C2 with Windows Server 2003.

For what it’s worth, C2 security is more than a just a rating because it tests things like the protection of objects and auditing. The audit trail facilities of SQL Server are highly advanced, and you can really push the event-logging envelope into outer space. I would almost go as far as saying that you can pretty much trace who passes wind in SQL Server 2005. Your auditing plans thus require careful consideration.

Auditing, like encryption, impacts performance. Every event is auditable, which means that the overhead to record the event accumulates and impacts server or DBMS performance. If you need to accommodate stringent auditing requirements, you might need to consider a second server to do nothing but audit all DBMS activity, or throw gobs of RAM and another processor or two at your base server.

You can audit using the SQL Profiler as discussed in Chapter 18. To configure login auditing right-click the server in SSMS, Object Explorer and select Properties. Go to the Security Page. Here you can choose both Login auditing and C2 audit tracing.