Can Auditing Fail?

  • Comments posted to this topic are about the item Can Auditing Fail?

  • Guess I am that "someone" whose auditing requirements surprised you 😀

    one of the needs for auditing to be async is, in most of the shops, the infrastructure and applications are handled by purely different teams. If the auditing is failing, infra team is held purely responsible for it and application teams don't want any impact to the application and obviously don't want to be held answerable.

  • I fully agree with the editorial. If there are legal or policy requirements auditing must not fail.

  • What is the cost of the audit, and what are the alternatives? The cost aren't just IT costs, but lost business or operations. I'd like to see a switch that could override the auditing on a logged basis. In the end, it is someone attesting to the system that makes it part of the record.

    412-977-3526 call/text

  • Auditing for the purpose of solving a system problem seems reasonable. But auditing for legal reasons makes me feel I am being held hostage by the crooks. We do it because we have to prove we are doing something right. Would anyone ever do that on their own system if no one else was ever using it? Sometimes I years for those good old days when the company was really small and we could just do things to the system and data whenever we needed to to keep things running smoothly. Now we have to prove to the outside world that we aren't the bad guys.

  • In most scenarios the auditing operation should be done asynchonously, if possible, for performance reasons. But you can't do that if the auditing operation is bundled within batch transaction.

    Another reason for separating the auditing operation from the batch transaction is that in the event the batch transaction fails, so does the audit event. I'm sure we're all familiar with the scenario where an error occurs, the error is logged to an audit table... but then the audit table insert is rolled back along with the rest of the batch transaction thus leaving no evidence that the error occurred.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Agree totally!

    One of the most frustrating things about the default tracee was the fact that one can not change the size and number of the rollover files. This meant for us that in some cases the default trace was rolling over all files in as little as 5 hours. Ok its easy to say increase your off host backups etc., but to what frequency? Should the servers get busier then do we keep on increasing these? Do we set up a filewatcher to check that the trace has rolled over and then back up the previous file. Why can we not just have the ability to amend the size and number of the default trace files?

    In the end we created another trace based on the default but with bigger and more numerous files.

    Regards

  • If your auditing process is failing, then that should be a top priority for investigation, and in something like a financial transaction database, you may want to consider suspending operation until the root cause is discovered and corrected.

    It's sort of like a branch manager walking into the bank one morning and finding the security guard's post empty for the first time in years. Maybe there is a mundane explanation, perhaps the guard suddenly got sick, but it still leaves one with an uneasy feeling that something is off and needs to be resolved before opening the doors for normal business.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • @Jeff_C

    In case, if you haven't read today's article

    http://www.sqlservercentral.com/articles/Audit/124740/ 🙂

  • lol - I had but thanks 😀

  • arr.nagaraj (5/4/2015)


    Guess I am that "someone" whose auditing requirements surprised you 😀

    one of the needs for auditing to be async is, in most of the shops, the infrastructure and applications are handled by purely different teams. If the auditing is failing, infra team is held purely responsible for it and application teams don't want any impact to the application and obviously don't want to be held answerable.

    I get not wanting to be impactful, but then what's the point of auditing? If it's just to troubleshoot or check when things go wrong, this might be fine. If it's to provide an accurate record of what happens, this isn't doing that. Or at least not guaranteeing that.

  • Eric M Russell (5/5/2015)


    In most scenarios the auditing operation should be done asynchonously, if possible, for performance reasons. But you can't do that if the auditing operation is bundled within batch transaction.

    Another reason for separating the auditing operation from the batch transaction is that in the event the batch transaction fails, so does the audit event. I'm sure we're all familiar with the scenario where an error occurs, the error is logged to an audit table... but then the audit table insert is rolled back along with the rest of the batch transaction thus leaving no evidence that the error occurred.

    This this isn't auditing, nor is it architected well. If I wanted to teach someone about auditing, this would be the issue. Need a variable that can be logged at the end storing the actions.

  • Steve Jones - SSC Editor (5/5/2015)


    Eric M Russell (5/5/2015)


    In most scenarios the auditing operation should be done asynchonously, if possible, for performance reasons. But you can't do that if the auditing operation is bundled within batch transaction.

    Another reason for separating the auditing operation from the batch transaction is that in the event the batch transaction fails, so does the audit event. I'm sure we're all familiar with the scenario where an error occurs, the error is logged to an audit table... but then the audit table insert is rolled back along with the rest of the batch transaction thus leaving no evidence that the error occurred.

    This this isn't auditing, nor is it architected well. If I wanted to teach someone about auditing, this would be the issue. Need a variable that can be logged at the end storing the actions.

    That's why I prefer to raise the error back to the calling application, or return a status code. I hate looking at a stored procecure that's six pages long and two of them are just error handling and auditing. It's a lot cleaner to implement global auditing and error handling in the application.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • I think we are discussing two entirely different requirements here. One relates to a company / legal requirement to ensure that various activities are traced in their entirety irrespective of where or how they were initiated. The other is not auditing as such, but application event logging.

  • I'd argue auditing needs to be in the database when it affects data or legal requirements. App logging certainly should always be included.

Viewing 15 posts - 1 through 15 (of 27 total)

You must be logged in to reply to this topic. Login to reply