auditing with context?

[Elhanan]

hi..

it would seem that generic auditng (for us anyway) always have a
problem, of not knowing the 'context' , meaning it's all nice to know
which fields where changed and when, but to have more data, like what
logic operation was perfromed in regards to which active parent
objects, now there lies the rub.

the user when getting reports would like to know more then just a list
of fields , so it would seem that a generic method which jumps up on
each buisness method being called, only get the current context (via
interfface which would implemented differently each time) is a
condradiction in terms.

 

[Martin Gregorie]

the user when getting reports would like to know more then just a list
of fields , so it would seem that a generic method which jumps up on
each buisness method being called, only get the current context (via
interfface which would implemented differently each time) is a
condradiction in terms.

This is a system design issue rather than anything that's Java specific.

Its probably best implemented by doing all database updates through
stored procedures that generate the audit log while doing any auditable
database operation. If you want to record context then this must must be
passed as a parameter to every stored procedure that generates audit
trail entries. Context can be quite bulky: the user name, a timestamp,
description of the operation and the name of the implementing class are
all relevant and may be merely a subset of the context required if the
system contains sensitive data. I haven't mentioned tracking field-level
changes to the database - that's a given of you're doing anything like
this.

However, doing this will carry costs during design and implementation as
well as imposing disk storage and and processing overheads. Storage
overheads need to be properly sized as they may be larger than anybody
can guess. Indeed, the audit trail is probably a multi-table section of
the database.

I'd say that management buy-in is essential if auditing is to be properly
costed and those costs approved. Its also essential if the audit trail is
actually used to track down bugs and user access violations.

 

[Lew]

This is a system design issue rather than anything that's Java specific.

Its probably best implemented by doing all database updates through
stored procedures that generate the audit log while doing any auditable
database operation. If you want to record context then this must must be
passed as a parameter to every stored procedure that generates audit
trail entries. Context can be quite bulky: the user name, a timestamp,
description of the operation and the name of the implementing class are
all relevant and may be merely a subset of the context required if the
system contains sensitive data. I haven't mentioned tracking field-level
changes to the database - that's a given of you're doing anything like
this.

However, doing this will carry costs during design and implementation as
well as imposing disk storage and and processing overheads. Storage
overheads need to be properly sized as they may be larger than anybody
can guess. Indeed, the audit trail is probably a multi-table section of
the database.

I'd say that management buy-in is essential if auditing is to be properly
costed and those costs approved. Its also essential if the audit trail is
actually used to track down bugs and user access violations.

Is this even a database question?

The OP discussed "fields", not a relational database concept, business
methods, logic operations and parent objects. This sounds like a
code-coverage question.

What confuses me is the mention of what "the user ... would like to know".
This kind of auditing is rarely user-space but maintenance-space, for the
benefit of operations personnel and maintenance programmers.

If this is about code coverage, it sounds like
a) rather too much work for too little benefit, and
b) a job for a logging aspect to the code.

 

[Martin Gregorie]

Is this even a database question?

I think it has to be. Asking about auditing changes to a list of fields
doesn't make much sense otherwise.

The OP discussed "fields", not a relational database concept, business
methods, logic operations and parent objects. This sounds like a
code-coverage question.

I've heard the terms 'fields' and 'columns' used interchangeably in
discussions about databases, but I was probably too specific in the terms
I used. For 'database' assume a data collection, not necessarily
controlled by an RDBMS. For 'stored procedure' read some sort of auditing
module built into the system between business logic and the data store.
Auditing belongs in the application infrastructure, not in the business
logic.

What confuses me is the mention of what "the user ... would like to
know". This kind of auditing is rarely user-space but maintenance-space,
for the benefit of operations personnel and maintenance programmers.

I took 'the user' to mean the project sponsor, who might well specify
fairly heavy duty data access audit trails for sensitive data. Granted,
the project sponsor requiring adequate audit trails would be a first in
many organizations but it shouldn't be like that.

If this is about code coverage, it sounds like a) rather too much work
for too little benefit, and b) a job for a logging aspect to the code.

Agreed, but I don't think that's what was meant, since there are
typically no users of any type involved in code coverage considerations.

 

[Arved Sandstrom]

[ SNIP ]

What confuses me is the mention of what "the user ... would like to know".
This kind of auditing is rarely user-space but maintenance-space, for the
benefit of operations personnel and maintenance programmers.

[ SNIP ]

Some of the production applications I work on right now audit changes to JPA
entities (updates, inserts, deletes) using entity lifecycle methods, audit
access to services (session EJBs) using interceptors, and audit page access
using JSF phase listeners. So, yes, the users here are operations personnel
and maintenance programmers.

AHS