December 4, 2008 at 8:02 pm
Comments posted to this topic are about the item The Need for Auditing
December 5, 2008 at 7:31 am
I use trace logs and trigger-based auditing. (I even wrote articles about it for this site last summer.) I've found those to be quite adequate to my needs.
I have a proc that takes a database and table name, a "main search field" (usually the PK) and a couple of other input parameters, and it does all the work for me of creating a a log table (in my DBALog database) for the database, creating the logging trigger (based on a sparse XML structure that only stores columns that have changed), and creating search and undo procs for any logged transaction, customized to the columns in the table being logged. Takes about 2 seconds to add logging to any table and is pretty much fire-and-forget. Of course, sometimes I'll modify the trigger so that it deviates from the default, but that's uncommon.
I also have the default trace running, and two custom traces running on the databases that need it the most. All are set to restart if the SQL Service restarts (from a reboot or whatever). It generally works out to keeping about 3-4 days of data.
And I have a DDL trigger in every production database and in "model" that logs schema/code changes, including who made the change, when, and the script used. I've had to make a few filters for this, because maintenance plan index rebuilds otherwise end up junking up the log, but beyond that it's been quite handy.
Those are what I use for auditing. Some of it may be overkill, but performance hasn't been hurt to an extent that any user can tell the difference, and it has come in quite handy quite a few times.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
December 8, 2008 at 4:44 am
Ahhh auditing...
I've used mostly trigger based auditing through the years on stuff I've designed, although a few clients did do auditing in the data layer, which worked really well for them.
Based on the application architecture and auditing requriements it was a good approach for them.
DDL triggers are great for capturing DDL changes. I've used them in environment where security has been less than optimal due to company policies, but thats another discussion.
December 8, 2008 at 9:09 am
Not many people auditing, or maybe caring, ...
or maybe awake :hehe:
December 8, 2008 at 11:46 am
^^ I don't know about everyone else, but I never got the newsletter this morning. Had to go to the site to get my fix. As for auditing, where I am we use trigger based auditing. Nothing too important being looked for, but if someone changes something, knowing the who, what, and when will lead them to the why.
December 8, 2008 at 9:34 pm
Yep, lack of replies was my fault. No newsletter. 🙁
September 16, 2014 at 1:47 am
I recently found, via Google searches, and implemented successfully, a trigger based solution called AutoAudit (http://autoaudit.codeplex.com/). This is an open source project, which auto generates triggers on your base tables. On DML operations the triggers fire and populate a few consolidated tables that store the old and new records and details of the change. Being open source it was free, and it has been really good in so much as we've never had a problem with it and it passed all our tests. Because it was open source we tested it exhaustively prior to implementation.
The DB where we've installed has low data volumes, and pretty low growth. Our DBA did say that if we had high data growth, due to the consolidated tables, he perhaps wouldn't have allowed it.
I recommend you give it a look.
September 16, 2014 at 3:00 am
Whenever I have come across the need for auditing then the preference by the business was against a home spun solution and for the deployment of a third party system as it was deemed easier to justify its selection on the basis that it was less open to subversion (original meaning, not the source control product). This could be argued either way and, I believe, totally dependent upon the auditing product selected.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 16, 2014 at 7:38 am
I am currently using ApexSQL Audit for DML changes on sensitive databases. It's trigger based, but the part I really like is the Audit Viewer tool they make, you can give that tool to security users who need to view the audit logs, and its easy to use interface makes them happy.
September 16, 2014 at 7:52 am
I mostly use Redgate and home grown solutions for DDL audits. Fortunately, I work mostly with OLAP databases and DML is not as big an issue. That auditing is handled in ETL processes.
Aigle de Guerre!
September 16, 2014 at 8:39 am
Where I work, we're not only interested in who changes data, we need to know who looks at it too.
We try to monitor access by using stored procs as the access point, and having the procs log the who and when.
However, what if someone finds a way to view data without using the procs?
We'd like to have another line of defense so we could at least know when that happens, something like a trigger that fires for SELECT events.
We spent some time trying to find tools to audit for SELECT activity, and were surprised to find that there's not much out there!
The audit stuff in SQL2012 (event-based, not the C2 stuff) can track SELECTs, but it's not very granular and is cumbersome when trying to monitor just a couple of things in a large, busy database.
(I think Extended Events has potential here, but I haven't had time to fully investigate that yet).
I'd like to see more options for monitoring SELECTs at a granular level.
3rd-party tool industry, I'm talking to you!
Does anyone else have this problem?
What are you folks doing to track it?
September 16, 2014 at 9:55 am
We audit select data using before and after writes for adds,updates, and deletes. For some tables we also have deny update and deny deletes in place. In certain sensitive data situations we log the daylights out of the transactions and retain the logs for some time as part of the history chain of custody of the transaction.
The audit data is kept for a variable length of time, but most kept for a long time. The audit data is backed up with the transactional data as well.
Not all gray hairs are Dinosaurs!
September 16, 2014 at 8:01 pm
IIRC, in SQL 2005 and above you could set certain columns only visible to certain groups/users. So you can create an admin level and give them fully visible, but the user groups you could set the SSN, birth date, etc. not visible. It is probably a bother to do something like that, but is another option
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
September 17, 2014 at 9:29 am
crussell-931424 (9/17/2014)
I'm a data guy. The more data the better, in general. But there are times when there is so much of it, it covers up the really important stuff, requiring ever more improved ways to analyze it all.
+Excellent
Not all gray hairs are Dinosaurs!
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply