Posted by: Arian Eigen Heald
Admins and Auditors, Database, DataManagement, Tools for Auditing and Security
(Sorry, I apologize for using an acronym, but I couldn’t resist.)
Whenever the subject comes up of logging activity in a database, immediately the complaints of “Too much overhead!” can be heard. Everybody thinks it’s a good idea in theory, but from a practical standpoint, it adds a lot of burdens to the database.
From a security standpoint, it’s really difficult to make sure that DBAs or Administrators are accurately logged AND denied access to the logs. On the database server itself, it’s next to impossible.
This isn’t really a new idea, but it has recently gained a lot of adherents: database monitoring. Quest Software has had some good products around for monitoring performance, but recently the focus (because of compliance, big surprise) has turned to access controls, logging, and monitoring activity.
For example, someone might have noticed a little sooner at Countrywide that someone was accessing a lot of customer data if a Database Activity Monitoring device had been installed.
There are two versions of this type of device. First, is the Network-based DAM, which can monitor all traffic going to and from the database server, and puts no load on the server itself. This is a great idea, unless, of course, your traffic is encrypted. Another issue is that this type of monitoring will miss activity that is local to the server itself.
Second is the host-based DAM, which is really the most effective of the two, because it can see everything you want to see via an agent installed on the server that reports back to the monitoring device elsewhere on the network. The overhead of an agent will not be as high as trying to enable auditing within the database itself, and, as much as I am not fond of agent software, in this case I would make an exception, after careful testing.
The drawback to this system is that the agent could be disabled, but the DAM should immediately alert personnel to that fact. If you are able to size your server appropriately, an agent’s overhead could be minimized. I’d love to hear from anyone using this type of configuration, and how they like it.