Auditing with C# and .NET

user_658809 0
Viewed 19626

I have a web application, and I would like to audit most of the users actions on the application, for example login, insertion to db, update to db, fired exceptions, etc.

One of my senios suggested using a queue for faster performance, so you just enqeue an event and it is then processed automatically without having to wait for it to be processed.

What are your suggestions? How should I process them? Enqueueing them is no problem, but I'm not sure how they will be processed then without no body calling a method.

I am using C# with .NET 4.0

audit logging .net c#
5 Answers

(Little late on the answer, this post shows up high in google, so I thought it may be worth looking at some of the options)

If you are looking to actually audit. (By this I mean to record that an action took place, who did it and when, and for that auditable log to be able to be used as evidence to an external auditor)

(Debug Logging vs Auditing logging)

If so, you can consider some options, such as:

  1. use an Audit logging library
  2. adopt an EventStore database
  3. use a logging library that fails loudly

1. using an audit library

  • Audit.NET has already been mentioned here and has an impressive number of downloads and is very feature-rich
  • auditable - an alternative to the above (disclaimer, its written by me)

both are pretty cool, as they allow you to bring your own datastore

2. Eventsourcing

The design here (which can impact your architecture to embrace Events) is that Events are immutable, and if you store them then you have an auditable store of things that happened in your system

note this does not look to solve the question above, but it does solve how to audit, so I have mentioned it

3. Logging library

you have to confirm that the logging library if it fails to add an Audit Log, it will throw an exception.

if it does not do that then you will be missing auditable logs, which then you cannot build trust with your Auditors

Side note 1 - with options 1 and 3, you may need to ensure that the log is written in the same transaction as your primary data store. to ensure that all of the information is ACID. (this is similar to the issue people have with publishing an event which is outside of the database transaction)

Side note 2 - that audit logs should be able to identify who did what, so you may/should need to encrypt the datastore they eventually end up in.

user_476420
Related