tduong's blog

The Problem
===========
The longer you've been working as a DBA, the more you've encountered things like these:

The time on a table changed and you don't remember doing it. You poke around but can't figure out who changed it.

There's someone you don't trust that you have to give access to. They are the kind of person that will look at things they are not supposed to, but you have to give them access.

There's someone who always messes things up when they get access. You know they'll do it again and you'll have to undo the damage. Would be nice to know what they are doing.

There's a contractor or a new employee that need access. You don't know them yet and not sure how reliable they are. It would be nice to be able to keep an eye on them.

Too many people have too much access and you're losing control. You try to figure out how to reduce the access they have or revoke some privileges, but this is pretty much what everyone claims they need to do their jobs.

You've been through an audit and the auditor wanted to know all sorts of things about the activity. Questions you just don't have the information needed to answer.

You probably spent many days chasing down the answers to these questions or try to find ways to collect it. The security in the database is set properly. The problem is that you need to know what people are doing with the access they have. This knowledge will give you more control.

The Rule engine is one of the critical pieces in an auditing solution. It sits between the data collection and the reporting output. It is the heart of the functionality that will take the job of reviewing the reports from impossible to manageable to easy. The reason it is so important is the vast amount of SQLs that go through a database engine. A good rule engine will reduce the amount of SQLs in the report and increase their relevance.

Change control is an important part of being compliant. You will not pass an audit without having a change control process in place. One of the requirements you might face is to monitor all changes in the database and make sure they all came from the change control process.

There is a common misconception about the value of application user identification. The reason for the misconception is the marketing of this feature by some companies, but we'll get into all that later. First lets examine the idea.

Most applications have a single database user that they use to access the data. To enforce security, these applications maintain an internal list of users and roles that they enforce. In other words – instead of using the database security features, that functionality is performed by the application. The result is that when you look at the database activity you see everything coming from a single user. An obvious requirement is to map the database activity to the application user as it is seen by the application.

Most companies have more than one database vendor. Oracle, SQL Server, DB2, MySQL and Sybase are all common depending on the company, and some use less common databases such as TeraData. There are, however, some important questions to ask before you dive into your cross platform heterogeneous requirements:

* Which databases do you actually need to audit? Is all your SOX, PCI, HIPAA or other sensitive data scattered across all these databases, or is your SQL Server just used for small home-grown apps that do not have any auditing requirements?

* Do you have the same DBA or team managing all these databases, or are they different teams that will end up managing auditing solutions independently? In the later case you are better off choosing the best solution for each database rather than mandating a single solution no one is too happy with.